Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 23 10月, 2012 3 次提交
    • 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
    • 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
    • P
      ARM: OMAP3: PM: apply part of the erratum i582 workaround · 856c3c5b
      由 Paul Walmsley 提交于 
      On OMAP34xx/35xx, and OMAP36xx chips with ES < 1.2, if the PER
powerdomain goes to OSWR or OFF while CORE stays at CSWR or ON, or if,
upon chip wakeup from OSWR or OFF, the CORE powerdomain goes ON before
PER, the UART3/4 FIFOs and McBSP2/3 SIDETONE memories will be
unusable.  This is erratum i582 in the OMAP36xx Silicon Errata
document.

This patch implements one of several parts of the workaround: the
addition of the wakeup dependency between the PER and WKUP
clockdomains, such that PER will wake up at the same time CORE_L3
does.

This is not a complete workaround.  For it to be complete:

1. the PER powerdomain's next power state must not be set to OSWR or
   OFF if the CORE powerdomain's next power state is set to CSWR or
   ON;

2. the UART3/4 FIFO and McBSP2/3 SIDETONE loopback tests should be run
   if the LASTPOWERSTATEENTERED bits for PER and CORE indicate that
   PER went OFF while CORE stayed on.  If loopback tests fail, then
   those devices will be unusable until PER and CORE can undergo a
   transition from ON to OSWR/OFF and back ON.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>
      856c3c5b
  3. 19 10月, 2012 3 次提交
  5. 18 10月, 2012 8 次提交
  7. 17 10月, 2012 9 次提交
  9. 16 10月, 2012 3 次提交
  11. 15 10月, 2012 3 次提交
    • R
      ARM: fix oops on initial entry to userspace with Thumb2 kernels · 68687c84
      由 Russell King 提交于 
      Daniel Mack reports an oops at boot with the latest kernels:

  Internal error: Oops - undefined instruction: 0 [#1] SMP THUMB2
  Modules linked in:
  CPU: 0    Not tainted  (3.6.0-11057-g584df1d #145)
  PC is at cpsw_probe+0x45a/0x9ac
  LR is at trace_hardirqs_on_caller+0x8f/0xfc
  pc : [<c03493de>]    lr : [<c005e81f>]    psr: 60000113
  sp : cf055fb0  ip : 00000000  fp : 00000000
  r10: 00000000  r9 : 00000000  r8 : 00000000
  r7 : 00000000  r6 : 00000000  r5 : c0344555  r4 : 00000000
  r3 : cf057a40  r2 : 00000000  r1 : 00000001  r0 : 00000000
  Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM Segment user
  Control: 50c5387d  Table: 8f3f4019  DAC: 00000015
  Process init (pid: 1, stack limit = 0xcf054240)
  Stack: (0xcf055fb0 to 0xcf056000)
  5fa0:                                     00000001 00000000 00000000 00000000
  5fc0: cf055fb0 c000d1a8 00000000 00000000 00000000 00000000 00000000 00000000
  5fe0: 00000000 be9b3f10 00000000 b6f6add0 00000010 00000000 aaaabfaf a8babbaa

The analysis of this is as follows.  In init/main.c, we issue:

	kernel_thread(kernel_init, NULL, CLONE_FS | CLONE_SIGHAND);

This creates a new thread, which falls through to the ret_from_fork
assembly, with r4 set NULL and r5 set to kernel_init.  You can see
this in your oops dump register set - r5 is 0xc0344555, which is the
address of kernel_init plus 1 which marks the function as Thumb code.

Now, let's look at this code a little closer - this is what the
disassembly looks like:

  c000d180 <ret_from_fork>:
  c000d180:       f03a fe08       bl      c0047d94 <schedule_tail>
  c000d184:       2d00            cmp     r5, #0
  c000d186:       bf1e            ittt    ne
  c000d188:       4620            movne   r0, r4
  c000d18a:       46fe            movne   lr, pc <-- XXXXXXX
  c000d18c:       46af            movne   pc, r5
  c000d18e:       46e9            mov     r9, sp
  c000d190:       ea4f 3959       mov.w   r9, r9, lsr #13
  c000d194:       ea4f 3949       mov.w   r9, r9, lsl #13
  c000d198:       e7c8            b.n     c000d12c <ret_to_user>
  c000d19a:       bf00            nop
  c000d19c:       f3af 8000       nop.w

This code was introduced in 9fff2fa0 (arm: switch to saner
kernel_execve() semantics).  I have marked one instruction, and it's
the significant one - I'll come back to that later.

Eventually, having had a successful call to kernel_execve(), kernel_init()
returns zero.

In returning, it uses the value in 'lr' which was set by the instruction
I marked above.  Unfortunately, this causes lr to contain 0xc000d18e -
an even address.  This switches the ISA to ARM on return but with a non
word aligned PC value.

So, what do we end up executing?  Well, not the instructions above - yes
the opcodes, but they don't mean the same thing in ARM mode.  In ARM mode,
it looks like this instead:

  c000d18c:       46e946af        strbtmi r4, [r9], pc, lsr #13
  c000d190:       3959ea4f        ldmdbcc r9, {r0, r1, r2, r3, r6, r9, fp, sp, lr, pc}^
  c000d194:       3949ea4f        stmdbcc r9, {r0, r1, r2, r3, r6, r9, fp, sp, lr, pc}^
  c000d198:       bf00e7c8        svclt   0x0000e7c8
  c000d19c:       8000f3af        andhi   pc, r0, pc, lsr #7
  c000d1a0:       e88db092        stm     sp, {r1, r4, r7, ip, sp, pc}
  c000d1a4:       46e81fff                        ; <UNDEFINED> instruction: 0x46e81fff
  c000d1a8:       8a00f3ef        bhi     0xc004a16c
  c000d1ac:       0a0cf08a        beq     0xc03493dc

I have included more above, because it's relevant.  The PSR flags which
we can see in the oops dump are nZCv, so Z and C are set.

All the above ARM instructions are not executed, except for two.
c000d1a0, which has no writeback, and writes below the current stack
pointer (and that data is lost when we take the next exception.) The
other instruction which is executed is c000d1ac, which takes us to...
0xc03493dc.  However, remember that bit 1 of the PC got set.  So that
makes the PC value 0xc03493de.

And that value is the value we find in the oops dump for PC.  What is
the instruction here when interpreted in ARM mode?

       0:       f71e150c                ; <UNDEFINED> instruction: 0xf71e150c

and there we have our undefined instruction (remember that the 'never'
condition code, 0xf, has been deprecated and is now always executed as
it is now being used for additional instructions.)

This path also nicely explains the state of the stack we see in the oops
dump too.

The above is a consistent and sane story for how we got to the oops
dump, which all stems from the instruction at 0xc000d18a being wrong.
Reported-by: NDaniel Mack <zonque@gmail.com>
Tested-by: NDaniel Mack <zonque@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      68687c84
    • A
      pinctrl: sirf: remove sirfsoc_gpio_set_pull function · 7bec2074
      由 Arnd Bergmann 提交于 
      The prima2 platform advertises needing no mach/gpio.h header file,
but its pinctrl driver now has a sirfsoc_gpio_set_pull function
that uses constants defined in arch/arm/mach-prima2/include/mach/gpio.h,
which fails to build.

Fortunately, the sirfsoc_gpio_set_pull is not used anywhere in the
kernel, so we can safely remove it. Any out of tree drivers using
it will have to be converted to use proper pinctrl functions to
do the same.

Without this patch, building prima2_defconfig results in:

drivers/pinctrl/pinctrl-sirf.c: In function 'sirfsoc_gpio_set_pull':
drivers/pinctrl/pinctrl-sirf.c:1331:7: error: 'SIRFSOC_GPIO_PULL_NONE' undeclared (first use in this function)
drivers/pinctrl/pinctrl-sirf.c:1331:7: note: each undeclared identifier is reported only once for each function it appears in
drivers/pinctrl/pinctrl-sirf.c:1334:7: error: 'SIRFSOC_GPIO_PULL_UP' undeclared (first use in this function)
drivers/pinctrl/pinctrl-sirf.c:1338:7: error: 'SIRFSOC_GPIO_PULL_DOWN' undeclared (first use in this function)
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NBarry Song <Baohua.Song@csr.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      7bec2074
    • K
      ARM: shmobile: armadillo800eva: __io abuse cleanup · bc8b2428
      由 Kuninori Morimoto 提交于 
      a2a47ca3
(ARM: __io abuse cleanup) cleanuped __io() -> IOMEM(),
but armadillo800eva was a outside of a target,
since "merge window" timing issue.
This patch cleanup it.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NSimon Horman <horms@verge.net.au>
      bc8b2428
  13. 14 10月, 2012 2 次提交
    • R
      ARM: config: make sure that platforms are ordered by option string · 93e22567
      由 Russell King 提交于 
      The large platform selection choice should be sorted by option string
so it's easy to find the platform you're looking for.  Fix the few
options which are out of this order.
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      93e22567
    • R
      ARM: config: sort select statements alphanumerically · b1b3f49c
      由 Russell King 提交于 
      As suggested by Andrew Morton:

  This is a pet peeve of mine.  Any time there's a long list of items
  (header file inclusions, kconfig entries, array initalisers, etc) and
  someone wants to add a new item, they *always* go and stick it at the
  end of the list.

  Guys, don't do this.  Either put the new item into a randomly-chosen
  position or, probably better, alphanumerically sort the list.

lets sort all our select statements alphanumerically.  This commit was
created by the following perl:

while (<>) {
	while (/\\\s*$/) {
		$_ .= <>;
	}
	undef %selects if /^\s*config\s+/;
	if (/^\s+select\s+(\w+).*/) {
		if (defined($selects{$1})) {
			if ($selects{$1} eq $_) {
				print STDERR "Warning: removing duplicated $1 entry\n";
			} else {
				print STDERR "Error: $1 differently selected\n".
					"\tOld: $selects{$1}\n".
					"\tNew: $_\n";
				exit 1;
			}
		}
		$selects{$1} = $_;
		next;
	}
	if (%selects and (/^\s*$/ or /^\s+help/ or /^\s+---help---/ or
			  /^endif/ or /^endchoice/)) {
		foreach $k (sort (keys %selects)) {
			print "$selects{$k}";
		}
		undef %selects;
	}
	print;
}
if (%selects) {
	foreach $k (sort (keys %selects)) {
		print "$selects{$k}";
	}
}

It found two duplicates:

Warning: removing duplicated S5P_SETUP_MIPIPHY entry
Warning: removing duplicated HARDIRQS_SW_RESEND entry

and they are identical duplicates, hence the shrinkage in the diffstat
of two lines.

We have four testers reporting success of this change (Tony, Stephen,
Linus and Sekhar.)
Acked-by: NJason Cooper <jason@lakedaemon.net>
Acked-by: NTony Lindgren <tony@atomide.com>
Acked-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      b1b3f49c
  15. 13 10月, 2012 1 次提交
  17. 12 10月, 2012 1 次提交
  19. 10 10月, 2012 2 次提交
    • J
      pinctrl/nomadik: support other alternate-C functions · c22df08c
      由 Jean-Nicolas Graux 提交于 
      Upgrade nomadik pinctrl driver to enable selection of other
alternate-C[1-4] functions on some specific ux500 SoC pins.
Handling of those functions is done thanks to PRCM GPIOCR
registers. This was previously managed in PRCMU driver and
it was not really convenient. Idea is to provide a common
way to control all alternate functions.

Note that this improvement does not support the old-fashioned way
used to control nomadik pins, namely the "nmk_config_pin()" function
and its derivatives.
Signed-off-by: NJean-Nicolas Graux <jean-nicolas.graux@stericsson.com>
Reviewed-by: NPhilippe Langlais <philippe.langlais@stericsson.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      c22df08c
    • A
      ARM: pxa: armcore: fix PCI PIO warnings · bfbad32a
      由 Arnd Bergmann 提交于 
      The it8152 PCI host used on the pxa/cm_x2xx machines
uses the old-style I/O window registration. This should
eventually get converted to pci_ioremap_io() but for
now, let's cast the IT8152_IO_BASE constant to an integer
type to get rid of the warnings.

Without this patch, building cm_x2xx_defconfig results in:

arch/arm/common/it8152.c: In function 'it8152_pci_setup':
arch/arm/common/it8152.c:287:18: warning: assignment makes integer from pointer without a cast [enabled by default]
arch/arm/common/it8152.c:288:16: warning: assignment makes integer from pointer without a cast [enabled by default]
arch/arm/common/it8152.c:291:17: warning: assignment makes integer from pointer without a cast [enabled by default]
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NIgor Grinberg <grinberg@compulab.co.il>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Krzysztof Halasa <khc@pm.waw.pl>
Cc: Mike Rapoport <mike@compulab.co.il>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Eric Miao <eric.y.miao@gmail.com>
      bfbad32a
  21. 09 10月, 2012 5 次提交
    • A
      ARM: integrator: use __iomem pointers for MMIO, part 2 · 21c8715f
      由 Arnd Bergmann 提交于 
      Due to some interesting merges in the integrator code, not
all users of mmio pointers were converted before, this
fixes all warnings that got introduced as a consequence.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      21c8715f
    • A
      ARM: assabet: fix bogus warning in get_assabet_scr (again) · c6e9fbbf
      由 Arnd Bergmann 提交于 
      Russell fixed this bogus warning before in 2f3eca8b "Shut up gcc
warning in assabet.c", but apparently gcc has become smarter (or dumber)
since 2005, and the same warning came up again.

This uses the uninitialized_var() macro to convince gcc that the
variable is actually being initialized. 100 times in fact.

Without this patch, building assabet_defconfig results in:

arch/arm/mach-sa1100/assabet.c: In function 'fixup_assabet':
arch/arm/mach-sa1100/assabet.c:397:6: warning: 'scr' may be used uninitialized in this function [-Wuninitialized]
arch/arm/mach-sa1100/assabet.c:389:16: note: 'scr' was declared here
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      c6e9fbbf
    • A
      ARM: shmobile: mark shmobile_init_late as __init · b3796d92
      由 Arnd Bergmann 提交于 
      Patch 35f2b0bd "ARM: shmobile: Move definition of shmobile_init_late()
to header" moved the definition of the shmobile_init_late function, but
dropped the __init annotation, which is now causing warnings because
the function calls shmobile_suspend_init, which is also marked init.

Without this patch, building kota2_defconfig results in:

WARNING: vmlinux.o(.text+0xb7c8): Section mismatch in reference from the function shmobile_init_late() to the function .init.text:shmobile_suspend_init()
The function shmobile_init_late() references
the function __init shmobile_suspend_init().
This is often because shmobile_init_late lacks a __init
annotation or the annotation of shmobile_suspend_init is wrong.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Magnus Damm <damm@opensource.se>
Cc: Simon Horman <horms@verge.net.au>
      b3796d92
    • O
      ARM: integrator_cp: fix build failure · 6e3a78d9
      由 Olof Johansson 提交于 
      arch/arm/mach-integrator/integrator_cp.c:272:32: error: 'of_aliases'
undeclared (first use in this function)

Move the OF-only timer init under #ifdef CONFIG_OF, just like
integrator_ap has it.
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>
      6e3a78d9
    • R
      ARM: vfp: fix saving d16-d31 vfp registers on v6+ kernels · 846a1368
      由 Russell King 提交于 
      Michael Olbrich reported that his test program fails when built with
-O2 -mcpu=cortex-a8 -mfpu=neon, and a kernel which supports v6 and v7
CPUs:

volatile int x = 2;
volatile int64_t y = 2;

int main() {
	volatile int a = 0;
	volatile int64_t b = 0;
	while (1) {
		a = (a + x) % (1 << 30);
		b = (b + y) % (1 << 30);
		assert(a == b);
	}
}

and two instances are run.  When built for just v7 CPUs, this program
works fine.  It uses the "vadd.i64 d19, d18, d16" VFP instruction.

It appears that we do not save the high-16 double VFP registers across
context switches when the kernel is built for v6 CPUs.  Fix that.

Cc: <stable@vger.kernel.org>
Tested-By: NMichael Olbrich <m.olbrich@pengutronix.de>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      846a1368