Prev: [PATCH 12/14] MTD: add few workarounds to nand system for SmartMedia/xD chips.
Next: Hung task - sync - 2.6.33-rc7 w/md6 multicore rebuild in process
From: Linus Walleij on 13 Feb 2010 09:00 2010/2/13 arjun rath <rath.arjun(a)gmail.com>: > 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 (I think it would be good if it did), instead most drivers using ADC have their ADC portions stored inside a driver for something else, e.g. drivers/hwmon for ADCs used in temperature monitoring, or drivers/power for ADCs used in monitoring of currents and voltages for power supplies/batteries. This is a bit bad for driving a generic ADC like this using spidev and, even if it was to be accessed from userspace only, having it under drivers/spi is rather counterintuitive, what happens when the next ADC using I2C turns up? drivers/i2c/chips? I would suggest creating subsystem drivers/adc if you have time and energy, other ideas? Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jonathan Cameron on 13 Feb 2010 12:00 Hi Arjun and Linus, > >> 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 (I > think it would be good if it did), instead most drivers using ADC have > their ADC portions stored inside a driver for something else, e.g. > drivers/hwmon for ADCs used in temperature monitoring, or > drivers/power for ADCs used in monitoring of currents and voltages > for power supplies/batteries. 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. As a quick summary of IIO. Except for a few bits of management code, basic drivers look pretty much like hwmon. An example in tree is the tsl2563 driver (under drivers/staging/iio/light) though that one is moving out to ALS when Amit has a chance to sort out the relevant patch. For more advanced drivers (only add support if you have a use as it is a fair bit more complex) we have support for hardware and software ring buffers, an events interface which is more or less the equivalent of input without cross device aggregation. ADC drivers are under drivers/staging/iio/adc. I think in mainline we still only have a max1363 driver which covers a lot of the i2c maxim parts (more to add after testing). There are a couple more iio using adc drivers in a blackfin tree at: http://blackfin.uclinux.org/gf/project/linux-kernel/scmsvn/ (Note these are very much under development!) Though from a quick look all of them are i2c based. For an spi equivalent, take a look at drivers/staging/iio/accel/ where we have the kxsd9 driver (which is another simple example of an IIO driver) + lis3l02dq and sca3000 which are on the heavy side (probably not a good place to start). For a general list of devices people are working on, or at least have and intend to work on, take a look at: https://sourceforge.net/apps/mediawiki/iioutils/index.php?title=Device_List Just for reference, the big up coming change in IIO is a new userspace ABI to clean things up before we get too many drivers using the somewhat messy old version. It will still be a little while before we have cleaned up the more controversial issues in the core (none of which touch on the simpler drivers) but with a steady increase in active developers things are speeding up. So in conclusion, if your use of the driver doesn't fall neatly under hwmon or elsewhere, and you don't mind writing for a subsystem which isn't entirely polished and may change, then IIO might be what you are looking for. 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. Just taking a quick and dirty look at the datasheet for the MAX1242: * You might have fun getting the required conversion delay before a read. (Chip select must be enabled for 7.5 microsecs before the clock starts) * Otherwise it is a nice simple chip with no actual control of anything. Perhaps you can supply some information on your application to guide an continuation of this discussion? Thanks, Jonathan Cameron > > This is a bit bad for driving a generic ADC like this using spidev and, > even if it was to be accessed from userspace only, having it under > drivers/spi is rather counterintuitive, what happens when the next ADC > using I2C turns up? drivers/i2c/chips? > > I would suggest creating subsystem drivers/adc if you have time and > energy, other ideas? > > Linus Walleij > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mike Frysinger on 13 Feb 2010 12:10 On Sat, Feb 13, 2010 at 11:51, Jonathan Cameron wrote: > http://blackfin.uclinux.org/gf/project/linux-kernel/scmsvn/ people who like git can always use: http://blackfin.uclinux.org/git/?p=readonly-mirrors/linux-kernel.git;a=summary -mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Walleij on 13 Feb 2010 16:30 2010/2/13 Jonathan Cameron <kernel(a)jic23.retrosnub.co.uk>: >>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: jassi brar on 15 Feb 2010 04:00
On Mon, Feb 15, 2010 at 1:29 PM, arjun rath <rath.arjun(a)gmail.com> wrote: > Let us try and see .If any body is having a reference driver for SPI based > ADC,they can share. Don't think you need to anything 'ADC specific' all u need is to _use_ your SPI driver. grep for spi_sync in linux/drivers/ and refer to any spi user driver. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |