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
25 matches
Mail list logo
