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; }
next prev 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: linkBe 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.