Re: driver: ddi_dma_alloc_handle issue
From: Philip Brown (phil+s3_at_bolthole.no-bots.com)
Date: 08/12/03
- Next message: Philip Brown: "Re: SOL licensing confusion"
- Previous message: Robert: "Solaris CDE Command for reading mail"
- In reply to: Bruce Adler: "Re: driver: ddi_dma_alloc_handle issue"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 12 Aug 2003 19:49:04 GMT
On Tue, 12 Aug 2003 10:19:45 GMT, bruce.NxOxSxPxAxMx.adler@acm.org wrote:
>
>"Philip Brown" <phil+s3@bolthole.no-bots.com> wrote in message news:slrnbjgtrb.en1.phil+s3@bolthole.com...
>> I'm trying to do exactly what I said above:
>> "Allocate memory **suitable** for DMA use".
>>
>> eg: a (small) contiguous chunk of memory, that I can get a physical
>> address to, and lock down in memory.
>
>Are you implying that your bus-mastering capable device can't do
>scatter-gather DMA but needs buffers a lot larger than a single
>page?
In some cases, yes.
Some video cards can do
scatter/gather, and some can't. the MGA cards, for example, cannot.
"A lot larger" is an overstatement. The bigger the better. But
64k, or 128k, or ideally 1 meg, is a lot better than just a single page,
for speed purposes.
>If there's real hardware involved then you must have a driver that
>attaches to the appropriate node in the device tree.
On x86, /dev/xsvc doesnt work that way. It CANT work that way.
Which is presumably why it is allowable on x86.
>In other words, it's impossible to create a generic-one-size-fits-all
>DMA setup function that will always work in all cases
I dont need "fits-ALL", I need "fits-most"
>> >What's wrong with allocating your buffers in the "vanilla" kernel memory
>> >address space?
>>
>> Cant do DMA to that, now can you?
>
>You most certainly can.
>
>In general, if it's memory allocated via ddi_dma_mem_alloc()
>then you just bind it to the handle using ddi_dma_addr_bind().
>
>Or, if it's random kernel virtual memory (i.e., memory your driver didn't
>allocate via ddi_dma_mem_alloc()) then you use the physio() interface.
>
>Or, in the case you seem to be trying to handle, if it's memory you want
>the user application to be able to access via the mmap() system call, then
>you have to plan ahead and pre-allocate the memory via the ddi_umem_alloc().
>
>There are chapters and sections in the WDD that describe each of these
>situations and how to code them.
There is no other way I have found, to provide user-level programs with
BOTH a mmapable address space, AND physical address information, for
locked down physical memory. ddi_umem_alloc does not allow physical
page info to be given to the user.
If you believe there is a way to do so, then please spell it out with
details for providing both sides up to the user.
>There's no such thing in Solaris as user-level *device* drivers.
Sure there is. There are a very famous set of user-level device drivers,
which are contained in packages like SUNWffbw, SUNWm64w, and given the
user-visible front-end name of "Xsun".
It is a user level process that directly controls the hardware.
If you want to call it something else, that's fine, but give me a valid
technical category name for it.
>It seems to me that the root problem is that you're backing into all
>sorts of pseudo driver, and/or root nexus, DMA hacks because you've
>(wrongly) convinced yourself that it's necessary to completely ignore
>how Solaris wants you to actually handle driver binding.
>....
>Why not just bind the driver correctly and avoid all the other
>hassles of trying to do DMA or buffer allocation without using
>the correct devinfo pointer.
You're ignoring the fact that I CANNOT BIND to the hardware, because
another driver is already bound to it, and I cant replace the driver that
is already bound to it.
Define "bind the driver correctly", given the above constraint
>The potential for conflicts between the Solaris console drivers and the
>Xserver are unavoidable if both programs are going to attempt to access
>the exact same hardware registers. You can't make the console driver
>to get out of your way unless it already has hooks to let you make that
>happen. In other words, there are no existing DDI functions that
>specifically make it possible to enforce "cooperation" on some random
>driver.
However, since the "driver" in this case is Xsun, or XFree86, there are
existing user-level hooks that "enforce cooperation".
Or more specifically, to tell the X server to not mess with the hardware,
while an extension module tweaks things.
>If you've got a driver that either maps device memory to user space,
>or kernel allocated DMA (or umem) buffers to device space (and user
>space), there's nothing to prevent you from implementing in that
>driver an ioctl that passes to the user application the details about
>the mapping that's been created for a specific hardware device
>instance and the specific set of buffers.
Yes there is. The fact that there is no API to get the physical address
information for memory allocated by ddi_umem_alloc.
The user can mmap it. but they have no way of telling what the physical
addreses is, and there is no way documented in WDD for a normal kernel
driver to find out that information and pass it through an ioctl either.
> I haven't bothered
>to look recently but I could have swore that there were in fact existing
>SPARC drivers that support video overlays and that make those features
>accessible to user applications via well specified ioctl() interfaces.
>Isn't that almost exactly what you're trying to do?
That is irrelevant. I already have a functioning driver that maps video
card memory to the user. That works fine, but does not cover the
requirements for the DMA needs of the target projects. The need is to have
DMA access to system RAM, not device memory.
One very large reason for this, is that writing to device memory from
the system CPU is too slow.
Another show-stopper reason, is that DMA to/from device memory is
NOT ALLOWED by the DMA engine for some cards.
FYI: the kernel-level code is at
http://www.bolthole.com/solaris/drivers/dmamem.tar
-- http://www.blastwave.org/ for solaris pre-packaged binaries with pkg-get Organized by the author of pkg-get [Trim the no-bots from my address to reply to me by email!] S.1618 http://thomas.loc.gov/cgi-bin/bdquery/z?d105:SN01618:@@@D http://www.spamlaws.com/state/ca1.html
- Next message: Philip Brown: "Re: SOL licensing confusion"
- Previous message: Robert: "Solaris CDE Command for reading mail"
- In reply to: Bruce Adler: "Re: driver: ddi_dma_alloc_handle issue"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
