Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 18 6月, 2006 5 次提交
  3. 10 6月, 2006 1 次提交
  5. 09 6月, 2006 4 次提交
    • L
      [PATCH] ep93xx build fix · fd0a0ac1
      由 Lennert Buytenhek 提交于 
      From: Lennert Buytenhek <buytenh@wantstofly.org>

The recent renaming of m48t86's ->readb() and ->writeb() platform driver
methods (2d7b20c1) to ->readbyte() and
->writebyte() to fix the ia64 build broke the build of the cirrus ep93xx
ARM platform.  This patch fixes it up.
Signed-off-by: NLennert Buytenhek <buytenh@wantstofly.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      fd0a0ac1
    • M
      [ARM] 3546/1: PATCH: subtle lost interrupts bug on i.MX · e2f04e18
      由 Matt Reimer 提交于 
      Patch from Matt Reimer

There is a subtle bug in the GPIO interrupt status register
handling in arch/arm/mach-imx/irq.c:imx_gpio_ack_irq(). The
documentation states that a 1 should be written to the relevant bit to
acknowledge a GPIO interrupt, but that is not what the code does.

The problem is that the |= writes back 1s for all the *other*
interrupts represented in the register, so interrupts could get lost.
For example, if interrupts are pending for GPIO B10 and B12, ISR_B
would have the value 0x00001400. Then when the interrupt code handles
GPIO B10, it eventually calls imx_gpio_ack_irq(IRQ_GPIOB(10)), which
effectively does this:

ISR_B |= 1 << 10;

with the result that (0x00001400 | 0x00000400) is written, clearing
the interrupt status bits for *both* GPIO B10 and B12.

The fix is to write 1s only for the interrupts we want to clear.

The same problem seems to be occurring in the DMA code; this patch
does not address those issues.
Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NMatt Reimer <mreimer@vpop.net>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      e2f04e18
    • R
      [ARM] 3547/1: PXA-OHCI: Allow platforms to specify a power budget · 0c27c5d5
      由 Richard Purdie 提交于 
      Patch from Richard Purdie

Add a power budget variable to the PXA OHCI platform data and add a
default value for the spitz platform(s) which prevents known failures
with certain USB devices.
Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      0c27c5d5
    • R
      [ARM] Fix Neponset IRQ handling · d782f33d
      由 Russell King 提交于 
      While testing the genirq code on ARM, a condition was found whereby
the Neponset IRQ handler was being re-entered, causing the system
to deadlock.

Under the ARM IRQ code, this would not have been a visible problem
because the "simple" IRQ handling had no re-entrancy protection.

Resolve this by acknowledging the parent interrupt after we mask it
when we are going to handle one of our "special" level-based sources
(from ethernet or USAR chip.)
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      d782f33d
  7. 06 6月, 2006 1 次提交
  9. 05 6月, 2006 1 次提交
  11. 03 6月, 2006 1 次提交
    • L
      [ARM] 3540/1: ixp23xx: deal with gap in interrupt bitmasks · ec8510f6
      由 Lennert Buytenhek 提交于 
      Patch from Lennert Buytenhek

On the ixp23xx, the microengine thread interrupt sources are numbered
56..119, but their mask/status bits are located in bit positions 64..127
in the various registers in the interrupt controller (bit positions
56..63 are unused.)

We don't deal with this, so currently, when asked to enable IRQ 64, we
will enable IRQ 56 instead.

The only interrupts >= 64 are the thread interrupt sources, and there
are no in-tree users of those yet, so this is fortunately not a big
problem, but this needs fixing anyway.
Signed-off-by: NLennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ec8510f6
  13. 01 6月, 2006 1 次提交
  15. 31 5月, 2006 1 次提交
  17. 18 5月, 2006 1 次提交
  19. 17 5月, 2006 2 次提交
    • D
      [ARM] 3529/1: s3c24xx: fix restoring control register with undefined instruction · c3fb0416
      由 Dimitry Andric 提交于 
      Patch from Dimitry Andric

In arch/arm/mach-s3c2410/sleep.S, the coprocessor registers are saved at
suspend time, and restored at resume time. However, an undefined
instruction is used when attempting to restore a non-existent "auxiliary
control register".  This leads to a crash on S3C2412, which has an ARM926
core instead of an ARM920.

At suspend time, the following fragment runs:

	mrc	p15, 0, r7, c2, c0, 0	@ translation table base address
	mrc	p15, 0, r8, c2, c0, 0	@ auxiliary control register
	mrc	p15, 0, r9, c1, c0, 0	@ control register

and at resume time, the following fragment runs:

	mcr	p15, 0, r7, c2, c0, 0		@ translation table base
	mcr	p15, 0, r8, c1, c1, 0		@ auxilliary control
	...
	mcr	p15, 0, r9, c1, c0, 0		@ turn on MMU, etc

There are several problems with these fragments:
1. The ARM920 and ARM926 cores don't have any "auxiliary control
   register", at least not according to the ARM920 and ARM926 TRM's.
2. The 2nd line of suspend erroneously saves the c2 register again.
3. This saved c2 value is restored using an undefined instruction.  For
   some reason this does not crash on ARM920, but does crash on ARM926.

The following patch fixes all these problems.
Signed-off-by: NDimitry Andric <dimitry@andric.com>
Yes, this looks sensible
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      c3fb0416
    • A
      [ARM] arch/arm/kernel/dma-isa.c: named initializers · 3170a5e8
      由 Adrian Bunk 提交于 
      This patch converts struct dma_resources to named initializers.

Besides fixing a compile error in -mm, it didn't sound like a bad idea.
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Acked-by: NAlexander Schulz <alex@shark-linux.de>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      3170a5e8
  21. 16 5月, 2006 5 次提交
  23. 10 5月, 2006 2 次提交
  25. 09 5月, 2006 2 次提交
  27. 08 5月, 2006 4 次提交
  29. 06 5月, 2006 3 次提交
  31. 05 5月, 2006 1 次提交
  33. 04 5月, 2006 1 次提交
  35. 03 5月, 2006 1 次提交
  37. 30 4月, 2006 1 次提交
  39. 26 4月, 2006 2 次提交