Re: [PATCH 00/18] ARM: Add minimal Raspberry Pi 4 support

From: Stefan Wahren <wahrenst@gmx.net>
To: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
	Christoph Hellwig <hch@lst.de>
Cc: Eric Anholt <eric@anholt.net>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Ray Jui <rjui@broadcom.com>,
	Scott Branden <sbranden@broadcom.com>,
	Matthias Brugger <mbrugger@suse.com>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	bcm-kernel-feedback-list@broadcom.com,
	linux-arm-kernel@lists.infradead.org,
	linux-rpi-kernel@lists.infradead.org, linux-gpio@vger.kernel.org,
	linux-mmc@vger.kernel.org
Subject: Re: [PATCH 00/18] ARM: Add minimal Raspberry Pi 4 support
Date: Tue, 23 Jul 2019 23:30:21 +0200	[thread overview]
Message-ID: <9937cd58-3921-6b9a-b099-d0aa28035e50@gmx.net> (raw)
In-Reply-To: <5f9b11f54c66fd0487837f7e58af3adf7f86635f.camel@suse.de>

Hi Nicolas,

Am 23.07.19 um 19:33 schrieb Nicolas Saenz Julienne:
> On Tue, 2019-07-23 at 18:26 +0200, Stefan Wahren wrote:
>> Hi Nicolas,
>>
>> thanks for your work, but i'm a little bit sceptical about these
>> changes. So here some thoughts.
>>
>> Am 23.07.19 um 15:32 schrieb Nicolas Saenz Julienne:
>>> On Tue, 2019-07-23 at 11:34 +0200, Christoph Hellwig wrote:
>>>> On Mon, Jul 22, 2019 at 08:10:17PM +0200, Stefan Wahren wrote:
>>>>> i rebased this series also and got this only on the RPi 4.
>>>>>
>>>>> After reverting the following:
>>>>>
>>>>> 79a986721de dma-mapping: remove dma_max_pfn
>>>>> 7559d612dff0 mmc: core: let the dma map ops handle bouncing
>>>>>
>>>>> This crash disappear, but wifi seems to be still broken.
>>>>>
>>>>> Would be nice, if you can investigate further.
>>>> That means dma addressing on this system doesn't just work for some
>>>> memory, and the mmc bounce buffering was papering over that just for
>>>> mmc.  Do you have highmem on this system?
>>>>
>>>> You might want to try this series, which has been submitted upstream:
>>>>
>>>>
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/arm-swiotlb
>>> Hi Christoph,
>>> I tried your series on top of Stefan's, it has no effect. I guess it's no
>>> surprise as with mult_v7_defconfig, you get SWIOTLB=n & LPAE=n.
>>>
>>> FYI DMA addressing constraints for RPi4 are the following: devices can only
>>> access the first GB of ram even though the board might have up to 4GB of
>>> ram.
>>> The DMA addresses are aliased with a 0xc0000000 offset. So 0x00000000 phys
>>> is
>>> aliased to 0xc0000000 in DMA. This is the same as for an RFC you commented
>>> last
>>> week trying to fix similar issues for arm64.
>>>
>>> You state in "arm: use swiotlb for bounce buffer on LPAE configs" that "The
>>> DMA
>>> API requires that 32-bit DMA masks are always supported". If I understand it
>>> correctly this device breaks that assumption. Which implies we need a bounce
>>> buffer system in place for any straming DMA user.
>>>
>>> It seems we're unable to use dma-direct/swiotlb, so I enabled arm's
>>> dmabounce
>>> on all devices hooked into RPi's limited interconnect, which fixes this
>>> issue.
>> Does it fix the wifi issue too?
> Well it works as long as I revert this: 901bb98918 ("nl80211: require and
> validate vendor command policy"). Which has nothing to do with DMA anyways.
>
> Was this the issue you where seeing?
Yes. So it's a regression? I will try to test it with a RPi 3B+