Tony Lindgren <tony@xxxxxxxxxxx> writes:
> * Tero Kristo <t-kristo@xxxxxx> [110622 09:38]:
[...]
>> +struct omap_prcm_irq __initdata omap_prcm_3xxx_irqs[] = {
>> + OMAP_PRCM_IRQ("wkup", 0,
>> + CHIP_IS_OMAP3430 | CHIP_GE_OMAP3630ES1_1),
>> + OMAP_PRCM_IRQ("evgenon", 2,
>> + CHIP_IS_OMAP3430 | CHIP_GE_OMAP3630ES1_1),
>> + OMAP_PRCM_IRQ("evgenoff", 3,
>> + CHIP_IS_OMAP3430 | CHIP_GE_OMAP3630ES1_1),
> ...
>
> Please note consider that this data will be coming from device
> tree and will disappear from here. We won't be merging any new
> data after v3.1 unless it comes from device tree.
Personally, I don't think this qualifies as device-tree data. At least
not yet, since the device tree does not currently handle this type of
thing since it's not a real interrupt controller.
Even for the newly proposed (but not merged) irq_domain stuff in the
device tree to work, there needs to be an irq_desc for each of the
"linux IRQs" (to use the term from the irq_domain stuff), so the above
mapping of names needs to exist in order to create the irq_descs so that
irq_domains can even work.
Also, until the rest of our IRQ infrastructure is converted to device
tree (which will also need irq_domains), and until there is a way to
describe the PRCM in the device tree, I don't think it makes sense to
use device tree to describe this small amount of data (which is also
__initdata.)
> So this too will need to be converted because we won't be able to add
> support for new omaps otherwise.
For small amounts of data like this, I think we can.
As long as we're working on the device tree for the big items, I think
we can make a case that items like this belong in the kernel. In my
opinion, just because it's data, doesn't mean it always belongs in the
device tree. Some kinds of data will always be needed to create
infrastructure even for the device tree to work. I think interrupts are
one of those items.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
