RFC Interrupt chip consolidation

Quoted 27 lines · Lars-Peter Clausen

Quoted 1 line · Thomas Gleixner

[...]

I've also noticed that all my chained demuxer handlers follow a similar scheme and a quick grep for generic_handle_irq revealed that quite a few other implementations also follow a similar scheme as well.

Something along the lines of ...

void irq_gc_chained_demux_handler(unsigned int irq, struct irq_desc *desc)

{
	struct irq_chip_generic *gc = irq_desc_get_handler_data(desc);
	struct irq_chip_type *ct = gc = irq_chip_generic_current_chip_type(gc);
	unsigned long pending = irq_reg_readl(ct->regs.pending);

	pending = irq_reg_readl(ct->regs.pending) & gc->mask_cache;

	for_each_set_bit (irq, &pending, gc->irq_cnt)
		generic_handle_irq(gc->irq_base + irq);
}

... could be used to replace those custom handlers in an irq_chip_generic based implementation.

With this the diffstat for JZ4740 looks even better:

 4 files changed, 91 insertions(+), 232 deletions(-)

Quoted 4 lines

Unfortunately it doesn't completely fit into the current irq_chip_generic implementation. For one there is no irq_chip_generic_current_chip_type, but I guess that could be implementing by adding a field to irq_chip_generic pointing to the current chip type. On the other hand I'm not sure if it is necessary to

No, you can get the current chip from irq_data.chip which always has a pointer to the current active one. container_of will give you the generic chip.

Quoted 8 lines

have different pending registers for different chip types of the same irq_chip_generic.

Another issue is that while the gpio unit on the JZ4740 supports different trigger modes it only supports either rising or falling edge at one time. So since it doesn't makes sense to implement switching between those two in a driver triggering in both edges is emulated by the irq chip.

That's what about 5 dozen other irq chips do as well.