On Fri, Apr 15, 2016 at 01:30:01PM +0300, Felipe Balbi wrote:
> Catalin Marinas <catalin.mari...@arm.com> 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.mari...@arm.com> 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);
xhci->dev.parent = dwc->dev;
xhci->dev.dma_mask = dwc->dev->dma_mask;
--
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
