Hi all,

Thanks for the suggestions.

Actually i am new to SPI,and all related ADC drivers in the latest kernels
are through I2C.i am going to use an temperature module through this adc
connected through SPI.so i think i am going to read the data only,no data
writing is required.

Let us try and see .If any body is having a reference driver for SPI based
ADC,they can share.

Regards

Arjun

On Sun, Feb 14, 2010 at 2:50 AM, Linus Walleij
<linus.ml.walleij-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>wrote:

> 2010/2/13 Jonathan Cameron <kernel-tko9wxEg+fIOOJlXag/Snyp2UmYkHbXO@public.gmane.org>:
>
> >>> can anybody share how to start a spi based ADC linux driver.I am having
> a
> >>> MAXIM 1242 ADC chip.
> >>
> >> The ḱernel does not contain any generic ADC subsystem abstraction
> >> (...)
> >
> > That's not entirely true.  These are covered by the IIO subsystem which
> > is admittedly currently in staging as some elements still need cleaning
> up.
> > (...)
> > ADC drivers are under drivers/staging/iio/adc.
>
> Great stuff. I knew about IIO and then it fell out of my mind, how
> could I...
>
> What strikes me especially about IIO is the underlying assumption, which I
> think ought to be written in clear somewhere where I missed it, and that
> is that all IIO drivers are supposed to deliver values and be controller
> from
> userspace with this nice ABI, and nothing's wrong with that of course.
>
> But I'm hinting about a few in-kernel uses: for AB3100 we have a battery
> charging mechanism, which use a (calibrated) ADC value supporting the
> bulk of the driver in the power/ subsystem.
>
> As it looks today IIO is not intended for the case where another subsystem
> needs to grab and use and ADC for its own purposes. Is this correct or did
> I get it all wrong?
>
> Would you say it'd be a good idea to hack the IIO ADC interface (for
> example) to be used also internally in the kernel, or would that violate
> the idea behind IIO?
>
> If these are disparate categories it would warrant a separate adc/
> subsystem, see.
>
> > Currently all discussions take place on LKML, but we are working on a
> more
> > focused alternative list which I'll announce once it is sorted out.
>
> LKML is just fine with me, for one.
>
> Yours,
> Linus Walleij
>