Linux/DRA722: Configuring a GPIO interrupt on IPU1 (running TI-RTOS) creates an interrupt error on MPU (running Linux)

Thanks Stan,

What I really don't understand is that interrupt 167 shows Linux with an IRQ to crossbar 28, which is the GPIO5 IRQ, and I'm assuming there's an ISR for that interrupt, but after I do my configuration on the M4, interrupt 168 appears in the list, apparently without a handler. I'd really like to understand what is creating this new interrupt, but meanwhile your solution will probably work.

Thanks again,

   Mike

More follow-up: I implemented Stan's suggestion, and manually removed interrupt 28 (GPIO5_IRQ_1) from the MPU crossbar as follows in the Linux console:
omapconf write 0x4a002b54 0x001b0000

After that, I get the interrupts working as hoped in the M4, and no errors on the A15/Linux side.

Now, we're trying to do the same thing, except as part of the Linux configuration. We've tried to do it by removing the interrupt for GPIO5 in the device tree, but this looks like it ended up having an unwanted side-effect of disabling GPIO7 outputs, that I'm using to bit-bang a SPI interface.

diff -rNuw kernel-source/arch/arm/boot/dts/dra7.dtsi
kernel-source-rem-int28/arch/arm/boot/dts/dra
--- kernel-source/arch/arm/boot/dts/dra7.dtsi 2017-09-25
08:55:02.814964991 -0400
+++ kernel-source-rem-int28/arch/arm/boot/dts/dra7.dtsi 2017-09-25
10:32:55.732056507 -0400
@@ -548,12 +548,9 @@
gpio5: gpio@4805b000 {
     compatible = "ti,omap4-gpio";
     reg = <0x4805b000 0x200>;
-    interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>;
     ti,hwmods = "gpio5";
     gpio-controller;
     #gpio-cells = <2>;
-    interrupt-controller;
-    #interrupt-cells = <2>;
};

def for gpio7

gpio7: gpio@48051000 {
     compatible = "ti,omap4-gpio";
     reg = <0x48051000 0x200>;
     interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
     ti,hwmods = "gpio7";
     gpio-controller;
     #gpio-cells = <2>;
     interrupt-controller;
     #interrupt-cells = <2>;
};

def for SPI1
mcspi1: spi@48098000 {
     compatible = "ti,omap4-mcspi";
     reg = <0x48098000 0x200>;
     interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
     #address-cells = <1>;
     #size-cells = <0>;
     ti,hwmods = "mcspi1";
     ti,spi-num-cs = <4>;
     dmas = <&sdma_xbar 35>,
            <&sdma_xbar 36>,
            <&sdma_xbar 37>,
            <&sdma_xbar 38>,
            <&sdma_xbar 39>,
            <&sdma_xbar 40>,
            <&sdma_xbar 41>,
            <&sdma_xbar 42>;
     dma-names = "tx0", "rx0", "tx1", "rx1",
                 "tx2", "rx2", "tx3", "rx3";
     status = "disabled";
};

diff of the two device trees disassembled :

/ {
#address-cells = <0x00000002>;
@@ -2846,12 +2846,9 @@
gpio@4805b000 {
     compatible = "ti,omap4-gpio";
     reg = <0x4805b000 0x00000200>;
-    interrupts = <0x00000000 0x0000001c 0x00000004>;
     ti,hwmods = "gpio5";
     gpio-controller;
     #gpio-cells = <0x00000002>;
-    interrupt-controller;
-    #interrupt-cells = <0x00000002>;
};
gpio@4805d000 {
     compatible = "ti,omap4-gpio";

Any ideas how to disable the GPIO5 interrupt in Linux, without any side-effects?

Thanks,
Mike

Nikhil,

I am enabling the clocks for GPIO2, 5, and 7 as follows:

//                case GPIO2:
                    CSL_FINST(l4PerCmReg->CM_L4PER_GPIO2_CLKCTRL_REG,
                              L4PER_CM_CORE_COMPONENT_CM_L4PER_GPIO2_CLKCTRL_REG_MODULEMODE, AUTO);

                    l4PerCmReg->CM_L4PER_GPIO2_CLKCTRL_REG |= (
                            (CM_L4PER_GPIO2_CLKCTRL_OPTFCLKEN_DBCLK_FCLK_EN << CM_L4PER_GPIO2_CLKCTRL_OPTFCLKEN_DBCLK_SHIFT) |
                            (CM_L4PER_GPIO2_CLKCTRL_MODULEMODE_AUTO << CM_L4PER_GPIO2_CLKCTRL_MODULEMODE_SHIFT));

//                case GPIO5:
                    CSL_FINST(l4PerCmReg->CM_L4PER_GPIO5_CLKCTRL_REG,
                              L4PER_CM_CORE_COMPONENT_CM_L4PER_GPIO5_CLKCTRL_REG_MODULEMODE, AUTO);

                    l4PerCmReg->CM_L4PER_GPIO5_CLKCTRL_REG |= (
                            (CM_L4PER_GPIO5_CLKCTRL_OPTFCLKEN_DBCLK_FCLK_EN << CM_L4PER_GPIO5_CLKCTRL_OPTFCLKEN_DBCLK_SHIFT) |
                            (CM_L4PER_GPIO5_CLKCTRL_MODULEMODE_AUTO << CM_L4PER_GPIO5_CLKCTRL_MODULEMODE_SHIFT));

//                case GPIO7:
                    CSL_FINST(l4PerCmReg->CM_L4PER_GPIO7_CLKCTRL_REG,
                        L4PER_CM_CORE_COMPONENT_CM_L4PER_GPIO7_CLKCTRL_REG_MODULEMODE, AUTO);

                    l4PerCmReg->CM_L4PER_GPIO7_CLKCTRL_REG |= (
                        (CM_L4PER_GPIO7_CLKCTRL_OPTFCLKEN_DBCLK_FCLK_EN << CM_L4PER_GPIO7_CLKCTRL_OPTFCLKEN_DBCLK_SHIFT) |
                        (CM_L4PER_GPIO7_CLKCTRL_MODULEMODE_AUTO << CM_L4PER_GPIO7_CLKCTRL_MODULEMODE_SHIFT));

This is from the BIOS side, and it's what worked before I disabled GPIO5 in the device tree. Is there a way for you to check if the clocks for GPIO5 and 7 are derived from a common clock? If they are, then what is a solution for my current problem?

Thanks,

   Mike

This thread is 3 years old now, but one of my customers ran into this same issue with seeing spurious Linux interrupts related to GPIO being used on other CPU's.  We found a different solution, so I wanted to share.  As background, this GPIO peripheral goes back at least as far as OMAP2 (i.e. 10+ years ago), and in those devices GPIO IRQ_1 was always routed to the ARM while IRQ_2 was always routed to the DSP.  It occurred to me that the issue might relate to the fact that the DSP/IPU is attempting to use IRQ_1 which is what the ARM traditionally uses.  My customer modified the RTOS driver to program the IRQ_2-related registers instead of IRQ_1, and correspondingly updated the crossbar to route IRQ_2 to the DSP.  Those changes resolved the spurious Linux interrupts.

Michael/Michel -- sorry I wasn't able to provide you this data point 3 years ago!  Hopefully this helps a few other people.

Brad,

Michael is no longer working at ACTIA Corp.

Sorry for the delay, I have been working on other issues and hadn't got to this part yet. I am working from home, I have to watch out as not to work too many hours, that is the issue here when working from home. The funny thing is that I can do more work even with only 8 hours days, not being bothered as frequently. My cats are the only ones that would disturb me when they are hungry or want attention.

Due to some serious issues with our external CAN which were only partially working I chose to revise the code. For  message everything is done thru messaging except broadcasting which sometime stops working when using external CAN with a bit too heavy loads. I am working on using circular buffers  cmem and limit the messaging. I am also looking at getting the SPI port to work instead of bit banging.

I have the internal CAN on Linux and only the external 3 CAN ports on the Cortex M4.  I experimented on Linux for the Microchip device but it can't handle heavy load, almost locks the processor. The issue has to do with the way the hardware is done. We have a STM32 co-processor and the electronic design team has noticed that when the DRA726 is turned off and the STM32 on with the interrupt pin activated on the DRA726, the DRA726 gets extremely hot. So it was decided to disconnect that line. The problem with Linux is that with no interrupt there is no way to get the kernel module to recognize the devices.

To go around that I rewrote the kernel module to use the other interrupts pins that can be enabled or disabled using a SPI message. That didn't work out too well so I wrote a kernel module that polls. It works perfectly for transmission but for reception I may miss many frames and if broadcasting too many messages it freezes the processor. I could disable the error message that do that but that would not get me to receive the missing messages.

Si I am going back partly to the M4. I keep the internal CAN on Linux where it works without issues and dedicate the Cortex M4 to handle the Microchip devices. In Michael's code he only used one Microchip device, the 3rd one was not populated and the 2nd one didn't always work. When the external CAN were misbehaving we would lose access to even the internal CAN ports. This has not been an issue so far with our current customers as they only use the internal CAN ports.

Does the IPU messaging work the same from a Linux kernel module? I would like to modify my kernel module to get  the external CAN to and from the Cortex M4 so I can use socket can just like I do for the internal CAN.

To create the code I am doing things a bit differently, not using eclipse. For the IPU1 I use the dra72x TI RTOS SDK and not the am57xx one and for the host I created my own Makefile.am and configure.ac files and use the SDK that I created with my yocto (poky).  I am still at kernel 4.4.45 but will eventually move to 4.19.73. I do have a working evironment with the new kernel but for our current customer I use the old one which is based on what TI uses for thei sdk 3.04 wtih the exception that I use poky with the recipes I need from the TI yocto.

If I have issues I can't figure out I will open an other message. You could close this one for now. I will save the info you are giving me for later review.

Thanks

Michel Catudal

ACTIA Corp

Michel Catudal said:

We have a STM32 co-processor and the electronic design team has noticed that when the DRA726 is turned off and the STM32 on with the interrupt pin activated on the DRA726, the DRA726 gets extremely hot.

You are damaging the device.  Please reference footnote 5 of the Absolute Max Ratings:

(5) The maximum valid input voltage on an IO pin cannot exceed 0.3 volts when the supply powering the IO is turned off.

You need a buffer to protect the processor pin.

Brad,

The pin has been disconnected in newer releases of the build. This problem is why I am reluctant to even use the interrupts that can be enabled in software, just in case the STM32 would turn the DRA726 off before the DRA726 had time to tell the microchip devices to turn them off.

Is that also an issue with the UART? The STM32 never initiate communication with the DRA726.

John is no longer working at ACTIA. You may want to send a message to Jed. If you don't have his Email address, just send me an Email and I will forward it to Jed.

Jed is responsible for the electronics design, we may have a hardware update sometimes in 2021. For now I just need to find ways around the problems.

Michel Catudal

ACTIA Corp

Brad,

I double checked my STM32 code and the interrupt pins would be the only ones that would cause problems.

The output lines from the MCP25625 that are directly connected to the DRA726 are MPU_CAN_SO, RX0BF_CANx and RX1BF_CANx. The jumper for the main interrupts are not populated. They were removed after we noticed that the processor was getting too hot.

As long as I have those lines turned off when I go low speed and turn the processor off I should be safe. Since clk, si are low when power is off there shouldn't be any activity on the so pins. As for the huart it is turned off then.

To be safe I probably need to stick with polling. Since those three devices are the only ones that will be handled in the Cortex M4 that should be good enough.

Michel Catudal

ACTIA Corp

,