According to Documentation/devicetree/bindings/net/fsl-fec.txt, when
interrupt-names is not passed the following interrupt order is assumed:
__Number of interrupts__ __Default__
1 "int0"
2 "int0", "pps"
3 "int0", "int1", "int2"
4 "int0", "int1", "int2", "pps"
In the current imx8mm.dtsi this translates to:
- int0 ---> IRQ 118
- int1 ---> IRQ 119
- int2 ---> IRQ 120
However, just like i.MX7, i.MX8MM uses the following ENET irq mapping:
- int0 ---> IRQ 120
- int1 ---> IRQ 118
- int2 ---> IRQ 119
Fix it by passing the interrupt-names property with the correct mapping.
Tested networking on a imx8mm-evk board successfully.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
---
Hi Fugang,
Could you please help review this RFC series?
My understanding is that the i.MX8M class of products are derived from
i.MX7 from an ENET IRQ mapping perspective. (i.MX8QXP also uses the
same i.MX7 mapping by the way). The Reference Manual also seems to
indicate the same, but the ENET IRQ naming differs a bit between the
i.MX7 and i.MX8MM RM's.
If this is correct, then I plan to also fix i.MX8MQ, i.MX8MN and i.MX8MP dtsi
files.
My initial goal was to add the pps irq (patch 2/2), but then I noticed
the potential irq mismatch and now it is a two patch series.
Thanks
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
imx8mm has IRQ 121 associated with the '1588 Timer Interrupt', so add an
entry for it.
With this change IRQ 121 can properly increment when PTP applications
like ptp4l is used.
Suggested-by: Rogerio Nunes <redacted>
Signed-off-by: Fabio Estevam <festevam@gmail.com>
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
From: Andy Duan <hidden> Date: 2020-08-19 01:45:09
From: Fabio Estevam <festevam@gmail.com> Sent: Wednesday, August 19, 2020 5:05 AM
imx8mm has IRQ 121 associated with the '1588 Timer Interrupt', so add an
entry for it.
With this change IRQ 121 can properly increment when PTP applications like
ptp4l is used.
No, IRQ 121 is not for PTP (ptp4l), upstream kernel already support PTP, the irq 121
is only for PPS, not relates to PTP. And PPS is optional that depends on board design and
real use case.
From: Andy Duan <hidden> Date: 2020-08-19 01:38:10
From: Fabio Estevam <festevam@gmail.com> Sent: Wednesday, August 19, 2020 5:05 AM
Hi Fugang,
Could you please help review this RFC series?
My understanding is that the i.MX8M class of products are derived from
i.MX7 from an ENET IRQ mapping perspective. (i.MX8QXP also uses the same
i.MX7 mapping by the way). The Reference Manual also seems to indicate the
same, but the ENET IRQ naming differs a bit between the
i.MX7 and i.MX8MM RM's.
If this is correct, then I plan to also fix i.MX8MQ, i.MX8MN and i.MX8MP dtsi
files.
My initial goal was to add the pps irq (patch 2/2), but then I noticed the
potential irq mismatch and now it is a two patch series.
Thanks
It doesn't matter, since there three irq share the same irq handler, and irq handler distinguish
Irq by checking register event, so there have no explicit mapping for the three irqs, so we never
see problem. But for the fourth irq that is required for the last one, which is for pps, not for ptp4l.
Regards,
Fugang
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Andy,
On Tue, Aug 18, 2020 at 10:36 PM Andy Duan [off-list ref] wrote:
It doesn't matter, since there three irq share the same irq handler, and irq handler distinguish
Irq by checking register event, so there have no explicit mapping for the three irqs, so we never
see problem. But for the fourth irq that is required for the last one, which is for pps, not for ptp4l.
Thanks. I will submit patches adding the fourth interrupt for the i.MX8M SoCs.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel