Freescale Linux BSP review

[Dave Airlie]

>
> 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?

Can't you just use Windows? why bother with open source at all if you
are willing to give up.

My point which people keep missing is that graphics stacks are a
single entity, that span kernel and userspace, one cannot exist
without the other, and there are interfaces that join them.

I will accept kernel code to initialise chips, set modes, do all that,
I won't accept new ioctl interfaces to userspace that cannot be
validated and have no use other than to serve the closed user blob.
The reason for this is the burden of maintaining the code/interfaces
falls onto the kernel community when we accept code. Now if we can no
longer validate that the interfaces work without running a binary blob
or we cannot change the interfaces without having to lobby some other
entity to change their blob then maintaining that code in the upstream
kernel is pointless.

I have no problem with closed 3D drivers I just want the manufacturers
to understand that if you want to go down that path you get to keep
both halves.

Dave.