Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 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
  3. 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
  5. 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
  7. 21 11月, 2012 1 次提交
  9. 20 11月, 2012 1 次提交
  11. 19 11月, 2012 1 次提交
    • L
      ARM: davinci: dm644x: fix out range signal for ED · e37212aa
      由 Lad, Prabhakar 提交于 
      Fix the video clock setting when custom timings are used with
pclock <= 27MHz. Existing video clock selection uses PLL2 mode
which results in a 54MHz clock whereas using the MXI mode results
in a 27MHz clock (which is the one actually desired).

This bug affects the Enhanced Definition (ED) support on DM644x.
Without this patch, out-range signals errors are were observed on
the TV when viewing ED. An out-of-range signal is often caused when
the field rate is above the rate that the television will handle.
Signed-off-by: NLad, Prabhakar <prabhakar.lad@ti.com>
Signed-off-by: NManjunath Hadli <manjunath.hadli@ti.com>
Cc: Sekhar Nori <nsekhar@ti.com>
[nsekhar@ti.com: reword commit message based on on-list discussion]
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
      e37212aa
  13. 16 11月, 2012 4 次提交
  15. 14 11月, 2012 1 次提交
  17. 13 11月, 2012 2 次提交
    • F
      ARM: boot: Fix usage of kecho · 2d4d07b9
      由 Fabio Estevam 提交于 
      Since commit edc88ceb (ARM: be really quiet when building with 'make -s') the
following output is generated when building a kernel for ARM:

echo '  Kernel: arch/arm/boot/Image is ready'
  Kernel: arch/arm/boot/Image is ready
  Building modules, stage 2.
echo '  Kernel: arch/arm/boot/zImage is ready'
  Kernel: arch/arm/boot/zImage is ready

As per Documentation/kbuild/makefiles.txt the correct way of using kecho is
'@$(kecho)'.

Make this change so no more unwanted 'echo' messages are displayed.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      2d4d07b9
    • K
      ARM: OMAP4: TWL: mux sys_drm_msecure as output for PMIC · 1ef43369
      由 Kevin Hilman 提交于 
      On OMAP4 boards using the TWL6030 PMIC, the sys_drm_msecure is
connected to the MSECURE input of the TWL6030 PMIC.  This signal
controls the secure-mode operation of the PMIC.  If its not mux'd
correctly, some functionality of the PMIC will not be accessible since
the PMIC will be in secure mode.

For example, if the TWL RTC is in secure mode, most of its registers
are read-only, meaning (re)programming the RTC (e.g. for wakeup from
suspend) will fail.

To fix, ensure the signal is properly mux'd as output when TWL is
intialized.

This fix is required when using recent versions of u-boot (>= v2012.04.01)
since u-boot is no longer setting the default mux for this pin.
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      1ef43369
  19. 12 11月, 2012 2 次提交
  21. 09 11月, 2012 1 次提交
  23. 08 11月, 2012 3 次提交
  25. 07 11月, 2012 1 次提交
  27. 06 11月, 2012 2 次提交
  29. 04 11月, 2012 1 次提交
  31. 31 10月, 2012 3 次提交
    • P
      ARM: OMAP4: hwmod data: do not enable or reset the McPDM during kernel init · bc05244e
      由 Paul Walmsley 提交于 
      Resolve this kernel boot message:

omap_hwmod: mcpdm: cannot be enabled for reset (3)

The McPDM on OMAP4 can only receive its functional clock from an
off-chip source.  This source is not guaranteed to be present on the
board, and when present, it is controlled by I2C.  This would
introduce a board dependency to the early hwmod code which it was not
designed to handle.  Also, neither the driver for this off-chip clock
provider nor the I2C code is available early in boot when the hwmod
code is attempting to enable and reset IP blocks.  This effectively
makes it impossible to enable and reset this device during hwmod init.

At its core, this patch is a workaround for an OMAP hardware problem.
It should be possible to configure the OMAP to provide any IP block's
functional clock from an on-chip source.  (This is true for almost
every IP block on the chip.  As far as I know, McPDM is the only
exception.)  If the kernel cannot reset and configure IP blocks, it
cannot guarantee a sane SoC state.  Relying on an optional off-chip
clock also creates a board dependency which is beyond the scope of the
early hwmod code.

This patch works around the issue by marking the McPDM hwmod record
with the HWMOD_EXT_OPT_MAIN_CLK flag.  This prevents the hwmod
code from touching the device early during boot.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Péter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
      bc05244e
    • P
      ARM: OMAP2+: hwmod: add flag to prevent hwmod code from touching IP block during init · 5fb3d522
      由 Paul Walmsley 提交于 
      Add HWMOD_EXT_OPT_MAIN_CLK flag to indicate that this IP block is
dependent on an off-chip functional clock that is not guaranteed to be
present during initialization.  IP blocks marked with this flag are
left in the INITIALIZED state during kernel init.

This is a workaround for a hardware problem.  It should be possible to
guarantee that at least one clock source will be present and active
for any IP block's main functional clock.  This ensures that the hwmod
code can enable and reset the IP block.  Resetting the IP block during
kernel init prevents any bogus bootloader, ROM code, or previous OS
configuration from affecting the kernel.  Hopefully a clock
multiplexer can be added on future SoCs.

N.B., at some point in the future, it should be possible to query the
clock framework for this type of information.  Then this flag should
no longer be needed.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
      5fb3d522
    • P
      ARM: dt: tegra: fix length of pad control and mux registers · 322337b8
      由 Pritesh Raithatha 提交于 
      The reg property contains <base length> not <base last_offset>. Fix
the length values to be length not last_offset.

Cc: stable@vger.kernel.org
Signed-off-by: NPritesh Raithatha <praithatha@nvidia.com>
Signed-off-by: NStephen Warren <swarren@nvidia.com>
      322337b8
  33. 30 10月, 2012 3 次提交
  35. 29 10月, 2012 1 次提交