lkml.org 
[lkml]   [2006]   [Dec]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 2.6.20-rc1 1/6] GPIO core
Hi!


> +Identifying GPIOs
> +-----------------
> +GPIOs are identified by unsigned integers in the range 0..MAX_INT. That
> +reserves "negative" numbers for other purposes like marking signals as
> +"not available on this board", or indicating faults.
> +
> +Platforms define how they use those integers, and usually #define symbols
> +for the GPIO lines so that board-specific setup code directly corresponds
> +to the relevant schematics. In contrast, drivers should only use GPIO

Perhaps these should not be integers, then?

typedef struct { int mydata } pin_t; prevents people from looking
inside, allows you to typecheck, and allows expansion in (unlikely) case where
more than int is needed? ...hotpluggable gpio pins?
> +Spinlock-Safe GPIO access
> +-------------------------
> +Most GPIO controllers can be accessed with memory read/write instructions.
> +That doesn't need to sleep, and can safely be done from inside IRQ handlers.
> +
> +Use these calls to access such GPIOs:
> +
> + /* GPIO INPUT: return zero or nonzero */
> + int gpio_get_value(unsigned gpio);
> +
> + /* GPIO OUTPUT */
> + void gpio_set_value(unsigned gpio, int value);
> +
> +The values are boolean, zero for low, nonzero for high. When reading the
> +value of an output pin, the value returned should be what's seen on the
> +pin ... that won't always match the specified output value, because of
> +issues including wire-OR and output latencies.
> +
> +The get/set calls have no error returns because "invalid GPIO" should have
> +been reported earlier in gpio_set_direction(). However, note that not all
> +platforms can read the value of output pins; those that can't should always
> +return zero.
> Also, these calls will be ignored for GPIOs that can't safely
> +be accessed wihtout sleeping (see below).

'Silently ignored' is ugly. BUG() would be okay there.

> +Platforms that support this type of GPIO distinguish them from other GPIOs
> +by returning nonzero from this call:
> +
> + int gpio_cansleep(unsigned gpio);

This is ugly :-(. But I don't see easy way around...


> +GPIOs mapped to IRQs
> +--------------------
> +GPIO numbers are unsigned integers; so are IRQ numbers. These make up
> +two logically distinct namespaces (GPIO 0 need not use IRQ 0). You can
> +map between them using calls like:
> +
> + /* map GPIO numbers to IRQ numbers */
> + int gpio_to_irq(unsigned gpio);
> +
> + /* map IRQ numbers to GPIO numbers */
> + int irq_to_gpio(unsigned irq);

. Don't we have irq_t already?

> +Those return either the corresponding number in the other namespace, or
> +else a negative errno code if the mapping can't be done. (For example,
> +some GPIOs can't used as IRQs.) It is an unchecked error to use a GPIO
> +number that hasn't been marked as an input using gpio_set_direction(), or

It should be valid to do irqs on outputs, if those outputs are really
tristates (wire-or or how you call it?)?

Pavel

--
Thanks for all the (sleeping) penguins.
-
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/

\
 
 \ /
  Last update: 2006-12-28 09:41    [from the cache]
©2003-2011 Jasper Spaans