On Monday 30 July 2012, Daniel Mack wrote:

On 30.07.2012 10:55, Haojian Zhuang wrote:

quoted

On Mon, Jul 30, 2012 at 4:34 PM, Daniel Mack [off-list ref] wrote:

quoted

On 30.07.2012 10:31, Arnd Bergmann wrote:

quoted

On Sunday 29 July 2012, Daniel Mack wrote:

quoted

And I also wonder whether using the second spec value for a priority
wouldn't be somehow abusive? Isn't that considered to denote the trigger
flags in contexts of interrupt controllers? At least, that is what
irq_domain_xlate_twocell() assumes.

You would not use irq_domain_xlate_twocell in that scenario but provide your
own, which is ok. Interpreting the second cell as the trigger flags is just
a convenient default because it's the most common use for that.

I see. Don't know how much sense it makes to have that detail
configurable though. Haojian? And I think we can still change that
detail later.

Arnd's suggestion is good. So we can setup each interrupt's priority
while parsing
all these pxa interrupts. In current code, we only assign priority
with the irq number.
Maybe it's not perfect solution. For example, Timer interrupt should
have highest
priority. LCD interrupt also has higher priority.

Arnd mentioned that instead of using the default
irq_domain_xlate_onecell(), we can hook up our own translation function.
While that is true, I wonder how that value that we send back in
*out_type will ever appear in the irq_chip callbacks. Looking at the
code that calls ->xlate(), I can see that irq_create_of_mapping() would
call irq_set_irq_type() with our passed value, which will then &= it
with IRQ_TYPE_SENSE_MASK (which is 0xf which doesn't suffice for our up
to 96 interrupts).

Arnd, either I don't get your point, or this would need some changes in
the irqdomain core. Could you elaborate a little?

When you have your own xlate function, you would still always set the default
flags (IRQ_TYPE_NONE), but you do record the priority from the flags
in the same way that at91_aic_irq_domain_xlate does.

	Arnd