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
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
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,
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,
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
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
On 24/04/17 20:28, Jan Kiszka wrote:
> This is an upstream port of an IIO driver for the TI ADC108S102 and
> ADC128S102. The former can be found on the Intel Galileo Gen2 and the
> Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration is
> included.
>
> Original author: Bogdan Pricop
On 24/04/17 20:28, Jan Kiszka wrote:
> This is an upstream port of an IIO driver for the TI ADC108S102 and
> ADC128S102. The former can be found on the Intel Galileo Gen2 and the
> Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration is
> included.
>
> Original author: Bogdan Pricop
On 27/04/17 07:01, Jonathan Cameron wrote:
> On 26/04/17 10:01, Mika Westerberg wrote:
>> On Tue, Apr 25, 2017 at 06:12:12PM +0200, Jan Kiszka wrote:
>>> Now, do you also a suggestion where to put that 5 V reference voltage
>>> value that is hard-coded (via wiring) on the target boards for the
On 27/04/17 07:01, Jonathan Cameron wrote:
> On 26/04/17 10:01, Mika Westerberg wrote:
>> On Tue, Apr 25, 2017 at 06:12:12PM +0200, Jan Kiszka wrote:
>>> Now, do you also a suggestion where to put that 5 V reference voltage
>>> value that is hard-coded (via wiring) on the target boards for the
On 26/04/17 10:01, Mika Westerberg wrote:
> On Tue, Apr 25, 2017 at 06:12:12PM +0200, Jan Kiszka wrote:
>> Now, do you also a suggestion where to put that 5 V reference voltage
>> value that is hard-coded (via wiring) on the target boards for the ADC?
>> That is now device-specific, not a
On 26/04/17 10:01, Mika Westerberg wrote:
> On Tue, Apr 25, 2017 at 06:12:12PM +0200, Jan Kiszka wrote:
>> Now, do you also a suggestion where to put that 5 V reference voltage
>> value that is hard-coded (via wiring) on the target boards for the ADC?
>> That is now device-specific, not a
On Wed, Apr 26, 2017 at 8:37 AM, Jan Kiszka wrote:
> On 2017-04-25 09:31, Peter Meerwald-Stadler wrote:
>> I think board-specific stuff should not go into the driver -> DT?
>
> Still looking for suggestions how to provide the external reference
> voltage as parameter.
On Wed, Apr 26, 2017 at 8:37 AM, Jan Kiszka wrote:
> On 2017-04-25 09:31, Peter Meerwald-Stadler wrote:
>> I think board-specific stuff should not go into the driver -> DT?
>
> Still looking for suggestions how to provide the external reference
> voltage as parameter. Chip select is gone now.
On Tue, Apr 25, 2017 at 06:12:12PM +0200, Jan Kiszka wrote:
> Now, do you also a suggestion where to put that 5 V reference voltage
> value that is hard-coded (via wiring) on the target boards for the ADC?
> That is now device-specific, not a controller parameter. Is there an
> ACPI-way to express
On Tue, Apr 25, 2017 at 06:12:12PM +0200, Jan Kiszka wrote:
> Now, do you also a suggestion where to put that 5 V reference voltage
> value that is hard-coded (via wiring) on the target boards for the ADC?
> That is now device-specific, not a controller parameter. Is there an
> ACPI-way to express
On 2017-04-25 09:31, Peter Meerwald-Stadler wrote:
>
>> This is an upstream port of an IIO driver for the TI ADC108S102 and
>> ADC128S102. The former can be found on the Intel Galileo Gen2 and the
>> Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration is
>> included.
>
> comments
On 2017-04-25 09:31, Peter Meerwald-Stadler wrote:
>
>> This is an upstream port of an IIO driver for the TI ADC108S102 and
>> ADC128S102. The former can be found on the Intel Galileo Gen2 and the
>> Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration is
>> included.
>
> comments
On 2017-04-25 15:47, Jan Kiszka wrote:
> On 2017-04-25 14:30, Mika Westerberg wrote:
>> On Tue, Apr 25, 2017 at 02:17:23PM +0200, Jan Kiszka wrote:
>>> I'm not ACPI guru: How do we come from a SSDT to information that is
>>> carried in the DSDT so far? How can we overload wrong information in the
On 2017-04-25 15:47, Jan Kiszka wrote:
> On 2017-04-25 14:30, Mika Westerberg wrote:
>> On Tue, Apr 25, 2017 at 02:17:23PM +0200, Jan Kiszka wrote:
>>> I'm not ACPI guru: How do we come from a SSDT to information that is
>>> carried in the DSDT so far? How can we overload wrong information in the
On 2017-04-25 14:30, Mika Westerberg wrote:
> On Tue, Apr 25, 2017 at 02:17:23PM +0200, Jan Kiszka wrote:
>> I'm not ACPI guru: How do we come from a SSDT to information that is
>> carried in the DSDT so far? How can we overload wrong information in the
>> built in DSDT this way? I'm all ears if
On 2017-04-25 14:30, Mika Westerberg wrote:
> On Tue, Apr 25, 2017 at 02:17:23PM +0200, Jan Kiszka wrote:
>> I'm not ACPI guru: How do we come from a SSDT to information that is
>> carried in the DSDT so far? How can we overload wrong information in the
>> built in DSDT this way? I'm all ears if
On Tue, Apr 25, 2017 at 02:17:23PM +0200, Jan Kiszka wrote:
> I'm not ACPI guru: How do we come from a SSDT to information that is
> carried in the DSDT so far? How can we overload wrong information in the
> built in DSDT this way? I'm all ears if we could fix our (and also the
> Galileo) quirks
On Tue, Apr 25, 2017 at 02:17:23PM +0200, Jan Kiszka wrote:
> I'm not ACPI guru: How do we come from a SSDT to information that is
> carried in the DSDT so far? How can we overload wrong information in the
> built in DSDT this way? I'm all ears if we could fix our (and also the
> Galileo) quirks
On Tue, Apr 25, 2017 at 02:23:48PM +0300, Andy Shevchenko wrote:
> > Needed to make it work. If there is a better file to keep that, I'll
> > move it.
>
> Ideally you need BIOS fixed for that.
>
> Otherwise you may do a separate code which would provide CS GPIO look up
> table.
>
> Mika, what
On Tue, Apr 25, 2017 at 02:23:48PM +0300, Andy Shevchenko wrote:
> > Needed to make it work. If there is a better file to keep that, I'll
> > move it.
>
> Ideally you need BIOS fixed for that.
>
> Otherwise you may do a separate code which would provide CS GPIO look up
> table.
>
> Mika, what
On 2017-04-25 13:35, Mika Westerberg wrote:
> On Tue, Apr 25, 2017 at 02:27:10PM +0300, Andy Shevchenko wrote:
>>> Shipping own DSDTs is no long-term path: we would be forced to provide
>>> separate images due to a single parameter being different in the DSDTs
>>> of the 2020 and 2040. And you
On 2017-04-25 13:35, Mika Westerberg wrote:
> On Tue, Apr 25, 2017 at 02:27:10PM +0300, Andy Shevchenko wrote:
>>> Shipping own DSDTs is no long-term path: we would be forced to provide
>>> separate images due to a single parameter being different in the DSDTs
>>> of the 2020 and 2040. And you
On Tue, Apr 25, 2017 at 02:27:10PM +0300, Andy Shevchenko wrote:
> > Shipping own DSDTs is no long-term path: we would be forced to provide
> > separate images due to a single parameter being different in the DSDTs
> > of the 2020 and 2040. And you cannot provide any overlay to adjust the
> >
On Tue, Apr 25, 2017 at 02:27:10PM +0300, Andy Shevchenko wrote:
> > Shipping own DSDTs is no long-term path: we would be forced to provide
> > separate images due to a single parameter being different in the DSDTs
> > of the 2020 and 2040. And you cannot provide any overlay to adjust the
> >
On Tue, 2017-04-25 at 12:53 +0200, Jan Kiszka wrote:
> On 2017-04-25 11:42, Andy Shevchenko wrote:
> > > Where is a good example? Sorry,
> > > I still don't see how to make code out of your comments.
> >
> > Mostly remove those ugly hacks and start over.
>
> Still not a constructive answer.
On Tue, 2017-04-25 at 12:53 +0200, Jan Kiszka wrote:
> On 2017-04-25 11:42, Andy Shevchenko wrote:
> > > Where is a good example? Sorry,
> > > I still don't see how to make code out of your comments.
> >
> > Mostly remove those ugly hacks and start over.
>
> Still not a constructive answer.
On Tue, 2017-04-25 at 11:32 +0200, Jan Kiszka wrote:
> On 2017-04-25 09:31, Peter Meerwald-Stadler wrote:
+Cc: Mika.
> > I think board-specific stuff should not go into the driver -> DT?
>
> Unfortunately, we only have half-baked ACPI on those boards.
That's the main problem and still no
On Tue, 2017-04-25 at 11:32 +0200, Jan Kiszka wrote:
> On 2017-04-25 09:31, Peter Meerwald-Stadler wrote:
+Cc: Mika.
> > I think board-specific stuff should not go into the driver -> DT?
>
> Unfortunately, we only have half-baked ACPI on those boards.
That's the main problem and still no
On 2017-04-25 11:42, Andy Shevchenko wrote:
> +Cc: Mika
>
> On Tue, Apr 25, 2017 at 8:44 AM, Jan Kiszka wrote:
>> On 2017-04-24 23:25, Andy Shevchenko wrote:
>>> On Mon, Apr 24, 2017 at 11:32 PM, Jan Kiszka wrote:
On 2017-04-24 22:05, Andy
On 2017-04-25 11:42, Andy Shevchenko wrote:
> +Cc: Mika
>
> On Tue, Apr 25, 2017 at 8:44 AM, Jan Kiszka wrote:
>> On 2017-04-24 23:25, Andy Shevchenko wrote:
>>> On Mon, Apr 24, 2017 at 11:32 PM, Jan Kiszka wrote:
On 2017-04-24 22:05, Andy Shevchenko wrote:
> On Mon, 2017-04-24 at
+Cc: Mika
On Tue, Apr 25, 2017 at 8:44 AM, Jan Kiszka wrote:
> On 2017-04-24 23:25, Andy Shevchenko wrote:
>> On Mon, Apr 24, 2017 at 11:32 PM, Jan Kiszka wrote:
>>> On 2017-04-24 22:05, Andy Shevchenko wrote:
On Mon, 2017-04-24 at 21:28
+Cc: Mika
On Tue, Apr 25, 2017 at 8:44 AM, Jan Kiszka wrote:
> On 2017-04-24 23:25, Andy Shevchenko wrote:
>> On Mon, Apr 24, 2017 at 11:32 PM, Jan Kiszka wrote:
>>> On 2017-04-24 22:05, Andy Shevchenko wrote:
On Mon, 2017-04-24 at 21:28 +0200, Jan Kiszka wrote:
> This is an upstream
On 2017-04-25 09:31, Peter Meerwald-Stadler wrote:
>
>> This is an upstream port of an IIO driver for the TI ADC108S102 and
>> ADC128S102. The former can be found on the Intel Galileo Gen2 and the
>> Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration is
>> included.
>
> comments
On 2017-04-25 09:31, Peter Meerwald-Stadler wrote:
>
>> This is an upstream port of an IIO driver for the TI ADC108S102 and
>> ADC128S102. The former can be found on the Intel Galileo Gen2 and the
>> Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration is
>> included.
>
> comments
On Tue, Apr 25, 2017 at 10:31 AM, Peter Meerwald-Stadler
wrote:
>
>> This is an upstream port of an IIO driver for the TI ADC108S102 and
>> ADC128S102. The former can be found on the Intel Galileo Gen2 and the
>> Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration
On Tue, Apr 25, 2017 at 10:31 AM, Peter Meerwald-Stadler
wrote:
>
>> This is an upstream port of an IIO driver for the TI ADC108S102 and
>> ADC128S102. The former can be found on the Intel Galileo Gen2 and the
>> Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration is
>> included.
>
> This is an upstream port of an IIO driver for the TI ADC108S102 and
> ADC128S102. The former can be found on the Intel Galileo Gen2 and the
> Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration is
> included.
comments below
naming: don't use placeholders, name after one of the
> This is an upstream port of an IIO driver for the TI ADC108S102 and
> ADC128S102. The former can be found on the Intel Galileo Gen2 and the
> Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration is
> included.
comments below
naming: don't use placeholders, name after one of the
On 2017-04-24 22:05, Andy Shevchenko wrote:
>> +{
>> +int ret;
>> +struct adc1x8s102_state *st;
>> +
>> +st = iio_priv(indio_dev);
>> +
>> +switch (m) {
>> +case IIO_CHAN_INFO_RAW:
>> +mutex_lock(_dev->mlock);
>> +if (indio_dev->currentmode ==
On 2017-04-24 22:05, Andy Shevchenko wrote:
>> +{
>> +int ret;
>> +struct adc1x8s102_state *st;
>> +
>> +st = iio_priv(indio_dev);
>> +
>> +switch (m) {
>> +case IIO_CHAN_INFO_RAW:
>> +mutex_lock(_dev->mlock);
>> +if (indio_dev->currentmode ==
On 2017-04-24 23:25, Andy Shevchenko wrote:
> On Mon, Apr 24, 2017 at 11:32 PM, Jan Kiszka wrote:
>> On 2017-04-24 22:05, Andy Shevchenko wrote:
>>> On Mon, 2017-04-24 at 21:28 +0200, Jan Kiszka wrote:
This is an upstream port of an IIO driver for the TI ADC108S102
On 2017-04-24 23:25, Andy Shevchenko wrote:
> On Mon, Apr 24, 2017 at 11:32 PM, Jan Kiszka wrote:
>> On 2017-04-24 22:05, Andy Shevchenko wrote:
>>> On Mon, 2017-04-24 at 21:28 +0200, Jan Kiszka wrote:
This is an upstream port of an IIO driver for the TI ADC108S102 and
ADC128S102. The
On Mon, Apr 24, 2017 at 11:32 PM, Jan Kiszka wrote:
> On 2017-04-24 22:05, Andy Shevchenko wrote:
>> On Mon, 2017-04-24 at 21:28 +0200, Jan Kiszka wrote:
>>> This is an upstream port of an IIO driver for the TI ADC108S102 and
>>> ADC128S102. The former can be found on the
On Mon, Apr 24, 2017 at 11:32 PM, Jan Kiszka wrote:
> On 2017-04-24 22:05, Andy Shevchenko wrote:
>> On Mon, 2017-04-24 at 21:28 +0200, Jan Kiszka wrote:
>>> This is an upstream port of an IIO driver for the TI ADC108S102 and
>>> ADC128S102. The former can be found on the Intel Galileo Gen2 and
On 2017-04-24 22:10, Andy Shevchenko wrote:
> On Mon, 2017-04-24 at 23:05 +0300, Andy Shevchenko wrote:
>> On Mon, 2017-04-24 at 21:28 +0200, Jan Kiszka wrote:
>>> This is an upstream port of an IIO driver for the TI ADC108S102 and
>>> ADC128S102. The former can be found on the Intel Galileo Gen2
On 2017-04-24 22:10, Andy Shevchenko wrote:
> On Mon, 2017-04-24 at 23:05 +0300, Andy Shevchenko wrote:
>> On Mon, 2017-04-24 at 21:28 +0200, Jan Kiszka wrote:
>>> This is an upstream port of an IIO driver for the TI ADC108S102 and
>>> ADC128S102. The former can be found on the Intel Galileo Gen2
On 2017-04-24 22:05, Andy Shevchenko wrote:
> On Mon, 2017-04-24 at 21:28 +0200, Jan Kiszka wrote:
>> This is an upstream port of an IIO driver for the TI ADC108S102 and
>> ADC128S102. The former can be found on the Intel Galileo Gen2 and the
>> Siemens SIMATIC IOT2000. For those boards,
On 2017-04-24 22:05, Andy Shevchenko wrote:
> On Mon, 2017-04-24 at 21:28 +0200, Jan Kiszka wrote:
>> This is an upstream port of an IIO driver for the TI ADC108S102 and
>> ADC128S102. The former can be found on the Intel Galileo Gen2 and the
>> Siemens SIMATIC IOT2000. For those boards,
On Mon, 2017-04-24 at 23:05 +0300, Andy Shevchenko wrote:
> On Mon, 2017-04-24 at 21:28 +0200, Jan Kiszka wrote:
> > This is an upstream port of an IIO driver for the TI ADC108S102 and
> > ADC128S102. The former can be found on the Intel Galileo Gen2 and
> > the
> > Siemens SIMATIC IOT2000. For
On Mon, 2017-04-24 at 23:05 +0300, Andy Shevchenko wrote:
> On Mon, 2017-04-24 at 21:28 +0200, Jan Kiszka wrote:
> > This is an upstream port of an IIO driver for the TI ADC108S102 and
> > ADC128S102. The former can be found on the Intel Galileo Gen2 and
> > the
> > Siemens SIMATIC IOT2000. For
On Mon, 2017-04-24 at 21:28 +0200, Jan Kiszka wrote:
> This is an upstream port of an IIO driver for the TI ADC108S102 and
> ADC128S102. The former can be found on the Intel Galileo Gen2 and the
> Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration is
> included.
>
> Original
On Mon, 2017-04-24 at 21:28 +0200, Jan Kiszka wrote:
> This is an upstream port of an IIO driver for the TI ADC108S102 and
> ADC128S102. The former can be found on the Intel Galileo Gen2 and the
> Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration is
> included.
>
> Original
This is an upstream port of an IIO driver for the TI ADC108S102 and
ADC128S102. The former can be found on the Intel Galileo Gen2 and the
Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration is
included.
Original author: Bogdan Pricop
Ported from Intel
This is an upstream port of an IIO driver for the TI ADC108S102 and
ADC128S102. The former can be found on the Intel Galileo Gen2 and the
Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration is
included.
Original author: Bogdan Pricop
Ported from Intel Galileo Gen2 BSP to Intel
60 matches
Mail list logo