> > > Any thoughts on this?
> > >
> > > diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> > > index 5e5f1fabc3d4..3db8deed83a6 100644
> > > --- a/arch/arm/mach-bcm/Kconfig
> > > +++ b/arch/arm/mach-bcm/Kconfig
> > > @@ -168,6 +168,7 @@ config ARCH_BCM2835
> > > select PINCTRL
> > > select PINCTRL_BCM2835
> > > select MFD_CORE
> > > + select DMABOUNCE
> > > help
> > > This enables support for the Broadcom BCM2835 and BCM2836 SoCs.
> > > This SoC is used in the Raspberry Pi and Roku 2 devices.
> > > diff --git a/arch/arm/mach-bcm/board_bcm2835.c b/arch/arm/mach-
> > > bcm/board_bcm2835.c
> > > index c09cf25596af..be788849c4bb 100644
> > > --- a/arch/arm/mach-bcm/board_bcm2835.c
> > > +++ b/arch/arm/mach-bcm/board_bcm2835.c
> > > @@ -3,6 +3,8 @@
> > > * Copyright (C) 2010 Broadcom
> > > */
> > >
> > > +#include <linux/device.h>
> > > +#include <linux/dma-mapping.h>
> > > #include <linux/init.h>
> > > #include <linux/irqchip.h>
> > > #include <linux/of_address.h>
> > > @@ -24,8 +26,37 @@ static const char * const bcm2835_compat[] = {
> > > NULL
> > > };
> > >
> > > +static int bcm2835_needs_bounce(struct device *dev, dma_addr_t dma_addr,
> > > size_t size)
> > > +{
> > > + /*
> > > + * The accepted dma addresses are [0xc0000000, 0xffffffff] which
> > > map
> > > to
> > > + * ram's [0x00000000, 0x3fffffff].
> > > + */
> > > + return dma_addr < 3ULL * SZ_1G;
> > > +}
> > > +
> > > +/*
> > > + * Setup DMA mask to 1GB on devices hanging from soc interconnect
> > > + */
> > > +static int bcm2835_platform_notify(struct device *dev)
> > > +{
> > > + if (dev->parent && !strcmp("soc", dev_name(dev->parent))) {
> > > + dev->dma_mask = &dev->coherent_dma_mask;
> > > + dev->coherent_dma_mask = DMA_BIT_MASK(30); /* 1GB */
> > Shouldn't this come from the device tree?
>
> Yes, actually I could use the 'dma-ranges' parsing code I suggested on the
> arm64 RFC. The same goes with 'dma_zone_size = SZ_1G', it ideally should be
> calculated based on the device-tree.
>
> The way I see it I'm not sure it's worth the effort, in arm64 we have no
> choice
> as there are no board files. But here we seem to be the only ones with this
> specific DMA addressing constraint, so fixing it in arm/common doesn't seem
> like it's going to benefit anyone else. Let's see how the arm arch maintainers
> react though.
>
> There is one catch though. I missed it earlier as I was excited to see the
> board boot, but some devices are failing to set their DMA masks:
>
> [ 1.989576] dwc2 fe980000.usb: can't set coherent DMA mask: -5
>
> It seems that other users of dmabounce also implement their own
> dma_supported(). I have to look into it.
Sadly it seems there are some limitations in dmabounce I didn't take into
account earlier. Among other things it can't deal with HighMem out of the box
and even when trying to adapt it to our needs, fails to do so as it allocates
using GFP_ATOMIC, which rules out using the CMA when allocating coherent
memory. Sorry for the noise, I got carried away too soon.
I did a dirty hack hooking up dma-direct/swiotlb to the board. It seems to be
working fine after some tweaks in arm's dma_capable(). That said I want to test
it further before sending anything ;).
Attachment:
signature.asc
Description: This is a digitally signed message part
