Subject: Re: [PATCH] drivers/misc: introduce Freescale Data Collection Manager driver

From: Mark Brown <[email-masked]>
Date: Tue, 2 Aug 2011 11:26:59 +0900

On Tue, Aug 02, 2011 at 01:57:45AM +0000, Tabi Timur-B04825 wrote:
> Mark Brown wrote:

> > I'd expect that things like the _lowest, _highest and _average
> > attributes which a number of drivers have are what you're looking for.

> Yes, but then all I'm doing is presenting numbers that don't change to an 
> interface, simply on the basis that the numbers represent sensor values.

> If I'm running a sensor application, I'm doing it to get real-time 
> monitoring of the sensors in my system.  The DCM on our boards is not 
> capable of real-time results.  So you're not actually "monitoring" the 
> hardware.  The data from the DCM is available only *after* you stop 
> running the background process.

Right, that seems to fit reasonably well with things like averages and
extremes.

> > At the very least it seems obvious how you might extend the interface if
> > some features you need are missing.  The subsystem has fairly extensive
> > documentation in Documentation/hwmon.

> I just don't see how it fits.  Yes, I could do it, but then I'd end up 
> with something that doesn't make any sense.  I would have to use a custom 
> interface to start monitoring and then another interface to stop it.  Then 

The most obvious thing seems to be to use the existing _reset_history
stuff to trigger a restart.  If the hardware is so incapable that it
can't cope with reads while active and needs to be reset to even pause
that's seems pretty rubbish, I'd have expected you could at least pause
measurement momentarily to do a read.

Perhaps integration as a PMU may make more sense?  The general point
here is that this doesn't sound like it's doing something so odd that it
shouldn't even be trying to work within any sort of framework.