Re: [PATCH 3/3] irq/irq_sim: implement irq_sim_irq2offset()
From: Marc Zyngier
Date: Wed Oct 18 2017 - 11:47:55 EST
On Wed, Oct 18 2017 at 2:49:07 pm BST, Bartosz Golaszewski <brgl@xxxxxxxx> wrote:
> 2017-10-18 12:13 GMT+02:00 Marc Zyngier <marc.zyngier@xxxxxxx>:
>>
>
> [snip!]
>
>> It looks to me that this is all because the irq_sim creation is a bit awkward.
>> You end-up with all kind of exotic interfaces because you don't know the base
>> of the irq range at creation time.
>>
>> How about something like this:
>>
>> diff --git a/kernel/irq/irq_sim.c b/kernel/irq/irq_sim.c
>> index 24caabf1a0f7..484c3544c0d1 100644
>> --- a/kernel/irq/irq_sim.c
>> +++ b/kernel/irq/irq_sim.c
>> @@ -49,7 +49,8 @@ static void irq_sim_handle_irq(struct irq_work *work)
>> * @sim: The interrupt simulator object to initialize.
>> * @num_irqs: Number of interrupts to allocate
>> *
>> - * Returns 0 on success and a negative error number on failure.
>> + * Returns the interrupt base on success and a negative error number
>> + * on failure.
>> */
>> int irq_sim_init(struct irq_sim *sim, unsigned int num_irqs)
>> {
>> @@ -78,7 +79,7 @@ int irq_sim_init(struct irq_sim *sim, unsigned int num_irqs)
>> init_irq_work(&sim->work_ctx.work, irq_sim_handle_irq);
>> sim->irq_count = num_irqs;
>>
>> - return 0;
>> + return sim->irq_base;
>> }
>> EXPORT_SYMBOL_GPL(irq_sim_init);
>>
>> You can then deal with the offset directly in your driver, as you're
>> guaranteed a 1:1 mapping.
>>
>
> This is what we have now in next for iio. The thing is we want to get
> rid of irq_base from the iio driver and store it (and relevant logic)
> in irq_sim to have less code in the caller. Otherwise we duplicate
> this info.
The IIO subsystem caching this information is a side effect of the way
it decides to deal with it. It is no different from the PCI layer
requesting 16 MSIs and having to work out which ones it got. It doesn't
go back to the irqchip to find out what's there.
How big is the saving on the IIO side?
Thanks,
M.
--
Jazz is not dead, it just smell funny.