ARM topic: Is DT on ARM the solution, or is there something better?

[Thierry Reding]

On Tue, Nov 19, 2013 at 10:27:40AM -0700, Stephen Warren wrote:
> On 11/19/2013 02:35 AM, Thierry Reding wrote:
> > On Mon, Nov 18, 2013 at 10:16:13AM -0700, Stephen Warren wrote:
> >> On 11/18/2013 09:06 AM, Thierry Reding wrote: ...
> >>> Part of my point was that you could possibly still use the same
> >>> IP with only a modified (standard) register interface. That way
> >>> no licensing of third party IP would be needed. You'd only need
> >>> to rewrite parts of the IP to make it look (and behave) like
> >>> the standard one.
> >>> 
> >>> That's exactly how 16550-compatible UARTs work, isn't it? Or
> >>> even the way that USB (EHCI, ...) work. There's a standardize
> >>> register interface, possibly with a way for vendor-specific
> >>> extensions, but the interface itself doesn't need to be
> >>> licensed, so there are no additional costs to supporting the
> >>> standard interface. There are only the advantages of being able
> >>> to reuse a well-tested body of code.
> >> 
> >> Your idea would be great if it could be made to work in
> >> practice.
> > 
> > This wasn't really my idea, so I can't take all the credit for it.
> > =)
> > 
> >> I'm not convinced how possible this would be, without ARM
> >> mandating it in their contractual licensing terms, or large
> >> customers mandating it in order to use SoCs for their flagship
> >> designs.
> > 
> > I don't think ARM mandating this is necessary. In the end it boils
> > down to faster time to market, doesn't it? I mean if you have a
> > device that exposes a standard set of registers and a driver for
> > that standard set already exists, then it's very little work to get
> > the device working with it. You also save a lot of work on
> > validation.
> 
> I get the impression that many silicon vendors simply do what they
> want when there aren't constraints that dictate otherwise. The
> benefits of upstream SW aren't valued by everyone, let alone the
> benefits of the HW equivalent - the standardized registers we're
> talking about. As such, without some force pushing for
> standardization, people won't do it. That force would need to be
> either ARM, or the customers/partners/ecosystem consuming the SoCs.
> 
> And note that we already have drivers in our product kernels (and
> simplified drivers upstream) for all this HW already, so switching
> register interface would actually be more work at least in the short
> term.

Yeah, if this could be made to work I'd expect this to only pay off in
the really long term. Even if people were convinced that this needed to
be done now I suspect that it could easily be a decade before the
benefits could be reaped.

In some ways it would be fundamental shift in how the industry works,
and quite probably not everyone will be convinced to tag along.

> Likely the best way to drive this forward is to talk to our silicon
> engineers and try and drive this through them. If you can persuade
> them, perhaps it can trickle back up to ARM and across other vendors.
> If you as an NVIDIA employee can't persuade the NVIDIA HW designers, I
> don't expect you could persuade other HW vendors:-)

It sounds pretty daunting. I don't feel like I personally have enough
experience or knowledge to drive something like this. Realistically this
would need investigating the myriads of register interfaces in existence
and extract the commonalities into something that could be made to work
on all hardware.

Then again, perhaps higher-level software abstractions could serve as a
good template. After all, the subsystem-level APIs in the Linux kernel
are already catered to supporting most of the hardware out there.

> > The 16550 UART register set wasn't mandated by anyone as far as I
> > know, but still the majority of UART devices implement it. I guess
> > the same is true of EHCI or SDHCI.
> 
> IIUC, the situation is a little different.
> 
> A platform existed that used the 8250/16550. That product got into the
> market first (or created a new market). Others wanted to be compatible
> with the product, so had to implement compatible registers. Thus,
> everyone made their motherboard/chipset UARTs work the same.
> 
> However, with ARM SoCs, there are multiple tens of vendors all
> developing products at once, and even for different markets, so the
> whole "must be compatible with this existing thing" driving force
> simply doesn't exist, simply because there is no one single "existing
> thing". Systems are also larger, and there are many more SW developers
> employed, so there's a bit more ability to deal with different HW too.
> It may not scale infinitely, but probably better than it did 30 years ago.

Perhaps pursuing this isn't such a good idea after all. If things really
ended up going in that direction many of us might turn out unemployed...

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/20131120/9f2f8852/attachment.sig>