[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
wdc PCMCIA force to 16bit capabilities
I would like to have an advice on a pcmcia/pc card issue.
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?
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
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
Main Index |
Thread Index |