<div class="gmail_quote">On Tue, Dec 14, 2010 at 10:06 AM, Jerome Glisse <<a href="mailto:j.glisse@gmail.com">j.glisse@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div><div></div><div class="h5">On Mon, Dec 13, 2010 at 9:04 PM, Jammy Zhou <<a href="mailto:jammy.zhou@linaro.org">jammy.zhou@linaro.org</a>> wrote: > > > On Tue, Dec 14, 2010 at 12:11 AM, Jerome Glisse <<a href="mailto:j.glisse@gmail.com">j.glisse@gmail.com</a>> wrote: >> >> On Mon, Dec 13, 2010 at 10:18 AM, Arnd Bergmann <<a href="mailto:arnd@arndb.de">arnd@arndb.de</a>> wrote: >> > On Monday 13 December 2010, Jammy Zhou wrote: >> >> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij >> >> <<a href="mailto:linus.walleij@linaro.org">linus.walleij@linaro.org</a>>wrote: >> >> >> >> > On 11 December 2010 22:41, Arnd Bergmann <<a href="mailto:arnd@arndb.de">arnd@arndb.de</a>> wrote: >> >> > >> >> > * amd-gpu -- a single but huge driver for the GPU. As is normally the >> >> >> case with GPU drivers, we can expect long discussions >> >> >> before it will get considered for mainline >> >> >> 4 patches >> >> >> 98 files changed, 278321 insertions(+), 0 deletions(-) >> >> >> >> >> > >> >> > Just out of curiosity, following the discussion between Dave Airlie >> >> > and Codeaurora this summer re GPU driver shims. >> >> > >> >> > Is the AMD GPU exposing all functionality in its kernel driver or >> >> > is there some userspace blob somewhere with lots of e.g. GL >> >> > goodies? >> >> > >> >> All the functionality for the kernel driver of AMD GPU Z430/Z160 (now >> >> belongs to Qualcom) is exposed. But we need accompanied userspace >> >> library to >> >> call these functionality (buffer management, command submission, ...). >> > >> > Who owns these components? If it's closed source, the only options we >> > have are lobbying for complete release of the specs for a >> > reimplementation >> > or reverse-engineering the drivers, which may at least get easier with >> > a user space driver than it would be with a kernel driver. >> > >> > Until there is a solution with an open source user space part, I would >> > suggest that the driver better be dropped from the Freescale BSP and >> > we should at least not waste time reviewing it. >> > >> > Arnd >> >> From a quick look it also seems that the API exposed to userspace >> would allow easy abuse of the GPU to access any system ram. There is a >> reason we do expensive command checking in the other amd gpu driver >> (drivers/gpu/drm/radeon/*cs.c files) > > No, the memory used by the GPU is reserved at boot time, so I think there is > no such a problem. > >> >> Cheers, >> Jerome > > </div></div>This isn't about what's reserved, this is about GPU capacity, if the GPU is isolated through an IOMMU and the GPU can't reprogram it then fine. But if not, then it's easy to abuse packet to reprogram the GPU GART (either by reprogramming GART register or by overwritting GART table) to point to any system ram. </blockquote><div> For non-PCI GPU in embedded world, there is no GART concept. Besides, the GPU MMU is disabled currently for some hardware problem. </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Cheers, Jerome </blockquote></div>