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

Groups > linux.kernel > #1645720 > unrolled thread

Re: [PATCH] iio: adc: Add support for TI ADC1x8s102

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] iio: adc: Add support for TI ADC1x8s102 Mark Brown <broonie@kernel.org> - 2017-05-19 18:10 +0200
    Re: [PATCH] iio: adc: Add support for TI ADC1x8s102 Jonathan Cameron <jic23@kernel.org> - 2017-05-20 18:30 +0200
      Re: [PATCH] iio: adc: Add support for TI ADC1x8s102 Mark Brown <broonie@kernel.org> - 2017-05-22 12:10 +0200

#1645720 — Re: [PATCH] iio: adc: Add support for TI ADC1x8s102

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

On Thu, Apr 27, 2017 at 07:01:07AM +0100, Jonathan Cameron wrote:

> Somewhat of a pain to basically use a random value as the default going
> forward.  Presumably this isn't the first ever ACPI table to need to
> tell use about a reference voltage...

> Mark, seen anything similar?

> I see https://www.kernel.org/doc/Documentation/arm64/arm-acpi.txt suggests
> that mapping to regulators isn't expected to ever happen...

There's multiple different camps trying to use ACPI for very different
things.  There's the server people on both x86 and ARM who want to use
standard ACPI and nothing but with the power management all hidden in
the AML but there's also the embedded x86 people who have the same needs
as DT platforms but find themselves unable to use DT so have to map all
the DT support into ACPI.  This has been accepted in areas that clearly
don't overlap with areas where there are existing ACPI bindings for
things, power management is one area where there are clear bindings
though.

[toc] | [next] | [standalone]

#1646147

On 19/05/17 17:01, Mark Brown wrote:
> On Thu, Apr 27, 2017 at 07:01:07AM +0100, Jonathan Cameron wrote:
> 
>> Somewhat of a pain to basically use a random value as the default going
>> forward.  Presumably this isn't the first ever ACPI table to need to
>> tell use about a reference voltage...
> 
>> Mark, seen anything similar?
> 
>> I see https://www.kernel.org/doc/Documentation/arm64/arm-acpi.txt suggests
>> that mapping to regulators isn't expected to ever happen...
> 
> There's multiple different camps trying to use ACPI for very different
> things.  There's the server people on both x86 and ARM who want to use
> standard ACPI and nothing but with the power management all hidden in
> the AML but there's also the embedded x86 people who have the same needs
> as DT platforms but find themselves unable to use DT so have to map all
> the DT support into ACPI.  This has been accepted in areas that clearly
> don't overlap with areas where there are existing ACPI bindings for
> things, power management is one area where there are clear bindings
> though.
Thanks Mark,

Just to clarify what do we do here, where a regulator is providing a
reference voltage and there appears to be no information on it in ACPI?

Right now we are just going with a fixed value that matches the board
someone has, but that's hardly sustainable.

Jonathan
> 

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

#1646693

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

On Sat, May 20, 2017 at 05:26:30PM +0100, Jonathan Cameron wrote:

> Just to clarify what do we do here, where a regulator is providing a
> reference voltage and there appears to be no information on it in ACPI?

> Right now we are just going with a fixed value that matches the board
> someone has, but that's hardly sustainable.

Yes, the ACPI people need to come up with some standard regulator
bindings for this sort of application.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web