Thread (1 message) 1 message, 1 author, 2015-05-06

BCM2836 (Raspberry Pi 2) port

From: Eric Anholt <hidden>
Date: 2015-05-06 18:51:33
Also in: linux-devicetree

Stephen Warren [off-list ref] writes:
On 04/21/2015 12:09 PM, Eric Anholt wrote:
quoted
This is my first submission of a Raspberry Pi 2 port.  It can be found
at https://github.com/anholt/linux/tree/bcm2836

I'm using the 2835 interrupt controller support, without adding the
checks for ARM local interrupts first.  That means no support for IPIs
(and thus no SMP), no PMU events, and no local timer (I'm using the
same 2835 peripheral one).

It supports a similar featureset to Pi 1 at this point.  Serial and SD
cards work.  Just one CPU supported.  USB (ethernet) works if you use
U-Boot, or my mailbox series
(https://github.com/anholt/linux/tree/bcm2836-mbox).
Tested-by: Stephen Warren <redacted>

I applied the patches on top of korg's linux-rpi.git for-rpi-next,
resolved the io_map conflicts, and tested without U-Boot.

I'll try to work out why it doesn't work with U-Boot. I can't
immediately see anything in /proc/device-tree that indicates the RPi
firmware is modifying the DT that's passed to the kernel to exclude any
CPU1..3 spin tables, so either the kernel isn't hitting those purely by
luck, or I'm guessing wrong re: the issue with U-Boot.
2836 SMP is now booting on my branch.  Big thanks to Andrea Merello for
doing most of the work on it.  Not-cleaned-up series is available at:

https://github.com/anholt/linux/tree/bcm2836-smp

There's a bunch of stuff in here I'm not sure about:

How do we like the way I'm inheriting 2835 stuff with the includes now?
(It's been a lot less merging work than my initial post had been, but
the /delete-node/ lines for 2386's changes are gross).

How do people feel about putting the 2386 local IRQ handling in the 2835
irqchip code?  Do we like the code sharing for GPU IRQs, or would we
rather have a separate driver?  Could we separate the 2836 local irqs
From 2835, and have it just call into 2835 for GPU IRQ handling?
Where do people think the arch timer frequency initialization should go
(commit "ARM: BCM2835: Set up the local timer frequency on 2836.")?  On
2709 it's in init_time(), but I hear we've been trying to move away from
these hooks.

Is there a sensible way to share our mapping of the local regs between
the driver and platform bits that need to access them?  (see
arch/arm/mach-bcm/bcm2836_platsmp.c for what we're doing currently)

Is there anything we would want to merge before getting a full working
implementation ready to merge?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150506/f167457b/attachment-0001.sig>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help