ADS1018 ADC driver
I am in the process of starting a new device driver for the ADS1018 ADC. Before starting I did some research as whether similar drivers exist in the kernel.
It appears that ADC drivers are in both hwmon and iio/adc. The closest drivers to the device mentioned are in hwmon.
Where is the best place for this new ADC driver?
Shouldn't ADCs all be in the same subsystem?
Has there been any effort to unify or distiguish where drivers should go?
Hi Michael,
Quoted 7 lines · Michael Welling
I am in the process of starting a new device driver for the ADS1018 ADC. Before starting I did some research as whether similar drivers exist in the kernel.
It appears that ADC drivers are in both hwmon and iio/adc. The closest drivers to the device mentioned are in hwmon.
Where is the best place for this new ADC driver?
Your call. You could add support for the chip to hwmon/ads1015.c, or you could write a new driver in iio/adc. If you do the latter, maybe you can also include support for ads1015 and ads1115, so we can ultimately remove the ads1015 driver from hwmon.
Quoted 3 lines
Shouldn't ADCs all be in the same subsystem?
Has there been any effort to unify or distiguish where drivers should go?
In general, ADCs primarily used for the purpose of ADC measurements would go into iio, and ADCs used primarily for hardware monitoring would go into hwmon.
There are no strict rules, though, and this is not always black-and-white. I am sure there are some drivers in hwmon which would be better suited for iio. Primarily that would be the case because the iio subsystem is relatively new, and such drivers did not have a home other than hwmon until a couple of years ago. If you find any drivers in hwmon which you think should be moved, please feel free to do the conversion.
Guenter
Quoted 6 lines · Guenter Roeck
Hi Michael,
Quoted 3 lines · Michael Welling
I am in the process of starting a new device driver for the ADS1018 ADC. Before starting I did some research as whether similar drivers exist in the kernel.
Quoted 8 lines
Quoted 4 lines
It appears that ADC drivers are in both hwmon and iio/adc. The closest drivers to the device mentioned are in hwmon.
Where is the best place for this new ADC driver?
Your call. You could add support for the chip to
hwmon/ads1015.c, or you could write a new driver in iio/adc. If you do the latter, maybe you can also include support for ads1015 and ads1115, so we can ultimately remove the ads1015 driver from hwmon.
Guenter,
Though the iio route may be more work I have a feeling the driver will be better off there. The use of regmap support should allow for both the SPI and I2C version to coexist.
I will try my best to implement the driver in a way that can cover these other I2C devices mentioned.
Quoted 7 lines
Quoted 4 lines
Shouldn't ADCs all be in the same subsystem?
Has there been any effort to unify or distiguish where drivers should go?In general, ADCs primarily used for the purpose of ADC measurements would go into iio, and ADCs used primarily for hardware monitoring would go into hwmon.
Quoted 6 lines
There are no strict rules, though, and this is not always black-and-white. I am sure there are some drivers in hwmon which would be better suited for iio. Primarily that would be the case because the iio subsystem is relatively new, and such drivers did not have a home other than hwmon until a couple of years ago. If you find any drivers in hwmon which you think should be moved, please feel free to do the conversion.
Has anyone considered an alternative implementation for generic ADCs?
I was thinking about an implementation similar to gpiolib whereas ADCs can be resources for other drivers.
For instance, ADC lines could be registered to a joystick driver and used to provide analog stick or pressure sensitive button. Another example could be registering analog lines for an analog accelerometer driver.
Is this a bad idea?
-Michael
Quoted 3 lines
Guenter
Michael,
Quoted 16 lines · Michael Welling
Quoted 6 lines · Guenter Roeck
Hi Michael,
Quoted 3 lines · Michael Welling
I am in the process of starting a new device driver for the ADS1018 ADC. Before starting I did some research as whether similar drivers exist in the kernel.
Quoted 8 lines
Quoted 4 lines
It appears that ADC drivers are in both hwmon and iio/adc. The closest drivers to the device mentioned are in hwmon.
Where is the best place for this new ADC driver?
Your call. You could add support for the chip to
hwmon/ads1015.c, or you could write a new driver in iio/adc. If you do the latter, maybe you can also include support for ads1015 and ads1115, so we can ultimately remove the ads1015 driver from hwmon.
Quoted 6 lines
Guenter,
Though the iio route may be more work I have a feeling the driver will be better off there. The use of regmap support should allow for both the SPI and I2C version to coexist.
Sorry, you lost me. There is no correlation between iio/hwmon and regmap. regmap can be (and is) used with both subsystems. Please clarify.
Quoted 19 lines
I will try my best to implement the driver in a way that can cover these other I2C devices mentioned.
Quoted 7 lines
Quoted 4 lines
Shouldn't ADCs all be in the same subsystem?
Has there been any effort to unify or distiguish where drivers should go?In general, ADCs primarily used for the purpose of ADC measurements would go into iio, and ADCs used primarily for hardware monitoring would go into hwmon.
Quoted 6 lines
There are no strict rules, though, and this is not always black-and-white. I am sure there are some drivers in hwmon which would be better suited for iio. Primarily that would be the case because the iio subsystem is relatively new, and such drivers did not have a home other than hwmon until a couple of years ago. If you find any drivers in hwmon which you think should be moved, please feel free to do the conversion.
Has anyone considered an alternative implementation for generic ADCs?
Quoted 9 lines
I was thinking about an implementation similar to gpiolib whereas ADCs can be resources for other drivers.
For instance, ADC lines could be registered to a joystick driver and used to provide analog stick or pressure sensitive button. Another example could be registering analog lines for an analog accelerometer driver.
Is this a bad idea?
I am quite sure that is possible. If it isn't currently supported, it waits for someone with a use case to implement it.
Guenter
Quoted 27 lines · Guenter Roeck
Michael,
Quoted 5 lines · Michael Welling
Quoted 4 lines · Guenter Roeck
Hi Michael,
Quoted 1 line · Michael Welling
I am in the process of starting a new device driver for the ADS1018
ADC.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Before starting I did some research as whether similar drivers
exist in the kernel.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
It appears that ADC drivers are in both hwmon and iio/adc. The
closest drivers to
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
the device mentioned are in hwmon.
Where is the best place for this new ADC driver?
Your call. You could add support for the chip to
hwmon/ads1015.c, oryou could write
Quoted 1 line
Quoted 1 line
a new driver in iio/adc. If you do the latter, maybe you can also
include support
Quoted 1 line
Quoted 1 line
for ads1015 and ads1115, so we can ultimately remove the ads1015
driver from hwmon.
Quoted 3 lines
Guenter,
Quoted 8 lines
Quoted 4 lines
Though the iio route may be more work I have a feeling the driver will be better off there. The use of regmap support should allow for both the SPI and I2C version to coexist.
Sorry, you lost me. There is no correlation between iio/hwmon and regmap.
regmap can be (and is) used with both subsystems. Please clarify.
I was thinking regmap could abstract the differences between the I2C and SPI devices simplifying the combination of the drivers into a single driver.
Looking at the datasheets this would not be as easy as thought. We will see when I get into the coding.
Quoted 34 lines
Quoted 6 lines
I will try my best to implement the driver in a way that can cover these other I2C devices mentioned.
Quoted 3 lines
Quoted 3 lines
Shouldn't ADCs all be in the same subsystem?
Has there been any effort to unify or distiguish where driversshould go?
Quoted 2 lines
Quoted 2 lines
Quoted 1 line
In general, ADCs primarily used for the purpose of ADC measurements
would go
Quoted 1 line
Quoted 1 line
into iio, and ADCs used primarily for hardware monitoring would go
into hwmon.
Quoted 2 lines
Quoted 2 lines
There are no strict rules, though, and this is not always
black-and-white.
Quoted 1 line
Quoted 1 line
I am sure there are some drivers in hwmon which would be better
suited for iio.
Quoted 1 line
Quoted 1 line
Primarily that would be the case because the iio subsystem is
relatively new,
Quoted 1 line
Quoted 1 line
and such drivers did not have a home other than hwmon until a couple
of years ago.
Quoted 1 line
Quoted 1 line
If you find any drivers in hwmon which you think should be moved,
please feel free
Quoted 5 lines
Quoted 1 line
to do the conversion.
Has anyone considered an alternative implementation for generic ADCs?
I was thinking about an implementation similar to gpiolib whereas
ADCs can be
Quoted 3 lines
resources for other drivers.
For instance, ADC lines could be registered to a joystick driver and
used to provide
Quoted 1 line
analog stick or pressure sensitive button. Another example could be
Quoted 8 lines
registering analog
Quoted 4 lines
lines for an analog accelerometer driver.
Is this a bad idea?
I am quite sure that is possible. If it isn't currently supported, it waits for someone
with a use case to implement it.
Okay. Well if more interest is expressed I might look into implementing it.
Quoted 2 lines
Guenter
Signature · 1 line
Sent from my Android device with K-9 Mail. Please excuse my brevity.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 5 lines · Jonathan Cameron
There is a rather slow process to separate entirely the back and front end
of IIO. This would get you to what you are describing (with a bit of front end work to set up the mapping to joystick axes). This was driven initially by the soc guys who have one multichannel ADC doing a dozen unconnected things. Mark Brown in particular.
Quoted 7 lines
Right now all IIO drivers still instantiate the userspace interface (for now users
who don't care ignore it). We then had in kernel channel mappings to allow client drivers access to most OHIO hardware interfaces. The classic example is iio-hwmon though there are other users all over the place. The input bridge (which is too simple to support you joystick example at the mo) has been languishing outside
Mainline for years due issues with the mapping and instantiation interfaces.
This is further along than I realized.
Looking at inkern.c and drivers that use the interface should get me started.
I will also look further into the input bridge and uinput.
Quoted 17 lines
Hopefully the addition of config fs support for instantiation of 'virtual'
hardware in IIO will finally give us a way around that.Anyhow what works now:
1. polled channel value and basic property reading (eg iio-hwmon)
2. Pushed (historically called buffered in IIO) data flows with channel demux (so clients only get a stream of data covering what they requested. Actually the demux is widely used by the IIO frontend as well.
What is missing.
1. Event support for stuff like thresholds. Not hard to add but not done yet. Could initially skip demuxing events and specify filtering must be done in the client.Interface gets a little fiddly as necessary to lock which events are enabled in some
cases to stop another client disabling them as a side effect. Lots of hardware has complex constraints on which events are enabled. Traditionally with only
one userspace this was userspace problem to deal with!
Quoted 8 lines
2. Property range exporting. This is useful for IIO userspace as well.
3. Allowing IIO on top of iio.
4. Dropping always having IIO userspace.
Mostly this work has stalled as I have very little time to work on it anymore. If you are interested then ask for more details on any of the above.
First I will focus on constructing the new driver for the ADS1018.
Which of these missing pieces would find the most use?
Quoted 5 lines
Quoted 4 lines
Quoted 4 lines
Guenter
Quoted 39 lines · Michael Welling
Quoted 5 lines · Jonathan Cameron
There is a rather slow process to separate entirely the back and front end
of IIO. This would get you to what you are describing (with a bit of front end work to set up the mapping to joystick axes). This was driven initially by the soc guys who have one multichannel ADC doing a dozen unconnected things. Mark Brown in particular.Quoted 7 lines
Right now all IIO drivers still instantiate the userspace interface (for now users
who don't care ignore it). We then had in kernel channel mappings to allow client drivers access to most OHIO hardware interfaces. The classic example is iio-hwmon though there are other users all over the place. The input bridge (which is too simple to support you joystick example at the mo) has been languishing outside
Mainline for years due issues with the mapping and instantiation interfaces.This is further along than I realized.
Looking at
inkern.cand drivers that use the interface should get me started.I will also look further into the input bridge and uinput.
Quoted 19 lines
Hopefully the addition of config fs support for instantiation of 'virtual'
hardware in IIO will finally give us a way around that.Anyhow what works now:
1. polled channel value and basic property reading (eg iio-hwmon)
2. Pushed (historically called buffered in IIO) data flows with channel demux (so clients only get a stream of data covering what they requested. Actually the demux is widely used by the IIO frontend as well.
What is missing.
1. Event support for stuff like thresholds. Not hard to add but not done yet. Could initially skip demuxing events and specify filtering must be done in the client.Interface gets a little fiddly as necessary to lock which events are enabled in some
cases to stop another client disabling them as a side effect. Lots of hardware has complex constraints on which events are enabled. Traditionally with only
one userspace this was userspace problem to deal with!2. Property range exporting. This is useful for IIO userspace as well.
Quoted 9 lines
Quoted 6 lines
3. Allowing IIO on top of iio.
4. Dropping always having IIO userspace.
Mostly this work has stalled as I have very little time to work on it anymore. If you are interested then ask for more details on any of the above.
First I will focus on constructing the new driver for the ADS1018.
It appears that the hardware is being revised and a different ADC is going to be used on the revision. That mean this driver fell off of my queue.
I was kind of looking forward writing it... oh well.
Sorry for the noise.
Quoted 7 lines
Which of these missing pieces would find the most use?
Quoted 5 lines
Quoted 4 lines
Quoted 4 lines
Guenter