lkml.org 
[lkml]   [2022]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 08/13] phy: qcom-qmp-pcie: drop power-down delay config
On Tue, Oct 11, 2022 at 04:46:53PM +0300, Dmitry Baryshkov wrote:
> On 11/10/2022 16:14, Johan Hovold wrote:
> > The power-down delay was included in the first version of the QMP driver
> > as an optional delay after powering on the PHY (using
> > POWER_DOWN_CONTROL) and just before starting it. Later changes modified
> > this sequence by powering on before initialising the PHY, but the
> > optional delay stayed where it was (i.e. before starting the PHY).
> >
> > The vendor driver does not use a delay before starting the PHY and this
> > is likely not needed on any platform unless there is a corresponding
> > delay in the vendor kernel init sequence tables (i.e. in devicetree).
> >
> > Let's keep the delay for now, but drop the redundant delay period
> > configuration while increasing the unnecessarily low timer slack
> > somewhat.
>
> Actually, the vendor driver does this 995..1005 sleep. But contrary to
> our driver it does that after programming whole PHY init sequence, which
> includes SW_RESET / START_CTL, but before programming the pipe clocks.

Right, it does it after starting the PHY which means that you don't have
to poll for as long for the PHY status.

It's a different delay entirely.

> I think we can either drop this delay completely, or move it before
> read_poll_timeout().

It definitely shouldn't be used for any new platforms, but I opted for
the conservative route of keeping it in case some of the older platforms
actually do need it.

My bet is that this is all copy-paste cruft that could be removed, but
I'd rather do that as a separate follow-on change. Perhaps after testing
some more SoC after removing the delay.

SC8280XP certainly doesn't need it.

Johan

\
 
 \ /
  Last update: 2022-10-11 15:54    [W:0.076 / U:0.664 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site