On Tuesday, September 10, 2013 10:35:22 PM Mark Brown wrote: > On Tue, Sep 10, 2013 at 10:04:21PM +0200, Rafael J. Wysocki wrote: > > On Tuesday, September 10, 2013 05:13:21 PM Mark Brown wrote: > > > > OK, that is very much not the model which embedded systems follow, in > > > embedded systems the driver for the device is fully in control of its > > > own power. It gets resources like GPIOs and regulators which allow it > > > to make fine grained decisions. > > > There are platforms where those resources are simply not available for > > direct manipulation and we need to use ACPI methods for power management. > > > Now, since those methods are used in pretty much the same way for all I2C > > devices, we add a PM domain for that to avoid duplicating the same code in > > all of the drivers in question (patch [2/2]). Does that make sense to you? > > It doesn't seem like a particular problem, but the existing usage does > need to be preserved for the systems that use it so things like having > auto as the default and updating the drivers seem like they're needed. > > > > If we're starting to get a reasonable number of buses following the same > > > pattern it seems like we're in a position to start > > > We need that for exactly 3 buses: platform (already done), I2C and SPI. > > > No other bus types are going to use ACPI this way for PM, at least for the > > time being, simply because PCI, USB and SATA/IDE have their own ways of doing > > this (which are bus-specific) and the spec doesn't cover other bus types > > directly (it defines support for UART, but we don't have a UART bus type). > > > Moreover, because PCI and USB use ACPI for PM in their own ways, moving that > > thing up to the driver core would be rather inconvenient. > > That only applies to the power domains though, what Mika was saying was > that the process for enabling runtime PM (just drop a reference) also > becomes easier with this method regardless of anything else - that makes > sense to me as something we might want to end up with so do we want to > just move towards making that a default? Possibly. :-) At least I don't see any fundamental obstacles ... -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
