linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: William Wu <william.wu@rock-chips.com>
To: "Heiko Stübner" <heiko@sntech.de>
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, 21 Jun 2016 17:11:44 +0800	[thread overview]
Message-ID: <576904D0.6060005@rock-chips.com> (raw)
In-Reply-To: <4674233.DVms812T4a@diego>

Dear Heiko,

On 06/20/2016 10:44 PM, Heiko Stübner wrote:
> Hi William,
>
> Am Freitag, 17. Juni 2016, 17:18:59 schrieb William Wu:
>> On 06/17/2016 07:15 AM, Heiko Stübner wrote:
>>> Am Donnerstag, 2. Juni 2016, 20:34:56 schrieb William Wu:
>>>> This patch adds the devicetree documentation required for Rockchip
>>>> USB3.0 core wrapper consisting of USB3.0 IP from Synopsys.
>>>>
>>>> It supports DRD mode, and could operate in device mode (SS, HS, FS)
>>>> and host mode (SS, HS, FS, LS).
>>>>
>>>> Signed-off-by: William Wu <william.wu@rock-chips.com>
> [...]
>
>>>> +Optional clocks:
>>>> +  "aclk_usb3otg0"	Aclk for specific usb controller clock.
> what does this clock do? Also most likely same argument as below.
Here is partial rk3399 clk tree about usb3:

aclk_usb3                       7            7   297000000 0 0
              aclk_usb3_grf                1            1 
297000000          0 0
              aclk_usb3_rksoc_axi_perf     1            1 
297000000          0 0
              aclk_usb3otg1                1            1 
297000000          0 0
              aclk_usb3otg0                1            1 
297000000          0 0
              aclk_usb3_noc                1            1 
297000000          0 0

from the clk tree, and check with our IC designers, we can see that:
1. aclk_usb3 is the parent clk of aclk_usb3****
2. aclk_usb3_grf  is used for both otg0 and otg1 grf, and these usb3 grf 
can be set
to control otg0 and otg1 controller, but not the phy.
3. aclk_usb3otg1 is otg1 controller clk,  aclk_usb3otg0 is otg0 
controller clk.
4. aclk_usb3_rksoc_axi_perf is the clk for usb3 performance monitor module.
5. aclk_usb3_noc is the clk for soc bus interconnect.

>
>>>> +  "aclk_usb3_rksoc_axi_perf"  USB AXI perf clock.  Not present on all
>>>> platforms.
>>> The clock names looks pretty strange. What are they for? Especially as
>>> nothing seems to use them right now.
>> "aclk_usb3_rksoc_axi_perf", it's the clk for usb3 performance monitor
>> module, you can refer to the GRF_USB3_PERF_xxx. And we don't use the usb3
>> performance monitor control registers right now.
> ok, then I'd suggest not defining the clock for now.
>
> For one, there are more perf blocks in the GRF (usb3, pcie, hdcp22, gmac, gpu,
> etc) which all seem to share a somewhat similar design, so they will maybe
> result in a separate driver of some form for the performance monitors.
>
> And secondly, it is somewhat easy to add new optional properties, but you
> cannot remove anything defined previously. So if we later decide to handle all
> the performance monitors differently, you can't remove that clock from the
> binding again. (or at least only with quite a bit of hassle).
>
> So as this clock isn't used at all yet, I guess it should not get included
> now.
Yes, I agree with you. We can remove the aclk_usb3_rksoc_axi_perf right now.
>
>>>> +  "aclk_usb3_grf"	USB grf clock.  Not present on all platforms.
>>> for my own education, which part of the GRF does this clock supply?
>> "aclk_usb3_grf", it's the clk for USB3 grf, e.g. GRF_USB3OTGX_CONX
> Hmm, this looks more like it belongs to the otg phy?
> Anyway, also seems unused right now, so same argument as above applies here.
As I have described above, the "aclk_usb3_grf" is  used for both otg0 
and otg1 grf,
and these usb3 grf can be set to control otg0 and otg1 controller, but 
not the phy.
And we have done a test that remove the grf clk, and the result showed 
that usb3
controller can't work normally. So I think we need the usb3 grf clk.

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

and the follow two clk can be removed:
1. aclk_usb3
2. aclk_usb3_rksoc_axi_perf

Is it ok?
>
>
> Heiko
>
>
>

  reply	other threads:[~2016-06-21  9:12 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 [this message]
2016-06-24 19:50         ` Heiko Stuebner
2016-06-28  3:18           ` William Wu
2016-06-28 16:41             ` Heiko Stuebner
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=576904D0.6060005@rock-chips.com \
    --to=william.wu@rock-chips.com \
    --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=heiko@sntech.de \
    --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 \
    /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).