>>>>> >>>> We could prefix all inputs with in and all outputs with out, assuming >>>> we move voltages out of the way. Ultimately we didn't have any output >>>> devices when we started hammering the interfaces into shape. >>>> >>>> >>> That sounds right to me. >>> >> We may need to do this gradually, or on the move from staging out into the >> main tree. Whilst we are in staging, I know there are mainstream users >> of a few drivers. Perhaps we just support old interface for them on a >> case by case basis. >> >> This will want a full proposal to lkml. >> >>>> >>>>> In addition we need to proper naming for what is input or output - >>>>> current, voltage, etc. >>>>> >>>>> The three power values can't be three different channels. >>>>> They are alternatives all on the same physical input channel, and the >>>>> naming should express this. >>>>> >>>>> >>>> Then it will have to be as modifiers. Right now we tend to use them to >>>> group things. So for accelerometers we can in theory have: >>>> >>>> accel0_x, >>>> accel0_y, >>>> accel1_x, etc. for chips implementing more than one sensor in a given >>>> direction. >>>> >>>> If we insist on same number meaning same physical ping then for typical >>>> inertial sensor the channel number would have to be unique. >>>> Thus take adis16400 we would need. >>>> >>>> in0_supply_raw >>>> gyro1_x_raw >>>> gyro2_y_raw >>>> gyro3_z_raw >>>> accel4_x_raw >>>> etc... >>>> which, whilst looking odd, wouldn't be a fundamental problem. >>>> >>>> >>> Agreed - that looks odd. And yes modifiers should work as well. >>> So we get to - >>> >>> in_powerX_Y_apparent_raw >>> >>> in_volatgeX_Y_rms_raw >>> >>> or >>> >>> inX_powerY_apparent_raw >>> inX_volatgeY_rms_raw >>> outX_volatgeY_raw >>> >>> >> I'm a little confused on what the Y is? I would imagine we can only have >> one apparent power measure per channel. The modifier will be into an enum >> associated with that 'apparent' label, much as we have 'x' >> for axis in devices where that makes sense. We may want to move away from >> the passing a character approach for those modifiers as well so we have >> just one path. >> > > Hi Jonathan, > > I'm now getting confused as well. > Yes one apparent power measure per channel is enough. > Didn't you say that the 3 power values will need to be different channels? > My point was that we need a modifier that identifies the physical > input/output channel. I was thinking of this other way around. We have perfectly good channel numbers. Lets use them for the physical channel, then use the modifiers to distinguish what we are dealing with. Thus, here we have: Channel types Power, Voltage, Current, (for now keep voltage as inX as it will easier to do a separate series converting all drivers to new naming) for power, we define modifiers, apparent, active, reactive. for voltage and current we will define the modifier rms (this is a change to what I proposed earlier so as to allow for events on RMS values. For consistency we will probably want to move the existing channel info element peak_raw over to be a modifier as well - what we currently do with that is a dirty hack that will bite us at some point) We then define channel numbering, to be an 'indicator' of shared physical channel (i.e. pin). I only say indicator so as to avoid a mass change of the tree in this driver patch. As with the channel renames, that wants to be a separate series. It actually effects only a few channels on a few devices so isn't a big problem. By saying channel numbers indicate physical channels iff they are present we get around having to assign the to axes on the IMU's and accelerometers. So we end up with here (I've gone for raw everywhere to avoid reading the datasheet thoroughly!) power0_apparent_raw power0_active_raw power0_reactive_raw in0_raw (probably become voltage0_raw at a later date, from waveform register?) in0_rms_raw in0_peak_raw (max value from set number of wave cycles - probably needs in0_peak_cycles as well?) curr0_raw (from waveform register?) curr0_rms_raw curr0_peak_raw (max value from set number of wave cycles..) Would this cover your requirements? It generalizes well (I think) so I'm quite keen on doing it roughly like this... As a follow up series, I'll (or some one else) also move the accelerometers etc to not specify their modifiers with 'x' as channel but rather the modifier code in channel2 of iio_chan_spec. Thanks for knocking this driver into shape! Hope it doesn't prove too painful. Jonathan -- 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
