Re: [RFC 13/14] irq_domain: Remove 'new' irq_domain in favour of the ppc one

Re: [RFC 13/14] irq_domain: Remove 'new' irq_domain in favour of the ppc one

[Michael Bohan]

On 1/12/2012 4:31 PM, Rob Herring wrote:
> 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.

I thought I would chime in here since this is very relevant to what 
we're doing on arm-msm. We are using Device Tree with the GIC. We also 
have several other interrupt chips, including one for a device that 
supports up to 32768 sparsely populated interrupts. Hence we are using 
SPARSE_IRQ to only allocate irq_descs on demand for this device.

To support this, I had to modify irq_domain_add() to not 'register' the 
domain. Eg. simply add the domain to the list, but do not initialize the 
hwirq values in the irq_data structure. This is because our irq_descs 
are allocated later based on Device Tree topology. This information is 
not available during of_irq_init().

But then I was left with the problem of managing irq_bases for multiple 
chip drivers. The problem with irq_alloc_desc() is that it doesn't allow 
you to allocate a range without allocating its corresponding resources. 
Meaning, I'd like to reserve a chunk of virqs, but not utilize any 
resources for them until I know they're necessary. This is where 
irq_domains comes in.

In order to support this properly, I decided it made sense to add a new 
API called irq_domain_find_free_range(). This walks the irq domains 
list, now sorted by domain->irq_base, to find the first available range 
of the size specified. Thus every irq chip then only needs to know the 
worst case number of interrupts it could ever support. The framework 
takes care of finding the specific virq base. And all of this 
information is available at of_irq_init() time. This all assumes that 
every chip driver registers with irq_domains.

I was planning on sending these patches out, but it seems like with 
Grant's patches, they may no longer be up to date. I was curious if any 
thought was given to supporting configurations like this the one I 
mentioned with the advent of these patches. I am happy to help test if 
you can steer me in the right direction.

Thanks,
Mike

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum

Re: [RFC 13/14] irq_domain: Remove 'new' irq_domain in favour of the ppc one

[Benjamin Herrenschmidt]

On Mon, 2012-01-16 at 18:43 -0800, Michael Bohan wrote:
> 
> I was planning on sending these patches out, but it seems like with 
> Grant's patches, they may no longer be up to date. I was curious if any 
> thought was given to supporting configurations like this the one I 
> mentioned with the advent of these patches. I am happy to help test if 
> you can steer me in the right direction.

I haven't had a chance to look in detail at what Grant is doing in his
latest series, but the ppc domain scheme that he's basing it on has the
concept of sparse interrupt domains.

For these, we use a radix tree for the reverse map (we do not rely on a
linear range) and we "allocate" linux IRQ numbers on-demand as we create
mapping for individual HW interrupts.

Cheers,
Ben.

Re: [RFC 13/14] irq_domain: Remove 'new' irq_domain in favour of the ppc one

[Grant Likely]

On Mon, Jan 16, 2012 at 8:42 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Mon, 2012-01-16 at 18:43 -0800, Michael Bohan wrote:
>>
>> I was planning on sending these patches out, but it seems like with
>> Grant's patches, they may no longer be up to date. I was curious if any
>> thought was given to supporting configurations like this the one I
>> mentioned with the advent of these patches. I am happy to help test if
>> you can steer me in the right direction.
>
> I haven't had a chance to look in detail at what Grant is doing in his
> latest series, but the ppc domain scheme that he's basing it on has the
> concept of sparse interrupt domains.
>
> For these, we use a radix tree for the reverse map (we do not rely on a
> linear range) and we "allocate" linux IRQ numbers on-demand as we create
> mapping for individual HW interrupts.

My latest patches are primarily a direct port of the ppc code to be
generic for all architectures, and it does pretty much what you want.
As Ben suggests, you should look at the radix revmap code.  Use the
irq_domain_add_tree() function for creating the irq_domain, and there
is no need to even pre-allocate the number of hwirqs that you want to
support.  It uses a radix tree to manage arbitrary mappings from hwirq
number to linux numbers.

The other option is the linear map which maintains a static array with
one entry per hwirq number.  Use irq_domain_add_linear() to create one
and pass in the maximum number of hwirqs supported by the controller.
It will allocate an array of irq_desc* so that irq_descs can be
allocated dynamically.

It is also important to note that for both these revmaps, the actual
virq number is irrelevant.  The irq_domain is entirely responsible for
allocation and management.  There will be no need for a 'chunk of
virqs' assigned to an irq controller.

BTW: Ben, if you can carve out some time, I'd appreciate a look over
my series and make sure you're okay with it.  Once it's had some
testing by arm and ppc folks, I want to get it into linux-next.

g.

Re: [RFC 13/14] irq_domain: Remove 'new' irq_domain in favour of the ppc one

[Benjamin Herrenschmidt]

On Tue, 2012-01-17 at 17:28 -0700, Grant Likely wrote:
> BTW: Ben, if you can carve out some time, I'd appreciate a look over
> my series and make sure you're okay with it.  Once it's had some
> testing by arm and ppc folks, I want to get it into linux-next.

I intend to do so but not while I'm at LCA :-)

Cheers,
Ben.

Re: [RFC 13/14] irq_domain: Remove 'new' irq_domain in favour of the ppc one

[Grant Likely]

[-- Attachment #1.1: Type: text/plain, Size: 504 bytes --]

On Jan 17, 2012 7:17 PM, "Benjamin Herrenschmidt" <benh@kernel.crashing.org>
wrote:
>
> On Tue, 2012-01-17 at 17:28 -0700, Grant Likely wrote:
> > BTW: Ben, if you can carve out some time, I'd appreciate a look over
> > my series and make sure you're okay with it.  Once it's had some
> > testing by arm and ppc folks, I want to get it into linux-next.
>
> I intend to do so but not while I'm at LCA :-)

Pish... slacker.

:-p

No problem, enjoy LCA. One of these years I need to make it over there.

g.

[-- Attachment #1.2: Type: text/html, Size: 700 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev