From: Heiko Stuebner <heiko@sntech.de>
To: William Wu <william.wu@rock-chips.com>
Cc: gregkh@linuxfoundation.org, balbi@kernel.org,
linux-rockchip@lists.infradead.org, briannorris@google.com,
dianders@google.com, kever.yang@rock-chips.com,
huangtao@rock-chips.com, frank.wang@rock-chips.com,
eddie.cai@rock-chips.com, John.Youn@synopsys.com,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
sergei.shtylyov@cogentembedded.com
Subject: Re: [PATCH v4 5/5] usb: dwc3: rockchip: add devicetree bindings documentation
Date: Tue, 28 Jun 2016 18:41:28 +0200 [thread overview]
Message-ID: <1652918.4YDfA4VDoG@phil> (raw)
In-Reply-To: <5771EC6C.3070707@rock-chips.com>
Hi William,
Am Dienstag, 28. Juni 2016, 11:18:04 schrieb William Wu:
> >> So about the usb3 controller clk management, I think it should contain
> >> the following clk:
> >> 1. aclk_usb3otg1
> >> 2. aclk_usb3otg0
> >> 3. aclk_usb3_grf
> >
> > correct, aclk_usb3otgX would then be the busclk for each controller if
> > I'm not mistaken and the grf clock should also get enabled, like we
> > also plan on doing for the vio_grf clock in the display area.
>
> OK, so aclk_usb3_grf should be marked as critical, right?
nope ... the consensus for the vio_grf clock was that the driver accessing
it should control it. So for the usb3_grf clock this would be your dwc3-
based driver being responsible for the grf-clock.
> I found that most of the grf clocks haven't been marked as critical,
> apart from vio_grf. So may I keep the aclk_usb3_grf in usb3 dts, and
> remove it after clock manager adds it to critical clocks?
you should keep the usb3-grf clock in the dts all the time.
> >> 4. aclk_usb3_noc
> >> For "aclk_usb3_noc", I discuss with our clk manager, the clk is always
> >> on before,
> >> but according to upstream maintainer's suggestion, we need to manage
> >> the
> >> noc clk by each module.
> >
> > can you point me to this discussion? The bus-interconnect is a very
> > separate component, which we don't model so far and thus we have all
> > the noc clocks simply marked as critical.
> >
> > As this clock doesn't belong to the actual usb controller block, but
> > said
> > separate component, handling it in the controller seems somehow wrong to
> > me.
> >
> > So my (current) opinion would again be to mark the noc clock as critical
> > for the time being.
>
> Sorry, it seems that I get the new information about clk management too
> late.:-)
>
> There's no dedicated discussion about noc clk, but similar to grf clock,
> please refer to "https://patchwork.kernel.org/patch/9171467/" for add
> pclk_vio_grf to critical clock on the RK3399, and you have agreed on
> that mark vio grf clk as critical. So I agree with your opinion, thanks~
The difference as I see it is, that the GRF parts are _part_ of the usb3
controller, while the interconnect really is a separate component,
connecting the controller to the rest of the system.
----------
| USB3 |----[Interconnect]----[rest of the system]
| [+GRF] |
----------
So the controller binding + driver should handle all clocks it needs to
operate. We currently don't model and handle the separate interconnect
though, so that noc clock should be critical for the time being.
Heiko
next prev parent reply other threads:[~2016-06-28 16:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-02 12:34 [PATCH v4 5/5] usb: dwc3: rockchip: add devicetree bindings documentation William Wu
2016-06-16 23:15 ` Heiko Stübner
2016-06-17 9:18 ` William Wu
2016-06-20 14:44 ` Heiko Stübner
2016-06-21 9:11 ` William Wu
2016-06-24 19:50 ` Heiko Stuebner
2016-06-28 3:18 ` William Wu
2016-06-28 16:41 ` Heiko Stuebner [this message]
2016-06-29 1:56 ` William Wu
2016-06-21 8:09 ` Felipe Balbi
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=1652918.4YDfA4VDoG@phil \
--to=heiko@sntech.de \
--cc=John.Youn@synopsys.com \
--cc=balbi@kernel.org \
--cc=briannorris@google.com \
--cc=dianders@google.com \
--cc=eddie.cai@rock-chips.com \
--cc=frank.wang@rock-chips.com \
--cc=gregkh@linuxfoundation.org \
--cc=huangtao@rock-chips.com \
--cc=kever.yang@rock-chips.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-usb@vger.kernel.org \
--cc=sergei.shtylyov@cogentembedded.com \
--cc=william.wu@rock-chips.com \
/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).