>> Patch 2/3 configures the interrupt type of the board, which (my guess)
>> most people like to see in device_tree / board files. > > No, the driver registers for the interrupt. It's up to the driver to > know what kind of interrupt (edge, level, rising, falling, etc) the > hardware generates. All the board file (or DT) does is tell the driver > where the interrupt is located (ie: which irq line). > > If the hardware generates a rising edge every time and is not > configurable, then it should be hard coded in the driver and not be > configurable. (the mrf24j40 _is_ configurable in this way). Ok, so i would drop the configuration part and hard code the type to edge type rising by passing IRQ_TYPE_EDGE_RISING to the request_irq() call (instead of using irq_set_irq_type()). I would modify patch 3/3 to completely drop the call to disable_irq_nosync() and enable_irq() in the isr / irqwork functions. > I have apparently misunderstood this problem from the very beginning, > and I'm sorry for the extra work I've caused. No problem, one of my goals was to get some deeper understanding of the kernel. This helps :) >> Patch 3/3 changes >> the way the interrupts are handled by the driver. For boards configured >> to level type interrupts we need to disable interrupts until the irqwork >> function is done (else the interrupt would fire multiple times until we >> are done with the work). For boards with edge type interrupts, the >> interrupt shouldn't be disabled because we may miss some interrupts >> while handling the first one. > > When you say boards configured to level type interrupts, what do you > mean? If the driver can configure the interrupt (on the SoC) to detect > rising edge, then why should the driver have to jump through hoops for a > level-interrupt? > > Do you have a board where it's not possible to detect an edge? No, i don't have one. From reading the code with disabling/enabling the interrupts in the interrupt handling I got the impression it was written for level type interrupts. So I made it configurable to not break boards with this setup. I fear this idea was simply wrong, because hard coding it to rising edge interrupts will most likely work for all boards. > I think the problem here may be that since the interrupt type was never > defined in the driver, a default was used which is different on your > board than on Alexander Smirnov's (when he was testing/writing the > driver). That's my guess anyway (and I've been wrong a lot today :) ) I think this is true, extended by the fact, that the raspberry kernel didn't enabled the irq at all without explicitly configuring the irq type. May this be a bug in the raspberry kernel? I will have some hours on the train tomorrow and will try to rework the patches. Thanks, Sascha > > Alan. > >> For patch 3/3 we need to tell the driver how the IRQ is configured. >> Removing the irq_set_irq_type() call from patch 2/3 would force the user >> to configure the irq type twice. Alas there seem to be no >> irq_get_irq_type() function available in the kernel :( >> >> What do you think about it? Maybe I should post it as rfc patch to netdev? >> >> Thanks, >> Sascha >> >>> In the device tree or board file (in your example), you're setting the >>> IRQ type that the board or SoC should expect. This patch sets the IRQ >>> type that the at86rf230 will generate. >>> >>>> I would only add this, if this is really necessary to setup irq_type at >>>> probing time. >>> If you want something other than the default from the at86rf230, then it >>> is necessary. >>> >>> Alan. >>> >>> >>> ------------------------------------------------------------------------------ >>> Everyone hates slow websites. So do we. >>> Make your web apps faster with AppDynamics >>> Download AppDynamics Lite for free today: >>> http://p.sf.net/sfu/appdyn_d2d_mar >>> _______________________________________________ >>> Linux-zigbee-devel mailing list >>> Linux-zigbee-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel >> >> > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > Linux-zigbee-devel mailing list > Linux-zigbee-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
