When 64-bit DMA was first used, there were problems with the
BCM4311 (14e4:4311). The problem was "fixed" by using the GFP_DMA
flag in the allocation of coherent ring descriptor memory.
The original problem is now believed to have been due to bugs in
the 64-bit DMA implementation in the rest of the kernel, and that
those bugs have been fixed. Accordingly, the requirement for the
descriptors to be in the DMA zone is relaxed.
Bounce buffers are left in the DMA zone.
Signed-off-by: Larry Finger <[email protected]>
---
John,
This material is for next.
Larry
---
Index: wireless-testing-new/drivers/net/wireless/b43/dma.c
===================================================================
--- wireless-testing-new.orig/drivers/net/wireless/b43/dma.c
+++ wireless-testing-new/drivers/net/wireless/b43/dma.c
@@ -393,14 +393,7 @@ static int alloc_ringmemory(struct b43_d
* has shown that 4K is sufficient for the latter as long as the buffer
* does not cross an 8K boundary.
*
- * For unknown reasons - possibly a hardware error - the BCM4311 rev
- * 02, which uses 64-bit DMA, needs the ring buffer in very low memory,
- * which accounts for the GFP_DMA flag below.
- *
- * The flags here must match the flags in free_ringmemory below!
*/
- if (ring->type == B43_DMA_64BIT)
- flags |= GFP_DMA;
ring->descbase = dma_alloc_coherent(ring->dev->dev->dma_dev,
B43_DMA_RINGMEMSIZE,
&(ring->dmabase), flags);
On Wed, 24 Aug 2011 14:40:24 -0500
Larry Finger <[email protected]> wrote:
> @Rafal - Incorporate this in your other patch.
I would rather like to have this as a separate patch and have
Rafal's other patch apply on _top_ of this.
> @@ -903,7 +896,7 @@ struct b43_dmaring *b43_setup_dmaring(st
> kfree(ring->txhdr_cache);
> ring->txhdr_cache = kcalloc(ring->nr_slots / TX_SLOTS_PER_FRAME,
> b43_txhdr_size(dev),
> - GFP_KERNEL | GFP_DMA);
> + GFP_KERNEL);
> if (!ring->txhdr_cache)
> goto err_kfree_meta;
>
>
Why are you removing this? Seems wrong to me.
This seems to be part of the bounce-buffer mechanism, that we _do_ still need
for legacy 30bit devices.
--
Greetings, Michael.
On Wed, 24 Aug 2011 17:02:52 -0500
Larry Finger <[email protected]> wrote:
> When 64-bit DMA was first used, there were problems with the
> BCM4311 (14e4:4311). The problem was "fixed" by using the GFP_DMA
> flag in the allocation of coherent ring descriptor memory.
>
> The original problem is now believed to have been due to bugs in
> the 64-bit DMA implementation in the rest of the kernel, and that
> those bugs have been fixed. Accordingly, the requirement for the
> descriptors to be in the DMA zone is relaxed.
>
> Bounce buffers are left in the DMA zone.
>
> Signed-off-by: Larry Finger <[email protected]>
> ---
>
> John,
>
> This material is for next.
John, please apply this even though it's marked RFC, unless somebody
objects in reasonable time, which I don't expect.
You can also add
Signed-off-by: Michael Buesch <[email protected]>
if you desire.
> Index: wireless-testing-new/drivers/net/wireless/b43/dma.c
> ===================================================================
> --- wireless-testing-new.orig/drivers/net/wireless/b43/dma.c
> +++ wireless-testing-new/drivers/net/wireless/b43/dma.c
> @@ -393,14 +393,7 @@ static int alloc_ringmemory(struct b43_d
> * has shown that 4K is sufficient for the latter as long as the buffer
> * does not cross an 8K boundary.
> *
> - * For unknown reasons - possibly a hardware error - the BCM4311 rev
> - * 02, which uses 64-bit DMA, needs the ring buffer in very low memory,
> - * which accounts for the GFP_DMA flag below.
> - *
> - * The flags here must match the flags in free_ringmemory below!
> */
> - if (ring->type == B43_DMA_64BIT)
> - flags |= GFP_DMA;
> ring->descbase = dma_alloc_coherent(ring->dev->dev->dma_dev,
> B43_DMA_RINGMEMSIZE,
> &(ring->dmabase), flags);
>
--
Greetings, Michael.
On 08/25/2011 12:24 PM, Rafał Miłecki wrote:
> 2011/8/25 Larry Finger<[email protected]>:
>> When 64-bit DMA was first used, there were problems with the
>> BCM4311 (14e4:4311). The problem was "fixed" by using the GFP_DMA
>> flag in the allocation of coherent ring descriptor memory.
>>
>> The original problem is now believed to have been due to bugs in
>> the 64-bit DMA implementation in the rest of the kernel, and that
>> those bugs have been fixed. Accordingly, the requirement for the
>> descriptors to be in the DMA zone is relaxed.
>
> Larry, it is not clear to me from the commit message: did you test
> that patch with your 14e4:4311?
Yes.
Larry
2011/8/25 Larry Finger <[email protected]>:
> When 64-bit DMA was first used, there were problems with the
> BCM4311 (14e4:4311). The problem was "fixed" by using the GFP_DMA
> flag in the allocation of coherent ring descriptor memory.
>
> The original problem is now believed to have been due to bugs in
> the 64-bit DMA implementation in the rest of the kernel, and that
> those bugs have been fixed. Accordingly, the requirement for the
> descriptors to be in the DMA zone is relaxed.
Larry, it is not clear to me from the commit message: did you test
that patch with your 14e4:4311?
--
Rafał
W dniu 25 sierpnia 2011 19:29 użytkownik Larry Finger
<[email protected]> napisał:
> On 08/25/2011 12:24 PM, Rafał Miłecki wrote:
>>
>> 2011/8/25 Larry Finger<[email protected]>:
>>>
>>> When 64-bit DMA was first used, there were problems with the
>>> BCM4311 (14e4:4311). The problem was "fixed" by using the GFP_DMA
>>> flag in the allocation of coherent ring descriptor memory.
>>>
>>> The original problem is now believed to have been due to bugs in
>>> the 64-bit DMA implementation in the rest of the kernel, and that
>>> those bugs have been fixed. Accordingly, the requirement for the
>>> descriptors to be in the DMA zone is relaxed.
>>
>> Larry, it is not clear to me from the commit message: did you test
>> that patch with your 14e4:4311?
>
> Yes.
Great, thanks for taking a look at this :)
--
Rafał
2011/8/24 Michael Büsch <[email protected]>:
> On Wed, 24 Aug 2011 14:40:24 -0500
> Larry Finger <[email protected]> wrote:
>
>> @Rafal - Incorporate this in your other patch.
>
> I would rather like to have this as a separate patch and have
> Rafal's other patch apply on _top_ of this.
/me agrees
Larry: don't care about my patches, do this one and I'll rebase my one.
--
Rafał