IRQ numbering (was: Better timer and RTC handling for 8641HPCN.)

[Kumar Gala]

On Mar 11, 2007, at 9:37 PM, Zhang Wei-r63237 wrote:

>>>>>>> Please use 80.
>>>>>>> We reserve the first 16 ints for legacy 8259 interrupts. And we
>>>>>>> want the
>>>>>>> virq is the same value to hw-irq.
>>>>>>
>>>>>> Why?
>>>>>
>>>>> If the virq equals hw-irq, it's clear and simple to user.
>>>>
>>>> I don't think that's a good reason to over allocate.
>>>>
>>>> There's a reason we have virtual IRQs now.  Its
>> specifically to deal
>>>> with issues like the 16 interrupts for 8259 and not have
>> to do games
>>>> to offset IRQs.
>>>>
>>>> If we needed create some debugfs or sysfs info that translates VIRQ
>>>> to HW irq
>>>>
>>>
>>> I know that's the advantage of virtual IRQs. But in this
>> platform, we
>>> want to fix up the virq to hwirq and let users know which irq is
>>> coming
>>> from which devices.
>>
>> But how do I know IRQ 42 is really 26 for the MPIC.  What are you
>> users doing that they can't handle the virtual irq concept?
>>
>> It was pointed out, that you are coupling the IRQ # in the .dts with
>> the kernel virtual number which is a bad idea.  In theory the device-
>> tree description shouldn't be coupled this tightly to the kernel.
>>
>> I think the Freescale reference boards should strive to show people
>> how to do things properly since people tend to copy this code
>> and use
>> it as a starting point.  I doubt most 86xx designs are really going
>> to have an 8259 controller on them and thus making things focus
>> around it seems silly.
>>
> Hi, Kumar,
>
> I have used the a fake interrupt hole to avoid the hwirq overlapping.
> Now the virq equals the hwirq.

For what's written into the register, sure.. But who cares about  
that.  You still have to know that virq 16 equals internal mpic irq  
0.  What's written into vector field of the mpic register isn't too  
terribly useful to the user.

> I agree with the virq has lots of advantages than irq offset. But  
> we can
> not give the user a fixup irq list since the virq will be changed by
> different device driver loading. And the user can not get the hwirq  
> from
> the user space application.

I'm confused, what are users doing that they need to deal with this?

> I think creating some debugfs or sysfs info that translates VIRQ to HW
> irq is a _good_ idea, or just add some fields (irq host, hwirq) in
> /proc/interrupts. If we have this, I'll fix all irqs in dts file and
> remove the fake irq hole.
>
> Before we have a virq-hwirq mapping list, I keep my option about  
> the irq
> number.

You need to explain what people are doing that they need this  
information.  You are implying there would be some functionality lost  
by removing the offset.  As far as I can tell this is just a debug  
convenience.

- k