On Mon, Jun 10, 2013 at 7:24 PM, Dave Airlie <airlied@xxxxxxxxx> wrote: >>> >>> That makes the driver just be a dumb scanout only driver. Sorry, >>> that *really* does not interest me one bit, because the CPU doing >>> framebuffer accesses is pig slow. >> >> Well, yes that is basically what I am saying, unless we can find a >> different way (dmabuf? if there is some way to pass it through the >> blob bits you don't have src code for?) >> >> The problem is that we really can't merge something upstream that lets >> you dma to arbitrary physical address. Maybe in staging, perhaps? Or >> otherwise if there is no other way, I hope someone will at least pick >> up the modesetting parts of it and get that merged upstream. The rest >> of the driver is looking pretty good, and I think it would be useful >> to have upstream. > > Totally what he said. > > upstream shouldn't be restricted by the bad decisions of others, and > adding security bypasses is one of them. > > I'd like to see all the ARM based drivers based on CMA if it can meet > their requirements afaiu CMA has issues w/ changing cache attributes of pages on older architectures like Russell is using. Although perhaps on older arm CMA should just be a straight carveout pool and not try to recycle the unused pages. At least then it would be the same API for the drivers. BR, -R > and using close to standard GEM/dma-buf interfaces. Otherwise it'll be > come an unmaintainable > nightmare for everyone, but mostly for me. > > Merging the base dumb KMS driver, then working out acceptable ways to > provide the extra > features is definitely the nicest way to do things. > > Dave. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
