Hi David, David Fisher <david.fish...@synopsys.com> writes: > 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
if you specify it in DT, you force DT to set dma_mask for you, so that's just masking the real problem. > 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. that's probably a regression caused by the commit you list below. Arnd ? > 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. > > We're not using any dwc3-<glue>.c wrapper here, but we've not needed > it before this commit. Relevant ? shouldn't be, no. It should work fine either way. > It might also be possible that we've messed up some KConfig that > changed between versions ? unlikely, imo. > Or is this a bug that needs patching - in arm(64) dma or something > different for dma setup in dwc3/host.c ? I'd assume it's a bug with arm64 since we have this working fine on arm32 and x86. Let's wait to hear from Arnd. -- balbi
signature.asc
Description: PGP signature
