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, > 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? 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; > - esp_write8(esp->config2, ESP_CFG2); > } > } > } -- To unsub
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 > 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
Hi Michael, [sorry for the long delay] On Mon, Apr 14, 2014 at 10:51 AM, Michael Schmitz 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
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 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; -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 sd 0:0:2:0: [sda] Unhandled error code sd 0:0:2:0: [
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 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; - 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 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 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; - 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 * plus modifications of the 53c7xx.c driver to support the Amiga. * * Rewritten to use 53c700.c by Kars de Jong */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include "esp_scsi.h" MODULE_AUTHOR("Michael Schmitz "); 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 = ZORRO_PROD_PHASE5_BLIZZARD_1220_CYBERSTORM, .driver_data = (unsigned long)&zorro_esp_driver_data[0], }, { .id = ZORRO_PROD_PHASE5_BLIZZARD_1230_II_FASTLANE_Z3_CYBERSCSI_CYBERSTORM060, .driver_data = (unsigned long)&zorro_esp_driver_data[0], }, { .id = ZORRO_PROD_PHASE5_CYBERSTORM_MK_II, .driver_da
Re: esp_scsi QTAG in FAS216
On 14.04.2014 05:14, David Miller wrote: From: Michael Schmitz 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 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; - 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
From: Michael Schmitz 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 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; - 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 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
Hi Michael, 2014-04-11 3:47 GMT+02:00 Michael Schmitz : > 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
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
2014-04-06 22:33 GMT+02:00 Michael Schmitz : > > 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
From: Michael Schmitz 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
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: Tuomas Vainikka 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
Re: esp_scsi QTAG in FAS216 (was Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver)
Tuomas, I might still have a copy of the manual somewhere from way back, if you haven't found it anywhere. Would be on an old disk or even hardcopy in storage, so please confirm you still need it. Cheers, Michael Am 13.09.2013 um 03:36 schrieb Tuomas Vainikka: On 09/11/2013 05:48 PM, Geert Uytterhoeven wrote: On Wed, Sep 11, 2013 at 12:12 PM, Michael Schmitz wrote: problem. Using PIO, only the first byte of the tag message comes through. It might not be esp_scsi's fault, but there seems to be an assumption that all devices support TCQ. Also, no SCSI-2 features seem to be enabled in the chip by esp_scsi. I'd have to check with DaveM, but such an assumption might in fact exist. BTW, it would be nice to start CCing linux-s...@vger.kernel.org and David S. Miller on future discussions. Gr{oetje,eeting}s, Geert Hello, 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). 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? 1. Page 2 in http://www.datasheetarchive.com/dl/Scans-030/ScansU9X12569.pdf -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
esp_scsi QTAG in FAS216 (was Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver)
On 09/11/2013 05:48 PM, Geert Uytterhoeven wrote: On Wed, Sep 11, 2013 at 12:12 PM, Michael Schmitz wrote: problem. Using PIO, only the first byte of the tag message comes through. It might not be esp_scsi's fault, but there seems to be an assumption that all devices support TCQ. Also, no SCSI-2 features seem to be enabled in the chip by esp_scsi. I'd have to check with DaveM, but such an assumption might in fact exist. BTW, it would be nice to start CCing linux-s...@vger.kernel.org and David S. Miller on future discussions. Gr{oetje,eeting}s, Geert Hello, 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). 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? 1. Page 2 in http://www.datasheetarchive.com/dl/Scans-030/ScansU9X12569.pdf -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