Hi Dave, On Thu, Mar 30, 2023 at 3:31 PM Dave Stevenson <dave.stevenson@xxxxxxxxxxxxxxx> wrote: > > 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. This seems not fixed in dw-mipi-dsi and it often still requires the forth and back switch of HS mode even if pre_enable_prev_first. Thanks, Jagan.
