On 03/13/2013 05:55 PM, Sascha Herrmann wrote: >>> I don't know if this patch is necessary. I think Alan told about this >>> some days ago. In my case I setting my irq_type with a device_tree and I >>> know other boards, which are not using a device_tree, do the same in the >>> boardspecific code file in arch/arm/**/*_board.c. >> The at86rf230 supports generating multiple types of IRQ (eg: rising and >> falling). His patch makes it configurable, in case it's being connected >> to a board or SoC that is not as configurable. > > To be honest, at the moment I'm not sure what would be the "right" > solution here. The patches don't change the way the IRQ are generated by > the rf230, but change the way the driver handle them. The rf230 always > sets the IRQ line to high when a interrupt cause occurs and resets the > line when we read the interrupt status register.
Yes, Alexander is right. I screwed this up. I looked in the email all the way back to 1/15 when you posted this originally, and I completely misunderstood the problem. > 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). I have apparently misunderstood this problem from the very beginning, and I'm sorry for the extra work I've caused. Check in mrf24j40.c where the IRQ_TYPE_EDGE_* flag is passed into request_irq(). > 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? 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 :) ) 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
