Message-ID: <20150223073009.GE29908@odux.rfo.atmel.com>
Date:	Mon, 23 Feb 2015 08:30:09 +0100
From:	Ludovic Desroches <ludovic.desroches@...el.com>
To:	Guenter Roeck <linux@...ck-us.net>
CC:	Peter Hurley <peter@...leysoftware.com>,
	Pantelis Antoniou <pantelis.antoniou@...sulko.com>,
	<frowand.list@...il.com>, Mark Rutland <mark.rutland@....com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Tony Lindgren <tony@...mide.com>,
	Koen Kooi <koen@...inion.thruhere.net>,
	Nicolas Ferre <nicolas.ferre@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Ludovic Desroches <ludovic.desroches@...el.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Matt Porter <matt.porter@...aro.org>
Subject: Re: [PATCH 2/4] of: DT quirks infrastructure

On Fri, Feb 20, 2015 at 10:48:18AM -0800, Guenter Roeck wrote:
> On Fri, Feb 20, 2015 at 01:09:58PM -0500, Peter Hurley wrote:
> > Hi Guenter,
> > 
> > On 02/20/2015 11:47 AM, Guenter Roeck wrote:
> > 
> > [...]
> > 
> > > I am open to hearing your suggestions for our use case, where the CPU card with
> > > the eeprom is manufactured separately from its carier cards.
> > 
> > I think your use case may be more compelling than two flavors of Beaglebone
> > (one of which is pretty much a dead stick), but it's also less clear what your
> > design constraints are (not that I really want to know, 'cause I don't).
> > 
> > But the logical extension of this is an N-way dtb that supports unrelated SOCs,
> > and I think most would agree that's not an acceptable outcome.
> > 
> With this logic you can pretty much refuse to accept anything new, anywhere.
> Including everything old, for that matter.
> 
> Food can be abused to poison people, therefore no one should be permitted to
> distribute food. Houses can be abused to falsely imprison people, therefore
> no one should live in houses. And don't even start talking about guns.
> Everything can be abused, therefore we should not do anything.
> 
> Discussions about possible abuse are for sure valid, and reducing the potential
> for abuse is a worthy goal, but not as argument to reject a solution for an
> existing and real roblem outright.
> 
> > My thought was that every design that can afford an EEPROM to probe can afford
> > a bootloader to select the appropriate dtb, and can afford the extra space
> > required for multiple dtbs.
> > 
> There are many more use cases where this is simply not the case. Another one,
> for example, is a system where the devicetree is loaded through u-boot using
> tftp. In this case, u-boot would have some information about the hardware
> to request the correct devicetree file, but it may not know about hardware
> variants.
> 
> Sure, one could solve that problem by making u-boot aware of such variants
> and maintaining a large number of dtb files as you suggest. That means,
> however, that there would be that need to maintain all those dtb files
> just to address minor differences, and having modify every piece of the
> system for each new variant. In essence you put a lot of burden on pretty
> much everyone from software to manufacturing to testing, plus possibly
> hardware, just for the purpose of rejecting a relatively simple solution
> for the problem Pantelis' patch set is trying to address.
> 

Other example that show how it becomes a mess. Tell me if we do that in
a wrong way but I don't think.

We have the following source files:
- a dtsi file for the SoC family
- a dtsi file for SoC variant enabling the devices available
- a dtsi file for the CPU module describing components on this module:
  the ethernet phy, the nand flash, etc.
- a dtsi file for the motherboard
- several dtsi files for different kind of display modules
- many dts file for the final board, it includes the SoC variant, the
  CPU module, the motherboard and one of the display module if needed.

At the end we have something like this (from our github, not all these
boards have been sent to the mainline)

arch/arm/boot/dts/sama5d3.dtsi
arch/arm/boot/dts/sama5d34ek_pda7.dts
arch/arm/boot/dts/sama5d36ek_revc_pda7.dts
arch/arm/boot/dts/sama5d31ek.dts
arch/arm/boot/dts/sama5d34ek_revc.dts
arch/arm/boot/dts/sama5d3xcm.dtsi
arch/arm/boot/dts/sama5d31ek_pda4.dts
arch/arm/boot/dts/sama5d34ek_revc_pda4.dts
arch/arm/boot/dts/sama5d3xdm.dtsi
arch/arm/boot/dts/sama5d31ek_pda7.dts
arch/arm/boot/dts/sama5d34ek_revc_pda7.dts
arch/arm/boot/dts/sama5d3xdm_pda4.dtsi
arch/arm/boot/dts/sama5d31ek_revc.dts
arch/arm/boot/dts/sama5d35ek.dts
arch/arm/boot/dts/sama5d3xdm_pda7.dtsi
arch/arm/boot/dts/sama5d31ek_revc_pda4.dts
arch/arm/boot/dts/sama5d35ek_revc.dts
arch/arm/boot/dts/sama5d3xek.its
arch/arm/boot/dts/sama5d31ek_revc_pda7.dts
arch/arm/boot/dts/sama5d36ek.dts
arch/arm/boot/dts/sama5d3xek_pda4.its
arch/arm/boot/dts/sama5d33ek.dts
arch/arm/boot/dts/sama5d36ek_cmp.dts
arch/arm/boot/dts/sama5d3xek_pda7.its
arch/arm/boot/dts/sama5d33ek_pda4.dts
arch/arm/boot/dts/sama5d36ek_cmp_pins_sleep.dtsi
arch/arm/boot/dts/sama5d3xmb.dtsi
arch/arm/boot/dts/sama5d33ek_pda7.dts
arch/arm/boot/dts/sama5d36ek_hdmi.dts
arch/arm/boot/dts/sama5d3xmb_revc.dtsi
arch/arm/boot/dts/sama5d33ek_revc.dts
arch/arm/boot/dts/sama5d36ek_pda4.dts
arch/arm/boot/dts/sama5d3xmb_revc_isi.dtsi
arch/arm/boot/dts/sama5d33ek_revc_pda4.dts
arch/arm/boot/dts/sama5d36ek_pda7.dts
arch/arm/boot/dts/sama5d4.dtsi
arch/arm/boot/dts/sama5d33ek_revc_pda7.dts
arch/arm/boot/dts/sama5d36ek_revc.dts
arch/arm/boot/dts/sama5d4ek.dts
arch/arm/boot/dts/sama5d34ek.dts
arch/arm/boot/dts/sama5d36ek_revc_cmp.dts
arch/arm/boot/dts/sama5d4ek_hdmi.dts
arch/arm/boot/dts/sama5d34ek_pda4.dts
arch/arm/boot/dts/sama5d36ek_revc_pda4.dts
arch/arm/boot/dts/sama5d4ek_pin_sleep_state.dtsi


> Ultimately, no matter what the kernel community ends up doing, Pantelis'
> solution or something similar _will_ find its way into our system.
> I would very much prefer to have the code upstream, but we will carry
> his patches along in our vendor branch if necessary. The functionality
> and its benefits for our development, manufacturing, and testing process
> are way too valuable to ignore, and it actually solves problems for which
> we don't have an acceptable solution today. I would be quite surprised
> if other vendors would not end up doing the same.

We'll probably do the same. Beaglebone is only an example.

> 
> Guenter


Regards

Ludovic
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists