Re: [patch/rfc 2.6.19-rc5] arch-neutral GPIO calls

On Mon, Nov 20, 2006 at 09:35:38PM -0800, David Brownell wrote:
On Monday 20 November 2006 9:09 pm, Bill Gatliff wrote:
It seems like the point
here is to help a driver find and assert their GPIO _pin_ so that the
driver can can talk to the attached external hardware.

Updating the GPIO controller is always (all architectures!) done in terms
of a number mapping to some controller and a bit number, not a pin. The
drivers never care about pins.

The only thing that cares about pins is board setup code -- briefly.

That's rather simplifying things. The driver using the GPIO number isn't
going to care about the pin number that it's associated with, but that's
not to say that another driver won't have an interest in the alternate
function of the pin that the GPIO is tied to, while the first driver is
expecting it to be used as a GPIO.

There is a need to layer a pin mux API underneath the GPIO API to deal
with these sorts of things, but that's obviously up to the platform to
take care of, and I think your API is a fairly good staging ground for
building up the layering in the platform parts.

Claiming that we set the pins once in the board setup code and then
forget about it is not realistic. I can't imagine anyone with many
different pin functions under mux (OMAP2 does too) seriously taking that
position.

So given that, I would argue that drivers _do_ care about the pins, just
not through the GPIO API.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [PATCH] atmel_serial: update the powersave handler to match serial core
    ... I think that a driver can do the request to a the gpio layer (may can be implemented ... pin change interrupt. ... For waking up, we need to switch on the main oscillator, wait until it ...
    (Linux-Kernel)
  • Re: [patch/rfc 2.6.19-rc5] arch-neutral GPIO calls
    ... For OMAP, those names can map one-to-one to integers. ... So the "gpio number" in AT91 would, as it turns out, also encode the line number in the lower 6 bits, and the controller number in the bits above that. ... Perhaps yet another reason why the gpio_request function might want to look at the hardware state--- so that drivers that aren't using the new API are still known to the GPIO resource manager by virtue of the signature they leave behind in the hardware configuration (you might not be able to detect that they're using a GPIO line, but you would be able to detect that a pin had been assigned to a non-GPIO function). ... HOW that is established is indeed explicitly left out of the driver itself, but it's awfully nice when there's a facility somewhere that can do it on the driver's behalf. ...
    (Linux-Kernel)
  • [patch -mm 00/20] chardev: GPIO for SCx200 & PC8736x: Intro
    ... GPIO SUPPORT FOR SCx200 & PC8736x ... The patch-set reworks the 2.4 vintage scx200_gpio driver for modern ... The vintage driver expresses the pin capabilities with pin-mode ...
    (Linux-Kernel)
  • Re: [patch/rfc 2.6.19-rc5] arch-neutral GPIO calls
    ... driver can can talk to the attached external hardware. ... Updating the GPIO controller is always done in terms ... of a number mapping to some controller and a bit number, ... If we can agree on syntax, and factoring pin mux separately (however it ...
    (Linux-Kernel)
  • Re: no sound with the new imac
    ... driver implementation and give a few debug hints. ... Pin Default 0x012b4050: HP Out at Ext Rear ... SELinux: Initializing. ... SELinux: Registering netfilter hooks ...
    (Linux-Kernel)