Re: gpio: mvebu: switch to regmap for register access

Re: gpio: mvebu: switch to regmap for register access

[Chris Packham]

Hi Thomas,

Doing some more testing against linux-next and I've found that this 
patch causes a flood of bad interrupts on my armada-xp-98dx3236 based 
board (kernel startup output below). If I revert this patch I can boot 
as normal.

This doesn't happen on the 98dx3236 DB or another Armada-385 based board 
I have so it's probably related something specific to this board 
(probably one of the i2c gpios based on the log messages).

Any thoughts on where I should start looking?

Booting Linux on physical CPU 0x0
Linux version 4.12.0-rc4-next-20170606-at1+ (chrisp@chrisp-dl) (gcc 
version 4.9.3 (crosstool-NG crosstool-ng-1.22.0) ) #98 SMP PREEMP
T Fri Jun 9 03:18:42 UTC 2017
CPU: ARMv7 Processor [562f5842] revision 2 (ARMv7), cr=10c5387d
CPU: div instructions available: patching division code
CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
OF: fdt: Machine model: x220/52
Memory policy: Data cache writealloc
On node 0 totalpages: 131072
free_area_init_node: node 0, pgdat 8092b100, node_mem_map 9fbfa000
   Normal zone: 1024 pages used for memmap
   Normal zone: 0 pages reserved
   Normal zone: 131072 pages, LIFO batch:31
