Re: dwc3 initiated xhci probe problem in arm64 4.4 kernel due to DMA setup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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().

> > 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.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux