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

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

[Laurent Pinchart]

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.

-- 
Regards,

Laurent Pinchart

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

[Doug Anderson]

Hi,


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

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

[Douglas Cooper]

[-- Attachment #1: Type: text/plain, Size: 3694 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4407 bytes --]

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

[Doug Anderson]

Hi,

On Sat, Sep 30, 2023 at 4:41 AM Douglas Cooper
<douglas.cooper1@gmail.com> wrote:
>
> 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.

Any chance that the disabling of HPD in ti_sn65dsi86_enable_comms() is
messing you up? Do you need to avoid doing that in the case of a full
sized DP?

I've never tried to use it with a full size DP connector, though I
think others have made it work. One thing to note is that when using
sn65dsi86 as a full sized DP the code currently disables the
"scrambler". If you still have control over the hardware, it seems
like it's supposed to be better to pull up the "TEST2" pin and then
add code to the driver to properly enable the right scrambler for DP.


-Doug