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+
