Hi, Catalin Marinas <catalin.marinas@xxxxxxx> writes: > 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(). a driver calling arch_setup_dma_ops() ? Doesn't sound very nice. >> > The commit above also describes why it is dangerous to assume a fallback >> > to swiotlb ops. >> > >> >> We're not using any dwc3-<glue>.c wrapper here, but we've not needed >> >> it before this commit. Relevant ? >> >> >> >> It might also be possible that we've messed up some KConfig that >> >> changed between versions ? Or is this a bug that needs patching - in >> >> arm(64) dma or something different for dma setup in dwc3/host.c ? >> > >> > What I don't understand is why of_dma_configure() is not called for a >> > device with compatible="synopsys,dwc3" in DT (IIUC, you said that you >> > specify this in DT and of_platform_populate should do the right >> > configuration). >> >> it works fine for dwc3 core, but dwc3 manually creates a device for the >> XHCI core it has inside it. > > Ah, I think I get it know. We have something similar for > pci_device_add() which calls arch_setup_dma_ops() (explicitly via > pci_dma_configure()) since the PCI devices are probed at runtime, so we > can't specify them in DT. The PCI device inherits some properties from > the parent node. > > The issue with a default swiotlb is that it may not always be the right > thing like the device being behind an IOMMU. oh well, then the platform_bus needs some love :-) -- balbi
Attachment:
signature.asc
Description: PGP signature
