Re: esp_scsi QTAG in FAS216
On Tue, 1 Nov 2016, Michael Schmitz wrote: > Hi Finn, > > Am 01.11.2016 um 12:47 schrieb Finn Thain: > > > > On Tue, 1 Nov 2016, Michael Schmitz wrote: > > > >>> I had tried to set that bit in zorro_esp_slave_configure but had not > >>> done a proper job of it - I'd only set esp->config3 and forgot to > >>> set tp->esp_config3. Time to retest this ... > >> > >> I don't think it's quite that easy - the ESP_CONFIG3_TENB bit needs > >> to be set for all targets if at least one SCSI-2 target is on the bus > >> and we allow dosconnecting, no? > > > > I think ESP_CONFIG3_TENB is for FAS100A and FASHME. The bug here is on > > ESP236 and FAS236, so ESP_CONFIG3_TBMS would be the relevant bit. > > I stand corrected. Err... confused. > > When setting ESP_CONFIG3_TBMS, should we set ESP_CONFIG3_GTM as well? I think that depends entirely on the target. But it isn't relevant to the bug at hand AFAICS. -- > > > The bit gets set when ESP_CONFIG2_SCSI2ENAB gets set (as in David's > > patch) so we then need to avoid clobbering it, since ESP_CONFIG3_TBMS > > == ESP_CONFIG3_EWIDE. I think we have to test for HME to avoid this > > clash. > > I'd want to set these bits for ESP236 and FAS236 only, so no clash with > HME. As you found out, ESP_CONFIG3_TBMS aka ESP_CONFIG3_EWIDE gets > clobbered on bus reset cleanup unconditionally. > > Cheers, > > Michael > > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: esp_scsi QTAG in FAS216
Hi Finn, Am 01.11.2016 um 12:47 schrieb Finn Thain: > > On Tue, 1 Nov 2016, Michael Schmitz wrote: > >>> I had tried to set that bit in zorro_esp_slave_configure but had not >>> done a proper job of it - I'd only set esp->config3 and forgot to set >>> tp->esp_config3. Time to retest this ... >> >> I don't think it's quite that easy - the ESP_CONFIG3_TENB bit needs to >> be set for all targets if at least one SCSI-2 target is on the bus and >> we allow dosconnecting, no? > > I think ESP_CONFIG3_TENB is for FAS100A and FASHME. The bug here is on > ESP236 and FAS236, so ESP_CONFIG3_TBMS would be the relevant bit. I stand corrected. Err... confused. When setting ESP_CONFIG3_TBMS, should we set ESP_CONFIG3_GTM as well? > The bit gets set when ESP_CONFIG2_SCSI2ENAB gets set (as in David's > patch) so we then need to avoid clobbering it, since ESP_CONFIG3_TBMS == > ESP_CONFIG3_EWIDE. I think we have to test for HME to avoid this clash. I'd want to set these bits for ESP236 and FAS236 only, so no clash with HME. As you found out, ESP_CONFIG3_TBMS aka ESP_CONFIG3_EWIDE gets clobbered on bus reset cleanup unconditionally. Cheers, Michael -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: esp_scsi QTAG in FAS216
On Tue, 1 Nov 2016, Michael Schmitz wrote: > > I had tried to set that bit in zorro_esp_slave_configure but had not > > done a proper job of it - I'd only set esp->config3 and forgot to set > > tp->esp_config3. Time to retest this ... > > I don't think it's quite that easy - the ESP_CONFIG3_TENB bit needs to > be set for all targets if at least one SCSI-2 target is on the bus and > we allow dosconnecting, no? I think ESP_CONFIG3_TENB is for FAS100A and FASHME. The bug here is on ESP236 and FAS236, so ESP_CONFIG3_TBMS would be the relevant bit. The bit gets set when ESP_CONFIG2_SCSI2ENAB gets set (as in David's patch) so we then need to avoid clobbering it, since ESP_CONFIG3_TBMS == ESP_CONFIG3_EWIDE. I think we have to test for HME to avoid this clash. -- > > Adrian - any chance I can get access to elgar again for some more testing? > > Cheers, > > Michael -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: esp_scsi QTAG in FAS216
Hi Finn, Am 30.10.2016 um 15:33 schrieb Finn Thain: > > On Sat, 29 Oct 2016, I wrote: > >> >> On Sun, 13 Apr 2014, David Miller wrote: >> >>> >>> But oddly in the NCR53CX docs: >>> >>> >>> http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR53C9X.txt >>> >>> it speaks as if ESP_CONFIG3_TMS and ESP_CONFIG3_TENB are merely finer >>> grained versions of config2 register setting ESP_CONFIG2_SCSI2ENAB, >>> which enables both features. >> >> Yes, so setting the ESP_CONFIG2_SCSI2ENAB bit is correct. The only >> problem is, doesn't the ESP_CONFIG3_TMS bit get cleared again later, >> when the CONFIG3 register is written to? >> > > Nevermind my question. To falsify my own theory, I see that > ESP_CONFIG3_TMS == ESP_CONFIG3_FCLK, and thus esp_scsi does actually set > the relevant bit, and therefore "the FSC can receive 3-byte messages > during businitiated select with ATN." >From my reading of the quoted docs,ESP_CONFIG3_TMS is valid for FAS100A (and later?). What esp_scsi sets (for FAS236 chips) is fast SCSI clock mode. The relevant bit for three byte message support for Mac and Amiga ESP hardware should be ESP_CONFIG3_TENB. I had tried to set that bit in zorro_esp_slave_configure but had not done a proper job of it - I'd only set esp->config3 and forgot to set tp->esp_config3. Time to retest this ... Cheers, Michael -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: esp_scsi QTAG in FAS216
On Sat, 29 Oct 2016, I wrote: > > On Sun, 13 Apr 2014, David Miller wrote: > > > > > But oddly in the NCR53CX docs: > > > > > > http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR53C9X.txt > > > > it speaks as if ESP_CONFIG3_TMS and ESP_CONFIG3_TENB are merely finer > > grained versions of config2 register setting ESP_CONFIG2_SCSI2ENAB, > > which enables both features. > > Yes, so setting the ESP_CONFIG2_SCSI2ENAB bit is correct. The only > problem is, doesn't the ESP_CONFIG3_TMS bit get cleared again later, > when the CONFIG3 register is written to? > Nevermind my question. To falsify my own theory, I see that ESP_CONFIG3_TMS == ESP_CONFIG3_FCLK, and thus esp_scsi does actually set the relevant bit, and therefore "the FSC can receive 3-byte messages during businitiated select with ATN." -- -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: esp_scsi QTAG in FAS216
On Sun, 13 Apr 2014, David Miller wrote:
> > esp_get_revision but later cleared in the same function. It appears
> > we'd need to set it after the call to scsi_esp_register() - can you
> > test whether that obsoletes the zorro_esp_slave_configure hack,
> > Tuomas?
> ...
> > > Group 2 Commands
> > > (seems to only be relevant for target mode).
> > >
> > > And about the QTE bit:
> > >
> > > Bit 6 Queue Tag Enable
> > >
> > > When this bit is set, the 53CF94/96 can receive 3-byte messages
> > > during bus-initiated Select With ATN. This feature is also enabled
> > > by setting bit 3 in the Configuration 2 register.
> >
> > My preference would be to set this one (named ESP_CONFIG3_TBMS). Your
> > opinion, Dave?
>
> As seems to be agreed upon here, the SCSI2 bit in the CONFIG2 register
> (ESP_CONFIG2_SCSI2ENAB) is only for when the chip is used in target
> mode. So it is not relevant for our discussion because this driver is
> for initiator mode operation only.
>
> But some pieces of documentation seem like they might not agree on this
> point.
I think there is ambiguity, and I see some differences between the
documentation for ESP236 and that for FAS236 devices. But I don't agree
that ESP_CONFIG2_SCSI2ENAB is only for target mode.
This bug affects re-selection. So documentation which refers to a "device
[being] selected" tends to be ambiguous, because re-selection is still
selection in some sense. E.g. the Am53C94/Am53C96 (preliminary) datasheet
says this:
Extended Message Feature: When the S2FE [ESP_CONFIG2_SCSI2ENAB] bit is
set and the device is selected with attention, the device will monitor
the /ATN signal at the end of the first message byte. If the /ATN
signal is active, the device will request two more message bytes
before switching to the command phase. If the /ATN signal is inactive
the device will switch to the command phase.
But the next part is clear enough and seems to explain the mac_esp
(ESP236) failure:
When the S2FE bit is reset the device as a target will request a
single message byte. As an initiator, the device will abort the
selection sequence if the target does not switch to the command phase
after receiving a single message byte.
The document you cited, NCR53C9X.txt, seems unambiguous about the role of
the initiator. (Just search for "identify message" to see the relevant
parts.)
Moreover, for reselection, NCR53C9X.txt says the chip will expect 2 tag
bytes only when tagged queueing is enabled, that is, QTE bit aka
ESP_CONFIG3_TMS bit is set. The QTE feature "is also enabled by setting
bit 3 in the Configuration 2 register", aka ESP_CONFIG2_SCSI2ENAB, which
is what your patch does.
>
> With respect to bit 3 in the config3 register, it can take on one of
> two meaning depending upon chip revision. As per ESP_CONFIG3_{TMS,FCLK}
> it either controls fast SCSI clocking, or it enabled 3 byte message
> recognition.
>
> But oddly in the NCR53CX docs:
>
>
> http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR53C9X.txt
>
> it speaks as if ESP_CONFIG3_TMS and ESP_CONFIG3_TENB are merely finer
> grained versions of config2 register setting ESP_CONFIG2_SCSI2ENAB,
> which enables both features.
Yes, so setting the ESP_CONFIG2_SCSI2ENAB bit is correct. The only problem
is, doesn't the ESP_CONFIG3_TMS bit get cleared again later, when the
CONFIG3 register is written to?
>
> Again I looked at the FreeBSD driver and for all chips after plain
> esp100, they set ESP_CONFIG2_SCSI2ENAB.
>
> Can we try testing the following patch?
It could be that this patch would be sufficient to fix mac_esp because
ESP236 seems to have no ESP_CONFIG3_TMS bit.
We know that this patch didn't work for zorro_esp (FAS236) but it would be
helpful to know what value the CONFIG3 register took in the end.
--
>
>
> esp_scsi: Set SCSI2 bit in config2 register.
>
> This should allow proper recognition of 3 byte reselection
> on all esp100a and later chips.
>
> Reported-by: Kars de Jong
> Reported-by: Michael Schmitz
> Signed-off-by: David S. Miller
>
> diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
> index 55548dc..16f69e0 100644
> --- a/drivers/scsi/esp_scsi.c
> +++ b/drivers/scsi/esp_scsi.c
> @@ -2160,7 +2160,7 @@ static void esp_get_revision(struct esp *esp)
>*/
> esp->rev = ESP100;
> } else {
> - esp->config2 = 0;
> + esp->config2 = ESP_CONFIG2_SCSI2ENAB;
> esp_set_all_config3(esp, 5);
> esp->prev_cfg3 = 5;
> esp_write8(esp->config2, ESP_CFG2);
> @@ -2187,8 +2187,6 @@ static void esp_get_revision(struct esp *esp)
> } else {
> esp->rev = ESP236;
> }
> - esp->config2 = 0;
> -
Re: esp_scsi QTAG in FAS216
Hi Michael,
[sorry for the long delay]
On Mon, Apr 14, 2014 at 10:51 AM, Michael Schmitz schmitz...@gmail.com wrote:
Not sure my patch had ever made it into Geert's m68k-queue - except for the
patch in my previous mail, my zorro_esp.c is still the same as I got from
you in October last year. The project has been on the back burner for too
long ...
I don't think it makes much sense to add it to my queue, as it's purely SCSI
and not critical for current m68k.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-m68k in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: esp_scsi QTAG in FAS216
Hi Geert, [sorry for the long delay] Tell me about it :-) I haven't had a good idea how to address this problem so rather kept mum about it. On Mon, Apr 14, 2014 at 10:51 AM, Michael Schmitz schmitz...@gmail.com wrote: Not sure my patch had ever made it into Geert's m68k-queue - except for the patch in my previous mail, my zorro_esp.c is still the same as I got from you in October last year. The project has been on the back burner for too long ... I don't think it makes much sense to add it to my queue, as it's purely SCSI and not critical for current m68k. Fine, Ill try and resolve that with Dave then. Tuomas will need to do the testing (unless someone wants to drop off the necessary hardware with me - unlikely). Thanks, Michael -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: esp_scsi QTAG in FAS216
On 14.04.2014 12:01, Michael Schmitz wrote:
Hi Dave,
When this bit is set, the 53CF94/96 can receive 3-byte messages during
bus-initiated Select With ATN. This feature is also enabled by setting
bit 3 in the Configuration 2 register.
My preference would be to set this one (named ESP_CONFIG3_TBMS). Your
opinion, Dave?
As seems to be agreed upon here, the SCSI2 bit in the CONFIG2 register
(ESP_CONFIG2_SCSI2ENAB) is only for when the chip is used in target
mode. So it is not relevant for our discussion because this driver is
for initiator mode operation only.
Agreed. ESP_CONFIG2_SCSI2ENAB might do more than we intend, and have
unintended side effects. It's just easier to test whether this fixes
our problem.
But some pieces of documentation seem like they might not agree on
this point.
With respect to bit 3 in the config3 register, it can take on one of
two meaning depending upon chip revision. As per ESP_CONFIG3_{TMS,FCLK}
it either controls fast SCSI clocking, or it enabled 3 byte message
recognition.
But oddly in the NCR53CX docs:
http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR53C9X.txt
it speaks as if ESP_CONFIG3_TMS and ESP_CONFIG3_TENB are merely finer
grained versions of config2 register setting ESP_CONFIG2_SCSI2ENAB,
which enables both features.
That's what I understood from the bits Kars quoted, yes. And in the
Amiga driver cases, it will always be the 3 byte message feature
controlled by that bit, as far as I can see.
Again I looked at the FreeBSD driver and for all chips after plain
esp100, they set ESP_CONFIG2_SCSI2ENAB.
Can we try testing the following patch?
That would be even easier than setting it explicitly in the Zorro
driver, thanks,
Michael
esp_scsi: Set SCSI2 bit in config2 register.
This should allow proper recognition of 3 byte reselection
on all esp100a and later chips.
Reported-by: Kars de Jong jo...@linux-m68k.org
Reported-by: Michael Schmitz schmitz...@gmail.com
Signed-off-by: David S. Miller da...@davemloft.net
diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index 55548dc..16f69e0 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -2160,7 +2160,7 @@ static void esp_get_revision(struct esp *esp)
*/
esp-rev = ESP100;
} else {
-esp-config2 = 0;
+esp-config2 = ESP_CONFIG2_SCSI2ENAB;
esp_set_all_config3(esp, 5);
esp-prev_cfg3 = 5;
esp_write8(esp-config2, ESP_CFG2);
@@ -2187,8 +2187,6 @@ static void esp_get_revision(struct esp *esp)
} else {
esp-rev = ESP236;
}
-esp-config2 = 0;
-esp_write8(esp-config2, ESP_CFG2);
}
}
}
Hello,
The patch above doesn't work. I've attached a log. Looks like the same
problem we've had all along.
The gzipped logs have all esp_scsi debug messages enabled for a
non-patched and patched versions.
-Tuomas
modprobe zorro_esp
zorro_esp: Blizzard 1230 found at address 0xea.
esp: esp0, regs[80ea8000:80eb] irq[2]
esp: esp0 is a FAS236, 40 MHz (ccf=0), SCSI ID 7
scsi0 : esp
scsi 0:0:2:0: Direct-Access SEAGATE ST51080N 0913 PQ: 0 ANSI: 2
scsi target0:0:2: Beginning Domain Validation
scsi target0:0:2: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 15)
scsi target0:0:2: Domain Validation skipping write tests
scsi target0:0:2: Ending Domain Validation
sd 0:0:2:0: [sda] 2109840 512-byte logical blocks: (1.08 GB/1.00 GiB)
sd 0:0:2:0: [sda] Write Protect is off
sd 0:0:2:0: [sda] Write cache: disabled, read cache: enabled, doesn't support
DPO or FUA
sd 0:0:2:0: Attached scsi generic sg0 type 0
esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB:
Read(10): 28 00 00 00 00 00 00 00 08 00
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB:
Read(10): 28 00 00 00 00 00 00 00 08 00
end_request: I/O error, dev sda, sector 0
Buffer I/O error on device sda, logical block 0
Dev sda: unable to read RDB block 0
sda: unable to read partition table
sd 0:0:2:0: [sda] Attached SCSI disk
root@amiga:~# esp: esp0: Reconnect IRQ2 timeout
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB:
Read(10): 28 00 00 20 31 00 00 00 08 00
end_request: I/O error, dev sda, sector 2109696
Buffer I/O error on device sda, logical block 263712
sd 0:0:2:0: [sda] Unhandled error code
sd 0:0:2:0: [sda]
Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 0:0:2:0: [sda] CDB:
Read(10): 28 00 00 20 31 00 00 00 08 00
end_request: I/O error, dev sda, sector 2109696
Buffer I/O error on device sda, logical block 263712
esp: esp0: Reconnect IRQ2 timeout
Re: esp_scsi QTAG in FAS216
Hi Tuomas,
My preference would be to set this one (named ESP_CONFIG3_TBMS). Your
opinion, Dave?
As seems to be agreed upon here, the SCSI2 bit in the CONFIG2 register
(ESP_CONFIG2_SCSI2ENAB) is only for when the chip is used in target
mode. So it is not relevant for our discussion because this driver is
for initiator mode operation only.
But some pieces of documentation seem like they might not agree on
this point.
With respect to bit 3 in the config3 register, it can take on one of
two meaning depending upon chip revision. As per
ESP_CONFIG3_{TMS,FCLK}
it either controls fast SCSI clocking, or it enabled 3 byte message
recognition.
But oddly in the NCR53CX docs:
http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/
NCR53C9X.txt
it speaks as if ESP_CONFIG3_TMS and ESP_CONFIG3_TENB are merely finer
grained versions of config2 register setting ESP_CONFIG2_SCSI2ENAB,
which enables both features.
Again I looked at the FreeBSD driver and for all chips after plain
esp100, they set ESP_CONFIG2_SCSI2ENAB.
Can we try testing the following patch?
esp_scsi: Set SCSI2 bit in config2 register.
This should allow proper recognition of 3 byte reselection
on all esp100a and later chips.
Reported-by: Kars de Jong jo...@linux-m68k.org
Reported-by: Michael Schmitz schmitz...@gmail.com
Signed-off-by: David S. Miller da...@davemloft.net
diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index 55548dc..16f69e0 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -2160,7 +2160,7 @@ static void esp_get_revision(struct esp *esp)
*/
esp-rev = ESP100;
} else {
- esp-config2 = 0;
+ esp-config2 = ESP_CONFIG2_SCSI2ENAB;
esp_set_all_config3(esp, 5);
esp-prev_cfg3 = 5;
esp_write8(esp-config2, ESP_CFG2);
@@ -2187,8 +2187,6 @@ static void esp_get_revision(struct esp *esp)
} else {
esp-rev = ESP236;
}
- esp-config2 = 0;
- esp_write8(esp-config2, ESP_CFG2);
}
}
}
I'll test these out soon.
Michael, where can I pull the latest version of zorro_esp?
Not sure my patch had ever made it into Geert's m68k-queue - except for
the patch in my previous mail, my zorro_esp.c is still the same as I
got from you in October last year. The project has been on the back
burner for too long ...
I'll look into setting up pull access to my repository. zorro_esp.c as
of today attached for now.
Cheers,
Michael
/* zorrro_esp.c: ESP front-end for Amiga ZORRO SCSI systems.
*
* Copyright (C) 1996 Jesper Skov (js...@cygnus.co.uk)
*
* Copyright (C) 2011 Michael Schmitz (schm...@debian.org) for
* migration to ESP SCSI core
*/
/*
* ZORRO bus code from:
*/
/*
* Detection routine for the NCR53c710 based Amiga SCSI Controllers for Linux.
* Amiga MacroSystemUS WarpEngine SCSI controller.
* Amiga Technologies/DKB A4091 SCSI controller.
*
* Written 1997 by Alan Hourihane al...@fairlite.demon.co.uk
* plus modifications of the 53c7xx.c driver to support the Amiga.
*
* Rewritten to use 53c700.c by Kars de Jong jo...@linux-m68k.org
*/
#include linux/module.h
#include linux/init.h
#include linux/interrupt.h
#include linux/ratelimit.h
#include linux/dma-mapping.h
#include linux/scatterlist.h
#include linux/delay.h
#include linux/zorro.h
#include linux/slab.h
#include asm/page.h
#include asm/pgtable.h
#include asm/cacheflush.h
#include asm/amigahw.h
#include asm/amigaints.h
#include scsi/scsi_host.h
#include scsi/scsi_transport_spi.h
#include scsi/scsi_device.h
#include scsi/scsi_tcq.h
#include esp_scsi.h
MODULE_AUTHOR(Michael Schmitz schm...@debian.org);
MODULE_DESCRIPTION(Amiga Zorro NCR5C9x (ESP) driver);
MODULE_LICENSE(GPL);
#define DMA_WRITE 0x8000
static struct zorro_driver_data {
const char *name;
unsigned long offset;
unsigned long dma_offset;
int absolute;
int zorro3; /* offset is absolute address */
} zorro_esp_driver_data[] = {
{ .name = CyberStormI, .offset = 0xf400, .dma_offset = 0xf800,
.absolute = 0, .zorro3 = 0 },
{ .name = CyberStormII, .offset = 0x1ff03, .dma_offset = 0x1ff43,
.absolute = 0, .zorro3 = 0 },
{ .name = Blizzard 2060, .offset = 0x1ff00, .dma_offset = 0x1ffe0,
.absolute = 0, .zorro3 = 0 },
{ .name = Blizzard 1230, .offset = 0x8000, .dma_offset = 0x1,
.absolute = 0, .zorro3 = 0 },
{ .name = Blizzard 1230II, .offset = 0x1, .dma_offset = 0x10021,
.absolute = 0, .zorro3 = 0 },
{ .name = Fastlane, .offset = 0x101, .dma_offset = 0x141,
.absolute = 0, .zorro3 = 1 },
{ 0 }
};
static struct zorro_device_id zorro_esp_zorro_tbl[] = {
{
.id =
Re: esp_scsi QTAG in FAS216
Hi Dave,
When this bit is set, the 53CF94/96 can receive 3-byte messages
during
bus-initiated Select With ATN. This feature is also enabled by
setting
bit 3 in the Configuration 2 register.
My preference would be to set this one (named ESP_CONFIG3_TBMS). Your
opinion, Dave?
As seems to be agreed upon here, the SCSI2 bit in the CONFIG2 register
(ESP_CONFIG2_SCSI2ENAB) is only for when the chip is used in target
mode. So it is not relevant for our discussion because this driver is
for initiator mode operation only.
Agreed. ESP_CONFIG2_SCSI2ENAB might do more than we intend, and have
unintended side effects. It's just easier to test whether this fixes
our problem.
But some pieces of documentation seem like they might not agree on
this point.
With respect to bit 3 in the config3 register, it can take on one of
two meaning depending upon chip revision. As per
ESP_CONFIG3_{TMS,FCLK}
it either controls fast SCSI clocking, or it enabled 3 byte message
recognition.
But oddly in the NCR53CX docs:
http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/
NCR53C9X.txt
it speaks as if ESP_CONFIG3_TMS and ESP_CONFIG3_TENB are merely finer
grained versions of config2 register setting ESP_CONFIG2_SCSI2ENAB,
which enables both features.
That's what I understood from the bits Kars quoted, yes. And in the
Amiga driver cases, it will always be the 3 byte message feature
controlled by that bit, as far as I can see.
Again I looked at the FreeBSD driver and for all chips after plain
esp100, they set ESP_CONFIG2_SCSI2ENAB.
Can we try testing the following patch?
That would be even easier than setting it explicitly in the Zorro
driver, thanks,
Michael
esp_scsi: Set SCSI2 bit in config2 register.
This should allow proper recognition of 3 byte reselection
on all esp100a and later chips.
Reported-by: Kars de Jong jo...@linux-m68k.org
Reported-by: Michael Schmitz schmitz...@gmail.com
Signed-off-by: David S. Miller da...@davemloft.net
diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index 55548dc..16f69e0 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -2160,7 +2160,7 @@ static void esp_get_revision(struct esp *esp)
*/
esp-rev = ESP100;
} else {
- esp-config2 = 0;
+ esp-config2 = ESP_CONFIG2_SCSI2ENAB;
esp_set_all_config3(esp, 5);
esp-prev_cfg3 = 5;
esp_write8(esp-config2, ESP_CFG2);
@@ -2187,8 +2187,6 @@ static void esp_get_revision(struct esp *esp)
} else {
esp-rev = ESP236;
}
- esp-config2 = 0;
- esp_write8(esp-config2, ESP_CFG2);
}
}
}
--
To unsubscribe from this list: send the line unsubscribe linux-m68k in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: esp_scsi QTAG in FAS216
Hi Michael, 2014-04-11 3:47 GMT+02:00 Michael Schmitz schmitz...@gmail.com: The more important issue is the one about the one-byte reconnect message. Does the manual speak to that particular issue? Any hint on how we could enable SCSI-2 features on chip init? There's the SCSI2 bit in the Config 2 register and/or the QTE bit in the Config 3 register. The 53CF9x-2 manual says about SCSI-2 bit: Bit 2 SCSI-2 Setting this bit allows the FSC to support two new features adopted in SCSI-2: the 3-byte message exchange for Tagged-Queueing and Group 2 commands. These features can also be set independently in the Config 3 register. Tagged-Queueing When this bit is set and the FSC is selected with ATN (Attention), it will request either one or three message bytes depending on whether ATN remains true or goes false. If ATN is still true after the first byte has been received, the FSC may request two more message bytes before switching to Command phase. If ATN goes false, it will switch to Command phase after the first message byte. When the bit is not set it will request a single message byte (as a target) when selected with ATN, and abort the selection sequence (as an initiator) if the target does not switch to Command phase after one message byte has been transferred. Group 2 Commands (seems to only be relevant for target mode). And about the QTE bit: Bit 6 Queue Tag Enable When this bit is set, the 53CF94/96 can receive 3-byte messages during bus-initiated Select With ATN. This feature is also enabled by setting bit 3 in the Configuration 2 register. The message bytes consist of a one-byte identify message and a two-byte queue tag message. The middle byte is the tagged queue message itself and the last byte is the tag value (0 to 255). When this bit is set, the second byte is checked to see if it is a valid queue tagging message. If the value of the byte is not 20, 21 or 22h, the sequence halts and an interrupt is generated. When this bit is not set, the chip aborts the Select With ATN sequence after it receives one Identify Message byte, if ATN is still asserted. Then there is a section called Bus Initiated Reselection: Bus Initiated Reselection The FSC will allow itself to be reselected as an initiator by a target if it has previously received the Enable Selection/Reselection command. If the sequence completes normally, the following information will be in the FIFO: * Bus ID * Identify Message * Optional 2-byte queue tag message The bus ID will always be present and will always be one byte. It is an un-encoded version of the state of the bus during Reselection phase. The identify message will always be present and will always be one byte. If queue tagging is enabled, and the target is sending a queue tag message, the target will also send two queue tag message bytes. Can you point me to a source for the manuals if possible? I only have dead tree versions of the QLogic manual and the Symbios Logic manual. The only public place I know of is bitsavers, they do have a manual for the 53C94/95/96 online here: http://bitsavers.trailing-edge.com/pdf/ncr/scsi/NCR_53C94_53C95_53C96_Data_Sheet_Feb90.pdf. I put the 53C90A/B manual online at http://members.home.nl/karsdejong/NCR53C90ab.pdf and a preliminary version of the 53CF94/96-2 at http://members.home.nl/karsdejong/NCR53CF9x-2.pdf. Kind regards, Kars. -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: esp_scsi QTAG in FAS216
Hi Kars,
thanks for the PDFs!
Bit 2 SCSI-2
Setting this bit allows the FSC to support two new features adopted in
SCSI-2: the 3-byte message exchange for Tagged-Queueing and Group 2
commands. These features can also be set independently in the Config 3
register.
Tagged-Queueing
When this bit is set and the FSC is selected with ATN (Attention), it
will request either one or three message bytes depending on whether
ATN remains true or goes false. If ATN is still true after the first
byte has been received, the FSC may request two more message bytes
before switching to Command phase. If ATN goes false, it will switch
to Command phase after the first message byte. When the bit is not set
it will request a single message byte (as a target) when selected with
ATN, and abort the selection sequence (as an initiator) if the target
does not switch to Command phase after one message byte has been
transferred.
That appears to be our problem if I recall correctly Tuomas' debugging
report. (reselection, not selection as initiator). As
esp_slave_configure() enables queue tags regardless of chip config,
we'd best make certain the chip is configured correctly.
The SCSI2 bit is used to test for presence of config register 2 in
esp_get_revision but later cleared in the same function. It appears
we'd need to set it after the call to scsi_esp_register() - can you
test whether that obsoletes the zorro_esp_slave_configure hack,
Tuomas?
diff --git a/drivers/scsi/zorro_esp.c b/drivers/scsi/zorro_esp.c
index 1a1eb95..b33c3b5 100644
--- a/drivers/scsi/zorro_esp.c
+++ b/drivers/scsi/zorro_esp.c
@@ -418,9 +418,6 @@ static int zorro_esp_init_one(struct zorro_dev *z,
return -EBUSY;
}
- /* Fill in the required pieces of hostdata */
- scsi_esp_template.slave_configure = zorro_esp_slave_configure;
-
host = scsi_host_alloc(tpnt, sizeof(struct esp));
if (!host) {
@@ -508,6 +505,10 @@ static int zorro_esp_init_one(struct zorro_dev *z,
if (err)
goto fail_free_irq;
+ esp-config2 = ESP_CONFIG2_SCSI2ENAB;
+ zorro_esp_write8(esp, esp-config2, ESP_CFG2);
+
+
zorro_set_drvdata(z, host);
return 0;
Group 2 Commands
(seems to only be relevant for target mode).
And about the QTE bit:
Bit 6 Queue Tag Enable
When this bit is set, the 53CF94/96 can receive 3-byte messages during
bus-initiated Select With ATN. This feature is also enabled by setting
bit 3 in the Configuration 2 register.
My preference would be to set this one (named ESP_CONFIG3_TBMS). Your
opinion, Dave?
Cheers,
Michael
--
To unsubscribe from this list: send the line unsubscribe linux-m68k in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: esp_scsi QTAG in FAS216
From: Michael Schmitz schmitz...@gmail.com
Date: Mon, 14 Apr 2014 10:38:09 +1200
That appears to be our problem if I recall correctly Tuomas' debugging
report. (reselection, not selection as initiator). As
esp_slave_configure() enables queue tags regardless of chip config,
we'd best make certain the chip is configured correctly.
The SCSI2 bit is used to test for presence of config register 2 in
esp_get_revision but later cleared in the same function. It appears
we'd need to set it after the call to scsi_esp_register() - can you
test whether that obsoletes the zorro_esp_slave_configure hack,
Tuomas?
...
Group 2 Commands
(seems to only be relevant for target mode).
And about the QTE bit:
Bit 6 Queue Tag Enable
When this bit is set, the 53CF94/96 can receive 3-byte messages during
bus-initiated Select With ATN. This feature is also enabled by setting
bit 3 in the Configuration 2 register.
My preference would be to set this one (named ESP_CONFIG3_TBMS). Your
opinion, Dave?
As seems to be agreed upon here, the SCSI2 bit in the CONFIG2 register
(ESP_CONFIG2_SCSI2ENAB) is only for when the chip is used in target
mode. So it is not relevant for our discussion because this driver is
for initiator mode operation only.
But some pieces of documentation seem like they might not agree on
this point.
With respect to bit 3 in the config3 register, it can take on one of
two meaning depending upon chip revision. As per ESP_CONFIG3_{TMS,FCLK}
it either controls fast SCSI clocking, or it enabled 3 byte message
recognition.
But oddly in the NCR53CX docs:
http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR53C9X.txt
it speaks as if ESP_CONFIG3_TMS and ESP_CONFIG3_TENB are merely finer
grained versions of config2 register setting ESP_CONFIG2_SCSI2ENAB,
which enables both features.
Again I looked at the FreeBSD driver and for all chips after plain
esp100, they set ESP_CONFIG2_SCSI2ENAB.
Can we try testing the following patch?
esp_scsi: Set SCSI2 bit in config2 register.
This should allow proper recognition of 3 byte reselection
on all esp100a and later chips.
Reported-by: Kars de Jong jo...@linux-m68k.org
Reported-by: Michael Schmitz schmitz...@gmail.com
Signed-off-by: David S. Miller da...@davemloft.net
diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index 55548dc..16f69e0 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -2160,7 +2160,7 @@ static void esp_get_revision(struct esp *esp)
*/
esp-rev = ESP100;
} else {
- esp-config2 = 0;
+ esp-config2 = ESP_CONFIG2_SCSI2ENAB;
esp_set_all_config3(esp, 5);
esp-prev_cfg3 = 5;
esp_write8(esp-config2, ESP_CFG2);
@@ -2187,8 +2187,6 @@ static void esp_get_revision(struct esp *esp)
} else {
esp-rev = ESP236;
}
- esp-config2 = 0;
- esp_write8(esp-config2, ESP_CFG2);
}
}
}
--
To unsubscribe from this list: send the line unsubscribe linux-m68k in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: esp_scsi QTAG in FAS216
On 14.04.2014 05:14, David Miller wrote:
From: Michael Schmitz schmitz...@gmail.com
Date: Mon, 14 Apr 2014 10:38:09 +1200
That appears to be our problem if I recall correctly Tuomas' debugging
report. (reselection, not selection as initiator). As
esp_slave_configure() enables queue tags regardless of chip config,
we'd best make certain the chip is configured correctly.
The SCSI2 bit is used to test for presence of config register 2 in
esp_get_revision but later cleared in the same function. It appears
we'd need to set it after the call to scsi_esp_register() - can you
test whether that obsoletes the zorro_esp_slave_configure hack,
Tuomas?
...
Group 2 Commands
(seems to only be relevant for target mode).
And about the QTE bit:
Bit 6 Queue Tag Enable
When this bit is set, the 53CF94/96 can receive 3-byte messages during
bus-initiated Select With ATN. This feature is also enabled by setting
bit 3 in the Configuration 2 register.
My preference would be to set this one (named ESP_CONFIG3_TBMS). Your
opinion, Dave?
As seems to be agreed upon here, the SCSI2 bit in the CONFIG2 register
(ESP_CONFIG2_SCSI2ENAB) is only for when the chip is used in target
mode. So it is not relevant for our discussion because this driver is
for initiator mode operation only.
But some pieces of documentation seem like they might not agree on
this point.
With respect to bit 3 in the config3 register, it can take on one of
two meaning depending upon chip revision. As per ESP_CONFIG3_{TMS,FCLK}
it either controls fast SCSI clocking, or it enabled 3 byte message
recognition.
But oddly in the NCR53CX docs:
http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR53C9X.txt
it speaks as if ESP_CONFIG3_TMS and ESP_CONFIG3_TENB are merely finer
grained versions of config2 register setting ESP_CONFIG2_SCSI2ENAB,
which enables both features.
Again I looked at the FreeBSD driver and for all chips after plain
esp100, they set ESP_CONFIG2_SCSI2ENAB.
Can we try testing the following patch?
esp_scsi: Set SCSI2 bit in config2 register.
This should allow proper recognition of 3 byte reselection
on all esp100a and later chips.
Reported-by: Kars de Jong jo...@linux-m68k.org
Reported-by: Michael Schmitz schmitz...@gmail.com
Signed-off-by: David S. Miller da...@davemloft.net
diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index 55548dc..16f69e0 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -2160,7 +2160,7 @@ static void esp_get_revision(struct esp *esp)
*/
esp-rev = ESP100;
} else {
- esp-config2 = 0;
+ esp-config2 = ESP_CONFIG2_SCSI2ENAB;
esp_set_all_config3(esp, 5);
esp-prev_cfg3 = 5;
esp_write8(esp-config2, ESP_CFG2);
@@ -2187,8 +2187,6 @@ static void esp_get_revision(struct esp *esp)
} else {
esp-rev = ESP236;
}
- esp-config2 = 0;
- esp_write8(esp-config2, ESP_CFG2);
}
}
}
I'll test these out soon.
Michael, where can I pull the latest version of zorro_esp?
-Tuomas
--
To unsubscribe from this list: send the line unsubscribe linux-m68k in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: esp_scsi QTAG in FAS216
2014-04-06 22:33 GMT+02:00 Michael Schmitz schmitz...@gmail.com: Hello Dave, Tuomas, Also, looking at the timeout formulae in the old NCR53C9x.c driver, the values would be different for FAS216. Why was this dropped from the modern esp_scsi? I've never seen a formula for any ESP or FAS chip for the timeout other than the one mentioned in huge comment in esp_set_clock_params(), although I do see the 7668 instead of 8192 factor being used in the old NCR53C9x driver. I haven't gone far enough back in the 53C9x revision history to be certain. but it would seem to me that Kars de Jong added that FAS special case. Can you confirm that, Kars? Any recollection as to the reason? That is the value that's in the data manual of the Symbios Logic SYM53CF94/96-2 (the actual chip that's in my Amiga SCSI controller). Funny, according to the QLogic FAS2x6 manual the value should be 7682 for FAS216/216U/236/236U chips... I don't think it's all that important. It only means that the actual selection timeout used by the chip will be slightly shorter than it is supposed to be. Kind regards, Kars. -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: esp_scsi QTAG in FAS216
Hello Kars, I've never seen a formula for any ESP or FAS chip for the timeout other than the one mentioned in huge comment in esp_set_clock_params(), although I do see the 7668 instead of 8192 factor being used in the old NCR53C9x driver. I haven't gone far enough back in the 53C9x revision history to be certain. but it would seem to me that Kars de Jong added that FAS special case. Can you confirm that, Kars? Any recollection as to the reason? That is the value that's in the data manual of the Symbios Logic SYM53CF94/96-2 (the actual chip that's in my Amiga SCSI controller). Funny, according to the QLogic FAS2x6 manual the value should be 7682 for FAS216/216U/236/236U chips... I don't think it's all that important. It only means that the actual selection timeout used by the chip will be slightly shorter than it is supposed to be. Thanks for checking that - I agree that it might not amount to much. The more important issue is the one about the one-byte reconnect message. Does the manual speak to that particular issue? Any hint on how we could enable SCSI-2 features on chip init? Can you point me to a source for the manuals if possible? Cheers, Michael -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: esp_scsi QTAG in FAS216
Hello Dave, Tuomas, Also, looking at the timeout formulae in the old NCR53C9x.c driver, the values would be different for FAS216. Why was this dropped from the modern esp_scsi? I've never seen a formula for any ESP or FAS chip for the timeout other than the one mentioned in huge comment in esp_set_clock_params(), although I do see the 7668 instead of 8192 factor being used in the old NCR53C9x driver. I haven't gone far enough back in the 53C9x revision history to be certain. but it would seem to me that Kars de Jong added that FAS special case. Can you confirm that, Kars? Any recollection as to the reason? Cheers, Michael -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: esp_scsi QTAG in FAS216
From: Michael Schmitz schmitz...@gmail.com Date: Mon, 7 Apr 2014 08:33:12 +1200 Hello Dave, Tuomas, Also, looking at the timeout formulae in the old NCR53C9x.c driver, the values would be different for FAS216. Why was this dropped from the modern esp_scsi? I've never seen a formula for any ESP or FAS chip for the timeout other than the one mentioned in huge comment in esp_set_clock_params(), although I do see the 7668 instead of 8192 factor being used in the old NCR53C9x driver. I haven't gone far enough back in the 53C9x revision history to be certain. but it would seem to me that Kars de Jong added that FAS special case. Can you confirm that, Kars? Any recollection as to the reason? Just as another reference point, I looked at the FreeBSD 'esp' driver and it also uses the 8192 factor for all chips, including FAS216. -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: esp_scsi QTAG in FAS216
From: Tuomas Vainikka tuomas.vaini...@aalto.fi Date: Thu, 12 Sep 2013 18:36:09 +0300 Does anyone have the register descriptions for the FAS216 chip? It would seem that receiving only one byte during reconnect is perfectly normal [1] unless SCSI-2 features are explicitly enabled (which esp_scsi doesn't seem to be doing). This is quite possibly true. I've never see it happen myself while testing the driver though. Also, looking at the timeout formulae in the old NCR53C9x.c driver, the values would be different for FAS216. Why was this dropped from the modern esp_scsi? I've never seen a formula for any ESP or FAS chip for the timeout other than the one mentioned in huge comment in esp_set_clock_params(), although I do see the 7668 instead of 8192 factor being used in the old NCR53C9x driver. I wrote esp_scsi.c based upon the old sparc ESP driver and the docs I had available to me. -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
