linuxconsole-dev

DMA/IRQ based hardware support.

[James S. <jsi...@tr...>]

The ruby tree has finished the moved away from using spinlocks to a
sempahore for the console lock. This means we can now have fbdev drivers
that use DMA :-) We can now write fbdev drivers using DMA. Thank you.

Re: [Linux-fbdev-devel] DMA/IRQ based hardware support.

[Scott A M. <sam...@co...>]

James Simmons wrote:
> 
> The ruby tree has finished the moved away from using spinlocks to a
> sempahore for the console lock.

Has this issue been discussed on this list?

The sempahore gives better support for threads/tasks?


> This means we can now have fbdev drivers
> that use DMA :-) We can now write fbdev drivers using DMA. Thank you.

Please pardon my ignorance...

When/why would you want to use DMA? Do all the drawing on CPU memory and
then DMA
the block to graphics memory? It seems that approach would get in the
way of acceleration.

Using DMA inside the acceleration routines? It seems on average you
would spend more time making the tests to decide to use DMA and
programming the DMA then it would be to write the pixels directly.

It seems most operations on fb would involve "small" rectangles that do
not use large contigous blocks of memory. Console scrolling would be
able to take advantage of it...

Thanks for any comments.


-- 
Scott A. McConnell

Re: [Linux-fbdev-devel] DMA/IRQ based hardware support.

[James S. <jsi...@tr...>]

> > The ruby tree has finished the moved away from using spinlocks to a
> > sempahore for the console lock.
> 
> Has this issue been discussed on this list?

Yes. Especially with the i810 fbdev driver. It can only work as a DMA/irq
based device. The console spinlock was preventing this. Turning off IRQs
prevented the hardware from working.

> The sempahore gives better support for threads/tasks?

?? Do you from a userland prespective?
 
> When/why would you want to use DMA? Do all the drawing on CPU memory and
> then DMA
> the block to graphics memory? It seems that approach would get in the
> way of acceleration.

Because one this is the only way some devices work. Second DMA often gives
better performance and it usually is much easier to program. For most
hardware you can send accel commands threw the DMA engine to draw things.
 
> Using DMA inside the acceleration routines? It seems on average you
> would spend more time making the tests to decide to use DMA and
> programming the DMA then it would be to write the pixels directly.

No. Fbcon needs only one DMA buffer. Allocate a chunck of memory and mark
it for DMA use. Then feed data into it. We do have to make sure that we
don't flood the DMA engine with to many commands. This can be controled
by the size of the buffer and with some conditional scheduling code. We do
the same thing for FIFOs and we also do a busy loop polling the accel
engine to see if it is busy. Often with DMA hardware you can feed it data
while the accel engine is busy and it gets processed as soon as the accel
engine is done with the previous command. 
 
> It seems most operations on fb would involve "small" rectangles that do
> not use large contigous blocks of memory. Console scrolling would be
> able to take advantage of it...

Correct. The new fbdev api is based around this idea.