On 03/11/2019 12:30 PM, Geert Uytterhoeven wrote:
>> Testing has shown that the RPC-IF module clock's parent is the RPCD2 clock,
>> not the RPC one -- the RPC-IF register reads stall otherwise...
>
> Perhaps... Or something else is wrong with how the RPC driver uses the
> clock hierarchy.
Yes, explicitly enabling RPCD2 did help as well.
> According to the docs, RPC clocks RPC-PHY, and RPCD2 clocks RPC-LINK.
I've also read the manual. Note it's not that reading a PHY register
hangs the kernel but reading CMNCR...
> Currently nothing references RPCD2, so it is disabled automatically.
Only on V3H.
> If you make RPC -> RPCD2 -> RPC-IF, enabling RPC-IF indeed enables
> both RPC and RPCD2.
Sure, it does. :-)
> Perhaps the RPC device node does need a reference to RPCD2?
Looks like that wouldn't hurt either...
> Is this also the case on R-Car V3M, where RPCD2 is not controlled by the
> CPG, but by the DIVREG register in the RPC-IF module itself?
No hangs were seen on V3M, despite the RPCD2 clock remained disabled.
The RPC clocks on both V3H and V3M suffer from a lack of clear documentation...
> See also section 62.4.7 (Frequency change), which does not have a
> subsection for V3H, but it may be impacted (changing RPCD2 causes
> an additional read of RPCCKR, satisfying the read-after-write requirement
> documented there).
Hmm, haven't seen this item before; it looks like we can't use the standard
divider component. BTW, this section in the 1.50 manual tells to use the soft
reset on V3MOK. OK, I'll investigate this...
>> Fixes: 94e3935b5756 ("clk: renesas: r8a77980: Add RPC clocks")
>> Signed-off-by: Sergei Shtylyov <[email protected]>
[...]
MBR, Sergei
