Am 25.07.19 um 10:22 schrieb Nicolas Saenz Julienne:
>>>> 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 ;).
>
Take your time.
But please inform about possible modifications to the devicetree. I will
sent out V2 of my series in a few days.
