Re: Freescale Linux BSP review

[Arnd Bergmann <arnd@arndb.de>]

On Tuesday 21 December 2010 18:29:56 Matt Sealey wrote:

> > The only thing that is currently being enforced is that no interfaces enter
> > the mainline kernel that rely on closed source user space. Once something
> > is merged in mainline, you are generally free to write code under any
> > license you want against that interface.
> 
> Yes, this is basically it: the problem here is that Alan is
> stipulating that as a copyright holder in the kernel he has a big
> problem with merging the code, but in fact as the merge proposal only
> includes GPL code, nobody has a leg to stand on except on moral
> grounds, and policy grounds. There is no legal issue here. It is not
> going into mainline, fair enough. What I am curious about is why did
> Linaro push it to dri-devel in the first place? I think the concept of
> taking a driver from a BSP and then just FLINGING it at mainline is
> not responsible in the first place. Isn't it enough to go into the
> Linaro tree, discretely and quietly? Then we can have a discussion
> about what to do about it within Linaro.

That's not how Linaro works. I forwarded it to the DRI list
to get technical input on what would be needed to have it merged
in mainline. If things were looking better on this front, we could
get it on track for mainline merging, and backport it into the Linaro
tree as soon as it hits linux-next. This is obviously not going
to happen unless we can find at least a subset of the code without
legal problems that we can clean up enough for integration.
 
> Frankly, this discussion (besides the sidetrack to the non-existant
> legal issues) did pop up a major problem in the possibility of
> unifying the IPU, dual GPU and other graphics subsystem frameworks on
> the i.MX processor line, and potentially others too (TI's LCDC and PVR
> graphics) in that DRM/DRI security policy will forbid them (in the
> form of David Arlie complaining) from sharing the same memory area,
> MMUs on or off. This actually means all 2D, 2D acceleration, 3D
> acceleration and DMA between the units requires bounce buffers and
> some overly complicated memory copying between memory areas for them
> to interoperate. I think TI hit this problem trying to get a texture
> from the DSP to the GPU to render it to a texture and came up with an
> awful (closed source :) method of ioctls and so on to achieve it. I
> had an idea to solve it using DRM and GEM but it's been shot down in
> concept now... what's the point? It'll never get into mainline.

Don't give up so early, there are a number of separate problems to
solve here. As far as I understand, the desire among many people
is to have the 3D acceleration hidden. Fine, so we can still do
accelerated 2D with free drivers and shouldn't be bothered by the
fact that we don't get 3D. There is a lot of work to do on proper
2D drivers and getting them into mainline still, so let's focus
on that and do a proper implementation for as many chips as possible.

By the time that is done, we may well have one or more manufacturers
willing to work with us on 3D support as well.

	Arnd