percpu: Embedded 15 pages/cpu @9fbde000 s31040 r8192 d22208 u61440
pcpu-alloc: s31040 r8192 d22208 u61440 alloc=15*4096
pcpu-alloc: [0] 0
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 130048
Kernel command line: console=ttyS0,115200 root=/dev/ram0 
releasefile=linuxbox_armv7-tb233.rel bootversion=6.2.4-devel loglevel=8 mtdo
ops.mtddev=errlog mvebu_edac.edac_op_state=0 reladdr=0x1000000,df49d3
PID hash table entries: 2048 (order: 1, 8192 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 499368K/524288K available (5120K kernel code, 174K rwdata, 1380K 
rodata, 1024K init, 122K bss, 24920K reserved, 0K cma-reserv
ed)
Virtual kernel memory layout:
     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
     vmalloc : 0xa0800000 - 0xff800000   (1520 MB)
     lowmem  : 0x80000000 - 0xa0000000   ( 512 MB)
     modules : 0x7f000000 - 0x80000000   (  16 MB)
       .text : 0x80008000 - 0x80600000   (6112 kB)
       .init : 0x80800000 - 0x80900000   (1024 kB)
       .data : 0x80900000 - 0x8092b800   ( 174 kB)
        .bss : 0x809308e8 - 0x8094f480   ( 123 kB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Preemptible hierarchical RCU implementation.
         RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=1.
         Tasks RCU enabled.
RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
L2C: DT/platform modifies aux control register: 0x1a08e700 -> 0x1a08e702
Aurora cache controller enabled, 8 ways, 512 kB
Aurora: CACHE_ID 0x00000100, AUX_CTRL 0x1a08e702
Switching to timer-based delay loop, resolution 40ns
sched_clock: 32 bits at 25MHz, resolution 40ns, wraps every 85899345900ns
clocksource: armada_370_xp_clocksource: mask: 0xffffffff max_cycles: 
0xffffffff, max_idle_ns: 76450417870 ns
Calibrating delay loop (skipped), value calculated using timer 
frequency.. 50.00 BogoMIPS (lpj=250000)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0x100000 - 0x100060
mvebu-soc-id: MVEBU SoC ID=0xF410, Rev=0x4
mvebu-pmsu: Initializing Power Management Service Unit
Hierarchical SRCU implementation.
smp: Bringing up secondary CPUs ...
smp: Brought up 1 node, 1 CPU
SMP: Total of 1 processors activated (50.00 BogoMIPS).
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 6
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, 
max_idle_ns: 19112604462750000 ns
futex hash table entries: 256 (order: 2, 16384 bytes)
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
clocksource: Switched to clocksource armada_370_xp_clocksource
NET: Registered protocol family 2
TCP established hash table entries: 4096 (order: 2, 16384 bytes)
TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
UDP hash table entries: 256 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
NET: Registered protocol family 1
PCI: CLS 0 bytes, default 64
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (junk in compressed archive); looks like 
an initrd
Freeing initrd memory: 11756K
workingset: timestamp_bits=30 max_order=17 bucket_order=0
squashfs: version 4.0 (2009/01/31) Phillip Lougher
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
io scheduler mq-deadline registered
io scheduler kyber registered
armada-xp-pinctrl f1018000.pin-ctrl: registered pinctrl driver
GPIO line 31 (bb-override) hogged as output/low
mvebu-pcie soc:pcie-controller@82000000: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x1000-0xfffff]
pci_bus 0000:00: root bus resource [mem 0xf8000000-0xffdfffff]
pci_bus 0000:00: root bus resource [bus 00-ff]
pci 0000:00:01.0: [11ab:f410] type 01 class 0x060400
PCI: bus0: Fast back to back transfers disabled
pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci 0000:01:00.0: [11ab:f410] type 00 class 0x020000
pci 0000:01:00.0: reg 0x10: [mem 0xe8000000-0xe80fffff 64bit pref]
pci 0000:01:00.0: reg 0x18: can't handle BAR above 4GB (bus address 
0xfffffffffc000000)
pci 0000:01:00.0: reg 0x18: [mem size 0x04000000 64bit pref]
pci 0000:01:00.0: reg 0x20: [mem 0xe8800000-0xe8ffffff 64bit pref]
pci 0000:01:00.0: supports D1 D2
PCI: bus1: Fast back to back transfers disabled
pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
pci 0000:00:01.0: BAR 8: assigned [mem 0xf8000000-0xfdffffff]
pci 0000:01:00.0: BAR 2: assigned [mem 0xf8000000-0xfbffffff 64bit pref]
pci 0000:01:00.0: BAR 4: assigned [mem 0xfc000000-0xfc7fffff 64bit pref]
pci 0000:01:00.0: BAR 0: assigned [mem 0xfc800000-0xfc8fffff 64bit pref]
pci 0000:00:01.0: PCI bridge to [bus 01]
pci 0000:00:01.0:   bridge window [mem 0xf8000000-0xfdffffff]
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
console [ttyS0] disabled
f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 19, base_baud = 
12500000) is a 16550A
console [ttyS0] enabled
f1012100.serial: ttyS1 at MMIO 0xf1012100 (irq = 20, base_baud = 
12500000) is a 16550A
brd: module loaded
loop: module loaded
pxa3xx-nand f10d0000.nand: This platform can't do DMA on this device
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xf1
nand: Micron MT29F1G08ABAEAWP
nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
pxa3xx-nand f10d0000.nand: ECC strength 16, ECC step size 2048
Bad block table found at page 65472, version 0x01
Bad block table found at page 65408, version 0x01
3 ofpart partitions found on MTD device pxa3xx_nand-0
Creating 3 MTD partitions on "pxa3xx_nand-0":
0x000000000000-0x000007000000 : "user"
0x000007000000-0x000007800000 : "errlog"
random: fast init done
mtdoops: ready 0, 1 (no erase)
mtdoops: Attached to MTD device 1
0x000007800000-0x000008000000 : "nand-bbt"
m25p80 spi0.0: m25p128 (16384 Kbytes)
4 ofpart partitions found on MTD device spi0.0
Creating 4 MTD partitions on "spi0.0":
0x000000000000-0x000000100000 : "u-boot"
0x000000100000-0x000000140000 : "u-boot-env"
0x000000140000-0x000000fc0000 : "unused"
0x000000fc0000-0x000001000000 : "idprom"
1 ofpart partitions found on MTD device spi0.1
Creating 1 MTD partitions on "spi0.1":
0x000000000000-0x000000020000 : "nvs"
libphy: Fixed MDIO Bus: probed
libphy: orion_mdio_bus: probed
usbcore: registered new interface driver asix
usbcore: registered new interface driver cdc_ether
usbcore: registered new interface driver smsc75xx
usbcore: registered new interface driver usb-storage
i2c /dev entries driver
irq 0, desc: 9c004700, depth: 1, count: 0, unhandled: 0
->handle_irq():  8015948c,
handle_bad_irq+0x0/0x294
->irq_data.chip(): 8090ed08,
no_irq_chip+0x0/0x88
->action():   (null)
    IRQ_NOPROBE set
  IRQ_NOREQUEST set
