>-------- Оригинално писмо -------- >От: Tomi Valkeinen >Относно: Re: OMAPFB: CMA allocation failures >До: Ивайло Димитров >Изпратено на: Сряда, 2013, Октомври 30 14:19:32 EET > >I really dislike the idea of adding the omap vram allocator back. Then >again, if the CMA doesn't work, something has to be done. > If I got Minchan Kim's explanation correctly, CMA simply can't be used for allocation of framebuffer memory, because it is unreliable. >Pre-allocating is possible, but that won't work if there's any need to >re-allocating the framebuffers. Except if the omapfb would retain and >manage the pre-allocated buffers, but that would just be more or less >the old vram allocator again. > >So, as I see it, the best option would be to have the standard dma_alloc >functions get the memory for omapfb from a private pool, which is not >used for anything else. > >I wonder if that's possible already? It sounds quite trivial to me. dma_alloc functions use either CMA or (iirc) get_pages_exact if CMA is disabled. Both of those fail easily. AFAIK there are several implementations with similar functionality, like CMEM and ION but (correct me if I am wrong) neither of them is upstreamed. In the current kernel I don't see anything that can be used for the purpose of reliable allocation of big chunks of contiguous memory. So, something should be done, but honestly, I can't think of anything but bringing VRAM allocator back. Not that I like the idea of bringing back ~700 lines of code, but I see no other option if omapfb driver is to be actually useful. Regards, Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
