tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

wdc PCMCIA force to 16bit capabilities

Hi everyone,

I would like to have an advice on a pcmcia/pc card issue.

short request:

According to the Xscale developer documentation the processor is capable of accessing PCMCIA in 16-bit.

"nPCE2 and nPCE1 are byte select high and low for a 16-bit data bus" (6.2.3 16-Bit PC Card / Compact Flash Interface @ Intel PXA 255 Processor Developer's Manual)

"[...] that the upper half of the data bus (MD[15:8]) are used for the transfer, and nPCE1 to indicate that the lower half of the data bus (MD[7:0]) are used. nPCE1 and nPCE2 are asserted for 16-bit accesses." (6.8.3 @same document)

The wdc_pcmcia.c driver always set the capability to 32bit if PCMCIA_IFTYPE_MEMORY is not set.

sc->sc_wdcdev.sc_atac.atac_cap |= ATAC_CAP_DATA32;

I would like to add an additional switch based on the capaiblities of the pcic (in this case pxa2x0_pcic). What would be the best data structure to pass this flag to wdc_pcmcia?

background story:

At the moment my boards CF Card isn't working properly, because the ata-driver try to IDENTIFY the CF card first by reading data in 16bit then in 32bit mode. Then the driver compares both values, reset the ATA_DRIVE_CAP32 flag and falls back to the 16bit mode. The last request is send, but instead of reading 32bit data of a single CF card slot, 16bit of data of both CF card slots are read (see Xscale data bus statement above). For the hardware the 32bit identify isn't finished and register field still indicate a pending request. Every following request from the system then checks the register field, detects the pending request and try to wait for completion. Up until ~2012 a workaround was in place which executed a command even through the previous command wasn't completed and created a fake disk data structure. This action would abort the pending identify and any following request worked fine. Without additonal diagnostic logs this roundtrip was properly unnoticed by the user. It could be detected if the first access on the disk would be a disklabel (or any other command printing the disk structure). If a disklabel command was executed the fake disk data could be observerd, any follwing disklabel execution would fetch the real values from the cf card.

I would like to create an patch to fix this issue without reintroduce the 2012ish workaround. For my point of view this should be done by telling wd/ata-drivers to never try 32bit mode for this particular controller.

Best Regards


Home | Main Index | Thread Index | Old Index