On Thursday, August 19, 2010 04:02:34 Stefano Babic wrote: > Of course, you could write a kernel module that does more thing in > kernel using gpiolib (I mean, you could replace for example gpio_clock > with a single system call, an ioctl for your driver). However, you will > miss the possibility to run on different architectures and you have > dependencies with your kernel.
i think it would be easy to write an arch-independent kernel driver. as long
as you stick to the generic GPIO interface (linux/gpio.h), there shouldnt be a
problem. just push the pin request off to userspace via an ioctl or
something.
> I changed as suggested by Mike my first implementation replacing direct
> I/O operations (open/close/write) with the stream functions (fopen,
> etc). Even if I set them as not buffered, I had the impression (really I
> have not measured, I have only tested if everything works) that there
> some penalties on performance.
you can always disagree with me on things ;). if you can show that there is a
performance penalty by using the stdio functions, then we can look at using
the unistd ones instead.
glancing over the driver, it seems like the gpio set/get values are the only
timing critical ones, and they'd be the easiest ones to use direct read/write
with since you only need to send out a single byte ('1' or '0'). the rest can
stick with the stdio funcs since they're called at setup/breakdown time only
and are the complicated ones.
-mike
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________ UrJTAG-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/urjtag-development
