Re: [PATCH] irq-dw-apb-ictl: convert to platform device

[Sebastian Hesselbarth]

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@xxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/