linux-toradex.git/arch, branch v2.6.31.7 Linux kernel for Apalis and Colibri modules speedstep-ich: fix error caused by 394122ab144dae4b276d74644a2f11c44a60ac5c 2009-12-08T18:22:11+00:00 Rusty Russell rusty@rustcorp.com.au 2009-11-03T07:35:30+00:00 7eeea230e8e078b125436e796cf30b71098107b7 commit 8dca15e40889e5d5e9655b03ba79c26200f760ce upstream. "[CPUFREQ] cpumask: avoid playing with cpus_allowed in speedstep-ich.c" changed the code to mistakenly pass the current cpu as the "processor" argument of speedstep_get_frequency(), whereas it should be the type of the processor. Addresses http://bugzilla.kernel.org/show_bug.cgi?id=14340 Based on a patch by Dave Mueller. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Acked-by: Dominik Brodowski <linux@brodo.de> Reported-by: Dave Mueller <dave.mueller@gmx.ch> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 8dca15e40889e5d5e9655b03ba79c26200f760ce upstream.

"[CPUFREQ] cpumask: avoid playing with cpus_allowed in speedstep-ich.c"
changed the code to mistakenly pass the current cpu as the "processor"
argument of speedstep_get_frequency(), whereas it should be the type of
the processor.

Addresses http://bugzilla.kernel.org/show_bug.cgi?id=14340

Based on a patch by Dave Mueller.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Acked-by: Dominik Brodowski <linux@brodo.de>
Reported-by: Dave Mueller <dave.mueller@gmx.ch>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
sparc: Move of_set_property_mutex acquisition outside of devtree_lock grab. 2009-12-08T18:22:04+00:00 David S. Miller davem@davemloft.net 2009-11-09T01:41:20+00:00 3c6f31de43c672ece8bcdd8262efd57c14c20c8f [ Upstream commit 1c9d80ddc60f8ac26344ec3db9830e5f8016c16d ] Otherwise we try to sleep with preemption disabled, etc. Noticed by Thomas Gleixner. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
[ Upstream commit 1c9d80ddc60f8ac26344ec3db9830e5f8016c16d ]

Otherwise we try to sleep with preemption disabled, etc.

Noticed by Thomas Gleixner.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
sparc64: replace parentheses in pmul() 2009-12-08T18:22:03+00:00 Roel Kluin roel.kluin@gmail.com 2009-11-08T08:26:56+00:00 e5ac34fd383ddae70158d220e45a25ad97b02452 [ Upstream commit 88b938e63e68fd35e603421f722be0f35dde1016 ] `>>' has a higher precedence than `?' so src2 evaluated to either 16 or 0 dependent on the bits set in rs2. Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
[ Upstream commit 88b938e63e68fd35e603421f722be0f35dde1016 ]

`>>' has a higher precedence than `?' so src2 evaluated to
either 16 or 0 dependent on the bits set in rs2.

Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Enable ACPI PDC handshake for VIA/Centaur CPUs 2009-12-08T18:21:48+00:00 Harald Welte HaraldWelte@viatech.com 2009-11-24T15:53:00+00:00 37ed9bf8e31377284ca719b823e6794386ee0d5b commit d77b81974521c82fa6fda38dfff1b491dcc62a32 upstream. In commit 0de51088e6a82bc8413d3ca9e28bbca2788b5b53, we introduced the use of acpi-cpufreq on VIA/Centaur CPU's by removing a vendor check for VENDOR_INTEL. However, as it turns out, at least the Nano CPU's also need the PDC (processor driver capabilities) handshake in order to activate the methods required for acpi-cpufreq. Since arch_acpi_processor_init_pdc() contains another vendor check for Intel, the PDC is not initialized on VIA CPU's. The resulting behavior of a current mainline kernel on such systems is: acpi-cpufreq loads and it indicates CPU frequency changes. However, the CPU stays at a single frequency This trivial patch ensures that init_intel_pdc() is called on Intel and VIA/Centaur CPU's alike. Signed-off-by: Harald Welte <HaraldWelte@viatech.com> Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit d77b81974521c82fa6fda38dfff1b491dcc62a32 upstream.

In commit 0de51088e6a82bc8413d3ca9e28bbca2788b5b53, we introduced the
use of acpi-cpufreq on VIA/Centaur CPU's by removing a vendor check for
VENDOR_INTEL.  However, as it turns out, at least the Nano CPU's also
need the PDC (processor driver capabilities) handshake in order to
activate the methods required for acpi-cpufreq.

Since arch_acpi_processor_init_pdc() contains another vendor check for
Intel, the PDC is not initialized on VIA CPU's.  The resulting behavior
of a current mainline kernel on such systems is:  acpi-cpufreq
loads and it indicates CPU frequency changes.  However, the CPU stays at
a single frequency

This trivial patch ensures that init_intel_pdc() is called on Intel and
VIA/Centaur CPU's alike.

Signed-off-by: Harald Welte <HaraldWelte@viatech.com>
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
kmap: fix build errors with DEBUG_HIGHMEM enabled 2009-12-08T18:21:10+00:00 Russell King rmk+kernel@arm.linux.org.uk 2009-11-18T18:03:19+00:00 ee83348407722a76b2cabc6c6628c55876fd51e3 commit 4ff1fa278b0bd1b2dd3c42efc0cb86788ffe05d5 upstream. d451564 broke ARM by requiring KM_IRQ_PTE, KM_NMI and KM_NMI_PTE to always be defined. Solve this by providing invalid definitions for these constants, but only if CONFIG_DEBUG_HIGHMEM is enabled. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 4ff1fa278b0bd1b2dd3c42efc0cb86788ffe05d5 upstream.

d451564 broke ARM by requiring KM_IRQ_PTE, KM_NMI and KM_NMI_PTE to
always be defined.  Solve this by providing invalid definitions for
these constants, but only if CONFIG_DEBUG_HIGHMEM is enabled.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
powerpc: Fix DEBUG_HIGHMEM build break from d4515646699 2009-12-08T18:21:10+00:00 Becky Bruce beckyb@kernel.crashing.org 2009-11-23T12:28:53+00:00 22e633d1ba54044a66de913d164987f1fa946eea commit e8105903d78c81119754a42926951d9d17e191ba upstream. Code was added to mm/higmem.c that depends on several kmap types that powerpc does not support. We add dummy invalid definitions for KM_NMI, KM_NM_PTE, and KM_IRQ_PTE. According to list discussion, this fix should not be needed anymore starting with 2.6.33. The code is commented to this effect so hopefully we will remember to remove this. Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit e8105903d78c81119754a42926951d9d17e191ba upstream.

Code was added to mm/higmem.c that depends on several
kmap types that powerpc does not support.  We add dummy
invalid definitions for KM_NMI, KM_NM_PTE, and KM_IRQ_PTE.

According to list discussion, this fix should not be needed
anymore starting with 2.6.33.  The code is commented to this
effect so hopefully we will remember to remove this.

Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
powerpc: Fix some late PowerMac G5 with PCIe ATI graphics 2009-11-10T00:23:15+00:00 Benjamin Herrenschmidt benh@kernel.crashing.org 2009-08-31T21:34:36+00:00 20cde25b833745a42ae7591592ec527653b569b4 commit cede3930f0ca6fef353fa01306c72a01420bd45e upstream. A misconfiguration by the firmware of the U4 PCIe bridge on PowerMac G5 with the U4 bridge (latest generations, may also affect the iMac G5 "iSight") is causing us to re-assign the PCI BARs of the video card, which can get it out of sync with the firmware, thus breaking offb. This works around it by fixing up the bridge configuration properly at boot time. It also fixes a bug where the firmware provides us with an incorrect set of accessible regions in the device-tree. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit cede3930f0ca6fef353fa01306c72a01420bd45e upstream.

A misconfiguration by the firmware of the U4 PCIe bridge on PowerMac G5
with the U4 bridge (latest generations, may also affect the iMac G5
"iSight") is causing us to re-assign the PCI BARs of the video card,
which can get it out of sync with the firmware, thus breaking offb.

