From: Jeff Garzik <jgarzik@pobox.com>
To: Tejun Heo <htejun@gmail.com>
Cc: Michael Madore <Michael.Madore@aslab.com>,
linux-ide@vger.kernel.org, albertcc@tw.ibm.com
Subject: Re: [PATCH linux-2.6.13-rc3] Mod15Write quirk against v2.6.13
Date: Sun, 21 Aug 2005 15:19:44 -0400 [thread overview]
Message-ID: <4308D3D0.50504@pobox.com> (raw)
In-Reply-To: <20050728141242.GA10010@htj.dyndns.org>
Tejun Heo wrote:
> Also, Jeff, I know you're very busy, but what do you think about
> taking m15w workaround into ata tree? It's been around for a while
> now and I haven't received any complaints (except for this one) yet.
> The workaround is ugly but it surely helps and I'm willing to maintain
> it.
I think your mod15write solution is too messy to deal with long-term.
Maintenance burden is much lower on us without it. It's not too
difficult to simply avoid certain combinations of hardware.
Note! As Carlos @ Silicon Image points out, the blacklist should only
apply to SiI 3112, not 3512/3114/etc. That's an open FIXME that would
benefit users.
> One thing that bothers me is how Albert's commit and the original
> ata_host_intr tell IRQ subsystem that an interrupt isn't ours when we
> know that we have generated a spurious interrupt. IMHO, we always
> should enter ata_host_intr and always tell IRQ subsystem that it's our
> interrupt if bmdma_status tells us so, regardless of ata status value.
> The current code is likely to cause "nobody cared" error which can be
> avoided.
If there is a mismatch between BMDMA's IRQ bit and ATA device indicating
an interrupt, that's a host state machine[1] violation that should be
addressed elsewhere.
I wouldn't mind using BMDMA IRQ bit as an indicator of the ATA intrq
status, though.
(for others) As linked on
http://www.t13.org/project/d1510r1-Host-Adapter.pdf
via
http://linux.yyz.us/sata/devel.html
you can find documentation on the BMDMA IRQ bit.
The main problem with using BMDMA IRQ bit is that it is likely never set
unless the commands are READ/WRITE DMA commands, which means we must
have separate host state machine tracking for PIO and non-data commands,
increasing complexity.
Jeff
[1] "host state machine" These are illustrated by the state machine
diagrams in ATA/ATAPI-7 Volume 3, under the chapter headings "Bus idle
protocol", "Non-data command protocol", "DMA command protocol", "Ultra
DMA data-{in,out} command protocol". STUDY THESE.
next prev parent reply other threads:[~2005-08-21 21:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1121894035.4885.15.camel@drevil.aslab.com>
2005-07-28 14:12 ` [PATCH linux-2.6.13-rc3] Mod15Write quirk against v2.6.13 Tejun Heo
2005-08-21 19:19 ` Jeff Garzik [this message]
2005-08-21 20:45 ` Tejun Heo
2005-08-21 21:10 ` Jeff Garzik
2005-08-21 21:44 ` Tejun Heo
2005-08-22 10:19 ` Bartlomiej Zolnierkiewicz
2005-08-22 11:46 ` [PATCH libata:upstream] sil: apply M15W quirk selectively Tejun Heo
2005-08-22 19:36 ` Jeff Garzik
2005-08-22 21:39 ` Tejun Heo
2005-08-22 21:45 ` Jeff Garzik
2005-08-22 22:27 ` [PATCH libata:upstream] sil: apply M15W quirk selectively (take 2) Tejun Heo
2005-08-23 5:06 ` Jeff Garzik
2005-08-21 19:34 ` [PATCH linux-2.6.13-rc3] Mod15Write quirk against v2.6.13 Jeff Garzik
2005-08-21 19:56 ` Tejun Heo
2005-08-21 20:11 ` Jeff Garzik
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=4308D3D0.50504@pobox.com \
--to=jgarzik@pobox.com \
--cc=Michael.Madore@aslab.com \
--cc=albertcc@tw.ibm.com \
--cc=htejun@gmail.com \
--cc=linux-ide@vger.kernel.org \
/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).