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 [ 1.828839] Modules linked in: [ 1.832075] CPU: 1 PID: 778 Comm: kworker/1:1 Not tainted 4.17.0-letux-lpae+ #2407 [ 1.840012] Hardware name: Generic OMAP5 (Flattened Device Tree) [ 1.846319] Workqueue: events deferred_probe_work_func [ 1.851724] [<c020fd94>] (unwind_backtrace) from [<c020b690>] (show_stack+0x10/0x14) [ 1.859856] [<c020b690>] (show_stack) from [<c083c848>] (dump_stack+0x7c/0x9c) [ 1.867443] [<c083c848>] (dump_stack) from [<c022b330>] (__warn+0xd8/0x108) [ 1.874765] [<c022b330>] (__warn) from [<c022b420>] (warn_slowpath_null+0x38/0x44) [ 1.882712] [<c022b420>] (warn_slowpath_null) from [<c051ee2c>] (gic_irq_domain_translate+0x78/0x100) [ 1.892393] [<c051ee2c>] (gic_irq_domain_translate) from [<c051f19c>] (gic_irq_domain_alloc+0x28/0x6c) [ 1.902163] [<c051f19c>] (gic_irq_domain_alloc) from [<c021f9d8>] (wakeupgen_domain_alloc+0xa4/0xc0) [ 1.911756] [<c021f9d8>] (wakeupgen_domain_alloc) from [<c0277810>] (__irq_domain_alloc_irqs+0x148/0x200) [ 1.921798] [<c0277810>] (__irq_domain_alloc_irqs) from [<c0277d00>] (irq_create_fwspec_mapping+0x278/0x32c) [ 1.932106] [<c0277d00>] (irq_create_fwspec_mapping) from [<c0277dfc>] (irq_create_of_mapping+0x48/0x50) [ 1.942064] [<c0277dfc>] (irq_create_of_mapping) from [<c072c1c4>] (of_irq_get+0x5c/0x64) [ 1.950646] [<c072c1c4>] (of_irq_get) from [<c06ccf40>] (i2c_device_probe+0xb8/0x260) [ 1.958869] [<c06ccf40>] (i2c_device_probe) from [<c05cbe5c>] (driver_probe_device+0x188/0x318) [ 1.968010] [<c05cbe5c>] (driver_probe_device) from [<c05ca60c>] (bus_for_each_drv+0x84/0x94) [ 1.976966] [<c05ca60c>] (bus_for_each_drv) from [<c05cbc3c>] (__device_attach+0x88/0xfc) [ 1.985546] [<c05cbc3c>] (__device_attach) from [<c05cb1e8>] (bus_probe_device+0x28/0x80) [ 1.994137] [<c05cb1e8>] (bus_probe_device) from [<c05c99c0>] (device_add+0x3f8/0x50c) [ 2.002453] [<c05c99c0>] (device_add) from [<c06ce484>] (i2c_new_device+0x1c0/0x29c) [ 2.010585] [<c06ce484>] (i2c_new_device) from [<c06d0950>] (of_i2c_register_device+0x130/0x174) [ 2.019813] [<c06d0950>] (of_i2c_register_device) from [<c06d0c5c>] (of_i2c_register_devices+0x70/0xbc) [ 2.029674] [<c06d0c5c>] (of_i2c_register_devices) from [<c06cea18>] (i2c_register_adapter+0x27c/0x390) [ 2.039539] [<c06cea18>] (i2c_register_adapter) from [<c06d3dbc>] (omap_i2c_probe+0x578/0x670) [ 2.048576] [<c06d3dbc>] (omap_i2c_probe) from [<c05cd974>] (platform_drv_probe+0x50/0xa0) [ 2.057257] [<c05cd974>] (platform_drv_probe) from [<c05cbe5c>] (driver_probe_device+0x188/0x318) [ 2.066576] [<c05cbe5c>] (driver_probe_device) from [<c05ca60c>] (bus_for_each_drv+0x84/0x94) [ 2.075525] [<c05ca60c>] (bus_for_each_drv) from [<c05cbc3c>] (__device_attach+0x88/0xfc) [ 2.084118] [<c05cbc3c>] (__device_attach) from [<c05cb1e8>] (bus_probe_device+0x28/0x80) [ 2.092695] [<c05cb1e8>] (bus_probe_device) from [<c05cb704>] (deferred_probe_work_func+0xf8/0x130) [ 2.102192] [<c05cb704>] (deferred_probe_work_func) from [<c0242648>] (process_one_work+0x244/0x464) [ 2.111776] [<c0242648>] (process_one_work) from [<c0242890>] (process_scheduled_works+0x28/0x30) [ 2.121082] [<c0242890>] (process_scheduled_works) from [<c0242e44>] (worker_thread+0x2e8/0x3ec) [ 2.130305] [<c0242e44>] (worker_thread) from [<c0246df0>] (kthread+0x134/0x150) [ 2.138069] [<c0246df0>] (kthread) from [<c02010d8>] (ret_from_fork+0x14/0x3c) [ 2.145640] Exception stack(0xee2dffb0 to 0xee2dfff8) [ 2.150936] ffa0: 00000000 00000000 00000000 00000000 [ 2.159530] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 2.168109] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 2.175078] ---[ end trace cc54ad81996a459a ]--- [ 2.179930] WARNING on irq_domain: interrupt-controller@48211000
The first line is from enabling some DEBUG in drivers/base/dd.c The last line is from a conditional printk after drivers/irqchip/irq-gic.c:1016
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:
omap5.dtsi says:
gic: interrupt-controller@48211000 { compatible = "arm,cortex-a15-gic"; interrupt-controller; #interrupt-cells = <3>; reg = <0 0x48211000 0 0x1000>, <0 0x48212000 0 0x2000>, <0 0x48214000 0 0x2000>, <0 0x48216000 0 0x2000>; interrupt-parent = <&gic>; };
but there is no description what #interrupt-cells = <3> means:
https://elixir.bootlin.com/linux/v4.17/source/Documentation/devicetree/bindi...
Should this be #interrupt-cells = <2>?
On the other hand this comes when retrying to probe 48070000.i2c which is defined as
i2c1: i2c@48070000 { compatible = "ti,omap4-i2c"; reg = <0x48070000 0x100>; interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>; #address-cells = <1>; #size-cells = <0>; ti,hwmods = "i2c1"; };
where the interrupts property has indeed 3 cells. So the bindings docmay just be incomplete.
But I have no idea why the condition
1016 WARN_ON(*type == IRQ_TYPE_NONE)
can trigger based on DT definitions?
BTW: I have observed the strcmp(NULL) issue also on Pyra/omap5 (which also uses pwm_bl).
So this might just be another symptom of the same issue.
Another strange observation is that bus_probe_device() is twice in the call stack.
BR and thanks, Nikolaus
* 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 :)
Regards,
Tony
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?
BR and thanks, Nikolaus
* 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"")
Regards,
Tony
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.
BR, Nikolaus
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
Hi Tony, Nikolaus, On Mon, Jun 11, 2018 at 9:08 AM Tony Lindgren tony@atomide.com wrote:
- 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
I tried following patch: diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi b/arch/arm/boot/dts/omap5-board-common.dtsi index 218892b..75684c5 100644 --- a/arch/arm/boot/dts/omap5-board-common.dtsi +++ b/arch/arm/boot/dts/omap5-board-common.dtsi @@ -393,7 +393,7 @@
palmas: palmas@48 { compatible = "ti,palmas"; - interrupts = <GIC_SPI 7 IRQ_TYPE_NONE>; /* IRQ_SYS_1N */ + interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>; /* IRQ_SYS_1N */ reg = <0x48>; interrupt-controller; #interrupt-cells = <2>; @@ -425,7 +425,7 @@ rtc { compatible = "ti,palmas-rtc"; interrupt-parent = <&palmas>; - interrupts = <8 IRQ_TYPE_NONE>; + interrupts = <8 IRQ_TYPE_LEVEL_HIGH>; ti,backup-battery-chargeable; ti,backup-battery-charge-high-current; }; @@ -443,7 +443,7 @@ palmas_pmic { compatible = "ti,palmas-pmic"; interrupt-parent = <&palmas>; - interrupts = <14 IRQ_TYPE_NONE>; + interrupts = <14 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "short-irq";
ti,ldo6-vibrator; @@ -659,7 +659,7 @@ pinctrl-names = "default"; pinctrl-0 = <&twl6040_pins>;
- interrupts = <GIC_SPI 119 IRQ_TYPE_NONE>; /* IRQ_SYS_2N cascaded to gic */ + interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>; /* IRQ_SYS_2N cascaded to gic */
/* audpwron gpio defined in the board specific dts */
and it looks like board boots fine. I just see an issue with gpadc and measuring voltage like: [ 91.059460] power_supply pyra-battery: driver failed to report `voltage_now' property: -110 [ 96.078130] palmas-gpadc 48070000.i2c:palmas@48:gpadc: conversion not completed [ 96.085980] palmas-gpadc 48070000.i2c:palmas@48:gpadc: ADC start conversion failed [ 96.100513] read channel error
it's just blind test without knowing too much details (I'm new in Pyra development ;) ) I tried also IRQ_TYPE_LEVEL_LOW but in this case when set for palmas board cannot find rootfs. I'll try to do some checks why gpadc is not working though.
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 :)
Regards,
Tony _______________________________________________ http://projects.goldelico.com/p/gta04-kernel/ Letux-kernel mailing list Letux-kernel@openphoenux.org http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
BR,
marek
* Belisko Marek marek.belisko@gmail.com [180615 20:43]:
Hi Tony, Nikolaus, On Mon, Jun 11, 2018 at 9:08 AM Tony Lindgren tony@atomide.com wrote:
- 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
I tried following patch: diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi b/arch/arm/boot/dts/omap5-board-common.dtsi index 218892b..75684c5 100644 --- a/arch/arm/boot/dts/omap5-board-common.dtsi +++ b/arch/arm/boot/dts/omap5-board-common.dtsi @@ -393,7 +393,7 @@
palmas: palmas@48 { compatible = "ti,palmas";
interrupts = <GIC_SPI 7 IRQ_TYPE_NONE>; /* IRQ_SYS_1N */
interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>; /* IRQ_SYS_1N */ reg = <0x48>; interrupt-controller; #interrupt-cells = <2>;@@ -425,7 +425,7 @@ rtc { compatible = "ti,palmas-rtc"; interrupt-parent = <&palmas>;
interrupts = <8 IRQ_TYPE_NONE>;
interrupts = <8 IRQ_TYPE_LEVEL_HIGH>; ti,backup-battery-chargeable; ti,backup-battery-charge-high-current; };@@ -443,7 +443,7 @@ palmas_pmic { compatible = "ti,palmas-pmic"; interrupt-parent = <&palmas>;
interrupts = <14 IRQ_TYPE_NONE>;
interrupts = <14 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "short-irq"; ti,ldo6-vibrator;@@ -659,7 +659,7 @@ pinctrl-names = "default"; pinctrl-0 = <&twl6040_pins>;
interrupts = <GIC_SPI 119 IRQ_TYPE_NONE>; /*IRQ_SYS_2N cascaded to gic */
interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>; /*IRQ_SYS_2N cascaded to gic */
/* audpwron gpio defined in the board specific dts */and it looks like board boots fine.
OK good to hear. Can you please post a proper fix to the the linux-omap and LAKML lists?
Regards,
Tony
Hi Tony, On Mon, Jun 18, 2018 at 9:01 AM Tony Lindgren tony@atomide.com wrote:
- Belisko Marek marek.belisko@gmail.com [180615 20:43]:
Hi Tony, Nikolaus, On Mon, Jun 11, 2018 at 9:08 AM Tony Lindgren tony@atomide.com wrote:
- 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
I tried following patch: diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi b/arch/arm/boot/dts/omap5-board-common.dtsi index 218892b..75684c5 100644 --- a/arch/arm/boot/dts/omap5-board-common.dtsi +++ b/arch/arm/boot/dts/omap5-board-common.dtsi @@ -393,7 +393,7 @@
palmas: palmas@48 { compatible = "ti,palmas";
interrupts = <GIC_SPI 7 IRQ_TYPE_NONE>; /* IRQ_SYS_1N */
interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>; /* IRQ_SYS_1N */ reg = <0x48>; interrupt-controller; #interrupt-cells = <2>;@@ -425,7 +425,7 @@ rtc { compatible = "ti,palmas-rtc"; interrupt-parent = <&palmas>;
interrupts = <8 IRQ_TYPE_NONE>;
interrupts = <8 IRQ_TYPE_LEVEL_HIGH>; ti,backup-battery-chargeable; ti,backup-battery-charge-high-current; };@@ -443,7 +443,7 @@ palmas_pmic { compatible = "ti,palmas-pmic"; interrupt-parent = <&palmas>;
interrupts = <14 IRQ_TYPE_NONE>;
interrupts = <14 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "short-irq"; ti,ldo6-vibrator;@@ -659,7 +659,7 @@ pinctrl-names = "default"; pinctrl-0 = <&twl6040_pins>;
interrupts = <GIC_SPI 119 IRQ_TYPE_NONE>; /*IRQ_SYS_2N cascaded to gic */
interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>; /*IRQ_SYS_2N cascaded to gic */
/* audpwron gpio defined in the board specific dts */and it looks like board boots fine.
OK good to hear. Can you please post a proper fix to the the linux-omap and LAKML lists?
I can but after applying this patch gpadc module seems to stop working so I need to fix this first (no idea how yet ;))
Regards,
Tony
BR,
marek
* Belisko Marek marek.belisko@gmail.com [180618 07:09]:
I can but after applying this patch gpadc module seems to stop working so I need to fix this first (no idea how yet ;))
Oh OK. Maybe check if that module or it's GPIO parent also needs matching level configured in the dts file? Maybe it's connected via I2C GPIO module or via PMIC GPIO?
Regards,
Tony
Hi Tony, On Mon, Jun 18, 2018 at 9:20 AM Tony Lindgren tony@atomide.com wrote:
- Belisko Marek marek.belisko@gmail.com [180618 07:09]:
I can but after applying this patch gpadc module seems to stop working so I need to fix this first (no idea how yet ;))
Oh OK. Maybe check if that module or it's GPIO parent also needs matching level configured in the dts file? Maybe it's connected via I2C GPIO module or via PMIC GPIO?
Nope I checked gpadc driver and from platform data can get 3 iqr's (at leat they are defined in omap5-board-common.dtsi) but drievr just gran EOC irq directly from palmas. I also checked palmas probe and there is code like: /* Change interrupt line output polarity */ | 19 #include <linux/delay.h> if (pdata->irq_flags & IRQ_TYPE_LEVEL_HIGH) | 20 #include <linux/i2c.h> reg = PALMAS_POLARITY_CTRL_INT_POLARITY; | 21 #include <linux/pm.h> else | 22 #include <linux/mfd/palmas.h> reg = 0;
so when it was none reg = 0 (with IRQ_TYPE_LEVEL_LOW it was not mounting rootfs at all but works with IRQ_TYPE_LEVEL_HIGH). So I'm still puzzled how to fix this issue. Any ideas what else to check? Also one thing which puzzles me is why gpadc in dts have 3 interrupts?: gpadc: gpadc { compatible = "ti,palmas-gpadc"; interrupts = <18 0 16 0 17 0>; #io-channel-cells = <1>; ti,channel0-current-microamp = <5>; ti,channel3-current-microamp = <10>; };
Thanks.
Regards,
Tony
BR,
marek
Hi Marek,
Am 19.06.2018 um 13:17 schrieb Belisko Marek marek.belisko@gmail.com:
Hi Tony, On Mon, Jun 18, 2018 at 9:20 AM Tony Lindgren tony@atomide.com wrote:
- Belisko Marek marek.belisko@gmail.com [180618 07:09]:
I can but after applying this patch gpadc module seems to stop working so I need to fix this first (no idea how yet ;))
Oh OK. Maybe check if that module or it's GPIO parent also needs matching level configured in the dts file? Maybe it's connected via I2C GPIO module or via PMIC GPIO?
Nope I checked gpadc driver and from platform data can get 3 iqr's (at leat they are defined in omap5-board-common.dtsi) but drievr just gran EOC irq directly from palmas. I also checked palmas probe and there is code like: /* Change interrupt line output polarity */ | 19 #include <linux/delay.h> if (pdata->irq_flags & IRQ_TYPE_LEVEL_HIGH) | 20 #include <linux/i2c.h> reg = PALMAS_POLARITY_CTRL_INT_POLARITY; | 21 #include <linux/pm.h> else | 22 #include <linux/mfd/palmas.h> reg = 0;
so when it was none reg = 0 (with IRQ_TYPE_LEVEL_LOW it was not mounting rootfs at all but works with IRQ_TYPE_LEVEL_HIGH). So I'm still puzzled how to fix this issue. Any ideas what else to check? Also one thing which puzzles me is why gpadc in dts have 3 interrupts?: gpadc: gpadc { compatible = "ti,palmas-gpadc"; interrupts = <18 0 16 0 17 0>; #io-channel-cells = <1>; ti,channel0-current-microamp = <5>; ti,channel3-current-microamp = <10>; };
Thanks.
Some more ideas: * the issue we are hunting did AFAIR appear first in 4.17-rc. It might just be better checks or something has really changed. * how is the twl4030 madc set up? It is likely not extremely different.
BR, Nikolaus
-
Belisko Marek -
H. Nikolaus Schaller -
Tony Lindgren