All of lore.kernel.org
 help / color / mirror / Atom feed
From: Finn Thain <fthain@telegraphics.com.au>
To: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Michael Schmitz <schmitzmic@gmail.com>,
	<linux-m68k@vger.kernel.org>, <linux-scsi@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Cc: Ondrej Zary <linux@rainbow-software.org>, Sam Creasey <sammy@sammy.net>
Subject: [PATCH v4 21/23] atari_scsi: Allow can_queue to be increased for Falcon
Date: Wed, 23 Mar 2016 21:10:30 +1100	[thread overview]
Message-ID: <20160323101014.681781582@telegraphics.com.au> (raw)
In-Reply-To: 20160323101009.341929635@telegraphics.com.au

[-- Attachment #1: atari_scsi-can_queue --]
[-- Type: text/plain, Size: 6525 bytes --]

The benefit of limiting can_queue to 1 is that atari_scsi shares the
ST DMA chip more fairly with other drivers (e.g. falcon-ide).

Unfortunately, this can limit SCSI bus utilization. On systems without
IDE, atari_scsi should issue SCSI commands whenever it can arbitrate for
the bus. Make that possible by making can_queue configurable.

Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Tested-by: Michael Schmitz <schmitzmic@gmail.com>

---
 drivers/scsi/atari_scsi.c |   83 ++++++++++++----------------------------------
 1 file changed, 22 insertions(+), 61 deletions(-)

Index: linux/drivers/scsi/atari_scsi.c
===================================================================
--- linux.orig/drivers/scsi/atari_scsi.c	2016-03-23 21:10:03.000000000 +1100
+++ linux/drivers/scsi/atari_scsi.c	2016-03-23 21:10:04.000000000 +1100
@@ -14,55 +14,23 @@
  *
  */
 
-
-/**************************************************************************/
-/*                                                                        */
-/* Notes for Falcon SCSI:                                                 */
-/* ----------------------                                                 */
-/*                                                                        */
-/* Since the Falcon SCSI uses the ST-DMA chip, that is shared among       */
-/* several device drivers, locking and unlocking the access to this       */
-/* chip is required. But locking is not possible from an interrupt,       */
-/* since it puts the process to sleep if the lock is not available.       */
-/* This prevents "late" locking of the DMA chip, i.e. locking it just     */
-/* before using it, since in case of disconnection-reconnection           */
-/* commands, the DMA is started from the reselection interrupt.           */
-/*                                                                        */
-/* Two possible schemes for ST-DMA-locking would be:                      */
-/*  1) The lock is taken for each command separately and disconnecting    */
-/*     is forbidden (i.e. can_queue = 1).                                 */
-/*  2) The DMA chip is locked when the first command comes in and         */
-/*     released when the last command is finished and all queues are      */
-/*     empty.                                                             */
-/* The first alternative would result in bad performance, since the       */
-/* interleaving of commands would not be used. The second is unfair to    */
-/* other drivers using the ST-DMA, because the queues will seldom be      */
-/* totally empty if there is a lot of disk traffic.                       */
-/*                                                                        */
-/* For this reasons I decided to employ a more elaborate scheme:          */
-/*  - First, we give up the lock every time we can (for fairness), this    */
-/*    means every time a command finishes and there are no other commands */
-/*    on the disconnected queue.                                          */
-/*  - If there are others waiting to lock the DMA chip, we stop           */
-/*    issuing commands, i.e. moving them onto the issue queue.           */
-/*    Because of that, the disconnected queue will run empty in a         */
-/*    while. Instead we go to sleep on a 'fairness_queue'.                */
-/*  - If the lock is released, all processes waiting on the fairness      */
-/*    queue will be woken. The first of them tries to re-lock the DMA,     */
-/*    the others wait for the first to finish this task. After that,      */
-/*    they can all run on and do their commands...                        */
-/* This sounds complicated (and it is it :-(), but it seems to be a       */
-/* good compromise between fairness and performance: As long as no one     */
-/* else wants to work with the ST-DMA chip, SCSI can go along as          */
-/* usual. If now someone else comes, this behaviour is changed to a       */
-/* "fairness mode": just already initiated commands are finished and      */
-/* then the lock is released. The other one waiting will probably win     */
-/* the race for locking the DMA, since it was waiting for longer. And     */
-/* after it has finished, SCSI can go ahead again. Finally: I hope I      */
-/* have not produced any deadlock possibilities!                          */
-/*                                                                        */
-/**************************************************************************/
-
+/*
+ * Notes for Falcon SCSI DMA
+ *
+ * The 5380 device is one of several that all share the DMA chip. Hence
+ * "locking" and "unlocking" access to this chip is required.
+ *
+ * Two possible schemes for ST DMA acquisition by atari_scsi are:
+ * 1) The lock is taken for each command separately (i.e. can_queue == 1).
+ * 2) The lock is taken when the first command arrives and released
+ * when the last command is finished (i.e. can_queue > 1).
+ *
+ * The first alternative limits SCSI bus utilization, since interleaving
+ * commands is not possible. The second gives better performance but is
+ * unfair to other drivers needing to use the ST DMA chip. In order to
+ * allow the IDE and floppy drivers equal access to the ST DMA chip
+ * the default is can_queue == 1.
+ */
 
 #include <linux/module.h>
 #include <linux/types.h>
@@ -443,6 +411,10 @@ static int falcon_get_lock(struct Scsi_H
 	if (IS_A_TT())
 		return 1;
 
+	if (stdma_is_locked_by(scsi_falcon_intr) &&
+	    instance->hostt->can_queue > 1)
+		return 1;
+
 	if (in_interrupt())
 		return stdma_try_lock(scsi_falcon_intr, instance);
 
@@ -776,22 +748,11 @@ static int __init atari_scsi_probe(struc
 		atari_scsi_reg_write = atari_scsi_falcon_reg_write;
 	}
 
-	/* The values for CMD_PER_LUN and CAN_QUEUE are somehow arbitrary.
-	 * Higher values should work, too; try it!
-	 * (But cmd_per_lun costs memory!)
-	 *
-	 * But there seems to be a bug somewhere that requires CAN_QUEUE to be
-	 * 2*CMD_PER_LUN. At least on a TT, no spurious timeouts seen since
-	 * changed CMD_PER_LUN...
-	 *
-	 * Note: The Falcon currently uses 8/1 setting due to unsolved problems
-	 * with cmd_per_lun != 1
-	 */
 	if (ATARIHW_PRESENT(TT_SCSI)) {
 		atari_scsi_template.can_queue    = 16;
 		atari_scsi_template.sg_tablesize = SG_ALL;
 	} else {
-		atari_scsi_template.can_queue    = 8;
+		atari_scsi_template.can_queue    = 1;
 		atari_scsi_template.sg_tablesize = SG_NONE;
 	}
 

WARNING: multiple messages have this Message-ID (diff)
From: Finn Thain <fthain@telegraphics.com.au>
To: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Michael Schmitz <schmitzmic@gmail.com>,
	linux-m68k@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-kernel@vger.kernel.org
Cc: Ondrej Zary <linux@rainbow-software.org>, Sam Creasey <sammy@sammy.net>
Subject: [PATCH v4 21/23] atari_scsi: Allow can_queue to be increased for Falcon
Date: Wed, 23 Mar 2016 21:10:30 +1100	[thread overview]
Message-ID: <20160323101014.681781582@telegraphics.com.au> (raw)
In-Reply-To: 20160323101009.341929635@telegraphics.com.au

[-- Attachment #1: atari_scsi-can_queue --]
[-- Type: text/plain, Size: 6525 bytes --]

The benefit of limiting can_queue to 1 is that atari_scsi shares the
ST DMA chip more fairly with other drivers (e.g. falcon-ide).

Unfortunately, this can limit SCSI bus utilization. On systems without
IDE, atari_scsi should issue SCSI commands whenever it can arbitrate for
the bus. Make that possible by making can_queue configurable.

Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Tested-by: Michael Schmitz <schmitzmic@gmail.com>

---
 drivers/scsi/atari_scsi.c |   83 ++++++++++++----------------------------------
 1 file changed, 22 insertions(+), 61 deletions(-)

Index: linux/drivers/scsi/atari_scsi.c
===================================================================
--- linux.orig/drivers/scsi/atari_scsi.c	2016-03-23 21:10:03.000000000 +1100
+++ linux/drivers/scsi/atari_scsi.c	2016-03-23 21:10:04.000000000 +1100
@@ -14,55 +14,23 @@
  *
  */
 
-
-/**************************************************************************/
-/*                                                                        */
-/* Notes for Falcon SCSI:                                                 */
-/* ----------------------                                                 */
-/*                                                                        */
-/* Since the Falcon SCSI uses the ST-DMA chip, that is shared among       */
-/* several device drivers, locking and unlocking the access to this       */
-/* chip is required. But locking is not possible from an interrupt,       */
-/* since it puts the process to sleep if the lock is not available.       */
-/* This prevents "late" locking of the DMA chip, i.e. locking it just     */
-/* before using it, since in case of disconnection-reconnection           */
-/* commands, the DMA is started from the reselection interrupt.           */
-/*                                                                        */
-/* Two possible schemes for ST-DMA-locking would be:                      */
-/*  1) The lock is taken for each command separately and disconnecting    */
-/*     is forbidden (i.e. can_queue = 1).                                 */
-/*  2) The DMA chip is locked when the first command comes in and         */
-/*     released when the last command is finished and all queues are      */
-/*     empty.                                                             */
-/* The first alternative would result in bad performance, since the       */
-/* interleaving of commands would not be used. The second is unfair to    */
-/* other drivers using the ST-DMA, because the queues will seldom be      */
-/* totally empty if there is a lot of disk traffic.                       */
-/*                                                                        */
-/* For this reasons I decided to employ a more elaborate scheme:          */
-/*  - First, we give up the lock every time we can (for fairness), this    */
-/*    means every time a command finishes and there are no other commands */
-/*    on the disconnected queue.                                          */
-/*  - If there are others waiting to lock the DMA chip, we stop           */
-/*    issuing commands, i.e. moving them onto the issue queue.           */
-/*    Because of that, the disconnected queue will run empty in a         */
-/*    while. Instead we go to sleep on a 'fairness_queue'.                */
-/*  - If the lock is released, all processes waiting on the fairness      */
-/*    queue will be woken. The first of them tries to re-lock the DMA,     */
-/*    the others wait for the first to finish this task. After that,      */
-/*    they can all run on and do their commands...                        */
-/* This sounds complicated (and it is it :-(), but it seems to be a       */
-/* good compromise between fairness and performance: As long as no one     */
-/* else wants to work with the ST-DMA chip, SCSI can go along as          */
-/* usual. If now someone else comes, this behaviour is changed to a       */
-/* "fairness mode": just already initiated commands are finished and      */
-/* then the lock is released. The other one waiting will probably win     */
-/* the race for locking the DMA, since it was waiting for longer. And     */
-/* after it has finished, SCSI can go ahead again. Finally: I hope I      */
-/* have not produced any deadlock possibilities!                          */
-/*                                                                        */
-/**************************************************************************/
-
+/*
+ * Notes for Falcon SCSI DMA
+ *
+ * The 5380 device is one of several that all share the DMA chip. Hence
+ * "locking" and "unlocking" access to this chip is required.
+ *
+ * Two possible schemes for ST DMA acquisition by atari_scsi are:
+ * 1) The lock is taken for each command separately (i.e. can_queue == 1).
+ * 2) The lock is taken when the first command arrives and released
+ * when the last command is finished (i.e. can_queue > 1).
+ *
+ * The first alternative limits SCSI bus utilization, since interleaving
+ * commands is not possible. The second gives better performance but is
+ * unfair to other drivers needing to use the ST DMA chip. In order to
+ * allow the IDE and floppy drivers equal access to the ST DMA chip
+ * the default is can_queue == 1.
+ */
 
 #include <linux/module.h>
 #include <linux/types.h>
@@ -443,6 +411,10 @@ static int falcon_get_lock(struct Scsi_H
 	if (IS_A_TT())
 		return 1;
 
+	if (stdma_is_locked_by(scsi_falcon_intr) &&
+	    instance->hostt->can_queue > 1)
+		return 1;
+
 	if (in_interrupt())
 		return stdma_try_lock(scsi_falcon_intr, instance);
 
@@ -776,22 +748,11 @@ static int __init atari_scsi_probe(struc
 		atari_scsi_reg_write = atari_scsi_falcon_reg_write;
 	}
 
-	/* The values for CMD_PER_LUN and CAN_QUEUE are somehow arbitrary.
-	 * Higher values should work, too; try it!
-	 * (But cmd_per_lun costs memory!)
-	 *
-	 * But there seems to be a bug somewhere that requires CAN_QUEUE to be
-	 * 2*CMD_PER_LUN. At least on a TT, no spurious timeouts seen since
-	 * changed CMD_PER_LUN...
-	 *
-	 * Note: The Falcon currently uses 8/1 setting due to unsolved problems
-	 * with cmd_per_lun != 1
-	 */
 	if (ATARIHW_PRESENT(TT_SCSI)) {
 		atari_scsi_template.can_queue    = 16;
 		atari_scsi_template.sg_tablesize = SG_ALL;
 	} else {
-		atari_scsi_template.can_queue    = 8;
+		atari_scsi_template.can_queue    = 1;
 		atari_scsi_template.sg_tablesize = SG_NONE;
 	}
 

  parent reply	other threads:[~2016-03-23 10:17 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-23 10:10 [PATCH v4 00/23] ncr5380: Eliminate macros, reduce code duplication, fix bugs etc Finn Thain
2016-03-23 10:10 ` Finn Thain
2016-03-23 10:10 ` [PATCH v4 01/23] g_ncr5380: Remove CONFIG_SCSI_GENERIC_NCR53C400 Finn Thain
2016-03-23 10:10   ` Finn Thain
2016-03-23 10:10 ` [PATCH v4 02/23] ncr5380: Remove FLAG_NO_PSEUDO_DMA where possible Finn Thain
2016-03-23 10:10   ` Finn Thain
2016-03-23 10:10 ` [PATCH v4 03/23] ncr5380: Remove REAL_DMA and REAL_DMA_POLL macros Finn Thain
2016-03-23 10:10   ` Finn Thain
2016-03-23 10:10 ` [PATCH v4 04/23] atari_NCR5380: Remove DMA_MIN_SIZE macro Finn Thain
2016-03-23 10:10   ` Finn Thain
2016-03-23 10:10 ` [PATCH v4 05/23] ncr5380: Disable the DMA errata workaround flag by default Finn Thain
2016-03-23 10:10   ` Finn Thain
2016-03-23 10:10   ` Finn Thain
2016-03-23 10:10 ` [PATCH v4 06/23] ncr5380: Remove PSEUDO_DMA macro Finn Thain
2016-03-23 10:10   ` Finn Thain
2016-03-23 10:10   ` Finn Thain
2016-03-23 10:10 ` [PATCH v4 07/23] ncr5380: Remove BOARD_REQUIRES_NO_DELAY macro Finn Thain
2016-03-23 10:10   ` Finn Thain
2016-03-23 10:10 ` [PATCH v4 08/23] ncr5380: Use DMA hooks for PDMA Finn Thain
2016-03-23 10:10   ` Finn Thain
2016-03-23 10:10   ` Finn Thain
2016-03-23 10:10 ` [PATCH v4 09/23] ncr5380: Adopt uniform DMA setup convention Finn Thain
2016-03-23 10:10   ` Finn Thain
2016-03-23 10:10   ` Finn Thain
2016-03-23 10:10 ` [PATCH v4 10/23] ncr5380: Merge DMA implementation from atari_NCR5380 core driver Finn Thain
2016-03-23 10:10   ` Finn Thain
2016-03-23 10:10   ` Finn Thain
2016-03-23 10:10 ` [PATCH v4 11/23] atari_scsi: Adopt NCR5380.c " Finn Thain
2016-03-23 10:10   ` Finn Thain
2016-03-23 10:10 ` [PATCH v4 12/23] sun3_scsi: " Finn Thain
2016-03-23 10:10   ` Finn Thain
2016-03-23 10:10 ` [PATCH v4 13/23] ncr5380: Remove disused atari_NCR5380.c " Finn Thain
2016-03-23 10:10   ` Finn Thain
2016-03-23 10:10 ` [PATCH v4 14/23] ncr5380: Reduce max_lun limit Finn Thain
2016-03-23 10:10   ` Finn Thain
2016-03-23 10:10 ` [PATCH v4 15/23] dmx3191d: Drop max_sectors limit Finn Thain
2016-03-23 10:10   ` Finn Thain
2016-03-23 10:10 ` [PATCH v4 16/23] ncr5380: Fix register decoding for debugging Finn Thain
2016-03-23 10:10   ` Finn Thain
2016-03-23 10:10 ` [PATCH v4 17/23] ncr5380: Remove remaining register storage qualifiers Finn Thain
2016-03-23 10:10   ` Finn Thain
2016-03-23 10:10 ` [PATCH v4 18/23] ncr5380: Remove DONT_USE_INTR and AUTOPROBE_IRQ macros Finn Thain
2016-03-23 10:10   ` Finn Thain
2016-03-23 10:10   ` Finn Thain
2016-03-23 10:10 ` [PATCH v4 19/23] ncr5380: Update usage documentation Finn Thain
2016-03-23 10:10   ` Finn Thain
2016-03-23 10:10 ` [PATCH v4 20/23] atari_scsi: Set a reasonable default for cmd_per_lun Finn Thain
2016-03-23 10:10   ` Finn Thain
2016-03-23 10:10 ` Finn Thain [this message]
2016-03-23 10:10   ` [PATCH v4 21/23] atari_scsi: Allow can_queue to be increased for Falcon Finn Thain
2016-03-23 10:10 ` [PATCH v4 22/23] mac_scsi: Fix pseudo DMA implementation Finn Thain
2016-03-23 10:10   ` Finn Thain
2016-05-19  9:00   ` Geert Uytterhoeven
2016-05-19  9:00     ` Geert Uytterhoeven
2016-05-19 12:02     ` Finn Thain
2016-05-19 12:55       ` Geert Uytterhoeven
2016-03-23 10:10 ` [PATCH v4 23/23] ncr5380: Call complete_cmd() for disconnected commands on bus reset Finn Thain
2016-03-23 10:10   ` Finn Thain
2016-03-23 20:54 ` [PATCH v4 00/23] ncr5380: Eliminate macros, reduce code duplication, fix bugs etc Martin K. Petersen
2016-03-23 20:54   ` Martin K. Petersen

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=20160323101014.681781582@telegraphics.com.au \
    --to=fthain@telegraphics.com.au \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux@rainbow-software.org \
    --cc=martin.petersen@oracle.com \
    --cc=sammy@sammy.net \
    --cc=schmitzmic@gmail.com \
    /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.