Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager

[Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>]

On 21:35 Mon 07 Jan     , Arnd Bergmann wrote:
> (Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc)
> 
> On Monday 07 January 2013, Tony Lindgren wrote:
> > > 
> > > At the end of the line, some kind of hardware glue is going to be needed.
> > > 
> > > I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw
> > > in the beagleboard), it is a bit premature to think about making it overly
> > > general, besides the part that are obviously part of the infrastructure 
> > > (like the DT overlay stuff).
> > > 
> > > What I'm getting at, is that we need some user experience about this, before
> > > going away and creating structure out of possible misconception about the uses. 
> > 
> > IMHO stuff like this will be needed by many SoCs. Some examples of similar
> > things for omaps that have eventually become generic frameworks have been
> > the clock framework, USB OTG support, runtime PM, pinmux framework and
> > so on.
> > 
> > So I suggest a minimal generic API from the start as that will make things
> > a lot easier in the long run.
> 
> I agree. The ux500 platform already has the concept of "user interface boards",
> which currently is not well integrated into devicetree. I believe Sascha
> mentioned that Pengutronix had been shipping some other systems with add-on
> boards and generating device tree binaries from source for each combination.
> 
> Ideally, both of the above should be able to use the same DT overlay logic
> as BeagleBone, and I'm sure there are more of those.
I'm looking for this also as on at91 sama9x5ek and sam9cn12ek and the
sama5d3xek, we have 1 wire eeproms to detect the boards (motherboards and
daugther boards)
where we have 1 1-wire per board and cpu boards so we can detect everything
and have it's revision and more information

we already have barebox that detect the 1-wire but we need the same handling
in the kernel

Best Regards,
J.
> 
> 	Arnd
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss