x86,mrst: Intel Medfield over-current detection patch
Subsystems (2)
PATCH 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
@@ -592,6 +592,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
Quoted 9 lines · Alan Cox
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.
Quoted 3 lines
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.
Hm. Do you have a summary or a pointer to that discussion? This really does seem to be a hardware monitoring device, and so hwmon would seem the more natural home for it - I'd like some idea of what the justification was.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 4 lines
Hm. Do you have a summary or a pointer to that discussion? This really does seem to be a hardware monitoring device, and so hwmon would seem the more natural home for it - I'd like some idea of what the justification was.
Basically that it has no interface features in common with anything in the hwmon API, nor that looked likely to be generic or could be made to fit them.
hwmon isn't "any hardware monitoring device", it's classes of devices that fit certain common interfaces - eg thermal reporting ones.
Alan
Quoted 11 lines · Alan Cox
Quoted 4 lines
Hm. Do you have a summary or a pointer to that discussion? This really does seem to be a hardware monitoring device, and so hwmon would seem the more natural home for it - I'd like some idea of what the justification was.
Basically that it has no interface features in common with anything in the hwmon API, nor that looked likely to be generic or could be made to fit them.
hwmon isn't "any hardware monitoring device", it's classes of devices that fit certain common interfaces - eg thermal reporting ones.
But also voltage and current reporting ones, including alarm thresholds.
Signature · 1 line
Matthew Garrett | [email protected]