From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: Dmitry Gryazin <gdu@mns.spb.ru>
Cc: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>,
Kirill Smelkov <kirr@mns.spb.ru>,
linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
navy-patches@mns.spb.ru
Subject: Re: [PATCH] ide: motherboard-info based blacklist for ide-dma
Date: Fri, 16 Jan 2009 15:35:44 +0300 [thread overview]
Message-ID: <49707F20.4030600@ru.mvista.com> (raw)
In-Reply-To: <200901151448.52900.gdu@mns.spb.ru>
Hello.
Dmitry Gryazin wrote:
>>>> True. However it should be possible to handle it correctly by adding
>>>> the
>>>> DMA quirk to the respective host drivers (seems to be via82cxxx.c in
>>>> case of
>>>> IEI PCISA-C3/EDEN).
>>>>
>>> Yeah, this seems a viable approach...
>>>
>>>> Kirill, could you please look into adding such quirk to via82cxxx
>>>> instead?
>>>>
>>>> [ It seems the best place to add it would be via_init_one() as we
>>>> could just
>>>>
>>> No, not really -- the issue is not at all as simple as this patch
>>> 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
>
Yes, but in almost exactly opposite order (well one check shoud be added)
VT82C686 (or whatever) and
secondary channel and
CFA device and
DMI ID is FIC PT2200
> 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).
You mean that this adaptor is directly connected to IDE slot with the
cable... hm, haven't seen those.
> 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?
>
Good question. However, with the on-board CF adapter already present
on the seconary channel it seems improbable that the user will need to
connect another (external) CF adapter. Even if he'd need it, he'd still
be able to use the primary port.
> 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...
>
I think it still does make sense.
MBR, Sergei
next prev parent reply other threads:[~2009-01-16 12:35 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-30 15:33 [PATCH] ide: motherboard-info based blacklist for ide-dma Kirill Smelkov
2008-12-30 16:30 ` Sergei Shtylyov
2008-12-31 19:12 ` Bartlomiej Zolnierkiewicz
2009-01-04 20:32 ` Sergei Shtylyov
2009-01-04 21:13 ` Sergei Shtylyov
2009-01-04 23:34 ` Sergei Shtylyov
2009-01-15 11:48 ` Dmitry Gryazin
2009-01-16 12:35 ` Sergei Shtylyov [this message]
2009-01-22 12:43 ` Dmitry Gryazin
2009-01-22 13:43 ` Sergei Shtylyov
2009-01-22 13:54 ` Sergei Shtylyov
2009-01-22 13:58 ` Sergei Shtylyov
2009-01-22 14:27 ` Dmitry Gryazin
2009-01-22 15:35 ` Sergei Shtylyov
2009-01-22 17:10 ` Sergei Shtylyov
2009-01-22 14:58 ` Dmitry Gryazin
2009-01-22 15:51 ` Sergei Shtylyov
2009-01-26 23:34 ` Sergei Shtylyov
2009-01-27 7:50 ` Dmitry Gryazin
2009-01-27 10:30 ` Sergei Shtylyov
2009-01-22 15:01 ` Bartlomiej Zolnierkiewicz
2009-01-22 15:53 ` Sergei Shtylyov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49707F20.4030600@ru.mvista.com \
--to=sshtylyov@ru.mvista.com \
--cc=bzolnier@gmail.com \
--cc=gdu@mns.spb.ru \
--cc=kirr@mns.spb.ru \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=navy-patches@mns.spb.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).