Le 05/10/2013 11:35, Lars-Peter Clausen a écrit :
On 10/05/2013 11:18 AM, leroy christophe wrote:
Le 05/10/2013 10:41, Lars-Peter Clausen a écrit :
On 10/05/2013 10:21 AM, Christophe Leroy wrote:
+ .consumer_channel = "channel_0",
+ .adc_channel_label = "0",
+ },
+ {
+ .consumer_dev_name = AD7923_NAME,
+ .consumer_channel = "channel_1",
+ .adc_channel_label = "1",
+ },
+ {
+ .consumer_dev_name = AD7923_NAME,
+ .consumer_channel = "channel_2",
+ .adc_channel_label = "2",
+ },
+ {
+ .consumer_dev_name = AD7923_NAME,
+ .consumer_channel = "channel_3",
+ .adc_channel_label = "3",
+ },
+ { }
+};
This is a mapping between channel names of the provider between the channel
names of the consumer. So it is specific to a certain combination of
consumer and provider and usually depend on how things are physically wired
on your board. As such there can be no generic mapping and this needs to go
into your machine/board driver. The mapping is usually passed to the IIO
driver via its platform data.
So e.g. imagine you have a provider like this driver and you have a consumer
that has a "voltage" channel. And on your board channel 3 of the ADC is what
you want to route to that consumer. Then your mapping would look like this:
{
.consumer_dev_name = "your_consumer_device.1",
.consumer_channel = "voltage",
.adc_channel_label = "AIN3",
}
And in your consumer driver you'd do:
channel = iio_channel_get(dev, "voltage");
Thanks for the explanation.
Can the mapping be retrieved via of_platform ?
Indeed, the only exemple I found was in the lp8788_adc driver, which
includes iio/machine.h and declares a default mapping, but it is based on
platform_data, not of_platform.
If you are using device tree you can specify the mapping inside the
devicetree. Have a look at
Documentation/devicetree/bindings/iio/iio-bindings.txt
Yes, I saw that. Is there anything that shall be done in the driver to
support it, or is it automatic ?
Christophe
--
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