On Thu, 2012-03-15 at 07:32 -0500, Rob Clark wrote: > On Thu, Mar 15, 2012 at 3:46 AM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > > On Wed, 2012-03-14 at 10:06 -0500, Rob Clark wrote: > > > >> > Well, as I said, it's not an issue for me and from my side it can be > >> > improved later. > >> > >> yeah, when CMA is actually merged, there are a few other things I'd > >> like to do to, incl converting omapfb over to use CMA and remove > >> omap_vram.. but I guess those will be other patches. > > > > Right, I just realized CMA is not in the kernel, nor does it seem to be > > in the linux-next. Is there a reason why you want it already merged? > > Wouldn't it be easier to get it in only when it can actually be used. > > Especially if there's room for improvement. > > Some folks are already pulling CMA into product kernels for various > reasons.. keeping this w/ #ifdef CONFIG_CMA guards seemed like it > would make their life a bit easier. > > But if people feel strongly about it, I can strip that out. Well, I wouldn't say "feel strongly", but... I think the mainline kernel should have code only for the mainline kernel, not for some custom kernels. And the code is not testable in any way, not even compilable. I think all code going in should be tested and compiled. Also, if the CMA code is not in, who says it won't change. Perhaps the CMA function won't even exist in the version going into mainline. Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
