When DMA mapping for RX fails because of the limitation, retry the allocation
in ZONE_DMA. When the network stack passes us TX buffers that cannot be mapped
because of the limitation, allocate a bounce buffer in ZONE_DMA and copy the
packet there.
Signed-off-by: Will Dyson <[EMAIL PROTECTED]>
---
On Thursday 05 April 2007 06:11, Will Dyson wrote:
> @@ -525,8 +525,24 @@ static int setup_rx_descbuffer(struct bcm43xx_dmaring
> *ring,
> return -ENOMEM;
> dmaaddr = map_descbuffer(ring, skb->data,
>ring->rx_buffersize, 0);
> - if (dma_mappi
On 4/5/07, Will Dyson <[EMAIL PROTECTED]> wrote:
> From: Will Dyson <[EMAIL PROTECTED]>
Well. Looks like I generated these with a typo in my email. You'd
think I'd learn not to do this stuff late at night
Anyway, this should address the previous comments. It'll always try
GFP_KERNEL first,
From: Will Dyson <[EMAIL PROTECTED]>
When DMA mapping for RX fails because of the limitation, retry the allocation
in ZONE_DMA. When the network stack passes us TX buffers that cannot be mapped
because of the limitation, allocate a bounce buffer in ZONE_DMA and copy the
packet there.
Signed-off-b
On 3/28/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> Er, are you sure? AFAIR all of the K8 CPUs have something called GART IOMMU,
> which is not a "real" IOMMU, but still it can do its job (to a limited extent,
> though).
Current Intel x86_64 chips have no such thing, however.
--
Will Dy
On 3/28/07, Michael Buesch <[EMAIL PROTECTED]> wrote:
> The dma_mask must be honored for _all_ DMA mapping actions without
> exceptions. That's what that mask is for.
As far as I can see, the DMA mapping actions _do_ honor the mask. If
the memory to be mapped is outside the mask (and no IOMMU is
On Thursday, 29 March 2007 00:16, Larry Finger wrote:
> Michael Buesch wrote:
> > On Wednesday 28 March 2007 23:43, Larry Finger wrote:
> As a result, every driver for
> hardware with less than 32-bit DMA addressing has to address (pun
> intended) the problem. We will
> probab
Michael Buesch wrote:
> On Wednesday 28 March 2007 23:43, Larry Finger wrote:
As a result, every driver for
hardware with less than 32-bit DMA addressing has to address (pun
intended) the problem. We will
probably be fighting the problem again when > 4 GB RAM computers become
On Wednesday 28 March 2007 23:43, Larry Finger wrote:
> >> As a result, every driver for
> >> hardware with less than 32-bit DMA addressing has to address (pun
> >> intended) the problem. We will
> >> probably be fighting the problem again when > 4 GB RAM computers become
> >> common and 32 bits
Michael Buesch wrote:
> On Wednesday 28 March 2007 19:42, Larry Finger wrote:
>> Will Dyson wrote:
>>> On 3/24/07, Michael Buesch <[EMAIL PROTECTED]> wrote:
>>>
I _still_ think that this should be fixed in the arch DMA code
and _not_ in every single driver on earth. But I discussed this i
On Wednesday 28 March 2007 19:42, Larry Finger wrote:
> Will Dyson wrote:
> > On 3/24/07, Michael Buesch <[EMAIL PROTECTED]> wrote:
> >
> >> I _still_ think that this should be fixed in the arch DMA code
> >> and _not_ in every single driver on earth. But I discussed this in
> >> the past.
> >
>
On Wednesday 28 March 2007 19:28, Will Dyson wrote:
> On 3/24/07, Michael Buesch <[EMAIL PROTECTED]> wrote:
>
> > I _still_ think that this should be fixed in the arch DMA code
> > and _not_ in every single driver on earth. But I discussed this in
> > the past.
>
> That would be nice. What would
On Wed, 2007-03-28 at 12:42 -0500, Larry Finger wrote:
> We will
> probably be fighting the problem again when > 4 GB RAM computers become
> common and 32 bits are not
> enough to address all of memory.
Not likely, most such machines have an IOMMU.
johannes
signature.asc
Description: This is a
Will Dyson wrote:
> On 3/24/07, Michael Buesch <[EMAIL PROTECTED]> wrote:
>
>> I _still_ think that this should be fixed in the arch DMA code
>> and _not_ in every single driver on earth. But I discussed this in
>> the past.
>
> That would be nice. What would that look like to you? A GFP flag tha
On 3/24/07, Michael Buesch <[EMAIL PROTECTED]> wrote:
> I _still_ think that this should be fixed in the arch DMA code
> and _not_ in every single driver on earth. But I discussed this in
> the past.
That would be nice. What would that look like to you? A GFP flag that
gets memory within the dma_
When the chip is limited to 30bit DMA, allocate RX buffers in ZONE_DMA. When
the network stack passes us TX buffers that cannot be mapped because of the
limitation (with an address > 1GB), allocate a bounce buffer in ZONE_DMA and
copy the packet there.
Signed-off-by: Will Dyson <[EMAIL PROTECTED]
On Friday 23 March 2007 22:24, Will Dyson wrote:
> When the chip is limited to 30bit DMA, allocate RX buffers in ZONE_DMA. When
> the network stack passes us TX buffers that cannot be mapped because of the
> limitation (with an address > 1GB), allocate a bounce buffer in ZONE_DMA and
> copy the pac
17 matches
Mail list logo
