The parallel port driver uses inb/outb calls to read/write directly to legacy parallel port memory regions. It would be nice if it could use the parport driver stack (e.g. parport + parport_pc). This would allow the driver to work without blacklisting those modules, and potentially allow other parport devices to be used besides parport_pc, thus avoiding the hassle of acquiring true legacy parallel port hardware.
(Edit: if there were any useful ones, that is. USB devices likely have latency way too high. PCMCIA and PCI cards probably already present as a legacy device. But, one idea is to create a new parport_gpio device that could work on SOC devices like raspberry pi...)
As documented in #11 (last scope trace) the timing required for software controlled timing is on the order of 1.4uS. I'm not sure what if any penalty is incurred by working through the driver stack as opposed to directly. Let's try it and a) see if it works, and b) see what the scope traces look like.
The parallel port driver uses inb/outb calls to read/write directly to legacy parallel port memory regions. It would be nice if it could use the parport driver stack (e.g. parport + parport_pc). This would allow the driver to work without blacklisting those modules, and potentially allow other parport devices to be used besides parport_pc, thus avoiding the hassle of acquiring true legacy parallel port hardware.
(Edit: if there were any useful ones, that is. USB devices likely have latency way too high. PCMCIA and PCI cards probably already present as a legacy device. But, one idea is to create a new parport_gpio device that could work on SOC devices like raspberry pi...)
As documented in #11 (last scope trace) the timing required for software controlled timing is on the order of 1.4uS. I'm not sure what if any penalty is incurred by working through the driver stack as opposed to directly. Let's try it and a) see if it works, and b) see what the scope traces look like.