Freescale Linux BSP review

Matt Sealey matt at
Mon Dec 20 09:41:01 PST 2010

On Mon, Dec 20, 2010 at 11:17 AM, Jerome Glisse <j.glisse at> wrote:
> On Mon, Dec 20, 2010 at 11:18 AM, Matt Sealey <matt at> wrote:
>> On Mon, Dec 13, 2010 at 9:18 AM, Arnd Bergmann <arnd at> wrote:
>>> On Monday 13 December 2010, Jammy Zhou wrote:
>>>> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij <linus.walleij at>wrote:
>>>> > On 11 December 2010 22:41, Arnd Bergmann <arnd at> 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.
> Security check of radeon GPU are advance enough to even catch and
> forbid overwriting other process video memory (this is more or less
> true depending on the generation you are looking at).
>> 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?
> So here you are advocating that we should accept any open source code
> inside the kernel just because it's open source and we love open
> source ? This is not how i understand the linux kernel project, we
> should not accept any open source driver that just add new api that we
> can't audit, test or understand. From my point of view any driver &
> new API should be introduced to support open source userspace. If GPU
> manufacturer don't want to open source their stack that's their issue
> but they should live with the pain of not having upstream kernel
> either. I believe, here i am just reformulating Dave point.

The code may need improvement but that's no reason to run around
saying everything needs to be open sourced, and that the solution is
in fact to reverse engineer the thing rather than accept it as the
current solution. Given how long nouveau and later Radeon card support
has taken in real life, even with full documentation from AMD, I
seriously doubt Linaro are going to be the ones to somehow make the
world change for OpenSource embedded GPU graphics. Linaro doesn't
exist just to spend all their time undermining the status quo for the
sake of it.

I also do not think that it is at all kernel policy to disallow kernel
drivers which do not have opensource userspace components. In fact,
Linus Torvalds begs to differ on this matter. The fact of the matter
is that the driver lives now, Qualcomm have it in their upstream,
Freescale have it in their upstream, Linaro are going to fetch from
that. It doesn't need to go all the way to stable, because people can
compile their own kernels if they want (and Linaro is there provide
the source to do that with the best interoperability with the silicon
vendors' chips as possible).

Well, good luck reverse engineering the GPU in the next 5 years,
because I suspect that is how long it is going to take.

I would love to see someone actually, physically prove that using the
libraries provided by vendors (Freescale's BSP, or from Genesi or so)
and the kernel driver committed, that you CAN actually cause rampant,
unsecured graphical corruption, before a discussion goes around to
those vendors about spending the next 6 months mired in legal work
trying to find all the potential IP sources and seek approval to
publish that code as opensource or perform rewrites. So far I don't
see that, just a "I'm fairly sure" from a trusted person. This is not
peer review, it's pure opinion. Go see how well you can break it,
submit a bug report, the vendors might fix it in the closed source
libraries or publish a kernel driver update to suit your needs.

Matt Sealey <matt at>
Product Development Analyst, Genesi USA, Inc.

More information about the dri-devel mailing list