Skip to contentSkip to conversation

ARM: shmobile: r8a73a4: Instantiate GIC from C board code in legacy builds

PATCH In review Magnus Damm 3 participants 8 messages Jan 28, 2015 – Jan 30, 2015

Subsystems (4)
lore
Share & tools
lore

Magnus Damm

author maintainer
#0 lore raw

PATCH v2 1/1 ARM: shmobile: r8a73a4: Instantiate GIC from C board code in legacy builds

From: Magnus Damm <[email protected]>

As of commit 9a1091ef0017c40a ("irqchip: gic: Support hierarchy irq domain."), the APE6EVM legacy board support is known to be broken.

The IRQ numbers of the GIC are now virtual, and no longer match the hardcoded hardware IRQ numbers in the legacy platform board code.

To fix this issue specific to non-muliplatform r8a73a4 and APE6EVM:
1) Instantiate the GIC from platform board code and also
2) Skip over the DT arch timer as well as
3) Force delay setup based on DT CPU frequency

With these 3 fixes in place interrupts on APE6EVM are now unbroken.

Partially based on legacy GIC fix by Geert Uytterhoeven, thanks to him for the initial work.

---

Suitable as a fix for v3.19-rc6.

Initially developed on top of v3.19-rc6 but also seems to apply cleanly to the renesas git repo with tag renesas-devel-20150128-v3.19-rc6.

 arch/arm/mach-shmobile/board-ape6evm.c |   20 ++++++++++++++++++++
 arch/arm/mach-shmobile/timer.c         |    7 +++++++
 2 files changed, 27 insertions(+)
arch/arm/mach-shmobile/board-ape6evm.c +20 -0
@@ -18,6 +18,8 @@
 #include <linux/gpio_keys.h>
 #include <linux/input.h>
 #include <linux/interrupt.h>
+#include <linux/irqchip.h>
+#include <linux/irqchip/arm-gic.h>
 #include <linux/kernel.h>
 #include <linux/mfd/tmio.h>
 #include <linux/mmc/host.h>
@@ -273,6 +275,22 @@ static void __init ape6evm_add_standard_
 				      sizeof(ape6evm_leds_pdata));
 }
 
+static void __init ape6evm_legacy_init_time(void)
+{
+	/* Do not invoke DT-based timers via clocksource_of_init() */
+}
+
+static void __init ape6evm_legacy_init_irq(void)
+{
+	void __iomem *gic_dist_base = ioremap_nocache(0xf1001000, 0x1000);
+	void __iomem *gic_cpu_base = ioremap_nocache(0xf1002000, 0x1000);
+
+	gic_init(0, 29, gic_dist_base, gic_cpu_base);
+
+	/* Do not invoke DT-based interrupt code via irqchip_init() */
+}
+
+
 static const char *ape6evm_boards_compat_dt[] __initdata = {
 	"renesas,ape6evm",
 	NULL,
@@ -280,7 +298,9 @@ static const char *ape6evm_boards_compat
 
 DT_MACHINE_START(APE6EVM_DT, "ape6evm")
 	.init_early	= shmobile_init_delay,
+	.init_irq       = ape6evm_legacy_init_irq,
 	.init_machine	= ape6evm_add_standard_devices,
 	.init_late	= shmobile_init_late,
 	.dt_compat	= ape6evm_boards_compat_dt,
+	.init_time	= ape6evm_legacy_init_time,
 MACHINE_END
arch/arm/mach-shmobile/timer.c +7 -0
@@ -70,6 +70,13 @@ void __init shmobile_init_delay(void)
 	if (!max_freq)
 		return;
 
+#ifdef CONFIG_ARCH_SHMOBILE_LEGACY
+	/* Non-multiplatform r8a73a4 SoC cannot use arch timer due
+	 * to GIC being initialized from C and arch timer via DT */
+	if (of_machine_is_compatible("renesas,r8a73a4"))
+		has_arch_timer = false;
+#endif
+
 	if (!has_arch_timer || !IS_ENABLED(CONFIG_ARM_ARCH_TIMER)) {
 		if (is_a7_a8_a9)
 			shmobile_setup_delay_hz(max_freq, 1, 3);
Acked-by on v2 1/1
#1 lore raw

Hi Magnus,

Quoted 13 lines · Magnus Damm

From: Magnus Damm <[email protected]>

As of commit 9a1091ef0017c40a ("irqchip: gic: Support hierarchy irq domain."), the APE6EVM legacy board support is known to be broken.

The IRQ numbers of the GIC are now virtual, and no longer match the hardcoded hardware IRQ numbers in the legacy platform board code.

To fix this issue specific to non-muliplatform r8a73a4 and APE6EVM:
1) Instantiate the GIC from platform board code and also
2) Skip over the DT arch timer as well as
3) Force delay setup based on DT CPU frequency

