Re: [PATCH 2/2] m68k/amiga - Zorro ESP: new zorro_esp.c

[Tuomas Vainikka]

On 05.03.2018 03:11, Michael Schmitz wrote:

Hi Finn,

On Mon, Mar 5, 2018 at 2:01 PM, Finn Thain  wrote:

On Mon, 5 Mar 2018, Michael Schmitz wrote:


+fail_unmap_dma_regs:
+ if (ioaddr > 0xff)
+ iounmap(esp->dma_regs);

I think you need to test for ZORRO_PROD_PHASE5_BLIZZARD_1230_IV_1260 here?

On second thought - no, I don't. the ID check above only determines what
Zorro-3 address is ioremapped, but in each case where ioaddr > 0xff,
something will have been mapped at this point.


I think you are talking about esp->regs? For esp->dma_regs, the ioremap is
conditional on ent->id, but the unmap is not.

The details of the ioremap are conditional on the ID, but the fact
that the ioremap happens (and hence esp->dma_regs is an ioremapped
address) is not. All Zorro-3 boards have to have both their regs and
dma_regs remapped.

What's confusing is that there is only a single Zorro-3 board
currently supported by the driver. Others will be added and I"ll use a
switch statement to pick the appropriate address based on the ID. That
might make it clearer.


Fastlane might be the only Z3 SCSI board that has the chip.

-Tuomas




+}
+
+static void zorro_esp_remove_one(struct zorro_dev *z)
+{
+ struct Scsi_Host *host = zorro_get_drvdata(z);
+ struct esp *esp = shost_priv(host);
+
+ scsi_esp_unregister(esp);
+
+ /* Disable interrupts. Perhaps use disable_irq instead ... */
+
+ free_irq(host->irq, esp);
+ dma_free_coherent(esp->dev, 16,
+   esp->command_block,
+   esp->command_block_dma);
+
+ if (host->base > 0xff) {
+ iounmap(esp->dma_regs);

Do you need to test for ZORRO_PROD_PHASE5_BLIZZARD_1230_IV_1260 first?

I can't - ent->id is not available here...

Maybe store ent->id in the private struct to get around that?

Yes, that could be done. I still think it's not needed.

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

[Tuomas Vainikka]

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

[Tuomas Vainikka]

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-scsi 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)

[Tuomas Vainikka]

On 09/11/2013 05:48 PM, Geert Uytterhoeven wrote:

On Wed, Sep 11, 2013 at 12:12 PM, Michael Schmitz schmitz...@gmail.com 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-scsi@vger.kernel.org and
David S. Miller da...@davemloft.net 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-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html