Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 07 12月, 2012 2 次提交
  3. 02 12月, 2012 1 次提交
  5. 28 11月, 2012 1 次提交
    • W
      ARM: 7586/1: sp804: set cpumask to cpu_possible_mask for clock event device · ea3aacf5
      由 Will Deacon 提交于 
      The SP804 driver statically initialises the cpumask of the clock event
device to be cpu_all_mask, which is derived from the compile-time
constant NR_CPUS. This breaks SMP_ON_UP systems where the interrupt
controller handling the sp804 doesn't have the irq_set_affinity callback
on the irq_chip, because the common timer code fails to identify the
device as cpu-local and ends up treating it as a broadcast device
instead.

This patch fixes the problem by using cpu_possible_mask at runtime,
which will correctly represent the possible CPUs when SMP_ON_UP is being
used.
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ea3aacf5
  7. 23 11月, 2012 1 次提交
    • D
      ARM: 7583/1: decompressor: Enable unaligned memory access for v6 and above · 5010192d
      由 Dave Martin 提交于 
      Modern GCC can generate code which makes use of the CPU's native
unaligned memory access capabilities.  This is useful for the C
decompressor implementations used for unpacking compressed kernels.

This patch disables alignment faults and enables the v6 unaligned
access model on CPUs which support these features (i.e., v6 and
later), allowing full unaligned access support for C code in the
decompressor.

The decompressor C code must not be built to assume that unaligned
access works if support for v5 or older platforms is included in
the kernel.

For correct code generation, C decompressor code must always use
the get_unaligned and put_unaligned accessors when dealing with
unaligned pointers, regardless of this patch.
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      5010192d
  9. 22 11月, 2012 11 次提交
    • A
      IXP4xx: use __iomem for MMIO · 0d2c9f05
      由 Arnd Bergmann 提交于 
      The ixp4xx queue manager uses "const struct qmgr_regs __iomem *" as the
type for a pointer that is passed to __raw_writel, which is not
allowed because of the const-ness.

Dropping the 'const' keyword fixes the problem. While we're here,
let's also drop the useless type cast.

Without this patch, building ixp4xx_defconfig results in:

In file included from arch/arm/mach-ixp4xx/ixp4xx_qmgr.c:15:0:
arch/arm/mach-ixp4xx/include/mach/qmgr.h: In function 'qmgr_put_entry':
arch/arm/mach-ixp4xx/include/mach/qmgr.h:96:2: warning: passing argument 2 of '__raw_writel' discards 'const' qualifier from pointer target type [enabled by default]
arch/arm/include/asm/io.h:88:91: note: expected 'volatile void *' but argument is of type 'const u32 *'
In file included from drivers/net/ethernet/xscale/ixp4xx_eth.c:41:0:
arch/arm/mach-ixp4xx/include/mach/qmgr.h: In function 'qmgr_put_entry':
arch/arm/mach-ixp4xx/include/mach/qmgr.h:96:2: warning: passing argument 2 of '__raw_writel' discards 'const' qualifier from pointer target type [enabled by default]
arch/arm/include/asm/io.h:88:91: note: expected 'volatile void *' but argument is of type 'const u32 *'
arch/arm/mach-ixp4xx/ixp4xx_qmgr.c: In function 'qmgr_set_irq':
arch/arm/mach-ixp4xx/ixp4xx_qmgr.c:41:9: warning: passing argument 2 of '__raw_writel' discards 'const' qualifier from pointer target type [enabled by default]
arch/arm/include/asm/io.h:88:91: note: expected 'volatile void *' but argument is of type 'const u32 *'
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NKrzysztof Hałasa <khc@pm.waw.pl>
      0d2c9f05
    • K
      IXP4xx: map CPU config registers within VMALLOC region. · b7b23db7
      由 Krzysztof Hałasa 提交于 
      Signed-off-by: NKrzysztof Hałasa <khc@pm.waw.pl>
      b7b23db7
    • K
      IXP4xx: Always ioremap() Queue Manager MMIO region at boot. · f0cdb153
      由 Krzysztof Hałasa 提交于 
      It doesn't make much sense to map QMgr dynamically - we almost always need it
and the static mapping will be needed for little-endian data-coherent operation
(to make QMgr region value-coherent).
Signed-off-by: NKrzysztof Hałasa <khc@pm.waw.pl>
      f0cdb153
    • T
      ixp4xx: Declare MODULE_FIRMWARE usage · 05cd3db0
      由 Tim Gardner 提交于 
      Cc: Krzysztof Halasa <khc@pm.waw.pl>
