On 03/09/2012 01:07 PM, Rob Herring wrote:
On 03/09/2012 12:45 PM, David Daney wrote:
[...]
Probably I have not explained well enough why legacy will not work.
We have three different interrupt controllers (although only one is
currently in-tree). hwirq to irq mapping for them is more or less as
follows:
I'll just repeat what others have said: if it's not upstream it doesn't
exist.
We have no knowledge about out of tree h/w to understand what you need
irq hwirqCIU hwirqCIU2 hwirqCIU3
----------------------------------------------------------------------
OCTEON_IRQ_USB0 56 81 934562
OCTEON_IRQ_TWSI 45 224 100543
OCTEON_IRQ_UART0 34 228 4572
.
.
.
How many actual hwirqs in each case and what is the range?
So for CIU3, it seems you would need to use a radix tree. CIU2 is
probably borderline depending on what is the max number. But because you
don't yet have code in tree for either yet, you can use a linear domain
for now. It shouldn't be hard to switch from linear to radix later.
Now what we notice here is that there is no possible 1:1 linearly
increasing mapping possible for the irq and *all* three hwirq sets. We
want a single binary that contains support for all three interrupt
controllers, so the OCTEON_IRQ_* values have to be the same for all
three interrupt controllers. Because of this, legacy mapping is
*impossible*.
OCTEON_IRQ_* values need to go. You may not have to do that now, but
certainly before doing support for CIU2 and CIU3 you do. Those platforms
should be DT only.
Since the possible ranges of the hwirq values is very large and quite
sparse, probably the radix mapping will be required.
Yes. You're not the only one with this issue.
Also to support non-OF drivers and architecture specific code for the
near future, I really think the existing IRQ values *must* be preserved.
For a legacy boot yes. But when you boot with DT, you should not need
them.
It is not a matter of how the system is booted, rather what all the
drivers are expecting...
This is certainly possible as several ARM platforms do this. You
need to start with minimal set of drivers enabled for DT and add them
back in 1 by 1.
What I don't understand about this is what happens during the transition?
What if a shared interrupt were referred from one non-OF driver by its
symbolic OCTEON_IRQ_? value, and from a second driver by its hwirq value
extracted from the DT? In that case you would be referring to the same
interrupt line by two different irq values, clearly that should be
prevented.
At a minimum, the change made for each converted driver would have to
include: removing the OCTEON_IRQ_? values, Maintain a list of hwirqs
that are outside of the domain and report this by the.map() function,
and then update this list.
David Daney
Rob
Therefore, as I said above, we need a way for my SOC/board code to
specify the mapping.
Perhaps we need to add an optional function to struct irq_domain_ops
that would allow the default mapping to be overridden on a per
irq_domain basis.
Otherwise, I think I will have to keep poking into the internal
irq_domain data structures to get the mappings I want.
What do you think?
David Daney
