On 20.05.2016 03:09, Matt Ranostay wrote:
On Thu, May 19, 2016 at 1:25 AM, Daniel Baluta
<daniel.baluta@xxxxxxxxx> wrote:
On Thu, May 19, 2016 at 8:58 AM, Jonathan Cameron
<jic23@xxxxxxxxxxxxxxxxxxxxx> wrote:
On 19 May 2016 04:38:09 BST, Matt Ranostay <mranostay@xxxxxxxxx>
wrote:
Jonathan et al,
Shortly going to be doing a project that requires an iio_map mapping
for using an iio channel input from an ADC. I've notice all seem to
be platform_data or hardcoded due to it being a SoC or statically
known MFD mapping.
For my application it isn't correct to create an hardcoded iio_map
mapping with the ADC driver (ti-ads1015) since nobody else would
care
about it, and wouldn't help in the case of multiple instances of the
same ADC.
But I would rather avoid the technical debt and uglyness of using a
board file.
What would be the best way via ACPI and DT to define channel
mappings
between name, consumers, and consumer channel names? Thought I
request
input here before I make any core iio subsystem changes.
Thanks,
Matt
Whilst we have gotten a fair bit of grief over the Linux specific
nature of the
binding, iio-hwmon does have bindings for this sort of case.
Mid term I have been wondering about taking it as far as having a
configfs
interface to create such soft hardware mappings at runtime....
+1 for configfs, would be the most flexible way for users.
Then I suppose the consumer driver would need to return -EIO or
similar until the user has setup the mapping with configfs?
Probably instantiate the consumer driver in configfs as well. Would be
tricky
if the consumer has real hardware as well though. If that were the case
then
yes would indeed need to return -EIO. Configfs is find for the data
reformatting
type of consumers. In this world ultimately we might have data fusing
drivers
+ filters etc as well as the more direct input, hwmon, thermal, battery
etc
bridges.
In that case though I thing devicetree bindings are representing real
things
in some sense so make more sense.
Also I suppose we could add configfs setup for the gpio interrupt
trigger that uses platform data currently. Although not sure it would
be sane to be touching interrupt-controllers from userspace.
We had a discussion about this a while ago and concluded we'd need
something
like a device tree binding that said 'this gpio can be used for this'
then
allow specific set up of what it was used for in userspace.
--
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
--
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
