From: Rob Herring <robherring2@gmail.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: sfr@canb.auug.org.au, Russell King <linux@arm.linux.org.uk>,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
linuxppc-dev@lists.ozlabs.org,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC 13/14] irq_domain: Remove 'new' irq_domain in favour of the ppc one
Date: Thu, 12 Jan 2012 18:31:28 -0600 [thread overview]
Message-ID: <4F0F7B60.5040701@gmail.com> (raw)
In-Reply-To: <CACxGe6vVSO0cTgPurr6jFoo9QF_W02UaABOFYadCTQGU9dcwmg@mail.gmail.com>
Adding lakml...
On 01/11/2012 03:27 PM, Grant Likely wrote:
> On Wed, Jan 11, 2012 at 2:15 PM, Rob Herring <robherring2@gmail.com> wrote:
>> Grant,
>>
>> On 01/11/2012 02:22 PM, Grant Likely wrote:
>>> This patch removes the simplistic implementation of irq_domains and enables
>>> the powerpc infrastructure for all irq_domain users. The powerpc
>>> infrastructure includes support for complex mappings between Linux and
>>> hardware irq numbers, and can manage allocation of irq_descs.
>>>
>>> This patch also converts the few users of irq_domain_add()/irq_domain_del()
>>> to call irq_domain_add_legacy() instead.
>>
>> So what is the non-legacy way? Legacy implies we don't want to do it
>> that way. I guess until we remove all non-DT platforms with GIC we are
>> stuck with legacy. That seems like it could be a ways out until we get
>> there.
>
> Non-legacy is letting the irq_domain manage the irq_desc allocations.
> Some of the controllers will be easy to convert, some will be more
> difficult. The primary thing that really blocks getting away from the
> legacy method is anything that expects hardcoded #defined irq numbers.
> The goal is to convert all users over to the linear revmap method.
>
So I gave this a spin on highbank. I ran into a couple problems.
I had to revert "irqdesc: Consolidate irq reservation logic" which is in
your branch, but not this series. irq_alloc_desc_from was returning -EEXIST.
The GIC code did not work which I think is specific to using gic_of_init
which makes irq_start = -1. With that it still doesn't work. It dies in
gic_set_type... I've found one problem which I'll reply inline to, but I
think this is a dead end path anyway.
You have removed the irq_alloc_descs call from the GIC which is a step
backwards. Several of the ARM DT enabled platforms are at the point they
can fully support dynamic virq base for each irqchip. I changed the
domain from legacy to linear and got things working. The issue with
linear is for SPARSE_IRQ. The default behavior on ARM for SPARSE_IRQ is
all nr_irqs are allocated at boot time before any controller is
initialized. The only platform with a GIC and requiring SPARSE_IRQ is
shmobile, but it is also the only one that calls irq_alloc_desc
functions for it's interrupts. So I think we are okay there. The problem
occurs when enabling SPARSE_IRQ for a non-DT platform with a GIC and
with irqchips that don't call irq_alloc_desc for their irqs. IMHO, this
should be an okay trade-off. There's no advantage to enabling SPARSE_IRQ
on ARM for platforms that don't require it. All the platforms with a GIC
have active work to convert to DT (except shmobile which I think is
okay), so it's a temporary issue.
Rob
WARNING: multiple messages have this Message-ID (diff)
From: robherring2@gmail.com (Rob Herring)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 13/14] irq_domain: Remove 'new' irq_domain in favour of the ppc one
Date: Thu, 12 Jan 2012 18:31:28 -0600 [thread overview]
Message-ID: <4F0F7B60.5040701@gmail.com> (raw)
In-Reply-To: <CACxGe6vVSO0cTgPurr6jFoo9QF_W02UaABOFYadCTQGU9dcwmg@mail.gmail.com>
Adding lakml...
On 01/11/2012 03:27 PM, Grant Likely wrote:
> On Wed, Jan 11, 2012 at 2:15 PM, Rob Herring <robherring2@gmail.com> wrote:
>> Grant,
>>
>> On 01/11/2012 02:22 PM, Grant Likely wrote:
>>> This patch removes the simplistic implementation of irq_domains and enables
>>> the powerpc infrastructure for all irq_domain users. The powerpc
>>> infrastructure includes support for complex mappings between Linux and
>>> hardware irq numbers, and can manage allocation of irq_descs.
>>>
>>> This patch also converts the few users of irq_domain_add()/irq_domain_del()
>>> to call irq_domain_add_legacy() instead.
>>
>> So what is the non-legacy way? Legacy implies we don't want to do it
>> that way. I guess until we remove all non-DT platforms with GIC we are
>> stuck with legacy. That seems like it could be a ways out until we get
>> there.
>
> Non-legacy is letting the irq_domain manage the irq_desc allocations.
> Some of the controllers will be easy to convert, some will be more
> difficult. The primary thing that really blocks getting away from the
> legacy method is anything that expects hardcoded #defined irq numbers.
> The goal is to convert all users over to the linear revmap method.
>
So I gave this a spin on highbank. I ran into a couple problems.
I had to revert "irqdesc: Consolidate irq reservation logic" which is in
your branch, but not this series. irq_alloc_desc_from was returning -EEXIST.
The GIC code did not work which I think is specific to using gic_of_init
which makes irq_start = -1. With that it still doesn't work. It dies in
gic_set_type... I've found one problem which I'll reply inline to, but I
think this is a dead end path anyway.
You have removed the irq_alloc_descs call from the GIC which is a step
backwards. Several of the ARM DT enabled platforms are at the point they
can fully support dynamic virq base for each irqchip. I changed the
domain from legacy to linear and got things working. The issue with
linear is for SPARSE_IRQ. The default behavior on ARM for SPARSE_IRQ is
all nr_irqs are allocated at boot time before any controller is
initialized. The only platform with a GIC and requiring SPARSE_IRQ is
shmobile, but it is also the only one that calls irq_alloc_desc
functions for it's interrupts. So I think we are okay there. The problem
occurs when enabling SPARSE_IRQ for a non-DT platform with a GIC and
with irqchips that don't call irq_alloc_desc for their irqs. IMHO, this
should be an okay trade-off. There's no advantage to enabling SPARSE_IRQ
on ARM for platforms that don't require it. All the platforms with a GIC
have active work to convert to DT (except shmobile which I think is
okay), so it's a temporary issue.
Rob
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robherring2@gmail.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: linux-kernel@vger.kernel.org,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Thomas Gleixner <tglx@linutronix.de>,
linuxppc-dev@lists.ozlabs.org,
Russell King <linux@arm.linux.org.uk>,
sfr@canb.auug.org.au,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC 13/14] irq_domain: Remove 'new' irq_domain in favour of the ppc one
Date: Thu, 12 Jan 2012 18:31:28 -0600 [thread overview]
Message-ID: <4F0F7B60.5040701@gmail.com> (raw)
In-Reply-To: <CACxGe6vVSO0cTgPurr6jFoo9QF_W02UaABOFYadCTQGU9dcwmg@mail.gmail.com>
Adding lakml...
On 01/11/2012 03:27 PM, Grant Likely wrote:
> On Wed, Jan 11, 2012 at 2:15 PM, Rob Herring <robherring2@gmail.com> wrote:
>> Grant,
>>
>> On 01/11/2012 02:22 PM, Grant Likely wrote:
>>> This patch removes the simplistic implementation of irq_domains and enables
>>> the powerpc infrastructure for all irq_domain users. The powerpc
>>> infrastructure includes support for complex mappings between Linux and
>>> hardware irq numbers, and can manage allocation of irq_descs.
>>>
>>> This patch also converts the few users of irq_domain_add()/irq_domain_del()
>>> to call irq_domain_add_legacy() instead.
>>
>> So what is the non-legacy way? Legacy implies we don't want to do it
>> that way. I guess until we remove all non-DT platforms with GIC we are
>> stuck with legacy. That seems like it could be a ways out until we get
>> there.
>
> Non-legacy is letting the irq_domain manage the irq_desc allocations.
> Some of the controllers will be easy to convert, some will be more
> difficult. The primary thing that really blocks getting away from the
> legacy method is anything that expects hardcoded #defined irq numbers.
> The goal is to convert all users over to the linear revmap method.
>
So I gave this a spin on highbank. I ran into a couple problems.
I had to revert "irqdesc: Consolidate irq reservation logic" which is in
your branch, but not this series. irq_alloc_desc_from was returning -EEXIST.
The GIC code did not work which I think is specific to using gic_of_init
which makes irq_start = -1. With that it still doesn't work. It dies in
gic_set_type... I've found one problem which I'll reply inline to, but I
think this is a dead end path anyway.
You have removed the irq_alloc_descs call from the GIC which is a step
backwards. Several of the ARM DT enabled platforms are at the point they
can fully support dynamic virq base for each irqchip. I changed the
domain from legacy to linear and got things working. The issue with
linear is for SPARSE_IRQ. The default behavior on ARM for SPARSE_IRQ is
all nr_irqs are allocated at boot time before any controller is
initialized. The only platform with a GIC and requiring SPARSE_IRQ is
shmobile, but it is also the only one that calls irq_alloc_desc
functions for it's interrupts. So I think we are okay there. The problem
occurs when enabling SPARSE_IRQ for a non-DT platform with a GIC and
with irqchips that don't call irq_alloc_desc for their irqs. IMHO, this
should be an okay trade-off. There's no advantage to enabling SPARSE_IRQ
on ARM for platforms that don't require it. All the platforms with a GIC
have active work to convert to DT (except shmobile which I think is
okay), so it's a temporary issue.
Rob
next prev parent reply other threads:[~2012-01-13 0:31 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-11 20:22 [RFC 0/14] Finish up irq_domain generalization Grant Likely
2012-01-11 20:22 ` [RFC 01/14] dt: Make irqdomain less verbose Grant Likely
2012-01-11 20:22 ` Grant Likely
2012-01-11 20:22 ` [RFC 02/14] irq_domain: Make irq_domain structure match powerpc's irq_host Grant Likely
2012-01-11 20:22 ` Grant Likely
2012-01-11 20:22 ` [RFC 03/14] irq_domain: convert microblaze from irq_host to irq_domain Grant Likely
2012-01-11 20:22 ` Grant Likely
2012-01-11 20:22 ` [RFC 04/14] irq_domain/powerpc: Use common irq_domain structure instead of irq_host Grant Likely
2012-01-11 20:22 ` Grant Likely
2012-01-11 20:22 ` [RFC 05/14] irq_domain/powerpc: eliminate irq_map; use irq_alloc_desc() instead Grant Likely
2012-01-11 20:22 ` Grant Likely
2012-01-11 20:22 ` [RFC 06/14] irq_domain/powerpc: Eliminate virq_is_host() Grant Likely
2012-01-11 20:22 ` Grant Likely
2012-01-12 10:17 ` Milton Miller
2012-01-18 0:38 ` Grant Likely
2012-01-18 0:38 ` Grant Likely
2012-01-18 21:25 ` Grant Likely
2012-01-11 20:22 ` [RFC 07/14] irq_domain: Move irq_domain code from powerpc to kernel/irq Grant Likely
2012-01-11 20:22 ` Grant Likely
2012-01-11 20:22 ` [RFC 08/14] irqdomain: remove NO_IRQ from irq domain code Grant Likely
2012-01-11 20:22 ` Grant Likely
2012-01-11 20:22 ` [RFC 09/14] irq_domain: Remove references to old irq_host names Grant Likely
2012-01-11 20:22 ` Grant Likely
2012-01-11 20:22 ` [RFC 10/14] irq_domain: Replace irq_alloc_host() with revmap-specific initializers Grant Likely
2012-01-11 20:22 ` Grant Likely
2012-01-11 20:22 ` [RFC 11/14] powerpc: Eliminate NO_IRQ usage Grant Likely
2012-01-11 20:22 ` Grant Likely
2013-07-25 21:58 ` Geert Uytterhoeven
2013-07-25 21:58 ` Geert Uytterhoeven
2013-07-26 3:56 ` Grant Likely
2013-07-26 3:56 ` Grant Likely
2013-08-23 13:18 ` Geert Uytterhoeven
2013-08-23 13:18 ` Geert Uytterhoeven
2013-08-23 13:22 ` Geert Uytterhoeven
2013-08-23 13:22 ` Geert Uytterhoeven
2012-01-11 20:22 ` [RFC 12/14] irq_domain: Add support for base irq and hwirq in legacy mappings Grant Likely
2012-01-11 20:22 ` Grant Likely
2012-01-13 0:37 ` Rob Herring
2012-01-13 0:37 ` Rob Herring
2012-01-13 0:53 ` Grant Likely
2012-01-13 0:53 ` Grant Likely
2012-01-11 20:22 ` [RFC 13/14] irq_domain: Remove 'new' irq_domain in favour of the ppc one Grant Likely
2012-01-11 20:22 ` Grant Likely
2012-01-11 21:15 ` Rob Herring
2012-01-11 21:15 ` Rob Herring
2012-01-11 21:27 ` Grant Likely
2012-01-11 21:27 ` Grant Likely
2012-01-13 0:31 ` Rob Herring [this message]
2012-01-13 0:31 ` Rob Herring
2012-01-13 0:31 ` Rob Herring
2012-01-13 0:47 ` Grant Likely
2012-01-13 0:47 ` Grant Likely
2012-01-13 0:47 ` Grant Likely
2012-01-13 0:53 ` Rob Herring
2012-01-13 0:53 ` Rob Herring
2012-01-13 0:53 ` Rob Herring
2012-01-13 2:20 ` Grant Likely
2012-01-13 2:20 ` Grant Likely
2012-01-13 2:20 ` Grant Likely
2012-01-17 2:43 ` Michael Bohan
2012-01-17 2:43 ` Michael Bohan
2012-01-17 2:43 ` Michael Bohan
2012-01-17 2:43 ` Michael Bohan
2012-01-17 3:42 ` Benjamin Herrenschmidt
2012-01-17 3:42 ` Benjamin Herrenschmidt
2012-01-17 3:42 ` Benjamin Herrenschmidt
2012-01-18 0:28 ` Grant Likely
2012-01-18 0:28 ` Grant Likely
2012-01-18 0:28 ` Grant Likely
2012-01-18 2:16 ` Benjamin Herrenschmidt
2012-01-18 2:16 ` Benjamin Herrenschmidt
2012-01-18 2:16 ` Benjamin Herrenschmidt
2012-01-18 6:50 ` Grant Likely
2012-01-18 6:50 ` Grant Likely
2012-01-11 20:22 ` [RFC 14/14] irq_domain: Remove irq_domain_add_simple() Grant Likely
2012-01-11 20:22 ` Grant Likely
2012-01-11 21:39 ` [RFC 0/14] Finish up irq_domain generalization Randy Dunlap
2012-01-11 21:39 ` Randy Dunlap
2012-01-11 20:50 ` Grant Likely
2012-01-11 20:50 ` Grant Likely
2012-01-11 21:23 ` Grant Likely
2012-01-11 21:23 ` Grant Likely
2012-01-11 22:48 ` Randy Dunlap
2012-01-11 22:48 ` Randy Dunlap
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=4F0F7B60.5040701@gmail.com \
--to=robherring2@gmail.com \
--cc=grant.likely@secretlab.ca \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=sfr@canb.auug.org.au \
--cc=tglx@linutronix.de \
/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.