Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1566241 > unrolled thread

[PATCH 0/7] Implement generic regulator constraints parsing for ACPI and OF

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/7] Implement generic regulator constraints parsing for ACPI and OF Furquan Shaikh <furquan@chromium.org> - 2017-01-25 01:10 +0100
    [PATCH 6/7] drivers/gpio: Add and export gpiod_lookup[_index] Furquan Shaikh <furquan@chromium.org> - 2017-01-25 01:10 +0100
      Re: [PATCH 6/7] drivers/gpio: Add and export gpiod_lookup[_index] Linus Walleij <linus.walleij@linaro.org> - 2017-01-26 16:30 +0100
    [PATCH 7/7] drivers/regulator: Initialize regulator init data for ACPI regulators Furquan Shaikh <furquan@chromium.org> - 2017-01-25 01:10 +0100
    Re: [PATCH 0/7] Implement generic regulator constraints parsing for  ACPI and OF Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> - 2017-01-25 13:30 +0100
    Re: [PATCH 0/7] Implement generic regulator constraints parsing for  ACPI and OF Mark Brown <broonie@kernel.org> - 2017-01-25 13:50 +0100
      Re: [PATCH 0/7] Implement generic regulator constraints parsing for  ACPI and OF "Rafael J. Wysocki" <rafael@kernel.org> - 2017-01-25 14:00 +0100
        Re: [PATCH 0/7] Implement generic regulator constraints parsing for  ACPI and OF Furquan Shaikh <furquan@chromium.org> - 2017-01-25 18:00 +0100
          Re: [PATCH 0/7] Implement generic regulator constraints parsing for  ACPI and OF Mark Brown <broonie@kernel.org> - 2017-01-25 19:30 +0100
          Re: [PATCH 0/7] Implement generic regulator constraints parsing for  ACPI and OF Mark Rutland <mark.rutland@arm.com> - 2017-01-25 19:30 +0100
            Re: [PATCH 0/7] Implement generic regulator constraints parsing for  ACPI and OF Mark Brown <broonie@kernel.org> - 2017-01-25 19:40 +0100
              Re: [PATCH 0/7] Implement generic regulator constraints parsing for  ACPI and OF Mark Rutland <mark.rutland@arm.com> - 2017-01-25 19:40 +0100
                Re: [PATCH 0/7] Implement generic regulator constraints parsing for  ACPI and OF Mark Brown <broonie@kernel.org> - 2017-01-25 20:00 +0100
                  Re: [PATCH 0/7] Implement generic regulator constraints parsing for  ACPI and OF Mark Rutland <mark.rutland@arm.com> - 2017-01-25 20:40 +0100
              Re: [PATCH 0/7] Implement generic regulator constraints parsing for  ACPI and OF Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-01-25 19:50 +0100
                Re: [PATCH 0/7] Implement generic regulator constraints parsing for  ACPI and OF Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-01-25 20:30 +0100
                  Re: [PATCH 0/7] Implement generic regulator constraints parsing for  ACPI and OF Mark Brown <broonie@kernel.org> - 2017-01-25 21:40 +0100
                    Re: [PATCH 0/7] Implement generic regulator constraints parsing for  ACPI and OF Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-01-25 22:20 +0100
                      Re: [PATCH 0/7] Implement generic regulator constraints parsing for  ACPI and OF Mark Brown <broonie@kernel.org> - 2017-01-25 22:40 +0100
                        Re: [PATCH 0/7] Implement generic regulator constraints parsing for  ACPI and OF Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-01-25 23:10 +0100
                          Re: [PATCH 0/7] Implement generic regulator constraints parsing for  ACPI and OF Mark Brown <broonie@kernel.org> - 2017-01-25 23:30 +0100
                  Re: [PATCH 0/7] Implement generic regulator constraints parsing for  ACPI and OF Al Stone <ahs3@redhat.com> - 2017-01-25 22:50 +0100
                    Re: [PATCH 0/7] Implement generic regulator constraints parsing for  ACPI and OF Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-01-26 00:30 +0100
                      Re: [PATCH 0/7] Implement generic regulator constraints parsing for  ACPI and OF Al Stone <ahs3@redhat.com> - 2017-01-26 01:20 +0100
                        Re: [PATCH 0/7] Implement generic regulator constraints parsing for  ACPI and OF Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-01-26 01:40 +0100
                          Re: [PATCH 0/7] Implement generic regulator constraints parsing for ACPI and OF "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-01-26 11:50 +0100
              Re: [PATCH 0/7] Implement generic regulator constraints parsing for  ACPI and OF Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> - 2017-01-25 20:20 +0100
                Re: [PATCH 0/7] Implement generic regulator constraints parsing for  ACPI and OF Mark Brown <broonie@kernel.org> - 2017-01-25 21:50 +0100

