Messages in this thread | | | Date | Mon, 9 Mar 2015 17:03:26 +0100 | Subject | Re: [PATCH] irq-dw-apb-ictl: convert to platform device | From | Linus Walleij <> |
| |
On Wed, Mar 4, 2015 at 11:46 AM, Vineet Gupta <Vineet.Gupta1@synopsys.com> wrote: > On Wednesday 04 March 2015 02:30 PM, Sebastian Hesselbarth wrote: >> On 04.03.2015 04:11, Jisheng Zhang wrote: >>> On Tue, 3 Mar 2015 06:56:59 -0800 >>> Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote: >>>> This allows utilization of probe deferral if master interrupt controller >>>> was not yet probed. >>>> >>>> In my case there's an DW APB GPIO configured as interrupt controller >>>> which is a master for DW APB INTC. >>>> >>>> Interrupt controller sub-node of DW APB GPIO gets parsed only on DW APB >>>> GPIO real probe - before that slave interrupt controllers cannot resolve >>>> its master connection which lead to failures on probes of devices that >>>> use DW APB INTC as its interrupt controller. >> Alexey, >> >> thanks for the input, but the point is not to break existing users which >> your patch clearly does. >> >> Just to get this straight for me, you are using DW_APB_INTC as a _slave_ >> interrupt controller of DW_APB_GPIO _master_ interrupt controller? Is >> this a fictional setup to test your IP or is it a real world example? >> >> IMHO, if the setup is real, i.e. an APB_INTC hooked up to a GPIO >> upstream-wise, you should think of a new driver for an externally >> connected but APB bus accessible (???) interrupt controller. If it >> is rather some extension of the GPIO controller you should amend >> dw_apb_gpio.c instead. >> >> Sorry, but I cannot really wrap my head around that specific setup... >> >> Sebastian > > Hi Sebastian, > > I think Alexey is away for rest of the week so let me fill in some of the details. > The setup is indeed real and part of ARC SDP (Software Development Platform) and > these patches are precursor to getting that merged upstream. > > SDP has a split main board / cpu card design, where both cards have an intc of own > to mux the irqs from respective levels. MB has a DW APB intc which sends a single > uplink to DW GPIO intc on cpu card, which in turn hooks up to ARC core. In the > final design, the board guys decided that this GPIO intc will act as a pass thru > for the downstream IRQ, but we still need to clear the interrupt on it etc - hence > it needs to properly show up in the cascaded intc hierarchy.
We have hierarchical IRQ domains in the Linux kernel since a while back and I think that is what you want here.
I am looking at some way to have any GPIOLIB_IRQCHIP turn up as a proper hierarchical irqchip but that means getting at the domain from an IRQ number, not just knowing it from context so have not gotten around to fixing this yet...
We have several cascaded irqchip drivers doing this already however, look in drivers/irqchip/irq-vic.c function vic_init_cascaded() for example. A cascaded GPIO-based irqchip is no different for what I can tell. Just call irq_set_chained_handler() and be happy.
Well there is also irq_set_parent(), which the gpiolib irqchip calls and which is helpful for the situation where the irq needs to be resent (see kernel/irq/resend.c).
I set this also for the cascaded irqs on GPIOLIB_IRQCHIP but don't know for sure if it's needed.
By the way please if you have time convert the DWAPB driver to GPIOLIB_IRQCHIP so we can solve problems like this in the GPIO core and need not deal with it in a myriad of drivers...
Yours, Linus Walleij
| |