TDA4AH-Q1: gpio中断不响应

我们在调一个外设，注册了中断后，没有响应，确认外设硬件中断有波形，且对应影响设置成输入模式可以读取到中断线的电平状态

dts

		gpio_irq = <&main_gpio0 24 GPIO_ACTIVE_HIGH>; /*gpio0_24 AE36*/

调用的地方

	client_data->gpio_pin = of_get_named_gpio_flags(
		client_data->dev->of_node,
		"gpio_irq", 0, NULL);
//	client_data->gpio_pin = 388;
	PINFO("%s gpio 2 number:%d\n", SENSOR_ACC_NAME, client_data->gpio_pin);
	if (client_data->gpio_pin < 0) {
		PINFO("%s return gpio number:%d\n", SENSOR_ACC_NAME, client_data->gpio_pin);
		err = client_data->gpio_pin;
		return err;
	}
	
#if 1
	err = gpio_request_one(client_data->gpio_pin,
				GPIOF_IN, "smi230_acc_interrupt");
	if (err < 0) {
		PDEBUG("gpio_request_one\n");
		return err;
	}
	err = gpio_direction_input(client_data->gpio_pin);
	if (err < 0) {
		PDEBUG("gpio_direction_input\n");
		return err;
	}
	
	printk("irq 2 %d\n",client_data->IRQ);
#endif	
	printk("irq 3 %d\n",client_data->IRQ);

	client_data->IRQ = gpio_to_irq(client_data->gpio_pin);
	printk("irq %d\n",client_data->IRQ);
	err = request_irq(client_data->IRQ, smi230_irq_handle,
			IRQF_TRIGGER_RISING,
			SENSOR_ACC_NAME, client_data);
	if (err < 0) {
		printk("request_irq %d\n",err);
		return err;
	}

以下中断计数没有增加的现象

364:00000000GPIO  24 Edge-davinci_gpio  SMI230ACC

同时我们也用

WKUP_GPIO0_13　Ｋ38测试是否支持中断，发现也不行

yk z：

我们发现对应的中断已经置位了

清空，自动置１

,

Shine：

请看一下Pinmux有没有设置对？

,

yk z：

现在用的引脚是AE36，pinmux是对的

devmem2 0x0011C060
/dev/mem opened.
Memory mapped at address 0xffffaf991000.
Read at address0x0011C060 (0xffffaf991060): 0x00050007

,

Cherry Zhou：

您好，您的问题我们已升级到英文论坛寻求帮助，链接如下，请持续关注：

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1262301/tda4ah-q1-the-gpio-interrupt-is-not-responding

,

Cherry Zhou：

您好，

为了确保在为中断定义的基础上正确地对 GPIO 进行引脚多路复用，且使用 Linux 检查启用中断的流程是否正确，您请可以按照此FAQ来查看是否可以在您的系统上复现？ 

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1058595/faq-tda4vm-how-to-test-gpio-interrupts

详情请见英文论坛答复。

,

yk z：

我们用(AE36) GPIO0_24做实验

diff --git a/board-support/linux-kernel/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts b/board-support/linux-kernel/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
index d7e846127..9c69bd834 100755
--- a/board-support/linux-kernel/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
+++ b/board-support/linux-kernel/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
@@ -248,7 +248,11 @@ vdd_sd_dv: regulator-TLV71033 {states = <1800000 0x0>,<3300000 0x1>;};
-
+	gpio_test{
+compatible = "ti,gpio_test";
+interrupt-parent = <&main_gpio0>;
+interrupts = <24 IRQ_TYPE_EDGE_BOTH>;
+	};cpsw9g_virt_mac: main-r5fss-cpsw9g-virt-mac0 {compatible = "ti,j721e-cpsw-virt-mac";dma-coherent;
@@ -747,6 +751,13 @@ mxt2113td: mxt2113td@4a {status = "okay";};};&mcu_i2c1 {status = "okay";pinctrl-names = "default";
@@ -762,14 +773,14 @@ smi230gyro: smi230gyro@68 {};smi230acc: smi230acc@18 {compatible = "SMI230ACC";
-pinctrl-names = "default";
-pinctrl-0 = <&imuacc_main_pins_default>;
+// pinctrl-names = "default";
+// pinctrl-0 = <&imuacc_main_pins_default>;reg = <0x18>;// pinctrl-0 = <&imuacc_pins_default>;// gpio_irq = <&wkup_gpio0 13 IRQ_TYPE_EDGE_RISING>; /*gpio0_24 AE36*/// gpio_irq = <&main_gpio0 24 0>; /*gpio0_24 AE36*/
-gpios = <&main_gpio0 24 0>;
+// gpios = <&main_gpio0 24 0>;status = "okay";};};
@@ -930,7 +941,10 @@ &pcie1_ep {};&main_gpio0 {
+	pinctrl-names = "default";
+pinctrl-0 = <&imuacc_main_pins_default>;status = "okay";
+};&main_gpio_intr {
@@ -1364,6 +1378,8 @@ &dsi0 {};&wkup_gpio0 {status = "okay";};diff --git a/board-support/linux-kernel/drivers/gpio/gpio-davinci.c b/board-support/linux-kernel/drivers/gpio/gpio-davinci.c
index 0dca22c8d..6b5307360 100644
--- a/board-support/linux-kernel/drivers/gpio/gpio-davinci.c
+++ b/board-support/linux-kernel/drivers/gpio/gpio-davinci.c
@@ -25,7 +25,11 @@#include <linux/pm_runtime.h>#include <asm-generic/gpio.h>
+#include <linux/interrupt.h>
+#include <linux/of_irq.h>
+#include <linux/of_gpio.h>+int gpio_test_init(void);#define MAX_REGS_BANKS 5#define MAX_INT_PER_BANK 32@@ -189,7 +193,34 @@ davinci_gpio_get_pdata(struct platform_device *pdev)dev_err(&pdev->dev, "Populating pdata from DT failed: err %d\n", ret);return NULL;}
+static irqreturn_t test_irq(int irq, void *data)
+{
+	printk("%s: irq %d, val=%d\n", __func__, irq,
+gpio_get_value(333));
+	return IRQ_HANDLED;
+}
+
+int gpio_test_init(void)
+{
+	struct device_node *np;
+	int irq;
+	int ret = 0;
+
+	np = of_find_node_by_name(NULL, "gpio_test");
+
+	if (np) {
+pr_info("Initializing gpio test\n");
+irq = irq_of_parse_and_map(np, 0);
+printk("irq number is %d\n", irq);
+ret = request_irq(irq, test_irq, //IRQF_TRIGGER_RISING,
+IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
+"key-gpio", NULL);
+if (ret)
+pr_err("request_irq returns %d\n", ret);
+	}+	return ret;
+}static int davinci_gpio_probe(struct platform_device *pdev){int bank, i, ret = 0;
@@ -197,7 +228,7 @@ static int davinci_gpio_probe(struct platform_device *pdev)struct davinci_gpio_controller *chips;struct davinci_gpio_platform_data *pdata;struct device *dev = &pdev->dev;
-
+	printk("Name of gpio dev is %s\n", pdev->name);pdata = davinci_gpio_get_pdata(pdev);if (!pdata) {dev_err(dev, "No platform data found\n");
@@ -275,6 +306,9 @@ static int davinci_gpio_probe(struct platform_device *pdev)ret = davinci_gpio_irq_setup(pdev);if (ret)return ret;
+	if (!strcmp("600000.gpio", pdev->name)) {
+gpio_test_init();
+	}return 0;}

devmem2 0x0011C060/dev/mem opened.Memory mapped at address 0xffff9563a000.Read at address 0x0011C060 (0xffff9563a060): 0x00050007

确认注册成功

echo value

中断信号

但是没有中断响应

,

yk z：

外部中断源没有，也没有中断生成

,

Cherry Zhou：

已跟进给工程师，请关注英文论坛的答复。

,

Cherry Zhou：

您好，

根据您发送的补丁文件，并没有看到引脚多路复用。 能否分享下 imuacc_main_pins_default 节点的内容？

由于看起来像使用的是主域 GPIO0_24，因此在 imuacc_main_pins_default 下应该有类似"J784S4_IOPAD(0x060, PIN_INPUT, 7) /* (AE36) MCASP2_AXR1.GPIO0_24 */"的内容。 请参考以上回复中的FAQ，来了解该节点应是什么样的示例。 

,

yk z：

	imuacc_main_pins_default: imuacc-main-pins-default {pinctrl-single,pins = <J784S4_IOPAD(0x060, PIN_INPUT, 7) /* (AE36) GPIO0_24 */>;};

,

yk z：

 请参考以上回复中的FAQ，来了解该节点应是什么样的示例。

目前按FAQ的实验看，系统没有响应GPIO的中断，我们移植了tp模块在这上面（在其他sdk中正常工作），gpio也没有触发中断，

结论：我们认为系统对于ＧＰＩＯ的中断不起作用

,

Cherry Zhou：

请看以下答复：

Device tree looks to be defined correctly, so issue must be elsewhere.

yk z said:我们移植了tp模块在这上面（在其他sdk中正常工作）

Could I get a reminder for which SDK version you are currently working on, and which SDK version the TP module was ported from? Also, apologies for my lack of knowledge, but could you clarify what "TP" stands for (ex. is it "Test Point")?

Lastly, could you check one last common issue that you face, which is that if GPIO is defined for RTOS usage, there would be a resource conflict and not allow Linux control of the GPIO? As an experiment, are you able to toggle the GPIO pin through software (assuming there is a test point designed in to verify the signal on this GPIO and this GPIO is fine to be configured as output)?

,

yk z：

TP"

	mxt2113td: mxt2113td@4a {compatible = "atmel,maxtouch";pinctrl-names = "default";//	pinctrl-0 = <&ub941_initb_pins_default>;reg = <0x4a>;//gpios = <&porta 13 0>; /*gpio13 for touch irq*/gpios = <&main_gpio0 30 0>;/*AH37*/status = "okay";};

	mxt2113td: mxt2113td@4a {compatible = "atmel,maxtouch";pinctrl-names = "default";//	pinctrl-0 = <&ub941_initb_pins_default>;reg = <0x4a>;//gpios = <&porta 13 0>; /*gpio13 for touch irq*/gpios = <&main_gpio0 30 0>;/*AH37*/status = "okay";};

Lastly, could you check one last common issue that you face, which is that if GPIO is defined for RTOS usage, there would be a resource conflict and not allow Linux control of the GPIO? As an experiment, are you able to toggle the GPIO pin through software (assuming there is a test point designed in to verify the signal on this GPIO and this GPIO is fine to be configured as output)?

Tp 意思是 touch

mxt2113td: mxt2113td@4a { compatible = "atmel,maxtouch"; pinctrl-names = "default"; // pinctrl-0 = <&ub941_initb_pins_default>; reg = <0x4a>; //gpios = <&porta 13 0>; /*gpio13 for touch irq*/ gpios = <&main_gpio0 30 0>;/*AH37*/ status = "okay"; };

我们将rtos相关的pimux注释掉了，开机后确认pinmux是对的

AE36

As an experiment, are you able to toggle the GPIO pin through software (assuming there is a test point designed in to verify the signal on this GPIO and this GPIO is fine to be configured as output)?

是可以验证没有虚焊，我们将引脚ＡＥ３６设置成input,可以读取到gpio value（电平由外部信号触发）

,

yk z：

结合以上，我们已经验证了，ＡＥ３６，ＡＨ３７，Ｋ38（linux　driver)包括你们ＦＡＱ实验，现象是：引脚可以控制，ＧＰＩＯ中断不能触发

,

Cherry Zhou：

请看如下答复：

yk z said:我们移植了tp模块在这上面（在其他sdk中正常工作），

Which SDK was the TP module working in, and which SDK is this ported over to? For example, is it ported over from TDA4VM PSDK Linux 8.5 version to TDA4VH PSDK RTOS 8.6 version? I would like to know whether this was working on a different device, OS, and/or version of the SDK, to see what differences could cause the device to work or not work.

yk z said:我们将rtos相关的pimux注释掉了，

Is the interrupt being handled in RTOS or Linux? If RTOS is handling the interrupt, Linux should not set up and hog the GPIO pin, and instead RTOS should be used to set up the pin.

,

yk z：

Which SDK was the TP module working in, and which SDK is this ported over to? For example, is it ported over from TDA4VM PSDK Linux 8.5 version to TDA4VH PSDK RTOS 8.6 version? I would like to know whether this was working on a different device, OS, and/or version of the SDK, to see what differences could cause the device to work or not work.

１：

Which SDK was the TP module working in, and which SDK is this ported over to? For example, is it ported over from TDA4VM PSDK Linux 8.5 version to TDA4VH PSDK RTOS 8.6 version? I would like to know whether this was working on a different device, OS, and/or version of the SDK, to see what differences could cause the device to work or not work.

tp能工作的sdk版本 version

ti-processor-sdk-linux-j7-evm-07_03_00_05

ti-processor-sdk-rtos-j7-evm-07_03_00_05

2:

Is the interrupt being handled in RTOS or Linux? If RTOS is handling the interrupt, Linux should not set up and hog the GPIO pin, and instead RTOS should be used to set up the pin.

目前没有在对应的sdk中添加gpio中断

case 问题 当前sdk版本是：

ti-processor-sdk-linux-j721s2-evm-08_06_00_10

ti-processor-sdk-rtos-j721s2-evm-08_06_00_11

,

Cherry Zhou：

您好，请看以下答复：

Understood, thanks for the clarification. It looks like there is a difference in SDK version as well as difference in device.

As such, I think the first step is to isolate if the problem is due to differences in SDK version, or differences in device. Although I understand this is additional work for you, can you:

Verify if you can move to 8.6 SDK on J721E, you can still use touch screen.
After verifying step one, check to see if device differences are taken into account. For example, this FAQ summarizes differences in GPIO between J721E and J721S2: https://e2e.ti.com/support/processors-group/processors—internal/f/processors—internal-forum/1160537/faq-tda4vh-reduction-in-the-number-of-gpios-from-j7es-to-j7ahp. 

In the meantime, I will be doing some experiments on my end to also see if GPIO interrupt behaviors have changed between 7.3 and 8.6 SDK, and additionally check the differences in behavior between J721E and J721S2. This will most likely take me a couple of days, so please expect an update next week at the latest. However, in case the issue is not just GPIO interrupt related for enabling touch screen, I think the customer experiments with the touch screen on 8.6 SDK on J721E will be worthwhile.

,

yk z：

e2e.ti.com/…/faq-tda4vh-reduction-in-the-number-of-gpios-from-j7es-to-j7ahpe2e.ti.com/…/faq-tda4vh-reduction-in-the-number-of-gpios-from-j7es-to-j7ahpe2e.ti.com/…/faq-tda4vh-reduction-in-the-number-of-gpios-from-j7es-to-j7ahpe2e.ti.com/…/faq-tda4vh-reduction-in-the-number-of-gpios-from-j7es-to-j7ahp

e2e.ti.com/…/faq-tda4vh-reduction-in-the-number-of-gpios-from-j7es-to-j7ahp

这个路径好像不能访问

,

Cherry Zhou：

您好，

该文档中的内容我已通过邮件发送给您，请注意查收。

,

yk z：

发的图很模糊，基本看不清楚，请问贵司rd那边对这个系统无法响应gpio中断有没有方案

,

Cherry Zhou：

您好，

FAQ文字版内容如下：

J7ES had many digital / LVCMOS RGMII interfaces, those interfaces are not present on AHP, and are instead mapped to SERDES/Analog ports. There are many more considerations for this decision including die size and package size that have been optimized including the number of DDR interfaces and power supply mapping.

From J7ES to J7AHP there is a reduction in number of LVCMOS IO PADs leads to a reduction in the number of usable GPIOs as per the below table.

Also, the available GPIOs may be muxed in a way where it may not be possible to use them as GPIOs.

SoC

Main domain

MCU domain

Total

J7ES

164

84

248

J7AEP / J7AHP

66

89

155

If your customers are migrating from J7ES to J7AHP, considering the fact that AHP is supposed to be a more powerful device the above limitation is non intuitive – please make sure the customers understand this.

Alternatives,

Use of IO expanders, in case the customer PCB design constrains allow this.
Utilizing GPIOs across domains, MCU GPIOs being used to configure MAIN domain transceivers / PHYs should be okay as long as there are configured by MCU R5Fs (this makes SW complex). Also some use cases may break FFI.
Tradeoffs with functionality / performance. Example, with Bosch we went ahead and reduced the number of trace pins to mux them as GPIOs.
Grouping the external Transceivers / PHYs as much as possible so that they can be controlled by same GPIOs.

yk z said:请问贵司rd那边对这个系统无法响应gpio中断有没有方案

以下是工程师的最新答复：

I just noticed after reviewing our conversations, but is the customer using J721S2 (TDA4AL) or J784S4 (TDA4AH)? The thread was originally created for TDA4AH, but in our latest conversations it was mentioned J721S2 SDK is used.

Can you confirm if the customer device is TDA4AH (for which the thread was originally created for), or TDA4AL (which is the device that the SDK being used is intended for)?

Lastly, I did a quick experiment, in which I followed the interrupt FAQ (https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1058595/faq-tda4vm-how-to-test-gpio-interrupts) for both 7.3 and 8.6 SDK. I found that behavior is the same on TDA4VM for both versions of SDK, so there seems to be not much change in terms of API when going from 7.3 to 8.6. Therefore, I think any issues customers are seeing is most likely due to the difference in SoC instead of difference in SDK.

,

yk z：

I just noticed after reviewing our conversations, but is the customer using J721S2 (TDA4AL) or J784S4 (TDA4AH)? The thread was originally created for TDA4AH, but in our latest conversations it was mentioned J721S2 SDK is used.

Can you confirm if the customer device is TDA4AH (for which the thread was originally created for), or TDA4AL (which is the device that the SDK being used is intended for)?

我们的调试的硬件对应的是tda4vh   sdk  ti-processor-sdk-linux-j784s4-evm-08_06_00_12,不好意思，上面标错了,这个case的标题中提到的case是针对td4vh平台

I think any issues customers are seeing is most likely due to the difference in SoC instead of difference in SDK
是否是sdk对不同soc针对中断子系统的兼容性问题

,

yk z：

I think any issues customers are seeing is most likely due to the difference in SoC instead of difference in SDK是否是sdk对不同soc针对中断子系统的兼容性问题

I think any issues customers are seeing is most likely due to the difference in SoC instead of difference in SDK
是否是sdk对不同soc针对中断子系统的兼容性问题

I think any issues customers are seeing is most likely due to the difference in SoC instead of difference in SDK
是否是sdk对不同soc针对中断子系统的兼容性问题

I think any issues customers are seeing is most likely due to the difference in SoC instead of difference in SDK是否是sdk对不同soc针对中断子系统的兼容性问题

,

Cherry Zhou：

好的感谢您的确认，我们和工程师确认后给到您答复。

,

Cherry Zhou：

您好，请看工程师最新的答复：

yk z said:是否是sdk对不同soc针对中断子系统的兼容性问题

Possibly. However, it could also still be that the GPIO pin that we are trying to configure is used by another process on the J784S4, and in your application these board/device related changes are not taken into consideration.

For example, if I try to run the FAQ example using the same pin that is used in the FAQ on J784S4, I get the following logs:

root@j784s4-evm:~# dmesg | grep gpio[ 1.010580] Name of gpio dev is 42110000.gpio[ 1.015349] Name of gpio dev is 600000.gpio[ 2.776707] Name of gpio dev is 42110000.gpio[ 2.782621] Initializing gpio test[ 2.791174] Name of gpio dev is 600000.gpio[ 4.719752] pinctrl-single 4301c000.pinctrl: pin PIN36 already requested by 42110000.gpio; cannot claim for 46000000.ethernetroot@j784s4-evm:~#

However, since I am also having other troubles porting over the FAQ example to J784S4, it could be that there is a change in API or the driver. I am still in the process of figuring out what the difference is, but please let me know what experiments the customer is trying out as well.

,

Cherry Zhou：

您好，可以参考以下最新的答复：

The interrupt router configuration is wrong in 8.6 SDK. This is fixed in 9.0 SDK.

Here are the 2 patches:

commit 68ec7433794c13da14e803b477ac6eefd330f243
Author: Dasnavis Sabiya <sabiya.d@ti.com>
Date:Tue Jun 27 16:21:51 2023 +0530arm64: dts: ti: k3-j784s4: Fix the interrupt ranges property for main gpio intrThe parent's input irq number is incorrect for the main_gpio_intr.Update the irq number as per the exact numbers in:https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j784s4/interrupt_cfg.htmlFixes: bebe2e3c9a30i ("arm64: dts: ti: Add initial support for J784S4 SoC")Signed-off-by: Dasnavis Sabiya <sabiya.d@ti.com>Reviewed-by: Apurva Nandan <a-nandan@ti.com>diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
index 2baac35dca2d..b6f40e7f7e13 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
@@ -112,7 +112,7 @@#interrupt-cells = <1>;ti,sci = <&sms>;ti,sci-dev-id = <10>;
-ti,interrupt-ranges = <8 360 56>;
+ti,interrupt-ranges = <8 392 56>;};

The above is for main domain GPIO interrupts.

commit f1ae38221253b800032585deff26e017615e5e5e
Author: Apelete Seketeli <aseketeli@baylibre.com>
Date:Tue Apr 18 10:58:36 2023 +0200arm64: dts: ti: k3-j784s4-evm: Fix wakeup gpio pinmux interrupt rangeThis patch fixes the interrupt range of wakeup gpio used by TPS6594 PMIC.Signed-off-by: Apelete Seketeli <aseketeli@baylibre.com>Signed-off-by: Esteban Blanc <eblanc@baylibre.com>Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi
index f04fcb614cbe..ec4330f5dbb8 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi
@@ -65,7 +65,7 @@#interrupt-cells = <1>;ti,sci = <&sms>;ti,sci-dev-id = <177>;
-ti,interrupt-ranges = <16 928 16>;
+ti,interrupt-ranges = <16 960 16>;};mcu_conf: syscon@40f00000 {

The above is for wake up domain.

,

yk z：

好的，我这边测试一下

,

yk z：

请教一下，这些中断范围信息应该可以查到的，但这边没有在trm手册中找到，这些是在哪些文档的哪里可以看啊

,

Cherry Zhou：

Hi，

我们确认下给您答复。

,

Cherry Zhou：

您好，请参考以下答复：

This was a mistake in our SDK, so you should not have had to go through the TRM for this. However, if you are interested in learning how to correlate the DTS file changes with the information in the TRM, I would recommend re-reading section 9.3 Interrupt Router in the TRM. For example, interrupt ID 960 is the start of the interrupts with 16th WKUP_GPIOMUX as the source interrupt:

Likewise, interrupt ID 392 is the start of the interrupts with 8th GPIOMUX as the source interrupt:

Thanks.

,

yk z：

谢谢解答