On April 27, 2012 19:02:35 Mark Brown wrote: > On Fri, Apr 27, 2012 at 11:28:28AM -0400, Mark Asselstine wrote: > > On April 26, 2012 22:52:58 Russell King - ARM Linux wrote: > > > What is the effect when the supplied IRQ does not have a mapping to > > > a > > > GPIO - or it _does_ by way of a badly coded irq_to_gpio() function > > > but that GPIO is not the correct one. > > > > > > There is no prevention against endlessly looping, so it could cause > > > a > > > system lockup. > > > > Unfortunately the commit [b1148fd4 mfd: fix pcap irq bottom handler > > ] which modified things to loop as long as the interrupt is asserted > > didn't supply much information regarding the behavior they were trying > > to achieve/fix nor what would be the consequence of bailing earlier. > > The usual reason for this pattern is to simulate level triggered IRQs on > an edge triggered interrupt controller. Makes sense. OK. I want to help here with a complete fix but it has been a while since I have waded into SPI and ARM initialization so here are some stumbling blocks for me. If I first fix the build issue by adding 'int gpio_num' to the pcap_platform_data and made use of pdata->gpio_num in place of irq_to_gpio() in pcap_isr_work(). Now to set gpio_num. In the board .c file I would assume the goal would be to create the necessary structs to set gpio_num for "ezx-pcap" and pass them to spi_register_board_info(). Right? But should I expect to already see some of this infrastructure in place already? Doesn't the "ezx-pcap" device already have to be defined somewhere, to have irq_base set for example? Or is this coming from firmware? Thanks, Mark A. -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
