All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Cox <alan@linux.intel.com>
To: jeff@garzik.org.com, linux-kernel@vger.kernel.org,
	linux-ide@vger.kernel.org
Subject: [RFC 2/4] libata: Remove excess delay in the tf_load path
Date: Wed, 17 Feb 2010 13:11:40 +0000	[thread overview]
Message-ID: <20100217131032.16338.64825.stgit@localhost.localdomain> (raw)
In-Reply-To: <20100217130847.16338.55586.stgit@localhost.localdomain>

We don't need to stall and wait after loading the task file and before
issuing a command, so don't do it. This shows up on profiles and is not
needed. It costs us up to 1mS on a dumb controller. Matches the old IDE
behaviour.

[Note we are now at 2mS on a dumb controller of what seems to be excess
 delay and fiddling, 3mS if you are writing ctl]

Signed-off-by: Alan Cox <alan@linux.intel.com>
---

 drivers/ata/libata-sff.c |    3 ---
 drivers/ata/pata_via.c   |    2 --
 2 files changed, 0 insertions(+), 5 deletions(-)


diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index cf0332a..3558ca8 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -579,7 +579,6 @@ void ata_sff_tf_load(struct ata_port *ap, const struct ata_taskfile *tf)
 		if (ioaddr->ctl_addr)
 			iowrite8(tf->ctl, ioaddr->ctl_addr);
 		ap->last_ctl = tf->ctl;
-		ata_wait_idle(ap);
 	}
 
 	if (is_addr && (tf->flags & ATA_TFLAG_LBA48)) {
@@ -615,8 +614,6 @@ void ata_sff_tf_load(struct ata_port *ap, const struct ata_taskfile *tf)
 		iowrite8(tf->device, ioaddr->device_addr);
 		VPRINTK("device 0x%X\n", tf->device);
 	}
-
-	ata_wait_idle(ap);
 }
 EXPORT_SYMBOL_GPL(ata_sff_tf_load);
 
diff --git a/drivers/ata/pata_via.c b/drivers/ata/pata_via.c
index 6356377..eccfed2 100644
--- a/drivers/ata/pata_via.c
+++ b/drivers/ata/pata_via.c
@@ -416,8 +416,6 @@ static void via_tf_load(struct ata_port *ap, const struct ata_taskfile *tf)
 			tf->lbam,
 			tf->lbah);
 	}
-
-	ata_wait_idle(ap);
 }
 
 static int via_port_start(struct ata_port *ap)

  reply	other threads:[~2010-02-17 13:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-17 13:10 [RFC 1/4] libata: cache device select Alan Cox
2010-02-17 13:11 ` Alan Cox [this message]
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
2010-03-02 17:28     ` Alan Cox

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=20100217131032.16338.64825.stgit@localhost.localdomain \
    --to=alan@linux.intel.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.