Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2

[Tony Lindgren]

* Jason Kridner <jkridner@xxxxxxxxxxxxxxx> [121101 11:52]:
> My apologies for starting a new thread, but I don't have this thread
> in my Inbox.
> 
> http://www.spinics.net/lists/linux-omap/msg81034.html
> 
> Tony Lindgren wrote:
> 
> >* Pantelis Antoniou <panto@xxxxxxxxxxxxxxxxxxxxxxx> [121031 15:02]:
> >>
> >> So when device's node is 'disabled' of_platform_device_create_pdata()
> >> will not create the device.
> >>
> >> Now, of course it is possible to re-trigger the platform's probe method
> >> to be called, and in fact I do so in the capebus patches.
> >
> >You should fix this in generic way then rather than working
> >around it in capebus. The same problem exists changing
> >between different functionality for the shared pins,
> >let's say between USB pins and UART pins if you want a
> >serial debug console on some phone.
> 
> The current capebus solution goes a long way to fixing a huge issue
> for BeagleBone users and I don't understand what seems to be a
> push-back on principle. On BeagleBone capes, these conflicts cannot be
> resolved early.
> 
> Do you have suggestions on some more generic method? It seems to me
> the proposed capebus approach strikes a good balance.

Having it all behave like a hotpluggable bus makes sense.

But the way to sort it out is to have all the omap internal
devices defined in a .dts file and have them set initially
with status = "disabled" in the .dts.

Then you just need a function dynamically change the kernel
internal device tree to enable and disable devices dynamically
so the dev entries get created and driver probe can happen.

Sure that means that some hwmod and omap_device functions
can't be __init any longer, but there should not be any
need to call hwmod and omap_device functions directly from
capebus.

If you want to take it one step further, you can also add
new capes to the kernel internal device tree dynamically
as you may have different pinmux and omap internal device
configurations on the capes.

Regards,

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