* Paul Walmsley <paul@xxxxxxxxx> [111216 12:20]: > Hi > > On Fri, 16 Dec 2011, Tony Lindgren wrote: > > > * 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. > > Sure, if there's some replacement way for drivers to call integration > functions. Right now there's no substitute, AFAIK. So far no one who has > written that platform_data function pointers should not be used has been > able to come up with a concrete alternative. > > > 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. > > There seems to be some misunderstanding here... > > This patch falls into one of two cases, as discussed further in > > http://marc.info/?l=linux-omap&m=132402667320943&w=2 > > If the device never needs to run in smart-idle wakeup mode, then what you > wrote is right -- there's no need for a new device->integration function > call here. The HWMOD_SWSUP_SIDLE flag should work fine, and no > new platform_data function pointers are needed. > > However, if the device does occasionally need to run at different levels > of "idle", as several of our devices do, then some new device->integration > function calls are indeed needed. PM runtime doesn't provide an interface > for varying gradations of "idle". This was discussed with Rafael and > Magnus a few months ago at LinuxCon Japan, and Rafael indicated at the > time that he felt those should be implemented by some other mechanism, > outside PM runtime. This makes some sense since it's not clear right now > (to me, anyway) how to implement something like this in a completely > generic way. > > ... > > Generally speaking, there are several integration functions that we either > call now via platform_data function pointers, or will need to call in the > future, from drivers. Even after the device tree conversion. Adjusting > the idle state that an IP block can enter when it enters PM runtime idle > is one set. Implementing integration-level device reset while the device > is enabled is another -- PM runtime (rightly in my view) doesn't have > anything to do with that. > > > 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. > > As written here: > > http://marc.info/?l=linux-omap&m=132402415520208&w=2 > > there seem to be a few different options for long-term approaches. But > implementing these will take quite some time and discussion. Depending on > what's done, the solution might touch a lot of code. In the meantime we > have bugs that should be fixed. Dealing with them now with platform_data > function pointers has the nice side benefit that it provides visibility to > the remaining operations that do need to cross the device->integration > boundary. > > So in case it was unclear, I'm not advocating platform_data function > pointers are the long-term answer. But they seem to be an important step > in the transition to whatever mechanism appears next, since no alternative > seems to exist. OK, sounds like there's no "official" way to do a bus level reset of a device right now from the device itself. So let's keep the platform_data around for that until we have some generic way of doing the reset from driver. > > 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. > > Hmm, I don't quite understand this part. You're referring to > non-executable data here? Right, the .data can contain knowledge how to reset device aaaa compared to similar device bbbb, but sounds like that won't help here as we don't have a way of doing it cleanly from the driver. 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
