linux-mips
[Top] [All Lists]

Re: [PATCH] provide functions for gpio configuration

To: Linux-Mips List <linux-mips@linux-mips.org>
Subject: Re: [PATCH] provide functions for gpio configuration
From: Phil Sutter <n0-1@freewrt.org>
Date: Wed, 29 Oct 2008 22:10:46 +0100
In-reply-to: <200810292107.43818.florian@openwrt.org>
Mail-followup-to: Linux-Mips List <linux-mips@linux-mips.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <1225310409-4440-1-git-send-email-n0-1@freewrt.org> <200810292107.43818.florian@openwrt.org>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.11
Hi Florian,

On Wed, Oct 29, 2008 at 09:07:42PM +0100, Florian Fainelli wrote:
> Le Wednesday 29 October 2008 21:00:09 Phil Sutter, vous avez écrit :
> > As gpiolib doesn't support pin multiplexing, it provides no way to
> > access the GPIOFUNC register. Also there is no support for setting
> > interrupt status and level. These functions provide access to them and
> > are needed by the CompactFlash driver.
> 
> Right, but we do have interrupt level and status fuctions, registered as 
> callbacks to an extended gpiochip structure. These two functions can remain 
> static to the gpio.c file since we should perform interrupt status and level 
> initialisation at gpiochip init time. Not sure which code you based your work 
> on, but linux-queue tree at linux-mips.org has such code.

Yes it does, but that's not part of gpiolib itself. Accessing them needs
a combination of gpio_to_chip() and container_of() to be used, which I
doubt makes sense on a device with a single, platform gpio chip.

> - GPIO initialisation should be done right after gpiochip registering

I'm not sure if this is absolutely true. The original CompactFlash
driver e.g. clears interrupt level in cf_irq_handler() and sets it in
prepare_cf_irq(). The latter function is called more than once.

> I would be rather in favor of adding the other missing callbacks to the 
> rb532_gpio_chip and make them look like the standard get/set functions. Just 
> like what was done with the interrupt level and status functions.

That could be a solution. Having both methods accessing the same data is
no choice anyway. I'll prepare a patch when I have time to.

Greetings, Phil

<Prev in Thread] Current Thread [Next in Thread>