- 15 Dec, 2020 40 commits
-
-
Christian König authored
We only completely delete the BO from the LRU on destruction. Signed-off-by:
Christian König <christian.koenig@amd.com> Acked-by:
Andrey Grodzovsky <andrey.grodzovsky@amd.com> Link: https://patchwork.freedesktop.org/patch/404618/
-
Christian König authored
Check the pin_count instead of the lru list is empty here. Signed-off-by:
-
Simon Ser authored
If a CRTC is missing a legacy primary plane pointer, a lot of things will be broken for user-space: fbdev stops working and the entire legacy uAPI stops working. Require all drivers to populate drm_crtc.primary to prevent these issues. Warn if it's NULL. Signed-off-by:
Simon Ser <contact@emersion.fr> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201211184634.74534-3-contact@emersion.fr
-
Simon Ser authored
If a primary or cursor plane is not compatible with a CRTC it's attached to via the legacy primary/cursor field, things will be broken for legacy user-space. v4: use drm_crtc_mask instead of BIT (Ville) Signed-off-by:
-
Simon Ser authored
The previous wording could be understood by user-space evelopers as "a primary/cursor plane is only compatible with a single CRTC" [1]. Reword the planes description to make it clear the DRM-internal drm_crtc.primary and drm_crtc.cursor planes are for legacy uAPI. [1]: https://github.com/swaywm/wlroots/pull/2333#discussion_r456788057Signed-off-by:
-
Zheng Yongjun authored
The parameter of kfree function is NULL, so kfree code is useless, delete it. Signed-off-by:
Zheng Yongjun <zhengyongjun3@huawei.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201214134628.4937-1-zhengyongjun3@huawei.com
-
Tomi Valkeinen authored
Panel drivers can send DSI commands in panel's prepare(), which happens before the bridge's enable() is called. The OMAP DSI driver currently only sets up the DSI interface at bridge's enable(), so prepare() cannot be used to send DSI commands. This patch fixes the issue by making it possible to enable the DSI interface any time a command is about to be sent. Disabling the interface is be done via delayed work. Clarifications for the delayed disable work and the panel doing DSI transactions: bridge_enable: If the disable callback is called just before bridge_enable takes the dsi_bus_lock, no problem, bridge_enable just enables the interface again. If the callback is ran just after bridge_enable's dsi_bus_unlock, no problem, dsi->video_enabled == true so the callback does nothing. bridge_disable: similar to bridge-enable, the callback won't do anything if video_enabled == true, and after bridge-disable has turned the video and the interface off, there's nothing to do for the callback. omap_dsi_host_detach: this is called when the panel does mipi_dsi_detach(), and we expect the panel to _not_ do any DSI transactions after (or during) mipi_dsi_detatch(), so there are no race conditions. Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201215104657.802264-85-tomi.valkeinen@ti.com
-
Tomi Valkeinen authored
We only need to set VC_CTRL:DCS_CMD_ENABLE for command mode panels when the HW has DSI_QUIRK_DCS_CMD_CONFIG_VC quirk. The old code did this right by accident, but now we set DCS_CMD_ENABLE for video mode panels too. Fix this by skipping the set for video mode. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Tomi Valkeinen authored
ULPS is a niche power-saving feature which only really affects command mode panels showing a static picture. I know the ULPS code used to work very long time ago, but I could not get it working with the current driver. As the ULPS code is not trivial and includes delayed work (so lots of chances for race issues), and just keeping DSI video and command mode panels working has been challenging enough even without ULPS, lets remove ULPS support. When the DSI driver works reliably for command and video mode displays, someone interested can work on ULPS and add it back if the power saving is substantial enough. Signed-off-by:
-
Tomi Valkeinen authored
The driver ignores MIPI_DSI_CLOCK_NON_CONTINUOUS, and always uses non-continuous clock. Fix this by using MIPI_DSI_CLOCK_NON_CONTINUOUS and at the same time, drop ddr_clk_always_on field which seems pretty useless. Signed-off-by:
-
Tomi Valkeinen authored
Clean up the code by separating video-mode enable/disable code into functions of their own. Signed-off-by:
-
Tomi Valkeinen authored
As we now have a fixed setup for VCs (VC0 for video stream, VC1 for commands), we can simplify the VC setup. Signed-off-by:
-
Tomi Valkeinen authored
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 authored
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 authored
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 authored
Clean up the code by inlining dsi_enable_video_outputs and dsi_disable_video_outputs functions. Signed-off-by:
-
Tomi Valkeinen authored
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 authored
Drop unneeded includes. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Reviewed-by:
-
Tomi Valkeinen authored
Add a panel database to the driver instead of reading propertes from DT data. This is similar to panel-simple, and I believe it's more future safe way to handle the panels. Signed-off-by:
-
Tomi Valkeinen authored
We have a useless 'if' in the dsicm_bl_update_status(), a left over from the conversion to DRM model. Drop the if. Signed-off-by:
-
Tomi Valkeinen authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
Set the column & page address once during setup, instead of relying the DSI host driver to set those. Signed-off-by:
-
Tomi Valkeinen authored
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 authored
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 authored
Add address-cells & size-cells to DSI nodes so that board files do not need to define them. Signed-off-by:
Tony Lindgren <tony@atomide.com> Reviewed-by:
-
Tomi Valkeinen authored
Simplify the code by moving code from _dsicm_enable_te() into dsicm_power_on(). Signed-off-by:
-
Tomi Valkeinen authored
Use the common MIPI_DCS_GET_ERROR_COUNT_ON_DSI define instead of driver's own. Signed-off-by:
-
Tomi Valkeinen authored
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 authored
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 authored
dssdev->owner is set, but never used. We can drop the field. Signed-off-by:
-
Tomi Valkeinen authored
The functions in display.c are not used, so drop the file. Signed-off-by:
-
