Skip to contentSkip to conversation

sun3x_esp: convert to esp_scsi

SCSI Kars de Jong 3 participants 3 messages Feb 10, 2008 – Feb 11, 2008 2 messages not in the archive SCSI

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): Pine.LNX.4.64.0802080932220.18242@anakin

#2 lore raw
Quoted 21 lines · Geert Uytterhoeven
Quoted 12 lines · Linux Kernel Mailing List
Gitweb:     http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0bb67f181834044db6e9b15c7d5cc3cce0489bfd
Commit:     0bb67f181834044db6e9b15c7d5cc3cce0489bfd
Parent:     f8d9d654fcc7dd87f5d0b222e233eaab15d650c4
Author:     Thomas Bogendoerfer <[email protected]>
AuthorDate: Fri Feb 1 00:13:34 2008 +0100
Committer:  James Bottomley <[email protected]>
CommitDate: Thu Feb 7 18:02:33 2008 -0600

[SCSI] sun3x_esp: convert to esp_scsi

Converted sun3x_esp driver to use esp_scsi.c

Quoted 7 lines
---
 drivers/scsi/Kconfig     |    1 +
 drivers/scsi/Makefile    |    2 +-
 drivers/scsi/sun3x_esp.c |  708 +++++++++++++++++++++-------------------------
 3 files changed, 318 insertions(+), 393 deletions(-)
Quoted 1 line

But the first one is back! Thank you, Thomas!

Thomas, can't you use ioreadxx() and friends instead of rolling your own memory mapped I/O handlers? readxx() and friends are only to be used on PCI-like buses.

Unfortunately, a simple conversion like this didn't work for me on the Blizzard SCSI IV. The driver gets stuck when probing devices:

esp: esp0, regs[80ea8000:80eb0000] irq[2]
esp: esp0 is a 53CF94/96-2, 40 MHz (ccf=0), SCSI ID 7
scsi0 : esp
ESP: tgt[0] lun[0] scsi_cmd [ 12 00 00 00 24 00 ]
ESP: start data addr[78e76590] len[36] write(1)
ESP: data done flgs[1] sent[36]
ESP: Command done status[0] message[0]
ESP: tgt[0] lun[0] scsi_cmd [ 12 00 00 00 86 00 ]
ESP: start data addr[78e76590] len[134] write(1)
ESP: data done flgs[1] sent[134]
ESP: Command done status[0] message[0]
scsi 0:0:0:0: Direct-Access QUANTUM FIREBALL_TM2110S 300N PQ: 0 ANSI: 2
target0:0:0: Beginning Domain Validation
ESP: tgt[0] lun[0] scsi_cmd [ 12 00 00 00 86 00 ]
ESP: Got msgin byte 4
ESP: Disconnecting tgt[0] tag[20:0]
ESP: reconnect tag, IRQ(0:10:97), <3>esp: esp0: Reconnect IRQ2 timeout
ESP: esp_schedule_reset() from 00127ad2
target0:0:0: Domain Validation Initial Inquiry Failed target0:0:0: Ending Domain Validation
ESP: tgt[1] lun[0] scsi_cmd [ 12 00 00 00 24 00 ]
ESP: tgt[2] lun[0] scsi_cmd [ 12 00 00 00 24 00 ]
ESP: Got msgin byte 7
ESP: Sending message [ 06 ]
...
ESP: Got msgin byte 7
ESP: Sending message [ 06 ]
...

The "Reconnect IRQ2 timeout" thing seemed wrong, so I modified it to never timeout there (perhaps the timer was a bit short on m68k). This causes it to get completely stuck, so the chip is apparently not in the mood to generate any interrupt ever. I wonder whether this is because a DMA operation is done with only 2 bytes...
The Blizzard DMA engine is rather simplistic (no byte counters). It's also undocumented.

The old driver used to use PIO for small transfers (like message in and SCSI commands). David, any ideas on this?

Kind regards,

Kars.

#3 lore raw
Quoted 2 lines · Kars de Jong

Thomas, can't you use ioreadxx() and friends instead of rolling your own memory mapped I/O handlers?

well, at least ioread32be/iowrite32be are looking promising, but a quick grep didn't show them for m68k.

Quoted 1 line

readxx() and friends are only to be used on PCI-like buses.

hmm, afaik readxx/writexx is not directly related to PCI. It's like ioread/iowrite to access iomapped address space. The difference to ioread/iowrite is that it doesn't support PCI IO space.

Thomas.

Signature · 2 lines
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                                [ RFC1925, 2.3 ]
maintainer
#4 lore raw
Quoted 6 lines · Thomas Bogendoerfer
Quoted 2 lines · Kars de Jong

Thomas, can't you use ioreadxx() and friends instead of rolling your own memory mapped I/O handlers?

well, at least ioread32be/iowrite32be are looking promising, but a quick grep didn't show them for m68k.

Someone could submit a patch ...

Quoted 5 lines
Quoted 1 line

readxx() and friends are only to be used on PCI-like buses.

hmm, afaik readxx/writexx is not directly related to PCI. It's like ioread/iowrite to access iomapped address space. The difference to ioread/iowrite is that it doesn't support PCI IO space.

That's correct ... at least that's the meaning we've ascribed on other architectures I've worked on. Any ioremap'd memory area can be accessed by readX/writeX. The current list of Buses I know it works on is MCA, EISA, GSC, Runway ... in addition to PCI.

James