Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 22 11月, 2012 12 次提交
  3. 16 11月, 2012 4 次提交
  5. 13 11月, 2012 1 次提交
    • 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
  7. 09 11月, 2012 1 次提交
  9. 08 11月, 2012 2 次提交
  11. 07 11月, 2012 1 次提交
  13. 06 11月, 2012 2 次提交
  15. 04 11月, 2012 1 次提交
  17. 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
  19. 30 10月, 2012 3 次提交
  21. 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
  23. 28 10月, 2012 2 次提交
    • M
      ARM: pxa/spitz_pm: Fix hang when resuming from STR · 510fcb0d
      由 Marko Katic 提交于 
      Devices that use spitz_pm.c will fail to resume
from STR (Suspend To Ram) when the charger plug is inserted
or removed when a device is in STR mode. The culprit is
a misconfigured gpio line - GPIO18. GPIO18 should be configured as a
regular GPIO input but it gets configured as an alternate function
GPIO18_RDY. And then later in postsuspend() it gets configured as
a regular GPIO18 input line.

Fix this by removing the GPIO18_RDY configuration so that GPIO18
only gets configured as a regular gpio input.
Signed-off-by: NMarko Katic <dromede@gmail.com>
Signed-off-by: NHaojian Zhuang <haojian.zhuang@gmail.com>
      510fcb0d
    • P
      ARM: pxa: hx4700: Fix backlight PWM device number · 8d6b00f5
      由 Paul Parsons 提交于 
      Recent changes to PXA PWM support changed the PXA27X PWM device
numbering scheme.

The linux-3.5 PXA PWM driver followed the hardware numbering scheme for
the 4 PWMs, while the linux-3.6-rc1 PXA PWM driver has adopted a linear
numbering scheme:

Address		Hardware	3.5 pwm_id	3.6-rc1 pwm_id
0x40b00000	PWM0		0		0
0x40b00010	PWM2		2		1
0x40c00000	PWM1		1		2
0x40c00010	PWM3		3		3

The hx4700 backlight uses PWM1 at 0x40c00000. Consequently the pwm_id
must be changed from 1 to 2.

This patch fixes the backlight PWM device number and at the same time
moves from the legacy PWM API (pwm_id) to the new PWM API (pwm_lookup).
Signed-off-by: NPaul Parsons <lost.distance@yahoo.com>
Cc: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: NHaojian Zhuang <haojian.zhuang@gmail.com>
      8d6b00f5
  25. 27 10月, 2012 4 次提交
  27. 26 10月, 2012 1 次提交