wdc PCMCIA force to 16bit capabilities

[smesgr <smesgr%gmail.com@localhost>]

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

Stephan