K32 vs K35
Following is a summary of changes in the display drivers between K32 and K35 versions in git tree http://git.omapzoom.org/?p=kernel/omap.git;a=summary (L27x release)
Changes in DSI driver
- Two HSDIVIDERS of DSI PLL regm3 and regm4 (in K32) are renamed to regm_dispc and regm_dsi in K35 in order to make them more generic. So while filling the DSI PLL parameters in the omap_dss_device structure in the board file, we need to ensure that regm3 and regm4 are replaced by regm_dispc and regm_dsi.
- If the DSI panel driver is modeled according to panel-taal.c, the omap_dss_device structure shouldn't need the function pointer members platform_enable and platform_disable to be populated. In other words, platform_enable and platform_disable are called whenever the panel is enabled and disbaled. If mux settings, gpio requests etc. are done in this function, then they will be unnecessarily called every time the panel is enabled/disabled, it is better to move them to something like omap4_display_init().
Changes that came in via open source community:
- DSI framedone interrupt handling was improved to reduce latency. This mainly changes the way commmand mode works.
- Panel Taal driver underwent cleanups. Specifically, it now has improved error handling, mutex and bus locking, optimized taal rotation, tearing functions.
Patches can be seen in:
- DSI timers (like LP RX, HS TX) are increased in order to prevent false timeouts.
Changes via L24x/L27x:
- In K32, DSI command mode K32 worked on a hacked auto update scheme (we sent command mode frames at a regular frequency). On K35 we moved to manual update mode. This should not impact video mode.
- Register configuration changes were done for following reasons: DSI PLL driven at lower frequencies, clock sources shifted to DSI PLL, DSI control register bits changed.
- Improved error recovery mechanism tries to reset DSI, and then the panel if some errors are detected by the dsi_irq_handler.
- DSS_FCLK, DSIx_FCLK, LCDx_CLK clock sources changed from PRCM DPLL to DSI PLLs to save power.
Changes in DPI driver
- The DPI(rgb) driver now needs the required pixel clock to be filled in the platform-specific board file. In K32 the required pixel clock was hardcoded in the drivers/video/omap2/dss/dpi.c driver. In particular, the following parameters were hardcoded in the driver in K32:
a) DSI PLL regm
b) DSI PLL regn
c) DSI PLL regm_dispc (REGM4 in TRM)
d) DSI_PLL regm_dsi (REGM5 in TRM)
In K35, only the DSI PLL's parameters (from (a) to (d)) are hardcoded in dpi.c driver, the DISPC_DIVISOR2 parameters ((e) and (f)) are now calculated based on the pixel clock requested in the board file. Hence it is necessary to populate the panel.timings.pixel_clock member in omap_dss_device struct before the dpi panel is enabled.
Above changes came in as follows:
Following changes came in via open source:
- This provides 2 options of either getting the required pixel clock from the PRCM DSS_FCLK or the DSI PLL.
- If we get it from DSS_FCLK: The code loops around a) The PRCM DPLL divisor b) DISPC_DIVISOR2.lcd c) DISPC_DIVISOR2.pcd to get the closest possible value to the pixel clock. It then sets them to get the required pixel clock.
- If we get it from DSI PLL: In this case the PRCM clock is fixed, the driver loops around regm, regn, regm3 (or regm4), DISPC_DIVISOR2.lcd and DISPC_DIVISOR2.pcd to get the desired pixel clock.
- The driver tries to align with the open source approach, but doesn't vary the DSS_FCLK coming from the PRCM.
- If pixel clock comes from PRCM: Patch iterates through fixed PRCM clock, DISPC_DIVISOR2.lcd and DISPC_DIVISOR2.pcd.
- If it comes from DSI PLL: Patch takes fixed PLL parameters (regm, regn, regm_dispc etc.) but iterates through different values of DISPC_DIVISOR2.lcd and DISPC_DIVISOR2.pcd.
Changes between L27.10.1 and L27.10.1-p1
- The following is the patch which makes the changes as mentioned above:
Changes in omap_dss_device structure and its impact on platform-specifc board file (board-4430sdp.c)
Movement of control functions from omap_dss_device to display driver:
- On K32, the omap_dss_device structure exposed function pointers for various control operations like enable, disable, suspend, resume, set_mirror, get_mirror, get_rotate, set_rotate, get_update_mode etc. These have been moved to the omap_dss_driver structure.
- Now, the panel driver provides these control functions by filling up its omap_dss_driver structure. Previously, it was done by the interface drivers (dpi.c, dsi.c, etc.).
- The panel driver and the interface driver now communicate with each other through a generic set of exported functions. For example, consider a pointer to the structure omap_dss_device named dssdev. Previously, a user of the panel device(V4L2/FB) would call dssdev->enable, now it calls dssdev->driver->enable. Suppose the device is, say, panel taal, then the function would map to taal_enable(). This function would further call omapdss_dsi_display_enable(), this is a function which will be used in the enable functions of all panel drivers which are of the type DSI. Hence, taal_enable() enables the dsi interface and also sets up panel related data. The present sequence of calls is:
omapfb_probe() calls dssdev->driver->enable() which points to omapdss_dsi_display_enable()
- In K32, the sequence was:
omapfb_probe() calls dssdev->enable() which points to dsi_display_enable()
- A good reference patch for the change set is:
Change in names of DSI PLL parameters regm3 and regm4:
- regm3 and regm4 have changed to regm_dispc and regm_dsi, this would need to be changed in the omap_dss_device struct of DSI panels in the board file. Reference patch:
Use of uniform display_enable and display_disable functions:
- In arch/arm/plat-omap/include/plat/display.h, 2 new functions omapdss_display_enable()/disable() have been introduced so that FB and V4L2 don't need to care about the previous state of the panel. These functions internally check the previous state and decide whether the panel is to be enabled or not. For example, it will ensure that if a suspended panel is tried to be enabled, the actual enable will happen only after FB or V4L2 calls panel resume.
- Refer Patches:
http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=04dbab98e7a6ca9b6470974df81eb99dd6fa207e Use of panel_start and panel_stop functions:
- Code common to suspend/resume/enable/disable in the panel driver is placed into new functions panel_start() and panel_stop(). For example, the change made for pico-dlp is in the following patch:
Removal of certain omap_dss_device members:
- The members reset_gpio, ext_te, ext_te_gpio have been removed from the omap_dss_device structure. These parameters now have to be passed to the panel driver through the void pointer data member in omap_dss_device struct.
- A good reference would be to see the taal omap_dss_device structure definition in the arch/arm/mach-omap2/board-4430sdp.c file and the corresponding taal_probe() function in drivers/video/omap2/displays/panel-taal.c
Power Management/HWMOD changes
- There was no OMAP4 PM support in K32. K35 has HWMOD support for DSS. All H/W blocks (dsi, dispc, hdmi etc) behave as independent platform devices, and get resources such as clocks, irqs etc. from HWMOD framework. Refer to introductory section at following link for further details on HWMOD: http://www.omappedia.org/wiki/HWMOD
- A central framework using PM runtime framework to enable and disable DSS mainclock and opt-clocks.
- Aggressive clock management calls in DSS functions (i.e. enable_clocks() and disable_clocks() seen at the beginning and the end of each function) are ignored for OMAP4. Now, all clocks are enabled when the first panel is enabled, and disabled when the last panel in "enabled" state is "disabled/suspended".
- PM runtime framework takes care of switching to retention state once the opt clocks and mainclk are disabled.
Following are some of the main patches that make up the PM framework for OMAP4 DSS (chronological order):
- Optional clock support for OMAP4 (these need to be handled separately, as HWMOD doesn't take care of optional clocks).
- Adding pm_runtime APIs for DSS.
- Removing aggressive clock cutting from DSS.
- Enabling display in omap_hwmod_44xx_data file.
- Core retention and CPU idle framework for DSS.
- dss_opt clock cutting in pm44xx.c.
- Enable/Disable 48Mhz optclocks for HDMI.
- Adding PM constraints for omap_vout driver.
- Enable dss opt clocks only after resmuing gpio related clocks as dss uses gpio lines.
- Introduce a state variable for enabling and disabling mainclk. This is required for removing checks of dssdev->state from each dss interface drivers.
- Return from omap_dss_mgr_apply if main clock is disabled.
- Fail registration of DSS isr's if mainclk is diabled since they write/read to DISPC registers.
- Remove omap_dss_prepare_idle and omap_dss_resume_idle as we will cut DSS clocks immediately when displays are disabled/suspended.
- If DSS is off we should not (and there is no need to) set the pipeline's channel out.
- Add error status to mainclk and opt_clock enable methods.
- Enable optional clocks with mainclk on OMAP4.
- Make multiple suspends and resume work correctly.
- Fixes for HDMI power state handling. Refer git log in following link for more details.
- Cut clocks when DSS devices (DSI/DPI/HDMI) are disabled. Enable clocks when they are enabled.
- Introduction of Writeback pipeline brings changes in v4l2 (omap_vout.c, omap_wb.c) and DSS2 core files like manager.c, dispc.c etc.
- Adaptation of Tiler 2.0 is now present in k35 driver.
- Fixes for HDMI 1.3 compliance, introduction of HDMI states, changes related to S3D, power management fixes, attach/detatch interrupt fixes.
Refer to git log at following link for full set of changes:
Most importantly refer to the information in this link:
Other general changes
- Interlaced and predecimation support.
- Addition of s3d drivers in v4l2.
- fb notification mechanism: tells fb driver that the framebuffer device is now connected to a panel of different resolution.
- OMAP4 ES2.0 changes.
- Pico driver cleanup.
- Some fixes in omapfb from open-source community.
- Cleaner scaling support (more FIR filter coefficient tables).
- Patches for 3430 and 3630 backward compatibility.
- No VENC support, No flicker filter support for TV out for OMAP4.