Hello!
On 11/06/2019 03:10 PM, Eugeniu Rosca wrote:
Sorry for a late reply -- I'm on 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.
>>> [1] 2ce7f2f425ef74 ("phy: Renesas R-Car gen3 PCIe PHY driver")
MBR, Sergei
