From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Jeff Garzik <jeff@garzik.org>
Cc: Alan Cox <alan@linux.intel.com>,
jeff@garzik.org.com, linux-kernel@vger.kernel.org,
linux-ide@vger.kernel.org
Subject: Re: [RFC 1/4] libata: cache device select
Date: Tue, 2 Mar 2010 17:28:47 +0000 [thread overview]
Message-ID: <20100302172847.2e87de07@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <4B8C2079.7010607@garzik.org>
> > - ata_dev_select(ap, qc->dev->devno, 1, 0);
> > + if (qc->dev->devno != ap->sff_selected)
> > + ata_dev_select(ap, qc->dev->devno, 1, 0);
> >
> > /* start the command */
> > switch (qc->tf.protocol) {
>
> My main worry here is that this logic excises the 150ms wait in
> ata_dev_select() that has been used effectively to allow ATAPI devices
> to "collect themselves" after waiting for idle, prior to command issuance.
It doesn't. You call it with wait = 1, can_sleep = 0 so it will never do
the 150ms magic delay here anyway (good job or it would kill us for
performance ;))
It does mean we don't do the device idle wait in that situation but there
are no code paths where we try to overlap commands by spinning on the
drive busy bit (again for obvious reasons)
Alan
prev parent reply other threads:[~2010-03-02 17:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-17 13:10 Alan Cox
2010-02-17 13:11 ` [RFC 2/4] libata: Remove excess delay in the tf_load path Alan Cox
2010-02-17 13:13 ` [RFC 3/4] libata: Remove excess command issue delays Alan Cox
2010-02-17 14:10 ` Sergei Shtylyov
2010-02-17 15:34 ` Alan Cox
2010-02-17 13:15 ` [RFC 4/4] libata: Make sil680 do its own exec_command posting Alan Cox
2010-02-18 5:13 ` [RFC 1/4] libata: cache device select Mark Lord
2010-02-18 10:16 ` Alan Cox
2010-03-01 20:15 ` Jeff Garzik
2010-03-02 17:28 ` Alan Cox [this message]
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=20100302172847.2e87de07@lxorguk.ukuu.org.uk \
--to=alan@lxorguk.ukuu.org.uk \
--cc=alan@linux.intel.com \
--cc=jeff@garzik.org \
--cc=jeff@garzik.org.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@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
all inboxes | Powered by JetHome®