From patchwork Mon Apr 15 11:25:38 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Javier Martinez Canillas X-Patchwork-Id: 2444651 Return-Path: X-Original-To: patchwork-linux-omap@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id 215403FD8C for ; Mon, 15 Apr 2013 11:26:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756220Ab3DOL0D (ORCPT ); Mon, 15 Apr 2013 07:26:03 -0400 Received: from mail-ia0-f177.google.com ([209.85.210.177]:42152 "EHLO mail-ia0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754647Ab3DOL0B (ORCPT ); Mon, 15 Apr 2013 07:26:01 -0400 Received: by mail-ia0-f177.google.com with SMTP id w33so4227499iag.22 for ; Mon, 15 Apr 2013 04:25:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=NO6BZd6lo9hpEvye3XhHYADiA+dv6Xdmx+P/xC6Y/aw=; b=010qBXNoQOO8FGsVdQOslR1RGj7OKmeIc7VsBCaUCRcPI1+kYttPUNke7/5fSKHfSk mJBhPTVFM+DonQsSzejywO0e9ARK9toQ2qlWpVSxB6Mh6vpw3hgWuGiDuBiDk4qS35lb RA6sL2BrG+GTjgV8s1E8nDFz5vf7eV3/RBFFKkceYTNEuyKTsaZfG+9DjVIQiLxbAkGE wAx7xH7psWGjU4RS/h0YMEl3DJJNAI1IrFDAxrmQuTSDjxyv2MHgSeRtCRdsUczSwA/O Rt5Jwze3YePDp8y2819dfzAdo4K6vUtLPZA3TUWbzlLWPHj2pRCqgRSjF5mM+UBdLhki O7gg== X-Received: by 10.50.141.129 with SMTP id ro1mr4941898igb.39.1366025158813; Mon, 15 Apr 2013 04:25:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.71.2 with HTTP; Mon, 15 Apr 2013 04:25:38 -0700 (PDT) In-Reply-To: References: <1329321854-24490-1-git-send-email-b-cousson@ti.com> <4F47AD08.4030504@ti.com> <512D39DA.7020306@ti.com> <512D3AB1.1080202@wwwdotorg.org> <512D3EC2.6050408@ti.com> <20130302200524.D230F3E1571@localhost> <51391F41.5000303@ti.com> <514C79E1.4090106@wwwdotorg.org> <514CE0AB.6060207@ti.com> <515319D5.20105@wwwdotorg.org> <5155C902.7080207@wwwdotorg.org> <5165CB9D.1090202@wwwdotorg.org> <51671D7B.5060303@wwwdotorg.org> <51673D70.3010503@wwwdotorg.org> From: Javier Martinez Canillas Date: Mon, 15 Apr 2013 13:25:38 +0200 Message-ID: Subject: Re: [PATCH 3/5] gpio/omap: Add DT support to GPIO driver To: Linus Walleij Cc: Stephen Warren , Jon Hunter , Grant Likely , Alexandre Courbot , Stephen Warren , Kevin Hilman , "devicetree-discuss@lists.ozlabs.org" , "linux-omap@vger.kernel.org" , Tarun Kanti DebBarma , "linux-arm-kernel@lists.infradead.org" Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org On Sun, Apr 14, 2013 at 10:53 PM, Linus Walleij wrote: > On Sun, Apr 14, 2013 at 3:35 AM, Javier Martinez Canillas > wrote: > >> Is the following inlined patch [1] what you were thinking that would >> be the right approach? Hi Linus, thanks a lot for your feedback. > > This looks sort of OK, but I'm still struggling with the question of > what we could do to help other implementations facing the same issue. > Yes, I don't know how we can make it easier to other implementations (besides adding the irq_request hook to irq_chip) since the logic is GPIO controller specific. For example I took a look to drivers/gpio/gpio-tegra.c and if I understood correctly, the implementation for this driver should be something like this: .irq_ack = tegra_gpio_irq_ack, @@ -355,6 +360,7 @@ static struct irq_chip tegra_gpio_irq_chip = { #ifdef CONFIG_PM_SLEEP .irq_set_wake = tegra_gpio_wake_enable, #endif + .irq_request = tegra_gpio_irq_request, }; static const struct dev_pm_ops tegra_gpio_pm_ops = { This is definitely quite similar to the omap-gpio.c change but not the same. > This is a pretty hard design pattern to properly replicate in every such > driver is it not? > > Hmmmm > Is indeed a hard design pattern but I couldn't figure out a more generic way to handle this. Maybe we could use [1] for now to solve the issue that we have with OMAP GPIO and later when the same issue is found on other GPIO controllers and a similar change is made on these drivers we will see some form of pattern that emerge allowing us to make a later refactor to reduce the code duplication. Or do you have a better idea on how to solve this? > Yours, > Linus Walleij Best regards, Javier --- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/gpio/gpio-tegra.c b/drivers/gpio/gpio-tegra.c index 414ad91..a2d5c3d 100644 --- a/drivers/gpio/gpio-tegra.c +++ b/drivers/gpio/gpio-tegra.c @@ -346,6 +346,11 @@ static int tegra_gpio_wake_enable(struct irq_data *d, unsigned int enable) } #endif +static int tegra_gpio_irq_request(struct irq_data *d) +{ + tegra_gpio_request(NULL, d->hwirq); +} + static struct irq_chip tegra_gpio_irq_chip = { .name = "GPIO",