Hi Chris,
some ideas:
On Monday 31 July 2006 23:23, Chris Boot wrote:
> Yes I was thinking that a GPIO is a resource a little like an IRQ and
> thinking of a registration and ownership system as well. I'm glad somebody
> came up with that suggestion!
>
> The access API is, as you say, more difficult. The access methods for slow
> GPIOs is indeed very simple but I can't think of any way to provide
> (near-)direct access for faster accesses in a portable way. Does anyone
> have any suggestions?
Maybe three kind of API. One for fastest access: The driver request the GPIO
itself from the GPIO management and has to share some kind of locking
mechanism with the other API to avoid conflicts when accessing the registers
to manipulate this GPIO. This could be the way an I2C driver works to be as
fast as possible. Buts its achitecture specific.
The second API is slower and supports some functions to manipulate the GPIOs
at higer lever. This API would be architrecture independend but for use in
the kernel only.
The third API I like to have is for some slow GPIO. They should be accessible
from user space in an easy way. For example through some entries in sysfs the
user can access with simple "cat" and "echo" commands.
Alltogether share the GPIO management and the locking mechanism.
Juergen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
