[haiku-development] Re: 64 bit physical addresses
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 22 Jun 2010 22:27:13 +0200
On 2010-06-22 at 18:36:42 [+0200], Siarzhuk Zharski <zharik@xxxxxx> wrote:
> Am 22.06.2010 16:03, schrieb Ingo Weinhold:
> > There are a few drivers for hardware that supports 64 bit addresses (like
> > HDA, AHCI, some network drivers),
>
> What is the "usual criterium" that hardware supports 64 bits addressing?
> The size of corresponding registers?
That's the minimum criterion, obviously. The respective hardware specs might
add other criteria. E.g. 64 bit support could be optional indicated by a
register flag.
> > I wasn't quite sure what to do what to do with several drivers for USB
> > devices (usb_serial, usb_audio, etc.). They allocate memory with
> > B_CONTIGUOUS -- usually a sign for memory for DMA -- but the physical
> > addresses are never retrieved as far as I have seen. I might have
> > overlooked something, though.
>
> Frankly speaking this part of usb_serial was just reverse-engineered
> from the Dano usb_acm so I never thought why it is done in this way.
> :-\ May be it was related to some restrictions from old BeOS USB
> support implementation? Regarding usb_audio - isn't it that buffers
> returned to Media Server during answer on B_MULTI_GET_BUFFERS ioctl must
> be physically contiguous?
I wouldn't know why. The media server -- any userland code really --
couldn't care less how memory is mapped physically. So unless the buffer is
passed to another driver somehow, I don't think a contiguous allocation is
necessary.
> In case this is not required - can I jsut
> allocate those buffers by call of malloc and throw away all this
> area-related stuff in my implementation of usb_audio?
I guess so.
CU, Ingo
Other related posts:
