All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: Jens Axboe <axboe@suse.de>
Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Playing with SATA NCQ
Date: Thu, 26 May 2005 15:49:07 -0400	[thread overview]
Message-ID: <42962833.4000000@pobox.com> (raw)
In-Reply-To: <20050526170658.GT1419@suse.de>

Jens Axboe wrote:
> On Thu, May 26 2005, Jeff Garzik wrote:
>>>+int ata_read_log_page(struct ata_port *ap, unsigned int device, char page,
>>>+		      char *buffer, unsigned int sectors)
>>>+{
>>>+	struct ata_device *dev = &ap->device[device];
>>>+	DECLARE_COMPLETION(wait);
>>>+	struct ata_queued_cmd *qc;
>>>+	unsigned long flags;
>>>+	u8 status;
>>>+	int rc;
>>>+
>>>+	assert(dev->class == ATA_DEV_ATA);
>>>+
>>>+	ata_dev_select(ap, device, 1, 1);
>>
>>is this needed?  These types of calls need to be removed, in general, as 
>>they don't make sense on FIS-based hardware at all.
> 
> 
> You tell me, this read_log_page() was mainly copy-pasted from the pio
> driven function above it. I'll try and kill the select when doing error
> testing.
> 
> 
>>>+	printk("RLP issue\n");
>>>+	spin_lock_irqsave(&ap->host_set->lock, flags);
>>>+	rc = ata_qc_issue(qc);
>>>+	spin_unlock_irqrestore(&ap->host_set->lock, flags);
>>>+	printk("RLP issue done\n");
>>>+
>>>+	if (rc)
>>>+		return -EIO;
>>>+
>>>+	wait_for_completion(&wait);
>>>+
>>>+	printk("RLP wait done\n");
>>>+
>>>+	status = ata_chk_status(ap);
>>>+	if (status & (ATA_ERR | ATA_ABORTED))
>>>+		return -EIO;
>>
>>we need to get rid of this too for AHCI-like devices
> 
> 
> Can you expand on that?

(this covers both quoted questions above)

The PIO function assumes that PCI IDE-like ATA register blocks (command 
registers, control registers) are available.  The read-log-page function 
can make no such assumptions.

dev-select and check-status should both be done by the machinery that 
occurs once you start things in motion by calling ata_qc_issue().

Doing things this way is necessary for FIS-based hardware like AHCI or 
SiI 3124.


>>>#ifdef CONFIG_PCI
>>>EXPORT_SYMBOL_GPL(pci_test_config_bits);
>>>Index: drivers/scsi/libata-scsi.c
>>>===================================================================
>>>--- f5c58b6b0cfd2a92fb3b1d1f4cbfdfb3df6f45d6/drivers/scsi/libata-scsi.c  
>>>(mode:100644)
>>>+++ uncommitted/drivers/scsi/libata-scsi.c  (mode:100644)
>>>@@ -336,6 +336,7 @@
>>>	if (sdev->id < ATA_MAX_DEVICES) {
>>>		struct ata_port *ap;
>>>		struct ata_device *dev;
>>>+		int depth;
>>>
>>>		ap = (struct ata_port *) &sdev->host->hostdata[0];
>>>		dev = &ap->device[sdev->id];
>>>@@ -353,6 +354,13 @@
>>>			 */
>>>			blk_queue_max_sectors(sdev->request_queue, 2048);
>>>		}
>>>+
>>>+		if (dev->flags & ATA_DFLAG_NCQ) {
>>>+			int ddepth = ata_id_queue_depth(dev->id) + 1;
>>>+
>>>+			depth = min(sdev->host->can_queue, ddepth);
>>>+			scsi_adjust_queue_depth(sdev, MSG_ORDERED_TAG, 
>>>depth);
>>
>>For all hardware that uses SActive (all NCQ), the max is 31 not 32.
> 
> 
> That's not true, the max is 32 counting 0 as a valid tag. So 31 is
> indeed th max tag value, but 32 is the depth.

I was talking about depth.  In libata, it's a policy decision to never 
use more than 31 tags at any given time.

You can change it from 31 to 32 in SuSE for value-add, if you wish :)

Note also that error handling occasionally needs a command slot, so the 
limit may even be 30 (or 31 at most).



> The two depths were added because we need to differentiate between the
> two for issuing new commands. ncq_depth > 0 is fine for issuing a new
> FPDMA request, where as non-FPDMA commands need both !ncq_depth and
> !depth.

You can definitely handle both FPDMA and non-FPDMA with a single 
variable.  Think harder on this one.  You have flags to work with, you 
know...

	Jeff



  parent reply	other threads:[~2005-05-26 19:49 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-26 14:00 Playing with SATA NCQ Jens Axboe
2005-05-26 16:25 ` Jeff Garzik
2005-05-26 17:07   ` Jens Axboe
2005-05-26 17:11     ` Jens Axboe
2005-05-26 17:15       ` Jeff Garzik
2005-05-26 17:33         ` Jens Axboe
2005-05-26 19:49     ` Jeff Garzik [this message]
2005-05-26 20:30       ` Jens Axboe
2005-05-27  7:20   ` Jens Axboe
2005-05-27  7:29     ` Jeff Garzik
2005-05-27  7:33       ` Jens Axboe
2005-05-27  7:51         ` Jeff Garzik
2005-05-27  8:00           ` Jens Axboe
2005-05-27  8:23             ` Jeff Garzik
2005-05-26 21:50 ` Mark Lord
2005-05-27  6:28   ` Jens Axboe
2005-05-27  6:58     ` Jeff Garzik
2005-05-27  7:15       ` Jens Axboe
2005-05-27  4:41 ` Jeff Garzik
2005-05-27  6:39   ` Jens Axboe
2005-05-27 21:40 ` Michael Thonke
2005-05-27 22:16   ` Jeff Garzik
2005-05-27 22:30     ` Michael Thonke
2005-05-28 12:12       ` Jens Axboe
2005-05-29 13:01         ` Michael Thonke
2005-05-29 14:09           ` Mark Lord
2005-05-29 14:24             ` Tyler
2005-05-29 15:22               ` Eric D. Mudama
2005-05-29 19:04             ` Jens Axboe
2005-05-29 19:05               ` Jeff Garzik
2005-05-29 19:21                 ` Jens Axboe
2005-05-29 19:03           ` Jens Axboe
2005-05-29 20:12             ` Michael Thonke
2005-05-29 20:17               ` Jeff Garzik
2005-05-30  6:05                 ` Jens Axboe
2005-05-30  6:07               ` Jens Axboe
2005-05-29 18:10         ` Michael Thonke
2005-05-29 19:06           ` Jens Axboe
2005-05-29 16:03 ` Erik Slagter
2005-05-29 16:34   ` Jeff Garzik
2005-05-29 16:50     ` Erik Slagter
2005-05-29 16:59       ` Jeff Garzik
2005-05-29 17:23         ` Erik Slagter
2005-05-29 17:29           ` Jeff Garzik
2005-05-29 17:45             ` Erik Slagter
2005-05-29 18:01               ` Jeff Garzik
2005-05-29 18:10                 ` Erik Slagter
2005-05-29 18:14                   ` Jeff Garzik
2005-05-29 18:27                 ` Michael Thonke
2005-05-29 18:31                   ` Jeff Garzik
2005-05-29 16:57   ` Michael Thonke
2005-05-29 17:26     ` Erik Slagter
2005-05-30  0:06       ` Mark Lord
2005-05-30  7:29         ` Erik Slagter
2005-05-30 18:09           ` Mark Lord
2005-05-30 18:22             ` Erik Slagter
2005-05-30 18:25               ` Mark Lord
2005-05-30 18:34                 ` Michael Thonke
2005-05-30 18:51                   ` Jeff Garzik
2005-05-30 18:48                 ` Jeff Garzik
2005-05-30 18:50               ` Jeff Garzik
2005-05-30 20:03                 ` Erik Slagter
2005-05-30 20:19                   ` Jeff Garzik
2005-05-31  7:44                     ` Erik Slagter
2005-05-30 23:14                 ` Mark Lord
2005-05-31  7:48                   ` Erik Slagter
2005-05-31  8:05                     ` Patrick McFarland
2005-05-29 21:49 ` Michael Thonke

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=42962833.4000000@pobox.com \
    --to=jgarzik@pobox.com \
    --cc=axboe@suse.de \
    --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.