Hi Jagan On Thu, 30 Mar 2023 at 07:56, Jagan Teki <jagan@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, Mar 29, 2023 at 10:16 PM Maxime Ripard <maxime@xxxxxxxxxx> wrote: > > > > On Wed, Mar 29, 2023 at 05:28:28PM +0100, Dave Stevenson wrote: > > > On Wed, 29 Mar 2023 at 14:19, Jagan Teki <jagan@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > 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. > > > > > > That statement contradicts the spec. > > > The DSI spec section 8.11.1 Transmission Packet Sequences says that > > > during any BLLP (Blanking or Low Power) period the host can do any of: > > > - remain in LP-11 > > > - transmit one or more non-video packets from host to peripheral in escape mode > > > - transmit one or more non-video packets from host to peripheral in > > > using HS mode > > > - receive one or more packets from peripheral to host using escape mode > > > - transmit data on a different virtual channel. > > > > > > Indeed if the sink doesn't set MIPI_DSI_MODE_LPM / > > > MIPI_DSI_MSG_USE_LPM, then the expectation is that any data transfer > > > will be in HS mode. > > > > > > That makes me confused as to the need for this patch. > > > > Yeah, and it looks like that would break the expectation that, in > > enable, a bridge can expect its controller to be in HS mode. > > > > I think that was Jagan is trying to do is to work around an issue with > > the Allwinner DSI driver: > > https://elixir.bootlin.com/linux/v6.3-rc4/source/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c#L775 > > Correct and I can see it seems to be a classic DSI sequence observed > in dw-mipi-dsi as well - based on Neil's comments. > https://lore.kernel.org/all/9aa3d19d-4378-aaf3-6857-c40be5d252c7@xxxxxxxxxxxx/ Neil's comments are from 2021, and his response would appear to be with regard the PHY power up sequence issues that pre_enable_prev_first should solve. The DSI host pre_enable can now be called before the sink's pre_enable, therefore allowing the PHY to be configured in pre_enable. Hacking the PHY init into mode_set is therefore not required. I don't see any restriction in dw-mipi-dsi over when transfer can be called (as long as it is between pre_enable and post_disable), and it supports MIPI_DSI_MSG_USE_LPM for requesting the command be sent in either LP or HS mode. > In fact, I did follow and initialize the command-mode mode_set which > set low-speed DCS and switch back to video-mode @enable and switch to > HS but could see the same issue as the host cannot accept DCS as > before (I might implement improper sequence, but not sure due to lack > of documentation). But this sequence has issues with calling > post_disable twice even on dw-mipi-dsi. Calling up/down the bridge chain from within other bridge elements is going to have issues and shouldn't be necessary. The comment in dw-mipi-dsi post_disable[1] * TODO Only way found to call panel-bridge post_disable & * panel unprepare before the dsi "final" disable... * This needs to be fixed in the drm_bridge framework and the API * needs to be updated to manage our own call chains... It has now been fixed up with pre_enable_prev_first. I seem to recall seeing a patchset for one of the DSI hosts (other than vc4) that was moving the init from mode_set to pre_enable - I think it is probably [2] for msm. Cheers Dave [1] https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c#L862-L867 [2] https://github.com/torvalds/linux/commit/ec7981e6c614254937b37ce0af9eac09901c05c5 > May be Neill, can comment here? > > Thanks, > Jagan.
