Ryan Underwood <[EMAIL PROTECTED]> 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? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
