Hi Tony,
On Oct 31, 2012, at 11:43 PM, Tony Lindgren wrote:
> * Pantelis Antoniou <panto@xxxxxxxxxxxxxxxxxxxxxxx> [121031 14:38]:
>>
>> There a a whole bunch of conflicting capes. There's no
>> way to instantiate them together. They must be instantiated
>> only after their EEPROMs are read and they are matched
>> to their corresponding cape drivers.
>
> You don't need to instantiate the capes during __init,
> you need to just instantiate the omap internal devices
> which are always there in the hardware. These internal
> devices just need to be set to state = "disabled" until
> they are used.
>
If you set the device's node state to disable the device
doesn't get registered; i.e. the device's probe method will not be
called.
The devices are instantiated by the call to
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
in omap_generic_init() (arch/arm/mach-omap2/board-generic.c)
Which for each child of the root node will call of_platform_bus_create
which in turn will call of_platform_device_create_pdata.
First check in there is
if (!of_device_is_available(np))
return NULL;
of_device_is_available() will return 0 in any case status is neither
"okay" or "ok".
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.
Since the bus drives of things like i2c & spi must be disabled if not
used by any cape, they are "disabled" by default, and are activated when
referenced by a cape.
In the file drivers/capebus/capebus-driver.c, there are two functions.
The first, capebus_of_platform_device_enable() will check if the referenced
device node is disabled, and after enabling it (with capebus_of_device_node_enable())
will call of_platform_device_create(), but now this time the instantiation
will be successful.
The problem is that now, we're way past the point in the boot sequence
that omap_build_device has been freed; calling the probe method will now lead
to a crash.
> The capes themselves should not have anything to do
> with omap_hwmod or omap_device, they just contain
> external connectors, regulators, LCD panels etc.
>
> To your capebus the omap internal devices should look
> like just regular struct device entries.
>
> Regards,
>
> Tony
Regards
-- Pantelis
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