Quoted 6 lines

With these 3 fixes in place interrupts on APE6EVM are now unbroken.

Partially based on legacy GIC fix by Geert Uytterhoeven, thanks to him for the initial work.

Thanks!

BTW, has anything tested lager-legacy with v3.19-rcX?
We forgot about it as its removal is queued, but it's probably affected, too (.init_irq is not set, and board-lager.c uses irq numbers in platform devices).

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

author maintainer
#2 lore raw
In reply to Magnus Damm

Hi Geert,

Quoted 18 lines · Geert Uytterhoeven

Hi Magnus,

Quoted 15 lines · Magnus Damm

From: Magnus Damm <[email protected]>

As of commit 9a1091ef0017c40a ("irqchip: gic: Support hierarchy irq domain."), the APE6EVM legacy board support is known to be broken.

The IRQ numbers of the GIC are now virtual, and no longer match the hardcoded hardware IRQ numbers in the legacy platform board code.

To fix this issue specific to non-muliplatform r8a73a4 and APE6EVM:
1) Instantiate the GIC from platform board code and also
2) Skip over the DT arch timer as well as
3) Force delay setup based on DT CPU frequency

With these 3 fixes in place interrupts on APE6EVM are now unbroken.

Quoted 8 lines
Quoted 4 lines

Partially based on legacy GIC fix by Geert Uytterhoeven, thanks to him for the initial work.

Thanks!

Thank you!

Quoted 3 lines

BTW, has anything tested lager-legacy with v3.19-rcX?
We forgot about it as its removal is queued, but it's probably affected, too (.init_irq is not set, and board-lager.c uses irq numbers in platform devices).

Good point. I'm afraid I have not tested that one. I thought they were gone since long!

To be honest, it seems kind of low priority since we should have working multiplatform support for that board anyway. Compared to r8a73a4 and APE6EVM where no multiplatform is available Lager and Koelsch must be in much better state.

Cheers,

/ magnus

#3 lore raw
In reply to Magnus Damm
Quoted 37 lines · Magnus Damm

Hi Geert,

Quoted 18 lines · Geert Uytterhoeven

Hi Magnus,

Quoted 15 lines · Magnus Damm

From: Magnus Damm <[email protected]>

As of commit 9a1091ef0017c40a ("irqchip: gic: Support hierarchy irq domain."), the APE6EVM legacy board support is known to be broken.

The IRQ numbers of the GIC are now virtual, and no longer match the hardcoded hardware IRQ numbers in the legacy platform board code.

To fix this issue specific to non-muliplatform r8a73a4 and APE6EVM:
1) Instantiate the GIC from platform board code and also
2) Skip over the DT arch timer as well as
3) Force delay setup based on DT CPU frequency

With these 3 fixes in place interrupts on APE6EVM are now unbroken.

Quoted 8 lines
Quoted 4 lines

Partially based on legacy GIC fix by Geert Uytterhoeven, thanks to him for the initial work.

Thanks!

Thank you!

Quoted 3 lines

BTW, has anything tested lager-legacy with v3.19-rcX?
We forgot about it as its removal is queued, but it's probably affected, too (.init_irq is not set, and board-lager.c uses irq numbers in platform devices).

Quoted 7 lines

Good point. I'm afraid I have not tested that one. I thought they were gone since long!

To be honest, it seems kind of low priority since we should have working multiplatform support for that board anyway. Compared to r8a73a4 and APE6EVM where no multiplatform is available Lager and Koelsch must be in much better state.

FWIW I have tested lager with its defconfig on v3.19-rc6 and it seems broken.

