[RFC] dynamic iio consumer channel mapping

[RFC] dynamic iio consumer channel mapping

[Matt Ranostay]

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

Re: [RFC] dynamic iio consumer channel mapping

[Jonathan Cameron]

On 19 May 2016 04:38:09 BST, Matt Ranostay <mranostay@gmail.com> 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....

J

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [RFC] dynamic iio consumer channel mapping

[Daniel Baluta]

On Thu, May 19, 2016 at 8:58 AM, Jonathan Cameron
<jic23@jic23.retrosnub.co.uk> wrote:
>
>
> On 19 May 2016 04:38:09 BST, Matt Ranostay <mranostay@gmail.com> 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.

Re: [RFC] dynamic iio consumer channel mapping

[Matt Ranostay]

On Thu, May 19, 2016 at 1:25 AM, Daniel Baluta <daniel.baluta@intel.com> wrote:
> On Thu, May 19, 2016 at 8:58 AM, Jonathan Cameron
> <jic23@jic23.retrosnub.co.uk> wrote:
>>
>>
>> On 19 May 2016 04:38:09 BST, Matt Ranostay <mranostay@gmail.com> 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?

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.

Re: [RFC] dynamic iio consumer channel mapping

[jic23]

On 20.05.2016 03:09, Matt Ranostay wrote:
> On Thu, May 19, 2016 at 1:25 AM, Daniel Baluta 
> <daniel.baluta@intel.com> wrote:
>> On Thu, May 19, 2016 at 8:58 AM, Jonathan Cameron
>> <jic23@jic23.retrosnub.co.uk> wrote:
>>> 
>>> 
>>> On 19 May 2016 04:38:09 BST, Matt Ranostay <mranostay@gmail.com> 
>>> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html