BTW, I don't think it was explicitly in the phoronix article, but the actual source for omapdrm is at drivers/staging/omapdrm.
cheers, Jesse On Tue, May 15, 2012 at 8:03 PM, Jesse Barker <jesse.bar...@linaro.org> wrote: > OK, so with respect to that article, we've been working with our > members to provide KMS drivers for their SoCs. The results are in > varying states of completeness and availability, but I would expect > that to improve in the coming cycles. You should be able to find DRM > drivers for pandaboard (omapdrm: see > http://www.phoronix.com/scan.php?page=news_item&px=MTA5MDg) and origen > (exynos - this driver is already upstream in drivers/gpu/drm/exynos) > with patches out for review on those all the time on the dri-devel > list. Snowball support has not quite made it to igloocommunity, but > that should be in progress. > > It's a work in progress, but we are making that progress all the time. > > I hope this helps. > > cheers, > Jesse > > On Tue, May 15, 2012 at 7:45 PM, Ilyes Gouta <ilyes.go...@gmail.com> wrote: >> Hi Jesse, >> >> Here: http://www.phoronix.com/scan.php?page=news_item&px=OTI0MA and >> http://lists.freedesktop.org/archives/wayland-devel/2011-March/000855.html >> >> It doesn't propose a unified interface for 2D accelerators on SoCs, though. >> >>> There's nothing I'm aware of that would define what you are asking >>> (apart from the Xserver's EXA framework which certainly isn't new or >> >> Yes, but that's heavily geared towards X11. >> >>> in the kernel). Even the interfaces exported by DRM require user >>> space code to orchestrate them (i.e., no kernel acceleration in the >>> purest sense). >> >> It just that it's kind of common that SoCs have separate IPs for >> handling 2D and 3D acceleration, not like PC world. And client code >> could live on both kernel and user lands, hence a need for arbitration >> and so on. >> >> I was just asking, out of curiosity. >> >> -Ilyes >> >> On Tue, May 15, 2012 at 6:11 PM, Jesse Barker <jesse.bar...@linaro.org> >> wrote: >>> Can you point out the article you're referring to that mentioned the >>> Linaro project? >>> >>> There's nothing I'm aware of that would define what you are asking >>> (apart from the Xserver's EXA framework which certainly isn't new or >>> in the kernel). Even the interfaces exported by DRM require user >>> space code to orchestrate them (i.e., no kernel acceleration in the >>> purest sense). >>> >>> cheers, >>> Jesse >>> >>> On Tue, May 15, 2012 at 5:59 PM, Ilyes Gouta <ilyes.go...@gmail.com> wrote: >>>> Hi Christian, >>>> >>>> Yes dma-buf is part of the picture, but rather if any work has been >>>> done to define an interface for the device itself, not the buffers. >>>> >>>> I do know that these are mostly managed from user-space for >>>> performance reasons, however I was curious to see if anything has been >>>> in the works for kernel-space (kind of drm but for much more tailored >>>> for 2D blitters). >>>> >>>> -Ilyes >>>> >>>> On Tue, May 15, 2012 at 3:14 PM, Christian Robottom Reis >>>> <k...@linaro.org> wrote: >>>>> On Mon, May 14, 2012 at 10:18:17PM +0100, Ilyes Gouta wrote: >>>>>> I've previously read (probably on Phoronix) that Linaro is working out >>>>>> a 'standard' kernel interface for 2D blitters IPs as commonly found on >>>>>> SoCs. >>>>>> >>>>>> Has it ever been the case? If yes, are there any >>>>>> documentation/references online? >>>>> >>>>> I wonder if you are talking about dma-buf and the other collection of >>>>> work around Unified Memory Management: >>>>> >>>>> https://wiki.linaro.org/OfficeofCTO/MemoryManagement >>>>> >>>>> It's not really specific for 2D blitter IPs, but it does define how >>>>> memory can be allocated and shared between different devices, >>>>> particularly between the CPU, display controller and GPU IP. >>>>> -- >>>>> Christian Robottom Reis, Engineering VP >>>>> Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 >>>>> Linaro.org: Open Source Software for ARM SoCs >>>> >>>> _______________________________________________ >>>> linaro-dev mailing list >>>> linaro-dev@lists.linaro.org >>>> http://lists.linaro.org/mailman/listinfo/linaro-dev _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