I tend to agree with your analysis about the priority. But I also tend to think that if its trivial to fix then it would be worth doing so.

#4 lore raw
In reply to Magnus Damm
Quoted 18 lines · Geert Uytterhoeven

Hi Magnus,

Quoted 15 lines · Magnus Damm

From: Magnus Damm <[email protected]>

As of commit 9a1091ef0017c40a ("irqchip: gic: Support hierarchy irq domain."), the APE6EVM legacy board support is known to be broken.

The IRQ numbers of the GIC are now virtual, and no longer match the hardcoded hardware IRQ numbers in the legacy platform board code.

To fix this issue specific to non-muliplatform r8a73a4 and APE6EVM:
1) Instantiate the GIC from platform board code and also
2) Skip over the DT arch timer as well as
3) Force delay setup based on DT CPU frequency

With these 3 fixes in place interrupts on APE6EVM are now unbroken.

Quoted 8 lines
Quoted 4 lines

Partially based on legacy GIC fix by Geert Uytterhoeven, thanks to him for the initial work.

Thanks!

Thanks, I have queued this up as a fix for v3.19.

Quoted 15 lines

BTW, has anything tested lager-legacy with v3.19-rcX?
We forgot about it as its removal is queued, but it's probably affected, too (.init_irq is not set, and board-lager.c uses irq numbers in platform devices).

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

#5 lore raw
In reply to Magnus Damm
Quoted 22 lines · Simon Horman
Quoted 21 lines · Geert Uytterhoeven

Hi Magnus,

Quoted 18 lines · Magnus Damm

From: Magnus Damm <[email protected]>

As of commit 9a1091ef0017c40a ("irqchip: gic: Support hierarchy irq domain."), the APE6EVM legacy board support is known to be broken.

The IRQ numbers of the GIC are now virtual, and no longer match the hardcoded hardware IRQ numbers in the legacy platform board code.

To fix this issue specific to non-muliplatform r8a73a4 and APE6EVM:
1) Instantiate the GIC from platform board code and also
2) Skip over the DT arch timer as well as
3) Force delay setup based on DT CPU frequency

With these 3 fixes in place interrupts on APE6EVM are now unbroken.

Partially based on legacy GIC fix by Geert Uytterhoeven, thanks to him for the initial work.

Quoted 7 lines
Quoted 5 lines
Quoted 1 line

Thanks!

Thanks, I have queued this up as a fix for v3.19.

Actually, perhaps I spoke a little soon there.

Although things seem a bit better booting ape6evm_defconfig still doesn't make it to userspace.

The bootlog is for renesas-next-20150126-v3.19-rc1 with your patch applied. A similar result seems to occur using v3.19-rc6 with your patch applied.

Starting kernel ...

