True. However it should be possible to handle it correctly by addingYeah, this seems a viable approach...
the
DMA quirk to the respective host drivers (seems to be via82cxxx.c in
case of
IEI PCISA-C3/EDEN).
Kirill, could you please look into adding such quirk to via82cxxxNo, not really -- the issue is not at all as simple as this patch
instead?
[ It seems the best place to add it would be via_init_one() as we
could just
tried to present it. Looking at its "Quick Startup Reference"
(http://f.ipc2u.ru/files/add/doc/496/M_PCISA-C800EV_ENG.pdf), the EPIC
board has *two* normal IDE connectors in addition to the CF slot
(connected to the secondary port -- and it seems possible that a hard
drive can be connected to the same port as CF), so the right place
seems to rather be in [mu]dma_filter() methods -- and the decision
should be strictly based on the drive type indicating CF, i.e. by
calling ata_id_is_cfa().
As you suggest, we could use the following criterions:
Board vendor="FIC" &&
Board name="PT-2200" &&
VIA-family IDE controller &&
drive type=CF
It should work good enough.
To test it I also tried to install external IDE CF adaptor to the secondary IDE controller (both master and slave).
And it's also identified as CF drive type. And we turn off DMA for it. But since external CF adaptor could be wired right, turning DMA off would be incorrect in some cases.
Yes, _that_ particular external IDE/CF adaptor that we bought, has the same problem, so turning DMA off on it should be correct. We even decided to verify ourselves that wrong soldering is the cause of problems, and wired manually necessary pins, and, voila, DMA works. So the question is:
Is it right to implement the above-mentioned criterion, which would work correctly in 99 cases of 100, but will pessimistically turn DMA off in
rare cases (e.g. rightly wired external IDE/CF adaptor attached to
PCISA/C3), or is the whole problem unsolvable?
We could not come up with the right criterion which selects exactly on-board CF slot, so if there is no satisfactory 100% reliable solution maybe it doesn't make sense to continue...