summaryrefslogtreecommitdiffstats
path: root/drivers/video
Commit message (Collapse)AuthorAgeFilesLines
* OMAPFB: fix framebuffer console colorsGrazvydas Ignotas2012-08-231-1/+1
| | | | | | | | | | | | | omapfb does not currently set pseudo palette correctly for color depths above 16bpp, making red text invisible, command like echo -e '\e[0;31mRED' > /dev/tty1 will display nothing on framebuffer console in 24bpp mode. This is because temporary variable is declared incorrectly, fix it. Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Cc: stable@vger.kernel.org # v3.x Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
* OMAPDSS: Fix SDI PLL lockingTomi Valkeinen2012-08-231-0/+14
| | | | | | | | | | | | | | | | | | | | Commit f476ae9dab3234532d41d36beb4ba7be838fa786 (OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in interface) broke the SDI output, as it causes the SDI PLL locking to fail. LCLK and PCLK divisors are located in shadow registers, and we normally write them to DISPC registers when enabling the output. However, SDI uses pck-free as source clock for its PLL, and pck-free is affected by the divisors. And as we need the PLL before enabling the output, we need to write the divisors early. It seems just writing to the DISPC register is enough, and we don't need to care about the shadow register mechanism for pck-free. The exact reason for this is unknown. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
* video: mb862xxfb: prevent divide by zero bugDan Carpenter2012-08-231-0/+2
| | | | | | | | Do a sanity check on these before using them as divisors. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Anatolij Gustschin <agust@denx.de> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
* drivers/video/auo_k190x.c: drop kfree of devm_kzalloc's dataJulia Lawall2012-08-231-2/+0
| | | | | | | | | | | | | | | | | | | | Using kfree to free data allocated with devm_kzalloc causes double frees. The semantic patch that fixes this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression x; @@ x = devm_kzalloc(...) ... ?-kfree(x); // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
* fbcon: Fix bit_putcs() call to kmalloc(s, GFP_KERNEL)Bruno Prémont2012-08-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Switch to kmalloc(,GFP_ATOMIC) in bit_putcs to fix below trace: [ 9.771812] BUG: sleeping function called from invalid context at /usr/src/linux-git/mm/slub.c:943 [ 9.771814] in_atomic(): 1, irqs_disabled(): 1, pid: 1063, name: mount [ 9.771818] Pid: 1063, comm: mount Not tainted 3.5.0-jupiter-00003-g8d858b1-dirty #2 [ 9.771819] Call Trace: [ 9.771838] [<c104f79b>] __might_sleep+0xcb/0xe0 [ 9.771844] [<c10c00d4>] __kmalloc+0xb4/0x1c0 [ 9.771851] [<c1041d4a>] ? queue_work+0x1a/0x30 [ 9.771854] [<c1041dcf>] ? queue_delayed_work+0xf/0x30 [ 9.771862] [<c1205832>] ? bit_putcs+0xf2/0x3e0 [ 9.771865] [<c1041e01>] ? schedule_delayed_work+0x11/0x20 [ 9.771868] [<c1205832>] bit_putcs+0xf2/0x3e0 [ 9.771875] [<c12002b8>] ? get_color.clone.14+0x28/0x100 [ 9.771878] [<c1200d2f>] fbcon_putcs+0x11f/0x130 [ 9.771882] [<c1205740>] ? bit_clear+0xe0/0xe0 [ 9.771885] [<c1200f6d>] fbcon_redraw.clone.21+0x11d/0x160 [ 9.771889] [<c120383d>] fbcon_scroll+0x79d/0xe10 [ 9.771892] [<c12002b8>] ? get_color.clone.14+0x28/0x100 [ 9.771897] [<c124c0b4>] scrup+0x64/0xd0 [ 9.771900] [<c124c22b>] lf+0x2b/0x60 [ 9.771903] [<c124cc95>] vt_console_print+0x1d5/0x2f0 [ 9.771907] [<c124cac0>] ? register_vt_notifier+0x20/0x20 [ 9.771913] [<c102b335>] call_console_drivers.clone.5+0xa5/0xc0 [ 9.771916] [<c102c58e>] console_unlock+0x2fe/0x3c0 [ 9.771920] [<c102ca16>] vprintk_emit+0x2e6/0x300 [ 9.771924] [<c13f01ae>] printk+0x38/0x3a [ 9.771931] [<c112e8fe>] reiserfs_remount+0x2ae/0x3e0 [ 9.771934] [<c112e650>] ? reiserfs_fill_super+0xb00/0xb00 [ 9.771939] [<c10ca0ab>] do_remount_sb+0xab/0x150 [ 9.771943] [<c1034476>] ? ns_capable+0x46/0x70 [ 9.771948] [<c10e059c>] do_mount+0x20c/0x6b0 [ 9.771955] [<c10a7044>] ? strndup_user+0x34/0x50 [ 9.771958] [<c10e0acc>] sys_mount+0x6c/0xa0 [ 9.771964] [<c13f2557>] sysenter_do_call+0x12/0x26 According to comment in bit_putcs() that kammloc() call only happens when fbcon is drawing to a monochrome framebuffer (which is my case with hid-picolcd). Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
* fbcon: prevent possible buffer overflow.Paul Cercueil2012-08-231-1/+1
| | | | | Signed-off-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
* fbcon: fix race condition between console lock and cursor timer (v1.1)Dave Airlie2012-08-221-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So we've had a fair few reports of fbcon handover breakage between efi/vesafb and i915 surface recently, so I dedicated a couple of days to finding the problem. Essentially the last thing we saw was the conflicting framebuffer message and that was all. So after much tracing with direct netconsole writes (printks under console_lock not so useful), I think I found the race. Thread A (driver load) Thread B (timer thread) unbind_con_driver -> | bind_con_driver -> | vc->vc_sw->con_deinit -> | fbcon_deinit -> | console_lock() | | | | fbcon_flashcursor timer fires | console_lock() <- blocked for A | | fbcon_del_cursor_timer -> del_timer_sync (BOOM) Of course because all of this is under the console lock, we never see anything, also since we also just unbound the active console guess what we never see anything. Hopefully this fixes the problem for anyone seeing vesafb->kms driver handoff. v1.1: add comment suggestion from Alan. Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
* Merge tag 'fbdev-updates-for-3.6' of git://github.com/schandinat/linux-2.6Linus Torvalds2012-08-0148-1089/+2468
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull fbdev updates from Florian Tobias Schandinat: - large updates for OMAP - support for LCD3 overlay manager (omap5) - omapdss output cleanup - removal of passive matrix LCD support as there are no drivers for such panels for DSS or DSS2 and nobody complained (cleanup) - large updates for SH Mobile - overlay support - separating MERAM (cache) from framebuffer driver - some updates for Exynos and da8xx-fb - various other small patches * tag 'fbdev-updates-for-3.6' of git://github.com/schandinat/linux-2.6: (78 commits) da8xx-fb: fix compile issue due to missing include fbdev: Make pixel_to_pat() failure mode more friendly da8xx-fb: do not turn ON LCD backlight unless LCDC is enabled fbdev: sh_mobile_lcdc: Fix vertical panning step video: exynos mipi dsi: Fix mipi dsi regulators handling issue video: da8xx-fb: do clock reset of revision 2 LCDC before enabling arm: da850: configure LCDC fifo threshold video: da8xx-fb: configure FIFO threshold to reduce underflow errors video: da8xx-fb: fix flicker due to 1 frame delay in updated frame video: da8xx-fb rev2: fix disabling of palette completion interrupt da8xx-fb: add missing FB_BLANK operations video: exynos_dp: use usleep_range instead of delay video: exynos_dp: check the only INTERLANE_ALIGN_DONE bit during Link Training fb: epson1355fb: Fix section mismatch video: exynos_dp: fix wrong DPCD address during Link Training video/smscufx: fix line counting in fb_write aty128fb: Fix coding style issues fbdev: sh_mobile_lcdc: Fix pan offset computation in YUV mode fbdev: sh_mobile_lcdc: Fix overlay registers update during pan operation fbdev: sh_mobile_lcdc: Support horizontal panning ...
| * da8xx-fb: fix compile issue due to missing includeFlorian Tobias Schandinat2012-07-291-0/+1
| | | | | | | | Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
| * fbdev: Make pixel_to_pat() failure mode more friendlyBenjamin Herrenschmidt2012-07-291-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | If we accidentally pass an incorrect bpp value to pixel_to_pat(), it panics. This is pretty useless, as we generally have the various console locks held at that point, so nothing will be displayed, and there is no reason to make this a fatal event. Let's WARN instead. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
| * da8xx-fb: do not turn ON LCD backlight unless LCDC is enabledManjunathappa, Prakash2012-07-291-4/+5
| | | | | | | | | | | | | | | | | | | | LCD blink is observed during suspend/resume and blank/unblank operations as backlight is ON during LCDC disable and enable. So make sure to turn OFF backlight before disabling and turn it ON after enabling. Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
| * fbdev: sh_mobile_lcdc: Fix vertical panning stepLaurent Pinchart2012-07-291-6/+6
| | | | | | | | | | | | | | | | | | Commit 15dede882e564601947f2ce4b647742c0351be6d added support for horizontal panning but accidentally computes the Y pan step value incorrectly for NV12/21 and NV16/61 formats. Fix this. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
| * video: exynos mipi dsi: Fix mipi dsi regulators handling issueDonghwa Lee2012-07-291-1/+1
| | | | | | | | | | | | | | | | | | When FB_BLANK_UNLANK event occured, exynos mipi dsi regulators have to turn on. Signed-off-by: Donghwa Lee <dh09.lee@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
| * video: da8xx-fb: do clock reset of revision 2 LCDC before enablingManjunathappa, Prakash2012-07-291-4/+8
| | | | | | | | | | | | | | | | | | | | As in specification software reset should be applied for several cycles before bringing it out of reset. Without this patch particularly during suspend and resume clock reset is not guaranteed to happen. Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
| * video: da8xx-fb: configure FIFO threshold to reduce underflow errorsManjunathappa, Prakash2012-07-291-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch works around the below silicon errata: During LCDC initialization, there is the potential for a FIFO underflow condition to occur. A FIFO underflow condition occurs when the input FIFO is completely empty and the LCDC raster controller logic that drives data to the output pins attempts to fetch data from the FIFO. When a FIFO underflow condition occurs, incorrect data will be driven out on the LCDC data pins. Software should poll the FUF bit field in the LCD_STAT register to check if an error condition has occurred or service the interrupt if FUF_EN is enabled when FUF occurs. If the FUF bit field has been set to 1, this will indicate an underflow condition has occurred and then the software should execute a reset of the LCDC via the LPSC. This problem may occur if the LCDC FIFO threshold size (LCDDMA_CTRL[TH_FIFO_READY]) is left at its default value after reset. Increasing the FIFO threshold size will reduce or eliminate underflows. Setting the threshold size to 256 double words or larger is recommended. Above issue is described in section 2.1.3 of silicon errata http://www.ti.com/lit/er/sprz313e/sprz313e.pdf Signed-off-by: Rajashekhara, Sudhakar <sudhakar.raj@ti.com> Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
| * video: da8xx-fb: fix flicker due to 1 frame delay in updated frameManjunathappa, Prakash2012-07-291-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Flicker/tearing effect is observed with current FB driver. Issue is because of 2 active DMA channels ping ponging among them along with usage of 2 DDR ping pong buffers in driver. Application unaware of active DMA channel keeps updating frame being displayed, this leads to tearing effect. Below steps describes the issue: 1)Initially assume both buffers FB0 and FB1 are programmed for buffer-0. 2)On EOF0: Program FB0 for buffer-1, indicate(wake up) application to fill up buffer-0. As FB1 is active and continues to DMA buffer-0 (which is being filled), leading to tearing/flickering issue. 3)On EOF1: Program FB1 for buffer-0, indicate(wake up) application to fill up buffer-1. As FB0 is active and continues to DMA buffer-1(which is being filled), leading to tearing/flickering issue. 4)On EOF0: Program FB0 for buffer-1, indicate(wake up) application to fill up buffer-0. As FB1 is active and continues to DMA buffer-0(which is being filled), leading to tearing/flickering issue. ... Above steps depict that issue is because of 1 frame delay in frame panned by application. Patch fixes the issue by keeping track free DMA channel and configures it in drivers PAN callback so that panned frame from application gets displayed in next frame period. Wiki below describes the issue in detail and it also has link to application with which issue can be reproduced. http://processors.wiki.ti.com/index.php/DA8xx_LCDC_Linux_FB_FAQs Signed-off-by: Nellutla, Aditya <aditya.n@ti.com> Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
| * video: da8xx-fb rev2: fix disabling of palette completion interruptManjunathappa, Prakash2012-07-291-5/+2
| | | | | | | | | | | | | | | | | | | | | | Writing '1' to particular bit of IRQENABLE_CLEAR register disables the corresponding interrupt on revision 2 LCDC. This register was wrongly configured to disable all previous enabled interrupts instead of disabling only palette completion interrupt. Patch fixes it by clearing only palette completion interrupt bit. Signed-off-by: Manjunathappa, Prakash <prakash.pm@ti.com> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
| * da8xx-fb: add missing FB_BLANK operationsYegor Yefremov2012-07-291-0/+3
| | | | | | | | | | | | | | | | | | add FB_BLANK_NORMAL, FB_BLANK_VSYNC_SUSPEND and FB_BLANK_HSYNC_SUSPEND modes (copy drivers/video/omap2/omapfb/omapfb-main.c implementation). Otherwise X-server will complain about invalid parameter. Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
| * Merge branch 'for-florian' of git://gitorious.org/linux-omap-dss2/linux into ↵Florian Tobias Schandinat2012-07-2530-634/+1085
| |\ | | | | | | | | | | | | | | | | | | | | | fbdev-next Conflicts: drivers/video/omap2/dss/core.c drivers/video/omap2/dss/dispc.c
| | * OMAPDSS: OVERLAY: Clean up replication checkingArchit Taneja2012-06-294-37/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replication logic for an overlay depends on the color mode in which it is configured and the video port width of the manager it is connected to. video port width now held in dss_lcd_mgr_config in the manager's private data in APPLY. Use this instead of referring to the omap_dss_device connected to the manager. Replication is enabled in the case of TV manager, the video_port_width is set to a default value of 24 for TV manager. Make the replication checking an overlay function since it's more of an overlay characteristic than a display characteristic. Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPDSS: RFBI: Use dss_mgr_enable to enable the overlay managerArchit Taneja2012-06-291-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | The RFBI driver uses a direct DISPC register write to enable the overlay manager. Replace this with dss_mgr_enable() which checks if the connected overlay and managers are correctly configured, and configure DSS for fifomerge. Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPDSS: DISPC: Remove a redundant functionArchit Taneja2012-06-291-16/+6
| | | | | | | | | | | | | | | | | | | | | | | | dss_mgr_is_lcd() available in dss.h does the same thing as dispc_mgr_is_lcd() in dispc.c. Remove the function from dispc.c and replace it with the one in dss.h. Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPDSS: APPLY: Remove usage of omap_dss_device from manual/auto update checksArchit Taneja2012-06-291-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | APPLY needs to know at certain places whether an overlay manager is in manual or auto update mode. The caps of the connected omap_dss_device were used to check that. A LCD manager is in manual update if stallmode is enabled for that manager. TV managers for now always auto update. Return the value of stallmode parameter in the private data 'lcd_confg' in mgr_manual_update() and ovl_manual_update(), for TV managers stallmode field will be false by default. Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPDSS: MANAGER: Check LCD related overlay manager parametersArchit Taneja2012-06-293-1/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The LCD related manager configurations are a part of the manager's private data in APPLY. Pass this to dss_lcd_mgr_config to dss_mgr_check and create a function to check the validity of some of the configurations. To check some of the configurations, we require information of interface to which the manager output is connected. These can be added once interfaces are represented as an entity. Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in interface ↵Archit Taneja2012-06-296-57/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | drivers Replace the DISPC fuctions used to configure LCD channel related manager parameters with dss_mgr_set_lcd_config() in APPLY. This function ensures that the DISPC registers are written at the right time by using the shadow register programming model. The LCD manager configurations is stored as a private data of manager in APPLY. It is treated as an extra info as it's the panel drivers which trigger this apply via interface drivers, and not a DSS2 user like omapfb or omapdrm. Storing LCD manager related properties in APPLY also prevents the need to refer to the panel connected to the manager for information. This helps in making the DSS driver less dependent on panel. A helper function is added to check whether the manager is LCD or TV. The direct DISPC register writes are removed from the interface drivers. Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPDSS: SDI: Configure dss_lcd_mgr_config struct with lcd manager parametersArchit Taneja2012-06-291-16/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create a dss_lcd_mgr_config struct instance in SDI. Fill up all the parameters of the struct with configurations held by the panel, and the configurations required by SDI. Use these to write to the DISPC registers. These direct register writes would be later replaced by a function which applies the configuration using the shadow register programming model. Create function sdi_config_lcd_manager() which fills the mgr_config parameters and writes to the DISPC registers. Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPDSS: DSI: Configure dss_lcd_mgr_config struct with lcd manager parametersArchit Taneja2012-06-291-36/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create a dss_lcd_mgr_config struct instance in DSI. Fill up all the parameters of the struct with configurations held by the panel, and the configurations required by DSI. Use these to write to the DISPC registers. These direct register writes would be later replaced by a function which applies the configuration using the shadow register programming model. The function dsi_configure_dispc_clocks() is now called in dsi_display_init_dispc(), this lets all the lcd manager related configurations happen in the same place. The DISPC_DIVISORo register was written in dsi_configure_dispc_clock(), now it just fills up the dispc_clock_info parameter in mgr_config. The clock_info is written later in dsi_display_init_dispc(). Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPDSS: RFBI: Configure dss_lcd_mgr_config struct with lcd manager parametersArchit Taneja2012-06-291-6/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create a dss_lcd_mgr_config struct instance in RFBI. Fill up all the parameters of the struct with configurations held by the panel, and the configurations required by RFBI. Use these to write to the DISPC registers. These direct register writes would be later replaced by a function which applies the configuration using the shadow register programming model. Create function rfbi_config_lcd_manager() which fills up the mgr_config parameters and writes to the DISPC regs. Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPDSS: DPI: Configure dss_lcd_mgr_config struct with lcd manager parametersArchit Taneja2012-06-291-9/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create a dss_lcd_mgr_config struct instance in DPI. Fill up all the parameters of the struct with configurations held by the panel, and the configurations required by DPI. Use these to write to the DISPC registers. These direct register writes would be later replaced by a function which applies the configuration using the shadow register programming model. The DISPC_DIVISORo registers were written in the functions dpi_set_dispc_clk() and dpi_set_dsi_clk(), now they just fill up the dispc_clock_info parameter in mgr_config. They are written later in dpi_config_lcd_manager. Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPDSS: Add struct to hold LCD overlay manager configurationArchit Taneja2012-06-291-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create a struct dss_lcd_mgr_config which holds LCD overlay manager related parameters. These are currently partially contained in the omap_dss_device connected to the manager, and the rest are in the interface driver. The parameters are directly written to the DISPC registers in the interface drivers. These should eventually be applied at the correct time using the shadow register programming model. This struct would help in grouping these parameters so that they can be applied together. Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPDSS: DISPC: Change return type of dispc_mgr_set_clock_div()Archit Taneja2012-06-295-21/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dipsc_mgr_set_clock div has an int return type to report errors or success. The function doesn't really check for errors and always returns 0. Change the return type to void. Checking for the correct DISPC clock divider ranges will be done when a DSS2 user does a manager apply. This support will be added later. Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPDSS: DSI: Fix HSYNC, VSYNC and DE polarities between DISPC and DSIArchit Taneja2012-06-291-18/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For DSI operation in videomode, DISPC logic levels for the signals HSYNC, VSYNC and DE need to be specified to DSI via the fields VP_HSYNC_POL, VP_VSYNC_POL and VP_DE_POL in DSI_CTRL registers. This information is completely internal to DSS as logic levels for the above signals hold no meaning on the DSI bus. Hence a DSI panel driver should be totally oblivious of these fields. Fix the logic levels/polarities in the DISPC and DSI registers to a default value. This is done by overriding these fields in omap_video_timings struct filled by the panel driver for DISPC, and use the equivalent default values when programming DSI_CTRL registers. Also, remove the redundant polarity related fields in omap_dss_dsi_videomode_data. Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPDSS: HDMI: Remove custom hdmi_video_timings structArchit Taneja2012-06-293-55/+213
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The hdmi CEA and VESA timings were represented by the struct hdmi_video_timings, omap_video_timings couldn't be used as it didn't contain the fields hsync/vsync polarities and interlaced/progressive information. Remove hdmi_video_timings, and use omap_video_timings instead. Cc: Mythri P K <mythripk@ti.com> Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPFB: Map interlace field in omap_video_timings with fb vmode flagsArchit Taneja2012-06-291-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the interlace field in omap_video_timings to configure/retrieve corresponding fb mode flags in fb_var_screeninfo and fb_videomode. The interlace field maps with the fb mode flags FB_VMODE_INTERLACED and FB_VMODE_NONINTERLACED. Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPDSS: DISPC/APPLY: Use interlace info in manager timings for ↵Archit Taneja2012-06-293-8/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dispc_ovl_setup() Currently the interlace parameter passed to dispc_ovl_setup() is configured by checking the display type, and set to true if the display type is VENC. This isn't correct as other panels can take interlaced content too. The omap_video_timings struct in manager's private data contains the info whether the panel is in interlaced mode or not. Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPDSS: Add interlace parameter to omap_video_timingsArchit Taneja2012-06-293-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a parameter called interlace which tells whether the timings are in interlaced or progressive mode. This aligns the omap_video_timings struct with the Xorg modeline configuration. It also removes the hack needed to write to divide the manager height by 2 if the connected interface is VENC. Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPDSS: Remove omap_panel_config enum from omap_dss_deviceArchit Taneja2012-06-299-42/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | omap_panel_config contains fields which are finally written to DISPC_POL_FREQo registers. These are now held by omap_video_timings and are set when the manager timings are applied. Remove the omap_panel_config enum, and remove all it's references from panel or interface drivers. Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPFB: Map the newly added omap_video_timings fields with fb sync flagsArchit Taneja2012-06-291-4/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the newly added fields in omap_video_timings(hsync, vsync and data_enable logic levels and data, hsync and vsync latching related info) to configure/retrieve corresponding sync flags in fb_var_screeninfo and fb_videomode. Out of the new fields, hsync_level and vsync_level can be mapped to the fb sync flags FB_SYNC_HOR_HIGH_ACT and FB_SYNC_VERT_HIGH_ACT. When converting fb mode to omap_video_timings, the fields which don't have an equivalent parameter in fb are kept as the original values if the panel driver has a get_timings op, else they are set to default values. Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPDSS: DISPC: Remove dispc_mgr_set_pol_freq()Archit Taneja2012-06-294-35/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dispc_mgr_set_pol_freq() configures the fields in the register DISPC_POL_FREQo. All these fields have been moved to omap_video_timings struct, and are now programmed in dispc_mgr_set_lcd_timings(). These will be configured when timings are applied via dss_mgr_set_timings(). Remove dispc_mgr_set_pol_freq() and it's calls from the interface drivers. Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPDSS: DISPC: Configure newly added omap_video_timing fieldsArchit Taneja2012-06-291-3/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hsync, Vsync, Data enable enable logic levels and latching info of Data lanes, Hsync and Vsync signals(with respect to pixel clock) are newly added parameters in omap_video_timings. Program these in dispc_mgr_set_lcd_timings. These will be configured when the manager's timings are set via dss_mgr_set_timings(). Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPDSS: DISPLAY: Ignore newly added omap_video_timings fields for display ↵Archit Taneja2012-06-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | timings sysfs file The display sysfs file for viewing/storing display timings is something which will be deprecated. The new omap_video_timings fields (hsync_level, vsync_level and others) are not configurable or viewable via this sysfs file. This prevents the need to make the input more configurable to take the new fields and at the same time work without these fields for backward compatibility. In display_timings_store, the omap_video_timings struct used to set the timings is initialized to the existing panel timings so that the new fields are taken in correctly. The other fields are taken from the user as before. Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPDSS: Add some new fields to omap_video_timingsArchit Taneja2012-06-2910-1/+164
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some panel timing related fields are contained in omap_panel_config in the form of flags. The fields are: - Hsync logic level - Vsync logic level - Data driven on rising/falling edge of pixel clock - Output enable/Data enable logic level - HSYNC/VSYNC driven on rising/falling edge of pixel clock Out of these parameters, Hsync and Vsync logic levels are a part of the timings in the Xorg modeline configuration. So it makes sense to move the to omap_video_timings. The rest aren't a part of modeline, but it still makes sense to move these since they are related to panel timings. These fields stored in omap_panel_config in dssdev are configured for LCD panels, and the corresponding LCD managers in the DISPC_POL_FREQo registers. Add the above fields in omap_video_timings. Represent their state via new enums. Add these parameters to the omap_video_timings instances in the panel drivers. Keep the corresponding IVS, IHS, IPC, IEO, RF and ONOFF flags in omap_panel_config for now. The struct will be removed later. Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPDSS: Remove passive matrix LCD support (part 4)Archit Taneja2012-06-297-39/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove configuration of Ac-bias pins Ac-bias pins need to be configured only for passive matrix displays. Remove acbi and acb fields in omap_dss_device and their configuration in panel drivers. Don't program these fields in DISP_POL_FREQo register any more. The panel driver for sharp-ls037v7dw01, and the panel config for Innolux AT070TN8 in generic dpi panel driver set acb to a non zero value. This is most likely carried over from the old omapfb driver which supported passive matrix displays. Cc: Thomas Weber <weber@corscience.de> Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPDSS: Remove passive matrix LCD support (part 3)Archit Taneja2012-06-296-31/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove omap_lcd_display_type enum The enum omap_lcd_display_type is used to configure the lcd display type in DISPC. Remove this enum and always set display type to TFT by creating function dss_mgr_set_lcd_type_tft(). Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPDSS: Remove passive matrix LCD support (part 2)Archit Taneja2012-06-2913-65/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove OMAP_DSS_LCD_TFT as a omap_panel_config flag. We don't support passive matrix displays any more. Remove this flag from all the panel drivers. Force the display_type to OMAP_DSS_LCD_DISPLAY_TFT in the interface drivers. Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPDSS: Remove passive matrix LCD support (part 1)Archit Taneja2012-06-296-36/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove clock constraints related to passive matrix displays. There is a constraint (pcd_min should be 3) for passive matrix displays. Remove this constraint in clock divider calculations as we won't support passive matrix displays any more. This cleans up the functions which calculate the clock dividers with DSI's PLL or DSS_FCLK as the clock source. Signed-off-by: Archit Taneja <archit@ti.com>
| | * OMAPDSS: HDMI: Replace spinlock with mutex in hdmi_check_hpd_stateJassi Brar2012-06-293-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | State change of HDMI PHY could potentially take many millisecs, we can do better by protecting things in hdmi_set_phy_pwr() with a mutex rather than a spin_lock_irqsave. Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| | * OMAPDSS: HDMI: Discard phy_tx_enabled memberJassi Brar2012-06-292-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | It is simpler to read the current status from a register as compared to maintaining a state variable to hold the information. Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| | * OMAPDSS: Add dump and debug support for LCD3Chandrabhanu Mahapatra2012-06-291-30/+40
| | | | | | | | | | | | | | | | | | | | | | | | DISPC functions have been modified to provide clock and register dumps and debug support for the LCD3 manager. Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| | * OMAPDSS: Add LCD3 overlay manager and Clock and IRQ supportChandrabhanu Mahapatra2012-06-296-9/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The support for LCD3 manager has been added into the manager module. LCD3 panel has registers as DISPC_CONTROL3 and DISPC_CONFIG3 just like those in LCD and LCD2 panels. These registers control the Display Controller (DISPC) module for LCD3 output. The three LCDs support Display Serial Interface (DSI), Remote Frame Buffer Interface (RFBI) and Parallel CMOS Output Interface (DPI). These LCDs can be connected through parallel output interface using DISPC and RFBI or DPI. For serial interface DSS uses DSI. The LCD3 panel, just like LCD and LCD2 panels, has a clock switch in DSS_CTRL register which has been enabled. The clock switch chooses between DSS_CLK and DPLL_DSI1_C_CLK1 as source for LCD3_CLK. New IRQs as DISPC_IRQ_VSYNC3, DISPC_IRQ_FRAMEDONE3, DISPC_IRQ_ACBIAS_COUNT_STAT3 and DISPC_IRQ_SYNC_LOST3 have been added specific to the new manager. Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
OpenPOWER on IntegriCloud