x86,mrst: Intel Medfield over-current detection patch
Subsystems (2)
PATCH RESEND 1/1 x86,mrst: Intel Medfield over-current detection patch
From: Durgadoss R <[email protected]>
This patch enables over current detection on the Intel Medfield Platform. This driver provides sysfs interfaces to configure current thresholds. When the current being drawn on the platform exceeds the configured threshold, an interrupt is generated. This interrupt can be used to bring the current consumption down by taking necessary hardware or software actions.
Note that while we use hwmon style helpers and interface this is not an hwmon device and hwmon has no common API with this hardware. After discussion with the hwmon maintainers it was decided to make this an x86 platform driver.
---
Documentation/x86/intel_mid/intel_mid_ocd.txt | 86 +++ drivers/platform/x86/Kconfig | 7 drivers/platform/x86/Makefile | 1 drivers/platform/x86/intel_mid_ocd.c | 640 +++++++++++++++++++++++++ 4 files changed, 734 insertions(+), 0 deletions(-) create mode 100644 Documentation/x86/intel_mid/intel_mid_ocd.txt create mode 100644 drivers/platform/x86/intel_mid_ocd.c
Documentation/x86/intel_mid/intel_mid_ocd.txt new file +86 -0
@@ -0,0 +1,86 @@ +Kernel driver over current detection driver +=========================================== + +Supported systems: + * Intel Medfield Platform + +Author: Durgadoss R + +Description +----------- + +This driver monitors the current drawn by the platform, and detects the +peak current conditions. When the current drawn is more than the +configured limit for a period of time (which is specified by a timer), an +interrupt is generated. The current limit and the timer value can be +configured at run time. + +The current thresholds aka BATTCURRENTLIMITS(BC) are of two types: + 1.warning threshold(BC1) + at which the system should take actions to bring the + current consumption down. + 2.shutdown threshold(BC2) + at which the hardware does a COLDOFF. + +The timer thresholds are of three types: + 1.warning threshold(T1) + This corresponds to the first flag for time that the battery + current has been above BC1. An interrupt is generated to allow + software to correct the situation based on use-case. + 2.hardware action threshold(T2) + This corresponds to the second flag for time that the battery + current has been above BC1. It signifies that the system + should control high current subsystems through hardware. + Besides a general interrupt, audio_volume_crush, vibra_disable + signals are sent. + 3.shutdown threshold(T3) + This final flag signifies that when the system current exceeds + the threshold for more than T3, system should shutdown. + +Following table summarizes the exported sysfs files: + +bcu_status(RW) - To enable/disable burst control unit. + 0 - enables bcu, 1 - disables bcu. +accumulation_time(RW)- Time since last clearing/overflow of warning_count + in milli seconds. Writing 0 resets the acc_time and + also clears both the warning counters. +warning_count(RO) - Two space seperated values that indicate the number + of times the current thresholds have been crossed. +action_mask(RW) - A hex value to enable/disable specific + actions taken when current violation happens. + bits [b4 b3 b2 b1 b0] control [a4 a3 a2 a1 a0] actions + respectively. a4 - camera output, a3 - sys burst, + a2 - SOC burst enable, a1 - vibra, a0 - audio output. + bits [b7 b6 b5] - Reserved. + Default value:08 (sys burst output is enabled). +action_status(RO) - A hex value showing the status of actions taken + since the __last__ interrupt. + b7 - T3 violation + b6 - T2 violation + b5 - T1 violation + b4 - camera action taken status + b3 - sys burst disable action taken status + b2 - SOC burst disable action taken status + b1 - vibra disable + b0 - audio volume crush + A '1' in a bit position indicates that particular + action has been taken. +current_warning(RW) - This gives the current(in mA) at which a warning is + generated. Range: 1400 to 4800. Default:3000 +current_shutdown(RW) - This gives the current(in mA) at which system shutdown + is initiated. Range:1800 to 5800. Default:3800 +timer_warning(RW) - Time above current_warning limit at which interrupts + are trigerred(so that software can bring the current + consumption down). Values are in micro seconds. + Range:200 to 7700 in steps of 500 +timer_hw_action(RW) - Time above current_warning limit at which the system + is trigerred into hardware control to bring down the + current consumption. Values are in micro seconds. + Range:200 to 7700 in steps of 500 +timer_shutdown(RW) - Time above current_warning limit at which a hardware + shutdown event is trigerred. The timer values are in + micro seconds. + Range:1000 to 15000 in steps of 1000 +For all timer interfaces, tolerance shall be 5% maximum. +All timers start running concurrently once current_warning/current_shutdown +is crossed.
drivers/platform/x86/Kconfig +7 -0
@@ -598,6 +598,13 @@ config GPIO_INTEL_PMIC Say Y here to support GPIO via the SCU IPC interface on Intel MID platforms. +config INTEL_MID_OCD + tristate "Intel MID platform over-current detector" + depends on INTEL_SCU_IPC + ---help--- + Say Y here to support over-current detection and handling on + Intel Medfield MID platforms. + config RAR_REGISTER bool "Restricted Access Region Register Driver" depends on PCI && X86_MRST
drivers/platform/x86/Makefile +1 -0
@@ -29,6 +29,7 @@ obj-$(CONFIG_ACPI_TOSHIBA) += toshiba_acpi.o obj-$(CONFIG_TOSHIBA_BT_RFKILL) += toshiba_bluetooth.o obj-$(CONFIG_INTEL_SCU_IPC) += intel_scu_ipc.o obj-$(CONFIG_INTEL_SCU_IPC_UTIL)+= intel_scu_ipcutil.o +obj-$(CONFIG_INTEL_MID_OCD) += intel_mid_ocd.o obj-$(CONFIG_RAR_REGISTER) += intel_rar_register.o obj-$(CONFIG_INTEL_IPS) += intel_ips.o obj-$(CONFIG_GPIO_INTEL_PMIC) += intel_pmic_gpio.o
drivers/platform/x86/intel_mid_ocd.c new file +640 -0
640 lines not on this page · raw message
hwmon includes support for exposing the instantaneous current draw. hwmon includes support for triggering events if a parameter crosses a threshold. I still don't see why this isn't an hwmon driver, perhaps with a small platform driver for the more estoric bits of the setup.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 4 lines · On Mon, 7 Feb 2011 19:58:43 +0000 Matthew Garrett <[email protected]> wrote:
hwmon includes support for exposing the instantaneous current draw. hwmon includes support for triggering events if a parameter crosses a threshold. I still don't see why this isn't an hwmon driver, perhaps with a small platform driver for the more estoric bits of the setup.
The hwmon maintainer says its not. Explicitly so. Been there, had that discussion a while ago (in fact we had it as well in December if you remember and I pointed you at the hwmon list discussion
Cc'd Guenter and quoting this time
------------------------------
Seems to be a lot of chip specific stuff. Actually, you don't define a single hwmon ABI attribute right now. So moving it to the x86 platform code might be a better option.
One possibility might be to move the driver to the x86 platform code, but add/use hwmon ABI attributes as much as possible, and register those attributes as hwmon device if CONFIG_HWMON is defined. Several other platform specific drivers already do the same.
------------------------------
Hence trying to move it to drivers/platform/x86
Alan
Quoted 11 lines · Alan Cox
Quoted 4 lines · On Mon, 7 Feb 2011 19:58:43 +0000 Matthew Garrett <[email protected]> wrote:
hwmon includes support for exposing the instantaneous current draw. hwmon includes support for triggering events if a parameter crosses a threshold. I still don't see why this isn't an hwmon driver, perhaps with a small platform driver for the more estoric bits of the setup.
The hwmon maintainer says its not. Explicitly so. Been there, had that discussion a while ago (in fact we had it as well in December if you remember and I pointed you at the hwmon list discussion
The hwmon maintainer says that it's not an hwmon driver, not that it shouldn't be an hwmon driver.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 9 lines · On Tue, 8 Feb 2011 13:52:28 +0000 Matthew Garrett <[email protected]> wrote:
Quoted 8 lines · Alan Cox
Quoted 4 lines · On Mon, 7 Feb 2011 19:58:43 +0000 Matthew Garrett <[email protected]> wrote:
hwmon includes support for exposing the instantaneous current draw. hwmon includes support for triggering events if a parameter crosses a threshold. I still don't see why this isn't an hwmon driver, perhaps with a small platform driver for the more estoric bits of the setup.
Quoted 6 lines
Quoted 3 lines
The hwmon maintainer says its not. Explicitly so. Been there, had that discussion a while ago (in fact we had it as well in December if you remember and I pointed you at the hwmon list discussion
The hwmon maintainer says that it's not an hwmon driver, not that it shouldn't be an hwmon driver.
That's not how I interpret it, but he's Cc'd so I'll let him speak for himself, failing that I'll stuff it in arch/x86/platform/mrst I guess
Quoted 9 lines · Alan Cox
Quoted 6 lines · On Tue, 8 Feb 2011 13:52:28 +0000 Matthew Garrett <[email protected]> wrote:
Quoted 5 lines · Alan Cox
Quoted 2 lines · On Mon, 7 Feb 2011 19:58:43 +0000 Matthew Garrett <[email protected]> wrote:
hwmon includes support for exposing the instantaneous current draw. hwmon includes support for triggering events if a parameter crosses a
Not explicitly, really. Sure, one can write a driver which triggers such an event, but afaik there is only one hwmon driver doing that right now, and doing so is not part of the hwmon infrastructure.
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
threshold. I still don't see why this isn't an hwmon driver, perhaps with a small platform driver for the more estoric bits of the setup.
The hwmon maintainer says its not. Explicitly so. Been there, had that discussion a while ago (in fact we had it as well in December if you remember and I pointed you at the hwmon list discussion
Quoted 5 lines
Quoted 2 lines
The hwmon maintainer says that it's not an hwmon driver, not that it shouldn't be an hwmon driver.
That's not how I interpret it, but he's Cc'd so I'll let him speak for himself, failing that I'll stuff it in
arch/x86/platform/mrstI guess
Seems to me there is some hair splitting going on here. Core element of hwmon drivers is that there are reported temperatures, voltages, current, power, humidity, etc. I don't see any of those here. All I see is various current limits. Those are secondary attributes from hwmon perspective. So I don't really see how this can be made a hwmon driver.
Anyway, didn't you have this discussion before ? Does this all have to be repeated over and over again ? I agree with everything Alan has said in the previous exchange last December. Repeating it won't change anything.
Guenter
Quoted 5 lines · Guenter Roeck
Seems to me there is some hair splitting going on here. Core element of hwmon drivers is that there are reported temperatures, voltages, current, power, humidity, etc. I don't see any of those here. All I see is various current limits. Those are secondary attributes from hwmon perspective. So I don't really see how this can be made a hwmon driver.
Ok, if the hardware has no mechanism for reporting the instantaneous draw then I can see it not working well in an hwmon sense. But I'd really prefer to see this look far more generic than it does - surely other hardware has similar functionality?
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 4 lines
Ok, if the hardware has no mechanism for reporting the instantaneous draw then I can see it not working well in an hwmon sense. But I'd really prefer to see this look far more generic than it does - surely other hardware has similar functionality?
I've not seen any - not anything genericisable anyway. I guess in theory you could dramatically extend the regulator API to do power draw management, bus current monitoring and overcurrent callbacks but I'm not sure it would make any sense. What you do with such events and how you manage it is incredibly platform specific.
In the PC world it's not so bad because overcurrent is a fault state - you whine about it and either shut down or cross fingers and keep going. In embedded devices it's not that simple and it is actively managed.
I'm open to bright ideas!
Alan
Quoted 11 lines · Alan Cox
Quoted 4 lines
Ok, if the hardware has no mechanism for reporting the instantaneous draw then I can see it not working well in an hwmon sense. But I'd really prefer to see this look far more generic than it does - surely other hardware has similar functionality?
I've not seen any - not anything genericisable anyway. I guess in theory you could dramatically extend the regulator API to do power draw management, bus current monitoring and overcurrent callbacks but I'm not sure it would make any sense. What you do with such events and how you manage it is incredibly platform specific.
Quoted 3 lines
In the PC world it's not so bad because overcurrent is a fault state - you whine about it and either shut down or cross fingers and keep going. In embedded devices it's not that simple and it is actively managed.
Yeah, fair enough. I'll queue this up.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 8 lines · Matthew Garrett
Quoted 5 lines · Guenter Roeck
Seems to me there is some hair splitting going on here. Core element of hwmon drivers is that there are reported temperatures, voltages, current, power, humidity, etc. I don't see any of those here. All I see is various current limits. Those are secondary attributes from hwmon perspective. So I don't really see how this can be made a hwmon driver.
Quoted 5 lines
Ok, if the hardware has no mechanism for reporting the instantaneous draw then I can see it not working well in an hwmon sense. But I'd really prefer to see this look far more generic than it does - surely other hardware has similar functionality?
Might well be. Just like thermal subsystem drivers act on thermal information and registers thermal drivers with the hwmon subsystem for reporting purposes, it might well be that there could at some point be a "current" subsystem doing something similar for currents. But that doesn't mean that it would make sense to provide such functionality from within the hwmon subsystem.
I have no idea if your other question can be answered right now. Maybe a more generic interface is possible, but one would need to see multiple implementations to determine what can be generalized. I personally don't believe that it is possible to define a useful generic interface without knowledge of multiple pieces of HW using that interface.
If someone volunteers to create a generic API, ABI, and possibly a new subsystem for current management, that person can go ahead and present that subsystem to the community for consideration. I am all for it. But it would not be appropriate to hold this driver hostage to the non-existence of such a subsystem.
Thanks,
Guenter