On Thu, Feb 09, 2012 at 06:34:34PM +0000, Jonathan Cameron wrote: > On 02/09/2012 06:10 PM, Greg KH wrote: > > On Sun, Jan 29, 2012 at 11:46:50AM +0000, Jonathan Cameron wrote: > >> From: Jonathan Cameron <jic23@xxxxxxxxx> > >> > >> Lifted from proposal for in kernel interface built on the out of staging > >> branch. > >> > >> Two elements here: > >> * Map as defined in "inkern.h" > >> * Matching code to actually get the iio_dev and channel > >> that we want from the global list of IIO devices. > >> > >> V2: As per Greg KH suggestion, move over to registration by passing > >> the tables into the provider drivers (how regulator does it). > >> This does not prevent us using the original more flexible approach > >> if at a later date there is a usecase that demands it. > >> > >> Signed-off-by: Jonathan Cameron <jic23@xxxxxxxxxx> > >> --- > >> drivers/staging/iio/Kconfig | 7 +- > >> drivers/staging/iio/Makefile | 2 +- > >> drivers/staging/iio/consumer.h | 103 +++++++++++++ > >> drivers/staging/iio/driver.h | 34 ++++ > >> drivers/staging/iio/iio_core.h | 3 + > >> drivers/staging/iio/industrialio-core.c | 2 +- > >> drivers/staging/iio/inkern.c | 256 +++++++++++++++++++++++++++++++ > >> drivers/staging/iio/machine.h | 30 ++++ > >> 8 files changed, 434 insertions(+), 3 deletions(-) > >> > >> diff --git a/drivers/staging/iio/Kconfig b/drivers/staging/iio/Kconfig > >> index 90162aa..65c2a8e 100644 > >> --- a/drivers/staging/iio/Kconfig > >> +++ b/drivers/staging/iio/Kconfig > >> @@ -10,8 +10,14 @@ menuconfig IIO > >> drivers for many different types of embedded sensors using a > >> number of different physical interfaces (i2c, spi, etc). See > >> drivers/staging/iio/Documentation for more information. > >> + > >> if IIO > >> > >> +config IIO_INKERN > >> + bool "In kernel support for IIO" > >> + help > >> + Support in kernel users of IIO device drivers. > > > > Of course you want this, all of the code in the kernel.org tree is "in > > kernel users" :) > > > > Seriously, I still fail to understand what is so special here that makes > > this a totally different design pattern from all other busses, > > especially when you aren't even a bus at all, but rather a "interface" > > to userspace for different device types. > > > > Why can't a driver just depend on this interface type, like all other > > interface types are, that way the built-in vs. as-a-module issues are > > all handled "automagically" by the config and build system. > > > Best simple comparison is with regulators. They provide voltages to > consumers; This iio stuff is about providing readings of voltage > (simplifying massively) to other users. All these adc's need > their own driver to provide that voltage to those that care. > The client drivers just want to ask 'what is the voltage?'. > > So to do it as a conventional module dependency we need a separate > dependency for every IIO device capable of providing a voltage > to every driver that might want to read one. > > There are a number of common use cases or which I'll list a few here. > a) Soc adc's. Typical soc might have an 8 channel adc. On a typical > board 2 channels are used for input (touchscreen), 2 for monitoring the > battery and > 4 brought out to an edge connector. Which are used for what and how > many of each are used is entirely under control of the board designer. > Thus we could have each SoC type adc driver handle the logic necessary > to register an input device, a hwmon device (and perhaps an IIO device). > This is the usecase that Mark Brown originally brought up. Right now > Arnd is blocking some SoC adc drivers that do this internally and > sending them in the direction of IIO. > > b) High spec devices used for input. This one we originally proposed > doing via a bridge in userspace and piping back in via uinput. > When I say high spec I meant 300+ dolar imu's etc. People do it > for niche systems, but the part will never primarily be used for this > so normally sits better in IIO, If we have borderline devices, they > will end up in IIO. If this stuff had been in place earlier (as > Dmitry pushed for) some of the existing parts in input might > never have been accepted. > > c) The other side is generating signals. People use arbitary waveform > generators to produce inputs for all sort of strange devices. > > So the question was whether to sit another subsystem under hwmon, input > IIO etc, or to have IIO evolve into that underlying subsystem. Given > with the channel mapping stuff we already had all the infrastructure > in place to do this, a vague consensus said do it in IIO. > > Now in many ways we'd love to have the IIO userspace stuff act as > just another client, but that's a way off yet basically due to the huge > number of special cases that would need to be handled. I'm personally > not yet sure that will ever happen. > > So in summary we don't do this as a simple dependency because of the > combinatorial explosion in dependencies that would be needed and the > connection modules that would be needed to glue it all together > vs what is a simple mapping that will sit nicely in device tree etc. So, would the "keep looping until all dependancies are met" patches from Grant that have been floating around for a while, solve this issue? Modules would properly initialize only when the needed other bits are present, which solves the problems the regulators and other drivers have today. If so, then I suggest we get that code into the tree soon, and then all of this "wierd" logic would go away, right? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
