On Mon, Dec 13, 2010 at 9:30 PM, Jammy Zhou <jammy.zhou@xxxxxxxxxx> wrote: > > > On Tue, Dec 14, 2010 at 10:06 AM, Jerome Glisse <j.glisse@xxxxxxxxx> wrote: >> >> On Mon, Dec 13, 2010 at 9:04 PM, Jammy Zhou <jammy.zhou@xxxxxxxxxx> wrote: >> > >> > >> > On Tue, Dec 14, 2010 at 12:11 AM, Jerome Glisse <j.glisse@xxxxxxxxx> >> > wrote: >> >> >> >> On Mon, Dec 13, 2010 at 10:18 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: >> >> > On Monday 13 December 2010, Jammy Zhou wrote: >> >> >> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij >> >> >> <linus.walleij@xxxxxxxxxx>wrote: >> >> >> >> >> >> > On 11 December 2010 22:41, Arnd Bergmann <arnd@xxxxxxxx> 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 >> > >> > >> >> 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. > > For non-PCI GPU in embedded world, there is no GART concept. Besides, the > GPU MMU is disabled currently for some hardware problem. > In a weird way you lucky ;) Cheers, Jerome Glisse _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
