In order to switch HS mode properly by DSI host, the DSI sink has to send the MIPI-DCS commands first before the DSI host switches to HS mode. This behavior requires a bridge init alter in @enable and @disable function calls with the help of @enable_next_first. Document the affected bridge init order with a proper explanation. Signed-off-by: Jagan Teki <jagan@xxxxxxxxxxxxxxxxxxxx> --- Changes for v7: - new patch drivers/gpu/drm/drm_bridge.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c index cdc2669b3512..3c6c9937537a 100644 --- a/drivers/gpu/drm/drm_bridge.c +++ b/drivers/gpu/drm/drm_bridge.c @@ -190,6 +190,21 @@ * Ultra Low Power State (ULPS) is not explicitly supported by DRM. If * implemented, it therefore needs to be handled entirely within the DSI Host * driver. + * + * DSI sink devices typically send the MIPI-DCS commands to the DSI host via + * general MIPI_DSI_DCS read and write API. The classical DSI sequence + * mentioned that the DSI host receives MIPI-DCS commands from the DSI sink + * first in order to switch HS mode properly. Once the DSI host switches to + * HS mode any MIPI-DCS commands from the DSI sink are unfunctional. + * + * DSI sink uses the @enable function to send the MIPI-DCS commands. In a + * typical DSI host, sink pipeline the @enable call chain start with the + * DSI host, and then the DSI sink which is the "wrong" order as DSI host + * @enable is called and switched to HS mode before DSI sink @enable. If + * the DSI host enables with the @enable_next_first flag then the @enable + * for the DSI sink will be called first before the @enable of the DSI host. + * This alter bridge init order makes sure that the MIPI-DCS commands send + * first and then switch to the HS mode properly by the DSI host. */ static DEFINE_MUTEX(bridge_lock); -- 2.25.1
