ARM/Kernel: Problems with multiple VIC registration

Hi All,

I've picked Linux kernel 3.8-rc4 and added the support for my ARM based board in it.

- The SoC has 2 VICs
- valid_sources are 32 (~0)
- NR_IRQS is defined as 104; => irq_desc[104]
- I'm not populating devices thro' DT

The first controller is registered throu' irq_domain_add_linear API. As a result of this call, a new domain is allocated to the VIC device.

In the next step IRQ mapping, irq_create_mapping is called and this maps all the IRQs in the Linux IRQ space. However in doing so, it uses irq_desc[1]...irq_desc[32]. irq_dec[0] is not used (checked using a debugger)!

When I'm trying to register the second VIC (it's throu' irq_domain_add_legacy), I'm getting warnings since irq_get_irq_data returns irq_data of irq_desc[32] which has already been mapped.

In short, irq_domain_add_legacy returns with NULL irq_domain.

I checked that multiple VIC registration works in Linux 3.4 Is it something that I'm missing while adapting to the new framework, or there's some undetected problem?

I've attached the logfile generated with debug prints ON. Would appreciate any help...

Thanks
Amit Virdi

Quoted 4 lines

Hi All,

I've picked Linux kernel 3.8-rc4 and added the support for my ARM based board in it.

What about rc6? Linus has been fixing some VIC issues in this area.

The first controller is registered throu' irq_domain_add_linear API. As a result of this call, a new domain is allocated to the VIC device.

Quoted 2 lines · Amit Virdi

The first controller is registered throu' irq_domain_add_linear API. As a result of this call, a new domain is allocated to the VIC device.

This is a bug. Do you have this patch in your tree:
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7611/1

Quoted 3 lines · Linus Walleij

On Tue, Feb 5, 2013 at 10:48 AM, Amit Virdi<[email protected]> wrote:

Quoted 6 lines

Quoted 2 lines

The first controller is registered throu' irq_domain_add_linear API. As a result of this call, a new domain is allocated to the VIC device.

This is a bug. Do you have this patch in your tree:
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7611/1

Yes, I have this patch (from rc2) and still the bug!

Quoted 4 lines · Amit Virdi

Quoted 3 lines · Linus Walleij

On Tue, Feb 5, 2013 at 10:48 AM, Amit Virdi<[email protected]> wrote:

Quoted 8 lines

Quoted 6 lines

Quoted 2 lines

The first controller is registered throu' irq_domain_add_linear API. As a result of this call, a new domain is allocated to the VIC device.

This is a bug. Do you have this patch in your tree:
http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7611/1

Yes, I have this patch (from rc2) and still the bug!

You have to post your code for your SoC board support for us to help out.

There are several things you can do wrong. For example a common mistake is to offset the IRQs on a new platform from zero. So that the first parameter to vic_init() is zero. This is not legal because Linux IRQ 0 is NO_IRQ and shall not be used. If this is your problems, IRQs shall offset from something like 64 so you can even use SPARSE_IRQ.

Quoted 5 lines · Linus Walleij

There are several things you can do wrong. For example a common mistake is to offset the IRQs on a new platform from zero. So that the first parameter to vic_init() is zero. This is not legal because Linux IRQ 0 is NO_IRQ and shall not be used. If this is your problems, IRQs shall offset from something like 64 so you can even use SPARSE_IRQ.

Yes, I was using 0 as the first offset in IRQs and my IRQs were defined from 0 to n. I changed it to 1 to n+1 and I'm now not using 0. Every problem seems to have resolved now.

Quoted 11 lines · Amit Virdi

Quoted 5 lines · Linus Walleij

There are several things you can do wrong. For example a common mistake is to offset the IRQs on a new platform from zero. So that the first parameter to vic_init() is zero. This is not legal because Linux IRQ 0 is NO_IRQ and shall not be used. If this is your problems, IRQs shall offset from something like 64 so you can even use SPARSE_IRQ.

Yes, I was using 0 as the first offset in IRQs and my IRQs were defined from 0 to n. I changed it to 1 to n+1 and I'm now not using 0. Every problem seems to have resolved now.

1 and n+1 is only going to work as long as you're defining NR_IRQS in the platform or in the .nr_irqs member of the MACHINE record.

If you use device tree or SPARSE_IRQ (which, by the way, you should turn on right now) you will run into trouble.

Bump it to 64+n.

Else you will just have to fix all this when you get to submitting board support upstream.