I've had a looksee into getting a PCMCIA parallel port card working for the
ipaq (in my case a Quatech SPP-100). Two seg faults were occurring when
trying to load the parport modules. Below are fixes to get parport up and
running - well,... sorta.
Seg 1:
------
Occurs from the 'parport_pc' module trying to scan for ISA ports that
obviously the ipaq doesn't have. The easiest way around this is to modify
the include file "/include/asm-arm/parport.h". Change the line in function
'parport_pc_find_nonpci_ports' to the following:
static int __devinit parport_pc_find_nonpci_ports (int autoirq, int autodma)
{
// return parport_pc_find_isa_ports (autoirq, autodma);
return 1; // IPaQ has no ISA ports.
}
Any justification need can be argued by saying that this function is only
ever called when scanning for built-in ports - which the ipaq will never
have. Scanning events must originate from 'parport_cs' not 'parport_pc'.
Returning 1 here tricks the module into loading by thinking it succeeded.
(parport_pc needs to be loaded before parport_cs can load). Besides, fixing
the 'parport_pc_find_isa_ports' function properly will probably end up
making 'parport_pc.c' too device dependant.
Seg 2:
------
The second segmentation fault appears to be a coding fault originating from
the 'parport_cs.c' file. In the function 'parport_config' around line 322,
there is a small for loop that cycles an array 5 elements. At least it
probably was 5 elements once. Now it only contains 3 elements. Hence a bad
memory dereference is occurring.
Change this: (~line 322: parport_cs.c)
for (i = 0; i < 5; i++)
if (p->modes & mode[i].flag) printk(",%s", mode[i].name);
To this:
for (i = 0; i < MAX_PARPORT_CS_MODES; i++)
if (p->modes & mode[i].flag) printk(",%s", mode[i].name);
Then complete by adding:
#define MAX_PARPORT_CS_MODES 3;
just above this: (~line 229: parport_cs.c)
static struct { u_int flag; char *name; } mode[] = {
{ PARPORT_MODE_TRISTATE, "PS2" },
{ PARPORT_MODE_EPP, "EPP" },
{ PARPORT_MODE_ECP, "ECP" },
};
Results:
--------
With these changes the parport module set 'parport', 'parport_pc',
'parport_cs' now install without complaint when the card is inserted.
According to all the documentation I can find and all the examples I've
tried, parport (with and with 'ppdev') should be working correctly. Nothing
complains and every function behaves as it should. An inserted card gets the
following stats:
Slot 0: Base_address (0xf6000378) IRQ: 42
Slot 1: Base_address (0xf7000378) IRQ: 32
EXCEPT 1, while I have tracked that the correct information is being written
correctly to this address, none of the data/status/control lines can
actually be changed no matter what you send it (correct or otherwise). Nor
can the data lines be read correctly when grounding them. (even writing
directly to that address does nothing to the port's lines). However I'm
certian the parport modules are working.
Possible reasons for this I suppose could be a bad PC-card (I only have the
one so I cannot check it), however I don't think that is the case. I think
something more fundamental is happening perhaps an oversight on my behalf
(all be it somewhat unusual ;-) to do with PC-cards on the ipaq or maybe the
version of pcmcia-cs utilities used. Or perhaps a kernel change is required.
I only been using the 2.4.16-rmk1-hh15 kernel (fam v. 0.5.1) but the parport
source code from the cvs of 2.4.17-rmk5-hh4.
EXCEPT 2, the ipaq will crash Linux (from all appearances) if the card is
ejected and then reinserted.
Any suggestions to this problem greatly appreciated.
Nicholas.
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2b29 : Tue Mar 05 2002 - 03:12:20 EST