Hi George,
On Fri, Jun 23, 2023 at 4:23 AM George Stark <gnstark@xxxxxxxxxxxxxx> wrote:
[...]
> Meson saradc channel 7 is connected to muxer that can switch channel
I think that this should read: ... is connected to a mux that ...
[...]
> static const struct iio_chan_spec meson_sar_adc_iio_channels[] = {
> @@ -245,6 +280,11 @@ static const struct iio_chan_spec meson_sar_adc_iio_channels[] = {
> MESON_SAR_ADC_CHAN(INDEX_CHAN_6),
> MESON_SAR_ADC_CHAN(INDEX_CHAN_7),
> IIO_CHAN_SOFT_TIMESTAMP(INDEX_CHAN_SOFT_TIMESTAMP),
> + MESON_SAR_ADC_MUX(INDEX_MUX_0_VSS, 0),
> + MESON_SAR_ADC_MUX(INDEX_MUX_1_VDD_DIV4, 1),
> + MESON_SAR_ADC_MUX(INDEX_MUX_2_VDD_DIV2, 2),
> + MESON_SAR_ADC_MUX(INDEX_MUX_3_VDD_MUL3_DIV4, 3),
> + MESON_SAR_ADC_MUX(INDEX_MUX_4_VDD, 4),
> MESON_SAR_ADC_TEMP_CHAN(), /* must be the last item */
I haven't had the chance to run these patches yet but: I think they
are breaking the temperature sensor readings on Meson8/8b/8m2 boards.
See arch/arm/boot/dts/meson.dtsi where the temperature channel is
being referenced:
io-channels = <&saradc 8>
With this series (this patch and I think also patch 3/6 "meson saradc:
unite iio channel array definitions") the numbering of the temperature
sensor channel changes.
To make things worse: in theory we can use meson_saradc to read the
SoC temperature sensor on GXBB, GXL and GXM boards (possibly on AXG as
well but I can't recall from the top of my head) instead of going
through SCPI.
I have experimented with this in the past but never got it to work.
Doing so in the future could lead to another channel index change,
depending on how we decide to go forward now.
There's two that I can think of:
- update meson.dtsi to use the new channel numbering (I don't expect
many 32-bit SoC users out there using new kernel + old .dtbs, but it's
impossible to say for sure)
- or keep the driver backwards compatible (that involves re-adding the
channel tables)
What do you think?
Best regards,
Martin
