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


Groups > linux.kernel > #1607216

Re: [PATCH v2 2/2] iio: Aspeed AST2400/AST2500 ADC

From Quentin Schulz <quentin.schulz@free-electrons.com>
Newsgroups linux.kernel
Subject Re: [PATCH v2 2/2] iio: Aspeed AST2400/AST2500 ADC
Date 2017-03-23 09:00 +0100
Message-ID <to5P3-7B0-1@gated-at.bofh.it> (permalink)
References <tnyT8-8vM-19@gated-at.bofh.it> <tnyT8-8vM-21@gated-at.bofh.it> <tnISt-7c5-5@gated-at.bofh.it> <to5P3-7B0-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Hi,

On 22/03/2017 21:46, Rick Altherr wrote:
> On Wed, Mar 22, 2017 at 12:21 AM, Quentin Schulz
> <quentin.schulz@free-electrons.com> wrote:
>> Hi,
>>
>> On 21/03/2017 21:48, Rick Altherr wrote:
>>> Aspeed AST2400/AST2500 BMC SoCs include a 16 channel, 10-bit ADC. Low
>>> and high threshold interrupts are supported by the hardware but are not
>>> currently implemented.
>>>
>>> Signed-off-by: Rick Altherr <raltherr@google.com>
>>> ---
>>>
>>> Changes in v2:
>>> - Rewritten as an IIO device
>>> - Renamed register macros to describe the register's purpose
>>> - Replaced awkward reading of 16-bit data registers with readw()
>>> - Added Kconfig dependency on COMPILE_TEST
>>>
[...]
>>> +#define ASPEED_ADC_CHAN(_idx, _addr) {                               \
>>> +     .type = IIO_VOLTAGE,                                    \
>>> +     .indexed = 1,                                           \
>>> +     .channel = (_idx),                                      \
>>> +     .address = (_addr),                                     \
>>> +     .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),           \
>>> +     .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) |  \
>>> +                             BIT(IIO_CHAN_INFO_SAMP_FREQ),   \
>>> +}
>>> +
>>> +static const struct iio_chan_spec aspeed_adc_iio_channels[] = {
>>> +     ASPEED_ADC_CHAN(0, 0x10),
>>> +     ASPEED_ADC_CHAN(1, 0x12),
>>> +     ASPEED_ADC_CHAN(2, 0x14),
>>> +     ASPEED_ADC_CHAN(3, 0x16),
>>> +     ASPEED_ADC_CHAN(4, 0x18),
>>> +     ASPEED_ADC_CHAN(5, 0x1A),
>>> +     ASPEED_ADC_CHAN(6, 0x1C),
>>> +     ASPEED_ADC_CHAN(7, 0x1E),
>>> +     ASPEED_ADC_CHAN(8, 0x20),
>>> +     ASPEED_ADC_CHAN(9, 0x22),
>>> +     ASPEED_ADC_CHAN(10, 0x24),
>>> +     ASPEED_ADC_CHAN(11, 0x26),
>>> +     ASPEED_ADC_CHAN(12, 0x28),
>>> +     ASPEED_ADC_CHAN(13, 0x2A),
>>> +     ASPEED_ADC_CHAN(14, 0x2C),
>>> +     ASPEED_ADC_CHAN(15, 0x2E),
>>
>> It would make sense to name the registers (the _addr parameter of your
>> macro) so it's easier to understand what it refers to.
>>
> 
> I agree with Joel on this.  There isn't really a better name than
> ADC_CHAN_0_DATA.  I'll change the macro parameter to _data_reg_addr to
> make that clearer.
> 

Is it the name in the datasheet?

[...]
>>> +     indio_dev->name = dev_name(&pdev->dev);
>>
>> This isn't good practice (cf.: https://lkml.org/lkml/2017/1/28/145 end
>> of the mail in the probe function). Better name it aspeed-adc or even
>> better to have a different name per compatible: ast2400-adc or ast2500-adc.
> 
> Ack.  Will use aspeed-adc to avoid parsing the compatible match and
> stripping the 'aspeed,' prefix.
> 

You don't need to parse the compatible match. You could use the data
void pointer in your struct of_device_id
(http://lxr.free-electrons.com/source/include/linux/mod_devicetable.h#L234)
like it's done here: https://lkml.org/lkml/2017/3/21/675
(sun4i_gpadc_of_id).

Note: please reply to all :)

Quentin

-- 
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH v2 1/2] Documentation: dt-bindings: Document bindings for Aspeed AST2400/AST2500 ADC Rick Altherr <raltherr@google.com> - 2017-03-21 21:50 +0100
  [PATCH v2 2/2] iio: Aspeed AST2400/AST2500 ADC Rick Altherr <raltherr@google.com> - 2017-03-21 21:50 +0100
    Re: [PATCH v2 2/2] iio: Aspeed AST2400/AST2500 ADC Peter Meerwald-Stadler <pmeerw@pmeerw.net> - 2017-03-21 22:30 +0100
      Re: [PATCH v2 2/2] iio: Aspeed AST2400/AST2500 ADC Rick Altherr <raltherr@google.com> - 2017-03-23 18:00 +0100
    Re: [PATCH v2 2/2] iio: Aspeed AST2400/AST2500 ADC Quentin Schulz <quentin.schulz@free-electrons.com> - 2017-03-22 08:30 +0100
      Re: [PATCH v2 2/2] iio: Aspeed AST2400/AST2500 ADC Joel Stanley <joel@jms.id.au> - 2017-03-22 11:10 +0100
        Re: [PATCH v2 2/2] iio: Aspeed AST2400/AST2500 ADC Jonathan Cameron <jic23@kernel.org> - 2017-03-25 18:30 +0100
      Re: [PATCH v2 2/2] iio: Aspeed AST2400/AST2500 ADC Quentin Schulz <quentin.schulz@free-electrons.com> - 2017-03-23 09:00 +0100
        Re: [PATCH v2 2/2] iio: Aspeed AST2400/AST2500 ADC Rick Altherr <raltherr@google.com> - 2017-03-23 18:00 +0100
    Re: [PATCH v2 2/2] iio: Aspeed AST2400/AST2500 ADC Joel Stanley <joel@jms.id.au> - 2017-03-22 10:50 +0100
      Re: [PATCH v2 2/2] iio: Aspeed AST2400/AST2500 ADC Rick Altherr <raltherr@google.com> - 2017-03-23 18:00 +0100
      Re: [PATCH v2 2/2] iio: Aspeed AST2400/AST2500 ADC Jonathan Cameron <jic23@kernel.org> - 2017-03-25 18:30 +0100

csiph-web