No experience with parallel port, no experience with GPIO, what WAS I thinking?!
Well, job's done now. Not so many lines of code it turns out.
Some thoughts:
1. The parallel port uses addresses such as '0x378' & IRQ values suach as '7'.
We must as well. That means that all /etc/modprobe.d/parport.conf files and
the like will be mapped to the correct addreses and IRQs in a
platform-dependent manner. Thankfully the authors franken-driver
"parport_pc.c" have somewhat obeyed the "assume you know nothing about the
value of that address" except in one, very important, hard-coded place.
2. The cards we could find on PC104 rarely had EPP/ECP modes. This means that
the old PS2 mode must be used to gain bi-directionality (on the TS-SER2 and
Measurement Computing boards we tested). And of course Murphy's law means that
for us on ARM, this would be the most poorly treated of the modes. It is called
PS2, BPP, and sometimes mistakenly SPP, or PCSPP, or TRISTATE. Argh.
Historical research convinced me that PS2 mode came from IBM, and has an
uncertain relationship to IEEE1284. The kernel config help for example for
IEEE1284, only mentions EPP/ECP only, not PS2. But you cannot (correction I
could not) run the port bi-directionally unless the 1284 modes are enabled. I
looked deeply into parport_pc code trying to figure out how PS2 mode could work
without defining the kernel token for 1284 modes, and it looked like the driver
authors have not kept the faith on allowing BPP to operate without also
defining the 1284 modes. The whole thing gave me bad dreams, so I just stopped
and let the 1284 modes in. Fortunately, we never had the problem of the
parport_pcc driver mistaking our hardware as being EPP/ECP compatible, so
that's a blessing as there is a ton of code for EPP/EPP.
3. Clients of the parport_pc driver often use the unfortunate technique of
looking up the port address from the driver to get their bearings. Work ok
with fixed io memory addresses on Intel. On ARM though, since each module must
call ioremap() on its own, these addresses do not, in general, match. In our
case the lower bytes align, so a simple mask allows the parport_pc client to
determine which of three port addresses have been selected. But again, this
makes sense, as the address offset for a given architecture is platform
dependent, and the burden should fall to the client to make sure it uses the
correct address, remapped - or whatever.
4. The IRQ part of the driver in our case requires manipulation of GPIO
registers (thanks again Jim) in port F. Do not confuse the enabling of the
interrupt via port F with the IRQ traffic within the CONTROL & STATUS bits.
All of this GPIO has been kept squarely out of view from parport_pc clients, by
handling all within parport_pc.c itself. The IRQ is defined and enabled via
GPIO once, at module insertion.
5. For cards like the TS-SER2 that have serial ports, drivers for these were
kept as a separate module. Easier that trying to knit serial drivers into the
parport mechanism.
I can't think of anything else. You?
Once we get everything freshly re-rolled, I'll put up a patch, etc. Thanks for
the help everyone!
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|