Booting Linux on physical CPU 0x0
Initializing cgroup subsys cpu
Linux version 3.19.0-rc1 ([email protected]) (gcc version 4.6.3 (GCC) ) #627 SMP Thu Jan 29 09:40:01 JST 2015
CPU: ARMv7 Processor [412fc0f3] revision 3 (ARMv7), crc5307d
CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
Machine model: APE6EVM
Ignoring memory block 0x200000000 - 0x240000000
debug: ignoring loglevel setting.
Memory policy: Data cache writealloc
On node 0 totalpages: 262144
free_area_init_node: node 0, pgdat c0521800, node_mem_map eeffa000
Normal zone: 1520 pages used for memmap
Normal zone: 0 pages reserved
Normal zone: 194560 pages, LIFO batch:31
HighMem zone: 67584 pages, LIFO batch:15
PERCPU: Embedded 8 pages/cpu @eefe5000 s11520 r0 d21248 u32768
pcpu-alloc: s11520 r0 d21248 u32768 alloc=8*4096
pcpu-alloc: [0] 0
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260624
Kernel command line: console=ttySC0,115200 ignore_loglevel root=/dev/nfs ip=dhcp rw
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1034044K/1048576K available (3773K kernel code, 220K rwdata, 980K rodata, 256K init, 188K bss, 14532K reserved, 0K cma-reserved, 270336K highmem) Virtual kernel memory layout:

    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
    vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
    lowmem  : 0xc0000000 - 0xef800000   ( 760 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
      .text : 0xc0008000 - 0xc04ad59c   (4758 kB)
      .init : 0xc04ae000 - 0xc04ee000   ( 256 kB)
      .data : 0xc04ee000 - 0xc0525358   ( 221 kB)
       .bss : 0xc0525358 - 0xc055457c   ( 189 kB)

Hierarchical RCU implementation.
RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1.
RCU: Adjusting geometry for rcu_fanout_leaf, nr_cpu_ids=1
NR_IRQS:16 nr_irqs:16 16
sched_clock: 32 bits at 128 Hz, resolution 7812500ns, wraps every 16777216000000000ns
Console: colour dummy device 80x30
Calibrating delay loop (skipped) preset value.. 1500.40 BogoMIPS (lpjX59375)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
CPU: Testing write buffer coherency: ok
CPU0: update cpu_capacity 1024
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0x40393df8 - 0x40393e50
Brought up 1 CPUs
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
VFP support v0.3: implementor 41 architecture 4 part 30 variant f rev 0
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
sh-pfc pfc-r8a73a4: r8a73a4_pfc handling gpio 0 -> 329
sh-pfc pfc-r8a73a4: r8a73a4_pfc support registered
renesas_irqc renesas_irqc.0: driving 32 irqs
renesas_irqc renesas_irqc.1: driving 26 irqs
hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
hw-breakpoint: maximum watchpoint size is 8 bytes.
sh_cmt sh-cmt-48-gen2.1: ch0: used for clock events
sh_cmt sh-cmt-48-gen2.1: ch0: used for periodic clock events
sh_cmt sh-cmt-48-gen2.1: ch1: used as clock source
Switched to clocksource sh-cmt-48-gen2.1
sh_cmt sh-cmt-48-gen2.1: ch0: used for oneshot clock events
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
futex hash table entries: 256 (order: 2, 16384 bytes)
NFS: Registering the id_resolver key type
Key type id_resolver registered
Key type id_legacy registered
nfs4filelayout_init: NFSv4 File Layout Driver Registering...
bounce: pool size: 64 pages
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
SuperH (H)SCI(F) driver initialized
sh-sci sh-sci.0: ttySC0 at MMIO 0xe6c40000 (irq = 176, base_baud = 0) is a scifa
console [ttySC0] enabled
sh-sci sh-sci.1: ttySC1 at MMIO 0xe6c50000 (irq = 177, base_baud = 0) is a scifa
sh-sci sh-sci.2: ttySC2 at MMIO 0xe6c20000 (irq = 180, base_baud = 0) is a scifb
sh-sci sh-sci.3: ttySC3 at MMIO 0xe6c30000 (irq = 181, base_baud = 0) is a scifb
sh-sci sh-sci.4: ttySC4 at MMIO 0xe6ce0000 (irq = 182, base_baud = 0) is a scifb
sh-sci sh-sci.5: ttySC5 at MMIO 0xe6cf0000 (irq = 183, base_baud = 0) is a scifb
libphy: smsc911x-mdio: probed
smsc911x smsc911x eth0: attached PHY driver [SMSC LAN8700] (mii_bus:phy_addr=smsc911x-fffffff:01, irq=-1) smsc911x smsc911x eth0: MAC Address: 00:08:f7:00:02:4b
rcar_thermal rcar_thermal: 3 sensor probed
Driver 'mmcblk' needs updating - please use bus_type methods
sh_mobile_sdhi sh_mobile_sdhi.0: No vqmmc regulator found

#6 lore raw
In reply to Magnus Damm
Quoted 31 lines · Simon Horman
Quoted 22 lines · Simon Horman
Quoted 21 lines · Geert Uytterhoeven

Hi Magnus,

Quoted 18 lines · Magnus Damm

From: Magnus Damm <[email protected]>

As of commit 9a1091ef0017c40a ("irqchip: gic: Support hierarchy irq domain."), the APE6EVM legacy board support is known to be broken.

The IRQ numbers of the GIC are now virtual, and no longer match the hardcoded hardware IRQ numbers in the legacy platform board code.

To fix this issue specific to non-muliplatform r8a73a4 and APE6EVM:
1) Instantiate the GIC from platform board code and also
2) Skip over the DT arch timer as well as
3) Force delay setup based on DT CPU frequency

