Skip to content
  1. Nov 22, 2012
  3. Nov 16, 2012
  5. Nov 13, 2012
    • Fabio Estevam's avatar
      ARM: boot: Fix usage of kecho · 2d4d07b9
      Fabio Estevam authored 
      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: default avatarFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      2d4d07b9
  7. Nov 09, 2012
  9. Nov 08, 2012
  11. Nov 07, 2012
  13. Nov 06, 2012
  15. Nov 04, 2012
  17. Oct 31, 2012
    • Paul Walmsley's avatar
      ARM: OMAP4: hwmod data: do not enable or reset the McPDM during kernel init · bc05244e
      Paul Walmsley authored 
      

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: default avatarPaul Walmsley <paul@pwsan.com>
Cc: Péter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Acked-by: default avatarPeter Ujfalusi <peter.ujfalusi@ti.com>
      bc05244e
    • Paul Walmsley's avatar
      ARM: OMAP2+: hwmod: add flag to prevent hwmod code from touching IP block during init · 5fb3d522
      Paul Walmsley authored 
      

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: default avatarPaul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
      5fb3d522
    • Pritesh Raithatha's avatar
      ARM: dt: tegra: fix length of pad control and mux registers · 322337b8
      Pritesh Raithatha authored 
      

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: default avatarPritesh Raithatha <praithatha@nvidia.com>
Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      322337b8
  19. Oct 30, 2012
  21. Oct 29, 2012
    • Will Deacon's avatar
      ARM: 7567/1: io: avoid GCC's offsettable addressing modes for halfword accesses · 7629a9f6
      Will Deacon authored 
      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: default avatarBastian Hecht <hechtb@googlemail.com>
Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      7629a9f6
    • Paul Walmsley's avatar
      ARM: 7566/1: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set · 39141ddf
      Paul Walmsley authored 
      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-g759e00b #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: default avatarPaul 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: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      39141ddf
    • Felipe Balbi 2's avatar
      ARM: 7565/1: sched: stop sched_clock() during suspend · 6a4dae5e
      Felipe Balbi 2 authored 
      

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: default avatarKevin Hilman <khilman@ti.com>
Acked-by: default avatarLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      6a4dae5e
  23. Oct 28, 2012
    • Marko Katic's avatar
      ARM: pxa/spitz_pm: Fix hang when resuming from STR · 510fcb0d
      Marko Katic authored 
      

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: default avatarMarko Katic <dromede@gmail.com>
Signed-off-by: default avatarHaojian Zhuang <haojian.zhuang@gmail.com>
      510fcb0d
    • Paul Parsons's avatar
      ARM: pxa: hx4700: Fix backlight PWM device number · 8d6b00f5
      Paul Parsons authored 
      

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: default avatarPaul Parsons <lost.distance@yahoo.com>
Cc: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: default avatarHaojian Zhuang <haojian.zhuang@gmail.com>
      8d6b00f5
  25. Oct 27, 2012
  27. Oct 26, 2012
  29. Oct 25, 2012