Bug#356458: [tbm@cyrius.com: Re: Bug#356458: linux-2.6: please include bigphysarea patch]
Ryan Underwood <nemesis@icequake.net> wrote:
>
>
> On Mon, Apr 24, 2006 at 09:09:39PM -0700, Andrew Morton wrote:
> >
> > I don't know what to suggest, really. I don't think that adding complexity
> > to MM to support rare and broken hardware is likely to be welcome.
>
> Like I said, it's hardly rare hardware. DC10plus is a very popular
> capture card, and similar to LinuxMediaLabs LML33 which requires the
> same patch (in a Linux-branded product no less). Lack of SG-DMA is not
> a new problem either:
> http://www.ussg.iu.edu/hypermail/linux/kernel/9901.3/0129.html
> http://uwsg.ucs.indiana.edu/hypermail/linux/kernel/0012.2/0899.html
>
> And users are being misled and in for a surprise:
> http://seb.france.free.fr/linux/mirodc10.html
> "v4l_bufsize=2048 indicates the size of the reserved bigphys buffer, it's
> enabled by default in Debian kernels (CONFIG_BIGPHYS_AREA=y), so all you
> need to do is to add to your append line in /etc/lilo.conf a
> bigphysarea parameter with the buffer size, this way the kernel will
> reserve this amount of memory as video buffer."
>
> bigphysarea was a good enough solution for Debian to ship at one time;
> unfortunately, the current Debian kernel maintainers believe the patch
> should be merged upstream instead (I Cc: them on this mail), while
> upstream argues with the previously happy users that the patch is badly
> designed and their hardware is broken besides. I'm mostly kidding
> there, but don't you agree that this would be a frustrating situation
> for a non-technical user? I'm not arguing that bigphysarea is a good
> solution, since I'm incompetent to judge its merits within the context
> of the kernel design (and parts of the patch do appear dodgy at a
> glance), but it is currently the only solution unless we figure out
> where to go from here.
I only see a quuery about bigphysarea maybe once per year.
> > What are the requirements here? How much physically contig memory? Are
> > there any bus addressing limitations on it?
>
> 2 to 4MB depending on the size of the framebuffer (realistically,
> 720x480x24bpp should be the upper limit, 640x480x24bpp for square pixel
> hardware). I have no idea wrt your second question, but I believe that
> contiguous physical memory from the frame grabber's DMA base address is
> the only requirement. The developers at mjpeg.sourceforge.net know the
> hardware far better than me, since I'm just a user of that project.
> Would a dialog with Ronald help you decide what to do?
We already have infrastructure for managing and allocating large
physically-contiguous hunks of memory: arch/*/mm/hugetlb.c. On x86 that
operates in 2MB hunks (non-PAE) and 4MB hunks (PAE).
Perhaps we could hook into there to get the needed memory?
Reply to: