investigating DMA based pixmap migration in Xglamo

[Dodji Seketeli]

Hello,

I have been investigating the use of DMA to transfer pixmap from system
ram to the video memory of the glamo chip, on gta02.

Problem statement
=================

The bus that interconnects the glamo GPU to the CPU of the s3c2442 chip
is very slow. Some measurements of the throughput when memcpy-ing data
from system ram to the video ram showed that goes at 30Mbytes/sec,
whereas doing copies in the system ram goes at around 130Mbytes/sec, if
not higher.

Kaa acceleration architecture we are using allows us to use hardware
capabilities to accelerate the transfer of pixmaps from system ram to
video ram. That transfer is called pixmap migration in X lingo.

On the other hand, the s3c2442 SoC has a DMA module that can perform
data copies without using the processor. In our case, using that DMA
module would not help us go faster than 30MB/sec because that speed is
a bus limitation. It will however (hopefully) free the processor to do
something else during the transfer.

What is needed
==============

So we need the framebuffer driver to expose entry points to perform
pixmap copies using the DMA module of the s3c2442 chip. That entry
point would then be called from withing the Xglamo server to perform
the pixmap migrations.


What has been done
===================

I spent the last week understanding the s3c2442 DMA module and kernel
api. I started putting together an implementation of a DMA based pixmap
copy. You can find the patch I have written attached to bug
http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1234 .

There are a few gotchas in that patch, so here is what it does:

1/ it creates a new blocking ioctl (called
FBIO_GLAMO_UPLOAD_PIXMAP_TO_VRAM) to the framebuffer device driver.
That ioctl is meant to copy a pixmap that resides in system ram to a
destination in video ram.

2/ the pixmap is first copied in an in-kernel buffer that is DMA
friendly. The DMA transfer will then copy the pixmap from this
in-kernel buffer to the destination, in vram. The ultimate
implementation should get rid of this copy to in-kernel DMA friendly
buffer. I needed to this for now, for the sake of simplicity, to get
things going, and have a chance to have the whole chain working first.

3/ the pixmap is then tranfered to vram, _line by line_ using DMA.
The line by line is important to notice here because it is bad
performance wise. But as pixmap copy must be done inherently line by
line, there is no easy way to that for now. Ultimately though, I should
be using a bounce buffer in offscreen vram. A bounce buffer is a buffer
allocated in offscreen (non visible) vram. The pixmap data would be
bulk copied in there first. Then, when that is done, the driver will
use the glamo blitter to do the proper copy of the pixmap (line by
line) to the actual final destination in vram. That way, the DMA won't
be done line by line, and the processor won't be used to do the copy
either.

4/ I was obliged to hack the s3c24xx DMA api a bit to make it support
the type of DMA transfer I needed. Actually there are two types of DMA
transfer supported by the s3c2442 module: software mode, and hardware
mode. In the software mode, the software basically triggers the
transfer, whereas in the hardware mode, it is the device where the data
is transfered to (or from) that triggers the transfer. That requires a
special wiring between the device and the s3c2442 chip.
In the case of the glamo chip though, from an s3c2442 DMA module
perspective, accessing vram is like accessing normal memory, so there
is not special wiring in place to do hardware more DMA. We must then do
software mode DMA. Unfortunately, software mode DMA was not really
supported by the s3c24xx DMA api that is in the kernel right now. So I
hacked it a bit to support it. That is in the patch attached to the bug
I referred to earlier; look in the file
linux-2.6.24/arch/arm/plat-s3c24xx/dma.c.

5/ I wrote a test application named test-glamo-dma to test/debug the
whole thing outside of X. Its OE package source is also attached to the
bug.

What needs to be done
======================

Well, continue hacking on this and make it actually usable from an
Xglamo perspective. When that is done, make Xglamo use it, and see if
it is fast enough.


That's all folks.

Thanks for reading so far :-)

Dodji.

-- 
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 - http://www.openedhand.com