LKML Archive on
help / color / mirror / Atom feed
From: Masahiro Yamada <>
To: Martin Blumenstingl <>
	Felipe Balbi <>,
	Rob Herring <>, Roger Quadros <>,
	Masami Hiramatsu <>,
	Jassi Brar <>,
	Kunihiko Hayashi <>,
	DTML <>,
	Felipe Balbi <>,
	Linux Kernel Mailing List <>,
	Rob Herring <>,
	Greg Kroah-Hartman <>,
	Mark Rutland <>
Subject: Re: [PATCH v2 2/2] usb: dwc3: support clocks and resets for DWC3 core
Date: Tue, 24 Apr 2018 10:17:12 +0900	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

2018-04-24 2:44 GMT+09:00 Martin Blumenstingl
> Hello,
> On Thu, Apr 19, 2018 at 1:03 PM, Masahiro Yamada
> <> wrote:
>> Historically, the clocks and resets are handled on the glue layer
>> side instead of the DWC3 core.  For simple cases, dwc3-of-simple.c
>> takes care of arbitrary number of clocks and resets.  The DT node
>> structure typically looks like as follows:
>>   dwc3-glue {
>>           compatible = "foo,dwc3";
>>           clocks = ...;
>>           resets = ...;
>>           ...
>>           dwc3 {
>>                   compatible = "snps,dwc3";
>>                   ...
>>           };
>>   }
>> By supporting the clocks and the reset in the dwc3/core.c, it will
>> be turned into a single node:
>>   dwc3 {
>>           compatible = "foo,dwc3", "snps,dwc3";
>>           clocks = ...;
>>           resets = ...;
>>           ...
>>   }
>> This commit adds the binding of clocks and resets specific to this IP.
>> The number of clocks should generally be the same across SoCs, it is
>> just some SoCs either tie clocks together or do not provide software
>> control of some of the clocks.
>> I took the clock names from the Synopsys datasheet: "ref" (ref_clk),
>> "bus_early" (bus_clk_early), and "suspend" (suspend_clk).
> looking at the code: this could mean that dwc3-exynos.c can be removed
> mid-term (assuming the PHY and regulator handling can be
> moved/removed/changed)

That is a good news.

> does the datasheet state anything about the clock speeds? from
> Documentation/devicetree/bindings/usb/dwc3-xilinx.txt:
> "bus_clk" Master/Core clock, have to be >= 125 MHz for SS operation
> and >= 60MHz for HS operation

Not sure.
"xlnx,zynqmp-dwc3" is a member of dwc3-of-simple.c
which just enables/disables clocks.

That information is not important.

>> I found only one reset line in the datasheet, hence the reset-names
>> property is omitted.
> does the datasheet state whether this is a level or a pulsed reset line?
> on Amlogic Meson GXL, GXM and AXG SoCs we use a pulsed (and shared)
> reset line (see ff0a632f08759e "usb: dwc3: of-simple: add support for
> shared and pulsed reset lines") because the reset line is shared
> between various components (USB2 PHY, USB3 PHY, dwc3 controller, ...)
> your current approach (having a vendor-specific "foo,dwc3" binding
> along with the generic "snps,dwc3") would allow having
> per-"of_device_id" settings which could indicate whether the reset
> lines are level or pulsed reset if these are "implementation specific"

I guess your commit
is wrong.

About the clocks, Rob Herring pointed out:

  However, this should be specific as to how many clocks and their
  function. This should be readily available to someone with access to
  Synopsys datasheet. The number of clocks should generally be the same
  across SoCs, it is just some SoCs either tie clocks together or don't
  provide s/w control of some of the clocks.

The same applies to the reset control.
The reset policy should be the same across SoCs
since we are using the same IP (i.e. the same delivered RTL).

You are using a pulse reset for DWC3
just because the reset controller in your SoC
is implemented like that.

This is NOT because your DWC3 in your SoC is
specially customized, right?

You put a reset-provider matter to a reset-consumer.

>> Supporting those clocks and resets is the requirement for new platforms.
> just to confirm:
> with this series your goal is to replace the wrapper node which is
> needed due to dwc3-of-simple.c ?

In my _hope_.

But, I cannot do this by myself
since I do not have such boards.

Depends on how people make efforts to covert existing platforms.

> would other drivers which currently create a wrapper node (like
> dwc3-keystone.c) keep their wrapper node or do you have any plans for
> removing it for the other "wrapper" drivers too?

We need to take a close look per driver.

Looking at the dwc3-keystone.c,
it works like an interrupt controller with irq-domain hierarchy.
If it is moved to the irqchip subsystem,
dwc3-keystone.c could be removed.

>> Enforcing the new binding breaks existing platforms since they specify
>> clocks and resets in their glue layer node, but nothing in the core
>> node.  I listed such exceptional cases in the DT binding.  The driver
>> code is loosened up to accept no clock/reset.  This change is based
>> on the discussion [1].
> (snip)
> Regards
> Martin

Best Regards
Masahiro Yamada

  reply	other threads:[~2018-04-24  1:18 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-19 11:03 [PATCH v2 0/2] usb: dwc3: support clocks and resets for DWC3 core Masahiro Yamada
2018-04-19 11:03 ` [PATCH v2 1/2] usb: dwc3: use local copy of resource to fix-up register offset Masahiro Yamada
2018-05-01 14:07   ` Masahiro Yamada
2018-04-19 11:03 ` [PATCH v2 2/2] usb: dwc3: support clocks and resets for DWC3 core Masahiro Yamada
2018-04-23 17:44   ` Martin Blumenstingl
2018-04-24  1:17     ` Masahiro Yamada [this message]
2018-04-28  2:41     ` Masahiro Yamada
2018-04-28 14:20       ` Martin Blumenstingl
2018-05-10  9:24         ` Masahiro Yamada
2018-04-25 15:21   ` Rob Herring
2018-04-27 16:20     ` Masahiro Yamada
2018-04-27 18:40       ` Rob Herring
2018-04-24  0:11 ` [PATCH v2 0/2] " Manu Gautam
2018-04-24  1:36   ` Masahiro Yamada

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

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