With these 3 fixes in place interrupts on APE6EVM are now unbroken.

Partially based on legacy GIC fix by Geert Uytterhoeven, thanks to him for the initial work.

Quoted 7 lines
Quoted 5 lines
Quoted 1 line

Thanks!

Thanks, I have queued this up as a fix for v3.19.

Quoted 7 lines

Actually, perhaps I spoke a little soon there.

Although things seem a bit better booting ape6evm_defconfig still doesn't make it to userspace.

The bootlog is for renesas-next-20150126-v3.19-rc1 with your patch applied. A similar result seems to occur using v3.19-rc6 with your patch applied.

As discussed with Magnus on IRC this seems to be a separate issue:
which I am yet to have any luck bisecting.

So regardless of this issue I will queue this patch up as it seems to be a valid fix for v3.19.

Quoted 109 lines

Starting kernel ...

Booting Linux on physical CPU 0x0
Initializing cgroup subsys cpu
Linux version 3.19.0-rc1 ([email protected]) (gcc version 4.6.3 (GCC) ) #627 SMP Thu Jan 29 09:40:01 JST 2015
CPU: ARMv7 Processor [412fc0f3] revision 3 (ARMv7), crc5307d
CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
Machine model: APE6EVM
Ignoring memory block 0x200000000 - 0x240000000
debug: ignoring loglevel setting.
Memory policy: Data cache writealloc
On node 0 totalpages: 262144
free_area_init_node: node 0, pgdat c0521800, node_mem_map eeffa000
Normal zone: 1520 pages used for memmap
Normal zone: 0 pages reserved
Normal zone: 194560 pages, LIFO batch:31
HighMem zone: 67584 pages, LIFO batch:15
PERCPU: Embedded 8 pages/cpu @eefe5000 s11520 r0 d21248 u32768
pcpu-alloc: s11520 r0 d21248 u32768 alloc=8*4096
pcpu-alloc: [0] 0
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260624
Kernel command line: console=ttySC0,115200 ignore_loglevel root=/dev/nfs ip=dhcp rw
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1034044K/1048576K available (3773K kernel code, 220K rwdata, 980K rodata, 256K init, 188K bss, 14532K reserved, 0K cma-reserved, 270336K highmem) Virtual kernel memory layout:

    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
    vmalloc : 0xf0000000 - 0xff000000   ( 240 MB)
    lowmem  : 0xc0000000 - 0xef800000   ( 760 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
      .text : 0xc0008000 - 0xc04ad59c   (4758 kB)
      .init : 0xc04ae000 - 0xc04ee000   ( 256 kB)
      .data : 0xc04ee000 - 0xc0525358   ( 221 kB)
       .bss : 0xc0525358 - 0xc055457c   ( 189 kB)

Hierarchical RCU implementation.
RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1.
RCU: Adjusting geometry for rcu_fanout_leaf, nr_cpu_ids=1
NR_IRQS:16 nr_irqs:16 16
sched_clock: 32 bits at 128 Hz, resolution 7812500ns, wraps every 16777216000000000ns
Console: colour dummy device 80x30
Calibrating delay loop (skipped) preset value.. 1500.40 BogoMIPS (lpjX59375)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
CPU: Testing write buffer coherency: ok
CPU0: update cpu_capacity 1024
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0x40393df8 - 0x40393e50
Brought up 1 CPUs
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
VFP support v0.3: implementor 41 architecture 4 part 30 variant f rev 0
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
sh-pfc pfc-r8a73a4: r8a73a4_pfc handling gpio 0 -> 329
sh-pfc pfc-r8a73a4: r8a73a4_pfc support registered
renesas_irqc renesas_irqc.0: driving 32 irqs
renesas_irqc renesas_irqc.1: driving 26 irqs
hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers.
hw-breakpoint: maximum watchpoint size is 8 bytes.
sh_cmt sh-cmt-48-gen2.1: ch0: used for clock events
sh_cmt sh-cmt-48-gen2.1: ch0: used for periodic clock events
sh_cmt sh-cmt-48-gen2.1: ch1: used as clock source
Switched to clocksource sh-cmt-48-gen2.1
sh_cmt sh-cmt-48-gen2.1: ch0: used for oneshot clock events
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
futex hash table entries: 256 (order: 2, 16384 bytes)
NFS: Registering the id_resolver key type
Key type id_resolver registered
Key type id_legacy registered
nfs4filelayout_init: NFSv4 File Layout Driver Registering...
bounce: pool size: 64 pages
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
SuperH (H)SCI(F) driver initialized
sh-sci sh-sci.0: ttySC0 at MMIO 0xe6c40000 (irq = 176, base_baud = 0) is a scifa
console [ttySC0] enabled
sh-sci sh-sci.1: ttySC1 at MMIO 0xe6c50000 (irq = 177, base_baud = 0) is a scifa
sh-sci sh-sci.2: ttySC2 at MMIO 0xe6c20000 (irq = 180, base_baud = 0) is a scifb
sh-sci sh-sci.3: ttySC3 at MMIO 0xe6c30000 (irq = 181, base_baud = 0) is a scifb
sh-sci sh-sci.4: ttySC4 at MMIO 0xe6ce0000 (irq = 182, base_baud = 0) is a scifb
sh-sci sh-sci.5: ttySC5 at MMIO 0xe6cf0000 (irq = 183, base_baud = 0) is a scifb
libphy: smsc911x-mdio: probed
smsc911x smsc911x eth0: attached PHY driver [SMSC LAN8700] (mii_bus:phy_addr=smsc911x-fffffff:01, irq=-1) smsc911x smsc911x eth0: MAC Address: 00:08:f7:00:02:4b
rcar_thermal rcar_thermal: 3 sensor probed
Driver 'mmcblk' needs updating - please use bus_type methods
sh_mobile_sdhi sh_mobile_sdhi.0: No vqmmc regulator found
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#7 lore raw
In reply to Magnus Damm
Quoted 37 lines · Simon Horman
Quoted 36 lines · Simon Horman
Quoted 22 lines · Simon Horman
Quoted 21 lines · Geert Uytterhoeven

Hi Magnus,

Quoted 18 lines · Magnus Damm

From: Magnus Damm <[email protected]>

As of commit 9a1091ef0017c40a ("irqchip: gic: Support hierarchy irq domain."), the APE6EVM legacy board support is known to be broken.

The IRQ numbers of the GIC are now virtual, and no longer match the hardcoded hardware IRQ numbers in the legacy platform board code.

To fix this issue specific to non-muliplatform r8a73a4 and APE6EVM:
1) Instantiate the GIC from platform board code and also
2) Skip over the DT arch timer as well as
3) Force delay setup based on DT CPU frequency

