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

[Linus Walleij]

On Wed, Jan 9, 2013 at 12:48 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Wednesday 09 January 2013, Linus Walleij wrote:

>> 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.

Right, so the picture is more complex.

Each logic module / plug-in card spawn a set of struct amba_device
primecells.

Each of them need clocks and interrupts. These are then cascaded
from the clocks/irqs on the main board.

>> 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.

So when taking into account that the daugther boards are not just
spawning themselves but a number of devices in turn, I thin
it's the only way...

I will get to tackle this when I've converted the Integrator PCI to DT
and removed the Integrator boardfiles.

Yours,
Linus Walleij