On Sunday 27 November 2011 07:04:41 Frank Wille wrote: > Mike Frysinger wrote: > > we've already got a "gpio" driver that sits on top of the Linux GPIO > > sysfs interface. we can't have another driver using the same name. > > Therefore I called it "parportgpio". I noticed the conflict, while > compiling it for the first time. ;)
ah, but your configure.ac patch still says "gpio" > > could you take a look at src/tap/cable/gpio.c and see if you could add > > > > NetBSD support to that instead ? i think you'd just have to update the > > accessor funcs ... > > I studied the gpio.c source, but there is not much which could be reused. > It would end up in a completely new driver. that's an OK answer (if that's the conclusion we come to). i'd like to keep things merged if possible, but i won't be a stickler about it. > The Linux GPIO sysfs interface is so much different. You would open a > single file for each GPIO pin and GPIO direction and read() or write() to > it. I didn't even understand what gpio_export does. the way the Linux GPIO sysfs interface works is: - by default, no pins are exported to userspace - to export a pin, you write the pin you want to request to the pseudo file "export" (this is what the gpio_export() func does) - once a pin is exported, you can access the pseudo files "direction" and "value" to control the pins direction (in/out) and value (0/1) respectively - once you're done with a pin, you release it by writing to the "unexport" pseudo file (this is what the gpio_export() func also does) > Under NetBSD (and OpenBSD) it is just a single file, /dev/gpio0, which > controls all GPIO pins of a device via ioctl(). sounds like we could still utilize the existing gpio driver ... we just replace the core concepts (requesting/releasing a pin, and changing its direction/value at runtime) with the NetBSD/OpenBSD ioctls > And I wanted to use the byteblaster.c cable (I have a ByteblasterMV), which > depends on urj_tap_parport_xxx accessor functions. So it seemed logical for > me to add a new parport lowlevel driver. hmm, this sounds like a general issue. the point of the current gpio driver is to drive the JTAG pins manually. what you want to do is simulate a parallel port with gpio pins and connect a cable driver to that. so the current code is designed to bypass the ByteblasterMV completely. is there a reason you need this between UrJTAG and the target hardware ? sounds like what we actually want to do is rip the current code out of the GPIO cable driver and into a GPIO core, and then add a GPIO parport lowlevel driver that uses this new core. > > POSIX says that isspace() and friends take an int, so i don't see why > > we need to cast a char to unsigned char to avoid warnings there. > > > > http://pubs.opengroup.org/onlinepubs/9699919799/functions/isspace.html > > The answer is in the link, you were refering to: > <more good stuff> let's start a new thread for this topic (sounds like there's quite a bit to explore) and keep the current one focused on the GPIO stuff. -mike
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d
_______________________________________________ UrJTAG-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/urjtag-development
