From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752104AbbJBWk1 (ORCPT ); Fri, 2 Oct 2015 18:40:27 -0400 Received: from devils.ext.ti.com ([198.47.26.153]:34837 "EHLO devils.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751294AbbJBWkX (ORCPT ); Fri, 2 Oct 2015 18:40:23 -0400 Subject: Re: [PATCH 2/2] gpio: omap: convert to use generic irq handler To: Linus Walleij References: <1443209283-20781-1-git-send-email-grygorii.strashko@ti.com> <1443209283-20781-3-git-send-email-grygorii.strashko@ti.com> CC: Alexandre Courbot , Santosh Shilimkar , Tony Lindgren , Linux-OMAP , Austin Schuh , , , "linux-gpio@vger.kernel.org" , "linux-kernel@vger.kernel.org" From: Grygorii Strashko Message-ID: <560F07CC.9050205@ti.com> Date: Fri, 2 Oct 2015 17:40:12 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/02/2015 03:17 PM, Linus Walleij wrote: > On Fri, Sep 25, 2015 at 12:28 PM, Grygorii Strashko > wrote: > >> This patch converts TI OMAP GPIO driver to use generic irq handler >> instead of chained IRQ handler. This way OMAP GPIO driver will be >> compatible with RT kernel where it will be forced thread IRQ handler >> while in non-RT kernel it still will be executed in HW IRQ context. >> As part of this change the IRQ wakeup configuration is applied to >> GPIO Bank IRQ as it now will be under control of IRQ PM Core during >> suspend. >> >> There are also additional benefits: >> - on-RT kernel there will be no complains any more about PM runtime usage >> in atomic context "BUG: sleeping function called from invalid context"; >> - GPIO bank IRQs will appear in /proc/interrupts and its usage statistic >> will be visible; >> - GPIO bank IRQs could be configured through IRQ proc_fs interface and, >> as result, could be a part of IRQ balancing process if needed; >> - GPIO bank IRQs will be under control of IRQ PM Core during >> suspend to RAM. >> >> Disadvantage: >> - additional runtime overhed as call chain till >> omap_gpio_irq_handler() will be longer now >> - necessity to use wa_lock in omap_gpio_irq_handler() to W/A warning >> in handle_irq_event_percpu() >> WARNING: CPU: 1 PID: 35 at kernel/irq/handle.c:149 handle_irq_event_percpu+0x51c/0x638() >> >> This patch doesn't fully follows recommendations provided by Sebastian >> Andrzej Siewior [1], because It's required to go through and check all >> GPIO IRQ pin states as fast as possible and pass control to handle_level_irq >> or handle_edge_irq. handle_level_irq or handle_edge_irq will perform actions >> specific for IRQ triggering type and wakeup corresponding registered >> threaded IRQ handler (at least it's expected to be threaded). >> IRQs can be lost if handle_nested_irq() will be used, because excecution >> time of some pin specific GPIO IRQ handler can be very significant and >> require accessing ext. devices (I2C). >> >> Idea of such kind reworking was also discussed in [2]. >> >> [1] http://www.spinics.net/lists/linux-omap/msg120665.html >> [2] http://www.spinics.net/lists/linux-omap/msg119516.html >> >> Tested-by: Tony Lindgren >> Tested-by: Austin Schuh >> Signed-off-by: Grygorii Strashko > > Patch applied. > Thanks. > I'm thinking that we need some recommendations on how to write > IRQ handlers in order to be RT-compatible. Can you help me lining > up the requirements in Documentation/gpio/driver.txt? > > I will write an RFC patch and let you write some additional text > to it in response then we can iterate it a bit. Sure. I'll try to help. -- regards, -grygorii