Message ID | 20210125093825.4292-1-s.hauer@pengutronix.de (mailing list archive) |
---|---|
Headers | show |
Series | usb: dwc2: Use clk bulk API for supporting multiple clocks | expand |
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: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