lkml.org 
[lkml]   [2018]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v2 2/2] usb: dwc3: support clocks and resets for DWC3 core
Hello,

On Thu, Apr 19, 2018 at 1:03 PM, Masahiro Yamada
<yamada.masahiro@socionext.com> 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)

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

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

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

> 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

\
 
 \ /
  Last update: 2018-04-23 19:45    [W:0.123 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site