From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Biju Das <biju.das.jz@bp.renesas.com>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
linux-clk <linux-clk@vger.kernel.org>,
Chris Paterson <Chris.Paterson2@renesas.com>,
Biju Das <biju.das@bp.renesas.com>,
Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>
Subject: Re: [PATCH 2/6] drivers: clk: renesas: r9a07g044-cpg: Add USB clocks
Date: Tue, 15 Jun 2021 12:24:52 +0200 [thread overview]
Message-ID: <CAMuHMdXHN-ThgpED0wUcWQjWyinnxQC8Yp_st-CWGpUj6mGmxw@mail.gmail.com> (raw)
In-Reply-To: <YMh5jWeONR6s+bwU@pendragon.ideasonboard.com>
Hi Laurent,
On Tue, Jun 15, 2021 at 11:57 AM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Tue, Jun 15, 2021 at 11:53:37AM +0200, Geert Uytterhoeven wrote:
> > On Tue, Jun 15, 2021 at 11:49 AM Laurent Pinchart
> > <laurent.pinchart@ideasonboard.com> wrote:
> > > On Tue, Jun 15, 2021 at 10:58:57AM +0200, Geert Uytterhoeven wrote:
> > > > 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.
> > >
> > > Does it ? Can't the same clock be referenced twice in DT ?
> >
> > Yes, you can reference the same clock twice. But what's the point?
> > If they're two different clocks, DT should reference two different
> > clocks. But the single bit should correspond to the ORed value of
> > the two clock enable states.
> >
> > Or do you mean something different?
>
> If the device has two clock inputs, I'd model the two clocks separately
> in the DT bindings. If those two clocks are gated by the same bit in an
> SoC, we have two options to model the integration:
>
> - Create a driver that registers different clocks with the same gating
> bit. We'll have two clocks to reference in DT.
OK, that's what I suggested.
> - Model both clocks as a single clock in the clock driver, and reference
> that clock twice in DT. This is simpler, but only works if the
> consumer doesn't need to query the clock rate.
Modelling them as a single clock is how the current RZ/G2L clock
driver would implement it. But why bother referencing it twice in DT?
renesas,ether*.yaml (assuming the Ethernet block is compatible)
documents a single clock only (ignoring optional refclk), and the driver
doesn't care about the clock rate.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
next prev parent reply other threads:[~2021-06-15 10:25 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-11 13:46 [PATCH 0/6] Add RZ/G2L USB2.0 phy and host support Biju Das
2021-06-11 13:46 ` [PATCH 1/6] dt-bindings: phy: renesas: Document RZ/G2L USB PHY Control bindings Biju Das
2021-06-21 4:01 ` Vinod Koul
2021-06-21 6:40 ` Biju Das
2021-06-11 13:46 ` [PATCH 2/6] drivers: clk: renesas: r9a07g044-cpg: Add USB clocks Biju Das
2021-06-14 12:26 ` Geert Uytterhoeven
2021-06-15 8:58 ` Geert Uytterhoeven
2021-06-15 9:48 ` Laurent Pinchart
2021-06-15 9:53 ` Geert Uytterhoeven
2021-06-15 9:57 ` Laurent Pinchart
2021-06-15 10:24 ` Geert Uytterhoeven [this message]
2021-06-16 10:16 ` Biju Das
2021-06-16 11:33 ` Laurent Pinchart
2021-06-16 10:12 ` Biju Das
2021-06-11 13:46 ` [PATCH 3/6] phy: renesas: Add RZ/G2L usb phy control driver Biju Das
2021-06-21 4:13 ` Vinod Koul
2021-06-21 6:51 ` Biju Das
2021-06-11 13:46 ` [PATCH 4/6] arm64: configs: defconfig: Enable RZ/G2L USB PHY " Biju Das
2021-06-11 13:46 ` [PATCH 5/6] dt-bindings: phy: renesas,usb2-phy: Document RZ/G2L phy bindings Biju Das
2021-06-11 13:46 ` [PATCH 6/6] arm64: dts: renesas: r9a07g044: Add USB2.0 phy and host support Biju Das
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMuHMdXHN-ThgpED0wUcWQjWyinnxQC8Yp_st-CWGpUj6mGmxw@mail.gmail.com \
--to=geert@linux-m68k.org \
--cc=Chris.Paterson2@renesas.com \
--cc=biju.das.jz@bp.renesas.com \
--cc=biju.das@bp.renesas.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-clk@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
--cc=sboyd@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).