Userspace GPIO

Userspace GPIO

[Federico Reghenzani]

Hi all,

not sure if this is the correct kernel mailing list, but it's related
to real-time applications.

I'm performing some tests with GPIO in Linux (with PREEMPT_RT patch,
but it's not currently important) and I noticed that user-space GPIO
via sysfs is very slow compared to kernel-space and this is obviously
expected, due to system calls overhead.

Then, i tried to map with ioremap() in the kernel and mmap() in the
user space the address of the memory-mapped GPIO register and I
noticed that on my platform (ARM, freescale imx6q) the kernel square
wave max frequency is ~5MHz compared to ~1.6MHz of user-space. In
theory, since both write in a virtual address mapped to a physical
address it should be the same (I verified the assembly of the kernel
module and of the user-space application and they have the same
instructions in the tested loop).

I concluded that the mmap() - since MAP_SHARED is required - sets the
VM_SHARED flag and the MMU of the ARM processor performs cache
coherency protocols that impact on GPIO switching performance, due to
the sharing flag in the page table.

I'm not sure if my analysis is correct, but, in that case, do you have
any other possible solution? Or a special flag for the mmap could be
proposed? In real-time application the performance of GPIO is often
important, and a 4x degradation from kernel-space to user-space can be
significant.


Cheers,
Federico Reghenzani

RE: Userspace GPIO

[Marco Candiago]

Thanks fellas,

I will investigate these options

Cheers,

Marco

-----Original Message-----
From: Juha Yrjölä [mailto:juha.yrjola@nokia.com]
Sent: Wednesday, May 17, 2006 7:49 PM
To: balrogg@gmail.com
Cc: Marco Candiago; linux-omap-open-source@linux.omap.com
Subject: Re: Userspace GPIO

andrzej zaborowski wrote:

> You could create it by modifying one of the drivers already present in
> the tree, I know the Intel PXA hackers have one of these and use it as
> a keypad driver because each key is associated with one GPIO line on
> their boards.

Or you could GPIO switch framework (arch/arm/plat-omap/gpio-switch.c),
which interfaces to user-space using sysfs.  It will need a small amount
of work to operate properly with the platform_data mechanism, though.

Cheers,
Juha


--------------------------------------------------------------------------
This email and any attachments may be confidential. They may contain legally
privileged information or copyright material. You should not read, copy,
use or disclose them without authorisation. If you are not an intended
recipient, please contact us at once by return email and then delete both
messages. We do not accept liability in connection with computer virus,
data corruption, delay, interruption, unauthorised access or unauthorised
amendment. This notice should not be removed.

Re: Userspace GPIO

[Juha Yrjölä]

andrzej zaborowski wrote:

> You could create it by modifying one of the drivers already present in
> the tree, I know the Intel PXA hackers have one of these and use it as
> a keypad driver because each key is associated with one GPIO line on
> their boards.

Or you could GPIO switch framework (arch/arm/plat-omap/gpio-switch.c), 
which interfaces to user-space using sysfs.  It will need a small amount 
of work to operate properly with the platform_data mechanism, though.

Cheers,
Juha

Re: Userspace GPIO

[andrzej zaborowski]

