Message-ID: <525CF052.4060508@ti.com>
Date:	Tue, 15 Oct 2013 13:05:46 +0530
From:	Sricharan R <r.sricharan@...com>
To:	Santosh Shilimkar <santosh.shilimkar@...com>
CC:	Rob Herring <robherring2@...il.com>, <tglx@...utronix.de>,
	<linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>,
	<linux-doc@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>,
	<linux-omap@...r.kernel.org>, <linus.walleij@...aro.org>,
	<linux@....linux.org.uk>, <tony@...mide.com>, <rnayak@...com>,
	<marc.zyngier@....com>, <grant.likely@...aro.org>,
	<mark.rutland@....com>
Subject: Re: [RFC PATCH 0/6] DRIVERS: IRQCHIP: Add support for crossbar IP

Hi Thomas,

On Tuesday 01 October 2013 08:37 PM, Santosh Shilimkar wrote:
> On Tuesday 01 October 2013 10:53 AM, Rob Herring wrote:
>> On 10/01/2013 08:57 AM, Santosh Shilimkar wrote:
>>> On Tuesday 01 October 2013 09:48 AM, Rob Herring wrote:
>>>> On 10/01/2013 06:13 AM, Sricharan R wrote:
>>>>> Hi,
>>>>>
>>>>> On Monday 30 September 2013 08:39 PM, Rob Herring wrote:
>>>>>> On 09/30/2013 08:59 AM, Sricharan R wrote:
>>>>>>> Some socs have a large number of interrupts requests to service
>>>>>>> the needs of its many peripherals and subsystems. All of the interrupt
>>>>>>> requests lines from the subsystems are not needed at the same
>>>>>>> time, so they have to be muxed to the controllers appropriately.
>>>>>>> In such places a interrupt controllers are preceded by an
>>>>>>> IRQ CROSSBAR that provides flexibility in muxing the device interrupt
>>>>>>> requests to the controller inputs.
>>>>>>>
>>>>>>> This series models the peripheral interrupts that can be routed through
>>>>>>> the crossbar to the GIC as 'routable-irqs'. The routable irqs are added
>>>>>>> in a separate linear domain inside the GIC. The registered routable domain's
>>>>>>> callback are invoked as a part of the GIC's callback, which in turn should
>>>>>>> allocate a free irq line and configure the IP accordingly. So every peripheral
>>>>>>> in the dts files mentions the fixed crossbar number as its interrupt. A free
>>>>>>> gic line for that gets allocated and configured when the peripheral's interrupt
>>>>>>> is mapped.
>>>>>>>
>>>>>>> The minimal crossbar driver to track and allocate free GIC lines and configure the
>>>>>>> crossbar is added here, along with the DT bindings.
>>>>>> Seems like interrupt-map property is what you need here.
>>>>>>
>>>>>> http://devicetree.org/Device_Tree_Usage#Advanced_Interrupt_Mapping
>>>>>>
>>>>>> Versatile Express also has an example.
>>>>>    OK, but the idea was not to tie up the crossbar<->interrupt numbers at the
>>>>>    DTS level, but to assign it dynamically during runtime. This was one of the
>>>>>   comments that came up with first crossbar support patches, which was assigning a
>>>>>   interrupt line to crossbar number in the DTS and setting it up in crossbar probe.
>>>> Is there an actual usecase on a single h/w design that you run out of
>>>> interrupts and it is a user decision which interrupts to use?
>>>>
>>> Yes. There are 240 peripheral interrupts connected out of which 160 can
>>> be used in this specific case. 
>> Yes, I understand the SOC connections. That does not answer my question.
>> The 240 interrupts are likely to be limited to fewer by board design,
>> pinmuxing, etc.
>>
> yes limited by different board designs ...
>
>> How do you handle the 161st interrupt request? Will never happen? Just
>> rely on the random driver probe ordering?
>>
> Well the board dts are expected to provide the peripheral support info to optimise it.
> If a board actually has more than 160 peripherals available then in that
> case the 161 interrupt will not be mapped. 
>  
>>>> You could fill in the interrupt-map at run-time. It would have to be
>>>> early (bootloader or early kernel init) and can't be at request_irq time.
>>>>
>>> Well all options are tried before coming up to the $subject solution.
>>> It was suggested by Thomas in the last review.
>>>  
>>>>>     https://lkml.org/lkml/2013/7/18/416
>>>>>
>>>>>    Since this approach of assigning in DTS was opposed, we moved to IRQCHIP and
>>>>>    that did not go as well. Finally was asked to handle this as a part of GIC driver with
>>>>>    a separate domain.
>>>>>    
>>>>>   http://www.spinics.net/lists/linux-omap/msg97085.html
>>>> This has nothing to do with the GIC, so it does not belong there.
>>>>
>>> Well the router makes connections from peripheral to GIC. Thomas can
>>> better explain it but I think since its doing irq routing for GIC on
>>> a given hardware, I don't see any issue having some generic map/unmap
>>> function in GIC. The actual implementation is still outside of GIC.
>> I read Thomas' reply as don't put this crap in his code.
>>
> That was for the IRQCHIP based approach and as part of that review
> Thomas suggested why not irqdomain and suggested a prototype code
> as well.
>  
>> You can call it generic, but it is not. It is specific to the GIC and
>> looks like an abuse of irqdomains to me. Look where the function
>> declaration for register_routable_domain_ops is.
>>
> I am not sure why you call it abuse of irqdomain since the map/unmap
> are exactly the interfaces where the logical to physical irq
> connections are made. Look at existing GIC code as well. I still
> let Thomas give his expert comment whether it is abusive because it
> it was, am sure he wouldn't have suggested that.
  Is this inline with what you were suggesting and
  is this approach fine ?

Regards,
 Sricharan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists