Freescale Linux BSP review
jammy.zhou at linaro.org
Mon Dec 13 18:04:03 PST 2010
On Tue, Dec 14, 2010 at 12:11 AM, Jerome Glisse <j.glisse at gmail.com> wrote:
> On Mon, Dec 13, 2010 at 10:18 AM, Arnd Bergmann <arnd at arndb.de> wrote:
> > On Monday 13 December 2010, Jammy Zhou wrote:
> >> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij <
> linus.walleij at linaro.org>wrote:
> >> > On 11 December 2010 22:41, Arnd Bergmann <arnd at arndb.de> 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
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dri-devel