Page 2 of 2 — ← Prev page 1 [2]

#1567005 — Re: [PATCH 0/7] Implement generic regulator constraints parsing for ACPI and OF

[Multipart message — attachments visible in raw view] — view raw

On Wed, Jan 25, 2017 at 02:05:58PM -0800, Dmitry Torokhov wrote:

> > Yes.  Querying the suspend mode configuration would be one way to do it
> > already.

> Suspend mode of what though? Regulator? I would not mind cleaning up at
> least some of the drivers if we had a generic API for doing such
> query... Would it be something like:

Yes, though there's some fun working out exactly when to query them.
Early resume should be safe.

> 	bool device_has_lost_state(struct device *dev,
> 				   struct regulator *supplies)

> with DT systems going strictly off regulator data and ACPI throwing
> its internal state in the mix?

> Or you meant something else?

I meant looking at individual regulators, though I guess that does have
a list of supplied as an argument.

[toc] | [prev] | [next] | [standalone]

#1566986 — Re: [PATCH 0/7] Implement generic regulator constraints parsing for ACPI and OF

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@redhat.com
-----------------------------------

[toc] | [prev] | [next] | [standalone]

#1567039 — Re: [PATCH 0/7] Implement generic regulator constraints parsing for ACPI and OF

On Wed, Jan 25, 2017 at 02:44:10PM -0700, Al Stone wrote:
> 
> 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.

