Freescale Linux BSP review

[Jerome Glisse]

On Mon, Dec 20, 2010 at 11:18 AM, Matt Sealey <matt at genesi-usa.com> wrote:
> 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.

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.

Cheers,
Jerome Glisse