On 01/24/2013 08:15 PM, Tomasz Figa wrote: > Hi, > > On Thursday 24 of January 2013 19:19:57 Lars-Peter Clausen wrote: >> On 01/24/2013 05:12 PM, Doug Anderson wrote: >>> Lars, >>> >>> Thank you for your comments / thoughts... >> >> Hi, >> >>> On Thu, Jan 24, 2013 at 1:54 AM, Lars-Peter Clausen <lars@xxxxxxxxxx> > wrote: >>>> adc: adc@12D10000 { >>>> >>>> #io-channel-cells = <1>; >>>> io-channel-output-names = "adc1", "adc2", ...; >>>> >>>> ncp15wb473@0 { >>>> >>>> compatible = "ntc,ncp15wb473"; >>>> ... >>>> io-channels = <&adc 0>; // First ADC channel >>> >>> I'm not an expert, but I think the typical way is: >>> * No need to include a handle to &adc. It's logically our parent. In >>> a similar way i2c devices don't specify their parent bus--they are >>> just listed under it. >>> * The "0" should be specified with reg = <0> >> >> The relationship between the IIO sensor device and the consumer device >> is not always a parent child relationship. In this case it makes sense >> to have the ADC as the parent for the thermistors. But for other cases >> this may not be true. E.g. take a touchscreen or power monitoring >> platform device which uses the IIO device to do measurements. > > The policy is to use children with reg property only inside a node > representing a bus controller through which the child device is being > accessed (like I2C, SPI). > > I would see IIO bindings similar to what we have with GPIOs, interrupts or > regulators, so io-channels = <&iio-controller channel> seems fine (or > rather iio-channels) with the node under appropriate parent. IIO is a very Linux specific term, the device tree bindings should be as OS agnostic as possible, so io-channels is probably the better term. > >>> To implement this I'd imagine that we'll need a new API call, right? >>> In this case the thermistor driver won't know the name of the channel. >>> >>> It can find the ADC (the struct device and probably other things) and >>> >>> knows a channel index. Am I understanding properly? >> >> This can be done by adding a new api call, but it would be best if both >> dt and non-dt based consumers can use the same function. I outlined one >> possible solution how this can be done in the previous mail to Naveen. > > In case of the solution I mentioned, implementation would be almost > identical to what is done with GPIOs (see drivers/gpio/gpiolib-of.c). Although similar to the GPIO bindings, the clk bindings are in my opinion an even better example. - Lars -- 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