And yet this is something that is sorely needed. If you look, for
example, at drivers in drivers/input/*, then all non-SOC-specific
devices can easily find their way onto both ACPI-based and DT-based
systems (not mentioning legacy-style boards). Having two distinct power
schemes implemented in drivers will lead to many problems.

Having unified way of describing hardware is how _DSD came about, right?
Nobody wanted to write and maintain and test two separate ways of
describing properties when one was already implemented and working.

Thanks.

-- 
Dmitry

[toc] | [prev] | [next] | [standalone]

#1567052 — Re: [PATCH 0/7] Implement generic regulator constraints parsing for ACPI and OF

On 01/25/2017 04:27 PM, Dmitry Torokhov wrote:
> On Wed, Jan 25, 2017 at 02:44:10PM -0700, Al Stone wrote:
>>
>> 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.
> 
> And yet this is something that is sorely needed. If you look, for
> example, at drivers in drivers/input/*, then all non-SOC-specific
> devices can easily find their way onto both ACPI-based and DT-based
> systems (not mentioning legacy-style boards). Having two distinct power
> schemes implemented in drivers will lead to many problems.

I really can't speak to those sorts of systems; where I deal with ACPI
is on enterprise-class server systems which seldom have a graphics card,
much less input devices other than a keyboard.  And in general, those
systems are required to use only ACPI.  If a vendor wants their device to
work on such a system, they need to provide a driver that works with ACPI.
It may also work with DT, but in this environment it doesn't matter.

Whether or not there are two power schemes is a moot point.  We have DT
and we have ACPI, and they have very different schemes for power management,
so we're already there.  And so far, my experience has been that as long as
the ACPI and DT parts of the driver are kept disjoint when the models diverge,
and share code when they are semantically absolutely identical, things work
pretty well.

> Having unified way of describing hardware is how _DSD came about, right?
> Nobody wanted to write and maintain and test two separate ways of
> describing properties when one was already implemented and working.

I can't speak for those that proposed _DSD to be part of the ACPI spec,
but no, it was not meant as a unified way of describing hardware, as far
as I can remember from the ASWG discussions I was part of.  The intent,
as I recall it, was to provide some of the same flexibility to ASL that
was available in DT.  At the time, power managment was even discussed as
one of the areas where the DT model and the ACPI model clashed.

-- 
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3@redhat.com
-----------------------------------

[toc] | [prev] | [next] | [standalone]

#1567054 — Re: [PATCH 0/7] Implement generic regulator constraints parsing for ACPI and OF

On Wed, Jan 25, 2017 at 05:15:52PM -0700, Al Stone wrote:
> On 01/25/2017 04:27 PM, Dmitry Torokhov wrote:
> > On Wed, Jan 25, 2017 at 02:44:10PM -0700, Al Stone wrote:
> >>
> >> 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.
> > 
> > And yet this is something that is sorely needed. If you look, for
> > example, at drivers in drivers/input/*, then all non-SOC-specific
> > devices can easily find their way onto both ACPI-based and DT-based
> > systems (not mentioning legacy-style boards). Having two distinct power
> > schemes implemented in drivers will lead to many problems.
> 
> I really can't speak to those sorts of systems; where I deal with ACPI
> is on enterprise-class server systems which seldom have a graphics card,
> much less input devices other than a keyboard. 

Yeah, so basically no power management except for CPU states ;)

> And in general, those
> systems are required to use only ACPI.  If a vendor wants their device to
> work on such a system, they need to provide a driver that works with ACPI.
> It may also work with DT, but in this environment it doesn't matter.
> 
> Whether or not there are two power schemes is a moot point.  We have DT
> and we have ACPI, and they have very different schemes for power management,
> so we're already there.  And so far, my experience has been that as long as
> the ACPI and DT parts of the driver are kept disjoint when the models diverge,
> and share code when they are semantically absolutely identical, things work
> pretty well.

As someone who's actually shipping both ACPI and DT-based devices
reusing the same peripherals I can assure you that it is really PITA to
have different PM behavior in a single driver and if we can converge on
something sane that would be great.

> 
> > Having unified way of describing hardware is how _DSD came about, right?
> > Nobody wanted to write and maintain and test two separate ways of
> > describing properties when one was already implemented and working.
> 
> I can't speak for those that proposed _DSD to be part of the ACPI spec,
> but no, it was not meant as a unified way of describing hardware, as far
> as I can remember from the ASWG discussions I was part of.  The intent,
> as I recall it, was to provide some of the same flexibility to ASL that
> was available in DT.  At the time, power managment was even discussed as
> one of the areas where the DT model and the ACPI model clashed.

That's not what I remember from discussions at Plumbers/KS... Binding
compatibility, even if for simplest properties, was one of the points.

Thanks.

-- 
Dmitry

[toc] | [prev] | [next] | [standalone]

#1567316

On Wednesday, January 25, 2017 04:33:42 PM Dmitry Torokhov wrote:
> On Wed, Jan 25, 2017 at 05:15:52PM -0700, Al Stone wrote:
> > On 01/25/2017 04:27 PM, Dmitry Torokhov wrote:
> > > On Wed, Jan 25, 2017 at 02:44:10PM -0700, Al Stone wrote:
> > >>
> > >> 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.
> > > 
> > > And yet this is something that is sorely needed. If you look, for
> > > example, at drivers in drivers/input/*, then all non-SOC-specific
> > > devices can easily find their way onto both ACPI-based and DT-based
> > > systems (not mentioning legacy-style boards). Having two distinct power
> > > schemes implemented in drivers will lead to many problems.
> > 
> > I really can't speak to those sorts of systems; where I deal with ACPI
> > is on enterprise-class server systems which seldom have a graphics card,
> > much less input devices other than a keyboard. 
> 
> Yeah, so basically no power management except for CPU states ;)
> 
> > And in general, those
> > systems are required to use only ACPI.  If a vendor wants their device to
> > work on such a system, they need to provide a driver that works with ACPI.
> > It may also work with DT, but in this environment it doesn't matter.
> > 
> > Whether or not there are two power schemes is a moot point.  We have DT
> > and we have ACPI, and they have very different schemes for power management,
> > so we're already there.  And so far, my experience has been that as long as
> > the ACPI and DT parts of the driver are kept disjoint when the models diverge,
> > and share code when they are semantically absolutely identical, things work
> > pretty well.
> 
> As someone who's actually shipping both ACPI and DT-based devices
> reusing the same peripherals I can assure you that it is really PITA to
> have different PM behavior in a single driver and if we can converge on
> something sane that would be great.

Agreed.

However, the problem is that PM in ACPI and in the DT-based code is done at
different levels.

ACPI uses the power resource abstraction and D-states to be able to combine
HW control over regulators (think things like MWAIT on Intel CPUs or generally
C-state management done via register wrtites on the CPU) with something that
can be exposed to software.

On the other hand, doing PM at the regulator level pretty much requires that
regulators be only maniplulated directly by software.

The common abstraction can sort of be provided through PM domains, which in the
ACPI case basically map to ACPI power resources and in the OF case genpd is used,
but that doesn't work if drivers expect to be able to control regulators directly
(which BTW isn't an good idea overall IMO, because that may need to be done
differently on different platforms even without ACPI AFAICS).

> > 
> > > Having unified way of describing hardware is how _DSD came about, right?
> > > Nobody wanted to write and maintain and test two separate ways of
> > > describing properties when one was already implemented and working.

So technically, _DSD itself is just a simplified _DSM.  It provides a simplified
interface for what has been possible all the time already anyway.

On top of that, there are _DSD properties, which are defined by the special
UUIDs that we support, and here the idea was to be able to provide information
in a way that resembles DT to be able to avoid artificial code branching in
drivers among other things.

> > I can't speak for those that proposed _DSD to be part of the ACPI spec,
> > but no, it was not meant as a unified way of describing hardware, as far
> > as I can remember from the ASWG discussions I was part of.  The intent,
> > as I recall it, was to provide some of the same flexibility to ASL that
> > was available in DT.  At the time, power managment was even discussed as
> > one of the areas where the DT model and the ACPI model clashed.
> 
> That's not what I remember from discussions at Plumbers/KS... Binding
> compatibility, even if for simplest properties, was one of the points.

The idea was that in the cases in which ACPI didn't provide any specific
frameworks for the given use cases, that would simply help to handle things
in a unified fashion.

Power management is not one of those cases, though.

Thanks,
Rafael

[toc] | [prev] | [next] | [standalone]

#1566875 — Re: [PATCH 0/7] Implement generic regulator constraints parsing for ACPI and OF

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.

I think that the difference between ACPI and DT firmware models,
in particular in relation to power states handling (and what piece
of SW is in charge of power management) is significant and goes beyond
naming conventions, therefore the code (and reasoning behind it - ie
to have an identical driver interface to a completely different FW
model) in this series is just not acceptable, that's a plain shortcut.

We will see how this should be implemented in ACPI, not with this
code (and FW bindings).

Thanks,
Lorenzo

[toc] | [prev] | [next] | [standalone]

#1566935 — Re: [PATCH 0/7] Implement generic regulator constraints parsing for ACPI and OF

[Multipart message — attachments visible in raw view] — view raw

On Wed, Jan 25, 2017 at 07:21:35PM +0000, Lorenzo Pieralisi wrote:
> On Wed, Jan 25, 2017 at 06:29:55PM +0000, Mark Brown wrote:

> > 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.

> I think that the difference between ACPI and DT firmware models,
> in particular in relation to power states handling (and what piece
> of SW is in charge of power management) is significant and goes beyond
> naming conventions, therefore the code (and reasoning behind it - ie
> to have an identical driver interface to a completely different FW
> model) in this series is just not acceptable, that's a plain shortcut.

> We will see how this should be implemented in ACPI, not with this
> code (and FW bindings).

Oh, absolutely - what I'm saying is that once that's done I'd expect
implementing it to be almost entirely a regulator core change in the
same way that implementing DT support was.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web