Re: ti-sn65dsi86 linux driver using dsi clock source for pll

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,


On Fri, Sep 29, 2023 at 2:50 PM Laurent Pinchart
<laurent.pinchart@xxxxxxxxxxxxxxxx> 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




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux