Messages in this thread | | | Date | Wed, 04 Mar 2015 13:00:11 +0100 | From | Sebastian Hesselbarth <> | Subject | Re: [PATCH] irq-dw-apb-ictl: convert to platform device |
| |
On 03/04/2015 11:46 AM, Vineet Gupta 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. >>>> [...] >> 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? [...] > > 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.
Vineet, thanks for the clarification. So, above describes the following setup:
APB_INTC->(GPIO line)->APB_GPIO->APB_INTC->(Main INTC)
I see that current early probing of APB_INTC does not fit well into the picture.
> Does that mean if we tweak irq-dw-apb-ictlc.c enough, it could double as driver > for intc component of dw-apb-gpio too ?
Hmm, I am inclined to say that if it is the setup above and not some tweaked hardware you have, we should try to rework the existing drivers to allow the setup.
We could share code of dw-apb-intc and try to distinguish early probed vs late probed devices, but I haven't thought in detail how to achieve this in a clean way.
Another option would be...
[...] >>>> +module_platform_driver(dw_apb_ictl_device_driver); >>> This is too late. If the ictl is needed during early boot, for example >>> on Marvell BG2Q DMP board, we still need to calibrate the delay loop, the >>> kernel will hang at "Calibrating delay loop..."
... to make Berlin use another timer that is not connected to dw-apb-intc slave controller. IIRC, there is a TWD timer in all (current) Berlin SoCs and it is directly connected to the master intc. We'll have to rework (silence) current TWD implementation to be usable on BG2CD UP and I haven't thought about the second clock source, yet.
Also, I admit it will most likely just postpone the general issue to the next SoC.
I'll have to have a deeper look into kernel sources, it has been a while I looked at this in detail. In the meantime, I hope there is somebody else with a better idea ;)
Sebastian
| |