* Paul Walmsley <paul@xxxxxxxxx> [111216 00:41]: > On Fri, 16 Dec 2011, Tomi Valkeinen wrote: > > > On Fri, 2011-12-16 at 01:27 -0700, Paul Walmsley wrote: > > > On Fri, 16 Dec 2011, Tomi Valkeinen wrote: > > > > > > > But with DT we can't use func pointers in platform_data either, right? > > > > > > In the future, if someone wants to run a platform_data-less kernel, > > > they'll have to come up with a replacement mechanism for these. Several > > > replacements have been proposed internally, such as having an > > > omap_bus/omap_device for devices with OMAP-specific integration, but right > > > now there are more pressing crises to deal with... > > > > Ok. Benoit was telling me not to use pdata, so I thought it's a hard > > rule for DT. He didn't give me a clear alternative, though =). > > As far as I know, we've got no other choice. And if we don't add these, > then not only will current code be broken, but when the time comes to > convert away from using platform_data function pointers, then no one will > know what functions should be exposed from the integration code for the > driver to call. There really should not be any need for platform_data with device tree. Idling a device should be done with pm_runtime calls. Then the bus code should idle the right device, in this case using the hwmod calls. Most of the platform_data function pointers can be replaced with Linux generic calls for regulator framework etc. If some frameworks are missing, then that's obviously a problem that should be addressed. Different devices can be handled with a combination of compatible flag + data. For example, take a look at drivers/tty/serial/of_serial.c and note how the of_platform_serial_table has a .data pointer for each different device. Regards, Tony -- 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
