Hi Sergei,
On Wed, Nov 13, 2019 at 02:51:48PM +0300, Sergei Shtylyov wrote:
> Hello!
>
> On 11/06/2019 03:10 PM, Eugeniu Rosca wrote:
>
> Sorry for a late reply -- I'm on vacation.
No worries. Please, enjoy your vacation :)
> [...]
> >>>> This PHY is still mostly undocumented -- the only documented registers
> >>>> exist on R-Car V3H (R8A77980) SoC where this PHY stays in a powered-down
> >>>> state after a reset and thus we must power it up for PCIe to work...
> >>>
> >>> Indeed, this [1] PCIE PHY driver looks entirely V3H-focused and looking
> >>> at the "Table 54.5 PCIE Controller Phy Register Configuration" in Rcar3
> >>> HW User’s Manual Rev.2.00 Jul 2019, _all_ except one PCIE PHY register
> >>> (PHY_CLK_RST) exist on V3H and no other Rcar3 SoC.
> >>>
> >>> So, except PHY_CLK_RST, this driver appears to be doomed to R8A77980.
> >>> Ironically, PHY_CLK_RST is exactly the register we now need to manage
> >>> to implement "Internal Reference Clock Supply" (HW man Chapter 54.3.14).
> >>
> >> Do you have in mind a working approach to switch internal/external clocks?
> >> phy_set_mode()?
> >
> > Thanks to Andrew (CC), the approach is to implement a new binding
> > "use-internal-reference-clock" and, based on its setting in DT,
>
> So boolean prop... should be OK.
>
> > write the appropriate value (0) into the PHY_REF_USE_PAD bit of
> > PHY_CLK_RST register, just as described in Chapter "54.3.14 Internal
> > Reference Clock Supply" of R-Car3 HW manual. We don't employ the
> > generic phy_set_mode().
> >
> > If you are fine with this approach, then we will try to find some time
> > to push Andrew's patches to you in the following days.
>
> >>> Just to avoid any surprises on our side, do you see any issues in
> >>> extending the driver to the whole R-Car3 family, even if only for the
> >>> sake of controlling the non-V3H PHY_CLK_RST register?
> >>
> >> Depends on the previous question...
>
> Wait, I don't see why we should support all the family. The PCIe PHY
> registers don't exist on each member of the family, according to the
> manual. Please continue using the chip spoecific "compatible" prop.
Given the "phy-rcar-gen3-pcie.c" driver name, I would expect that
enriching its behavior with Gen3 non-V3H functionality is legitimate.
Hope to see your review comments when the series is submitted. TIA.
>
> >>> [1] 2ce7f2f425ef74 ("phy: Renesas R-Car gen3 PCIe PHY driver")
>
> MBR, Sergei
--
Best Regards,
Eugeniu