unexpected IRQ trap at vector 00
irq 0, desc: 9c004700, depth: 1, count: 0, unhandled: 0
->handle_irq():  8015948c,
handle_bad_irq+0x0/0x294
->irq_data.chip(): 8090ed08,
no_irq_chip+0x0/0x88
->action():   (null)
    IRQ_NOPROBE set
  IRQ_NOREQUEST set
unexpected IRQ trap at vector 00
irq 0, desc: 9c004700, depth: 1, count: 0, unhandled: 0
->handle_irq():  8015948c,
handle_bad_irq+0x0/0x294
->irq_data.chip(): 8090ed08,
no_irq_chip+0x0/0x88
->action():   (null)
    IRQ_NOPROBE set
  IRQ_NOREQUEST set
unexpected IRQ trap at vector 00
irq 0, desc: 9c004700, depth: 1, count: 0, unhandled: 0
->handle_irq():  8015948c,
handle_bad_irq+0x0/0x294
->irq_data.chip(): 8090ed08,
no_irq_chip+0x0/0x88
->action():   (null)
    IRQ_NOPROBE set
  IRQ_NOREQUEST set
unexpected IRQ trap at vector 00

Re: gpio: mvebu: switch to regmap for register access

[Chris Packham]

On 09/06/17 15:36, Chris Packham wrote:
> Hi Thomas,
> 
> Doing some more testing against linux-next and I've found that this
> patch causes a flood of bad interrupts on my armada-xp-98dx3236 based
> board (kernel startup output below). If I revert this patch I can boot
> as normal.
> 
> This doesn't happen on the 98dx3236 DB or another Armada-385 based board
> I have so it's probably related something specific to this board
> (probably one of the i2c gpios based on the log messages).
> 
> Any thoughts on where I should start looking?

Sure enough I think the problem is related to a pca9555 connected to one 
of the CPU gpios.

	gpio@27 {
		#address-cells = <2>;
		#size-cells = <0>;
		compatible = "nxp,pca9555";
		reg = <0x27>;
		gpio-controller;
		#gpio-cells = <2>;
		interrupt-parent = <&gpio0>;
		interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
	};

If I remove the interrupt properties I don't see the problem.

Re: gpio: mvebu: switch to regmap for register access

[Gregory CLEMENT]

Hi Chris,
 
 On ven., juin 09 2017, Chris Packham <Chris.Packham@alliedtelesis.co.nz> wrote:

> On 09/06/17 15:36, Chris Packham wrote:
>> Hi Thomas,
>> 
>> Doing some more testing against linux-next and I've found that this
>> patch causes a flood of bad interrupts on my armada-xp-98dx3236 based
>> board (kernel startup output below). If I revert this patch I can boot
>> as normal.
>> 
>> This doesn't happen on the 98dx3236 DB or another Armada-385 based board
>> I have so it's probably related something specific to this board
>> (probably one of the i2c gpios based on the log messages).
>> 
>> Any thoughts on where I should start looking?
>
> Sure enough I think the problem is related to a pca9555 connected to one 
> of the CPU gpios.
>
> 	gpio@27 {
> 		#address-cells = <2>;
> 		#size-cells = <0>;
> 		compatible = "nxp,pca9555";
> 		reg = <0x27>;
> 		gpio-controller;
> 		#gpio-cells = <2>;
> 		interrupt-parent = <&gpio0>;
> 		interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
> 	};
>
> If I remove the interrupt properties I don't see the problem.

I found the bug and I've just sent a fix for it.

Thanks for the report,

Gregory

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com