Stephen Warren <swarren@xxxxxxxxxxxxx> writes: > On 04/21/2015 12:09 PM, Eric Anholt wrote: >> 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 <swarren@xxxxxxxxxxxxx> > > 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?
Attachment:
signature.asc
Description: PGP signature
