On Thu, Jan 26, 2017 at 11:35:55AM +0100, Rafael J. Wysocki wrote:
> 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).
W
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 discu
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
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 mod
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
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
>
On Wed, Jan 25, 2017 at 09:30:40PM +, Mark Brown wrote:
> On Wed, Jan 25, 2017 at 01:17:14PM -0800, Dmitry Torokhov wrote:
> > On Wed, Jan 25, 2017 at 08:39:07PM +, Mark Brown wrote:
>
> > > That's *not* a sensible thing for drivers to assume regardless of the
> > > presence or absence 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 +, Mark Brown wrote:
>>> On Wed, Jan 25, 2017 at 06:23:20PM +, Mark Rutland wrote:
On Wed, Jan 25, 2017 at 08:56:42AM -0800, Furquan S
On Wed, Jan 25, 2017 at 01:17:14PM -0800, Dmitry Torokhov wrote:
> On Wed, Jan 25, 2017 at 08:39:07PM +, Mark Brown wrote:
> > That's *not* a sensible thing for drivers to assume regardless of the
> > presence or absence of explicitly controlled regulators, that just seems
> > like a plain old
On Wed, Jan 25, 2017 at 08:39:07PM +, Mark Brown wrote:
> On Wed, Jan 25, 2017 at 11:27:11AM -0800, Dmitry Torokhov wrote:
>
> > 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
On Wed, Jan 25, 2017 at 07:21:35PM +, Lorenzo Pieralisi wrote:
> On Wed, Jan 25, 2017 at 06:29:55PM +, 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 abo
On Wed, Jan 25, 2017 at 11:27:11AM -0800, Dmitry Torokhov wrote:
> 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
On Wed, Jan 25, 2017 at 06:49:49PM +, Mark Brown wrote:
> On Wed, Jan 25, 2017 at 06:34:20PM +, Mark Rutland wrote:
> > On Wed, Jan 25, 2017 at 06:29:55PM +, Mark Brown wrote:
>
> > > > Mark, this was added in this cycle; can we please rip that out for now?
>
> > > If it's instantiate
On Wed, Jan 25, 2017 at 10:44:32AM -0800, Dmitry Torokhov wrote:
> On Wed, Jan 25, 2017 at 06:29:55PM +, Mark Brown wrote:
> > On Wed, Jan 25, 2017 at 06:23:20PM +, Mark Rutland wrote:
> > > On Wed, Jan 25, 2017 at 08:56:42AM -0800, Furquan Shaikh wrote:
> >
> > > > That is the reason why
On Wed, Jan 25, 2017 at 06:29:55PM +, Mark Brown wrote:
> On Wed, Jan 25, 2017 at 06:23:20PM +, 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
>
On Wed, Jan 25, 2017 at 06:34:20PM +, Mark Rutland wrote:
> On Wed, Jan 25, 2017 at 06:29:55PM +, Mark Brown wrote:
> > > Mark, this was added in this cycle; can we please rip that out for now?
> > If it's instantiated directly we probably should.
> I think that given the larger problem
On Wed, Jan 25, 2017 at 06:29:55PM +, Mark Brown wrote:
> On Wed, Jan 25, 2017 at 06:23:20PM +, 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
>
On Wed, Jan 25, 2017 at 06:29:55PM +, Mark Brown wrote:
> On Wed, Jan 25, 2017 at 06:23:20PM +, 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
>
On Wed, Jan 25, 2017 at 06:23:20PM +, 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/fix
On Wed, Jan 25, 2017 at 08:56:42AM -0800, Furquan Shaikh wrote:
> I understand that ACPI provides its own bindings to allow firmware to
> control power management and thus regulators have been a part of the
> firmware control. However, there are use cases where the kernel driver
> wishes to contro
On Wed, Jan 25, 2017 at 08:56:42AM -0800, Furquan Shaikh wrote:
> I understand that ACPI provides its own bindings to allow firmware to
> control power management and thus regulators have been a part of the
> firmware control. However, there are use cases where the kernel driver
> wishes to control
On Wed, Jan 25, 2017 at 4:55 AM, Rafael J. Wysocki wrote:
>
> On Wed, Jan 25, 2017 at 1:49 PM, Mark Brown wrote:
> > On Tue, Jan 24, 2017 at 04:06:34PM -0800, Furquan Shaikh wrote:
> >
> >> Since regulator properties remain the same across OF and ACPI
> >> regulators, this series of patches provi
On Wed, Jan 25, 2017 at 1:49 PM, Mark Brown wrote:
> On Tue, Jan 24, 2017 at 04:06:34PM -0800, Furquan Shaikh wrote:
>
>> Since regulator properties remain the same across OF and ACPI
>> regulators, this series of patches provides common routine for
>> obtaining regulation constraints from device
On Tue, Jan 24, 2017 at 04:06:34PM -0800, Furquan Shaikh wrote:
> Since regulator properties remain the same across OF and ACPI
> regulators, this series of patches provides common routine for
> obtaining regulation constraints from device tree and ACPI nodes. In
As Lorenzo explained this is real
[+MarkR]
On Tue, Jan 24, 2017 at 04:06:34PM -0800, Furquan Shaikh wrote:
> Until now, the regulator framework assumed that regulators are being
> passed in using device tree(OF) only. However, with the recent change
> to add ACPI fixed regulator, it is necessary to have all the regulator
> init da
Until now, the regulator framework assumed that regulators are being
passed in using device tree(OF) only. However, with the recent change
to add ACPI fixed regulator, it is necessary to have all the regulator
init data and regulation constraints parsing performed for ACPI
regulators as well. This
26 matches
Mail list logo