Cc: Imre Kaloz <kaloz@openwrt.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: NTim Gardner <tim.gardner@canonical.com>
Signed-off-by: NKrzysztof Hałasa <khc@pm.waw.pl>
      05cd3db0
    • K
      IXP4xx: Remove time limit for PCI TRDY to enable use of slow devices. · f203bc64
      由 Krzysztof Hałasa 提交于 
      Signed-off-by: NKrzysztof Hałasa <khc@pm.waw.pl>
      f203bc64
    • K
      IXP4xx: Fix off-by-one bug in Goramo MultiLink platform. · 87ba5c6a
      由 Krzysztof Hałasa 提交于 
      Signed-off-by: NKrzysztof Hałasa <khc@pm.waw.pl>
      87ba5c6a
    • K
      IXP4xx: Fix Goramo MultiLink platform compilation. · 3043c5c8
      由 Krzysztof Hałasa 提交于 
      Signed-off-by: NKrzysztof Hałasa <khc@pm.waw.pl>
      3043c5c8
    • I
      ARM - OMAP: ads7846: fix pendown debounce setting · 0a0d6285
      由 Igor Grinberg 提交于 
      Commit 97ee9f01 (ARM: OMAP: fix the ads7846 init code) have enabled the
pendown GPIO debounce time setting by the below sequence:

  gpio_request_one()
  gpio_set_debounce()
  gpio_free()

It also revealed a bug in the OMAP GPIO handling code which prevented
the GPIO debounce clock to be disabled and CORE transition to low power
states.

Commit c9c55d92 (gpio/omap: fix off-mode bug: clear debounce settings on
free/reset) fixes the OMAP GPIO handling code by making sure that the
GPIO debounce clock gets disabled if no GPIO is requested from current
bank.

While fixing the OMAP GPIO handling code (in the right way), the above
commit makes the gpio_request->set_debounce->free sequence invalid as
after freeing the GPIO, the debounce settings are lost.

Fix the debounce settings by moving the debounce initialization to the
actual GPIO requesting code - the ads7846 driver.
Signed-off-by: NIgor Grinberg <grinberg@compulab.co.il>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      0a0d6285
    • J
      ARM: Kirkwood: Update PCI-E fixup · 1dc831bf
      由 Jason Gunthorpe 提交于 
      - The code relies on rc_pci_fixup being called, which only happens
  when CONFIG_PCI_QUIRKS is enabled, so add that to Kconfig. Omitting
  this causes a booting failure with a non-obvious cause.
- Update rc_pci_fixup to set the class properly, copying the
  more modern style from other places
- Correct the rc_pci_fixup comment
Signed-off-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: stable@vger.kernel.org
Signed-off-by: NJason Cooper <jason@lakedaemon.net>
      1dc831bf
    • R
      Dove: Fix irq_to_pmu() · d356cf5a
      由 Russell King - ARM Linux 提交于 
      PMU interrupts start at IRQ_DOVE_PMU_START, not IRQ_DOVE_PMU_START + 1.
Fix the condition.  (It may have been less likely to occur had the code
been written "if (irq >= IRQ_DOVE_PMU_START" which imho is the easier
to understand notation, and matches the normal way of thinking about
these things.)
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Cc: stable@vger.kernel.org
Signed-off-by: NJason Cooper <jason@lakedaemon.net>
      d356cf5a
    • R
      Dove: Attempt to fix PMU/RTC interrupts · 5d3df935
      由 Russell King - ARM Linux 提交于 
      Fix the acknowledgement of PMU interrupts on Dove: some Dove hardware
has not been sensibly designed so that interrupts can be handled in a
race free manner.  The PMU is one such instance.

The pending (aka 'cause') register is a bunch of RW bits, meaning that
these bits can be both cleared and set by software (confirmed on the
Armada-510 on the cubox.)

Hardware sets the appropriate bit when an interrupt is asserted, and
software is required to clear the bits which are to be processed.  If
we write ~(1 << bit), then we end up asserting every other interrupt
except the one we're processing.  So, we need to do a read-modify-write
cycle to clear the asserted bit.

However, any interrupts which occur in the middle of this cycle will
also be written back as zero, which will also clear the new interrupts.

The upshot of this is: there is _no_ way to safely clear down interrupts
in this register (and other similarly behaving interrupt pending
registers on this device.)  The patch below at least stops us creating
new interrupts.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Cc: stable@vger.kernel.org
Signed-off-by: NJason Cooper <jason@lakedaemon.net>
      5d3df935
  11. 21 11月, 2012 2 次提交
  13. 20 11月, 2012 8 次提交
  15. 19 11月, 2012 12 次提交
  17. 16 11月, 2012 2 次提交