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
next prev 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.