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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux