Comments

The Data Collection Manager (DCM) is a feature of the FPGA on some Freescale
PowerPC reference boards that can read temperature, current, and voltage
settings from the sensors on those boards. This driver exposes the DCM via a
sysfs interface (/sys/devices/platform/fsl-ocm.0).
The DCM collects and tallies data over a period of time in the background,
without utilizing any resources on the host (CPU, memory, etc). The data is
summarized and made available when data collection stops. This allows power
consumption to be measured while the host is performing some tasks (usually
a benchmark).
Signed-off-by: Timur Tabi <timur@freescale.com>
---
Grant, could you please review the way I instantiate the platform driver and
call the .probe function?
Documentation/misc-devices/fsl_dcm.txt | 50 +++
drivers/misc/Kconfig | 14 +
drivers/misc/Makefile | 1 +
drivers/misc/fsl_dcm.c | 750 ++++++++++++++++++++++++++++++++
4 files changed, 815 insertions(+), 0 deletions(-)
create mode 100644 Documentation/misc-devices/fsl_dcm.txt
create mode 100644 drivers/misc/fsl_dcm.c

On Mon, Aug 01, 2011 at 04:48:54PM -0500, Timur Tabi wrote:
> The Data Collection Manager (DCM) is a feature of the FPGA on some Freescale> PowerPC reference boards that can read temperature, current, and voltage> settings from the sensors on those boards. This driver exposes the DCM via a> sysfs interface (/sys/devices/platform/fsl-ocm.0).
This sounds like it should be a hwmon driver.
> The DCM collects and tallies data over a period of time in the background,> without utilizing any resources on the host (CPU, memory, etc). The data is> summarized and made available when data collection stops. This allows power> consumption to be measured while the host is performing some tasks (usually> a benchmark).
Though this is a bit odd for the subsystem I don't think it's too far
out of what other hwmon chips can do, some of them do have longer term
stats than just instantaneous readings.

Mark Brown wrote:
> On Mon, Aug 01, 2011 at 04:48:54PM -0500, Timur Tabi wrote:>> The Data Collection Manager (DCM) is a feature of the FPGA on some Freescale>> PowerPC reference boards that can read temperature, current, and voltage>> settings from the sensors on those boards. This driver exposes the DCM via a>> sysfs interface (/sys/devices/platform/fsl-ocm.0).>> This sounds like it should be a hwmon driver.
I didn't see any way to interface the hardware to the hwmon layer in a
manner that provides the information that our customers went using this
hardware.
>> The DCM collects and tallies data over a period of time in the background,>> without utilizing any resources on the host (CPU, memory, etc). The data is>> summarized and made available when data collection stops. This allows power>> consumption to be measured while the host is performing some tasks (usually>> a benchmark).>> Though this is a bit odd for the subsystem I don't think it's too far> out of what other hwmon chips can do, some of them do have longer term> stats than just instantaneous readings.
Can you show an example or some documentation? I couldn't find anything
remotely like that. I don't even see anything that lets me start/stop
monitoring of sensors.

On Mon, Aug 01, 2011 at 11:58:00PM +0000, Tabi Timur-B04825 wrote:
> Mark Brown wrote:> > On Mon, Aug 01, 2011 at 04:48:54PM -0500, Timur Tabi wrote:
> >> PowerPC reference boards that can read temperature, current, and voltage> >> settings from the sensors on those boards. This driver exposes the DCM via a> >> sysfs interface (/sys/devices/platform/fsl-ocm.0).
> > This sounds like it should be a hwmon driver.
> I didn't see any way to interface the hardware to the hwmon layer in a > manner that provides the information that our customers went using this > hardware.
Even if that's the case I can't see that it is a good reason for adding
a driver out of any subsystem with a completely non-standard interface.
> > Though this is a bit odd for the subsystem I don't think it's too far> > out of what other hwmon chips can do, some of them do have longer term> > stats than just instantaneous readings.
> Can you show an example or some documentation? I couldn't find anything > remotely like that. I don't even see anything that lets me start/stop > monitoring of sensors.
I'd expect that things like the _lowest, _highest and _average
attributes which a number of drivers have are what you're looking for.
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.

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.
> 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
I would query the results use the hwmon interface, but the results would
be static. That just seems silly.

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.