aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/omapdrm
AgeCommit message (Collapse)AuthorFilesLines
2020-12-15drm/omap: dsi: rename dsi_display_* functionsTomi Valkeinen1-18/+18
The function names have evolved to be very confusing, and bunch of them have "display" in them even if the function doesn't deal with display as such (e.g. dsi_display_enable which just enables the DSI interface). Rename them by dropping the "display". Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: display_disable cleanupTomi Valkeinen1-16/+3
We can drop dsi_display_disable() which just calls _dsi_display_disable(), and rename _dsi_display_disable() to dsi_display_disable(). The WARN_ON(!dsi_bus_is_locked(dsi)) in dsi_display_disable is extra and can be dropped, as _dsi_display_disable() has the same WARN_ON(). Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: display_enable cleanupTomi Valkeinen1-13/+3
We can drop dsi_display_enable(), which just calls _dsi_display_enable(), and rename _dsi_display_enable() to dsi_display_enable(). The WARN_ON(!dsi_bus_is_locked(dsi)) in dsi_display_enable is extra and can be dropped, as _dsi_display_enable() has the same WARN_ON(). Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: move enable/disable to bridge enable/disableTomi Valkeinen1-33/+22
Clean up the code by inlining dsi_enable_video_outputs and dsi_disable_video_outputs functions. Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: move structs & defines to dsi.hTomi Valkeinen3-447/+460
Move structs and defines to a private dsi.h header file to make dsi.c a bit easier to navigate. Also move the (now) private structs and defines from omapdss.h to dsi.h. Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: use separate VCs for cmd and videoTomi Valkeinen1-5/+7
For command mode panels we can use a single VC for sending command and video data, even if we have to change the data source for that VC when going from command to video or vice versa. However, with video mode panels we want to keep the pixel data VC enabled, and use another VC for command data, and the commands will get interleaved into the pixel data. This patch makes the driver use VC0 for commands and VC1 for video. Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: enable HS before sending the frameTomi Valkeinen1-0/+2
We currently use a single VC for sending commands and pixel data. The LP/HS mode for pixel data is correctly set to HS by accident, as we have set the VC to HS already earlier. However, if we use a different VC for video data, the VC is in LP mode. Fix this by always enabling HS mode before starting a frame update. Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: skip dsi_vc_enable_hs when already in correct modeTomi Valkeinen1-6/+4
Simplify and optimize dsi_vc_enable_hs() so that it can be called without checking the current HS/LP mode. Make dsi_vc_enable_hs() return if the VC is already in the correct mode. Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: untangle vc & channelTomi Valkeinen1-23/+22
DSI virtual channel and hardware VC blocks have gotten tangled as described in the previous commits. This has not caused any issues, as the value for both is 0, so it happens to work. To fix the issue, change the code to use the correct one of the two. Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: pass vc and channel to various functionsTomi Valkeinen1-26/+28
To start fixing the issues related to channels and vcs described in the previous commit, pass vc and/or channel to various functions which will need it do properly handle different DSI channels and VCs. No functional changes. Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: rename 'channel' to 'vc'Tomi Valkeinen1-110/+110
The "channel" usage in omap dsi driver is confusing. We have three different "channels": 1) DSI virtual channel ID. This is a number from 0 to 3, included in the packet payload. 2) VC. This is a register block in the DSI IP. There are four of those blocks. A VC is a DSI "pipeline", with defined fifo settings, data source (cpu or dispc), and some other settings. It has no relation to the 1). 3) dispc channel. It's the "pipeline" number dispc uses to send pixel data. The previous patch handled the third case. To start fixing 1) and 2), we first rename all uses of 'channel' to 'vc', as in most of the cases that is the correct thing to use. However, in some places 1) and 2) have gotten mixed up (i.e. the code uses msg->channel when it should use vc), which will be fixed in the following patch. Note that mixing 1) and 2) currently is "fine", as at the moment we only support DSI peripherals with DSI virtual channel 0, and we always use VC0 to send data. So both 1) and 2) are always 0. Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: cleanup dispc channel usageTomi Valkeinen1-8/+8
The "channel" usage in omap dsi driver is confusing. As the first step, change "channel" to "dispc_channel" when dealing with the dispc channel. Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: drop useless channel checksTomi Valkeinen1-11/+0
A DSI peripheral can have virtual channel ID of 0-3. This should be always the case, and there's no need in the driver to validate the channel. Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: simplify VC handlingTomi Valkeinen1-36/+13
The VC handling has gotten quite tangled up. As the first step to clean it up, lets define that we only support a single DSI peripheral (which was really already the case), and we always use VC0 (define VC_DEFAULT 0) register block to send data to the peripheral. We can thus have a single mipi_dsi_device pointer and remove the for-loops which made passes over all the four VCs (just the first one was ever used). Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: send nop instead of page & columnTomi Valkeinen1-29/+17
The OMAP DSI command mode panel driver used to send page & column address before each frame update, and this code was moved into the DSI host driver when converting it to the DRM bridge model. However, it's not really required to send the page & column address before each frame. It's also something that doesn't really belong to the DSI host driver, so we should drop the code. That said, frame updates break if we don't send _something_ between the frames. A NOP command does the trick. It is not clear if this behavior is as expected from a DSI command mode frame transfer, or is it a feature/issue with OMAP DSI driver, or a feature/issue in the command mode panel used. Most likely this is related to the following from the DSI spec: "To enable PHY synchronization the host processor should periodically end HS transmission and drive the Data Lanes to the LP state. This transition should take place at least once per frame." Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: set trans_mode according to client mode_flagsTomi Valkeinen1-0/+7
The DSI host driver currently ignores the video mode flags in client->mode_flags. Add the code to take the transfer mode from client's mode_flags. Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: pll: fix iteration loop checkTomi Valkeinen1-0/+6
If the PLL calc function is given bad parameters, n_start/m_start may be higher than n_stop/m_stop, which leads to the loops iterating through the whole u32 number space. Fix this by failing early on such cases. Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: remove dss_mgr_opsTomi Valkeinen6-87/+33
dss_mgr_ops was needed with the multi-module architecture, but is no longer needed. We can thus remove it and use direct calls. Signed-off-by: Tomi Valkeinen <[email protected]> Acked-by: Laurent Pinchart <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: remove dispc_opsTomi Valkeinen9-200/+144
dispc_ops was created to help with the multi-module architecture and giving us the possibility of multiple dispc implementations. Neither of these is valid anymore, and we can remove dispc_ops and use direct calls to dispc. Signed-off-by: Tomi Valkeinen <[email protected]> Acked-by: Laurent Pinchart <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: drop unused owner fieldTomi Valkeinen7-8/+0
dssdev->owner is set, but never used. We can drop the field. Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: remove unused display.cTomi Valkeinen3-63/+1
The functions in display.c are not used, so drop the file. Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: squash omapdrm sub-modules into oneTomi Valkeinen10-202/+155
At the moment we have three different modules: omapdss-base, omapdss, omapdrm. This setup is finally obsolete, as the last omapdrm specific panel has been converted to DRM panel. We can thus remove omapdss-base and omapdss, and just compile everything into omapdrm.ko. Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: simplify pin configSebastian Reichel2-39/+13
Simplify DSI pin config, which always originates from DT nowadays. With the code being fully contained in the DSI encoder, we can drop the public structure. Since the function is no longer exposed, it now directly takes the private DSI data pointer. This drops a pointless conversion and means the pins can be configured earlier. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: simplify DSI manual update codeSebastian Reichel3-23/+9
Move dsi_ops into the main structure, since all other ops are gone. Instead of checking the device type we can simply check if dsi_ops are set. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: drop dssdev display fieldSebastian Reichel2-7/+1
All displays are now using a drm_panel or a drm_bridge that models the connector instead of dssdev, so this field is always 0 and can be dropped. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: drop DSS ops_flagsSebastian Reichel2-10/+0
The omapdss device's ops_flags field is no longer used and can be dropped. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: drop unused DSS next pointerSebastian Reichel4-18/+2
Since all encoders and panels are using the bridge API now, we next pointer is no longer useful and can be dropped. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: simplify omap_display_idSebastian Reichel1-8/+1
We no longer need to check for the DSS API, since all encoders, panels and connectors have been converted to the bridge API. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: remove unused omap_connectorSebastian Reichel6-190/+6
Remove unused code. Connectors are now created via drm_bridge_connector_init() and no longer OMAP specific. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: remove legacy DSS device operationsSebastian Reichel5-193/+0
All DSS devices have been converted to bridge API, so the device operations are always NULL. This removes the device ops function pointers and all code using it. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: Register a drm_bridgeSebastian Reichel1-45/+89
In order to integrate with a chain of drm_bridge, the internal DSI output has to expose its operations through the drm_bridge API. Register a bridge at initialisation time to do so and remove the omap_dss_device operations that are now unused. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/panel: Move OMAP's DSI command mode panel driverSebastian Reichel5-651/+0
The panel driver is no longer using any OMAP specific APIs, so let's move it into the generic panel directory. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Cc: Thierry Reding <[email protected]> Cc: Sam Ravnborg <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Acked-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: remove global dss_device variableSebastian Reichel4-29/+9
We can simply provide the device to the omapdrm driver via pdata. omapdss_is_initialized() is no longer required (even before this patch), since omapdrm device is only registered after the pointer is initialized. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: panel-dsi-cm: fix remove()Sebastian Reichel1-3/+0
Do not try to reset the panel after DSI has been detached, since the DSI clocks may have been disabled at this point. The panel will be disabled and unprepared before being removed and a reset will be done when being probed again. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: panel-dsi-cm: support unbindingSebastian Reichel1-3/+2
Now, that the driver implements the common DRM panel API the unbind no longer needs to be suppressed. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Acked-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: panel-dsi-cm: use DEVICE_ATTR_ROSebastian Reichel1-4/+4
Use DEVICE_ATTR_RO helper instead of plain DEVICE_ATTR, which makes the code a bit shorter and easier to read. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: implement check timingsSebastian Reichel1-26/+44
Implement check timings, which will check if it's possible to configure the clocks for the provided mode using the same code as the set_config() hook. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: drop omapdss-boot-initSebastian Reichel3-234/+0
The table of compatible values needed to be prefixed with "omapdss," is empty, so all of this code is doing nothing now. Let's drop it. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: convert to drm_panelSebastian Reichel4-158/+182
This converts the DSI module to expect common drm_panel display drivers instead of dssdev based ones. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: drop custom panel capability supportSebastian Reichel4-19/+17
Due to previous changes the DSI encoder gets the capabilities via DSI client's mode_flags and no longer needs the omapdss specific caps. The core code now checks if the DSI encoder is actually configured into command mode instead of just checking the panel capabilities. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: Reverse direction of the DSS device enable/disable operationsSebastian Reichel2-57/+45
Complete the direction reversal of the DSS device enable/disable operations started by commit 19b4200d8f4b ("drm/omap: Reverse direction of the DSS device enable/disable operations"). This effectively drops the requirement of calling DSS specific code from the DSI panel driver moving it a bit further to a standard drm_panel driver. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: move panel refresh function to hostSebastian Reichel4-95/+88
This moves the panel refresh/update function from the panel driver into the DSI host driver to prepare for common drm_panel support. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: do ULPS in host driverSebastian Reichel3-279/+60
Move ULPS handling into the DSI host controller, so that we no longer need a custom API for the DSI client. Note that for now ULPS is always disabled. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Acked-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: untangle ulps ops from enable/disableSebastian Reichel3-20/+46
Create a custom function pointer for ULPS and use it instead of reusing disable/enable functions for ULPS mode switch. This allows us to use the common disable/enable functions pointers for DSI. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: do bus locking in host driverSebastian Reichel3-60/+28
This moves the bus locking into the host driver and unexports the custom API in preparation for drm_panel support. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: drop custom enable_te() APISebastian Reichel3-14/+25
Instead of using the custom enable_te() API, this automatically enables/disables TE core support when a matching packet is sent to the panel. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: move TE GPIO handling into coreSebastian Reichel2-109/+140
In preparation for removing custom DSS calls from the DSI panel driver, this moves support for external tearing event GPIOs into the DSI host driver. This way tearing events are always handled in the core resulting in simplification of the panel drivers. The TE GPIO acquisition follows works in the same way as the exynos DSI implementation. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: lp/hs switching support for transfer()Sebastian Reichel3-7/+10
Integrate low-power / high-speed bus switching into transfer function and drop the omapdrm specific enable_hs() callback. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: panel-dsi-cm: use bulk regulator APISebastian Reichel1-44/+21
Use bulk regulator API to simplify the code. This also switches from _optional variant to normal variant, which will provide a dummy regulator (i.e. if some always-enabled regulator is not described in DT). Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-12-15drm/omap: dsi: use pixel-format and mode from attachSebastian Reichel2-14/+19
In order to reduce the amount of custom functionality, this moves handling of pixel format and DSI mode from set_config() to dsi attach. Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.