Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752775Ab0AHHn4 (ORCPT ); Fri, 8 Jan 2010 02:43:56 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752620Ab0AHHnz (ORCPT ); Fri, 8 Jan 2010 02:43:55 -0500 Received: from outbound.icp-qv1-irony-out2.iinet.net.au ([203.59.1.107]:45311 "EHLO outbound.icp-qv1-irony-out2.iinet.net.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752604Ab0AHHnz convert rfc822-to-8bit (ORCPT ); Fri, 8 Jan 2010 02:43:55 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUBAGZwRkt8qNTn/2dsb2JhbAAI1CSELwQ X-IronPort-AV: E=Sophos;i="4.49,241,1262534400"; d="scan'208";a="594791035" Subject: Re: [PATCH] gpio: introduce gpio_request_one() and friends Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ben Nizette In-Reply-To: Date: Fri, 8 Jan 2010 18:43:49 +1100 Cc: David Brownell , linux-kernel , Andrew Morton Content-Transfer-Encoding: 8BIT Message-Id: References: To: Eric Miao X-Mailer: Apple Mail (2.1077) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1829 Lines: 34 On 08/01/2010, at 6:16 PM, Eric Miao wrote: > On Fri, Jan 8, 2010 at 2:08 PM, Ben Nizette wrote: >> >> On 08/01/2010, at 4:14 PM, Eric Miao wrote: >> >>> commit 29cd35f57699fd93a12132186d52109a55ed57e7 >>> Author: Eric Miao >>> Date: Fri Jan 8 12:16:28 2010 +0800 >>> >>> gpio: introduce gpio_request_one() and friends >>> >>> gpio_request() without initial configuration of the GPIO is normally >>> useless, introduce gpio_request_one() together with GPIOF_ flags for >>> input/output direction and initial output level. >> >> Well yea it is useless without initial configuration but I've always done that configuration before any gpiolib calls. The initial direction and state stuff really has to be set up and pin-mux or gpio-chip-activate time otherwise it'll glitch; by the time we get to gpio_request time I've got everything just how I like it and just want the refcount aspect of gpio_request. >> > > The hardware will anyway glitch if the pin mux and GPIO registers are > different, which is almost true on every platform. The problem is not > to prevent GPIO from being glitch, but how to survive GPIO glitch. Well not if you bunt the port mux calls to after the gpio initialisation stuff so none of the glitches actually make it to the pin.. .. but OK, I see the point of this patch. I guess my real issue belongs in another patchset; to change the platforms I deal with to allow gpiolib calls before the portmux ones (and make sure the portmux calls don't trounce the gpiolib setup). Thanks, --Ben.-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/