On Wed, Jul 24, 2019 at 1:33 AM Nicolas Saenz Julienne <nsaenzjulienne@xxxxxxx> wrote: > > 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? > > [ 4.969679] WARNING: CPU: 2 PID: 21 at net/wireless/core.c:868 wiphy_register+0x8e8/0xbdc [cfg80211] > [...] > [ 4.969974] ieee80211 phy0: brcmf_cfg80211_attach: Could not register wiphy device (-22) We're seeing this on different platforms (allwinner / rockchip / amlogic) with Broadcom WiFi chips. So it's unlikely to be related with anything in this series. I believe a fix for this has already been queued up: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git/commit/?id=91046d6364afde646734c7ead1f649d253c386e9 ChenYu
