Re: [PATCH 5/6] X86 platform drivers: Remove EC dump fromthinkpad_acpi

[Henrique de Moraes Holschuh]

On Thu, 01 Jul 2010, Thomas Renninger wrote:
> There is a general interface for that now (provided by
> other patches in this patch series):
> /sys/devices/system/ec/*/io
> 
> Signed-off-by: Thomas Renninger <trenn@xxxxxxx>
> 
> CC: Alexey Starikovskiy <astarikovskiy@xxxxxxx>
> CC: Len Brown <lenb@xxxxxxxxxx>
> CC: linux-kernel@xxxxxxxxxxxxxxx
> CC: linux-acpi@xxxxxxxxxxxxxxx
> CC: platform-driver-x86@xxxxxxxxxxxxxxx
> CC: Henrique de Moraes Holschuh <hmh@xxxxxxxxxx>
> CC: ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx

No outright objections, but...

> -EXPERIMENTAL: Embedded controller register dump -- /proc/acpi/ibm/ecdump
> -------------------------------------------------------------------------

[...]

> -registers. Values which have changed since the last time the registers
> -were dumped are marked with a star:

[...]

> -This feature can be used to determine the register holding the fan
> -speed on some models. To do that, do the following:
> -
> -	- make sure the battery is fully charged
> -	- make sure the fan is running
> -	- run 'cat /proc/acpi/ibm/ecdump' several times, once per second or so
> -
> -The first step makes sure various charging-related values don't
> -vary. The second ensures that the fan-related values do vary, since
> -the fan speed fluctuates a bit. The third will (hopefully) mark the
> -fan register with a star:
> -
> -[root@x40 ibm-acpi]# cat /proc/acpi/ibm/ecdump
> -EC       +00 +01 +02 +03 +04 +05 +06 +07 +08 +09 +0a +0b +0c +0d +0e +0f
> -EC 0x00:  a7  47  87  01  fe  96  00  08  01  00  cb  00  00  00  40  00
> -EC 0x10:  00  00  ff  ff  f4  3c  87  09  01  ff  42  01  ff  ff  0d  00
> -EC 0x20:  00  00  00  00  00  00  00  00  00  00  00  03  43  00  00  80
> -EC 0x30:  01  07  1a  00  30  04  00  00  85  00  00  10  00  50  00  00
> -EC 0x40:  00  00  00  00  00  00  14  01  00  04  00  00  00  00  00  00
> -EC 0x50:  00  c0  02  0d  00  01  01  02  02  03  03  03  03  bc  02  bc
> -EC 0x60:  02  bc  02  00  00  00  00  00  00  00  00  00  00  00  00  00
> -EC 0x70:  00  00  00  00  00  12  30  40  24  27  2c  27  21  80  1f  80
> -EC 0x80:  00  00  00  06 *be  0d  03  00  00  00  0e  07  00  00  00  00
> -EC 0x90:  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
> -EC 0xa0:  ff  09  ff  09  ff  ff  64  00  00  00  a2  41  ff  ff  e0  00
> -EC 0xb0:  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
> -EC 0xc0:  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
> -EC 0xd0:  03  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
> -EC 0xe0:  00  00  00  00  00  00  00  00  11  20  49  04  24  06  55  03
> -EC 0xf0:  31  55  48  54  35  38  57  57  08  2f  45  73  07  65  6c  1a
> -
> -Another set of values that varies often is the temperature
> -readings. Since temperatures don't change vary fast, you can take
> -several quick dumps to eliminate them.
> -
> -You can use a similar method to figure out the meaning of other
> -embedded controller registers - e.g. make sure nothing else changes
> -except the charging or discharging battery to determine which
> -registers contain the current battery capacity, etc. If you experiment
> -with this, do send me your results (including some complete dumps with
> -a description of the conditions when they were taken.)

I'd prefer if the above text gets replaced by something that adds a pointer
to the new facility, instead of being just outright removed.  Also, the text
about how to use the facility to detect tachometers and thermometers should
be retained, if at all possible.

Soes your helper userspace util do the "differential" analysis that
thinkpad-acpi used to (the "*" after values that changed since last read)?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/