On Tue, Oct 11, 2022 at 05:04:04PM +0300, Dmitry Baryshkov wrote: > On 11/10/2022 16:53, Johan Hovold wrote: > > 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. > > No-no-no. The 995-1005 delay was added guess for which SoC? For ipq8074, > where the config tables contain the ugly CFG_L writes for SW_RESET / > START_CTRL. So, it is the same delay, but added by somebody who didn't > care enough. The original 10-11 delay is a completely different story, > you are correct here. Yeah, I noticed that ipq8074 was the first to abuse the prwdn_delay and possibly because of it starting the PHY already in its PCS table (which it never should have). I'm talking about the intent of pwrdn_delay which was to add a delay after powering-on the phy and before starting it. The vendor driver has a 1 ms delay after starting the PHY and before it starts polling as the PHY on newer SoC tend to take > 1 ms before they are ready. So, I still claim that that delay in the vendor driver is a different one entirely. > Thus, I'd say, the PCIe delay should be moved after the registers > programming. No, not necessarily. Again, that's an optimisation in the vendor driver to avoid polling so many times. Since I can say for sure that there are no PHY that start in less than 1 ms, I wouldn't add it unconditionally. Either way, separate change. > >> 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. > > I think in our case this delay just falls into status polling. We'd > probably need it, if we'd add the noretain handling. I'm not sure I understand what you're referring to here ("noretain handling")? Johan