2011-03-28 10:50:11     Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Document created by Aaronwu Employee on Aug 26, 2013
Version 1Show Document
  • View in full screen mode

2011-03-28 10:50:11     Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Robert Wimmer (GERMANY)

Message: 99362   

 

Hi guys,

 

just some stupid little questions where I'm feeling unsure.

 

Following situation:

 

With my ADSP-BF537 I'd like to use GPIO pin PH12 as an external interrupt source.

Not wanting to reinvent the wheel (e.g. writing something own with UIO) I thought it could be a great idea to use the "gpio_keys" driver with following settings in the "blackfin/mach-bf537" board file:

 

static struct gpio_keys_button bfin_gpio_keys_table[] = {

    {BTN_0, GPIO_PH12, 0, "gpio-keys: BTN_0", EV_KEY},

};

 

As soon as this driver [gpio_keys] in conjunction with the (on my side) necessary "bfin_mac" driver is compiled into the kernel (I'm NOT using "kernel modules" functionality) and a signal is sent to PH12, system freezes.

I could figure out that, as soon as an interrupt from PH12 occurs, the ISR "bfin_mac_interrupt" (linux-2.6.x/drivers/net/bfin_mac.c) is called again as soon as it returns. That means to me that an interrupt flag is not cleared (assumably IRQ_PH12). Please correct me if I'm wrong.

 

Perhaps this is the cause of that:

 

DMA1 (MAC RX)    +-.

-----------------|  \

                 |  |-------- SIC_ISR[17] -> IVG11

-----------------|  /

PORTH IRQ A      +-'

 

 

Source:

.   www.surveyor.com/blackfin/Blackfin-HRM.pdf

. Chapter 4-3; Page 111; Figure 4-1. Interrupt Routing Overview

 

It seems to me that PH12 is configured to be IRQ A that is ORed with MAC RX.

 

 

Now my questions:

 

- Is there any possibility to use both drivers with this configuration?

A software solution would be preferred, changing pins on hardware side would mean a much bigger effort to me.

- Do I overlook something?

 

Thanks in advance!

 

Robert

 

 

 

 

Controller:

- ADSP-BF537 rev0.3

 

Tested Blackfin Linux versions:

- 2010R1-RC3

- 2010R1-RC5

TranslateQuoteReplyEditDelete

 

 

2011-03-28 11:06:50     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Sonic Zhang (CHINA)

Message: 99363   

 

PH12 is muxed with MII RXDV PIN on bf537. You can't use this PIN in gpio_key driver unless you connect your phy into RMII other than MII in your customized board and revise the configuration of bfin_mac driver accordingly.

QuoteReplyEditDelete

 

 

2011-03-28 11:28:19     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Robert Wimmer (GERMANY)

Message: 99365   

 

Thank you very much for your fast response!!!

 

You said: "unless I am in RMII mode". This is my current configuration of  "bfin_mac":

 

#if defined(CONFIG_BFIN_MAC) || defined(CONFIG_BFIN_MAC_MODULE)

#include <linux/bfin_mac.h>

 

static const unsigned short bfin_mac_peripherals[] = P_RMII0;

 

static struct bfin_phydev_platform_data bfin_phydev_data[] = {

        {

                .addr = 1,

                .irq = PHY_POLL, // IRQ_MAC_PHYINT

        },

};

 

static struct bfin_mii_bus_platform_data bfin_mii_bus_data = {

        .phydev_number = 1,

        .phydev_data = bfin_phydev_data,

        .phy_mode = PHY_INTERFACE_MODE_RMII,

        .mac_peripherals = bfin_mac_peripherals,

};

 

static struct platform_device bfin_mii_bus = {

        .name = "bfin_mii_bus",

        .dev = {

                .platform_data = &bfin_mii_bus_data,

        }

};

 

static struct platform_device bfin_mac_device = {

        .name = "bfin_mac",

        .dev = {

                .platform_data = &bfin_mii_bus,

        }

};

#endif

 

So I assume I should be in that mode.

 

As I understood you it could be possible to keep my configuration and use both drivers concurrently. But I do not have any idea how. Could you please give me a hint?

 

Thanks!!!

TranslateQuoteReplyEditDelete

 

 

2011-03-28 11:58:48     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Mike Frysinger (UNITED STATES)

Message: 99366   

 

changing to RMII mode isnt something that can be done simply in your config.  your hardware must actually be wired in RMII mode.  is that the case with your board ?

QuoteReplyEditDelete

 

 

2011-03-28 12:04:39     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Robert Wimmer (GERMANY)

Message: 99367   

 

Yes! It's the case!

TranslateQuoteReplyEditDelete

 

 

2011-03-28 12:25:53     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Mike Frysinger (UNITED STATES)

Message: 99368   

 

i imagine the bfin_mac_interrupt() func needs to check some status register to make sure that it is actually the source, and if not, return IRQ_NONE.  otherwise the IRQ core will keep calling the mac irq handler since it claims it processed things.

 

maybe something like:

--- drivers/net/bfin_mac.c      (revision 9801)

+++ drivers/net/bfin_mac.c      (working copy)

@@ -1161,6 +1161,8 @@ static irqreturn_t bfin_mac_interrupt(in

 

get_one_packet:

        if (current_rx_ptr->status.status_word == 0) {

+               u16 irq_status;

+

                /* no more new packet received */

                if (number == 0) {

                        if (current_rx_ptr->next->status.status_word != 0) {

@@ -1168,9 +1170,13 @@ get_one_packet:

                                goto real_rx;

                        }

                }

-               bfin_write_DMA1_IRQ_STATUS(bfin_read_DMA1_IRQ_STATUS() |

-                                          DMA_DONE | DMA_ERR);

-               return IRQ_HANDLED;

+

+               irq_status = bfin_read_DMA1_IRQ_STATUS();

+               if (irq_status & (DMA_DONE | DMA_ERR)) {

+                       bfin_write_DMA1_IRQ_STATUS(DMA_DONE | DMA_ERR);

+                       return IRQ_HANDLED;

+               } else

+                       return IRQ_NONE;

        }

 

real_rx:

QuoteReplyEditDelete

 

 

2011-03-28 12:44:28     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Robert Wimmer (GERMANY)

Message: 99370   

 

Looks not sooo bad! Thank you very much!

 

The modification causes the system not freezing anymore but now following messages occur (sorry for posting such large dumps):

 

irq 24: nobody cared (try booting with the "irqpoll" option)

 

Hardware Trace:

   0 Target : <0x001455a4> { _dump_stack + 0x0 }

     Source : <0x0002cbfc> { ___report_bad_irq + 0x2c } JUMP.L

   1 Target : <0x0002cbfc> { ___report_bad_irq + 0x2c }

     Source : <0x001456a4> { _printk + 0x14 } RTS

   2 Target : <0x001456a0> { _printk + 0x10 }

     Source : <0x0000e9c8> { _vprintk + 0x320 } RTS

   3 Target : <0x0000e9bc> { _vprintk + 0x314 }

     Source : <0x0000e9b6> { _vprintk + 0x30e } IF CC JUMP pcrel (BP)

   4 Target : <0x0000e9a4> { _vprintk + 0x2fc }

     Source : <0x0000e996> { _vprintk + 0x2ee } IF CC JUMP pcrel (BP)

   5 Target : <0x0000e98e> { _vprintk + 0x2e6 }

     Source : <0x0000e428> { _release_console_sem + 0x1d8 } RTS

   6 Target : <0x0000e420> { _release_console_sem + 0x1d0 }

     Source : <0x0000e412> { _release_console_sem + 0x1c2 } IF CC JUMP pcrel

   7 Target : <0x0000e402> { _release_console_sem + 0x1b2 }

     Source : <0x0000e3fc> { _release_console_sem + 0x1ac } IF CC JUMP pcrel (BP)

   8 Target : <0x0000e3ea> { _release_console_sem + 0x19a }

     Source : <0x0000e3dc> { _release_console_sem + 0x18c } IF CC JUMP pcrel (BP)

   9 Target : <0x0000e3d6> { _release_console_sem + 0x186 }

     Source : <0x00021380> { _up + 0x68 } RTS

  10 Target : <0x0002137a> { _up + 0x62 }

     Source : <0x0002136e> { _up + 0x56 } IF CC JUMP pcrel (BP)

  11 Target : <0x0002135c> { _up + 0x44 }

     Source : <0x0002134e> { _up + 0x36 } IF CC JUMP pcrel (BP)

  12 Target : <0x00021348> { _up + 0x30 }

     Source : <0x00021340> { _up + 0x28 } JUMP.S

  13 Target : <0x00021318> { _up + 0x0 }

     Source : <0x0000e3d2> { _release_console_sem + 0x182 } CALL pcrel

  14 Target : <0x0000e3be> { _release_console_sem + 0x16e }

     Source : <0x0000e2c8> { _release_console_sem + 0x78 } IF CC JUMP pcrel (BP)

  15 Target : <0x0000e29a> { _release_console_sem + 0x4a }

     Source : <0x0000e3ae> { _release_console_sem + 0x15e } IF CC JUMP pcrel (BP)

Stack info:

SP: [0x001d1cfc] <0x001d1cfc> /* kernel dynamic memory */

FP: (0x001d1e68)

Memory from 0x001d1cf0 to 001d2000

001d1cf0: 00000018  001d1cfc  00000018 [001bd8e8] 0002cc00  001c06e0  010702e0  00000006

001d1d10: 00000018  00000000  0002cd26  001c06e0  00000000  00000001  00000000  0002d6a2

001d1d30: 001c06e0  001d0000  001d0000  010702e0  00000018  00000000  ffffe000  001be308

001d1d50: 001abcb0  00012166 <ffa00220> 001d0000  00000018  001d1ed8  00000031  2fec287b

001d1d70: 00000000  ffa00bee  00000104  00000202  2fec6166  00000000  000004e2  000121fe

001d1d90: 001d0000  00000000  00000000  0140a000  01e7dbd2  000121fe  000122c4  0000000b

001d1db0: 02002000  0000bf8c  ffa012b0  0000bf70  ffa012ae  00000000  00000000  00006ee6

001d1dd0: 00000000  00246ec2  00000000  00000000  7ffff000  000000c0  00000137  00000000

001d1df0: 00000000  00000000  00000000  0000005b  00001802  00000001  fffffffc  00000006

001d1e10: 00000003  01470b7c  0129bea4  001d2000  001abcb0  001d0000  001d0000  001d0000

001d1e30: 00000000  001bd8e8  001c2bc8  00000006  00000202  00000000  0000000a  001d1ea4

001d1e50: 00000100  001d0000  0000ffff  0000ffff  001c2bc8  00000006 (00000000)<0002bd1e>

001d1e70: 001d1ed4  00000000  0002d6a2  001c0140  001a5258  000122c4  001d0000  001d0000

001d1e90: 001d0008  00000006  00000000  00000000  ffffe000 <ffa00220> 001d0000  00000006

001d1eb0: ffa00250  00000600  00000000  00000000  ffa00bee  00000002  00000000  00000000

001d1ed0: 00000000  00000000  ffa00144  00008050  00000000  00000000  0140a000  01e7dbd2

001d1ef0: ffa00144 <ffa00180> 00000006  02002020  000a975c  ffa012b0  000a9728  ffa012ae

001d1f10: 00000000  00000000  00000331  00000000  000009dc  00000000  00000000  7ffff000

001d1f30: 000000c0  00000137  00000000  00000000  00000000  00000000  0000005b  00001802

001d1f50: 00000001  fffffffc  00000006  00000003  01470b7c  0129bea4  001d2000  001a5258

001d1f70: ffa00120  001d0000  001d0008  001bd8e8  001d0000  ffa008d4  ffa00120  00000000

001d1f90: 00000000  00000000  00000000  00000000  00000000  0000ffff  0000ffff  ffa008d4

001d1fb0: 00000006  001eaebc  00000000  00000000  001d2000  001d268a  001ae4dc  001a5004

001d1fd0: 00000000  001eaebc  00000000  001e84f4  001a46e4  0000001c  001d2210  001eaebc

001d1ff0: 001dc422  00000000  00000000  ffb00000

Return addresses in stack:

    address : <0xffa00220> { _asm_do_IRQ + 0x40 }

   frame  1 : <0x0002bd1e> { _handle_IRQ_event + 0x32 }

    address : <0xffa00220> { _asm_do_IRQ + 0x40 }

    address : <0xffa00180> { _cpu_idle + 0x2c }

handlers:

[<000d82d4>] (_bfin_mac_interrupt+0x0/0x58)

Disabling IRQ #24

 

> (try booting with the "irqpoll" option)

 

Isn't that this part of configuration? ->

 

static struct bfin_phydev_platform_data bfin_phydev_data[] = {

        {

                .addr = 1,

                .irq = PHY_POLL, // IRQ_MAC_PHYINT

        },

};

 

I tried it with Blackfin Linux 2010R1-RC3.

TranslateQuoteReplyEditDelete

 

 

2011-03-28 12:46:57     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Mike Frysinger (UNITED STATES)

Message: 99371   

 

did you register the GPIO_PH12 interrupt handler ?

QuoteReplyEditDelete

 

 

2011-03-28 13:05:16     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Robert Wimmer (GERMANY)

Message: 99372   

 

Piuuh, sorry for my lack of knowledge: Not explicitely!

 

I just followed these instructions:

 

  docs.blackfin.uclinux.org/doku.php?id=linux-kernel:drivers:gpio-keys&s[]=gpio&s[]=keys

 

Where do I have to do that? Any references on that existing?

TranslateQuoteReplyEditDelete

 

 

2011-03-28 13:11:39     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Mike Frysinger (UNITED STATES)

Message: 99373   

 

all you need to do is add the platform resources to your boards file and enable the driver.  then make sure said driver is correctly loaded at runtime.

 

look at /proc/interrupts and /proc/gpio to make sure that the pin has been claimed correctly.

QuoteReplyEditDelete

 

 

2011-03-28 13:21:44     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Robert Wimmer (GERMANY)

Message: 99374   

 

Ah! Ok! Thanks!

 

Yes, I did! This is an excerpt from my boards file:

 

#if defined(CONFIG_KEYBOARD_GPIO) || defined(CONFIG_KEYBOARD_GPIO_MODULE)

#include <linux/input.h>

#include <linux/gpio_keys.h>

 

static struct gpio_keys_button bfin_gpio_keys_table[] = {

    {BTN_0, GPIO_PH12, 0, "gpio-keys: BTN_0", EV_KEY},

};

 

static struct gpio_keys_platform_data bfin_gpio_keys_data = {

    .buttons        = bfin_gpio_keys_table,

    .nbuttons       = ARRAY_SIZE(bfin_gpio_keys_table),

};

 

static struct platform_device bfin_device_gpiokeys = {

    .name      = "gpio-keys",

    .dev = {

        .platform_data = &bfin_gpio_keys_data,

    },

};

#endif

 

And here:

 

root:~> cat /proc/interrupts

  6:     182837      CORE  Blackfin CoreTimer

16:         24      INTN  i2c-bfin-twi

18:          0      INTN  BFIN_UART_RX

19:         45      INTN  BFIN_UART_TX

24:     100000      INTN  EMAC_RX

26:          0      INTN  Blackfin GPTimer0

94:          0      GPIO  gpio-keys: BTN_0

NMI:          0      CORE  Non Maskable Interrupt

Err:          0

 

 

And that:

 

 

 

root:~> cat /proc/gpio

GPIO_0:         bfin-uart               Peripheral

GPIO_1:         bfin-uart               Peripheral

GPIO_10:        mmc_spi                 Peripheral

GPIO_11:        bfin-spi                Peripheral

GPIO_12:        bfin-spi                Peripheral

GPIO_13:        bfin-spi                Peripheral

GPIO_32:        bfin_mac                Peripheral

GPIO_33:        bfin_mac                Peripheral

GPIO_36:        bfin_mac                Peripheral

GPIO_37:        bfin_mac                Peripheral

GPIO_38:        bfin_mac                Peripheral

GPIO_40:        bfin_mac                Peripheral

GPIO_41:        bfin_mac                Peripheral

GPIO_44:        gpio-irq94 *            GPIO INPUT

GPIO_46:        bfin_mac                Peripheral

GPIO_47:        bfin_mac                Peripheral

GPIO_48:        bfin_mac                Peripheral

GPIO_49:        bfin_mac                Peripheral

GPIO_50:        i2c-bfin-twi            Peripheral

GPIO_51:        i2c-bfin-twi            Peripheral

GPIO_59:        mtd_dataflash           Peripheral

 

 

 

And at last an excerpt from the boot messages:

 

[...]

 

bfin-gpio: GPIO 44 is already reserved by BFIN-GPIO! (Documentation/blackfin/bfin-gpio-notes.txt)

input: gpio-keys as /devices/platform/gpio-keys.0/input/input0

[...]

 

 

 

Ah! I almost forgot:

 

root:~> ls -l /dev/input/event0

crw-rw-r--    1 root     root       13,  64 Jan  1 00:00 /dev/input/event0

TranslateQuoteReplyEditDelete

 

 

2011-03-28 13:26:33     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Robert Wimmer (GERMANY)

Message: 99375   

 

I also forgot to mention that "gpio_keys" works fine if I remove the "bfin_mac" driver.

TranslateQuoteReplyEditDelete

 

 

2011-03-28 14:03:40     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Robert Wimmer (GERMANY)

Message: 99376   

 

Ok, uClinux-dist 2010R1-RC5 shows the same errors in addition to a "NullPointerException" that is caused by "current_rx_ptr" being NULL. My hacked solution is (diff to original 2010R1-RC5):

 

--- ../uClinux-dist/2010R1-RC5/linux-2.6.x/drivers/net/bfin_mac.c       2010-09-06 09:21:59.000000000 +0200

+++ linux-2.6.x/drivers/net/bfin_mac.c  2011-03-28 20:02:23.000000000 +0200

@@ -1177,8 +1177,13 @@

        struct net_device *dev = dev_id;

        int number = 0;

 

+  if (NULL == current_rx_ptr)

+  { goto l_return; }

+

get_one_packet:

        if (current_rx_ptr->status.status_word == 0) {

+               u16 irq_status;

+

                /* no more new packet received */

                if (number == 0) {

                        if (current_rx_ptr->next->status.status_word != 0) {

@@ -1186,9 +1191,17 @@

                                goto real_rx;

                        }

                }

-               bfin_write_DMA1_IRQ_STATUS(bfin_read_DMA1_IRQ_STATUS() |

-                                          DMA_DONE | DMA_ERR);

-               return IRQ_HANDLED;

+l_return:

+               irq_status = bfin_read_DMA1_IRQ_STATUS();

+               if (irq_status & (DMA_DONE | DMA_ERR))

+               {

+                       bfin_write_DMA1_IRQ_STATUS(DMA_DONE | DMA_ERR);

+                       return IRQ_HANDLED;

+               }

+               else

+               {

+      return IRQ_NONE;

+               }

        }

 

real_rx:

 

 

But the  "irq 24: nobody cared (try booting with the "irqpoll" option)" still exists. Simply adding "irqpoll" to the bootargs (which is not really a solution) does NOT help...

TranslateQuoteReplyEditDelete

 

 

2011-03-28 14:37:15     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Mike Frysinger (UNITED STATES)

Message: 99379   

 

when does the error show up ?  immediately ?  or only when you press the button ?

QuoteReplyEditDelete

 

 

2011-03-29 02:29:12     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Robert Wimmer (GERMANY)

Message: 99397   

 

Sorry to answer this late (that's it with the time differences ) and thx for your efforts!

 

The 'irq 24: nobody cared (try booting with the "irqpoll" option)' error shows up if PH12 causes the interrupt. I'm just speculating: It seems that bfin_mac awaits IRQ24 to be handled but the interrupt is actually thrown by PH12.

TranslateQuoteReplyEditDelete

 

 

2011-03-29 02:36:29     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Mike Frysinger (UNITED STATES)

Message: 99400   

 

hmm, in looking at the code a bit more, you might have to add IRQF_SHARED to the flags field of request_irq(IRQ_MAX_RX)

QuoteReplyEditDelete

 

 

2011-03-29 02:40:44     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Mike Frysinger (UNITED STATES)

Message: 99401   

 

and if that doesnt help, we might just have to have a developer look at an actual system.  trouble is that i dont know of any ADI hardware atm that has a BF537, RMII, and PH12 pulled out to poke.

 

a bit annoying, but the core Blackfin interrupt code atm only supports mask A with GPIOs.  it'd be nice if we had a way of picking mask B, but i dont know how feasible that is atm.  if you could route to mask B, it'd make the issue moot for you as the bfin_mac driver doesnt use the MAC TX int, so they're be no contention.

QuoteReplyEditDelete

 

 

2011-03-29 03:02:54     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Robert Wimmer (GERMANY)

Message: 99403   

 

Ah , I hadn't expressed myself clearly about my speculations: What I meant is: I think that IRQ 24 needs to get the IRQ_HANDLED return value at the same time as IRQ 94 awaits IRQ_NONE from "bfin_mac_interrupt" while IRQ 94 has to be handled by "gpio_keys". Hmmm, seems a little bit tricky...

 

How how to realize that?

TranslateQuoteReplyEditDelete

 

 

2011-03-29 03:05:38     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Robert Wimmer (GERMANY)

Message: 99404   

 

Uih! Haven't seen you've answered yet! Really fast!!

 

I already tried that with IRQF_SHARED in "bfin_mac_probe" with same results.

 

Yes, it's annoying...

TranslateQuoteReplyEditDelete

 

 

2011-03-29 03:27:34     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Robert Wimmer (GERMANY)

Message: 99419   

 

Just for documentation reasons:

 

 

 

I found following links that sound interesting:

 

 

 

  blackfin.uclinux.org/gf/project/uclinux-dist/forum/?_forum_action=ForumMessageBrowse&thread_id=2015&action=ForumBrowse

 

  blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=775

 

 

 

Digging further...

TranslateQuoteReplyEditDelete

 

 

2011-03-29 03:52:04     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Robert Wimmer (GERMANY)

Message: 99420   

 

Next step:

 

To use IRQ B for PortH pins, modify PORTH_MASKB. In my case this would be:

 

 

 

PORTH_MASKA &= 0x1000

 

PORTH_MASKB |= 0x1000

 

 

 

...further searching for where to manipulate these settings...

TranslateQuoteReplyEditDelete

 

 

2011-03-29 03:52:55     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Robert Wimmer (GERMANY)

Message: 99421   

 

Sorry, typo: correct: PORTH_MASKA &= 0x1000 -> PORTH_MASKA &= ~0x1000

TranslateQuoteReplyEditDelete

 

 

2011-03-29 04:22:09     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Robert Wimmer (GERMANY)

Message: 99422   

 

Intermediate result:

 

I made a dirty hack in:

 

linux-2.6.x/drivers/input/keyboard/gpio_keys.c

 

 

 

static int __devinit gpio_keys_probe(struct platform_device *pdev)

 

[...]

 

    /* get current state of buttons */

    for (i = 0; i < pdata->nbuttons; i++)

        gpio_keys_report_event(&ddata->data[i]);

    input_sync(input);

 

/* HACK */

bfin_write_PORTHIO_MASKA(0x0000);

bfin_write_PORTHIO_MASKA_CLEAR(0x1000);

bfin_write_PORTHIO_MASKB(0x1000);

bfin_write_PORTHIO_MASKB_SET(0x1000);

 

/* /HACK */

 

    device_init_wakeup(&pdev->dev, wakeup);

 

    return 0;

 

 

That's NOT a solution but the 'irq 24: nobody cared (try booting with the "irqpoll" option)' doesn't occur any more. But currently it seems that gpio_keys isn't working properly.

 

I'll post it in here if I found a temporary solution. Keep your fingers crossed for me!

TranslateQuoteReplyEditDelete

 

 

2011-03-30 04:27:18     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Robert Wimmer (GERMANY)

Message: 99460   

 

Just a reminder for me (and for anyone who wants to manipulate IRQ masks):

 

 

 

Excerpt: Interrupt masks are set with:

 

static void bfin_gpio_mask_irq(unsigned int irq);

 

in which a function

 

set_gpio_maska(irq_to_gpio(irq), 0);

 

is called.

 

Also there are other ones that refer to MASKA in following file:

 

linux-2.6.x/arch/blackfin/mach-common/ints-priority.c

 

 

 

I think that's a good point for further research about my problem.

 

If, and only if, I'll be successful with my tests, I'll post a patch (just with a temporary solution) for anyone who COULD be interested in that.

 

 

 

So, thank you very, very, very much for your help, Mike and Sonic!!!

 

 

 

Robert

TranslateQuoteReplyEditDelete

 

 

2011-03-30 04:37:45     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Mike Frysinger (UNITED STATES)

Message: 99461   

 

looking at the blackfin irq code a bit more, you can see why port H gpio ints work when you disable the mac driver:

# if defined(BF537_FAMILY) && !(defined(CONFIG_BFIN_MAC) || defined(CONFIG_BFIN_MAC_MODULE))

        case IRQ_MAC_RX:

# endif

 

there is no demuxing of this irq ... it's either always routed to the gpio logic, or it's always routed to the mac driver.  you could try deleting the BFIN_MAC check there and in bfin_demux_gpio_irq.

 

this obviously stems from all the boards ADI has done with the MAC uses MII, not RMII, and so we have no way of testing this.

 

i dont suppose you have a board you'd be willing to lend me if we cant get further ?

QuoteReplyEditDelete

 

 

2011-03-30 08:22:18     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Robert Wimmer (GERMANY)

Message: 99466   

 

Hi Mike,

 

 

 

thank you for your reply! I'm currently still playing around with ints-priority.c with no positive results at the moment. Just removing BFIN_MAC check in the driver (as I understood it's the bfin_mac_interrupt patch from you) and in "bfin_demux_gpio_irq" as well as the check in "init_arch_irq" does currently not improve the behavior. What has changed when I hacked (dirty, dirty... ) something like this in several parts (every time I found "_maska"):

 

  if (IRQ_PH12 == irq)

    set_gpio_maskb(gpionr, 0);

  else

    set_gpio_maska(gpionr, 0);

 

 

is, that this 'irq 24: nobody cared (try booting with the "irqpoll" option)' error doesn't show up anymore. As well as for example:

 

root:~> cat /sys/kernel/debug/blackfin/Port\ I-O/PORTHIO_MASKA

0x0000

root:~> cat /sys/kernel/debug/blackfin/Port\ I-O/PORTHIO_MASKB

0x1000

 

 

shows me that ints-priority.c definitely HAS to be the (at least the utmost) crux of the matter.

 

But I'm not yet fully through with my playing around as well as I haven't tested it with 2010R1-RC5 (just with 2010R1-RC3 at this moment) also.

 

 

 

<quote>i dont suppose you have a board you'd be willing to lend me if we cant get further ?</quote>

 

Thx for this offer!

 

I DO have something you could test with!

 

You can send the address, where I should send the board to, to my E-Mail account.

 

Robert

TranslateQuoteReplyEditDelete

 

 

2011-03-30 09:59:33     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Robert Wimmer (GERMANY)

Message: 99467   

 

Ok, again just for documentation:

 

So far I could verify that the MASK registers are set correctly (if I haven't overlooked something) as well as an interrupt is thrown at PH12 (I set "Kernel hacking -> Debug MMRs" to get "/sys/kernel/debug/blackfin" info):

 

root:~> cat /sys/kernel/debug/blackfin/Port\ I-O/PORTHIO

0x3000

root:~> echo 0x1000 > /sys/kernel/debug/blackfin/Port\ I-O/PORTHIO_CLEAR && cat /sys/kernel/debug/blackfin/Port\ I-O/PORTHIO

0x2000

root:~> cat /sys/kernel/debug/blackfin/Port\ I-O/PORTHIO

0x3000

root:~> echo 0x1000 > /sys/kernel/debug/blackfin/Port\ I-O/PORTHIO_CLEAR && cat /sys/kernel/debug/blackfin/Port\ I-O/PORTHIO

0x2000

root:~> cat /sys/kernel/debug/blackfin/Port\ I-O/PORTHIO

0x3000

root:~> cat /sys/kernel/debug/blackfin/Port\ I-O/PORTHIO_MASKA_CLEAR

0x0000

root:~> cat /sys/kernel/debug/blackfin/Port\ I-O/PORTHIO_MASKA_SET

0x0000

root:~> cat /sys/kernel/debug/blackfin/Port\ I-O/PORTHIO_MASKB_SET

0x1000

root:~> cat /sys/kernel/debug/blackfin/Port\ I-O/PORTHIO_MASKB_CLEAR

0x1000

root:~> cat /sys/kernel/debug/blackfin/Port\ I-O/PORTHIO_BOTH

0x1000

root:~> cat /sys/kernel/debug/blackfin/Port\ I-O/PORTHIO_EDGE

0x1000

 

 

That an interrupt is thrown but not handled by the kernel shows me that I have not "mounted" the interrupt correctly to the event framework. What's a little bit irritating is that "bfin_demux_gpio_irq" seems not to be called. At least I cannot see the debug messages I added. Perhaps I'm simply doing something wrong. Now further investigating...

 

Why am I spamming this board with ongoing procedures? - Because several times I searched for something and often missed some valuable steps for searching while other posts contained things that were useful to me though they had not directly any connection to my problems. Hopefully my postings can help other people in ANY way. Additionally it's a good reference for me...

TranslateQuoteReplyEditDelete

 

 

2011-03-31 05:09:31     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Robert Wimmer (GERMANY)

Message: 99472   

 

Again just a reminder:

 

Forgot to post this "evidence" of IRQ B to be thrown!

 

root:~> cat /sys/kernel/debug/blackfin/System\ Interrupt\ Controller\ Register\ File/SIC_ISR

0x00040000

 

 

Bit 18 of SIC_ISR:

 

DMA2 (MAC TX), Port H

Interrupt B Interrupt

 

According to   www.surveyor.com/blackfin/Blackfin-HRM.pdf, chapter 4, Figure 4-9. System Interrupt Status Register.

TranslateQuoteReplyEditDelete

 

 

2011-04-15 03:46:30     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Mike Frysinger (UNITED STATES)

Message: 99878   

 

the good news is that with your board, ive been able to figure things out (i think).  the bad news is that i did a bit of cleaning up/refactoring in the process, so i dont know how easy it'll be to drop this into 2010R1.  chances are, you'll want to do a custom rip (but that shouldnt be too hard).

 

root:/> grep ^board.name /proc/cpuinfo

board name      : DNP/5370

 

root:/> ping -c 1 192.168.1.2

PING 192.168.1.2 (192.168.1.2): 56 data bytes

64 bytes from 192.168.1.2: seq=0 ttl=64 time=4.000 ms

 

--- 192.168.1.2 ping statistics ---

1 packets transmitted, 1 packets received, 0% packet loss

round-trip min/avg/max = 4.000/4.000/4.000 ms

 

root:/> event_test /dev/input/event0

Input driver version is 1.0.1

Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100

Input device name: "gpio-keys"

Supported events:

  Event type 0 (Sync)

  Event type 1 (Key)

    Event code 256 (Btn0)

Testing ... (interrupt to exit)

Event: time 1167609628.396000, type 1 (Key), code 256 (Btn0), value 0

Event: time 1167609628.396000, -------------- Report Sync ------------

Event: time 1167609628.396000, type 1 (Key), code 256 (Btn0), value 1

Event: time 1167609628.396000, -------------- Report Sync ------------

Event: time 1167609628.396000, type 1 (Key), code 256 (Btn0), value 0

Event: time 1167609628.396000, -------------- Report Sync ------------

Event: time 1167609628.396000, type 1 (Key), code 256 (Btn0), value 1

Event: time 1167609628.396000, -------------- Report Sync ------------

QuoteReplyEditDelete

 

 

2011-04-15 15:25:14     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Mike Frysinger (UNITED STATES)

Message: 99894   

 

ive done a bit more testing/cleanups and committed things to svn trunk

 

the key commit is svn rev 9854

QuoteReplyEditDelete

 

 

2011-04-20 07:46:05     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Robert Wimmer (GERMANY)

Message: 100041   

 

Many thanks Mike! I'll play around with it!!

TranslateQuoteReplyEditDelete

 

 

2011-04-21 07:59:16     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Robert Wimmer (GERMANY)

Message: 100083   

 

Hmmm... ok! I'm stuck.

 

You're looking to me like a wizard, Mike.

 

How did you manage to get both drivers working together?

 

> so i dont know how easy it'll be to drop this into 2010R1

 

Yes, that's not really good news... when even you imply this could be tricky...

 

> chances are, you'll want to do a custom rip

 

That would be ok for me. Of course a (more) generic setting would somehow be nice but... don't know if it's worth getting ripped off a leg for that.

 

Again thank you very much for putting that much effort into my little ailments!

 

grz:rob

TranslateQuoteReplyEditDelete

 

 

2011-04-22 03:39:00     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Mike Frysinger (UNITED STATES)

Message: 100121   

 

see if the attached patch for 2010R1 helps

 

bf537-demux-mac-rx.patch

QuoteReplyEditDelete

 

 

2011-04-26 02:47:39     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Robert Wimmer (GERMANY)

Message: 100154   

 

Thx, Mike!!! I'll try and report!

TranslateQuoteReplyEditDelete

 

 

2011-04-26 09:48:22     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Robert Wimmer (GERMANY)

Message: 100171   

 

Sooo, I really don't want to bother you (though I surely do ) but: Nope, doesn't work for me. Neither with 2010R1-RC3 nor 2010R1-RC5 nor 2010R1 SVN snapshot rev. 10140.

 

Without any further modifications, Kernel crashes because inta_irq, which is 24 in bfin_mac case, isn't caught by bfin_demux_gpio_irq (arch/blackfin/mach-common/ints_priority.c) anymore (IRQ_MAC_RX now is 106). Adding an additional case to the demuxer with IRQ_PH_INTA_MAC_RX solves the crash problem (and ethernet is working, but only if that case sets irq = IRQ_PH0, with inta_irq == 24 -> irq = IRQ_PH12 kernel crashes again), but the gpio_keys driver's IRQ still is neither thrown (by the framework as it seems) nor caught (for sure).

 

I tried that both without the modifications posted in this thread before (bfin_mac_interrupt patch and set_gpio_maska/b mods) and with them. Always the same result: gpio_keys doesn't like me. :'(

 

Are there any [additional] settings I have to manipulate? Surely they are but... blind as I am... Which settings do I have to take care of?

TranslateQuoteReplyEditDelete

 

 

2011-05-02 16:54:40     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Mike Frysinger (UNITED STATES)

Message: 100347   

 

sorry for the delay.  the patch i posted missed changing one line.  try the attached one ... this works for me on 2010R1 with your board.

 

bf537-demux-mac-rx-v2.patch

QuoteReplyEditDelete

 

 

2011-05-03 00:36:18     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Robert Wimmer (GERMANY)

Message: 100352   

 

> sorry for the delay.

 

Doesn't matter!

 

Many thanks for your efforts! I'll test and report.

TranslateQuoteReplyEditDelete

 

 

2011-05-03 02:36:55     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Robert Wimmer (GERMANY)

Message: 100355   

 

First report:

 

Looks good! gpio_keys_report_event now is called (verified that with "printk") but event_test /dev/input/event0 currently isn't working. But that doesn't mean anything (...that event_test isn't working...-> perhaps I made some mistakes). I'll make some further tests and report! Thx again, Mike!!

TranslateQuoteReplyEditDelete

 

 

2011-05-04 02:56:36     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Robert Wimmer (GERMANY)

Message: 100401   

 

Last report:

 

Hooray!!! It works fine!!!

 

The cause, why event_test wasn't working at first, was that I (so I assume) let PH12 jiggle too fast. Letting it high for just 8.4 us seems not to be working for the input event handling via gpio_keys. For me this case is closed.

 

So again: Thank you very, very much for your efforts, Mike!

TranslateQuoteReplyEditDelete

 

 

2011-05-04 03:04:36     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Mike Frysinger (UNITED STATES)

Message: 100402   

 

there might be debouncing logic in gpio_keys to squelch "noise".  i'd have to do some research into the matter.

 

glad things are working for you now ... do you want your board back ?  or should i hold onto it in case you have issues in the future ?

QuoteReplyEditDelete

 

 

2011-05-04 08:44:16     Re: Conflicting IRQs: gpio_keys(GPIO_PH12)/bfin_mac(IRQ_MAC_RX)?

Robert Wimmer (GERMANY)

Message: 100418   

 

Hi Mike!

 

> there might be debouncing logic in gpio_keys to squelch "noise".

 

Referring to:   docs.blackfin.uclinux.org/doku.php?id=linux-kernel:drivers:gpio-keys&s[]=input

<quote>Be aware that this driver has no debouncing as a default property.</quote>

 

no debounce is made until explicitely configured. I also set the debounce configuration of gpio_keys in the board file to "0" to ensure that. Didn't change anything. I think the driver is just to slow to recognize the falling edge withing 8.4 microseconds. But that doesn't matter after all. My application won't have to be THAT responsive. I'll try that but I can imagine that it'll just work as I need.

 

> i'd have to do some research into the matter.

 

I think there's no need for that but many thanks for that offer! I'll bother you if I'll have problems.

 

> glad things are working for you now ...

 

Me, too!

 

> do you want your board back ?  or should i hold onto it in case you have issues in the future ?

 

Currently there is no urgent need for me to getting the board back. If that'll be the case, I'll let you know. So, just keep it for now! In addition to that I won't refrain from asking more stupid questions.

 

Thanks!!!

 

 

grz:rob

Outcomes