Re: iio: adc: anyone working on TI ADS7066?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 22 Mar 2021 21:39:17 -0700
Drew Fustini <drew@xxxxxxxxxxxxxxx> wrote:

> On Sat, Mar 20, 2021 at 06:26:24PM +0000, Jonathan Cameron wrote:
> > On Fri, 19 Mar 2021 20:52:34 -0700
> > Drew Fustini <drew@xxxxxxxxxxxxxxx> wrote:
> >   
> > > I have a board with a TI ADS7066 8-channel ADC [1] that I want to get
> > > working in Linux.  I see there is already driver support in iio for
> > > ADS1015, ADS79xx, ADS8344, ADS868x and ADS124S0x.
> > > 
> > > Is anyone already working with the ADS7066 or a similar part in that
> > > series?
> > > 
> > > If not, I'll take one of the existing TI drivers as a template for the
> > > ADS7066 driver.
> > > 
> > > Thank you,
> > > Drew  
> > 
> > Hi Drew,
> > 
> > I've not seen anything for this part.
> > 
> > From a 10 second glance at the data sheet I see it's capable of
> > ADC / GPIO on each pin.   If you plan to support that functionality
> > at somepoint make sure to define dt bindings and similar to specify
> > which channels are enabled and dynamically create the iio_chan_spec
> > array to match.  It can be a bit ugly to retrofit later.  
> 
> Thanks for the feedback.  The GPIO functionality is not used on the
> custom hardware that I have, so I am thinking I would only implement
> the ADC functionality.  Is that too short sighted?

That's fine.  We'd just end up with a DT binding that had a default
of "no channels specified == all ADC".

It might turn out you want to do per channel settings anyway in DT.

> 
> > Oh. It does daisy chaining as well. That is always fun to support
> > though I guess you may well not have it wired up to do that.
> > Oversampling as well - though that looks nice and simple for once.  
> 
> The hardware I have has two ADS7066 wired up in parallel so I don't
> think I would be looking at implementing dasiy chain initially.
> 
> Is that ok just implement what I am actually using or is the preference
> to have a driver implement all the latent functionality before it would
> be merged?

Absolutely fine to do just what you need initially then others can add
the fun bells and whistles when they need them.

Only exception is the binding doc should try to reflect what the hardware
can support even if the driver doesn't use it.  This applies to things
like interrupt lines or regulators.

Jonathan

> 
> Thanks,
> Drew




[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Input]     [Linux Kernel]     [Linux SCSI]     [X.org]

  Powered by Linux