On 04/28/2011 11:31 AM, 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. > > >>>>>>> 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... > Honestly I don't like 'curr' - In my opinion we should use SI until symbols (as well as standardized derived SI units where applicable). In this particular case current is a SI unit. For everything further we should use symbols commonly used in Anglo-American EE and Physics literature. (NIST, IEEE, ...) > 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 > > -- 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
