RE: [PATCH 2/6] drivers: clk: renesas: r9a07g044-cpg: Add USB clocks

[Biju Das <biju.das.jz@bp.renesas.com>]

Hi Geert,

Thanks for the feedback.

> Subject: Re: [PATCH 2/6] drivers: clk: renesas: r9a07g044-cpg: Add USB
> clocks
> 
> Hi Biju,
> 
> On Mon, Jun 14, 2021 at 2:26 PM Geert Uytterhoeven <geert@linux-m68k.org>
> wrote:
> > On Fri, Jun 11, 2021 at 3:46 PM Biju Das <biju.das.jz@bp.renesas.com>
> wrote:
> > > Add clock entries for USB{0,1}.
> > >
> > > Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> > > Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> >
> > Thanks for your patch!
> >
> > > --- a/drivers/clk/renesas/r9a07g044-cpg.c
> > > +++ b/drivers/clk/renesas/r9a07g044-cpg.c
> > > @@ -88,6 +88,12 @@ static struct rzg2l_mod_clk r9a07g044_mod_clks[] =
> {
> > >         DEF_MOD("dmac",         R9A07G044_CLK_DMAC,
> > >                                 R9A07G044_CLK_P1,
> > >                                 0x52c, (BIT(0) | BIT(1)), (BIT(0) |
> > > BIT(1))),
> > > +       DEF_MOD("usb0",         R9A07G044_CLK_USB0,
> > > +                               R9A07G044_CLK_P1,
> > > +                               0x578, (BIT(0) | BIT(2) | BIT(3)),
> (BIT(0) | BIT(2) | BIT(3))),
> > > +       DEF_MOD("usb1",         R9A07G044_CLK_USB1,
> > > +                               R9A07G044_CLK_P1,
> > > +                               0x578, (BIT(1) | BIT(3)), (BIT(1) |
> > > + BIT(3))),
> > >         DEF_MOD("scif0",        R9A07G044_CLK_SCIF0,
> > >                                 R9A07G044_CLK_P0,
> > >                                 0x584, BIT(0), BIT(0)),
> >
> > While the above matches the datasheet, I see a problem with the
> > implementation. As BIT(3) of the CPG_{CLKON,CLKMON,RST}_USB is shared
> > by the two USB2.0 channels, disabling USB_PCLK or asserting
> > USB_PRESETN will affect both channels.  So it looks like you need
> > special handling to make sure that doesn't happen while the other
> channel is in use.
> >
> > Or am I missing something?
> 
> I'm getting the impression we do have to model the individual bits as
> separate clocks (and resets).  That would solve the problem with the
> shared USB_PCLK, as the clock framework will take care of keeping it
> enabled when at least one channel is in use.
> 
> Besides USB, SDHI has 4 clock bits, which we definitely don't want to
> control together, as the card detect clock must not be stopped while
> suspended.
> However, the exception to the rule is Ethernet: each channel has
> 2 clocks, but only a single bit to control, so this needs a custom single-
> gate-for-dual-clock driver.
> 
> Perhaps merging the clock binding definitions and initial driver for
> v5.14 was a bit premature...
> Anyway, we'll have 6 rcs after v5.14-rc1 to get it right ;-)
> 
> What do you think?

I am ok with this approach for USB, SDHI and Ethernet.

Regards,
Biju