Tim Waugh (twaugh@matra.co.uk)
Thu, 29 Apr 1999 12:29:56 +0100
> I will *try* and perform a slight rewrite on the SPP detection code
> which may be failing in id_probe (for those interested, id_probe was
> a routine I wrote 2 years back in the hope of reliably detecting EPP).
If you have an idea for probing that doesn't rely on reading back what you
write to the data register or the control register, please tell us! :-)
The SPP detection code in my tree was modified not long ago in order to
detect Thomas Ruth's port, although it now seems that 2.2.4 can detect it
fine(!). This new failure to detect a port still happens with the SPP
modifications.
Basically, the new SPP code writes 0x0c to ctr, writes to data and tries to
read it back. If it sees something different, it assumes that the port
doesn't latch data, and moves on to the control register. If it can read
back enough bits from there, we really have a port there. I think it needs
the low seven bits (on my machine, the top bit cannot be set). But it may
be that this port doesn't allow us to read the control register.
If the data register and control register tests both fail, but the user has
specified the address, we assume they know what they're talking about.
Otherwise, no port.
What's happening is that detection fails but the base address is specified,
so the parport is available to ppa. It should be in a sane state, because
we write 0x0c to it again at the end.
If the port is returning garbage when we read control, it will break
parport_frob_control, and anything that uses it. This might be what's up.
What do you think?
I'll have to put some debugging code in the SPP detection routine. Maybe
next patch.
Tim.
*/
-- 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 2.0b3 on Thu 29 Apr 1999 - 07:31:12 EDT