On Nov 23, 2011, at 14:31, Michal Nazarewicz wrote: > On Wed, 23 Nov 2011 20:30:30 +0100, Jean-Francois Dagenais <jeff.dagenais@xxxxxxxxx> wrote: >> I am maintaining a kernel for an embedded product. We have an FPGA >> acquisition device interfaced through PCI-e on different intel platforms. >> The acquisition device needs an extra large physically contiguous memory >> area to autonomously dump acquired data into. > > [...] > >> We are doing another incarnation of the product on an Atom E6xx which has >> no such IOMMU and am looking into ways of allocating a huge chunk of ram. >> Kind of like integrated gfx chips do with RAM, but I don't have the assistance >> of the BIOS. > > One trick that you might try to use (even though it's a bit hackish) is to > pass ram=### on Linux command line where the number passed is actual memory > minus size of the buffer you need. Other then that, you might take a look > at CMA (CMAv17 it was sent last week or so to linux-mm) which in one of the > initialisation steps needs to grab memory regions. Thanks for that, I am looking into it. Looks like it can do what I want. Are there any mainline merge plans? Unless I am mistaken, because of SWIOTLB, only x86_32 is supported, correct? Since I want to allocate the buffer once at startup, then keep it until shutdown, can you suggest a simpler, less flexible alternative? (other than the boot args method which I consider a fallback plan). > > -- > Best regards, _ _ > .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o > ..o | Computer Science, Michał “mina86” Nazarewicz (o o) > ooo +----<email/xmpp: mpn@xxxxxxxxxx>--------------ooO--(_)--Ooo-- Thanks for helping! -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href