status of DMA usage for system ram to video ram pixmap copies

Dodji Seketeli dodji at
Mon Feb 25 13:14:49 CET 2008


In my previous email at,
I introduce this DMA related task.

In the "What has been done" paragraph, I taked about how the DMA was
done, in bullet point 3/.

I have also said there that instead of doing DMA N times - N being
the number of lines of a given pixmap - I should instead do the DMA
transfer of the pixmap data once, to an offscreen area in video ram
that I would call a bounce buffer, then I should use the 2D engine of
the GLAMO chip to do the proper copy of the DMA from the bounce buffer
to the actual proper destination on visible video ram. And all this
needs to be done in the kernel, of course.

So that is what I tried to do last week but I failed. Why ?

Actually, there are two ways to drive GLAMO chip. You can either
write values to some registers, or you can submit
commands to a command queue. The commands just tell a command
processor to assign values to registers. Problem is that sometimes, you
have to use the former way, sometimes the later. You are never sure
when to use which. But one thing is sure, it is _way_ easier to use the
former way.

So to be quick, I though I would just write values to the registers
myself directly instead of using the command processor. And it appeared
that does not work. I really have to use the command processor, like
what I do in the Xglamo server, in userland.
The gotcha is that it is a lot more work as the command processor needs
to be initialised etc, and its use is a bit cumbersome.

Also, as it needs to be initialised with certain values that are
dynamic, the initialisation needs to happen only once. So if the kernel
does the initialisation, the Xglamo server must not (re)do the
initialisation afterwards. Instead, Xglamo needs to ask the kernel to
do the command processor initialisation on his behalf.

So I guess this is what I need to investigate this week. I hope it will
work and I can get this (hopefully) faster DMA scheme working at
last :-)

Thank you for your attention.


OpenedHand Ltd.
Unit R, Homesdale Business Center / 216 - 218 Homesdale Road /
Bromley / BR1 2QZ / United Kingdom.  Tel,fax: +44 (0) 208 819 6559

Expert Open Source For Consumer Devices -

More information about the openmoko-devel mailing list