The adcxx communicates with a host processor via an SPI/Microwire Bus
interface. The device family responds with 12-bit data, of which the LSB bits
are transmitted by the lower resolution devices as 0.
The unavailable bits are 0 in LSB.
Shift is calculated per resolution and used in scaling and raw data read.
Lets reuse the driver to support the family of devices with name
ADC<bb><c>S<sss>, where
* bb is the resolution in number of bits (8, 10, 12)
* c is the number of channels (1, 2, 4, 8)
* sss is the maximum conversion speed (021 for 200 kSPS, 051 for 500 kSPS
and 101 for 1 MSPS)
Complete datasheets are available at TI's website here:
https://www.ti.com/lit/ds/symlink/adc<bb><c>s<sss>.pdf
Tested only with ti-adc102s051 on BegalePlay SBC.
https://www.beagleboard.org/boards/beagleplay
Co-developed-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Sukrut Bellary <sbellary@baylibre.com>
---
drivers/iio/adc/ti-adc128s052.c | 51 +++++++++++++++++++++++++++++++++
1 file changed, 51 insertions(+)
diff --git a/drivers/iio/adc/ti-adc128s052.c b/drivers/iio/adc/ti-adc128s052.c
index fbf15c83c127..b515ed0bb1d5 100644
--- a/drivers/iio/adc/ti-adc128s052.c
+++ b/drivers/iio/adc/ti-adc128s052.c
@@ -7,6 +7,21 @@
* https://www.ti.com/lit/ds/symlink/adc128s052.pdf
* https://www.ti.com/lit/ds/symlink/adc122s021.pdf
* https://www.ti.com/lit/ds/symlink/adc124s021.pdf
+ *
+ * The adcxx4s communicates with a host processor via an SPI/Microwire Bus
+ * interface. This driver supports the whole family of devices with a name
+ * ADC<bb><c>S<sss>, where
+ * bb is the resolution in number of bits (8, 10, 12)
+ * c is the number of channels (1, 2, 4, 8)
+ * sss is the maximum conversion speed (021 for 200 kSPS, 051 for 500 kSPS and
+ * 101 for 1 MSPS)
+ *
+ * Complete datasheets are available at TI's website here:
+ * https://www.ti.com/lit/ds/symlink/adc<bb><c>s<sss>.pdf
+ *
+ * 8, 10, and 12 bits converters send 12-bit data with unavailable bits set to
+ * 0 in LSB.
+ * Shift is calculated per resolution and used in scaling and raw data read.
*/
#include <linux/cleanup.h>
@@ -110,8 +125,20 @@ static int adc128_read_raw(struct iio_dev *indio_dev,
}, \
}
+#define ADC082_VOLTAGE_CHANNEL(num) _ADC128_VOLTAGE_CHANNEL(num, 8)
+#define ADC102_VOLTAGE_CHANNEL(num) _ADC128_VOLTAGE_CHANNEL(num, 10)
#define ADC128_VOLTAGE_CHANNEL(num) _ADC128_VOLTAGE_CHANNEL(num, 12)
+static const struct iio_chan_spec adc082s021_channels[] = {
+ ADC082_VOLTAGE_CHANNEL(0),
+ ADC082_VOLTAGE_CHANNEL(1),
+};
+
+static const struct iio_chan_spec adc102s021_channels[] = {
+ ADC102_VOLTAGE_CHANNEL(0),
+ ADC102_VOLTAGE_CHANNEL(1),
+};
+
static const struct iio_chan_spec adc122s021_channels[] = {
ADC128_VOLTAGE_CHANNEL(0),
ADC128_VOLTAGE_CHANNEL(1),
@@ -137,6 +164,18 @@ static const struct iio_chan_spec adc128s052_channels[] = {
static const char * const bd79104_regulators[] = { "iovdd" };
+static const struct adc128_configuration adc082s021_config = {
+ .channels = adc082s021_channels,
+ .num_channels = ARRAY_SIZE(adc082s021_channels),
+ .refname = "vref",
+};
+
+static const struct adc128_configuration adc102s021_config = {
+ .channels = adc102s021_channels,
+ .num_channels = ARRAY_SIZE(adc102s021_channels),
+ .refname = "vref",
+};
+
static const struct adc128_configuration adc122s021_config = {
.channels = adc122s021_channels,
.num_channels = ARRAY_SIZE(adc122s021_channels),
@@ -217,6 +256,12 @@ static int adc128_probe(struct spi_device *spi)
static const struct of_device_id adc128_of_match[] = {
{ .compatible = "rohm,bd79104", .data = &bd79104_config },
+ { .compatible = "ti,adc082s021", .data = &adc082s021_config },
+ { .compatible = "ti,adc082s051", .data = &adc082s021_config },
+ { .compatible = "ti,adc082s101", .data = &adc082s021_config },
+ { .compatible = "ti,adc102s021", .data = &adc102s021_config },
+ { .compatible = "ti,adc102s051", .data = &adc102s021_config },
+ { .compatible = "ti,adc102s101", .data = &adc102s021_config },
{ .compatible = "ti,adc122s021", .data = &adc122s021_config },
{ .compatible = "ti,adc122s051", .data = &adc122s021_config },
{ .compatible = "ti,adc122s101", .data = &adc122s021_config },
@@ -229,6 +274,12 @@ static const struct of_device_id adc128_of_match[] = {
MODULE_DEVICE_TABLE(of, adc128_of_match);
static const struct spi_device_id adc128_id[] = {
+ { "adc082s021", (kernel_ulong_t)&adc082s021_config },
+ { "adc082s051", (kernel_ulong_t)&adc082s021_config },
+ { "adc082s101", (kernel_ulong_t)&adc082s021_config },
+ { "adc102s021", (kernel_ulong_t)&adc102s021_config },
+ { "adc102s051", (kernel_ulong_t)&adc102s021_config },
+ { "adc102s101", (kernel_ulong_t)&adc102s021_config },
{ "adc122s021", (kernel_ulong_t)&adc122s021_config },
{ "adc122s051", (kernel_ulong_t)&adc122s021_config },
{ "adc122s101", (kernel_ulong_t)&adc122s021_config },
--
2.34.1On Sat, Jun 14, 2025 at 12:15 PM Sukrut Bellary <sbellary@baylibre.com> wrote: > > The adcxx communicates with a host processor via an SPI/Microwire Bus > interface. The device family responds with 12-bit data, of which the LSB bits > are transmitted by the lower resolution devices as 0. > The unavailable bits are 0 in LSB. > Shift is calculated per resolution and used in scaling and raw data read. > > Lets reuse the driver to support the family of devices with name > ADC<bb><c>S<sss>, where I believe it's incorrect, i.e. it's something like ...S<ss><?>, where <?> is something you need to clarify, and <ss> is definitely a speed in kSPS. > * bb is the resolution in number of bits (8, 10, 12) > * c is the number of channels (1, 2, 4, 8) > * sss is the maximum conversion speed (021 for 200 kSPS, 051 for 500 kSPS > and 101 for 1 MSPS) > > Complete datasheets are available at TI's website here: > https://www.ti.com/lit/ds/symlink/adc<bb><c>s<sss>.pdf > > Tested only with ti-adc102s051 on BegalePlay SBC. > https://www.beagleboard.org/boards/beagleplay ... > * https://www.ti.com/lit/ds/symlink/adc128s052.pdf > * https://www.ti.com/lit/ds/symlink/adc122s021.pdf > * https://www.ti.com/lit/ds/symlink/adc124s021.pdf Forgot to sort out in the previous patch? -- With Best Regards, Andy Shevchenko
On Sat, Jun 14, 2025 at 09:45:43PM +0300, Andy Shevchenko wrote: > On Sat, Jun 14, 2025 at 12:15 PM Sukrut Bellary <sbellary@baylibre.com> wrote: > > > > The adcxx communicates with a host processor via an SPI/Microwire Bus > > interface. The device family responds with 12-bit data, of which the LSB bits > > are transmitted by the lower resolution devices as 0. > > The unavailable bits are 0 in LSB. > > Shift is calculated per resolution and used in scaling and raw data read. > > > > Lets reuse the driver to support the family of devices with name > > ADC<bb><c>S<sss>, where > > I believe it's incorrect, i.e. it's something like ...S<ss><?>, where > <?> is something you need to clarify, and <ss> is definitely a speed > in kSPS. > Thank you for the review. I am not sure about the last s in <sss>. It could be TI's silicon spins versioning. I couldn't find any information about it in any of the datasheets. I can drop the last s or mark it as <ssx> and specify the first two <ss> as maximum speed. > > * bb is the resolution in number of bits (8, 10, 12) > > * c is the number of channels (1, 2, 4, 8) > > * sss is the maximum conversion speed (021 for 200 kSPS, 051 for 500 kSPS > > and 101 for 1 MSPS) > > > > Complete datasheets are available at TI's website here: > > https://www.ti.com/lit/ds/symlink/adc<bb><c>s<sss>.pdf > > > > Tested only with ti-adc102s051 on BegalePlay SBC. > > https://www.beagleboard.org/boards/beagleplay > > ... > > > * https://www.ti.com/lit/ds/symlink/adc128s052.pdf > > * https://www.ti.com/lit/ds/symlink/adc122s021.pdf > > * https://www.ti.com/lit/ds/symlink/adc124s021.pdf > > Forgot to sort out in the previous patch? > I will fix this in respin. > -- > With Best Regards, > Andy Shevchenko
On 6/28/25 6:09 PM, Sukrut Bellary wrote: > On Sat, Jun 14, 2025 at 09:45:43PM +0300, Andy Shevchenko wrote: >> On Sat, Jun 14, 2025 at 12:15 PM Sukrut Bellary <sbellary@baylibre.com> wrote: >>> >>> The adcxx communicates with a host processor via an SPI/Microwire Bus >>> interface. The device family responds with 12-bit data, of which the LSB bits >>> are transmitted by the lower resolution devices as 0. >>> The unavailable bits are 0 in LSB. >>> Shift is calculated per resolution and used in scaling and raw data read. >>> >>> Lets reuse the driver to support the family of devices with name >>> ADC<bb><c>S<sss>, where >> >> I believe it's incorrect, i.e. it's something like ...S<ss><?>, where >> <?> is something you need to clarify, and <ss> is definitely a speed >> in kSPS. >> > Thank you for the review. > I am not sure about the last s in <sss>. > It could be TI's silicon spins versioning. > I couldn't find any information about it in any of the datasheets. > I can drop the last s or mark it as <ssx> and specify the first two <ss> as > maximum speed. > I have a hunch that the last digit has to do with pinout/number of power supplies. adc128s052 has two supplies V_A and V_D while the others only have V_A. If this sounds vaguely familiar, it is because it was discussed today in this thread [1] that Jonathan CC'ed you in. :-) [1]: https://lore.kernel.org/linux-iio/20250628162910.1256b220@jic23-huawei/
On Sun, Jun 29, 2025 at 2:30 AM David Lechner <dlechner@baylibre.com> wrote: > > On 6/28/25 6:09 PM, Sukrut Bellary wrote: > > On Sat, Jun 14, 2025 at 09:45:43PM +0300, Andy Shevchenko wrote: > >> On Sat, Jun 14, 2025 at 12:15 PM Sukrut Bellary <sbellary@baylibre.com> wrote: > >>> > >>> The adcxx communicates with a host processor via an SPI/Microwire Bus > >>> interface. The device family responds with 12-bit data, of which the LSB bits > >>> are transmitted by the lower resolution devices as 0. > >>> The unavailable bits are 0 in LSB. > >>> Shift is calculated per resolution and used in scaling and raw data read. > >>> > >>> Lets reuse the driver to support the family of devices with name > >>> ADC<bb><c>S<sss>, where > >> > >> I believe it's incorrect, i.e. it's something like ...S<ss><?>, where > >> <?> is something you need to clarify, and <ss> is definitely a speed > >> in kSPS. > >> > > Thank you for the review. > > I am not sure about the last s in <sss>. > > It could be TI's silicon spins versioning. > > I couldn't find any information about it in any of the datasheets. > > I can drop the last s or mark it as <ssx> and specify the first two <ss> as > > maximum speed. > > > I have a hunch that the last digit has to do with pinout/number of > power supplies. adc128s052 has two supplies V_A and V_D while the > others only have V_A. > > If this sounds vaguely familiar, it is because it was discussed > today in this thread [1] that Jonathan CC'ed you in. :-) With all this being said, please, switch to <ss><p> and describe <p>, but with the caveat that the <p> is empirically deducted based on what community observes. > [1]: https://lore.kernel.org/linux-iio/20250628162910.1256b220@jic23-huawei/ -- With Best Regards, Andy Shevchenko
On Sun, Jun 29, 2025 at 09:06:47AM +0300, Andy Shevchenko wrote: > On Sun, Jun 29, 2025 at 2:30 AM David Lechner <dlechner@baylibre.com> wrote: > > > > On 6/28/25 6:09 PM, Sukrut Bellary wrote: > > > On Sat, Jun 14, 2025 at 09:45:43PM +0300, Andy Shevchenko wrote: > > >> On Sat, Jun 14, 2025 at 12:15 PM Sukrut Bellary <sbellary@baylibre.com> wrote: > > >>> > > >>> The adcxx communicates with a host processor via an SPI/Microwire Bus > > >>> interface. The device family responds with 12-bit data, of which the LSB bits > > >>> are transmitted by the lower resolution devices as 0. > > >>> The unavailable bits are 0 in LSB. > > >>> Shift is calculated per resolution and used in scaling and raw data read. > > >>> > > >>> Lets reuse the driver to support the family of devices with name > > >>> ADC<bb><c>S<sss>, where > > >> > > >> I believe it's incorrect, i.e. it's something like ...S<ss><?>, where > > >> <?> is something you need to clarify, and <ss> is definitely a speed > > >> in kSPS. > > >> > > > Thank you for the review. > > > I am not sure about the last s in <sss>. > > > It could be TI's silicon spins versioning. > > > I couldn't find any information about it in any of the datasheets. > > > I can drop the last s or mark it as <ssx> and specify the first two <ss> as > > > maximum speed. > > > > > I have a hunch that the last digit has to do with pinout/number of > > power supplies. adc128s052 has two supplies V_A and V_D while the > > others only have V_A. > > > > If this sounds vaguely familiar, it is because it was discussed > > today in this thread [1] that Jonathan CC'ed you in. :-) > > With all this being said, please, switch to <ss><p> and describe <p>, > but with the caveat that the <p> is empirically deducted based on what > community observes. > > > [1]: https://lore.kernel.org/linux-iio/20250628162910.1256b220@jic23-huawei/ > Ok, sure. I will use this in v5. > -- > With Best Regards, > Andy Shevchenko
© 2016 - 2025 Red Hat, Inc.