I've stuck the -current atapi support into a stock 2.0.5 kernel, and believe
I've done it correctly. I've discovered some problems with the atapi code I'd
like let people know about.
First, I'm running ONLY a CD ATAPI device, no hard disk. I know others have
had their own issues with this, but mine seem to be different. My CD is a
Sony CDU-55E.
First, the current layering of wd.c is obviously not well suited to this
configuration. Your ATAPI controller has to react a certain way to particular
ATA commands to get to the point of being probed at all as an ATAPI CD. The 3
trials of ATA you must pass are 1) writable byte count / cyl. address
registers, 2) successful wdreset(), and 3) successful WDCC_DIAGNOSE behavior.
The first test is reasonable, for what its worth. My ATAPI CD fails the
current implementation of wdreset(), although the ATAPI spec is pretty
specific about how this should be handled and the code looks potentially
correct. I need to trace this down more. I get through the WDCC_DIAGNOSE
test OK.
So, by ignoring wdreset() failure in the wdc probe, I can get my device
recognized. At that point the atapi_probe/atapi_attach work just fine and
identify the device.
The next issue is with the MODE_SENSE issued by the wcd code. It asks for the
CDROM Capabilites page (0x2A). It expects this in a 24 byte struct and asks
for 24 bytes. However, my ATAPI spec indicates that this page is 28 bytes
long, and that's also what my device tries to send. The atapi.c code
considers this an overrun (although the device indicates no errors) and leaves
the data on the table. By defining the last 4 bytes in the capabilities
struct, giving me a 28 byte struct, I succeed with the MODE_SENSE and get
valid information.
I have a couple of issues/questions with this. First, wcd.c seems to be using
too small a struct for this MODE_SENSE command. Perhaps this is version skew
on the ATAPI spec? Second, the spec indicates that since a host doesn't know
how much data will be returned with a MODE_SENSE, it should rely on the byte
count registers from the device. This is probably referring to a request for
ALL pages, which returns an unpredictable amount of data. However the spec
says that, in general, the host should divert to the bit bucket any excess
data offered by the device (and send pad bytes when the device asks for more
than is required). Seems like atapi_io() should be less sensitive to
overrun/underrun. Finally, even if we consider the byte count in error, it
does no good to leave the data there. It would think it better to transfer
the data to the bit bucket to finish the command, returning an error.
My current (final?) problem is that the TEST_UNIT_READY command issued during
wcd driver open never seems to generate an interrupt. I haven't solved this
one yet, but it may be related to the state of the IEN bit in wd_ctrl at the
end of wdreset(), since this is the first opportunity for the device to
interrupt. Which reminds me that the infinite sleeps in atapi.c are less than
ideal.
BTW, the spec I refer to is the ATAPI for CD-ROMs spec, rev. 2.5 8/10/95.
It's marked as "Status: Review Copy" so I guess some parts are in flux. But I
figured its accurate for basic information. I believe there was an earlier
version as well where I got this, but it was 8MB and this one was 3MB. I
found it through the magic of the Internet at ftp://fission.dt.wdc.com/pub/stan
dards/atapi/.
-josh
========================================================================
Josh Littlefield American Internet Corporation
josh@american.com 4 Preston Court
tel: 617-271-9200 fax: 617-275-4930 Bedford, MA 01730-2334