I don't know enough about the basic requirements for most of the really
interesting cards to be able to say much..
> I see two options: one is to support cards that can do DMA directly. The
> other is to have two pages with one mapped to userspace at a time and
> have the kernel flush the other (usually through the cards FIFO).
>
> Asking for this DMA interface could probably be supported by having an
> ioctl on /dev/fb (using fbcon).
I'd prefer not having /dev/fb be involved at all, more a system-call like
approach that would be in two parts:
- the user would ask for a DMA-able memory region (of some size, possibly
larger than a page, but definitely not much larger than say 16kB).
- the kernel would give the user the area at some specified virtual
address, and return the physical address
With the above you can already make bus-master cards happy completely from
user space (modulo interrupts when they are ready).
In addition, there would be a second part for any cards that actually use
the motherboard DMA engine (which is fairly slow and broken, but the card
designer may not have wanted to do busmastering), which would be more of a
"setup_dma()" system call using the above buffer.
> With modern PCI based cards with proper registers one wouldn't need to
> consider the interface that XAA deals with in any circumstance, since
> the XAA driver would only use the DMA interface to send commands to the
> card.
Right. I would really not like to have the kernel involved very much at
all. With _most_ well designed cards it should be enough for the
application to just have a small private area that it can point the video
card at, and then it probes the video card shared memory (or IO access) to
initiate the bus master cycles.
So with a good card you'd never actually go into the kernel to start up
the DMA - you'd only ask the kernel to allocate the area for you (once, at
startup). After that the user program can do everything on its own.
Note that I'd really like to keep this separate from /dev/fb, because the
DMA issue might be useful for other stand-along things (video grabbers,
scanners, frame-grabbers, audio, high-speed IEEE ports etc).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu