The regulator framework uses a lot of printks with a
specific formatting using __func__. This converts them
to use pr_ calls with a central format string.
Cc: bleong@codeaurora.org
Signed-off-by: Daniel Walker <dwalker@codeaurora.org>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
This adds a pr_fmt line which uses the __func__ macro. I also
convert the current pr_ lines to remove their __func__ usage.
Cc: bleong@codeaurora.org
Signed-off-by: Daniel Walker <dwalker@codeaurora.org>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Supply regulators are disabled only when the last
reference count is removed on the child regulator
(the use count goes from 1 to 0). This patch changes
the behaviour of enable so the supply regulator is
enabled only when the use count of the child
regulator goes from 0 to 1.
Signed-off-by: Bengt Jonsson <bengt.g.jonsson@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@stericsson.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Provide some basic trace facilities to the regulator API. We generate
events on regulator enable, disable and voltage setting over the actual
hardware operations (which are assumed to be the expensive ones which
require interaction with the actual device). This is intended to facilitate
debug of the performance and behaviour with consumers allowing unified
traces to be generated including the regulator operations within the
context of the other components of the system.
For enable we log the explicit delay for the voltage ramp separately to
the interaction with the hardware to highlight the time consumed in I/O.
We should add a similar delay for voltage changes, though there the
relatively small magnitude of the changes in the context of the I/O
costs makes it much less critical for most regulators.
Only hardware interactions are currently traced as the primary focus is
on the performance and synchronisation of actual hardware interactions.
Additional tracepoints for debugging of the logical operations can be
added later if required.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
Change the interface used by set_voltage() to report the selected value
to the regulator core in terms of a selector used by list_voltage().
This allows the regulator core to know the voltage that was chosen
without having to do an explict get_voltage(), which would be much more
expensive as it will generally access hardware.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
This patch add locks around regulator supply enable.
Signed-off-by: Mattias Wallin <mattias.wallin@stericsson.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
This patch adds a driver for the built-in hardware watchdog device
of the Atheros AR71XX/AR724X/AR913X SoCs.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: Imre Kaloz <kaloz@openwrt.org>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
This driver adds support for /dev/watchdog for boards using either the MCP51 or
MCP55 chipsets. These are also known as the nForce 430 and nForce 550. This
driver is likely to work on other chipsets as well, though those are the only
two that have been tested.
Signed-off-by: Mike Waychison <mikew@google.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
This driver adds /dev/watchdog support for the AMD sp5100 aka SB7x0 chipsets.
It follows the same conventions found in other /dev/watchdog drivers.
Signed-off-by: Priyanka Gupta <priyankag@google.com>
Signed-off-by: Mike Waychison <mikew@google.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Update Kconfig with the additional Fintek hardware that we support.
Signed-off-by: Lutz Ballaschke <vegan.grindcore@googlemail.com>
Acked-by: Giel van Schijndel <me@mortis.eu>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
This patch adds the DeviceIDs for TCO Watchdog on the Intel DH89xxCC PCH.
Signed-off-by: Seth Heasley <seth.heasley@intel.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
This patch adds the Intel NM10 DeviceIDs for iTCO Watchdog.
Reported-by: Dan Weinlader <dan@weinlader.org>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
ks8695_wdt needs KS8695_CLOCK_RATE, which is defined in
mach/hardware.h, which is pulled in by the include of mach/timex.h,
but the latter is going away, so just include mach/hardware.h
directly.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Lennert Buytenhek <buytenh@secretlab.ca>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
When the watchdog period is changed, it needs to be propagated to all cores
in addition to the core that performed the change.
Signed-off-by: Randy Vinson <rvinson@mvista.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Normally, the watchdog is disabled when dev/watchdog is closed, but if
CONFIG_WATCHDOG_NOWAYOUT is defined, then it means that the watchdog should
remain enabled. So we should disable it only if CONFIG_WATCHDOG_NOWAYOUT is
not defined.
Also ensure that /dev/watchdog is only opened by one process at a time. That
way, a second process can't accidentally disable the watchdog while the first
process has it open. There shouldn't be any need for more than one process to
open /dev/watchdog anyway.
Signed-off-by: Timur Tabi <timur@freescale.com>
Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Annotate alim7101_pci_tbl as '__used' to fix following warning:
CC drivers/watchdog/alim7101_wdt.o
drivers/watchdog/alim7101_wdt.c:433: warning: ‘alim7101_pci_tbl’ defined but not used
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Annotate ali_pci_tbl as '__used' to fix following warning:
CC drivers/watchdog/alim1535_wdt.o
drivers/watchdog/alim1535_wdt.c:304: warning: ‘ali_pci_tbl’ defined but not used
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
The watchdog driver for the SUPERIO chip winbond w83627ehf does not work.
If you open /dev/watchdog and write a character to /dev/watchdog then
the watchdog will be triggered. However the watchdog will not trigger
the hardware RESET after the timeout, because the watchdog has never been
enabled.
Signed-off-by: Herman Morsink Vollenbroek <h.morsinkvollenbroek@home.nl>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
The following adds watchdog support for the Winbond W83627DHG chip.
I have tested it on a PQ7-M102XL (Intel Atom) board.
Signed-off-by: Benny Lønstrup Ammitzbøll <benny@ammitzboell-consult.dk>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Add Fintek f71869 as a supported watchdog device.
Signed-off-by: Michel Arboi <michel@arboi.fr.eu.org>
Acked-by: Giel van Schijndel <me@mortis.eu>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Watchdog support for Fintek F71862fg Super-I/O added.
Two different hardware reset pins of the F71862fg chip can be configured
by an additional module parameter.
Signed-off-by: Lutz Ballaschke <vegan.grindcore@googlemail.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Cleaned up and replaced some magic numbers by constants.
Signed-off-by: Lutz Ballaschke <vegan.grindcore@googlemail.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
A notification event 0x81 from an ACPI battery device requires us to
re-read the battery information structure. Follow this requirement
and remove and re-create the battery's attibutes in sysfs so that
they reflect the reporting units used by the battery at the moment
(those units may actually change sometimes at run time, which happens
on some Thinkpads).
The approach used in this patch was suggested by Matthew Garrett.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reported-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The wake_capable ACPI device flag is not necessary, because it is
only used in scan.c for recording the information that _PRW is
present for the given device. That information is only used by
acpi_add_single_object() to decide whether or not to call
acpi_bus_get_wakeup_device_flags(), so the flag may be dropped
if the _PRW check is moved to acpi_bus_get_wakeup_device_flags().
Moreover, acpi_bus_get_wakeup_device_flags() always returns 0,
so it really should be void.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
Before evaluating _PRW for devices that are reported as inactive or
not present by their _STA control methods we should check if those
methods are actually present (otherwise the evaulation of _PRW will
obviously fail and a scary message will be printed unnecessarily).
Reported-by: Andreas Mohr <andi@lisas.de>
Reported-by: Maciej Rutecki <maciej.rutecki@gmail.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
It certainly is not a good idea to execute _ON or _OFF and _STA
for the same power resource at the same time which may happen in
some circumstances in theory. To prevent that from happening,
read the power state of each power resource under its mutex, as
that will prevent the state from being changed at the same time.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
Rename acpi_power_off_device() to acpi_power_off() in analogy with
acpi_power_on().
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
init_fpu() (which is indirectly called by the fpu switching code) assumes
it is in process context. Rather than makeing init_fpu() use an atomic
allocation, which can cause a task to be killed, make sure the fpu is
already initialized when we enter the run loop.
KVM-Stable-Tag.
Reported-and-tested-by: Kirill A. Shutemov <kas@openvz.org>
Acked-by: Pekka Enberg <penberg@kernel.org>
Reviewed-by: Christoph Lameter <cl@linux.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
Since acpi_bus_set_power() should not use __acpi_bus_get_power() to
update the device's device->power.state field before changing its
power state (this may cause device->power.state to be inconsistent
with the device power resources' reference counters), remove this
call from it. In consequence, the acpi_power_nocheck variable is not
necessary any more, so it can be dropped along with the DMI table
used for setting that variable for HP Pavilion 05.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
There are no more users of acpi_bus_get_power(), so it can be
dropped. Moreover, it should be dropped, because it modifies
the device->power.state field of an ACPI device without updating
the reference counters of the device's power resources, which is
wrong.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
Use the new function acpi_bus_update_power(), which is safer than
acpi_bus_get_power(), for getting device power state in
acpi_fujitsu_add() and acpi_fujitsu_hotkey_add().
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Reported-and-Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Use the new function acpi_bus_update_power() for manipulating power
resources used by ACPI fan devices, which allows them to be put into
the right state during initialization and resume. Consequently,
remove the flags.force_power_state field from struct acpi_device,
which is not necessary any more.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
Depending on the organization of the ACPI namespace, power resource
device objects may generally be scanned after the "regular" device
objects that they are referred from through _PRn. This, in turn, may
cause acpi_bus_get_power_flags() to attempt to access them through
acpi_bus_init_power() before they are registered (and initialized by
acpi_power_driver). [This is not a theoretical issue, it actually
happens for one PnP device on my testbed HP nx6325.]
To fix this problem, make acpi_bus_get_power_flags() attempt to
register power resource devices as soon as they have been found in
the _PRn output for any other devices.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
