RE: BCM91x80A/B PCI DMA problems

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

On Maw, 2006-03-14 at 08:55 -0800, Mark E Mason wrote:
> > needs fixing. The drivers don't deal with this matter beyond 
> > setting their PCI DMA range mask.
> 
> Thanks!
> 
> I'm not that familiar with all parts of the Linux kernel.  What should I
> be looking for in order to find the relevant bits in the arch-port code?

At the heart of it you need to look at the PCI DMA API. 

[Documentation/DMA-mapping.txt]

Linux uses three kinds of address: virtual and physical are the usual
expected CPU view, bus is the view from the I/O side. On most platforms
physical == bus but not all.

These are mapped onto the dma_* functions of the same name for most
platforms (see include/asm-generic/pci-dma-compat.h) but need not be.
The allocators then grab memory from the right memory pool (16Mb, 32bit,
highmem ..).

For mapping of pages this isn't so simple as the page might be above the
DMA limit of a device. dma_map_* gives you the bus address of a
something relative to the device. This is arch implemented and can
return an address out of the device range.

For a block device that is misbehaving you want to check

1. That the DMA allocations done by the driver (eg the IDE PRD) are
coming in below 4GB as expected

2. Take a look then at block/ll_rw_blk.c which deals with the block
layer. Dump the calls to blk_queue_block_limit and make sure the things
it does are looking sane. 

3. Take a look at what is going on in blk_rq_map_sg which deals with
mapping scatter gather lists to the device, while handling the bounce
limits. (dma_unmap_sg is the clean up end of this)

4. This lot then gets used by ide_build_sglist in drivers/ide/ide-dma.c
and the related ide_build_dmatable function. These might also be worth
dropping debug into to see what is cooking.

Alan