Freescale Linux BSP review

Jerome Glisse j.glisse at gmail.com
Mon Dec 13 18:35:10 PST 2010


On Mon, Dec 13, 2010 at 9:30 PM, Jammy Zhou <jammy.zhou at linaro.org> wrote:
>
>
> On Tue, Dec 14, 2010 at 10:06 AM, Jerome Glisse <j.glisse at gmail.com> wrote:
>>
>> On Mon, Dec 13, 2010 at 9:04 PM, Jammy Zhou <jammy.zhou at linaro.org> wrote:
>> >
>> >
>> > 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
>> >> > 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


More information about the dri-devel mailing list