From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9C4E4C4361B for ; Mon, 7 Dec 2020 12:35:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 694AD233F7 for ; Mon, 7 Dec 2020 12:35:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727126AbgLGMfR (ORCPT ); Mon, 7 Dec 2020 07:35:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50438 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726370AbgLGMfR (ORCPT ); Mon, 7 Dec 2020 07:35:17 -0500 Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 00455C0613D1 for ; Mon, 7 Dec 2020 04:34:30 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id q8so14704228ljc.12 for ; Mon, 07 Dec 2020 04:34:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=boKMjDjJa5tRLm1VPCUmtsYmlC2fesJJoaLCTYk8EUo=; b=XRCkYUCdOmvRRAtRW3hi67kI3cSeDfNcypHvLS8jdjZZe/bAI5psCeUuTET6Ap9u/a 5vY1eRHmi2x5zg4MXni5dltguovscn5Vx3S8VYcRZaFkS6Xh6yKIhlvAz9GaKMKYZ2jL bypClOGEwkbSDSCtYJUpOdXlkMHCfpDbv5lgyAMEqIRY6tCKHpMjxBMym9nMiaNZpZ4r qkGb4ZLSq7dUPqVo0McnPOil2TXOvm33hPJK/S4rEnAIB7HVJ2nl+1UdMreUuvqDVSgl bAs2J7FdEnjl0ku+0IfuhgiDcU/fYPx1YUxP0BS5VEkva4tHgDXe73Iv5BD+lKX1cXYe hkjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=boKMjDjJa5tRLm1VPCUmtsYmlC2fesJJoaLCTYk8EUo=; b=btkjXwz1rcRymkmk6xD78gcIMFoqpILNqL6bgO+Vm1SJIdXrU7n+9o2iut57+p2bYy MQ+TlahqfHoU2Shl3GL88nXp0Z3ZAOZ+Y1bXAo5dGwXs8EK2Gr6B+kDiB1yYvcbzbJVN JLNSfq/z15d2tisjuMc2eweVNBTdFKIZ2/XpSt4TOzZ/q/fUXi2fsAmFtXAcWJzwrskx VgR4WRHnZdbCbmDuD2bt7fCs6UTkWuZnSBpYa1TK8E4i2iTTAn3rLTJB0PG797JK2igR WxNi0IkipOwwX23TIDaBQgcwQWlZn5xIks8mxGWnsg5R0hr5sm6yiO387RNrHnQq4WUw wmFQ== X-Gm-Message-State: AOAM5327NdysAlHFdhtAeMCciUeOfekrKbIsSx6qYoH0ToDodUuyQVWG WsGtTaCLA5xp+6r/Vn+khwQAZzuohPpoMYPqxdO2dYfTDctp8WPy X-Google-Smtp-Source: ABdhPJxCMdxWp9BFOclJM4l0os50hx76oBCQDWSP9Mz1ISgEte4ORw7PcLsLj6UH4DkqJ6zlcpFPOuTE9rfLfpwTh4Y= X-Received: by 2002:a2e:321a:: with SMTP id y26mr8487351ljy.293.1607344469350; Mon, 07 Dec 2020 04:34:29 -0800 (PST) MIME-Version: 1.0 References: <1jeek5ps3b.fsf@starbuckisacylon.baylibre.com> <1jtusxkh6v.fsf@starbuckisacylon.baylibre.com> In-Reply-To: <1jtusxkh6v.fsf@starbuckisacylon.baylibre.com> From: Linus Walleij Date: Mon, 7 Dec 2020 13:34:18 +0100 Message-ID: Subject: Re: 0001-add-amlogic-gpio-to-irq To: Jerome Brunet , Marc Zyngier Cc: Andy Shevchenko , =?UTF-8?B?5p6X5Zyj5qyi?= , khilman , narmstrong , "martin.blumenstingl" , linux-gpio , linux-arm-kernel , linux-amlogic , linux-kernel Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 7, 2020 at 12:07 PM Jerome Brunet wrote: > On Mon 07 Dec 2020 at 11:18, Andy Shevchenko wrote: > > On Fri, Dec 4, 2020 at 4:25 PM Jerome Brunet wrote: > >> On Fri 04 Dec 2020 at 10:13, Linus Walleij wrote: > > > >> This HW only has 8 irqs that can each be mapped to a pin. No direct > >> translation can be made, we have to allocate an irq to monitor the line. > >> So when gpio_to_irq() was called, we had to do that allocation dynamically > >> to return a valid irq number. Since there was no counter part to > >> gpio_to_irq(), those allocation cannot be freed during the lifetime of > >> the device. gpio_to_irq() is just a helper really and should not really be used to allocate anything. In device tree systems, the GPIO provider should nominally present itsel as a dual-mode gpio-controller and interrupt-controller for example: gpio1: gpio@4e000000 { compatible = "cortina,gemini-gpio", "faraday,ftgpio010"; reg = <0x4e000000 0x100>; interrupts = <23 IRQ_TYPE_LEVEL_HIGH>; resets = <&syscon GEMINI_RESET_GPIO1>; clocks = <&syscon GEMINI_CLK_APB>; gpio-controller; #gpio-cells = <2>; interrupt-controller; #interrupt-cells = <2>; }; The GPIOs are normally *not* translated to IRQs in this set-up. Rather the interrupts are requested by consumers using request_[threaded_]irq() which means you should be using the irqchip callbacks such as .irq_request_resources() and .irq_release_resources() to allocate one of the free irq lines to use. These will be called at the right points if a properly written driver requests an IRQ and when the driver is removed. In some rare cases gpio_to_irq() is used because all the driver knows is a GPIO number and it want to try to obtain an IRQ for it, and if a 1-to-1 mapping exists it returns this number. This is not the norm, but the exception. So maybe the problem is that you need to go back and think about updating the DT bindings for this thing to include interrupt-controller as well? > * This HW has to create the mapping between GPIO and irq number > dynamically. The number of irqs available is very limited. This should be done using irq_chip callbacks. > * We only get to know a mapping is required when gpio_to_irq() is called No that callback should not be used for that. > * There is no way to know when it is safe to dispose of the created > mapping The way that is done is when .irq_release_resources() is called. > * Some drivers require a trigger type we don't support. These will create > mappings and not use it because of the failure when .set_type() is > called I don't quite understand this. Do you mean you are bombarded by pointless requests for interrupts that will not work anyways? Then do not assign interrupts to these drivers in the device tree. These requesting devices and their requests are under your control. The drivers should be able to back out and work without interrupt if request_irq() fails because it can't provide the type on interrupt you want: int irq = request_irq(irq, my_isr, IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING, "My ISR", cookie); // This results in .irq_request_resources() and .irq_set_type() if (irq < 0) { // Oopps out of IRQs or couldn't support double edges, bail out or use polling } Just do it like this (you might have to augment your drivers) and you'll be fine? > To answer your question, there an API which lets us know a mapping is > needed, but none to inform that it is not required anymore. The GPIO API > was not meant to used like this. Not saying it is good or bad, this is > just how it is. So don't use it? Yours, Linus Walleij