From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751646AbdJRPru (ORCPT <rfc822;w@1wt.eu>);
        Wed, 18 Oct 2017 11:47:50 -0400
Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:42888 "EHLO
        foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1750742AbdJRPrt (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 18 Oct 2017 11:47:49 -0400
From: Marc Zyngier <marc.zyngier@arm.com>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Thomas Gleixner <tglx@linutronix.de>,
        Jonathan Cameron <Jonathan.Cameron@huawei.com>,
        Lars-Peter Clausen <lars@metafoo.de>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] irq/irq_sim: implement irq_sim_irq2offset()
In-Reply-To: <CAMRc=MfTrrg3_WUoabZxrQZr4aM_UOGvmoGrqR3yFmPmhNB-6Q@mail.gmail.com>
        (Bartosz Golaszewski's message of "Wed, 18 Oct 2017 14:49:07 +0200")
Organization: ARM Ltd
References: <20171005124446.26265-1-brgl@bgdev.pl>
        <20171005124446.26265-4-brgl@bgdev.pl>
        <e1f7141c-8688-8b15-2cc2-24c1d0678713@arm.com>
        <CAMRc=McsPhPgxY_-ZD6SYJy4bed4uQXmYyvedRbCaMgFV6gbZw@mail.gmail.com>
        <e5d643d2-94d7-acdf-ef87-0b490f6fb8c5@arm.com>
        <CAMRc=MfTrrg3_WUoabZxrQZr4aM_UOGvmoGrqR3yFmPmhNB-6Q@mail.gmail.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)
Date: Wed, 18 Oct 2017 16:47:45 +0100
Message-ID: <87d15kjw4e.fsf@on-the-bus.cambridge.arm.com>
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Oct 18 2017 at  2:49:07 pm BST, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> 2017-10-18 12:13 GMT+02:00 Marc Zyngier <marc.zyngier@arm.com>:
>>
>
> [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.