Re: [RFC] ARM: sa1100/assabet: move dmabounce hack to ohci driver

[Russell King (Oracle)]

On Tue, Feb 01, 2022 at 05:10:38PM +0000, Robin Murphy wrote:
> On 2022-02-01 15:02, Arnd Bergmann wrote:
> > From: Arnd Bergmann <arnd@xxxxxxxx>
> > 
> > The sa1111 platform is one of the two remaining users of the old Arm
> > specific "dmabounce" code, which is an earlier implementation of the
> > generic swiotlb.
> > 
> > Linus Walleij submitted a patch that removes dmabounce support from
> > the ixp4xx, and I had a look at the other user, which is the sa1111
> > companion chip.
> > 
> > Looking at how dmabounce is used, I could narrow it down to one driver
> > one one machine:
> > 
> >   - dmabounce is only initialized on assabet and pfs168, but not on
> >     any other sa1100 or pxa platform using sa1111.
> 
> Hmm, my reading of it was different. AFAICS it should affect all platforms
> with CONFIG_ARCH_SA1100 + CONFIG_SA1111 - the bus notifier from
> sa1111_init() will initialise dmabounce for everything where
> sa1111_configure_smc() has punched a hole in the DMA mask to handle the
> addressing erratum. sa1111_needs_bounce() looks to be a further
> consideration for platforms where DMA *additionally* cannot target an entire
> bank of memory at all.

Correct. The SA1111 companion can only access one SDRAM bank, whereas
the SA1110 SoC can address up to four SDRAM banks. On platforms where
there is only one bank of SDRAM, there is no issue. However, on the
Assabet there is one SDRAM bank, and on the Neponset daughter board
with the SA1111, there is a second bank. As explained in the commentry,
the SA1111 can be hardware-configured via resistive jumpers to access
either bank, but we only support the factory-shipped configuration,
which is bank 0 (the lowest addressable bank.)

The SA1111 also has an issue that one of its address lines doesn't
behave correctly, and depending on the SDRAM columns/rows, this
punches multiple holes in the SDRAM address space it can access,
which is what the sa1111_dma_mask[] array is about, and we end up
with every alternate megabyte of physical address space being
inaccessible.

The DMA mask, along with the logic in dmabounce (which truely uses the
DMA mask as, erm, a *mask* rather than the misnamed *limit* that it
has been) know about both of these issues.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!