[lkml]   [2016]   [Nov]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH v2 5/7] iio: multiplexer: new iio category and iio-mux driver
On 2016-11-19 16:49, Jonathan Cameron wrote:
> On 17/11/16 21:48, Peter Rosin wrote:
>> When a multiplexer changes how an iio device behaves (for example
>> by feeding different signals to an ADC), this driver can be used
>> create one virtual iio channel for each multiplexer state.
>> Depends on the generic multiplexer driver.
> I'm not really following what all the ext info stuff in here is about.
> Could you add a little more description of that?

Certainly. I have two needs for this series. The first one is simple
when it comes to the iio part and complex because the mux is shared
between three 8-way muxes on three of the inputs to an ADS-1015 ADC.
The forth ADC line to the ADS-1015 is not muxed. Those three muxes
are of course GPIO-controlled and share GPIO pins. And the GPIO
pins also control an i2c bus that is muxed 8-ways as well. There are
eight (possible) batteries, and we monitor voltage/current/temp with
the 3 muxed ADC lines, and 8 chargers sit on i2c behind the i2c mux.
I guess it felt natural for the HW designer to select battery with
the GPIO lines, but that do not fit too well with the code as it
is without this series...

For this first need, the iio mux does not need ext_info.

The second need is simple in the mux part but worse in the iio
department. It's another 8-way mux that simply muxes an ADC line,
so that is simple. However, the ADC line is the envelope detector
that just got added to linux-next, and it has two ext_info
attributes that needs to be set differently for different mux
states. Two of the states need "invert" to be false, the rest need
"invert" to be true. And it is also preferable to have different
values for "compare_interval" for different mux states since the
signals on the diffrent mux states have the different frequency

True, I could have the ext-info attributes go straight through
the mux, and just start by writing values to "invert"
and "compare_interval", and only then read a sample. But then I
would need to lock out other users during the duration of this
transaction. I believe that the best place to put that lock is
in the iio mux (when it locks its control-mux) and not leave it
to userspace to solve this in some brittle cooperative manner.

> Perhaps an example of how it is used and what the resulting interface
> looks like?

The resulting interface is just a copy of the (ext_info) interface
exposed by the parent channel (with a cache that is rewritten to
the parent on every iio mux state change). I have plans to add code
to not rewrite ext_info attributes that have never been changed in
any mux state.

Below I have an example file listing.

device0 is a dpot (mcp4561).
device1 is a dac (dpot-dac, wrapping the above dpot).
device2 is an adc (envelope-detector, wrapping the above dac)
device3 is a mux (iio-mux, wrapping the above adc)

The 8-way iio-mux have no signals attached on mux states 0 and 1, which
is why the first channel for device 3 is in_altvoltage2.

Ultimately, I would like some knob to hide devices 0, 1 and 2 from
userspace. They need/should only be visible to in-kernel users. Or
is there such a knob already?


$ ls /sys/bus/iio/devices/iio\:device*
dev out_resistance_raw_available
name out_resistance_scale
of_node power
out_resistance0_raw subsystem
out_resistance1_raw uevent

dev out_voltage0_scale
name power
of_node subsystem
out_voltage0_raw uevent

dev name
in_altvoltage0_compare_interval of_node
in_altvoltage0_invert power
in_altvoltage0_raw subsystem
in_altvoltage0_scale uevent

dev in_altvoltage5_raw
in_altvoltage2_compare_interval in_altvoltage5_scale
in_altvoltage2_invert in_altvoltage6_compare_interval
in_altvoltage2_raw in_altvoltage6_invert
in_altvoltage2_scale in_altvoltage6_raw
in_altvoltage3_compare_interval in_altvoltage6_scale
in_altvoltage3_invert in_altvoltage7_compare_interval
in_altvoltage3_raw in_altvoltage7_invert
in_altvoltage3_scale in_altvoltage7_raw
in_altvoltage4_compare_interval in_altvoltage7_scale
in_altvoltage4_invert name
in_altvoltage4_raw of_node
in_altvoltage4_scale power
in_altvoltage5_compare_interval subsystem
in_altvoltage5_invert uevent

 \ /
  Last update: 2016-11-20 05:42    [W:0.080 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site