linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).