<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/iio/adc, branch linux-4.12.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.12.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.12.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2017-09-09T15:39:29Z</updated>
<entry>
<title>iio: adc: ti-ads1015: add adequate wait time to get correct conversion</title>
<updated>2017-09-09T15:39:29Z</updated>
<author>
<name>Akinobu Mita</name>
</author>
<published>2017-07-20T15:24:22Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6c6c3c6bd9543c08c8c153c387f2ffdcd6bd2698'/>
<id>urn:sha1:6c6c3c6bd9543c08c8c153c387f2ffdcd6bd2698</id>
<content type='text'>
commit 4744d4e2afebf9644a439da9ca73d822fdd67bd9 upstream.

This driver assumes that the device is operating in the continuous
conversion mode which performs the conversion continuously.  So this driver
inserts a wait time before reading the conversion register if the
configuration is changed from a previous request.

Currently, the wait time is only the period required for a single
conversion that is calculated as the reciprocal of the sampling frequency.
However we also need to wait for the the previous conversion to complete.
Otherwise we probably get the conversion result for the previous
configuration when the sampling frequency is lower.

Cc: Daniel Baluta &lt;daniel.baluta@gmail.com&gt;
Signed-off-by: Akinobu Mita &lt;akinobu.mita@gmail.com&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iio: adc: ti-ads1015: don't return invalid value from buffer setup callbacks</title>
<updated>2017-09-09T15:39:29Z</updated>
<author>
<name>Akinobu Mita</name>
</author>
<published>2017-07-20T15:24:21Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=00202ded930ed79f1253c3847cbd56c361ee7bba'/>
<id>urn:sha1:00202ded930ed79f1253c3847cbd56c361ee7bba</id>
<content type='text'>
commit a6fe5e52d5ecfc98530034d6c9db73777cf41ede upstream.

pm_runtime_get_sync() and pm_runtime_put_autosuspend() return 0 on
success, 1 if the device's runtime PM status was already requested status
or error code on failure.  So a positive return value doesn't indicate an
error condition.

However, any non-zero return values from buffer preenable and postdisable
callbacks are recognized as an error and this driver reuses the return
value from pm_runtime_get_sync() and pm_runtime_put_autosuspend() in
these callbacks.  This change fixes the false error detections.

Cc: Daniel Baluta &lt;daniel.baluta@gmail.com&gt;
Signed-off-by: Akinobu Mita &lt;akinobu.mita@gmail.com&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iio: adc: ti-ads1015: avoid getting stale result after runtime resume</title>
<updated>2017-09-09T15:39:29Z</updated>
<author>
<name>Akinobu Mita</name>
</author>
<published>2017-07-20T15:24:20Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=303d31eb5adfaa67dc9ae4422d4fd123b4b5bcf6'/>
<id>urn:sha1:303d31eb5adfaa67dc9ae4422d4fd123b4b5bcf6</id>
<content type='text'>
commit 73e3e3fc50de50cfd68e945d85679c983ed31bd9 upstream.

This driver assumes that the device is operating in the continuous
conversion mode which performs the conversion continuously.  So this driver
doesn't insert a wait time before reading the conversion register if the
configuration is not changed from a previous request.

This assumption is broken if the device is runtime suspended and entered
a power-down state.  The forthcoming request causes reading a stale result
from the conversion register as the device is runtime resumed just before.

Fix it by adding a flag to detect that condition and insert a necessary
wait time.

Cc: Daniel Baluta &lt;daniel.baluta@gmail.com&gt;
Signed-off-by: Akinobu Mita &lt;akinobu.mita@gmail.com&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iio: adc: ti-ads1015: enable conversion when CONFIG_PM is not set</title>
<updated>2017-09-09T15:39:28Z</updated>
<author>
<name>Akinobu Mita</name>
</author>
<published>2017-07-20T15:24:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6c164a8ad918a144812f6eff26537d84929b7784'/>
<id>urn:sha1:6c164a8ad918a144812f6eff26537d84929b7784</id>
<content type='text'>
commit e8245c68350104b6022b6783719e843d69ea7c43 upstream.

The ADS1015 device have two operating modes, continuous conversion mode
and single-shot mode.  This driver assumes that the continuous conversion
mode is selected by runtime resume callback when the ADC result is
requested.

If CONFIG_PM is disabled, the device is always in the default single-shot
mode and no one begins a single conversion.  So the conversion register
doesn't contain valid ADC result.  Fix it by changing the continuous mode
in probe function.

Cc: Daniel Baluta &lt;daniel.baluta@gmail.com&gt;
Signed-off-by: Akinobu Mita &lt;akinobu.mita@gmail.com&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iio: adc: ti-ads1015: fix scale information for ADS1115</title>
<updated>2017-09-09T15:39:28Z</updated>
<author>
<name>Akinobu Mita</name>
</author>
<published>2017-07-20T15:24:18Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6c5595e0815d9d9c8af901c00648e9b96bbf4114'/>
<id>urn:sha1:6c5595e0815d9d9c8af901c00648e9b96bbf4114</id>
<content type='text'>
commit 8d0e8e795623bd6229cf48bb7777a1c456c370ed upstream.

The ti-ads1015 driver supports ADS1015 and ADS1115 devices.  The same
scale information is used for both devices in this driver, however they
have actually different values and the ADS1115's one is not correct.

These devices have the same full-scale input voltage range for each PGA
selection.  So instead of adding another hardcoded scale information,
compute a correct scale on demand from each device's resolution.

