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

[Pantelis Antoniou]

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