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: [PATCH] SATA NCQ support
Date: Fri, 27 May 2005 03:22:16 -0400 [thread overview]
Message-ID: <4296CAA8.9060307@pobox.com> (raw)
In-Reply-To: <20050527070353.GL1435@suse.de>
Jens Axboe wrote:
> Update the patch, it's against bleeding edge git (applies to 2.6.12-rc5
> as well). Changes:
I'll throw this into libata-dev branch "ncq" right now.
> +static void ahci_host_ncq_intr_err(struct ata_port *ap)
> +{
> + void *mmio = ap->host_set->mmio_base;
> + void *port_mmio = ahci_port_base(mmio, ap->port_no);
> + char *buffer;
> +
> + printk(KERN_ERR "ata%u: ncq interrupt error\n", ap->id);
> +
> + ahci_intr_error(ap, readl(port_mmio + PORT_IRQ_STAT));
> +
> + buffer = kmalloc(512, GFP_KERNEL);
cannot use GFP_KERNEL in interrupt context
> @@ -2868,6 +2995,21 @@
> int ata_qc_issue(struct ata_queued_cmd *qc)
> {
> struct ata_port *ap = qc->ap;
> + int rc = ATA_QC_ISSUE_FATAL;
> +
> + /*
> + * see if we can queue one more command at this point in time, see
> + * comment at ata_qc_issue_ok(). NCQ commands typically originate from
> + * the SCSI layer, we can ask the mid layer to defer those commands
> + * similar to a QUEUE_FULL condition on a 'real' SCSI device
> + */
> + if (!ata_qc_issue_ok(ap, qc, 0)) {
> + if (qc->flags & ATA_QCFLAG_DEFER)
> + return ATA_QC_ISSUE_DEFER;
> +
> + ata_qc_issue_wait(ap, qc);
> + assert(ata_qc_issue_ok(ap, qc, 0));
> + }
>
This is too late. We shouldn't get to this point and find out, "uh oh,
queue full."
ata_qc_new() should fail to obtain a qc if the queue is full, at which
point you may directly return queue-full.
If ata_qc_new() succeeds, but wish to wait for the queue to drain, add
that logic -much- earlier than the ata_qc_issue() call. I would rather
have that logic at a higher level.
> @@ -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);
> +
> + depth = min(sdev->host->can_queue, ddepth);
> + scsi_adjust_queue_depth(sdev, MSG_SIMPLE_TAG, depth);
> + }
> }
>
> return 0; /* scsi layer doesn't check return value, sigh */
> @@ -1594,3 +1641,22 @@
> }
> }
>
> +int ata_scsi_change_queue_depth(struct scsi_device *sdev, int queue_depth)
> +{
> + struct ata_port *ap;
> + struct ata_device *dev;
> + int max_depth;
> +
> + if (sdev->id >= ATA_MAX_DEVICES)
> + return sdev->queue_depth;
> +
> + ap = (struct ata_port *) &sdev->host->hostdata[0];
> + dev = &ap->device[sdev->id];
> +
> + max_depth = min(sdev->host->can_queue, ata_id_queue_depth(dev->id));
> + if (queue_depth > max_depth)
> + queue_depth = max_depth;
> +
> + scsi_adjust_queue_depth(sdev, MSG_SIMPLE_TAG, queue_depth);
> + return queue_depth;
> +}
Please add this function immediately above, or below,
ata_scsi_slave_config(). That will make backporting to 2.4.x easier.
> ===================================================================
> --- 3ac9a34948049bff79a2b2ce49c0a3c84e35a748/include/linux/ata.h (mode:100644)
> +++ uncommitted/include/linux/ata.h (mode:100644)
> @@ -79,7 +79,8 @@
> ATA_NIEN = (1 << 1), /* disable-irq flag */
> ATA_LBA = (1 << 6), /* LBA28 selector */
> ATA_DEV1 = (1 << 4), /* Select Device 1 (slave) */
> - ATA_DEVICE_OBS = (1 << 7) | (1 << 5), /* obs bits in dev reg */
> + ATA_DEVICE_OBS = (1 << 5), /* obs bits in dev reg */
> + ATA_FPDMA_FUA = (1 << 7), /* FUA cache bypass bit */
> ATA_DEVCTL_OBS = (1 << 3), /* obsolete bit in devctl reg */
> ATA_BUSY = (1 << 7), /* BSY status bit */
> ATA_DRDY = (1 << 6), /* device ready */
Don't do this. You can add ATA_FPDMA_FUA, but don't arbitrarily change
ATA_DEVICE_OBS.
This is something that may have to be done on a per-device basis.
Jeff
next prev parent reply other threads:[~2005-05-27 7:22 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-27 7:03 [PATCH] SATA NCQ support Jens Axboe
2005-05-27 7:22 ` Jeff Garzik [this message]
2005-05-27 7:30 ` Jens Axboe
2005-05-27 7:37 ` Jeff Garzik
2005-05-27 7:47 ` Jens Axboe
2005-05-27 7:56 ` Jens Axboe
2005-05-27 8:24 ` Jeff Garzik
2005-05-27 8:27 ` Jeff Garzik
2005-05-27 8:28 ` Jeff Garzik
2005-05-27 8:35 ` Jens Axboe
2005-05-27 8:38 ` Jeff Garzik
2005-05-27 8:42 ` Jens Axboe
2005-05-27 23:47 ` Jeff Garzik
2005-05-27 13:18 ` Matthias Andree
2005-05-27 13:53 ` Jens Axboe
2005-05-27 14:46 ` Matthias Andree
2005-05-27 14:58 ` Jens Axboe
2005-05-29 13:16 ` Matthias Andree
2005-05-29 16:36 ` Jeff Garzik
2005-05-30 2:35 ` Eric D. Mudama
2005-05-30 3:41 ` Greg Stark
2005-05-30 4:04 ` Eric D. Mudama
2005-05-30 6:21 ` Greg Stark
2005-05-30 6:33 ` Jens Axboe
2005-05-30 12:16 ` Jens Axboe
2005-05-30 12:37 ` Jens Axboe
2005-05-30 14:51 ` Jens Axboe
2005-05-27 16:00 ` Jeff Garzik
[not found] <48Hix-88s-7@gated-at.bofh.it>
[not found] ` <48N4N-4B5-25@gated-at.bofh.it>
[not found] ` <48Pzt-6Kb-5@gated-at.bofh.it>
2005-05-31 0:00 ` Robert Hancock
2005-05-31 1:21 ` 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=4296CAA8.9060307@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.