Freescale Linux BSP review
matt at genesi-usa.com
Mon Dec 20 08:18:21 PST 2010
On Mon, Dec 13, 2010 at 9: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.
The concerns about host memory access via the GPU driver are valid but
unnecessary. The GPU MMU directly intervenes on memory access and can
only modify memory space allocated to the GPU resource - getting data
into this memory requires some extreme manual intervention if not done
by the kernel driver itself; this memory area is set internally by the
platform device resource.. As such (on the i.MX515 at least) the top
64MB of memory reserved for the GPU is the only memory you need to
worry about, and any "corruption" will be limited to invalid API usage
which is also checked with assertions and other protection mechanisms.
Any other "unsecured" memory location such as system RAM cannot be
affected as the GPU MMU will not write or read any other memory than
the defined resource. It is not an outside possibility that you may
abuse the GPU to corrupt graphics RAM... but you can do that with any
GPU even with security checks.
Ownership of the code is dependent on who licensed it. I do not think
Linaro need be so concerned over opensourcing or reimplementing
drivers. The fact that the kernel driver is open source as it is, and
this is by far the most important part. The userspace library is
closed because it is proprietary; and I think it is well outside
Linaro's remit to lobby for opensourcing of proprietary code simply to
meet an esoteric and needless demand for source code access (as it
stands, you can get source code access by signing the usual plethora
of NDAs with the appropriate vendor, as Genesi has done). It is my
understanding that Freescale/AMD and Qualcomm maintain seperate forks
of the driver and do not cooperate on development, and in any case,
Linaro does not include Qualcomm anyway, therefore it is also to my
understanding that this discussion is also beyond Linaro's remit.
Can't we all just be happy that we actually have 3D drivers?
Matt Sealey <matt at genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
More information about the dri-devel