[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <521765DC.2000609@ti.com>
Date: Fri, 23 Aug 2013 09:38:36 -0400
From: Santosh Shilimkar <santosh.shilimkar@...com>
To: Sekhar Nori <nsekhar@...com>
CC: Sricharan R <r.sricharan@...com>, Rajendra Nayak <rnayak@...com>,
Nishanth Menon <nm@...com>,
Russell King - ARM Linux <linux@....linux.org.uk>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
Tony Lindgren <tony@...mide.com>,
Linus Walleij <linus.walleij@...aro.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Felipe Balbi <balbi@...com>,
Grant Likely <grant.likely@...retlab.ca>,
Thomas Gleixner <tglx@...utronix.de>,
Linux-OMAP <linux-omap@...r.kernel.org>,
"devicetree-discuss@...ts.ozlabs.org"
<devicetree-discuss@...ts.ozlabs.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 1/3] misc: Add crossbar driver
On Friday 23 August 2013 04:14 AM, Sekhar Nori wrote:
> On Friday 23 August 2013 12:23 PM, Sricharan R wrote:
>> On Friday 23 August 2013 12:06 PM, Sekhar Nori wrote:
>>> On Friday 23 August 2013 11:41 AM, Sricharan R wrote:
>>>> Hi,
>>>> On Friday 23 August 2013 10:17 AM, Rajendra Nayak wrote:
>>>>> On Thursday 22 August 2013 05:03 PM, Sricharan R wrote:
>>>>>> maps crossbar number<-> to interrupt number and
>>>>>> calls request_irq(int_no, crossbar_handler,..)
>>>>> So will this mapping happen based on some data passed from DT or
>>>>> just based on whats available when the device does a request_irq()?
>>>>>
>>>>> If its based on whats available then I see an issue when you need
>>>>> to remap something thats already mapped by default (and not used)
>>>>> since you run out of all free ones.
>>>> Yes, when done based on what is available then there is a
>>>> problem when we run out of free ones because we do not
>>>> know which one to replace. I was thinking of something like
>>>> this,
>>>> 1) DT would give a list of all free ones, and also if some are
>>>> mapped as default and not used, mark those also as free.
>>>>
>>>> 2) While mapping see if it has a default mapping and use it.
>>>> otherwise, pick from free list.
>>> Since the entire DT is available to you at boot time, you should be able
>>> to find each node where interrupt-parent = <&crossbar> and then allocate
>>> one of 0-160 GIC interrupt numbers for that node, no? Where would there
>>> be a need for default mapping and remapping? From one the mails in the
>>> thread the crossbar is completely flexible - any of the 320 crossbar
>>> interrupts can be mapped to any of the 160 GIC interrupts.
>>>
>>> Any GIC interrupts left after this boot-time scan can be added to an
>>> unused list for use with runtime DT fragments (when that support comes).
>>>
>>> Sorry if I misunderstood, but above proposal sounds like maintaining a
>>> separate free interrupt lines list in DT. That will quickly go out of sync.
>> Say, peripheral x uses crossbar 1 and specifies this in DT.
>> During boot crossbar 1 gets mapped int 10. So if by default
>> some other crossbar has its interrupt mapped to 10,
>> then it should be removed. Instead clear all crossbar registers
>> once and mark all as free, then allocate only during request.
>> Correct ?. In this the free no need to maintain any list.
>
> Right, so in my suggestion there is nothing like a "default mapping" and
> entire 160 GIC interrupt number space is up for grabs. I think this will
> be much simpler to write and maintain.
>
> If you really want to maintain default mapping as far as possible, you
> can do two passes on the crossbar interrupt numbers requested. Once to
> assign the default map - for numbers less that 160 - and then look at
> the free GIC interrupt slots and use those for numbers greater than 160.
>
The whole point we are moving to domain is not have any default
mapping(connection done) at DT level. Rather DT only specifies the
peripherals and their cross-bar connection ID(i.e cross-bar IRQ line).
This will be the driver input as a IRQ line from DT. The cross-bar
driver needs to map any of the free list available on *request* only.
Of-course you have 320 inputs out of which only 160 can be mapped
and once you run out of it, you just return error on request IRQ.
That way there is no contention.
Regards,
Santosh
--
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