summaryrefslogtreecommitdiff
path: root/drivers/video/omap2
AgeCommit message (Collapse)Author
2011-07-21Revert "Merge remote-tracking branch 'arm-soc/for-next' into linaro-3.0"Nicolas Pitre
This reverts commit c7e0c8535d73f8c5bf760926a2bd71c9840cf2ef, reversing changes made to dfee09c8acf18e84fe197bb5d821d1e4e02d020f. John Stultz reports that Panda doesn't boot anymore and 'git bisect' indicated the merge commit itself as the culprit. The resulting kernel log is: [ 1.734802] OMAP DSS rev 4.0 [ 1.740417] omap_hwmod: dss_core: _wait_target_disable failed [ 1.746429] omap_device: omapdss_dss.-1: new worst case deactivate latency 01 [ 1.755035] omapdss DISPC error: can't get dss_clk [ 1.760101] omapdss_dispc: probe of omapdss_dispc failed with error -2 [ 1.767333] omapdss HDMI error: can't get hdmi_clk [ 1.772399] omapdss_hdmi: probe of omapdss_hdmi failed with error -2 [ 1.780273] ------------[ cut here ]------------ [ 1.785125] WARNING: at drivers/video/omap2/dss/dispc.c:553dispc_runtime_ge) [ 1.793640] Modules linked in: [ 1.796905] ---[ end trace 6fcb132ac310d004 ]--- [ 1.801757] Unable to handle kernel NULL pointer dereference at virtualaddr0 [...] Revert it so a later version of the arm-soc merge result can be used instead.
2011-06-22OMAP: DSS2: DSS: Fix context save/restoreTomi Valkeinen
The current method of saving and restoring the context could cause a restore before saving, effectively "restoring" zero values to registers. Add ctx_valid field to indicate if the saved context is valid and can be restored. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-06-22OMAP: DSS2: DISPC: Fix context save/restoreTomi Valkeinen
The current method of saving and restoring the context could cause a restore before saving, effectively "restoring" zero values to registers. Add ctx_valid field to indicate if the saved context is valid and can be restored. Also restructure the code to save the ctx_loss_count in save_context(), which makes more sense than the previous method of storing new ctx_loss_count in dispc_need_ctx_restore. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-06-22OMAP: DSS2: Remove ctx loss count from dss.cTomi Valkeinen
dss.c only saves 1 register (3 in OMAP3) so the extra overhead from need_ctx_restore & co. is probably bigger than the time spent saving and restoring those few registers every time. So remove the code from dss.c and restore context every time dss has been off. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-06-22OMAP: DSS2: DISPC: remove finegrained clk enables/disablesTomi Valkeinen
dispc.c enables and disables clocks in almost every function to make sure the clocks are enabled when the function is called. This is rather unoptimal way to handle the problem. With pm_runtime other components have to call dispc_runtime_get() to enable dispc clocks before calling any other dispc functions. Thus the finegrained clk enables/disables can be removed. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-06-22OMAP: DSS2: Use PM runtime & HWMOD supportTomi Valkeinen
Use PM runtime and HWMOD support to handle enabling and disabling of DSS modules. Each DSS module will have get and put functions which can be used to enable and disable that module. The functions use pm_runtime and hwmod opt-clocks to enable the hardware. Acked-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-06-22OMAP: DSS2: Remove CONFIG_OMAP2_DSS_SLEEP_BEFORE_RESETTomi Valkeinen
CONFIG_OMAP2_DSS_SLEEP_BEFORE_RESET is used to avoid an unclear bug at DSS reset time. The pm runtime will handle reset in the future, and this code has to be removed. Hopefully we won't see this error anymore. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-06-22OMAP: DSS2: Remove core_dump_clocksTomi Valkeinen
Currently dss.c does all the low level clock handling in the DSS, and thus it contains pointers to all the clocks. This allows dss.c to dump the clock information for all the clocks. With pm_runtime this is no longer the case, as each submodule will handle its clocks independently. Thus remove the core_dump_clocks function as it cannot be used with pm_runtime. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-06-22OMAP: DSS2: Add new FEAT definitions for features missing from OMAP2Tomi Valkeinen
OMAP2 doesn't have CPR, PRELOAD nor FIR_COEF_V registers. Add new feature definitions for those, and check the feature before accessing those registers. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-06-22OMAP: DSS2: Add FEAT_VENC_REQUIRES_TV_DAC_CLKTomi Valkeinen
OMAP3430 requires an 96MHz clock to VENC's DAC, but no other OMAP needs it. Add a new feature, FEAT_VENC_REQUIRES_TV_DAC_CLK, which tells if the clock is needed on this platform, and use that feature in venc.c to decide if the clock needs enabling. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-06-22OMAP: DSS2: DPI: remove unneeded SYSCK enable/disableTomi Valkeinen
DSI PLL requires sys_clk to function, and DPI enables sys_clk when it wants to use DSI PLL. However, DSI PLL code already handles enabling sys_clk, so DPI's sys_clk code is extra. Remove the unneeded sys_clk handling from dpi.c. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-06-22OMAP: DSS2: rewrite use of context_loss_countTomi Valkeinen
The function to get device's context loss count has changed from omap_pm_get_last_off_on_transaction_id() to omap_pm_get_dev_context_loss_count() Change name of the function pointer in omapdss.h accordingly, and use the term "context loss count" instead of "context id" in the code. Restructure the context loss count functions to handle errors properly, and ensure that context is always considered lost if an error happens. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-06-22OMAP: DSS2: Remove clk optimization at dss initTomi Valkeinen
DSS enables core clocks for the duration of initialization to avoid unnecessary context saves and restores. With PM runtime the clocks cannot be handled in this way, outside the dss module drivers. Thus we need to remove the optimization. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-06-22OMAP: DSS2: Init dispc first before other componentsTomi Valkeinen
The initialization order of the DSS modules is important when pm_runtime support is implemented. Currently RFBI is initialized before DISPC, which will cause problems with pm_runtime as RFBI uses DISPC. Change the init order so that DISPC is before RFBI. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-06-22OMAP: DSS2: Clean up probe for DSS & DSITomi Valkeinen
Both dss.c and dsi.c had a probe function, which was almost a dummy one, calling dss_init() and dsi_init(). Remove the init functions by moving the initialization code into probe functions. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-06-22OMAP: DSS2: Handle dpll4_m4_ck in dss_get/put_clocksTomi Valkeinen
Get and put for dpll4_m4_ck was handled in dss_init/dss_exit. Move the code to dss_get/put_clocks(), which is a better place to handle it. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-06-22OMAP: DSS2: Reset LANEx_ULPS_SIG2 bits after useTomi Valkeinen
LANEx_ULPS_SIG2 bits are left on after entering ULPS. This doesn't cause any problems currently, as DSI HW is reset when it is enabled. However, if the reset is not done, operation fails if the bits are still set. So reset the bits after entering ULPS to ensure operation even without HW reset. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-06-22OMAP: DSS2: Taal: Make driver more fault tolerantTomi Valkeinen
If ULPS exit fails, and the following reset fails also, Taal driver was left in state where it thinks DSI is enabled while it really isn't, leading to crash. This patch checks the return value of taal_panel_reset, and if that fails, ulps_enabled is left true, causing the driver to retry ulps exit later. Also the return value of taal_wake_up is checked at taal_disable, and if wake up fails, we'll skip the power_off. This could leave the panel into a not-quite-valid state, but there's nothing we can do about it in that situation. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-06-16OMAP: DSS2: remove update_mode from omapdssTomi Valkeinen
Remove the whole update_mode stuff from omapdss driver. If automatic update for manual update displays is needed, it's better implemented in higher layers. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-06-16OMAP: DSS2: OMAPFB: Implement auto-update modeTomi Valkeinen
Implement auto-update mode for manual-update displays. omapfb driver uses a delayed work to update the display with a constant rate. The update mode can be changed via OMAPFB_SET_UPDATE_MODE ioctl, which previously called omapdss but is now handled inside omapfb, and a new sysfs file, "update_mode". The update interval is by default 20 times per second, but can be changed via "auto_update_freq" module parameter. There is also a new module parameter "auto_update", which will make omapfb start manual update displays in auto-update mode. This auto-update mode can be used for testing if the userspace does not support manual update displays properly. However, it is a very inefficient solution, and should be considered more as a hack for testing than something that could be used as a long term solution. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-06-16OMAP: DSS2: OMAPFB: Add struct to store per-display dataTomi Valkeinen
Create a new struct omapfb_display_data to contain omapfb's private per-display data. Move the bpp override there. This struct will be used to hold auto/manual update state of a display in the following patches. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-06-14OMAP: DSS: Add picodlp panel driverMayuresh Janorkar
picodlp panel driver is required for driving DLP dpp2600. It consists of a dss driver and an i2c_client. i2c_client is required for sending commands to dpp (DLP Pico Projector). Based on original design from Mythri P K <mythripk@ti.com> The power-up sequence consists of: Setting PWRGOOD to a logic low state. Once power is stable and thus the DPP2600 is stable, then PWRGOOD should be deactivated (Set to a logic high). The DPP2600 will then perform a power-up initialization routine that will first configure and lock its PLL followed by loading self configuration data from external flash. DPP2600 would be activated and the EMU_DONE signal will be driven high. After this once internal initialization routine, which will take approximately 510ms, i2c commands can be sent. To know more please visit: http://www.omappedia.org/wiki/PicoDLP_projector_guide Signed-off-by: Mayuresh Janorkar <mayur@ti.com> Signed-off-by: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-06-14OMAP: DSS: Add a picodlp header fileMythri P K
picodlp is a projector connected supported by OMAP. DLP used in OMAP4 is dpp2600 (DLP Pico Projector) The DLP requires commands to be sent over i2c for configurations, Commands are defined together in this header file To know more about dpp2600 commands please visit: https://focus.ti.com/myti/docs/extranet.tsp?sectionId=403 Signed-off-by: Mythri P K <mythripk@ti.com> Signed-off-by: Mayuresh Janorkar <mayur@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-06-14OMAP: DSS2: DSI: Change dummy macros to inline functionsTomi Valkeinen
Using empty macros for performance measurement functions when DSS DEBUG is not enabled causes an unused variable warning. Change the empty macros to empty inline functions to remove the warning. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-06-14OMAP: DSS2: remove extra includes from include/video/omapdss.hTomi Valkeinen
omapdss.h included platform_device.h and atomic.h, neither of which is needed by omapdss.h. Remove those includes from omapdss.h, and fix the affected .c files which did not include platform_device.h even though they should. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-23OMAP: DSS2: Add support for NV12 formatAmber Jain
Add the support for NV12 color format. Configure base address for UV component of NV12 color format. Change the way chroma scaling is handled for YUV formats on OMAP4 by enabling chroma-resampling for video pipeline and hence using FIR2 register set for scaling UV. Changes to _dispc_set_scaling(), because of the reason above, are: - call _dispc_set_scaling_common() to handle scaling for all color formats except for OMAP4 where it only handles scaling for RGB or Y-component - call _dispc_set_scaling_uv() for special handling required for UV component on OMAP4. - dispc_set_scaling_uv() also resets chroma-resampling bit for RGB color modes. Contains chroma scaling (_dispc_set_scaling_uv) design and implemented by Lajos Molnar <molnar@ti.com> Signed-off-by: Amber Jain <amber@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-23OMAP: DSS2: Add new registers for NV12 supportAmber Jain
Add new registers specific to UV color component that are introduced in OMAP4. Add simple helper functions to configure the newly added registers. These new registers are mainly: - UV base address registers used specifically for NV12 color-format - FIR registers used for UV-color-component scaling on OMAP4 - Accumulator registers used for UV-color-component scaling Add these new registers to save/restore and DUMPREG functions. Also add two new features for OMAP4: - FEAT_HANDLE_UV_SEPARATE - this is used on OMAP4 as UV color-component requires separate handling. - FEAT_ATTR2 - this is used on OMAP4 to configure new ATTRIBUTES2 register. Signed-off-by: Amber Jain <amber@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-23OMAP: DSS2: Use for loop where ever possible in SR(), RR()Amber Jain
Use for loop instead of individual entries for OVL_FIR_COEF_H, OVL_FIR_COEF_HV, OVL_FIR_COEF_V and OVL_CONV_COEF in SR() and RR(). Signed-off-by: Amber Jain <amber@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-23OMAP: DSS2: Ensure non-zero FIR values are configuredAmber Jain
FIR values can never be zero as per TRM, and the current code writes zero when scaling is not used. It was not causing any problem as scaling was disabled when zero was written. Its still safer to not write zero to it in any case. Now we configure correct FIR values even when scaling is not used (i.e. set FIR to 1024 when scaling is not used), but the scaling enable bits are still kept off if the scaling is not needed. Signed-off-by: Amber Jain <amber@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-23OMAP: DSS2: Add new color formats for OMAP4Amber Jain
Add new color formats supported by OMAP4: NV12, RGBA16, RGBX16, ARGB16_1555, XRGB16_1555. NV12 color format is defined here, its support in DSS will be added separately. Signed-off-by: Amber Jain <amber@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-19OMAP4: DSS2: HDMI: Implement ASoC Codec driver for HDMI audioRicardo Neri
Implement an ASoC Codec Driver to handle audio configuration. The implementation offers an interface for audio configuration and control to be exposed to ALSA while hidding the HDMI details. The ASoC driver supports the Basic Audio configuration as described in CEA-861-D: 2-channel linear PCM with 32, 44.1 and 48kHz sample rates and 16 bits/sample. It additionally supports 24 bit/sample in 32-bit words. Signed-off-by: Ricardo Neri <ricardo.neri@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-19OMAP4: DSS2: HDMI: Add functionality for audio configurationRicardo Neri
Add functionality for relevant audio configuration. Functions to configure the audio FIFO and DMA as well as functions for the audio core and Audio Info frame are included. This functionality is to be used by the ASoC HDMI audio codec. Signed-off-by: Ricardo Neri <ricardo.neri@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-19OMAP4: DSS2: HDMI: Add enums and structures for audioRicardo Neri
Add enurations and structures for audio configuration. This includes enumerations for the Audio InfoFrame, I2S, audio FIFO and audio core. Signed-off-by: Ricardo Neri <ricardo.neri@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-19OMAP4: DSS2: HDMI: Add DSS feature for CTS calculationRicardo Neri
CTS and N parameters are used to regenerate the audio clock from the TMDS clock at the HDMI sink. In OMAP4430 ES1.0 version the calculation of the CTS parameter is done by the HDMI IP (hardware mode) while in others it must be done by the HDMI driver (software mode). A DSS feature is used to indicate the HDMI driver which mode is used. Signed-off-by: Ricardo Neri <ricardo.neri@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-19OMAP4: DSS2: Create a DSS features structure for OMAP4430 ES1.0Ricardo Neri
Create a separate DSS features structure for OMAP4430 ES1.0. This structure is used to expose features only present in such silicon version. Specifically, this is required to handle how the HDMI IP calculates the CTS parameter for audio clock regeneration packets. OMAP4430 ES1.0 is the only one that supports computation of the CTS parameter by the HDMI IP (hardware mode). The rest of the revisions require the HDMI driver to perform the computation. Signed-off-by: Ricardo Neri <ricardo.neri@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-16OMAP: DSS2: DSI: Get line buffer size from DSI_GNQ registerArchit Taneja
The line buffer sizes vary across DSI modules, create a function dsi_get_line_buf_size() using DSI_GNQ register to get the size of line buffer used for the DISPC video port data. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-16OMAP: DSS2: DSI: Get number of DSI data lanes using DSI_GNQ registerArchit Taneja
On OMAP3, the DSI module has 2 data lanes. On OMAP4, DSI1 has 4 data lanes and DSI2 has 2 data lanes. Introduce function dsi_get_num_data_lanes() which returns the number of data lanes on the dsi interface, introduce function dsi_get_num_data_lanes_dssdev() which returns the number of data lanes used by the omap_dss_device connected to the lanes. Use the DSI_GNQ register on OMAP4 to get the number of data lanes, modify dsi.c to use the number of lanes and the extra data lanes on DSI1. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-16OMAP: DSS2: DSI: Use system workqueue for delayed work instead of a private ↵Archit Taneja
workqueue In the previous DSI driver design, a private workqueue was needed to prevent a deadlock as explained in the commit : 0f16aa0ae6b84d7ae72fbe8999e6a94cb78edd4e . In the current design, the workqueue is only used for queueing delayed work in the case where we don't get a FRAMEDONE interrupt for 250 milliseconds. It is safe to remove the private workqueue amd use the system workqueue instead to schedule the delayed work with the new design where the deadlock can't occur. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-16OMAP: DSS2: DSI: Remove DISPC pixel clock related info in dsi_dump_clocks()Archit Taneja
dsi_dump_clocks() prints lck and pck rates for the DISPC channel which it is connected to. Remove this since it is already printed by dispc_dump_clocks() in debugfs. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-12OMAP: DSS2: OMAPFB: Reduce stack usageTomi Valkeinen
omapfb_mode_to_timings() had struct fb_info, struct fb_var and struct fb_ops allocated from stack. This caused the stack usage grow quite high. Use kzalloc to allocate the structs instead. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-12OMAP: DSS2: OMAPFB: remove dead codeTomi Valkeinen
Remove old unused code lying inside #if 0. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-12OMAP: DSS2: RFBI: cleanupTomi Valkeinen
The RFBI driver is quite messy. Remove dead and unneeded code and add statics to functions. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-12OMAP: DSS2: RFBI: add omap_rfbi_configureTomi Valkeinen
Add omap_rfbi_configure() which the panel driver can use to reconfigure the data element size and the number of data lines in the RFBI bus. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-12OMAP: DSS2: RFBI: clock enable/disable changesTomi Valkeinen
RFBI enables and disables clocks inside almost every function to get a finegrained control to the clocks. However, the current understanding is that this is not necessary power-management-wise. Change the clocking scheme so that RFBI clocks are enabled when the omapdss_rfbi_display_enable is called, and disabled when omapdss_rfbi_display_disable is called. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-12OMAP: DSS2: RFBI: add rfbi_bus_lockTomi Valkeinen
Add similar bus lock to RFBI as is in DSI. The panel driver can use the bus lock to mark that the RFBI bus is currently in use. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-12OMAP: DSS2: Add missing dummy functionsTomi Valkeinen
dpi.c does not compile if DSI is not compiled in. Add the missing dummy functions so that dpi.c compiles. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-12OMAP: DSS2: Taal: Use device name in backlight_device_registerArchit Taneja
Panel Taal driver uses the string "taal" to register for a backlight device. This causes backlight_device_register() to fail when a second taal panel is added. Use dev_name(&dssdev->dev) as a parameter instead of the string. Note: This will break backlight related sysfs commands. Use the name as generated by the DSS2 driver, in the form "displayi", which represents the ith registered display device. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-12OMAP4: DSS2: DSI: Changes for DSI2 on OMAP4Archit Taneja
Introduce DSI2 PLL clock sources needed by LCD2 channel and DSI2 Protocol engine and DISPC Functional clock. Do the following: - Modify dss_get_dsi_clk_source() and dss_select_dsi_clk_source() to take the dsi module number as an argument. - Create debugfs files for dsi2, split the corresponding debugfs functions. - Allow DPI to use these new clock sources. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-12OMAP: DSS2: DSI: Pass pointer to struct to packet_sent_handler isrsArchit Taneja
dsi_packet_sent_handler_vp() and dsi_packet_sent_handler_l4() currently receive the completion parameter as their argument. This is not sufficient information to differentiate between DSI1 and DSI2 platform devices. Pass the struct "dsi_packet_sent_handler_data" to the packet_sent_handler isrs, these contain the platform_device pointer of the DSI device and the pointer to the completion struct. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-12OMAP: DSS2: DSI: Use platform_device pointer to get dsi dataArchit Taneja
The dsi related data structure currently creates one global instance of itself which is accessed by dsi functions. Remove this global structure instance and declare the struct as dsi_data. Modify dsi_init() to allocate a "dsi_data" structure for each platform device instance. Link this data with the device's platform_device pointer. Create the function dsi_get_dsidrv_data() which takes the pdev and return a pointer to the device's dsi_data. Make dsi_get_dsidev_id() return only 0 for now, this will be removed once the name of the DSI platform device is changed to the device instance form, like "omapdss_dsi.0" and "omapdss_dsi.1" etc. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-12-05 12:16:03 +0000