On Fri, Feb 18, 2011 at 23:58, Rafael J. Wysocki <rjw@xxxxxxx> wrote: > On Friday, February 18, 2011, Rabin Vincent wrote: >> On Thu, Feb 17, 2011 at 20:55, Rabin Vincent <rabin@xxxxxx> wrote: >> > This will solve the platform vs AMBA bus, but shouldn't we really be >> > aiming for consistent behaviour between these and the other busses such >> > as I2C and SPI, which are also usually commonly used on the same >> > platforms and are using GENERIC_PM_OPS? >> > >> > Should we be auditing all platform drivers and then switch platform to >> > the GENERIC_PM_OPS? >> > >> > Or should the two points (1) and (2) be not handled in the bus at all >> > and be left to individual drivers (in which case we should audit i2c and >> > spi and change GENERIC_PM_OPS)? >> >> How about something like the below? If we have something like this, we >> can just switch platform to GENERIC_PM_OPS and add the >> pm_runtime_want_interaction() (or something better named) call to the >> i2c and spi drivers using runtime PM. > > Why don't we make platform_bus_type behave along the lines of generic ops > instead? At least drivers/spi/omap2_mcspi.c, drivers/video/sh_mobile_lcdcfb.c and drivers/watchdog/omap_wdt.c are some pm_runtime-using drivers which seem to do different things in their runtime vs normal suspend/resume routines, so forcing platform into the active-on-resume behaviour of the generic ops may make some use cases impossible. Conversion of more OMAP drivers to runtime pm appears to be ongoing so I'd imagine we'd be seeing more of this. Perhaps Kevin or Magnus will have a comment here. The same thing applies to AMBA drivers. Looking at the i2c drivers using runtime pm in comparison, they all seem to be using straightforward UNIVERSAL_PM_OPS-style code with the runtime and the system sleep doing the same things. So maybe we do need to treat platform/AMBA different from the I2C/SPI group? -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
