On Tuesday, June 10, 2014 at 03:41:35 PM, Robert Hodaszi wrote:
> Commit c8231a9af8147f8a401fc55931ec44abfb937660 ("iio: mxs-lradc: compute
> temperature from channel 8 and 9") merged channel 8 and channel 9 to create
> an IIO_TEMP channel. It changed the number of LRADC channels, which could
> cause incompatibility with previous device-tree declarations, and also
> makes it illogical (e.g. channel 15 is <&lradc 14>).
>
> Add channel 9 as a copy of channel 8. Reading channel 9 has the same output
> as reading channel 8.
>
> Signed-off-by: Robert Hodaszi <robert.hodaszi@xxxxxxxx>
> ---
[...]
> static const struct iio_chan_spec mxs_lradc_chan_spec[] = {
> - MXS_ADC_CHAN(0, IIO_VOLTAGE),
> - MXS_ADC_CHAN(1, IIO_VOLTAGE),
> - MXS_ADC_CHAN(2, IIO_VOLTAGE),
> - MXS_ADC_CHAN(3, IIO_VOLTAGE),
> - MXS_ADC_CHAN(4, IIO_VOLTAGE),
> - MXS_ADC_CHAN(5, IIO_VOLTAGE),
> - MXS_ADC_CHAN(6, IIO_VOLTAGE),
> - MXS_ADC_CHAN(7, IIO_VOLTAGE), /* VBATT */
> + MXS_ADC_VOLTAGE_CHAN(0),
> + MXS_ADC_VOLTAGE_CHAN(1),
> + MXS_ADC_VOLTAGE_CHAN(2),
> + MXS_ADC_VOLTAGE_CHAN(3),
> + MXS_ADC_VOLTAGE_CHAN(4),
> + MXS_ADC_VOLTAGE_CHAN(5),
> + MXS_ADC_VOLTAGE_CHAN(6),
> + MXS_ADC_VOLTAGE_CHAN(7), /* VBATT */
> /* Combined Temperature sensors */
> - {
> - .type = IIO_TEMP,
> - .indexed = 1,
> - .scan_index = 8,
> - .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> - BIT(IIO_CHAN_INFO_OFFSET) |
> - BIT(IIO_CHAN_INFO_SCALE),
> - .channel = 8,
> - .scan_type = {.sign = 'u', .realbits = 18, .storagebits = 32,},
> - },
I wonder, shouldn't the IIO framework handle this kind of a "hole" in the
iio_chan_spec structure, where one entry has .channel = N and the subsequent one
has .channel = N + 2 somehow ?
> - MXS_ADC_CHAN(10, IIO_VOLTAGE), /* VDDIO */
> - MXS_ADC_CHAN(11, IIO_VOLTAGE), /* VTH */
> - MXS_ADC_CHAN(12, IIO_VOLTAGE), /* VDDA */
> - MXS_ADC_CHAN(13, IIO_VOLTAGE), /* VDDD */
> - MXS_ADC_CHAN(14, IIO_VOLTAGE), /* VBG */
> - MXS_ADC_CHAN(15, IIO_VOLTAGE), /* VDD5V */
[...]
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
