Re: [RFC PATCH] Documentation: devicetree: add description for generic bus properties

[Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>]

On Fri, Nov 29, 2013 at 01:13:59PM +0000, Dave Martin wrote:
> On Fri, Nov 29, 2013 at 09:57:03AM +0000, Russell King - ARM Linux wrote:
> > On Fri, Nov 29, 2013 at 10:37:14AM +0100, Thierry Reding wrote:
> > > There's a large gap between how fast new SoCs are supposed to tape out
> > > and the rate at which new code can be merged upstream. Perhaps some of
> > > that could be mitigated by putting more of the complexity into firmware
> > > and that's already happening to some degree for ARMv8. But I suspect
> > > there's a limit to what you can hide away in firmware while at the same
> > > time giving the kernel enough information to do the right thing.
> > 
> > One of the bigger issues which stands in the way of companies caring
> > about mainstream support is closed source IPs like VPUs and GPUs.
> > 
> > If you have one of those on your chip, even if the kernel side code
> > is already under the GPL, normally that code is not "mainline worthy".
> > Also, as the userspace code may not be open source, some people object
> > to having the open source part in the kernel.
> > 
> > So for customers to be able to get the performance out of the chip,
> > they have to stick with having non-mainline kernel.
> > 
> > At that point, why bother spending too much time getting mainline
> > support for the device.  It's never going to be fully functional in
> > mainline.  It doesn't make sense for these SoC companies.
> 
> Putting effort into upstream support for something that is only relevant
> to GPUs (or VPUs) does look less valuable for us right now, unless it
> encourages people to start posting more GPU/VPU code upstream, and we
> know there are other blockers there.

I think you miss my point.  Manufacturers want their chips to be useful
to people, and they want all the features on their chip to be usable.
They don't want something which sort-of works but has chunks of support
for various IP that they spent time integrating not supported.

So they have two options: either they develop a kernel out of mainline
which supports everything, which isn't subject to the whims of mainline
kernel developers breaking it all the time because of lack of testing,
or they decide that they're not going to support everything and work on
mainline only.

The problem with the latter is they're explicitly saying to some
customers that they're on their own as far as that's concerned, and
they're not prepared to do that: customers are the people who pay the
bills, remember, and you don't turn them away without good reason.

For example, I doubt that SolidRun would've picked Freescale's IMX6
for their next board unless there was support for the GPU and VPU in
some kernel somewhere.  Remember, not everyone is interested in producing
yet another toy board which can only really be used as a NAS.  Some want
accelerated graphics and hardware assisted video decode today too, and
want to sell products based on those features.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html