Cc: Daniel Baluta &lt;daniel.baluta@gmail.com&gt;
Signed-off-by: Akinobu Mita &lt;akinobu.mita@gmail.com&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iio: adc: ti-ads1015: fix incorrect data rate setting update</title>
<updated>2017-09-09T15:39:28Z</updated>
<author>
<name>Akinobu Mita</name>
</author>
<published>2017-07-20T15:24:17Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1d7fadc5937f9de6ef14cf6e66c3ea2de55f86d4'/>
<id>urn:sha1:1d7fadc5937f9de6ef14cf6e66c3ea2de55f86d4</id>
<content type='text'>
commit 0d106b74c558e3000aa0e058b4725cacb70ce77a upstream.

The ti-ads1015 driver has eight iio voltage channels and each iio channel
can hold own sampling frequency information.

The ADS1015 device only have a single config register which contains an
input multiplexer selection, PGA and data rate settings.  So the driver
should load the correct settings when the input multiplexer selection is
changed.

However, regardless of which channlel is currently selected, changing any
iio channel's sampling frequency information immediately overwrites the
current data rate setting in the config register.

It breaks the current data rate setting if the different channel's sampling
frequency information is changed because the data rate setting is not
reloaded when the input multiplexer is switched.

This removes the unexpected config register update and correctly load the
data rate setting before getting adc result.

Cc: Daniel Baluta &lt;daniel.baluta@gmail.com&gt;
Signed-off-by: Akinobu Mita &lt;akinobu.mita@gmail.com&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iio: adc: vf610_adc: Fix VALT selection value for REFSEL bits</title>
<updated>2017-08-16T20:47:00Z</updated>
<author>
<name>Stefan-Gabriel Mirea</name>
</author>
<published>2017-07-06T09:06:41Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e8a1edad18fae0a967a1225e242908412497ee61'/>
<id>urn:sha1:e8a1edad18fae0a967a1225e242908412497ee61</id>
<content type='text'>
commit d466d3c1217406b14b834335b5b4b33c0d45bd09 upstream.

In order to select the alternate voltage reference pair (VALTH/VALTL), the
right value for the REFSEL field in the ADCx_CFG register is "01", leading
to 0x800 as register mask. See section 8.2.6.4 in the reference manual[1].

[1] http://www.nxp.com/docs/en/reference-manual/VFXXXRM.pdf

Fixes: a775427632fd ("iio:adc:imx: add Freescale Vybrid vf610 adc driver")
Signed-off-by: Stefan-Gabriel Mirea &lt;stefan-gabriel.mirea@nxp.com&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iio: adc: Revert "axp288: Drop bogus AXP288_ADC_TS_PIN_CTRL register modifications"</title>
<updated>2017-08-16T20:46:56Z</updated>
<author>
<name>Hans de Goede</name>
</author>
<published>2017-06-30T17:42:54Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=20035abc9e083387a3c163207f185468f5c137bb'/>
<id>urn:sha1:20035abc9e083387a3c163207f185468f5c137bb</id>
<content type='text'>
commit 631b010abc5b57009c6a8328f51492665f6ef310 upstream.

Inheriting the ADC BIAS current settings from the BIOS instead of
hardcoding then causes the AXP288 to disable charging (I think it
mis-detects an overheated battery) on at least one model tablet.

So lets go back to hard coding the values, this reverts
commit fa2849e9649b ("iio: adc: axp288: Drop bogus
AXP288_ADC_TS_PIN_CTRL register modifications"), fixing charging not
working on the model tablet in question.

The exact cause is not fully understood, hence the revert to a known working
state.

Reported-by: Umberto Ixxo &lt;sfumato1977@gmail.com&gt;
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iio: aspeed-adc: wait for initial sequence.</title>
<updated>2017-08-16T20:46:55Z</updated>
<author>
<name>Mykola Kostenok</name>
</author>
<published>2017-07-17T09:00:35Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5f26ebe1afdcf348a9daafd419f97bca02e1a49c'/>
<id>urn:sha1:5f26ebe1afdcf348a9daafd419f97bca02e1a49c</id>
<content type='text'>
commit 737cc2a593782df6846b3cab7e0f64384f58364a upstream.

This patch enables adc engine at initialization time and waits
for the initial sequence completion before enabling adc channels.

Without this code adc channels are not functional and shows
zeros for all connected channels.

Tested on mellanox msn platform.

v1 -&gt; v2:
Pointed by Rick Altherr:
 - Wait init sequence code enabled by bool
from OF match table.

Signed-off-by: Mykola Kostenok &lt;c_mykolak@mellanox.com&gt;
Reviewed-by: Rick Altherr &lt;raltherr@google.com&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iio: adc: meson-saradc: fix potential crash in meson_sar_adc_clear_fifo</title>
<updated>2017-06-11T14:00:13Z</updated>
<author>
<name>Martin Blumenstingl</name>
</author>
<published>2017-06-04T13:28:23Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=103a07d4278203d6299798cd74cdc4d209801cac'/>
<id>urn:sha1:103a07d4278203d6299798cd74cdc4d209801cac</id>
<content type='text'>
meson_sar_adc_clear_fifo passes a 0 as value-pointer to regmap_read().
In case of the meson-saradc driver this ends up in regmap_mmio_read(),
where the value-pointer is de-referenced unconditionally to assign the
value which was read.
Fix this by passing an actual pointer, even though all we want to do is
to discard the value.

As a side-effect this fixes a sparse warning ("Using plain integer as
NULL pointer") as reported by Paolo Cretaro.

Fixes: 3adbf3427330 ("iio: adc: add a driver for the SAR ADC found in Amlogic Meson SoCs")
Reported-by: Paolo Cretaro &lt;paolocretaro@gmail.com&gt;
Signed-off-by: Martin Blumenstingl &lt;martin.blumenstingl@googlemail.com&gt;
Cc: &lt;Stable@vger.kernel.org&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
</content>
</entry>
</feed>
