mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
Cc: Jonathan Cameron <jic23@kernel.org>,
	linux-iio@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Sascha Weisenberger <sascha.weisenberger@siemens.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Subject: Re: [PATCH] iio: adc: Add support for TI ADC1x8s102
Date: Wed, 26 Apr 2017 07:37:34 +0200	[thread overview]
Message-ID: <5f628aa9-092f-52c0-549c-db7bdb7ea67b@siemens.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1704250906150.7992@vps.pmeerw.net>

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 below
> 
> naming: don't use placeholders, name after one of the supported chips and 
> list them in Kconfig and the driver file
> 
> what is the difference between this chip and those supported 
> by ti-adc084s021 which was proposed by Mårten Lindahl on April 21?

I've cross-read that driver, and it looks fairly different to me.

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

Also, should I suggest a device tree binding even though I have no test
case for it? My current feeling is to better leave this exercise to the
first user on a DT platform.

[...]

>> +
>> +/*
>> + * Defining the ADC resolution being 12 bits, we can use the same driver for
>> + * both ADC108S102 (10 bits resolution) and ADC128S102 (12 bits resolution)
>> + * chips. The ADC108S102 effectively returns a 12-bit result with the 2
>> + * least-significant bits unset.
>> + */
>> +#define ADC1x8S102_BITS		12

[...]

>> +#define ADC1X8S102_V_CHAN(index)					\
>> +	{								\
>> +		.type = IIO_VOLTAGE,					\
>> +		.indexed = 1,						\
>> +		.channel = index,					\
>> +		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |		\
>> +			BIT(IIO_CHAN_INFO_SCALE),			\
>> +		.address = index,					\
>> +		.scan_index = index,					\
>> +		.scan_type = {						\
>> +			.sign = 'u',					\
>> +			.realbits = ADC1x8S102_BITS,			\
> 
> this should be different for the 128 and 108 part, shift missing
> 
> most drivers do shifting and don't use _SCALE for that purpose

What would be the difference when following your suggestion?

To my understanding, which is based on the comment above, the 108 simply
has its two least significant bits cleared, i.e. it provides a value
with the exact same scale, just with lower resolution.

> 
>> +			.storagebits = 16,				\
>> +			.endianness = IIO_BE,				\
>> +		},							\
>> +	}

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

  parent reply	other threads:[~2017-04-26  5:53 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-24 19:28 Jan Kiszka
2017-04-24 20:05 ` Andy Shevchenko
2017-04-24 20:10   ` Andy Shevchenko
2017-04-24 20:37     ` Jan Kiszka
2017-04-24 20:32   ` Jan Kiszka
2017-04-24 21:25     ` Andy Shevchenko
2017-04-25  5:44       ` Jan Kiszka
2017-04-25  9:42         ` Andy Shevchenko
2017-04-25 10:53           ` Jan Kiszka
2017-04-25 11:27             ` Andy Shevchenko
2017-04-25 11:35               ` Mika Westerberg
2017-04-25 12:17                 ` Jan Kiszka
2017-04-25 12:30                   ` Mika Westerberg
2017-04-25 13:47                     ` Jan Kiszka
2017-04-25 16:12                       ` Jan Kiszka
2017-04-26  9:01                         ` Mika Westerberg
2017-04-27  6:01                           ` Jonathan Cameron
2017-04-27  6:04                             ` Jonathan Cameron
2017-05-19 16:01                             ` Mark Brown
2017-05-20 16:26                               ` Jonathan Cameron
2017-05-22 10:06                                 ` Mark Brown
2017-04-25  6:06   ` Jan Kiszka
2017-04-25  7:31 ` Peter Meerwald-Stadler
2017-04-25  9:20   ` Andy Shevchenko
2017-04-25  9:32   ` Jan Kiszka
2017-04-25 11:23     ` Andy Shevchenko
2017-04-25 12:20       ` Mika Westerberg
2017-04-26  5:37   ` Jan Kiszka [this message]
2017-04-26 10:21     ` Andy Shevchenko
2017-04-27  6:14 ` Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5f628aa9-092f-52c0-549c-db7bdb7ea67b@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=jic23@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmeerw@pmeerw.net \
    --cc=sascha.weisenberger@siemens.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®