[-- Attachment #1: Type: text/plain, Size: 3458 bytes --]

Hi Marco,

On 17/05/06, Marco Candiago <Marco.Candiago@nicta.com.au> wrote:
>
> Matt, Richard,
>
> Thanks for your replies.
>
> Matt,
>
>         devmem2 does do the job and is ridiculously easy to use.
>
> Richard,
>
>  I understand what you are saying, but I simply do not know how to
> create a proxy of this nature.  Do you have any recommended
> documentation that would
> Enlighten me.

You could create it by modifying one of the drivers already present in
the tree, I know the Intel PXA hackers have one of these and use it as
a keypad driver because each key is associated with one GPIO line on
their boards. I don't know the name of the driver they use but I found
two similar drivers in the kernel.org tree:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=46d66037b917c5851222b56af77f4b158ce793aa;hb=0c056c50a6218e0e577817c16ba8851af593d742;f=drivers/char/cs5535_gpio.c
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=664a6e97eb1a8012475625af6383825a3d885e20;hb=0c056c50a6218e0e577817c16ba8851af593d742;f=drivers/char/scx200_gpio.c
I imagine you would have to throw out the device specific code from
them and replace the *_gpio_read and *_gpio_write functions with calls
to omap_set_gpio_datain() and omap_set_gpio_dataout().

>
> Marco
>
>
> -----Original Message-----
> From: linux-omap-open-source-bounces@linux.omap.com
> [mailto:linux-omap-open-source-bounces@linux.omap.com] On Behalf Of
> Woodruff, Richard
> Sent: Tuesday, May 16, 2006 10:10 PM
> To: Matt Callow
> Cc: linux-omap-open-source@linux.omap.com
> Subject: RE: Userspace GPIO
>
> > Since the GPIO lines are mapped into the ARM memory space, you can use
> a
> > program like devmem2 to access the memory locations directly. Maybe
> not
> > the most elegant solution but I've used the program successfully on an
> > OMAP board. Try searching for devmem2.c in google.
>
> I wouldn't recommend that.  32 GPIOs are controlled per register.  A
> direct user space write with out any locking could destroy the state of
> a gpio owned by someone else.  If someone really wanted to use it, then
> some proxy between (/proc/sys/syscall) to the real kernel API should be
> created.  It might be fun to have some notification method if the GPIO
> were configured as an interrupt source.
>
> Regards,
> Richard W.
> _______________________________________________
> Linux-omap-open-source mailing list
> Linux-omap-open-source@linux.omap.com
> http://linux.omap.com/mailman/listinfo/linux-omap-open-source
>
> --------------------------------------------------------------------------
> This email and any attachments may be confidential. They may contain legally
> privileged information or copyright material. You should not read, copy,
> use or disclose them without authorisation. If you are not an intended
> recipient, please contact us at once by return email and then delete both
> messages. We do not accept liability in connection with computer virus,
> data corruption, delay, interruption, unauthorised access or unauthorised
> amendment. This notice should not be removed.
> _______________________________________________
> Linux-omap-open-source mailing list
> Linux-omap-open-source@linux.omap.com
> http://linux.omap.com/mailman/listinfo/linux-omap-open-source
>

Regards,
Andrew
-- 
balrog 2oo6

Dear Outlook users: Please remove me from your address books
http://www.newsforge.com/article.pl?sid=03/08/21/143258

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

RE: Userspace GPIO

[Marco Candiago]

Matt, Richard,

Thanks for your replies.

Matt,

	devmem2 does do the job and is ridiculously easy to use.

Richard,

 I understand what you are saying, but I simply do not know how to
create a proxy of this nature.  Do you have any recommended
documentation that would
Enlighten me.

Marco


-----Original Message-----
From: linux-omap-open-source-bounces@linux.omap.com
[mailto:linux-omap-open-source-bounces@linux.omap.com] On Behalf Of
Woodruff, Richard
Sent: Tuesday, May 16, 2006 10:10 PM
To: Matt Callow
Cc: linux-omap-open-source@linux.omap.com
Subject: RE: Userspace GPIO

> Since the GPIO lines are mapped into the ARM memory space, you can use
a
> program like devmem2 to access the memory locations directly. Maybe
not
> the most elegant solution but I've used the program successfully on an
> OMAP board. Try searching for devmem2.c in google.

I wouldn't recommend that.  32 GPIOs are controlled per register.  A
direct user space write with out any locking could destroy the state of
a gpio owned by someone else.  If someone really wanted to use it, then
some proxy between (/proc/sys/syscall) to the real kernel API should be
created.  It might be fun to have some notification method if the GPIO
were configured as an interrupt source.

Regards,
Richard W.
_______________________________________________
Linux-omap-open-source mailing list
Linux-omap-open-source@linux.omap.com
http://linux.omap.com/mailman/listinfo/linux-omap-open-source

--------------------------------------------------------------------------
This email and any attachments may be confidential. They may contain legally
privileged information or copyright material. You should not read, copy,
use or disclose them without authorisation. If you are not an intended
recipient, please contact us at once by return email and then delete both
messages. We do not accept liability in connection with computer virus,
data corruption, delay, interruption, unauthorised access or unauthorised
amendment. This notice should not be removed.

RE: Userspace GPIO

[Woodruff, Richard]

> Since the GPIO lines are mapped into the ARM memory space, you can use
a
> program like devmem2 to access the memory locations directly. Maybe
not
> the most elegant solution but I've used the program successfully on an
> OMAP board. Try searching for devmem2.c in google.

I wouldn't recommend that.  32 GPIOs are controlled per register.  A
direct user space write with out any locking could destroy the state of
a gpio owned by someone else.  If someone really wanted to use it, then
some proxy between (/proc/sys/syscall) to the real kernel API should be
created.  It might be fun to have some notification method if the GPIO
were configured as an interrupt source.

Regards,
Richard W.

Re: Userspace GPIO

[Matt Callow]

Marco Candiago wrote:
> Hello,
>
> We are developing with the Innovator 1510 2.6.12-rc2-omap1 kernel
> version.
>
> Going through the archives I see that a similar type of question has
> been a
> Asked regarding accessing the GPIO lines via user-space; the answer
> being just a link to the mailing list archives.
>
> With this kernel is there a convenient method of toggling the GPIO lines
> without having to resort to kernel space programming. With some other
> hardware I have seen using Linux, it is possible to access the GPIO
> lines via a /proc entry, however, I don't see that here.
>
>   
Since the GPIO lines are mapped into the ARM memory space, you can use a 
program like devmem2 to access the memory locations directly. Maybe not 
the most elegant solution but I've used the program successfully on an 
OMAP board. Try searching for devmem2.c in google.

Matt

Userspace GPIO

[Marco Candiago]

Hello,

We are developing with the Innovator 1510 2.6.12-rc2-omap1 kernel
version.

Going through the archives I see that a similar type of question has
been a
Asked regarding accessing the GPIO lines via user-space; the answer
being just a link to the mailing list archives.

With this kernel is there a convenient method of toggling the GPIO lines
without having to resort to kernel space programming. With some other
hardware I have seen using Linux, it is possible to access the GPIO
lines via a /proc entry, however, I don't see that here.

I apologize if this question is obtuse, but any help would be greatly
Appreciated.

Thanks,

Marco 

--------------------------------------------------------------------------
This email and any attachments may be confidential. They may contain legally
privileged information or copyright material. You should not read, copy,
use or disclose them without authorisation. If you are not an intended
recipient, please contact us at once by return email and then delete both
messages. We do not accept liability in connection with computer virus,
data corruption, delay, interruption, unauthorised access or unauthorised
amendment. This notice should not be removed.