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

[Vineet Gupta]

On Wednesday 04 March 2015 05:30 PM, Sebastian Hesselbarth wrote:
> 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)

Not quite, we only have 1 DW APB intc (see ASCII art below)

Ethernet or xyz device IRQ -> APB INTC -> GPIO line -> APB GPIO -> ARC Core 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.

Above is part 1 of setup - although to give you complete picture (perhaps
orthogonal to this exact issue), we have another GPIO intc at cpu level which is
used to wire up the cpu local peripherals (e.g. debug uart). Sounds a bit crazy,
but it is what it is.

        ---------------------
        |  snps,arc700-intc |
        ---------------------
          | #7          | #15
-------------------  ------------------
| DW GPIO INTC    |  | DW GPIO INTC   |
-------------------  ------------------
         |                       |        
         |                    [ Debug UART on cpu card ]
         |
--------------------    
|  DW APB INTC (MB)|
--------------------
  |      |     |  |
[eth] [uart] [... other perip on Main Board]


Note the APB INTC to GPIO intc is more like a single wire pass thru.


> 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.

Yeah I don't like this approach - we fix it now for good !

>
> 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 ;)

Lets see :-)

Thx,
-Vineet
--
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/