On Mon, 27 Nov 2023 at 18:07, Michael Walle <mwalle@xxxxxxxxxx> wrote: > > Hi, > > > 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. 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
