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

[Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>]

On Wednesday 09 January 2013, Linus Walleij wrote:
> On Wed, Jan 9, 2013 at 9:11 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> > On Tue, 08 Jan 2013, Arnd Bergmann wrote:
> >> I don't remember the details unfortunately. Lee should be the one who can find out.
> >> IIRC there was at least a single integeger number on them.
> >
> > Not as far as I can remember. There was (is?) a crude method of
> > identifying UIBs, but attempting to obtain certain I2C lines and
> > testing which ones were accessible. However, if there is an issue
> > with I2C, the wrong UIB was 'probed'.
> 
> Right, so the UIBs had different GPIO expanders on some I2C addresses,
> so we attempt to communicate with the expander to see if it's board type A,
> and if it doesn't respond it's deemed to be board type B.
> 
> This is the code:
> arch/arm/mach-ux500/board-mop500-uib.c

Ok, no idea what I was confusing it with then.

> Compare this other case: the Integrator has pluggable daughterboards,
> (called LMs, logic modules) and in that case we have specific registers
> to detect them, and register the daughter board on this specific bus
> that Russell came up with in arch/arm/mach-integrator/lm.c,
> the actual board detection is in arch/arm/mach-integrator/integrator_ap.c:
> 
> static void __init ap_init(void)
> {
>         unsigned long sc_dec;
>         int i;
> 
>         platform_device_register(&cfi_flash_device);
> 
>         sc_dec = readl(ap_syscon_base + INTEGRATOR_SC_DEC_OFFSET);
>         for (i = 0; i < 4; i++) {
>                 struct lm_device *lmdev;
> 
>                 if ((sc_dec & (16 << i)) == 0)
>                         continue;
> 
>                 lmdev = kzalloc(sizeof(struct lm_device), GFP_KERNEL);
>                 if (!lmdev)
>                         continue;
> 
>                 lmdev->resource.start = 0xc0000000 + 0x10000000 * i;
>                 lmdev->resource.end = lmdev->resource.start + 0x0fffffff;
>                 lmdev->resource.flags = IORESOURCE_MEM;
>                 lmdev->irq = IRQ_AP_EXPINT0 + i;
>                 lmdev->id = i;
> 
>                 lm_device_register(lmdev);
>         }
> 
>         integrator_init(false);
> }
> 
> In this case I think the autodetect is so nice that device tree probing
> is mostly pointless. If it wasn't for the fact that we get a
> cross-depenency to defined interrupts and clocks and whatever that
> are coming from the device tree. Which is where DT shows its
> all-or-nothing face.

Well, the extension bus above can easily be represented as a single device
with four interrupts and four memory ranges. The child devices don't
have to show up in DT at all, since they can be detected, but the detection
mechanism should be there. This is the same as PCI devices, where we have
to describe the host controller, but not the add-on cards.

> So to get an elegant DT probing in this case I *guess* the right thing
> to do is to dynamically add nodes to the device tree from the board
> code, or have all alternatives inside the DT marked "disable" and then
> mark them as "okay" from the board code by modifying the DT at
> runtime.

That would also work, but I think the other way is simpler.

	Arnd