Mike Frysinger wrote: >> 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"
Yes, maybe I should have changed that too. But I thought there is no conflict, because it is the only "gpio" in the group of lowlevel parport drivers. > 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) Ok, I understand. What were the reasons against exporting all GPIO pins by default? >> 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 That is certainly possible. But also setting a pin to 0 or 1 has to be done via ioctl(). >> 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. Indeed. In fact it is a real parallel port. :) > so the current code is designed to bypass the ByteblasterMV completely. > is there a reason you need this between UrJTAG and the target hardware > ? Not much. IIRC you have to drive a specific parallel port pin low to enable the output lines of the 74HC244 chip on the ByteblasterMV. > 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. Sounds good. If you prepare the GPIO code for Linux, I can add NetBSD support and will write the parport lowlevel driver using it. Regards, -- Frank Wille ------------------------------------------------------------------------------ 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
