Freescale Linux BSP review

[Jerome Glisse]

On Wed, Dec 22, 2010 at 6:02 AM, Konstantinos Margaritis
<markos at genesi-usa.com> wrote:
> On 22 December 2010 09:51, Matt Sealey <matt at genesi-usa.com> wrote:
>> Okay I hereby refrain from legal comments.
>>
>> In any case, this code has passed legal at Freescale and AMD *AND*
>> Qualcomm. It would not be GPL if it has not been vetted (and it took
>> them a year to get to this point).
>
> It appears that this discussion ended up on phoronix.com [1], with an
> air of hostility towards Genesi and Matt for no good reason.
>
> I don't know whose idea was that, but it's certainly of very bad taste
> and helps very little to the discussion. Matt poses real questions and
> issues we -as a company producing ARM products- face all the time.
> Admittedly the technical reasons for not including the kernel-space
> driver into mainline presented by Dave Airlie are correct and very
> down-to-earth. But IMHO, *this* should be the starting point to
> continue the discussion, instead of immediately rejecting this driver.
> Is there *any* way that problem posed by Dave could be solved, perhaps
> by throwing the ball to the ARM vendor companies to provide just a
> small extra part of the code needed to do API checks and therefore
> ensuring the kernel guys CAN actually do their work as they like?

It's not enough to provide a toy program/library that just call into
the new kernel API, you really need to provide a full open source use
case that does achieve somethings using the new kernel API you are
introducing. It's the only way we can possibly evaluate the new API.

Open source GPU kernel API are a pain to design and i can tell you
that if i had liberty to change them i would do that a lot until
finding the best one (nouveau is in happy situation here and they are
more than right to wait until they are completely satisfied with the
API before freezing it).

> As for the philosophical problems, well, I'm sure everyone here
> understands that the situation of ARM graphics in the kernel is in no
> way comparable to Intel or Nvidia/ATI chipsets, they had totally
> different starting points. ARM came from the embedded market where it
> thrived for many years with the exact same licensing rules that we all
> would like to abolish in just a few months, where at the same time we
> "swallowed" the fact that it took Intel and ATI/AMD - forget nvidia,
> nv-obfuscated driver IN the kernel for YEARS? really? - many years to
> accept mainline opensource development. And even Intel with all their
> experience made a complete mess of things using the latest cpus.

No body is saying AMD or Intel were fast to jump into open source,
doesn't mean that ARM ecosystem can't do it faster than AMD or Intel
did.

> I *really* do appreciate Linaro and the effort from ARM and the
> relevant vendors towards open source enablement, and Genesi has proven
> that by donating ~50 ARM based netbooks and smarttops to Linaro
> developers at Linaro at UDS -and around ~40 units to other projects
> including Debian and Gentoo -and we intend to give more in the future.
> We know the process and how it works, just as well as everyone here
> does actually. But we also have to be pragmatic. An ARM based
> solution/product with no long-term support from the kernel side will
> find it very hard to survive indeed. I strongly believe that, half a
> solution is better than no solution, and it can also serve a purpose
> until a proper full solution appears. It also does show a leap of good
> faith from the FOSS side, and one which ARM companies will have to
> follow soon.
>
> So, if by chance anyone really expects ARM licensees to do 180 degrees
> change in philosophy overnight, I obviously cannot speak for them, but
> IMHO, that is not bound to happen. It will probably happen in a few
> years but only by discussion and collaboration, seriously not by
> dealing with absolutes. Denying even the smallest step backwards from
> the side of the FOSS community is not a victory, it's a downright
> failure of the community side to actively support and push ARM -based
> devices as an alternative Linux desktop and portable solutions
> (netbook etc).
>
> My 2c.
>

Cheers,
Jerome Glisse