>> There is only the firmware loader. Once the firmware is loaded it >> should provide an ATA interface to any inserted memory card or at >> least this is what I understood > > Sure. Obviously this is not what happens.
But in fact a working ATA interface (ATA-1 conforming to ANSI X3.221 1994) is provided by the PCI1620 chip with the firmware loaded. I can tell you this because I have tested the ports of the device provided by the PCMCIA system after a memory card insertion. The only trouble was that somehow the ATA drivers (pata_pcmcia) was unable to work with the ATA device. After some debugging I have realized that the problem was the way that the PIO data transfer was made in pata_pcmcia. It was on 16 bits and it seems that the emulated ATA device only handled 8 bit transfers (at least until it's correct setup). So the drive failed to IDENTIFY because it had a bad status after the identify drive ATA command. The status was that the device still has data to transfer when the driver did not expect this. It is normal because the driver only made half the reads from the data register because of the 16 bit (driver) - 8 bit (device) "misunderstanding". > >> This problem was already signaled at >> http://bugzilla.kernel.org/show_bug.cgi?id=6991 but, I do not know >> why, the developers blamed the firmware loader. > > Because it is the most likely source of error. > > Many other memory cards and readers that do not require the > firmware loader work without problems. > OK but this one really does :). It does not move without it. >> From what I can tell the firmware loader works just fine because >> if it would not (which would mean that we have a bad firmware >> loaded) the machine would freeze upon insertion of a card (I know >> from experience). > > The firmware loader is not just responsible for transmitting a > firmware to the device. > > The firmware loader is responsible for communicating with a device > and set it up so that it behaves like another, new, device. I checked the datasheet of the PCI1620 chip and the firmware uploading sequence is according to the specifications. The only thing the uploader must do after upload is set the status that the upload has finished (which it does). >> My question is: Is there a problem with the pata_pcmcia >> implementation or there should be a separate pata_pcmcia_pci1620 >> implementation that would handle only this deviece? > > The third party module is probably causing the problem by not > initializing the hardware correctly. > > A separate driver for this special device is a possible solution, but > I think an attempt to fix the special initializer module is a better > first step. That needs to be reliable before a separate driver is > written anyway. > > Do you have contact with the developers of the module? Could you > point them to these bugs and see if they can help get it fixed? So I am really happy that I have my card reader working with a modified pata_pcmcia driver which uses an 8 bit data_xfer function. Also the set_xfer_mode function had to be replaced with a custom one which, for now, does not do anything. I would really like to share this with other users of this device but I don't really know how. Alan (the author of pata_pcmcia) suggested that the modifications would be better in a new module (which I named pata_1620). The only thing I could come up with is this wiki http://gentoo-wiki.com/HARDWARE_Texas_Instruments_PCI1620_Cardbus_Controller_with_a_4_in_1_memory_card_reader I hope it will help whoever needs it. For now the process to set up the device is very unfriendly but it could be made better. The first issue would be if the firmware could be distributed with this Linux driver. This raises some copyright issues... I think. Thanks for your help. Cristian _______________________________________________ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
