[prev in list] [next in list] [prev in thread] [next in thread]
List: dri-devel
Subject: Re: ti-sn65dsi86 linux driver using dsi clock source for pll
From: Douglas Cooper <douglas.cooper1 () gmail ! com>
Date: 2023-09-30 11:41:15
Message-ID: 823b5c4e-6b26-4818-be71-72d36681c70f () Spark
[Download RAW message or body]
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 #3 (text/html)]
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
</head>
<body>
<div name="messageBodySection">
<div dir="auto">Hi Doug<br />
<br />
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. <br /> <br />
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. <br /> <br />
Doug C.</div>
</div>
<div name="messageReplySection">On Sep 29, 2023 at 7:25 PM -0400, Doug Anderson \
<dianders@chromium.org>, wrote:<br /> <blockquote type="cite" \
style="border-left-color: grey; border-left-width: thin; border-left-style: solid; \
margin: 5px 5px;padding-left: 10px;">Hi,<br /> <br />
<br />
On Fri, Sep 29, 2023 at 2:50 PM Laurent Pinchart<br />
<laurent.pinchart@ideasonboard.com> wrote:<br />
<blockquote type="cite"><br />
Hi Doug,<br />
<br />
CC'ing the dri-devel mailing list and Douglas Anderson.<br />
<br />
On Fri, Sep 29, 2023 at 03:36:52PM -0400, Douglas Cooper wrote:<br />
<blockquote type="cite">Hello,<br />
<br />
I've been trying to get the ti-sn65dsi86 to work with the dsi bus as the clk<br />
source (refclk grounded) and have concluded that the pll is not getting locked.<br />
Assuming the hardware is sound, have you ever seen this topology evaluated<br />
before? I'm questioning if that was a use case considered in the driver<br />
development. I will continue to actively investigate this.<br /></blockquote>
<br />
I don't think I've tested this mode, sorry. Maybe other people on the<br />
list have some experience with this.<br /></blockquote>
<br />
I wouldn't suggest using this mode unless you have no choice.<br />
<br />
From my recollection we tried to use this mode on the very first<br />
prototype board of sdm845-cheza. It turned out to be _very_ limiting<br />
and it couldn't properly meet the timing requirements of the panel we<br />
were using. I think someone hacked things up temporarily by<br />
underdriving the panel at a much lower refresh rate and we eventually<br />
got it working, but we quickly abandoned trying to use ti-sn65dsi86 in<br />
this mode and threw away all of those old prototype boards.<br />
<br />
Since then, I've _tried_ to keep the code in ti-sn65dsi86 supporting<br />
this mode alive, but I'm not super confident in it.<br />
<br />
One thing that sticks out in particular in my mind is a bit of code in<br />
ti_sn65dsi86_resume(). You can see there that we don't call<br />
ti_sn65dsi86_enable_comms() if there's no reference clock. I believe<br />
that I added this code more out of guessing than anything else, since<br />
I don't recall this being well documented in the manual and, when the<br />
code was added, the early prototypes of cheza were long, long gone. I<br />
believe (?) I guessed this by seeing that I couldn't do things like<br />
AUX channel transfers without configuring the PLL and the PLL was<br />
based on the reference clock. Ah, here ya go. I documented my thought<br />
process in commit b137406d9679 ("drm/bridge: ti-sn65dsi86: If refclk,<br />
DP AUX can happen w/out pre-enable"). Though looking at it now, it<br />
seems odd that the code waiting for the PLL to lock doesn't happen<br />
until ti_sn_link_training(). Hmmm...<br />
<br />
If you have tested and see that things work differently than I<br />
guessed, feel free to send up a patch!<br />
<br />
One thing to note is that if, indeed, you need a reference clock<br />
before you can do AUX transactions then it's going to be really hard<br />
to make this work together with the generic "edp-panel". Specifically<br />
you'd need to turn on the MIPI source clock _before_ you can read the<br />
EDID of the panel, but without the EDID you won't really know what<br />
MIPI clock you should use. :-/<br />
<br />
-Doug<br /></blockquote>
</div>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic