All of lore.kernel.org
 help / color / mirror / Atom feed
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Thomas Gleixner <tglx@linutronix.de>, linus.walleij@linaro.org
Cc: Sricharan R <r.sricharan@ti.com>,
	LKML <linux-kernel@vger.kernel.org>,
	devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
	LAK <linux-arm-kernel@lists.infradead.org>,
	linux-omap@vger.kernel.org, Russell King <linux@arm.linux.org.uk>,
	Tony Lindgren <tony@atomide.com>,
	rnayak@ti.com
Subject: Re: [RFC PATCH 1/4] DRIVERS: IRQCHIP: Add crossbar irqchip driver
Date: Wed, 18 Sep 2013 11:07:10 -0400	[thread overview]
Message-ID: <5239C19E.1090609@ti.com> (raw)
In-Reply-To: <52332772.5040203@ti.com>

Thomas,

On Friday 13 September 2013 10:55 AM, Santosh Shilimkar wrote:
> On Friday 13 September 2013 10:24 AM, Thomas Gleixner wrote:

[...]

>> Before you dig into MSI, lets talk about irq domains first.
>>
>> GIC implements a legacy irq domain, i.e. a linear domain of all
>> possible GIC interrupts with a 1:1 mapping.
>>
>> So why can't you make use of irq domains and have the whole routing
>> business implemented sanely?
>>
>> What's needed is in gic_init_bases():
>>
>>        if (of_property_read(node, "routable_irqs", &nr_routable_irqs) {
>>        	  irq_domain_add_legacy(nr_gic_irqs);
>>        } else {
>>        	  irq_domain_add_legacy(nr_per_cpu_irqs);
>> 	  irq_domain_add_linear(nr_routable_irqs);
>>        }
>>
>> Now that separate domain has an xlate function which grabs a free GIC
>> irq from a bitmap and returns the hardware irq number in the gic
>> space. The map/unmap callbacks take care of setting up / tearing down
>> the route in the crossbar.
>>
>> Thoughts?
>>
> This sounds pretty good idea. We will explore above option.
> Thanks Thomas.
> 
After further looking into this, the irqdomain approach lets us
setup the map only once during the init. This is similar to
the earlier approach of cross-bar driver where at probe time
the router was setup.  The whole debate started with the fact
that we shouldn't fix the irq mapping at probe and should
dynamically change the mapping based on [request/free]_irq()
to be able to maximize the use of the IP.

Since we have agreed now to move ahead with irdomain, i thought
of mentioning it here.

Regards,
Santosh








WARNING: multiple messages have this Message-ID (diff)
From: santosh.shilimkar@ti.com (Santosh Shilimkar)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 1/4] DRIVERS: IRQCHIP: Add crossbar irqchip driver
Date: Wed, 18 Sep 2013 11:07:10 -0400	[thread overview]
Message-ID: <5239C19E.1090609@ti.com> (raw)
In-Reply-To: <52332772.5040203@ti.com>

Thomas,

On Friday 13 September 2013 10:55 AM, Santosh Shilimkar wrote:
> On Friday 13 September 2013 10:24 AM, Thomas Gleixner wrote:

[...]

