From patchwork Wed Apr 23 07:24:42 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Javier Martinez Canillas X-Patchwork-Id: 4039211 Return-Path: X-Original-To: patchwork-linux-omap@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 1C7F79F4DC for ; Wed, 23 Apr 2014 07:24:55 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id C5D59201DE for ; Wed, 23 Apr 2014 07:24:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7A5A820176 for ; Wed, 23 Apr 2014 07:24:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757213AbaDWHYp (ORCPT ); Wed, 23 Apr 2014 03:24:45 -0400 Received: from mail-wg0-f45.google.com ([74.125.82.45]:58704 "EHLO mail-wg0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756728AbaDWHYo (ORCPT ); Wed, 23 Apr 2014 03:24:44 -0400 Received: by mail-wg0-f45.google.com with SMTP id l18so446282wgh.28 for ; Wed, 23 Apr 2014 00:24:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rEtZEmi+Z/LQJgsivZS/2FusZ88hPntVKrx+e3jqEsU=; b=ZJKCN8RGEFK0cq7F+XZiGr66Zs3W33Kv4x/HCYuJLNWpGYOAV3M3zktEPvvwmv5Oqb JDQTKMdEegGNzZ1rAYDrO2CXdU30+goZwt8gMnqAm5InHnPb3GamDqUCaJtzSp19lY9w 5pVIEWf8raOa6DkD4TnJgSqyKMj0R0isJJpTGQmkylcZVFuti6ouSI6z3x15GkGnu5/V Hi+wuCacmOWTOHxf+XBaKQTPhU4+DisZEzx6GmBF/ZZAu/IlYg/lxK3rlm5HkotveBDQ c6mJoq/9nzNK12X6m/iaDD2zNTWVnsCPKDq2SqpDYFhgNDugqHSBYjzWRDCrDD1AI/2W RpjQ== X-Gm-Message-State: ALoCoQms+5HoFBYiI5Q0utzZF9FK52jZhadEMxzVcp9ZsyumjTG3IV5sAr1eJeIiSIfhF4Ax7bv+ MIME-Version: 1.0 X-Received: by 10.194.9.8 with SMTP id v8mr986717wja.53.1398237882918; Wed, 23 Apr 2014 00:24:42 -0700 (PDT) Received: by 10.180.8.33 with HTTP; Wed, 23 Apr 2014 00:24:42 -0700 (PDT) X-Originating-IP: [95.23.110.23] In-Reply-To: <20140423013022.GA18648@kahuna> References: <53566C20.6000208@ti.com> <53568706.1050204@ti.com> <5356E5E4.1060509@ti.com> <5356F2A4.6010106@ti.com> <20140423013022.GA18648@kahuna> Date: Wed, 23 Apr 2014 09:24:42 +0200 Message-ID: Subject: Re: regressions in linux-next? From: Javier Martinez Canillas To: Nishanth Menon Cc: Tony Lindgren , Santosh Shilimkar , Kevin Hilman , Linus Walleij , linux-omap , Peter Ujfalusi Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hello Nishanth and Tony, On Wed, Apr 23, 2014 at 3:30 AM, Nishanth Menon wrote: > On 01:08-20140423, Javier Martinez Canillas wrote: > [...] >> > on AM335x-sk: >> >> So this makes only am335x-sk to fail with the gpiolib irpchip >> >> conversion as reported by Peter and you. >> >> >> >> Do you know what special use of GPIO have this board to behave >> >> differently than the other boards? I've looked at the DTS but didn't >> >> find anything evident. >> > >> > I could not find anything interesting yet. Peter did mention that >> > reverting d04b76626e94 helped make the platform boot fine. I am trying >> > to add a few prints and see which specific line does things go bad.. >> > and if so why.. unfortunately, I am using the board remotely as well.. >> > Will try to track this down in the next few hours and post back. >> > >> >> Great, thanks a lot for your help and sorry for the inconvenience! > > Yep - If I am correct, and as we all suspected, GPIO0_7 which controls > the VTT regulator for DDR is getting configured as input, instead of > output. > http://slexy.org/raw/s2gReMRZI6 (with diff: > http://slexy.org/view/s20nueCE8H - ignore many of the prints as I was > trying to truncate and isolate - had to switch to non-relaxed versions > of writes to force sequencing with barriers to trace it down..) > > > Anyways, the key log is [0]: > gpiochip_irq_map -> calls > irq_set_irq_type(irq, chip->irq_default_type); > which inturn triggers: gpio-omap.c's gpio_irq_type > in this, logic: > if (!LINE_USED(bank->mod_usage, offset)) is invoked prior to > setting the input type for the GPIO 0_7 (you can see the logic > walks through setting every GPIO to input!). > > The original usage as far as I could discern was that this function was > only called after probe got completed as the gpio requests were > triggered. Thanks a lot for figuring out what was going on here. I think that is not correct for gpiochip_irq_map() to call this function. After all creating a mapping doesn't mean that the GPIO is actually used as an IRQ. > > There are probably many hacks possible, but a cleaner solution might > involve gpio_irqchip knowing when to set the type and knowing which gpios > not to mess with. > > Example hack: > Since we call gpiochip_irqchip_add with IRQ_TYPE_NONE, > in gpio-omap's gpio_irq_type could do: > if (type == IRQ_TYPE_NONE) > return 0; > boots, http://slexy.org/raw/s24M8lHqZX - but ofcourse, there'd be other > side effects I have'nt thought through.. Linus, what do you think of the following patch? From ede333e85e0320d32e8c2d123560808ed7e43ece Mon Sep 17 00:00:00 2001 From: Javier Martinez Canillas Date: Wed, 23 Apr 2014 09:13:54 +0200 Subject: [PATCH 1/1] gpio: don't call irq_set_irq_type() on IRQ domain map function Creating a mapping for a GPIO pin into the Linux virtual IRQ space does not necessarily mean that the GPIO is going to be used as an interrupt line, it only means that it could be used. So, calling irq_set_irq_type() is not correct since that is already done either when a driver calls request_irq() or when the OF core calls of_irq_to_resource() because a device node defined a GPIO controller phandle as its "interrupt-parent". In either case irq_set_irq_type() will be called and the GPIO controller driver will take any required action for an IRQ. Signed-off-by: Javier Martinez Canillas Tested-by: Peter Ujfalusi --- drivers/gpio/gpiolib.c | 1 - 1 file changed, 1 deletion(-) } diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index c12fe9d..b493781 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -1402,7 +1402,6 @@ static int gpiochip_irq_map(struct irq_domain *d, unsigned int irq, #else irq_set_noprobe(irq); #endif - irq_set_irq_type(irq, chip->irq_default_type); return 0;