With these 3 fixes in place interrupts on APE6EVM are now unbroken.

Partially based on legacy GIC fix by Geert Uytterhoeven, thanks to him for the initial work.

Quoted 7 lines
Quoted 5 lines
Quoted 1 line

Thanks!

Thanks, I have queued this up as a fix for v3.19.

Actually, perhaps I spoke a little soon there.

Although things seem a bit better booting ape6evm_defconfig still doesn't make it to userspace.

Quoted 8 lines
Quoted 2 lines

The bootlog is for renesas-next-20150126-v3.19-rc1 with your patch applied. A similar result seems to occur using v3.19-rc6 with your patch applied.

As discussed with Magnus on IRC this seems to be a separate issue:
which I am yet to have any luck bisecting.

So regardless of this issue I will queue this patch up as it seems to be a valid fix for v3.19.

To clarify:

With this patch queued up the ape6evm now boots to a prompt using the ape6evm_defconfig with the following modifications:

* Disabling CONFIG_BLOCK
* Disabling CONFIG_NET
* Enabling initrd (as NFS user-space is no longer possible due to the above)

When booting such a configuration a long delay occurs after initialising the SDHI devices. This delay can be avoided by:

* Disabling CONFIG_REGULATOR

With Magnus's patch things are better but we still have a partial regression.

Given that we are working towards removing support for booting the ape6evm using legacy C and that the reason that the above configuration is needed to get to user-space is not know (at least to me) it seems unlikely to me that this problem or problems will receive more attention.

The purpose of this email is to document the above.

I would like to thank Magnus for the time he has spent on this problem for this and other SoCs. And the time he spent working with my to try to get the ape6evm in better shape; an effort that appears to have been in vain.