Hi, Catalin Marinas <catalin.marinas@xxxxxxx> writes: > On Fri, Apr 15, 2016 at 01:30:01PM +0300, Felipe Balbi wrote: >> Catalin Marinas <catalin.marinas@xxxxxxx> writes: >> > On Fri, Apr 15, 2016 at 11:01:08AM +0100, Catalin Marinas wrote: >> >> On Fri, Apr 15, 2016 at 12:49:15PM +0300, Felipe Balbi wrote: >> >> > Catalin Marinas <catalin.marinas@xxxxxxx> writes: >> >> > > On Thu, Apr 14, 2016 at 12:46:47PM +0000, David Fisher wrote: >> >> > >> dwc3 is in dual-role, with "synopsys,dwc3" specified in DT. >> >> > >> >> >> > >> When xhci is probed, initiated from dwc3/host.c (not DT), we get : >> >> > >> xhci-hcd: probe of xhci-hcd.7.auto failed with error -5 >> >> > >> This -EIO error originated from inside dma_set_mask() down in include/asm-generic/dma-mapping-common.h >> >> > >> >> >> > >> If "generic-xhci" is specified in DT instead, it probes fine as a host-only dwc3 >> >> > >> The difference between DT initiated probe and dwc3 initiated probe is that >> >> > >> when DT initiated probe gets to dma_supported, dma_supported is >> >> > >> implemented by swiotlb_dma_supported (previously set up by a DT call to arch_dma_setup_ops). >> >> > >> Whereas when dwc3 initiated xhci probe gets to dma_supported, arch_dma_setup_ops has not been called >> >> > >> and dma_supported is only implemented by __dummy_dma_supported, returning 0. >> >> > >> >> >> > >> Bisecting finds the "bad" commit as >> >> > >> 1dccb598df549d892b6450c261da54cdd7af44b4 (inbetween 4.4-rc1 and 4.4-rc2) >> >> > >> --- a/arch/arm64/include/asm/dma-mapping.h >> >> > >> --- a/arch/arm64/mm/dma-mapping.c >> >> > >> >> >> > >> Previous to this commit, dma_ops = &swiotlb_dma_ops was done in arm64_dma_init >> >> > >> After this commit, the assignment is only done in arch_dma_setup_ops. >> >> > > >> >> > > This restriction was added on purpose and the arm64 __generic_dma_ops() >> >> > > now has a comment: >> >> > > >> >> > > /* >> >> > > * We expect no ISA devices, and all other DMA masters are expected to >> >> > > * have someone call arch_setup_dma_ops at device creation time. >> >> > > */ >> >> > >> >> > how ? >> >> >> >> Usually by calling arch_setup_dma_ops(). >> > >> > Or of_dma_configure(), I forgot to mention this (see the >> > pci_dma_configure() function as an example). >> >> the device is manually created, there's not OF/DT for it ;-) > > As for PCI, the created device doesn't have a node but the bridge does. > Something like below, completely untested: > > diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c > index c679f63783ae..96d8babd7f23 100644 > --- a/drivers/usb/dwc3/host.c > +++ b/drivers/usb/dwc3/host.c > @@ -32,7 +32,10 @@ int dwc3_host_init(struct dwc3 *dwc) > return -ENOMEM; > } > > - dma_set_coherent_mask(&xhci->dev, dwc->dev->coherent_dma_mask); > + if (IS_ENABLED(CONFIG_OF) && dwc->dev->of_node) > + of_dma_configure(&xhci->dev, dwc->dev->of_node); > + else > + dma_set_coherent_mask(&xhci->dev, dwc->dev->coherent_dma_mask); assuming this works fine for all users, I don't have an issue with it. Grygorii has just been working on DMA setup for k2 and dwc3, so I want to make sure this won't regress those devices. -- balbi
Attachment:
signature.asc
Description: PGP signature
