Message ID | 20210125093825.4292-1-s.hauer@pengutronix.de |
---|---|
Headers | show |
Series | usb: dwc2: Use clk bulk API for supporting multiple clocks | expand |
On Mon, Jan 25, 2021 at 10:38:24AM +0100, Sascha Hauer wrote: > This adds support for an additional clock for the dwc2 core in case > there is another clock to the phy which must be enabled. to the phy? 'clocks' is inputs to DWC2. Shouldn't there be a phy device/driver? > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> > --- > Documentation/devicetree/bindings/usb/dwc2.yaml | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/usb/dwc2.yaml b/Documentation/devicetree/bindings/usb/dwc2.yaml > index e5ee51b7b470..56dd0d18d535 100644 > --- a/Documentation/devicetree/bindings/usb/dwc2.yaml > +++ b/Documentation/devicetree/bindings/usb/dwc2.yaml > @@ -57,11 +57,14 @@ properties: > maxItems: 1 > > clocks: > - maxItems: 1 > + minItems: 1 > + maxItems: 2 > > clock-names: > items: > - const: otg > + - const: phy > + minItems: 1 > > resets: > items: > -- > 2.20.1 >
On Mon, Jan 25, 2021 at 10:38:23AM +0100, Sascha Hauer wrote: > Currently the dwc2 driver only supports a single clock. I have a board > here which has a dwc2 controller with a somewhat special clock routing > to the phy. Both the dwc2 controller and the ULPI phy get their phy > clock from a SI5351 clock generator. This clock generator has multiple > clock outputs which each is modelled as a separate clk in Linux. > Unfortunately the clock to the phy and the clock to the dwc2 core are on > two different output pins of the SI5351, so we have two clocks which > must be enabled. The phy is driven by the usb-nop-xceiver driver which > supports a single clock. My first approach was to add support for a > second clock to that driver, but technically the other clock is > connected to the dwc2 core, so instead I added support for a second > clock to the dwc2 driver. This can easily be archieved with the clk > bulk API as done in this series. Where is the usb-nop-xceiver single clock coming from? Maybe you shouldn't be using usb-nop-xceiver? There is a ULPI binding though that alone doesn't really help you. Rob
On Tue, Feb 09, 2021 at 10:46:59AM -0600, Rob Herring wrote: > On Mon, Jan 25, 2021 at 10:38:24AM +0100, Sascha Hauer wrote: > > This adds support for an additional clock for the dwc2 core in case > > there is another clock to the phy which must be enabled. > > to the phy? 'clocks' is inputs to DWC2. Shouldn't there be a phy > device/driver? Maybe I should have said "from the phy". I have a USB3320 ULPI phy here connected to the DWC2. The usual setup would look like this: -----. clk60M .------------ DWC2 |<------------| USB3320 Phy -----' '------------ I don't think this clock is abstracted anywhere in this case, it's just there and always enabled. For reasons unknown to me our customer decided to not let the USB3320 generate the clock, but used an external clock generator instead, so my setup looks like this: | SI5351a | '---------' clk60M_1 | | clk60M_2 -----. | | .------------ DWC2 |<----' '--->| USB3320 Phy -----' '------------ The SI5351a is abstracted as a clock driver in Linux. Note that clk60M_1 and clk60M_2 are really two clocks which must both be enabled. clk60M_2 is handled by the phy driver (which is the usb-nop-xceiver in my case), what I am trying to add here in this patch is support for clk60M_1. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On Tue, Feb 09, 2021 at 10:54:24AM -0600, Rob Herring wrote: > On Mon, Jan 25, 2021 at 10:38:23AM +0100, Sascha Hauer wrote: > > Currently the dwc2 driver only supports a single clock. I have a board > > here which has a dwc2 controller with a somewhat special clock routing > > to the phy. Both the dwc2 controller and the ULPI phy get their phy > > clock from a SI5351 clock generator. This clock generator has multiple > > clock outputs which each is modelled as a separate clk in Linux. > > Unfortunately the clock to the phy and the clock to the dwc2 core are on > > two different output pins of the SI5351, so we have two clocks which > > must be enabled. The phy is driven by the usb-nop-xceiver driver which > > supports a single clock. My first approach was to add support for a > > second clock to that driver, but technically the other clock is > > connected to the dwc2 core, so instead I added support for a second > > clock to the dwc2 driver. This can easily be archieved with the clk > > bulk API as done in this series. > > Where is the usb-nop-xceiver single clock coming from? It's coming from the SI5351 clock generator > > Maybe you shouldn't be using usb-nop-xceiver? There is a ULPI binding > though that alone doesn't really help you. The clock that feeds the phy is handled by the usb-nop-xceiver just fine, it's the clock that is fed to the DWC2 controller that I need support for. I hope my other mail makes this clearer a bit. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |