Re: Oddities and how to handle them.

[Jonathan Cameron <jic23@cam.ac.uk>]

Guenter / Jean - cc'd you two because we have an sysfs interface naming question for
AC sensors that touches on the edge of hwmon.

>>>>>> Hi Michael,
>>>>>>
>>>>>> ade7758 - Complex driver I'm not that keen on touching without a lot
>>>>>> of testing support. Don't suppose you want to take this one Michael?
>>>>>> (*looks hopeful*) At lease blugeoning it into more or less current
>>>>>> interfaces would be a great help. I can do it, but then I suspect
>>>>>> I'll break it in a few exciting ways :(
>>>>>>
>>>>> I can fix building on this one. However I currently don't have
>>>>> enough time to fix and document the API.
>>>> That's fine.  We won't be pushing any of the energy meter drivers out
>>>> of staging for a while yet anyway!
>>>>> The buffer scan attribute naming is a bit complicated on this one.
>>>>> Do you think we can stick with wform?
>>>>> There is some interaction with the WAVEFORM MODE Register. Ideally
>>>>> we have enable files for all possible waveform selection
>>>>> possibilities, which are numerous, 3 sources (phases)  * 5
>>>>> measurement options (Current, Voltage, Active Power, Reactive
>>>>> Power and VA). Only one combination can be enabled at a given
>>>>> time, since they are exclusive
>>>> or.
> 
> Hi Jonathan,
> 
> For the metering parts I think we need to define a few more channel types.
> 
> How about this ones
> 
> inSX            S is the apparent power.
> inPX            P is the active power.
> inQX            Q is the reactive power.
> inVX            V is the voltage. (only inX ?)
> inVRMSX VRMS is the quadratic mean voltage.
Call it 'root mean square' rather than quadratic in the docs. They have different
meanings in English.
> inIX            I is the current.
currX as per hwmon?  They also define a power attribute, but only 1 (as DC
I guess). Cc'd Guenter and Jean to see if we can / want to share an interface...

Guenter/ Jean, do you think hwmon will ever handle AC sensors? Maybe we want to be
well clear of your interfaces just to avoid confusion? Or define a new set of shared
names for the above that we will both use (when it becomes relevant?)
> inIRMSX IRMS is the quadratic mean current.
> 
> Since they won't be really popular
> 
> How about using a string in iio_chan_type_name_spec
> 
>         [IIO_IN_GENERIC] = "in%s",
Firstly, perhaps, IIO_IN_MOD will correspond better with naming?

Been thinking about exactly this question for the light sensors...
Initially strings seemed like the obvious thing to do, but then I thought
some more.  For all of these we will need to have matching event codes.
The easiest there would be to do them as IIO_EV_MOD_POWER_APPARENT etc.
Once we have those defines, we might as well roll the names into the core
as a string table referenced by value stored in channel2.
Actually, arguably we shouldn't be doing the same for 'x','y','z' as well
for consistency. Right now we allow for directions without corresponding event
codes. That way lies doom!

I know there aren't likely to be hundreds of these devices any time soon,
but we don't really want to set a precedence for allowing free naming.
That was part of the justification for moving to chan_spec in the first
place!

Jonathan