On 04/29/2011 05:03 PM, Jonathan Cameron wrote: > 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. > 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. >> ? >> >>>> >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -- Greetings, Michael -- Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft: Muenchen; Registergericht: Muenchen HRB 40368; Geschaeftsfuehrer:Dr.Carsten Suckrow, Thomas Wessel, William A. Martin, Margaret Seif -- 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
