Hi Nikolaus, On Mon, Jun 11, 2018 at 10:52 AM H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Tony,
Am 11.06.2018 um 09:54 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [180611 07:20]:
Hi Tony,
Am 11.06.2018 um 09:07 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [180610 08:33]:
Hi Tony, I've observed this message on the Pyra with letux-4.17.0-lpae kernel:
[ 1.806477] platform 48070000.i2c: Retrying from deferred list [ 1.813802] ------------[ cut here ]------------ [ 1.818666] WARNING: CPU: 1 PID: 778 at drivers/irqchip/irq-gic.c:1016 gic_irq_domain_translate+0x78/0x100
Yes that needs to be fixed for all omap5 for the IRQ_TYPE_NONE users. We just need to set the proper EDGE/LEVEL and the direction for them in the omap5.dtsi file.
The code has a comment:
1015 /* Make it clear that broken DTs are... broken */ 1016 WARN_ON(*type == IRQ_TYPE_NONE);
This would mean that something in the core DT is broken as we import the omap5-common.dtsi.
I have researched a little:
...
Should this be #interrupt-cells = <2>?
No we just need to stop using IRQ_TYPE_NONE :)
The omap5.dtsi seems to be clean, but
fgrep -R 'interrupts = <GIC' arch/arm/boot/dts/omap5*.dts*
reports (amongst good cases)
arch/arm/boot/dts/omap5-board-common.dtsi: interrupts = <GIC_SPI 7 IRQ_TYPE_NONE>; /* IRQ_SYS_1N */ arch/arm/boot/dts/omap5-board-common.dtsi: interrupts = <GIC_SPI 119 IRQ_TYPE_NONE>; /* IRQ_SYS_2N cascaded to gic */ arch/arm/boot/dts/omap5-cm-t54.dts: interrupts = <GIC_SPI 7 IRQ_TYPE_NONE>; /* IRQ_SYS_1N */
I.e. Palmas and twl6040.
So what would be the right edges/levels? Also IRQ_TYPE_LEVEL_HIGH?
Yes I think that is correct. Might be worth checking the PMIC docs and also see the comments in the following patch in Linux next:
21135b6ec700 ("Revert "ARM: dts: am437x-sk-evm: Correct tps65218 irq type"")
Strangely it doesn't seem to make a difference if I specify IRQ_TYPE_LEVEL_HIGH, IRQ_TYPE_LEVEL_LOW or IRQ_TYPE_LEVEL_NONE in omap5-board-common.dtsi
So it is unfortunately not a low-hanging fruit to fix this issue...
@Marek: this is probably something you could start to look into as soon as you have your Pyra prototype.
I received it today. This sound like good start point ;). Thanks.
BR, Nikolaus
BR,
marek