On 01/25/2017 12:27 PM, Dmitry Torokhov wrote: > On Wed, Jan 25, 2017 at 10:44:32AM -0800, Dmitry Torokhov wrote: >> On Wed, Jan 25, 2017 at 06:29:55PM +0000, Mark Brown wrote: >>> On Wed, Jan 25, 2017 at 06:23:20PM +0000, Mark Rutland wrote: >>>> On Wed, Jan 25, 2017 at 08:56:42AM -0800, Furquan Shaikh wrote: >>> >>>>> That is the reason why the recent change to add ACPI support to fixed >>>>> regulators was done >>>>> (https://github.com/torvalds/linux/blob/master/drivers/regulator/fixed.c#L100). >>> >>>> To be honest, I'm surprised this got merged. >>> >>> My understanding was that it was instantiated from another device as an >>> implementation detail of that device, letting it say "this GPIO should >>> be handled as a regulator". >>> >>>> Mark, this was added in this cycle; can we please rip that out for now? >>> >>> If it's instantiated directly we probably should. >>> >>>> We can certainly come up with something that allows drivers to support >>>> both, but trying to do this without updating drivers opens a huge set of >>>> problems. >>> >>> I think there's a reasonable chance that any ACPI specs could be written >>> in such a way as to allow transparent support in Linux, the main thing >>> I'd worry about is naming issues. >> >> So if I am reading this correctly, currently ACPI does not expose power >> supplies directly, but rather ties them to the device power state (D0, >> D3cold, etc). Linux drivers do not usually follow that state model and >> expect to have all their power supplies be given to them and then >> figures out what to do with them itself. Given that, what do we do? Do >> we map only entries from _PR3 so they are available to drivers via >> regulator_get()? Or we ask the standard to add method enumerating all >> supplies? > > For the record, the main issue for the drivers, which is being solved by > exposing power supplies to the driver, is the following: > > 1. We suspend the device. Since there is no regulators the driver > assumes that it will retain it's state upon resume > 2. System goes into some sleep state > 3. System wakes up > 4. Device goes through resume, normally disabling wakeup interrupt and > enabling normal processing > 5. We end up with non functioning device because the firmware actually > cut the power off without the driver knowing anything about it. > > I would really hate to go through _every_ driver and add the following > code to the resume path: > > #if IS_ENABLED(CONFIG_ACPI) > if (acpi_device_was_powered_off_between_suspend_and_now(dev)) { > completely_reinitialize_device(dev); > } > #endif > > Thanks. > Please see Sections 3.2-3.5 (3.6, too, for a broader picture) in the ACPI spec [0] for an overview of ACPI power management. Section 7 of the spec [0] adds the details on how the firmware and OS are to cooperate in managing power. In those sections, ACPI defines a PowerResource object, aka a power supply of some flavor. ACPI devices are then connected to that power resource. So, the spec may already have what you need defined. Further, the code in drivers/acpi /device_pm.c and drivers/acpi/power.c may handle the situations described -- I believe that's their intent, at any rate. If the ACPI ASL is written properly, I don't think the device driver would have to add the code shown above; it would just be handled via the acpi driver and ASL. The ACPI model is specifically designed so that drivers don't have to know these sorts of things, so that the hardware and firmware underneath the OS can change over time without having to change the OS -- the OS just needs to know how to talk to ACPI. But, to the point of some of the other discussion on the thread, this ACPI sort of power management is a very, very different model than DT so that intertwining the two models is highly unlikely to work, IMHO. [0] http://www.uefi.org/specifications -- version 6.1, specifically. -- ciao, al ----------------------------------- Al Stone Software Engineer Red Hat, Inc. ahs3@xxxxxxxxxx ----------------------------------- -- 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
