DMA ...

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
User avatar
kmtdk
Member
Member
Posts: 263
Joined: Sat May 17, 2008 4:05 am
Location: Cyperspace, Denmark
Contact:

DMA ...

Post by kmtdk »

Hello
I have startede to make a dma driver.
but i got one 1 question:
how to map the device to a dma chanel, do i have a "list" to go forward, or how do i do that ?
( by saying "list" i mean the defaults, an exempel : soundblaster is normaly located at chanel 1, floppy 2. )

KMT dk
well, what to say, to much to do in too little space.
when it goes up hill, increase work, when it goes straight, test yourself but when going down, slow down.
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re: DMA ...

Post by Brendan »

Hi,
kmtdk wrote:how to map the device to a dma chanel, do i have a "list" to go forward, or how do i do that ?
( by saying "list" i mean the defaults, an exempel : soundblaster is normaly located at chanel 1, floppy 2. )
How do you solve the same problem for I/O ports and IRQs?

I was going to write a lot of stuff about resource detection (using ACPI, PCI, ISA Plug & Play, manual probing, configuration files, etc to determine I/O ports, IRQs, memory mapped I/O areas in the physical address space, DMA channels), but then I thought about it and started wondering why you care if all you're doing is writing a driver for the ISA DMA controller...

Basically there's only 2 ways of doing it:
  • a) the kernel trusts the drivers and the drivers figure out what they need access to. In this case any driver can ask for access to any DMA channel (as long as the DMA channel isn't already in use by something else).
    b) the kernel doesn't trust the drivers. In this case the kernel (or something acting on behalf of the kernel that the kernel does trust) needs to find out which DMA channels a driver is allowed to access; and the DMA driver just asks the kernel if someone is allowed to access the DMA channel or not.
In both of these cases, the DMA driver itself doesn't need to determine who can access which DMA channels. Or to put it another way: the OS's security policies are implemented at a higher level, and it's these security policies (or the lack of security policies in some cases) that determine who can and can't use each DMA channel (and potentially, which physical address ranges they can access via. DMA transfers if they do have permission to use DMA channels).


Cheers,

Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
User avatar
Combuster
Member
Member
Posts: 9301
Joined: Wed Oct 18, 2006 3:45 am
Libera.chat IRC: [com]buster
Location: On the balcony, where I can actually keep 1½m distance
Contact:

Re: DMA ...

Post by Combuster »

...now if the IOMMU was standard issue... :wink:
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
User avatar
bewing
Member
Member
Posts: 1401
Joined: Wed Feb 07, 2007 1:45 pm
Location: Eugene, OR, US

Re: DMA ...

Post by bewing »

In the very olden days, some boards had to be specifically jumpered for a particular DMA channel -- but even then, it only took 2 jumpers to select any 8 bit, or alternatively any 16 bit DMA channel (depending on the card type).
Post Reply