On 29/07/15 18:26, nick wrote: > > > On 2015-07-29 11:12 AM, Roger Quadros wrote: >> On 29/07/15 17:08, nick wrote: >>> >>> >>> On 2015-07-29 09:52 AM, Roger Quadros wrote: >>>> On 29/07/15 15:13, nick wrote: >>>>> >>>>> >>>>> On 2015-07-29 08:06 AM, Roger Quadros wrote: >>>>>> Tony, >>>>>> >>>>>> On 13/07/15 15:40, Tony Lindgren wrote: >>>>>>> * Roger Quadros <rogerq@xxxxxx> [150713 03:07]: >>>>>>>> Tony, >>>>>>>> >>>>>>>> On 13/07/15 10:10, Tony Lindgren wrote: >>>>>>>>> * Roger Quadros <rogerq@xxxxxx> [150710 05:26]: >>>>>>>>>> Since the Interrupt Events are used only by the NAND driver, >>>>>>>>>> there is no point in managing the Interrupt registers >>>>>>>>>> in the GPMC driver and complicating it with irqchip modeling. >>>>>>>>> >>>>>>>>> I don't think it's a good idea to allow external drivers to >>>>>>>>> tinker directly with GPMC registers. How about just set up GPMC >>>>>>>>> as an irqchip for the edge detection interrupts? >>>>>>>>> >>>>>>>>> I think we already have devices with multiple NAND chips. And >>>>>>>>> there's nothing stopping other drivers from using the edge >>>>>>>>> detection interrupts. >>>>>>>> >>>>>>>> OK. The GPMC_IRQ registers manage 2 NAND specific interrupts >>>>>>>> (terminalcount and fifo) and 'n' WAIT pin edge interrupts. >>>>>>>> >>>>>>>> So we can model this as a irqchip with 'n + 2' interrupts. >>>>>>> >>>>>>> OK >>>>>> >>>>>> For the wait pins irqchip is not sufficient and it needs to be gpiochip >>>>>> with irqchip. Waitpin status can be read from GPIO_STATUS register. >>>>>> >>>>>> Just getting the interrupt is not enough and we want to know if the >>>>>> line is high or low. That is how nand->dev_ready works. >>>>>> >>>>>> How about having 2 IRQ domains? >>>>>> One is irqchip with 2 interrupts (terminalcount and fifo) and second is >>>>>> gpiochip + irqchip for the n wait pins. >>>>>> >>>>>> The nand driver can then be modified to use GPIO to get Read/Busy >>>>>> pin status from the wait pin. >>>>>> >>>>>> cheers, >>>>>> -roger >>>>>> >>>>> Doesn't OMAP boards support shared IRQs and if so why not share them across one >>>>> IRQ domain if possible to save IRQ domains for other hardware that needs its >>>>> own IRQ domain. This is just a suggestion through as I don't have the hardware >>>>> spec sheet on me Roger. >>>> >>>> IRQ domain is a virtual abstraction introduced to prevent kernel irq number overlapping >>>> in a single flat domain. I don't see what you can save by domain reuse. >>>> Some memory maybe at most. >>>> >>>> Shared interrupt is something totally different but we're trying to add real >>>> hardware interrupts here. Didn't understand what you will share it with. >>>> >>>> cheers, >>>> -roger >>>> >>> My question then is do these hardware interrupts need to be on their own interrupt line >>> for the CPU or can they share a CPU line as my concern is if possible we may be able to >>> save a interrupt line for other use. I known on Intel CPUs this is a very limited resource >>> but not sure on OMAP based boards if not then just avoid my recommendations. >> >> It is like adding an external interrupt controller to expand the number of available >> hardware interrupts. >> This interrupt controller will still use the same GPMC IRQ line to propagate the >> irq event upwards. >> >> cheers, >> -roger >> > That was my other suggestion for IRQ issues. Would you mind sending me a link to a spec sheet so > I can review your patches better as you stated you wanted me to do this for you. Sure. You can pick up any of omap3/4 or 5 Technical Reference Manuals. e.g. omap5 TRM is here http://www.ti.com/product/OMAP5432/technicaldocuments cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
