On Tue, 28 Nov 2023 at 21:50, Michael Walle <michael@xxxxxxxx> wrote: > > >> >> > DSI device lifetime has three different stages: > >> >> > 1. before the DSI link being powered up and clocking, > >> >> > 2. when the DSI link is in LP state (for the purpose of this question, > >> >> > this is the time between the DSI link being powered up and the video > >> >> > stream start) > >> >> > 3. when the DSI link is in HS state (while streaming the video). > >> >> > >> >> It's not clear to me what (2) is. What is the state of the clock and > >> >> data lanes? > >> > > >> > Clk an Data0 should be in the LP mode, ready for LP Data Transfer. > >> > >> Then this is somehow missing > >> https://docs.kernel.org/gpu/drm-kms-helpers.html#mipi-dsi-bridge-operation > >> > >> A DSI host should keep the PHY powered down until the pre_enable > >> operation > >> is called. All lanes are in an undefined idle state up to this point, > >> and > >> it must not be assumed that it is LP-11. pre_enable should initialise > >> the > >> PHY, set the data lanes to LP-11, and the clock lane to either LP-11 > >> or HS > >> depending on the mode_flag MIPI_DSI_CLOCK_NON_CONTINUOUS. > >> > >> So I don't think these three states are sufficient, see below, that > >> there > >> should be at least four. > > > >Which one is #4? > > enabled clock lane (HS mode), data lanes in LP-11 What is the purpose of such a mode? > > -michael > > >> > >> > > >> > I don't think we support ULPS currently. > >> > > >> > > >> >> > >> >> I'm facing similar issues with the tc358775 bridge. This bridge needs > >> >> to release its reset while both clock and data lanes are in LP-11 > >> >> mode. > >> >> But then it needs to be configured (via I2C) while the clock lane is > >> >> in enabled (HS mode), but the data lanes are still in LP-11 mode. > >> >> > >> >> To me it looks like there is a fouth case then: > >> >> 1. unpowered > >> >> 2. DSI clock and data are in LP-11 > >> >> 3. DSI clock is in HS and data are in LP-11 > >> >> 4. DSI clock is in HS and data is in HS > >> >> > >> >> (And of course the bridge needs continuous clock mode). > >> >> > >> >> > Different DSI bridges have different requirements with respect to the > >> >> > code being executed at stages 1 and 2. For example several DSI-to-eDP > >> >> > bridges (ps8640, tc358767 require for the link to be quiet during > >> >> > reset time. > >> >> > The DSI-controlled bridges and DSI panels need to send some commands > >> >> > in stage 2, before starting up video > >> >> > > >> >> > In the DRM subsystem stage 3 naturally maps to the > >> >> > drm_bridge_funcs::enable, stage 1 also naturally maps to the > >> >> > drm_bridge_funcs::pre_enable. Stage 2 doesn't have its own place in > >> >> > the DRM call chain. > >> >> > Earlier we attempted to solve that using the pre_enable_prev_first, > >> >> > which remapped pre-enable callback execution order. However it has led > >> >> > us to the two issues. First, at the DSI host driver we do not know > >> >> > whether the panel / bridge were updated to use pre_enable_prev_first > >> >> > or not. Second, if the bridge has to perform steps during both stages > >> >> > 1 and 2, it can not do that. > >> >> > > >> >> > I'm trying to find a way to express the difference between stages 1 > >> >> > and 2 in the generic code, so that we do not to worry about particular > >> >> > DSI host and DSI bridge / panel peculiarities when implementing the > >> >> > DSI host and/or DSI panel driver. > >> >> > >> >> For now, I have a rather hacky ".dsi_lp11_notify" callback in > >> >> drm_bridge_funcs which is supposed to be called by the DSI host while > >> >> the > >> >> clock and data lanes are in LP-11 mode. But that is rather an RFC and > >> >> me > >> >> needing something to get the driver for this bridge working. Because > >> >> it's > >> >> badly broken. FWIW, you can find my work-in-progress patches at > >> >> https://github.com/mwalle/linux/tree/feature-tc358775-fixes > >> >> > >> >> -michael > >> >> > >> > > >> > > >> > -- > >> > With best wishes > >> > Dmitry > > > > > > > -- With best wishes Dmitry
