On 04/29/11 15:21, Michael Hennerich wrote: > On 04/28/2011 05:46 PM, Jonathan Cameron wrote: >> On 04/28/11 15:58, Michael Hennerich wrote: >> >>> On 04/28/2011 04:21 PM, Jonathan Cameron wrote: >>> >>>> On 04/28/11 14:51, Jean Delvare wrote: >>>> >>>> >>>>> On Thu, 28 Apr 2011 10:31:15 +0100, Jonathan Cameron wrote: >>>>> >>>>> >>>>>> Guenter / Jean - cc'd you two because we have an sysfs interface naming question for >>>>>> AC sensors that touches on the edge of hwmon. >>>>>> >>>>>> >>>>>> >>>>>>> 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? >>>>>> >>>>>> >>>>> Well, never say never ;) While I've never heard of such sensors, I >>>>> guess it would make some sense for a computer PSU to include a sensor >>>>> chip monitoring both the AC input and the DC output to measure the >>>>> efficiency of the unit. >>>>> >>>>> >>>>> >>>>>> 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?) >>>>>> >>>>>> >>>>> It's hard to tell in advance what hwmon would implement, as we lack >>>>> actual examples. All I can say is that we would never use "in" prefixes >>>>> for power or current. The above power examples would most probably be >>>>> named powerX_apparent_input, powerX_active_input and >>>>> powerX_reactive_input, if we ever have to support these. And >>>>> inX_rms_input for the root mean square voltage input. >>>>> >>>>> But then again, I'm not sure if there is any point in sharing anything, >>>>> or forcing any difference, between hwmon and iio interfaces. They are >>>>> different by nature, and if we don't strictly enforce their relation, >>>>> they are bound to randomly diverge and converge anyway. >>>>> >>>>> >>>>> >>>> Agreed to a certain extent, but saying that there is no point in reinventing >>>> the wheel. I think the naming you've just suggested is clearer anyway. >>>> >>>> Ultimately I don't insist on keeping to your interfaces when it really doesn't >>>> make sense, but when it does, it makes our life easier as we aren't starting from >>>> scratch. Also, politically it was suggested we do this by a few people I'd like >>>> to keep on side. >>>> >>>> Michael - howabout doing the rms values as done with peak_raw - as chan info parameters >>>> (directly derived from raw values anyway). >>>> >>>> >>> I don't understand - why would the RMS value being a _raw value? >>> V and Vrms are calculated inside the metering IC. >>> And so far we use the _raw stuff only if the value needs to be scaled >>> somehow. >>> >> So these are already in Volts? (or I guess millivolts?) >> > Need to check the exact data representation. > There are offset and gain control registers associated. Ideally they are > properly set and then we get the voltage in millivolts. > The none RMS values are the absolute voltages that get sampled into the > ring buffer. > The RMS voltages are calculated inside the part and provided to the user > as sysfs attributes files. Cool. In that case we don't need the raw. However, we do perhaps need to make it clear it is processed and put _input at the end instead... > >> Surely they need the same scaling as in0_raw? >> >>> >>> >>>> Then define two new (to us) channel types. >>>> >>>> IIO_CURRENT = "curr%d" >>>> IIO_POWER = "curr%d" >>>> >>>> >>> power? >>> >> Oopsy. >> >>>> Using the rfc I'm going to post after I send this email, we can add additional names to a channel. >>>> The only slight annoyance is the 3 power values will need to be different channels, so under that >>>> we will have: >>>> >>>> power0_apparent_raw is the apparent power. >>>> power1_active_raw is the active power. >>>> power2_reactive_raw is the reactive power. >>>> in0 is the voltage. >>>> >>>> >>> If we want to be more verbose, why do we use 'in' for voltage and not >>> voltageX ? >>> >> Matching hwmon, Greg KH and others pushed for this early on. I didn't care >> really as long as it didn't get in the way. So when you get down to >> it combination of trying to limit variation of interfaces in kernel >> and politics. Jean has always argued (as here) that it probably isn't >> going to work anyway! >> > IIO and HWMON servers different purposes. I think we already got to the > point of divergent interfaces. True. But so far it is only for things where we really have to do so, such as threshold interrupts. Hwmon's alarms are fine for their usecases but only cover a fraction of what we have on inertial sensors for starters. (as you'd expect) > >> >>> It looks to me we're messing something up here. For DACs we use outX for >>> voltage! >>> I think we have to come up with something that allows us to specify >>> whether something is an output or input. >>> >> 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. > ? >>> >>>> in0_rms_raw is the rms voltage. >>>> curr0_raw is the current. >>>> >>>> We may want to think about how to indicate which of these are measured on the same physical pin. >>>> If we were to have all the power measures as power0_* then we need another way of differentiating >>>> their event codes. Could use modifiers I suppose... I've just sanity checked that there are no >>>> other issues, by modifying tsl2563 to claim both intensity readings are on the same channel. >>>> >>>> What do you think? >>>> _______________________________________________ >>>> Device-drivers-devel mailing list >>>> Device-drivers-devel@xxxxxxxxxxxxxxxxxxxx >>>> https://blackfin.uclinux.org/mailman/listinfo/device-drivers-devel >>>> >>>> >>>> >>> >>> >> >> > > -- 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