Jean Delvare [Wed, 7 Jan 2009 15:37:35 +0000 (16:37 +0100)]
hwmon: Check for ACPI resource conflicts
Check for ACPI resource conflicts in hwmon drivers. I've included
all Super-I/O and PCI drivers.
I've voluntarily left out:
* Vendor-specific drivers: if they conflicted on any system, this would
pretty much mean that they conflict on all systems, and we would know
by now.
* Legacy ISA drivers (lm78 and w83781d): they only support chips found
on old designs were ACPI either wasn't supported or didn't deal with
thermal management.
* Drivers accessing the I/O resources indirectly (e.g. through SMBus):
the checks are already done where they belong, i.e. in the bus drivers.
Signed-off-by: Jean Delvare <jdelvare@suse.de> Acked-by: David Hubbard <david.c.hubbard@gmail.com>
Manuel Lauss [Wed, 7 Jan 2009 15:37:34 +0000 (16:37 +0100)]
hwmon: (lm70) Add TI TMP121 support
The Texas Instruments TMP121 is a SPI temperature sensor very similar
to the LM70, with slightly higher resolution. This patch extends the
LM70 driver to support the TMP121. The TMP123 differs in pin assign-
ment.
Signed-off-by: Manuel Lauss <mano@roarinelk.homelinux.net> Signed-off-by: Jean Delvare <khali@linux-fr.org>
This fixes a byteswap bug in the LM70 temperature sensor driver,
which was previously covered up by a converse bug in the driver
for the LM70EVAL-LLP board (which is also fixed).
Other fixes: doc updates, remove an annoying msleep(), and improve
three-wire protocol handling.
Signed-off-by: Kaiwan N Billimoria <kaiwan@designergraphix.com>
[ dbrownell@users.sourceforge.net: doc and whitespace tweaks ] Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Jean Delvare <khali@linux-fr.org>
Hans de Goede [Wed, 7 Jan 2009 15:37:33 +0000 (16:37 +0100)]
hwmon: Deprecate the fscher and fscpos drivers
Now that the new merged fschmd driver has gained support for the watchdog
integrated into these IC's, there is no more reason to keep the old fscher
and fscpos drivers around, so mark them as deprecated.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jean Delvare <khali@linux-fr.org>
Darrick J. Wong [Wed, 7 Jan 2009 15:37:33 +0000 (16:37 +0100)]
hwmon: (i5k_amb) Load automatically on all 5000/5400 chipsets
It turns out that we cannot create a pci_driver in this driver because PCI will
not call this module's probe function if the i5000-edac driver is already
loaded. That said, we only want one value (AMBASE) from the PCI config space.
Neither driver alters this value, so it's safe to read it. However, we still
want the module aliases, so provide that.
Signed-off-by: Darrick J. Wong <djwong@us.ibm.com> Signed-off-by: Jean Delvare <khali@linux-fr.org>
Allow it87.c to handle IT8720 chipset like IT8718 in order to
retrieve voltage, temperatures and fans speed from sensors
tools. Also updating the related documentation.
Signed-off-by: Jean-Marc Spaggiari <jean-marc@spaggiari.org> Signed-off-by: Jean Delvare <khali@linux-fr.org>
Jean Delvare [Wed, 7 Jan 2009 15:37:32 +0000 (16:37 +0100)]
hwmon: Don't overuse I2C_CLIENT_MODULE_PARM
I2C_CLIENT_MODULE_PARM is overkill for force_subclients. We really
only use 4 out of the 48 slots, so we're better defining a custom
variable instead. This change saves 92 bytes of data for each of the
five drivers affected.
Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: Wolfgang Grandegger <wg@grandegger.com> Acked-by: Marc Hulsman <m.hulsman@tudelft.nl> Cc: Mark M. Hoffman <mhoffman@lightlink.com>
Hans de Goede [Wed, 7 Jan 2009 15:37:31 +0000 (16:37 +0100)]
hwmon: (f71882fg) Fix fan_to/from_reg prototypes
The RPM after conversion from / before conversion to a register value can be
much more than 65535 (up to 1500000), so putting this into an u16 can cause
overflows. This changes the functions to use an int to store / get RPM instead.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jean Delvare <khali@linux-fr.org>
Hans de Goede [Wed, 7 Jan 2009 15:37:29 +0000 (16:37 +0100)]
hwmon: (f71882fg) Separate max and crit alarm and beep
While studying the datasheets for adding F8000 support, I noticed that the
F718x2 has separate alarms (and beep control) for its max and crit limits.
We keep the temp#_alarm attributes as they are, even though it would be more
logical to rename them to temp#_max_alarm. Because lm_sensors v2 depends
on them.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jean Delvare <khali@linux-fr.org>
Hans de Goede [Wed, 7 Jan 2009 15:37:29 +0000 (16:37 +0100)]
hwmon: (f71882fg) Cleanup fan and temp hyst functions
Simplify fan and temp hyst. handling by treating the registers as an array of
nibbles instead of using switch cases. Also unify the way hysts are handled
between temp and fans, the temp code was storing the actual per temp hyst
values in 4 u8's, where as the fan code was storing actual register values.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jean Delvare <khali@linux-fr.org>
Hans de Goede [Wed, 7 Jan 2009 15:37:28 +0000 (16:37 +0100)]
hwmon: (f71882fg) Fix various sysfs callback function issues
While working on adding F8000 support I noticed that various of the
store sysfs functions (and a few of the show also) had issues.
This patch fixes the following issues in these functions:
* store: storing the result of strto[u]l in an int, resulting in a possible
overflow before boundary checking
* store: use of f71882fg_update_device(), we don't want to read the whole
device in store functions, just the registers we need
* store: use of cached register values instead of reading the needed regs
in the store function, including cases where f71882fg_update_device() was
not used, this could cause real isues
* show: shown value is a calculation of 2 or more cached register reads,
without locking the data struct.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jean Delvare <khali@linux-fr.org>
Hans de Goede [Wed, 7 Jan 2009 15:37:28 +0000 (16:37 +0100)]
hwmon: (f71882fg) Prepare for adding F8000 support
This patch is a preparation patch for adding F8000 support to the f71882fg
driver. If you look at the register addresses and esp, the bits used for
the temperature channels, then you will notice that it appears that they
start at 1 in a system meant to start at 0. As the F8000 actually uses the 0
addresses and bits, this patch changes the f71882fg driver to take 4
temperatures numbered 0-3 in to account, using 1-3 in this new scheme for
the temperatures actually present in the F718x2FG.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jean Delvare <khali@linux-fr.org>
Hans de Goede [Wed, 7 Jan 2009 15:37:28 +0000 (16:37 +0100)]
hwmon: (f71882fg) Move some io access from the detect to the probe function
The f71882fg driver did some io to ioports it hadn't reserved yet in its
find (detect) function, this patches moves this io to the probe function
where these ports are reserved and this io belongs.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jean Delvare <khali@linux-fr.org>
Add PWM (fan speed control) support to the f71882fg driver. Both
manual control and automatic (temperature-based) modes are supported.
Additionally, each mode has a PWM-based and an RPM-based variant. By
default we use the mode set by the BIOS.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Cc: Mark van Doesburg <mark.vandoesburg@hetnet.nl> Signed-off-by: Jean Delvare <khali@linux-fr.org>
Convert f71882fg driver from SENSOR_ATTR to SENSOR_ATTR2 use, this is a
preparation patch for adding pwm support, which is broken out to make what
changes really in the pwm support patch clear.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Cc: Mark van Doesburg <mark.vandoesburg@hetnet.nl> Signed-off-by: Jean Delvare <khali@linux-fr.org>
Paul Walmsley [Wed, 7 Jan 2009 15:23:46 +0000 (17:23 +0200)]
OMAP3 SmartReflex: get rid of custom clocks
smartreflex.c defines some custom clocks that don't have clockdomains
associated with them, which is now disallowed. The custom clocks are
not actually needed, so remove them. This patch should not cause any
functional change.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kalle Jokiniemi <ext-kalle.jokiniemi@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Paul Walmsley [Wed, 7 Jan 2009 15:23:46 +0000 (17:23 +0200)]
OMAP2/3 clock: don't tinker with hardirqs when they are supposed to be disabled
Clock rate change code executes inside a spinlock with hardirqs
disabled. The only code that should be messing around with the
hardirq state should be the plat-omap/clock.c code. In the
omap2_reprogram_dpllcore() case, this probably just wastes cycles, but
in the omap3_core_dpll_m2_set_rate() case, this is a nasty bug.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Paul Walmsley [Wed, 7 Jan 2009 15:23:45 +0000 (17:23 +0200)]
OMAP2/3 clock: omap2_clk_enable(): fix bugs in clockdomain handling
omap2_clk_enable() should enable a clock's clockdomain before
attempting to enable its parent clock's clockdomain. Similarly, in
the unlikely event that the parent clock enable fails, the clockdomain
should be disabled.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Paul Walmsley [Wed, 7 Jan 2009 15:23:45 +0000 (17:23 +0200)]
OMAP2/3 clock: every clock must have a clkdm
Every OMAP2/3 clock must now have an assigned clockdomain, so we can
remove the checks from clk_enable()/clk_disable(). Instead, verify
that the clockdomain is present only at clock init time via the
arch_clock clk_register() hook.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Provide a mechanism for OMAP chip family (e.g., OMAP1, 2, 3) clock
code to define a clk_register function via struct clk_functions. This
is currently only used for OMAP2/3, to handle clock->clockdomain
registration.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Paul Walmsley [Wed, 7 Jan 2009 15:23:45 +0000 (17:23 +0200)]
OMAP clock: drop clk_get_usecount()
This function is race-prone and mistakenly conveys the impression to
drivers that it is part of the clock interface. Get rid of it: core
code that absolutely needs this can just check clk->usecount. Drivers
should not use it at all.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Paul Walmsley [Wed, 7 Jan 2009 15:23:45 +0000 (17:23 +0200)]
OMAP2/3 clock: convert remaining MPU barriers into OCP barriers
Several parts of the OMAP2/3 clock code use wmb() to try to ensure
that the hardware write completes before continuing. This approach is
problematic: wmb() only ensures that the write leaves the ARM. It
does not ensure that the write actually reaches the endpoint device.
The endpoint device in this case - either the PRM, CM, or SCM - is
three interconnects away from the ARM - and the final interconnect is
low-speed. And the OCP interconnects will post the write, and who
knows how long that will take to complete. So the wmb() is not what
we want. Worse, the wmb() is indiscriminate; it causes the ARM to
flush any other unrelated buffered writes and wait for the local
interconnect to acknowledge them - potentially very expensive.
Fix this by converting the wmb()s into readbacks of the same PRM/CM/SCM
register. Since the PRM/CM/SCM devices use a single OCP thread, this
will cause the MPU to block while waiting for posted writes to that device
to complete.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Consolidate the commit code for DELAYED_APP clocks into a subroutine,
_omap2xxx_clk_commit(). Also convert the MPU barrier wmb() into an
OCP barrier, since with an MPU barrier, we have no guarantee that the
write actually reached the endpoint device.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Paul Walmsley [Wed, 7 Jan 2009 15:23:21 +0000 (17:23 +0200)]
OMAP2/3 clock: don't use a barrier after clk_disable()
clk_disable() previously used an ARM barrier, wmb(), to try to ensure
that the hardware write completed before continuing. There are some
problems with this approach.
The first problem is that wmb() only ensures that the write leaves the
ARM -- not that it actually reaches the endpoint device. In this
case, the endpoint device - either the PRM, CM, or SCM - is three
interconnects away from the ARM, and the final interconnect is
low-speed. And the OCP interconnects will post the write, who knows
how long that will take to complete. So the wmb() is not really what
we want.
Worse, the wmb() is indiscriminate; it will cause the ARM to flush any
other unrelated buffered writes and wait for the local interconnect to
acknowledge them - potentially very expensive.
This first problem could be fixed by doing a readback of the same PRM/CM/SCM
register. Since these devices use a single OCP thread, this will cause the
MPU to wait for the write to complete.
But the primary problem is a conceptual one: clk_disable() should not
need any kind of barrier. clk_enable() needs one since device driver
code must not access a device until its clocks are known to be
enabled. But clk_disable() has no such restriction.
Since blocking the MPU on a PRM/CM/SCM write can be a very
high-latency operation - several hundred MPU cycles - it's worth
avoiding this barrier if possible.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Russell King [Wed, 7 Jan 2009 15:23:21 +0000 (17:23 +0200)]
OMAP clock: rearrange clock.h structure order
... to eliminate unnecessary padding. We have rather a lot of these
structures, so eliminating unnecessary padding results in a saving of
1488 bytes.
[paul@pwsan.com: updated against current linux-omap clock tree, now saves
1512 bytes on OMAP3 builds]
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Russell King [Wed, 7 Jan 2009 15:20:26 +0000 (17:20 +0200)]
OMAP2/3 clock: remove clk->owner
clk->owner is always NULL, so its existence doesn't serve any useful
function other than bloating the kernel by 992 bytes. Remove it.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Paul Walmsley [Wed, 7 Jan 2009 15:20:25 +0000 (17:20 +0200)]
OMAP2 clock: drop CONFIG_PARTICIPANT clock flag
The CONFIG_PARTICIPANT flags indicates to the clock rate and parent
changing functions that they should not be used on this clock. Better
just to remove the clock function pointers that operate on those
clocks. The name of the flag is just terrible: its meaning has almost
nothing to do with its name, and the use of the CONFIG_ prefix makes
it appear to be a Kconfig option. Get rid of it.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Russell King [Wed, 7 Jan 2009 15:20:25 +0000 (17:20 +0200)]
OMAP clock: remove VIRTUAL_CLOCK
Nothing tests the clock flags for this bit, so it serves no purpose.
Remove it.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Paul Walmsley [Wed, 7 Jan 2009 15:20:25 +0000 (17:20 +0200)]
OMAP clock: drop RATE_FIXED
The RATE_FIXED flag currently has no useful purpose. Fixed rate clocks
should simply not implement the recalc, set_rate, set_parent, and round_rate
function pointers.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Paul Walmsley [Wed, 7 Jan 2009 15:20:24 +0000 (17:20 +0200)]
OMAP clock: track child clocks
Track child clocks for each struct clk. This optimizes traversals of the
clock tree from parent to child, which happens during rate propagation, and
in the future, clock notifiers.
Previously, parent-to-child traversals sequentially scanned the entire
clock list at each step to determine the children of a particular
clock node. Now each struct clk maintains a clock list of its
children. For a DPLL3_M2_CK rate change, this converts what were
about O(6*180*2) operations into O(6*6*2) operations. The savings
will be even more significant after the future notifier patches:
something like O(6*180*6) to O(6*6*6).
The price paid is additional runtime memory consumption - 8 bytes per
clock and 16 bytes per child clock - roughly 4.5KiB on OMAP3. The
memory comes mostly from bootmem, since initial clock registration
takes place before slab is ready. Several other operations will take
slightly more time due the extra bookkeeping: clk_register(),
clk_unregister(), clk_set_parent(), and omap2_init_clksel_parent().
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Paul Walmsley [Wed, 7 Jan 2009 15:20:24 +0000 (17:20 +0200)]
OMAP clock: support "dry run" rate and parent changes
For upcoming notifier support, modify the rate recalculation code to
take parent rate and rate storage parameters. The goal here is to
allow the clock code to determine what the clock's rate would be after
a parent change or a rate change, without actually changing the
hardware registers. This is used by the upcoming notifier patches to
pass a clock's current and planned rates to the notifier callbacks.
Also add a new clock flag, RECALC_ON_ENABLE, which causes the clock
framework code to recalculate the current clock's rate and propagate
down the tree after a clk_enable() or clk_disable(). This is used by
the OMAP3 DPLLs, which change rates when they enable or disable, unlike
most clocks.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Paul Walmsley [Wed, 7 Jan 2009 15:20:23 +0000 (17:20 +0200)]
OMAP2/3 clock: drop recalc function pointers from fixed rate clocks
Now that rate recalculation and rate propagation are two separate
operations, drop recalc function pointers from all fixed rate clocks.
Their rates are fixed, so there's no need to recalculate.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Paul Walmsley [Wed, 7 Jan 2009 15:20:23 +0000 (17:20 +0200)]
OMAP clock: move rate recalc, propagation code up to plat-omap/clock.c
Previously the individual clock recalculation functions handled their
own rate recalculation. This can be handled in the clk_set_rate(),
clk_set_parent(), and recalculate_root_clocks() functions in
plat-omap/clock.c. Removes duplicate code and clarifies the role of the
recalc functions.
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Paul Walmsley [Wed, 7 Jan 2009 15:20:23 +0000 (17:20 +0200)]
OMAP2/3 clock: use standard set_rate fn in omap2_clk_arch_init()
Use the standard clk_set_rate() function in omap2_clk_arch_init()
rather than omap2_select_table_rate() -- this will ensure that clock
rates are recalculated and propagated correctly after those operations
are consolidated into clk_set_rate().
Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
Bernd Schmidt [Wed, 7 Jan 2009 15:14:38 +0000 (23:14 +0800)]
Blackfin arch: Faster C implementation of no-MPU CPLB handler
This is a mixture ofcMichael McTernan's patch and the existing cplb-mpu code.
We ditch the old cplb-nompu implementation, which is a good example of
why a good algorithm in a HLL is preferrable to a bad algorithm written in
assembly. Rather than try to construct a table of all posible CPLBs and
search it, we just create a (smaller) table of memory regions and
their attributes. Some of the data structures are now unified for both
the mpu and nompu cases. A lot of needless complexity in cplbinit.c is
removed.
Further optimizations:
* compile cplbmgr.c with a lot of -ffixed-reg options, and omit saving
these registers on the stack when entering a CPLB exception.
* lose cli/nop/nop/sti sequences for some workarounds - these don't
* make
sense in an exception context
Additional code unification should be possible after this.
[Mike Frysinger <vapier.adi@gmail.com>:
- convert CPP if statements to C if statements
- remove redundant statements
- use a do...while loop rather than a for loop to get slightly better
optimization and to avoid gcc "may be used uninitialized" warnings ...
we know that the [id]cplb_nr_bounds variables will never be 0, so this
is OK
- the no-mpu code was the last user of MAX_MEM_SIZE and with that rewritten,
we can punt it
- add some BUG_ON() checks to make sure we dont overflow the small
cplb_bounds array
- add i/d cplb entries for the bootrom because there is functions/data in
there we want to access
- we do not need a NULL trailing entry as any time we access the bounds
arrays, we use the nr_bounds variable
]
Signed-off-by: Michael McTernan <mmcternan@airvana.com> Signed-off-by: Mike Frysinger <vapier.adi@gmail.com> Signed-off-by: Bernd Schmidt <bernds_cb1@t-online.de> Signed-off-by: Bryan Wu <cooloney@kernel.org>
Robin Getz [Wed, 7 Jan 2009 15:14:39 +0000 (23:14 +0800)]
Blackfin arch: panic when running on a chip rev below what we are compiled for
If we are running on a chip revision below what we are compiled for,
there will be missing anomaly workarounds, and a panic is inevitable. Do
is sooner, rather than later, so people don't look for bugs that already
have workarounds (that they turned off).
Signed-off-by: Robin Getz <rgetz@blackfin.uclinux.org> Signed-off-by: Bryan Wu <cooloney@kernel.org>
projects / linux-2.6-omap-h63xx.git / log