Re: b44 driver causes panic when using swiotlb

[Larry Finger]

On 01/31/2011 10:41 PM, Larry Finger wrote:
> From: Robert Hancock
> Date: Mon Jan 31 2011 - 22:22:32 EST
> 
>     * Next message: Amit Shah: "Re: [PATCH 1/3] tty: move hvc drivers to
> drivers/tty/hvc/"
>     * Previous message: Grant Likely: "Re: [RFC][PATCH] Power domains for
> platform bus type"
>     * In reply to: FUJITA Tomonori: "Re: b44 driver causes panic when using swiotlb"
>     * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> 
> On 01/31/2011 07:28 PM, FUJITA Tomonori wrote:
> 
>     On Mon, 31 Jan 2011 18:54:21 -0600
>     Robert Hancock<hancockrwd@xxxxxxxxx> wrote:
> 
>         On 01/31/2011 10:36 AM, Andi Kleen wrote:
> 
>             On Mon, Jan 31, 2011 at 10:54:12AM -0500, Chuck Ebbert wrote:
> 
>                 The b44 driver is triggering this panic in swiotlb_map_page():
> 
>                 if (!dma_capable(dev, dev_addr, size))
>                 panic("map_single: bounce buffer is not DMA'ble");
> 
>                 The kernel log says the bounce buffers are at 0xdb400000, but
> b44 can
>                 only do DMA to the first 1GB of memory:
> 
> 
>             b44 needs to use GFP_DMA then and do its own custom bouncing.
>             The standard pci_map_* bounce buffering is only designed for at least
>             32bit capable devices.
> 
> 
>         That seems wrong - it's a documented API and that restriction isn't
>         documented. Either it should comply with the request or return a failure
>         if it can't accomodate it, not just blow up internally. There's no
>         reason the driver should have to deal with this on its own.
> 
>         In this case the DMA mapping code should really be falling back to
>         GFP_DMA automatically if the IOMMU aperture is outside the DMA mask of
>         the device.
> 
> 
>     swiotlb allocates the bounce buffer when a system boots up. We can't
>     allocate much in GFP_DMA. swiotlb uses somewhere under 4GB. So it
>     can't help devices that have odd dma_mask (that is, except for 4GB).
> 
>     Unfortunately, Such device needs to do own custom bouncing or needs
>     their subsystem to does that.
> 
>     Some ideas to implement something that works for such device were
>     discussed. Seems that the conclusion is that it's doesn't worth making
>     the common code complicated for such minor and insane devices.
> 
> 
> I don't think this is the only device that has sub-32-bit DMA restrictions, this
> will just lead to a bunch of duplicated code. In particular, how is LPC DMA
> supposed to work?
> 
> At the very least we should be allowing the driver to deal with the failure
> instead of panicing the system. Otherwise we are just leaving a land mine for
> people to trip over.

Some devices driven by b43legacy and b43 only support 30-bit DMA, which is what
I suspect b44 handles. The b43* drivers use a bounce buffer. If a generic
mechanism were created, those 2 would use it.

Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/