>> Before you dig into MSI, lets talk about irq domains first.
>>
>> GIC implements a legacy irq domain, i.e. a linear domain of all
>> possible GIC interrupts with a 1:1 mapping.
>>
>> So why can't you make use of irq domains and have the whole routing
>> business implemented sanely?
>>
>> What's needed is in gic_init_bases():
>>
>>        if (of_property_read(node, "routable_irqs", &nr_routable_irqs) {
>>        	  irq_domain_add_legacy(nr_gic_irqs);
>>        } else {
>>        	  irq_domain_add_legacy(nr_per_cpu_irqs);
>> 	  irq_domain_add_linear(nr_routable_irqs);
>>        }
>>
>> Now that separate domain has an xlate function which grabs a free GIC
>> irq from a bitmap and returns the hardware irq number in the gic
>> space. The map/unmap callbacks take care of setting up / tearing down
>> the route in the crossbar.
>>
>> Thoughts?
>>
> This sounds pretty good idea. We will explore above option.
> Thanks Thomas.
> 
After further looking into this, the irqdomain approach lets us
setup the map only once during the init. This is similar to
the earlier approach of cross-bar driver where at probe time
the router was setup.  The whole debate started with the fact
that we shouldn't fix the irq mapping at probe and should
dynamically change the mapping based on [request/free]_irq()
to be able to maximize the use of the IP.

Since we have agreed now to move ahead with irdomain, i thought
of mentioning it here.

Regards,
Santosh

WARNING: multiple messages have this Message-ID (diff)
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Thomas Gleixner <tglx@linutronix.de>, <linus.walleij@linaro.org>
Cc: Sricharan R <r.sricharan@ti.com>,
	LKML <linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>,
	<linux-doc@vger.kernel.org>,
	LAK <linux-arm-kernel@lists.infradead.org>,
	<linux-omap@vger.kernel.org>,
	Russell King <linux@arm.linux.org.uk>,
	Tony Lindgren <tony@atomide.com>, <rnayak@ti.com>
Subject: Re: [RFC PATCH 1/4] DRIVERS: IRQCHIP: Add crossbar irqchip driver
Date: Wed, 18 Sep 2013 11:07:10 -0400	[thread overview]
Message-ID: <5239C19E.1090609@ti.com> (raw)
In-Reply-To: <52332772.5040203@ti.com>

Thomas,

On Friday 13 September 2013 10:55 AM, Santosh Shilimkar wrote:
> On Friday 13 September 2013 10:24 AM, Thomas Gleixner wrote:

[...]

>> Before you dig into MSI, lets talk about irq domains first.
>>
>> GIC implements a legacy irq domain, i.e. a linear domain of all
>> possible GIC interrupts with a 1:1 mapping.
>>
>> So why can't you make use of irq domains and have the whole routing
>> business implemented sanely?
>>
>> What's needed is in gic_init_bases():
>>
>>        if (of_property_read(node, "routable_irqs", &nr_routable_irqs) {
>>        	  irq_domain_add_legacy(nr_gic_irqs);
>>        } else {
>>        	  irq_domain_add_legacy(nr_per_cpu_irqs);
>> 	  irq_domain_add_linear(nr_routable_irqs);
>>        }
>>
>> Now that separate domain has an xlate function which grabs a free GIC
>> irq from a bitmap and returns the hardware irq number in the gic
>> space. The map/unmap callbacks take care of setting up / tearing down
>> the route in the crossbar.
>>
>> Thoughts?
>>
> This sounds pretty good idea. We will explore above option.
> Thanks Thomas.
> 
After further looking into this, the irqdomain approach lets us
setup the map only once during the init. This is similar to
the earlier approach of cross-bar driver where at probe time
the router was setup.  The whole debate started with the fact
that we shouldn't fix the irq mapping at probe and should
dynamically change the mapping based on [request/free]_irq()
to be able to maximize the use of the IP.

Since we have agreed now to move ahead with irdomain, i thought
of mentioning it here.

Regards,
Santosh








  reply	other threads:[~2013-09-18 15:07 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-12 15:39 [RFC PATCH 0/4] DRIVERS: IRQCHIP: Add crossbar irqchip driver Sricharan R
2013-09-12 15:39 ` Sricharan R
2013-09-12 15:39 ` Sricharan R
2013-09-12 15:39 ` [RFC PATCH 1/4] " Sricharan R
2013-09-12 15:39   ` Sricharan R
2013-09-12 15:39   ` Sricharan R
2013-09-12 20:18   ` Thomas Gleixner
2013-09-12 20:18     ` Thomas Gleixner
     [not found]     ` <alpine.DEB.2.02.1309122201530.4089-3cz04HxQygjZikZi3RtOZ1XZhhPuCNm+@public.gmane.org>
2013-09-12 20:48       ` Santosh Shilimkar
2013-09-12 20:48         ` Santosh Shilimkar
2013-09-12 20:48         ` Santosh Shilimkar
2013-09-12 22:22         ` Thomas Gleixner
2013-09-12 22:22           ` Thomas Gleixner
2013-09-12 22:51           ` Santosh Shilimkar
2013-09-12 22:51             ` Santosh Shilimkar
2013-09-12 22:51             ` Santosh Shilimkar
     [not found]             ` <5232457A.8080709-l0cyMroinI0@public.gmane.org>
2013-09-13  0:26               ` Thomas Gleixner
2013-09-13  0:26                 ` Thomas Gleixner
2013-09-13  0:26                 ` Thomas Gleixner
2013-09-13  1:42                 ` Santosh Shilimkar
2013-09-13  1:42                   ` Santosh Shilimkar
2013-09-13  1:42                   ` Santosh Shilimkar
2013-09-13  8:32                   ` Sricharan R
2013-09-13  8:32                     ` Sricharan R
2013-09-13  8:32                     ` Sricharan R
2013-09-13 14:24                   ` Thomas Gleixner
2013-09-13 14:24                     ` Thomas Gleixner
     [not found]                     ` <alpine.DEB.2.02.1309131142540.4089-3cz04HxQygjZikZi3RtOZ1XZhhPuCNm+@public.gmane.org>
2013-09-13 14:55                       ` Santosh Shilimkar
2013-09-13 14:55                         ` Santosh Shilimkar
2013-09-13 14:55                         ` Santosh Shilimkar
2013-09-18 15:07                         ` Santosh Shilimkar [this message]
2013-09-18 15:07                           ` Santosh Shilimkar
2013-09-18 15:07                           ` Santosh Shilimkar
     [not found]                           ` <5239C19E.1090609-l0cyMroinI0@public.gmane.org>
2013-09-18 22:31                             ` Thomas Gleixner
2013-09-18 22:31                               ` Thomas Gleixner
2013-09-18 22:31                               ` Thomas Gleixner
2013-09-17 12:26                     ` Linus Walleij
2013-09-17 12:26                       ` Linus Walleij
2013-09-18 13:52                       ` Sricharan R
2013-09-18 13:52                         ` Sricharan R
2013-09-18 15:25                         ` Sricharan R
2013-09-18 15:25                           ` Sricharan R
2013-09-18 22:13                           ` Thomas Gleixner
2013-09-18 22:13                             ` Thomas Gleixner
2013-09-12 20:54   ` Felipe Balbi
2013-09-12 20:54     ` Felipe Balbi
2013-09-12 20:54     ` Felipe Balbi
2013-09-12 21:35     ` Thomas Gleixner
2013-09-12 21:35       ` Thomas Gleixner
     [not found]       ` <alpine.DEB.2.02.1309122334370.4089-3cz04HxQygjZikZi3RtOZ1XZhhPuCNm+@public.gmane.org>
2013-09-12 22:12         ` Thomas Gleixner
2013-09-12 22:12           ` Thomas Gleixner
2013-09-12 22:12           ` Thomas Gleixner
2013-09-20  8:58   ` Mark Rutland
2013-09-20  8:58     ` Mark Rutland
2013-09-20  8:58     ` Mark Rutland
     [not found]     ` <20130920085830.GF17453-NuALmloUBlrZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
2013-09-20  9:59       ` Sricharan R
2013-09-20  9:59         ` Sricharan R
2013-09-20  9:59         ` Sricharan R
2013-09-12 15:39 ` [RFC PATCH 2/4] ARM: DTS: DRA: Add crossbar device binding Sricharan R
2013-09-12 15:39   ` Sricharan R
2013-09-12 15:39   ` Sricharan R
2013-09-12 15:39 ` [RFC PATCH 3/4] ARM: DTS: DRA: Replace peripheral interrupt numbers with crossbar inputs Sricharan R
2013-09-12 15:39   ` Sricharan R
2013-09-12 15:39   ` Sricharan R
2013-09-12 15:39 ` [RFC PATCH 4/4] ARM: DRA: Kconfig: Enable crossbar irqchip driver for DRA7xx Sricharan R
2013-09-12 15:39   ` Sricharan R
2013-09-12 15:39   ` Sricharan R

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5239C19E.1090609@ti.com \
    --to=santosh.shilimkar@ti.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=r.sricharan@ti.com \
    --cc=rnayak@ti.com \
    --cc=tglx@linutronix.de \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.