>> >> > 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 -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 > > >
