On Tuesday 10 January 2017 09:19 PM, Tony Lindgren wrote: > * Alexandre Bailon <abailon@xxxxxxxxxxxx> [170110 07:23]: >> On 01/10/2017 11:05 AM, Sekhar Nori wrote: >>> On DA8xx, CPPI 4.1 DMAengine is not an independent system resource, but >>> embedded within the USB 2.0 controller. So, I think all that is needed >>> is for MUSB DA8xx glue to trigger probe of CPPI 4.1 dmaengine driver >>> when it is ready. I am not sure all this DA850-specific clock handling >>> is really necessary. >> Actually, we have a circular dependency. >> USB core tries to get DMA channels during the probe, which fails because >> CPPI 4.1 driver is not ready. >> But it will never be ready because the USB clock must be enabled before >> DMA driver probe, what will not happen because USB driver have disabled >> the clock when probe failed. >> >> Someone in the office suggested me to use the component API, >> that could help me to probe the DMA from the USB probe. >> >> Another way to workaround the dependency would be to do defer the >> function calls that access to hardware to avoid to control clock from >> DMA driver. > > Or you really have some wrapper IP block around musb and cppi41 just > like am335x has. > > See drivers/usb/musb/musb_am335x.c and compatible properties for > "ti,am33xx-usb" and it's children in am33xx.dtsi. This looks like what will will need to da850 too. Alexandre, If the wrapper is going to work, can you see if it will end up breaking DT compatibility once introduced? If yes, I suggest reverting the usb1 DT node in da850-lcdk.dts so we don't get into a DT compatibility problem once v4.10 releases. Thanks, Sekhar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
