public inbox for linux-kernel@vger.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 v3 21/23] atari_scsi: Allow can_queue to be increased for Falcon
Date: Mon, 21 Mar 2016 13:32:10 +1100	[thread overview]
Message-ID: <20160321023155.093996953@telegraphics.com.au> (raw)
In-Reply-To: 20160321023149.604138431@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-21 13:31:43.000000000 +1100
+++ linux/drivers/scsi/atari_scsi.c	2016-03-21 13:31:44.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-21  4:06 UTC|newest]

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

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=20160321023155.093996953@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox