ADS1018 ADC driver

ADS1018 ADC driver

[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?
Shouldn't ADCs all be in the same subsystem?
Has there been any effort to unify or distiguish where drivers should go?

Re: ADS1018 ADC driver

[Guenter Roeck]

Hi Michael,

On 09/21/2015 03:06 PM, Michael Welling wrote:
> 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.

> 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

Re: ADS1018 ADC driver

[Michael Welling]

On Mon, Sep 21, 2015 at 06:04:36PM -0700, Guenter Roeck wrote:
> Hi Michael,
> 
> On 09/21/2015 03:06 PM, Michael Welling wrote:
> >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.

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.

> 
> >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.

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

> 
> Guenter
> 

Re: ADS1018 ADC driver

[Guenter Roeck]

Michael,

On 09/21/2015 06:27 PM, Michael Welling wrote:
> On Mon, Sep 21, 2015 at 06:04:36PM -0700, Guenter Roeck wrote:
>> Hi Michael,
>>
>> On 09/21/2015 03:06 PM, Michael Welling wrote:
>>> 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.
>
> 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.

> I will try my best to implement the driver in a way that
> can cover these other I2C devices mentioned.
>
>>
>>> 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.
>
> 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?
>
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

Re: ADS1018 ADC driver

[mwelling]

On September 21, 2015 9:04:22 PM CDT, Guenter Roeck <linux@roeck-us.net> wrote:
>Michael,
>
>On 09/21/2015 06:27 PM, Michael Welling wrote:
>> On Mon, Sep 21, 2015 at 06:04:36PM -0700, Guenter Roeck wrote:
>>> Hi Michael,
>>>
>>> On 09/21/2015 03:06 PM, Michael Welling wrote:
>>>> 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.
>>
>> 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.
>

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.

>> I will try my best to implement the driver in a way that
>> can cover these other I2C devices mentioned.
>>
>>>
>>>> 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.
>>
>> 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?
>>
>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.

>
>Guenter

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: ADS1018 ADC driver

[Michael Welling]

On Wed, Sep 23, 2015 at 06:59:56AM +0100, Jonathan Cameron wrote:
> 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.
> 
> 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.

> 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.
> 
> 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?

> 
> >
> >>
> >>Guenter
>

Re: ADS1018 ADC driver

[Michael Welling]

On Wed, Sep 23, 2015 at 02:45:14AM -0500, Michael Welling wrote:
> On Wed, Sep 23, 2015 at 06:59:56AM +0100, Jonathan Cameron wrote:
> > 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.
> > 
> > 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.
> 
> > 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.
> > 
> > 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.

> Which of these missing pieces would find the most use?
> 
> > 
> > >
> > >>
> > >>Guenter
> >