Re: Buffer management in the zr36067 driver

On Sat, 9 Jun 2007, Jean Delvare wrote:
> The maximum order seems to be 10 on x86_64. This is 4 MB. Even if we
> can't get that, being able to get 512 kB or 1 MB would be a significant
> improvement over the current situation. Maybe we can even get 2 or 4 MB
> if we preallocate the buffers on driver load. Arguably, this can be
> seen as a waste of kernel memory, so maybe this should be an option
> rather than the default.

Even a 1MB buffer would be enough to capture a full sized PAL frame in yuyv
format.  All the buffers don't have to be a single contiguous region, just
each individual buffer.  So a 1MB buffer is plenty big, if you can get at
least two of them.

The zr36067 uncompressed DMA is designed for hardware overlay into a video
framebuffer, so it doesn't support non-contiguous memory regions for a
single frame like pretty much all other hardware.  That's why video-buf
isn't any good and allocation the video buffers is so much harder than
other hardware.

> I believe that the driver should not hard-code a memory limit value.
> Instead, it should always try kmalloc (or __get_free_pages), and it
> should fallback to other methods (get_high_mem, bigphys_area) only if
> kmalloc fails.  What do you think?

Sounds like a good idea.  The only problem would be if someone does use the
bigphys_area patch to reserve memory at boot time, they probably want to
use it.  If the kmalloc pool is used, then the bigphys poll will just be
wasted.  It might make sense to try bigphys area _first_ and then if that
fails see if kmalloc will work.

> me.  And it doesn't work for me at least, the largest amount I manage to
> get is 32 kB.  Does this really work for anyone?  I'm surprised it was
> even accepted into the kernel tree.  Shouldn't we remove this from the
> driver?

I just get 64kB with that, I have no idea if it actually works.

> header comment says it implements non-contiguous, PCI-DMA-able buffers
> for video drivers.  Couldn't this be used in the zr36067 driver as well?

Could be used for the compressed capture, since it supports non-contiguous
memory.  I wonder if system with IOMMU resources could work around the
zr36067 contiguous memory requirements?

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/