On Thu, Apr 28, 2011 at 06:19:09AM -0400, Jonathan Cameron wrote: > On 04/28/11 11:04, Michael Hennerich wrote: > > 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, ...) > Agreed, but it's an interface that is in place so best to match where > we can. That way far fewer argument lie (we can always blame someone > else :) hwmon only uses inX for voltages. As such, usage of currX would only make sense if you also use powerX for power, energyX for energy and so on. > > > >> 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?) > >> Depends if this would be for hardware monitoring purposes, which seems to be unlikely. If it were, any ABI extensions or driver-specific attributes would presumably be based on the existing hwmon ABI. Guenter -- 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