This works around it by fixing up the bridge configuration properly
at boot time. It also fixes a bug where the firmware provides us with
an incorrect set of accessible regions in the device-tree.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
powerpc/pci: Fix regression in powerpc MSI-X 2009-11-10T00:23:14+00:00 Andre Detsch adetsch@br.ibm.com 2009-11-04T15:03:19+00:00 01ab8be189e37f37ede8bd9532bd22198062d631 commit 8435b027b87a78145992c37b0b8ed0f1b7761bf0 upstream. Patch f598282f5145036312d90875d0ed5c14b49fd8a7 exposed a problem in powerpc MSI-X functionality, making network interfaces such as ixgbe and cxgb3 stop to work when MSI-X is enabled. RX interrupts were not being generated. The problem was caused because MSI irq was not being effectively unmasked after device initialization. Signed-off-by: Andre Detsch <adetsch@br.ibm.com> Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 8435b027b87a78145992c37b0b8ed0f1b7761bf0 upstream.

Patch f598282f5145036312d90875d0ed5c14b49fd8a7 exposed a problem in
powerpc MSI-X functionality, making network interfaces such as ixgbe
and cxgb3 stop to work when MSI-X is enabled. RX interrupts were not
being generated.

The problem was caused because MSI irq was not being effectively
unmasked after device initialization.

Signed-off-by: Andre Detsch <adetsch@br.ibm.com>
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
powerpc/pmac: Fix issues with sleep on some powerbooks 2009-11-10T00:23:12+00:00 Benjamin Herrenschmidt benh@kernel.crashing.org 2009-10-09T11:27:54+00:00 6b05a888adf307827a8cc960a6f660555bf9a683 commit 11a50873ef2b3c1c3fe99a661c22c08f35d93553 upstream. Since the change of how interrupts are disabled during suspend, certain PowerBook models started exhibiting various issues during suspend or resume from sleep. I finally tracked it down to the code that runs various "platform" functions (kind of little scripts extracted from the device-tree), which uses our i2c and PMU drivers expecting interrutps to work, and at a time where with the new scheme, they have been disabled. This causes timeouts internally which for some reason results in the PMU being unable to see the trackpad, among other issues, really it depends on the machine. Most of the time, we fail to properly adjust some clocks for suspend/resume so the results are not always predictable. This patch fixes it by using IRQF_TIMER for both the PMU and the I2C interrupts. I prefer doing it this way than moving the call sites since I really want those platform functions to still be called after all drivers (and before sysdevs). We also do a slight cleanup to via-pmu.c driver to make sure the ADB autopoll mask is handled correctly when doing bus resets Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 11a50873ef2b3c1c3fe99a661c22c08f35d93553 upstream.

Since the change of how interrupts are disabled during suspend,
certain PowerBook models started exhibiting various issues during
suspend or resume from sleep.

I finally tracked it down to the code that runs various "platform"
functions (kind of little scripts extracted from the device-tree),
which uses our i2c and PMU drivers expecting interrutps to work,
and at a time where with the new scheme, they have been disabled.

This causes timeouts internally which for some reason results in
the PMU being unable to see the trackpad, among other issues, really
it depends on the machine. Most of the time, we fail to properly adjust
some clocks for suspend/resume so the results are not always
predictable.

This patch fixes it by using IRQF_TIMER for both the PMU and the I2C
interrupts. I prefer doing it this way than moving the call sites since
I really want those platform functions to still be called after all
drivers (and before sysdevs).

We also do a slight cleanup to via-pmu.c driver to make sure the
ADB autopoll mask is handled correctly when doing bus resets

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
powerpc/pmac: Fix PowerSurge SMP IPI allocation 2009-11-10T00:23:11+00:00 Benjamin Herrenschmidt benh@kernel.crashing.org 2009-07-14T20:56:58+00:00 e434e9fc1661989db1a39b6f5be29c39e13b419a commit 527b3639616b21c257518ee7c26fbf05232db0c0 upstream. The code for setting up the IPIs for SMP PowerSurge marchines bitrot, it needs to properly map the HW interrupt number Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
commit 527b3639616b21c257518ee7c26fbf05232db0c0 upstream.

The code for setting up the IPIs for SMP PowerSurge marchines bitrot,
it needs to properly map the HW interrupt number

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>