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

[thierry.reding@gmail.com (Thierry Reding)]

On Fri, Nov 29, 2013 at 09:42:23AM -0800, Greg KH wrote:
> On Fri, Nov 29, 2013 at 10:37:14AM +0100, Thierry Reding wrote:
> > > > Some of this is a consequence of the push to have the firmware
> > > > minimal. As soon as you say the kernel has to configure the address
> > > > map you've created a big complexity for it..
> > > 
> > > Why the push to make firmware "minimal"?  What is that "saving"?  You
> > > just push the complexity from one place to the other, just because ARM
> > > doesn't seem to have good firmware engineers, doesn't mean they should
> > > punish their kernel developers :)
> > 
> > In my experience the biggest problem here is that people working on
> > upstream kernels and therefore confronted with these issues are seldom
> > able to track the latest developments of new chips.
> > 
> > When the time comes to upstream support, most of the functionality has
> > been implemented downstream already, so it actually works and there's no
> > apparent reason why things should change.
> 
> That's a failure of the companies involved.

Yes, I know.

> > Now I know that that's not an ideal situation and upstreaming should
> > start a whole lot earlier, but even if that were the case, once the
> > silicon tapes out there's not a whole lot you can do about it anymore.
> > Starting with upstreaming even before that would have to be a solution,
> > but I don't think that's realistic at the current pace of development.
> 
> For other companies it is realistic.  I have a whole presentation on
> this, and why it even makes good business sense to do it properly (hint,
> saves you time and money, who doesn't like that?)

I've seen a recording of that presentation. Twice. =)

> > 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.
> > 
> > I am completely convinced that our goal should be to do upstreaming
> > early and ideally there shouldn't be any downstream development in the
> > first place. The reason why we're not there yet is because it isn't
> > practical to do so currently, so I'm very interested in suggestions or
> > finding ways to improve the situation.
> 
> "Practical"?  Heh, other companies know how to do this properly, and
> because of that, they will succeed, sorry.
> 
> It can be done, the fact that ARM and it's licensees don't want to do
> it, doesn't mean it isn't "practical" at all, it's just a failure on
> their part to do things in the "correct" way, wasting time and money in
> the process.

Well, I can't really argue with that, so I'll stop with the whining and
go back to work.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131129/167c3957/attachment-0001.sig>