From: Santosh Shilimkar <santosh.shilimkar-l0cyMroinI0@public.gmane.org>
To: Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
Cc: Sricharan R <r.sricharan-l0cyMroinI0@public.gmane.org>,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
LAK
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>,
rnayak-l0cyMroinI0@public.gmane.org
Subject: Re: [RFC PATCH 1/4] DRIVERS: IRQCHIP: Add crossbar irqchip driver
Date: Fri, 13 Sep 2013 10:55:46 -0400 [thread overview]
Message-ID: <52332772.5040203@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1309131142540.4089-3cz04HxQygjZikZi3RtOZ1XZhhPuCNm+@public.gmane.org>
On Friday 13 September 2013 10:24 AM, Thomas Gleixner wrote:
> On Thu, 12 Sep 2013, Santosh Shilimkar wrote:
>> On Thursday 12 September 2013 08:26 PM, Thomas Gleixner wrote:
>>> Let me summarize:
>>>
>>> - GIC supports up to 160 interrupts
>>>
>>> - CROSSBAR supports up to 250 interrupts
>>>
>>> - CROSSBAR routes up to 160 out of 250 interrupts to the GIC ones
>>>
>>> - Drivers request a CROSSBAR interrupt number which must be mapped
>>> to some arbitrary available GIC irq number
>>>
>> Correct.
>>
>>> So basically the CROSSBAR mechanism is pretty much the same as MSI[X]
>>> just in a different flavour and with a different set of semantics and
>>> limitations, i.e. poor mans MSI[X] with a new level of bogosity.
>>>
>>> So if CROSSBAR is going to be the new fangled SoC MSI[X] long term
>>> equivalent then you better provide some infrastructure for that and
>>> make the drivers ready to use it. Maybe check with the PCI/MSI folks
>>> to share some of the interfaces.
>>>
>>> If that whole thing is another onetime HW designers wet dream, then
>>> please go back to the limited but completely functional (Who is going
>>> to use more than 160 peripheral interrupts????) device tree model. I
>>> really have no interest to support hardware designer brain farts.
>>>
>> Thanks for clear NAK for irqchip approach. I should have looped you
>> in the discussion where I was also suggesting against the irqchip
>> approach. We will try to look at MSI stuff but if its get too
>> complicated am going to fall-back to the initial probe based
>> approach to achieve the functionality.
>
> 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.
Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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: Fri, 13 Sep 2013 10:55:46 -0400 [thread overview]
Message-ID: <52332772.5040203@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1309131142540.4089@ionos.tec.linutronix.de>
On Friday 13 September 2013 10:24 AM, Thomas Gleixner wrote:
> On Thu, 12 Sep 2013, Santosh Shilimkar wrote:
>> On Thursday 12 September 2013 08:26 PM, Thomas Gleixner wrote:
>>> Let me summarize:
>>>
>>> - GIC supports up to 160 interrupts
>>>
>>> - CROSSBAR supports up to 250 interrupts
>>>
>>> - CROSSBAR routes up to 160 out of 250 interrupts to the GIC ones
>>>
>>> - Drivers request a CROSSBAR interrupt number which must be mapped
>>> to some arbitrary available GIC irq number
>>>
>> Correct.
>>
>>> So basically the CROSSBAR mechanism is pretty much the same as MSI[X]
>>> just in a different flavour and with a different set of semantics and
>>> limitations, i.e. poor mans MSI[X] with a new level of bogosity.
>>>
>>> So if CROSSBAR is going to be the new fangled SoC MSI[X] long term
>>> equivalent then you better provide some infrastructure for that and
>>> make the drivers ready to use it. Maybe check with the PCI/MSI folks
>>> to share some of the interfaces.
>>>
>>> If that whole thing is another onetime HW designers wet dream, then
>>> please go back to the limited but completely functional (Who is going
>>> to use more than 160 peripheral interrupts????) device tree model. I
>>> really have no interest to support hardware designer brain farts.
>>>
>> Thanks for clear NAK for irqchip approach. I should have looped you
>> in the discussion where I was also suggesting against the irqchip
>> approach. We will try to look at MSI stuff but if its get too
>> complicated am going to fall-back to the initial probe based
>> approach to achieve the functionality.
>
> 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.
Regards,
Santosh
WARNING: multiple messages have this Message-ID (diff)
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Thomas Gleixner <tglx@linutronix.de>
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>, <linus.walleij@linaro.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: Fri, 13 Sep 2013 10:55:46 -0400 [thread overview]
Message-ID: <52332772.5040203@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1309131142540.4089@ionos.tec.linutronix.de>
On Friday 13 September 2013 10:24 AM, Thomas Gleixner wrote:
> On Thu, 12 Sep 2013, Santosh Shilimkar wrote:
>> On Thursday 12 September 2013 08:26 PM, Thomas Gleixner wrote:
>>> Let me summarize:
>>>
>>> - GIC supports up to 160 interrupts
>>>
>>> - CROSSBAR supports up to 250 interrupts
>>>
>>> - CROSSBAR routes up to 160 out of 250 interrupts to the GIC ones
>>>
>>> - Drivers request a CROSSBAR interrupt number which must be mapped
>>> to some arbitrary available GIC irq number
>>>
>> Correct.
>>
>>> So basically the CROSSBAR mechanism is pretty much the same as MSI[X]
>>> just in a different flavour and with a different set of semantics and
>>> limitations, i.e. poor mans MSI[X] with a new level of bogosity.
>>>
>>> So if CROSSBAR is going to be the new fangled SoC MSI[X] long term
>>> equivalent then you better provide some infrastructure for that and
>>> make the drivers ready to use it. Maybe check with the PCI/MSI folks
>>> to share some of the interfaces.
>>>
>>> If that whole thing is another onetime HW designers wet dream, then
>>> please go back to the limited but completely functional (Who is going
>>> to use more than 160 peripheral interrupts????) device tree model. I
>>> really have no interest to support hardware designer brain farts.
>>>
>> Thanks for clear NAK for irqchip approach. I should have looped you
>> in the discussion where I was also suggesting against the irqchip
>> approach. We will try to look at MSI stuff but if its get too
>> complicated am going to fall-back to the initial probe based
>> approach to achieve the functionality.
>
> 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.
Regards,
Santosh
next prev parent reply other threads:[~2013-09-13 14:55 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 [this message]
2013-09-13 14:55 ` Santosh Shilimkar
2013-09-13 14:55 ` Santosh Shilimkar
2013-09-18 15:07 ` Santosh Shilimkar
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=52332772.5040203@ti.com \
--to=santosh.shilimkar-l0cymroini0@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \
--cc=linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=r.sricharan-l0cyMroinI0@public.gmane.org \
--cc=rnayak-l0cyMroinI0@public.gmane.org \
--cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
--cc=tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org \
/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.