ti-sn65dsi86 linux driver using dsi clock source for pll

[Douglas Cooper]

Hi Doug

That’s really good feedback. Thanks so much for taking the time to outline that. I’ll keep investigating and dig into those areas you mentioned.

I should have mentioned I’m also using the chip in conjunction with a full size dp connector which appears to be supported. Also, besides the pll not locking I’m seeing an issue with the chip reporting there is no display connected when it reads the SN_HPD_DISABLE_REG in the ti_sn_bridge_detect function. This seems bizarre considering it reports accurately when I remove the module and i2cget the value. I was thinking this could be a false negative if the driver is actively trying to configure it and it’s failing.

Doug C.
On Sep 29, 2023 at 7:25 PM -0400, Doug Anderson <dianders at chromium.org>, wrote:
> Hi,
>
>
> On Fri, Sep 29, 2023 at 2:50 PM Laurent Pinchart
> <laurent.pinchart at ideasonboard.com> wrote:
> >
> > Hi Doug,
> >
> > CC'ing the dri-devel mailing list and Douglas Anderson.
> >
> > On Fri, Sep 29, 2023 at 03:36:52PM -0400, Douglas Cooper wrote:
> > > Hello,
> > >
> > > I've been trying to get the ti-sn65dsi86 to work with the dsi bus as the clk
> > > source (refclk grounded) and have concluded that the pll is not getting locked.
> > > Assuming the hardware is sound, have you ever seen this topology evaluated
> > > before? I'm questioning if that was a use case considered in the driver
> > > development. I will continue to actively investigate this.
> >
> > I don't think I've tested this mode, sorry. Maybe other people on the
> > list have some experience with this.
>
> I wouldn't suggest using this mode unless you have no choice.
>
> From my recollection we tried to use this mode on the very first
> prototype board of sdm845-cheza. It turned out to be _very_ limiting
> and it couldn't properly meet the timing requirements of the panel we
> were using. I think someone hacked things up temporarily by
> underdriving the panel at a much lower refresh rate and we eventually
> got it working, but we quickly abandoned trying to use ti-sn65dsi86 in
> this mode and threw away all of those old prototype boards.
>
> Since then, I've _tried_ to keep the code in ti-sn65dsi86 supporting
> this mode alive, but I'm not super confident in it.
>
> One thing that sticks out in particular in my mind is a bit of code in
> ti_sn65dsi86_resume(). You can see there that we don't call
> ti_sn65dsi86_enable_comms() if there's no reference clock. I believe
> that I added this code more out of guessing than anything else, since
> I don't recall this being well documented in the manual and, when the
> code was added, the early prototypes of cheza were long, long gone. I
> believe (?) I guessed this by seeing that I couldn't do things like
> AUX channel transfers without configuring the PLL and the PLL was
> based on the reference clock. Ah, here ya go. I documented my thought
> process in commit b137406d9679 ("drm/bridge: ti-sn65dsi86: If refclk,
> DP AUX can happen w/out pre-enable"). Though looking at it now, it
> seems odd that the code waiting for the PLL to lock doesn't happen
> until ti_sn_link_training(). Hmmm...
>
> If you have tested and see that things work differently than I
> guessed, feel free to send up a patch!
>
> One thing to note is that if, indeed, you need a reference clock
> before you can do AUX transactions then it's going to be really hard
> to make this work together with the generic "edp-panel". Specifically
> you'd need to turn on the MIPI source clock _before_ you can read the
> EDID of the panel, but without the EDID you won't really know what
> MIPI clock you should use. :-/
>
> -Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20230930/fd661d05/attachment-0001.htm>