[PATCH] drm/bridge: ti-sn65dsi83: Check link status register after enabling the bridge

[Dave Stevenson]

On Wed, 8 Sept 2021 at 16:26, Marek Vasut <marex at denx.de> wrote:
>
> On 9/8/21 1:11 PM, Dave Stevenson wrote:
> > Hi Marek and Andrzej
>
> Hello Dave,
>
> skipping the protocol discussion, which I hope Andrej will pick up.
>
> [...]
>
> >>> Usually video transmission starts in crtc->enable (CRTC->Encoder), and
> >>> in encoder->enable (encoder->bridge), so in bridges->enable it would be
> >>> too late for LP11 state - transmission can be already in progress.
> >>>
> >>> It shows well that this order of calls does not fit well to DSI, and
> >>> probably many other protocols.
> >>>
> >>> Maybe moving most of the bridge->enable code to bridge->pre_enable would
> >>> help, but I am not sur if it will not pose another issues.
> >>
> >> Yep, that won't work e.g. with the exynos DSIM, because
> >> exynos_dsi_set_display_mode() sets the data lanes to LP11.
> >
> > Isn't the bigger question for SN65DSI8[3|4|5] whether the clock lane
> > is running or not in pre_enable?
>
> I think the bigger question really is -- how do we cater for all the
> different bridges with different init-time requirements.
>
> >>> This is quick analysis, so please fix me if I am wrong.
> >>
> >> I pretty much agree that the current state of things does not fit with
> >> DSI too well.
> >
> > That was why I was questioning how DSI was meant to be implemented in
> > https://lore.kernel.org/dri-devel/CAPY8ntBUKRkSam59Y+72dW_6XOeKVswPWffzPj3uvgE6pV4ZGQ@mail.gmail.com/
> >
> > The need to have the DSI host in a defined idle state (often LP-11,
> > but varying whether the clock lane is in HS) before powering up the
> > panel/bridge is incredibly common, but currently undefined in DRM.
> >
> > Taking the SN65DSI83 as an example, the datasheet [1] section 7.4.2
> > states that the clock lane must be in HS mode, and data lanes in LP-11
> > when coming out of reset. That means that we can't be "enable" as that
> > will have the data lanes in HS mode and sending video, and as we can't
> > be in "pre_enable" as the DSI PHY will be powered down and so we won't
> > have the clock lanes in HS mode.
> >
> > I've hit a similar one with the Toshiba TC358762 where it seems to get
> > upset if it is receiving video data when it gets configured.
> > panel-raspberrypi-touchscreen[2] which drives that chip is
> > intermittent when using panel enable, whereas panel prepare is
> > significantly more reliable but relies on the DSI host being
> > initialised to LP-11 by breaking the chain.
>
> Right
>
> To make it worse, not initing the DSI bridge exactly per spec leads to
> intermittent failures, not consistently occuring ones.

Yes, I suspect it's been just down to timing as to whether the display
side starts producing video data before or after all the configuration
has been sent, and I get random LP commands timing out. (We're only
dropping to LP in vertical blanking, so there isn't a huge amount of
time).

> >    Dave
> >
> > [1] https://www.ti.com/lit/ds/symlink/sn65dsi83.pdf
> > [2] https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
>
> Unrelated to this discussion -- there is a tc358762 driver, driver for
> that attiny88 regulator, and driver for the touchscreen chip, on that
> rpi 7" display, in upstream. You can use those to replace the composite
> panel driver (it works at least against stm32mp1 DSI host with the rpi
> 7" panel). Sadly there is little documentation for that attiny88
> protocol or firmware, that's what I don't like about that panel.

Thank you, I know they exist, and I'm looking at exactly that problem
at the moment!

panel-raspberrypi-touchscreen doesn't expose any form of regulator
control, so trying to hook edt-ft54x6 on for the touchscreen sees it
getting the power yanked from under it. I'm trying to switch to those
drivers so that the two play nicely.

The Atmel is a bit nasty in trying to initialise the bridge, panel,
and touch all at the same time. The edt-ft54x6 driver generally probes
first and powers everything up when the DSI host isn't initialised.
This seems to upset the TC358762 and it then won't initialise.
It is possible to poke most things manually through the PORTA, PORTB
and PORTC commands, but I'm currently failing to create a reliable
mechanism :-( I have the advantage that I have the source code for the
Atmel (it's not nice)

  Dave