Re: [spi-devel-general] Accelerometer, Gyros and ADC's etc withinthe kernel.

[Jonathan Cameron]

Hi Anton
> > Typical requirements within an application include simply polling for 
> > current
> > readings, and using device triggered interrupts to grab data 
> > continuously to a
> > ring buffer, for collection by suitable userspace code.  Obviously it 
> > would be
> > desirable to standardize sysfs controls for various calibration 
> > parameters as
> > much as possible across the various devices.
> >     
>
> Also, I'd mention that most ADC devices could report in "bunched" mode,
> i.e.
>
> 1. Request ADC readings from pins X, Y, Z1, Z2.
> 2. Wait for single IRQ
> 3. Read all the results
>   
Good point. I guess it's going to be a while before we work out an 
anywhere near
exhaustive list of such events that we might want to be able to control.
> At handhelds.org, we've wrote quite good (I think) ADC subsystem,
> that keeps in mind ADC capabilities. It implements two interfaces:
> in-kernel (e.g. for touchscreen drivers), and userspace interface via
> sysfs. I was planning to implement drivers/input/ interface too.
> I always don't find time to clean it up and submit, though.
>   
I know that feeling!
> Here is ADC subsystem itself:
> http://handhelds.org/cgi-bin/cvsweb.cgi/~checkout~/linux/kernel26/drivers/misc/adc/adc.c
> http://handhelds.org/cgi-bin/cvsweb.cgi/~checkout~/linux/kernel26/include/linux/adc.h
> ^ It is in drivers/misc/, but I think better placement would be
>   drivers/adc.
>   
Looking at the code (briefly admittedly, I'll have a closer look 
tomorrow) it looks like a nice simple and
effective interface. 

The question here, is what functionality of the system under discussion 
does it fulfill.  Again we are in the
territory of possibly having multiple drivers for a device depending on 
how it is being used in the kernel.
Not ideal, but may in fact be more maintainable in the long run.

The sysfs interface looks similar to that I was intending to implement, 
but obviously for your application you
don't need any of the buffering support etc and it makes sense to keep 
everything as simple as possible.

Perhaps if we aim to keep in mind the possibility of combining your ADC 
system with a more general
input device system, it may make sense to do so at a later stage. 

Anything I write is certainly going to share a considerable amount of 
functionality and approach with your code.
> Some drivers for this subsystem:
> http://handhelds.org/cgi-bin/cvsweb.cgi/~checkout~/linux/kernel26/drivers/misc/adc/ads7846_adc_ssp.c
> ^ ADC driver for ADS7846 chips (HP iPaq hx4700 and some HTC phones, the
>   driver is using SSP subsystem, switching it to the SPI is still in my enless
>   TODO list).
>   
I'll keep these part in mind, as a the moment adding any component for 
testing involves me getting my soldering iron out
and I hate soldering!

> http://handhelds.org/cgi-bin/cvsweb.cgi/~checkout~/linux/kernel26/drivers/misc/adc/samcop_adc.c
> ^ SAMCOP (HP iPaq H5xxx) ADC driver.
>
> http://handhelds.org/cgi-bin/cvsweb.cgi/~checkout~/linux/kernel26/drivers/misc/adc/tsc2200_adc_ssp.c
> ^ TSC2200 ADC driver (used AFAIK in some HTC phones, or ASUS handhelds).
>
> http://handhelds.org/cgi-bin/cvsweb.cgi/~checkout~/linux/kernel26/drivers/misc/adc/ad7877.c
> ^ AD7877 ADC driver (HTC phones too, IIRC).
>
> Now, The Generic ADC Touchscreen Driver (tested to work quite good with all
> above ADC drivers on appropriate hardware):
> http://handhelds.org/cgi-bin/cvsweb.cgi/~checkout~/linux/kernel26/drivers/input/touchscreen/ts-adc.c
>
> And finally, ADC Battery driver ("backup" batteries in the iPaq devices
> usually report their voltage via ADC chip, the same used by the
> touchscreen).
> http://handhelds.org/cgi-bin/cvsweb.cgi/~checkout~/linux/kernel26/drivers/power/adc_battery.c
>
> p.s.
> I have more recent (for current Linus' tree) code for ADC subsystem, but
> it still needs some love to be submittable.
>   
Thanks.  I'll have a look at the stuff above and pester you if I need a 
more recent version.

Jonathan


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/