Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 19 11月, 2012 4 次提交
  3. 09 11月, 2012 1 次提交
  5. 07 11月, 2012 1 次提交
  7. 04 11月, 2012 1 次提交
  9. 30 10月, 2012 1 次提交
  11. 29 10月, 2012 3 次提交
    • W
      ARM: 7567/1: io: avoid GCC's offsettable addressing modes for halfword accesses · 7629a9f6
      由 Will Deacon 提交于 
      Using the 'o' memory constraint in inline assembly can result in GCC
generating invalid immediate offsets for memory access instructions with
reduced addressing capabilities (i.e. smaller than 12-bit immediate
offsets):

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54983

As there is no constraint to specify the exact addressing mode we need,
fallback to using 'Q' exclusively for halfword I/O accesses. This may
emit an additional add instruction (using an extra register) in order
to construct the address but it will always be accepted by GAS.
Reported-by: NBastian Hecht <hechtb@googlemail.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      7629a9f6
    • P
      ARM: 7566/1: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set · 39141ddf
      由 Paul Walmsley 提交于 
      After commit 846a1368 ("ARM: vfp: fix
saving d16-d31 vfp registers on v6+ kernels"), the OMAP 2430SDP board
started crashing during boot with omap2plus_defconfig:

[    3.875122] mmcblk0: mmc0:e624 SD04G 3.69 GiB
[    3.915954]  mmcblk0: p1
[    4.086639] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
[    4.093719] Modules linked in:
[    4.096954] CPU: 0    Not tainted  (3.6.0-02232-g759e00b8 #570)
[    4.103149] PC is at vfp_reload_hw+0x1c/0x44
[    4.107666] LR is at __und_usr_fault_32+0x0/0x8

It turns out that the context save/restore fix unmasked a latent bug
in commit 5aaf2544 ("ARM: 6203/1: Make
VFPv3 usable on ARMv6").  When CONFIG_VFPv3 is set, but the kernel is
booted on a pre-VFPv3 core, the code attempts to save and restore the
d16-d31 VFP registers.  These are only present on non-D16 VFPv3+, so
this results in an undefined instruction exception.  The code didn't
crash before commit 846a1368 because the save and restore code was
only touching d0-d15, present on all VFP.

Fix by implementing a request from Russell King to add a new HWCAP
flag that affirmatively indicates the presence of the d16-d31
registers:

   http://marc.info/?l=linux-arm-kernel&m=135013547905283&w=2

and some feedback from Måns to clarify the name of the HWCAP flag.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Dave Martin <dave.martin@linaro.org>
Cc: Måns Rullgård <mans.rullgard@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      39141ddf
    • F
      ARM: 7565/1: sched: stop sched_clock() during suspend · 6a4dae5e
      由 Felipe Balbi 2 提交于 
      The scheduler imposes a requirement to sched_clock()
which is to stop the clock during suspend, if we don't
do that any RT thread will be rescheduled in the future
which might cause any sort of problems.

This became an issue on OMAP when we converted omap-i2c.c
to use threaded IRQs, it turned out that depending on how
much time we spent on suspend, the I2C IRQ thread would
end up being rescheduled so far in the future that I2C
transfers would timeout and, because omap_hsmmc depends
on an I2C-connected device to detect if an MMC card is
inserted in the slot, our rootfs would just vanish.

arch/arm/kernel/sched_clock.c already had an optional
implementation (sched_clock_needs_suspend()) which would
handle scheduler's requirement properly, what this patch
does is simply to make that implementation non-optional.

Note that this has the side-effect that printk timings
won't reflect the actual time spent on suspend so other
methods to measure that will have to be used.

This has been tested with beagleboard XM (OMAP3630) and
pandaboard rev A3 (OMAP4430). Suspend to RAM is now working
after this patch.

Thanks to Kevin Hilman for helping out with debugging.
Acked-by: NKevin Hilman <khilman@ti.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      6a4dae5e
  13. 27 10月, 2012 4 次提交
  15. 26 10月, 2012 1 次提交
  17. 25 10月, 2012 14 次提交
  19. 24 10月, 2012 3 次提交
  21. 23 10月, 2012 7 次提交
    • M
      ARM: dma-mapping: support debug_dma_mapping_error · 871ae57a
      由 Ming Lei 提交于 
      Without the patch, kind of below warning will be dumped if DMA-API
debug is enabled:

[   11.069763] ------------[ cut here ]------------
[   11.074645] WARNING: at lib/dma-debug.c:948 check_unmap+0x770/0x860()
[   11.081420] ehci-omap ehci-omap.0: DMA-API: device driver failed to
check map error[device address=0x0000000
0adb78e80] [size=8 bytes] [mapped as single]
[   11.095611] Modules linked in:

Cc: Russell King <linux@arm.linux.org.uk>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      871ae57a
    • K
      ARM: OMAP3: Beagle: fix OPP customization and initcall ordering · 65bf7ca0
      由 Kevin Hilman 提交于 
      After commit 24d7b40a (ARM: OMAP2+:
PM: MPU DVFS: use generic CPU device for MPU-SS), OPPs are registered
using an existing CPU device, not the omap_device for MPU-SS.

First, fix the board file to use get_cpu_device() as required by the
above commit, otherwise custom OPPs will be added to the wrong device.

Second, the board files OPP init is called from the its init_machine
method, and the generic CPU devices are not yet created when
init_machine is run.  Therefore OPP initialization will fail.  To fix,
use a device_initcall() for the board file's OPP customization, and
make the device_initcall board-specific by using a machine_is check.
Reported-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>
      65bf7ca0
    • R
      ARM: drop experimental status for hotplug and Thumb2 · 00b7dede
      由 Russell King 提交于 
      Both these features have been around for a long time now, and haven't
had any recent issues brought up.  So lets drop their experimental
status.

In any case, hotplugis  selected by other non-experimental options
which then cause a Kconfig warning.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      00b7dede
    • T
      ARM: OMAP3: Fix 3430 legacy mux names for ssi1 signals. · 1d8643dd
      由 Tony Lindgren 提交于 
      On n900 uart1 pins are not not used for uart, instead they are
used to connect to a cell modem over ssi. Looks like we're
currently missing these signal names for 3430 for some reason,
and only have some of them listed for 3630. Obviously the signals
are there for 3430 if n900 is using them and they are documented
in some TRMs.

Note that these will eventually be replaced by device tree
based pinctrl-single.c driver. But for now these are needed
to verify the SSI pins for devices like Nokia N900.
Signed-off-by: NTony Lindgren <tony@atomide.com>
      1d8643dd
    • T
      ARM: OMAP2+: Fix location of select PINCTRL · 24942e8a
      由 Tony Lindgren 提交于 
      Commit 8f31cefe (ARM: OMAP2+: select PINCTRL in Kconfig)
added select PINCTRL, but accdentally added it to a wrong
location.

We want to select if for ARCH_OMAP2PLUS, not for
ARCH_OMAP2PLUS_TYPICAL.
Signed-off-by: NTony Lindgren <tony@atomide.com>
      24942e8a
    • P
      ARM/dts: omap3: Fix mcbsp2/3 hwmods to be able to probe the drivers for audio · eef6fcaa
      由 Peter Ujfalusi 提交于 
      Fixes the following errors:
[    2.318084] omap-mcbsp 49022000.mcbsp: invalid rx DMA channel
[    2.324432] omap-mcbsp 49024000.mcbsp: invalid rx DMA channel

Which is because we failed to link the sidetone hwmod for McBSP2/3. The
missing sidetone hwmod link will prevent omap_device_alloc() to append the
DMA resources since we - accidentally - end up having the same number of
resources provided from DT (IO/IRQ) as we have in hwmod for the McBSP ports
without the ST resources.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: NBenoit Cousson <b-cousson@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      eef6fcaa
    • K
      ARM: OMAP2: UART: fix console UART mismatched runtime PM status · 44b1d42a
      由 Kevin Hilman 提交于 
      The runtime PM framework assumes that the hardware state of devices
when initialized is disabled.  For all omap_devices, we idle/disable
device by default.  However, the console uart uses a "no idle" option
during omap_device init in order to allow earlyprintk usage to work
seamlessly during boot.

Because the hardware is left partially enabled after init (whatever
the bootloader settings were), the omap_device should later be fully
initialized (including mux) and the runtime PM framework should be
told that the device is active, and not disabled so that the hardware
state is in sync with runtime PM state.

To fix, after the device has been created/registered, call
omap_device_enable() to finialize init and use pm_runtime_set_active()
to tell the runtime PM core the device is enabled.

Tested on 2420/n810, 3530/Overo, 3530/Beagle, 3730/OveroSTORM,
3730/Beagle-xM, 4460/PandaES.
Suggested-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Sourav Poddar <sourav.poddar@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>
      44b1d42a