[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1004072207390.18281-100000@netrider.rowland.org>
Date: Wed, 7 Apr 2010 22:10:17 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: Robert Hancock <hancockrwd@...il.com>
cc: Daniel Mack <daniel@...aq.de>, <linux-kernel@...r.kernel.org>,
Pedro Ribeiro <pedrib@...il.com>, <akpm@...ux-foundation.org>,
Greg KH <gregkh@...e.de>, <alsa-devel@...a-project.org>,
<linux-usb@...r.kernel.org>
Subject: Re: USB transfer_buffer allocations on 64bit systems
On Wed, 7 Apr 2010, Robert Hancock wrote:
> >> The problem is appearantly the way the transfer buffer is allocated in
> >> the drivers. In the snd-usb-caiaq driver, I used kzalloc() to get memory
> >> which works fine on 32bit systems. On x86_64, however, it seems that
> >> kzalloc() hands out memory beyond the 32bit addressable boundary, which
> >> the DMA controller of the 32bit PCI-connected EHCI controller is unable
> >> to write to or read from. Am I correct on this conclusion?
> >
> > That seems like the right answer. You are correct that an EHCI
> > controller capable only of 32-bit memory accesses would not be able to
> > use a buffer above the 4 GB line.
> AFAIK, the driver shouldn't have to worry about this at all. When the
> buffer gets DMA-mapped for the controller, the DMA mapping code should
> see that the device has a 32-bit DMA mask and either bounce or IOMMU-map
> the memory so that it appears below 4GB.
That's true. It would of course be more efficient for the buffer to be
allocated below 4 GB, but it should work okay either way. Daniel, do
you have any idea why it fails?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists