Re: [PATCH v4] m68k/amiga - Amiga Zorro NCR53C9x boards: new zorro_esp.c

[Kars de Jong]

Hi Michael,

2018-03-17 2:16 GMT+01:00 Michael Schmitz <schmitz...@gmail.com>:
> From: Michael Schmitz <schm...@debian.org>
>
> New combined SCSI driver for all ESP based Zorro SCSI boards for
> m68k Amiga.
>
> Code largely based on board specific parts of the old drivers (blz1230.c,
> blz2060.c, cyberstorm.c, cyberstormII.c, fastlane.c which were removed
> after the 2.6 kernel series for lack of maintenance) with contributions
> by Tuomas Vainikka (TCQ bug tests and workaround) and Finn Thain (TCQ
> bugfix by use of PIO in extended message in transfer).
>
> New Kconfig option and Makefile entries for new Amiga Zorro ESP SCSI
> driver included in this patch.
>
> Use DMA transfers wherever possible, with board-specific DMA set-up
> functions copied from the old driver code. Three byte reselection messages
> do appear to cause DMA timeouts. So wire up a PIO transfer routine for
> these instead. esp_reselect_with_tag explicitly sets esp->cmd_block_dma as
> target address for the message bytes but PIO requires a virtual address.
> Substiute kernel virtual address esp->cmd_block in PIO transfer call if
> DMA address is esp->cmd_block_dma and phase is message in.
>
> PIO code taken from mac_esp.c where the reselection timeout issue was
> debugged and fixed first, with minor macro and function rename.
>
> Signed-off-by: Michael Schmitz <schmitz...@gmail.com>
> Reviewed-by: Finn Thain <fth...@telegraphics.com.au>
> ---
>
> Changes since v1:
>
> Fixed issues raised by Finn Thain in initial code review:
>
> - use KBUILD_MODNAME for driver name string.
> - use pr_fmt() for pr_* format prefix.
> - clean up DMA error reporting: clear error flag before each DMA
>   operation, set error flag on PIO error. Don't test phase in dma_err hook.
> - change confusing comment about semantics of read flag, add comments
>   indicating DMA direction to DMA setup hooks.
> - drop spurious braces around switch clauses.
> - lift cfreq setting out of ID switch clauses.
> - fix indentation.
> - fix error codes on probe fail.
> - drop check for board ID when unmapping DMA regs in error handling:
>   the ioaddr > 0xff test already catches all cases where the DMA
>   registers were ioremapped.
> - dynamically alloc zorro_private_data.
> - fix use of driver_data field (don't mix host and zorro_esp_priv
>   pointers). Note: require esp pointer in zorro_esp_priv to find host
>   pointer!
> - back out phase bits changes to pio_cmd !write branch introduced
>   to cope with ESP SELAS command. We don't use that code so keep
>   it in sync with Finn's version.
> - use esp_ops.dma_length_limit() to limit transfer size. After review
>   of old driver code, use 0xff max transfer size throughout.
>
> Fixed issues raised by Geert Uytterhoven:
>
> - dynamically alloc zorro_private_data, store as device drvdata.
> - store ctrl_data for CyberStormI in driver private data.
> - use dma_sync_single_for_device() instead of cache_push/clear.
> - handle case of duplicate board identity - check whether board is
>   Zorro III or Zorro II (use ROM resource data for this). Also fix
>   up DMA mask for Zorro II boards to 32 bits (these are really CPU
>   expansion slot boards).
> - remove zorro3 field from driver_data struct (now in private data).
> - add braces around ambiguous if - else construct.
> - use named structs instead of array for board config data.
> - use scsi_option driver data flag for boards with optional ESP.
>
> Other improvements and bugfixes
>
> - fix Zorro device table error (duplicate ID used, also raised
>   by Kars de Jong).
> - error code fixup in error handling path.
> - add separate DMA setup for Blizzard 1230 II board.
> - add support for Cyberstorm II board.
> - add register structs and DMA setup for Zorro III Fastlane board,
>   following logic from old fastlane.c driver. Wire up Fastlane DMA
>   and interrupt status routines, map the necessary low 24 bit board
>   address space used for DMA target address setting. Clean up DMA
>   register space ioremap() branch for Zorro III boards (currently
>   Fastlane only) to end confusion about what to do in error recovery.
> - use esp_ops.fastlane_esp_dma_invalidate() on Fastlane (and skip
>   fastlane_esp_reset_dma() in DMA setup).
> - credit Tuomas Vainikka for contributing Blizzard 1230 code (and
>   testing).
> - clarify comment about unsupported Oktagon SCSI board.
> - remove unused const definitions carried over from old driver.
>
> Changes since v2:
>
> - add SPDX-License-Identifier.
> - remove unused ratelimit.h.
> - drop phys_to_virt() in PIO transfer routine, after ensuring PIO is only
>   used for message in transfers to esp->command_block. This obvia

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

[Kars de Jong]

2018-03-04 0:54 GMT+01:00 Michael Schmitz :
> +static struct zorro_device_id zorro_esp_zorro_tbl[] = {
> +   {
> +   .id = ZORRO_PROD_PHASE5_BLIZZARD_1220_CYBERSTORM,
> +   .driver_data = (unsigned long)_esp_driver_data[0],
> +   },
> +   {
> +   .id = 
> ZORRO_PROD_PHASE5_BLIZZARD_1230_II_FASTLANE_Z3_CYBERSCSI_CYBERSTORM060,
> +   .driver_data = (unsigned long)_esp_driver_data[0],
> +   },
> +   {
> +   .id = ZORRO_PROD_PHASE5_CYBERSTORM_MK_II,
> +   .driver_data = (unsigned long)_esp_driver_data[1],
> +   },
> +   {
> +   .id = ZORRO_PROD_PHASE5_BLIZZARD_2060,
> +   .driver_data = (unsigned long)_esp_driver_data[2],
> +   },
> +   {
> +   .id = ZORRO_PROD_PHASE5_BLIZZARD_1230_IV_1260,
> +   .driver_data = (unsigned long)_esp_driver_data[3],
> +   },
> +   {
> +   .id = 
> ZORRO_PROD_PHASE5_BLIZZARD_1230_II_FASTLANE_Z3_CYBERSCSI_CYBERSTORM060,
> +   .driver_data = (unsigned long)_esp_driver_data[4],
> +   },
> +   { 0 }
> +};
> +MODULE_DEVICE_TABLE(zorro, zorro_esp_zorro_tbl);


The ID ZORRO_PROD_PHASE5_BLIZZARD_1230_II_FASTLANE_Z3_CYBERSCSI_CYBERSTORM060
is used at index 1 and index 5.
I'm guessing only the first one will be detected.

Regards,

Kars.

Re: esp_scsi QTAG in FAS216

[Kars de Jong]

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-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [SCSI] sun3x_esp: convert to esp_scsi

[Kars de Jong]

On vr, 2008-02-08 at 09:33 +0100, Geert Uytterhoeven wrote:
 On Fri, 8 Feb 2008, Linux Kernel Mailing List wrote:
  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
  
  Signed-off-by: Thomas Bogendoerfer [EMAIL PROTECTED]
  Signed-off-by: James Bottomley [EMAIL PROTECTED]
  ---
   drivers/scsi/Kconfig |1 +
   drivers/scsi/Makefile|2 +-
   drivers/scsi/sun3x_esp.c |  708 
  +-
   3 files changed, 318 insertions(+), 393 deletions(-)
 
 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:80eb] 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), 3esp: 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.


-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] Remove of old NCR53C9x/esp family of drivers

[Kars de Jong]

On do, 2008-01-03 at 20:05 +0100, Geert Uytterhoeven wrote:
 On Thu, 3 Jan 2008, James Bottomley wrote:
  On Thu, 2008-01-03 at 17:40 +0200, Boaz Harrosh wrote:
   As recommended by Christoph Hellwig. There is no use
of Fixing these drivers, since there is a much simpler
and modern esp infrastructure with David Miller's esp_scsi
   
 - Remove all driver files dependent on NCR53C9x.c
   deleted:drivers/scsi/NCR53C9x.c
   deleted:drivers/scsi/NCR53C9x.h
   deleted:drivers/scsi/blz1230.c
   deleted:drivers/scsi/blz2060.c
   deleted:drivers/scsi/cyberstorm.c
   deleted:drivers/scsi/cyberstormII.c
   deleted:drivers/scsi/dec_esp.c
   deleted:drivers/scsi/fastlane.c
   deleted:drivers/scsi/mac_esp.c
   deleted:drivers/scsi/mca_53c9x.c
   deleted:drivers/scsi/oktagon_esp.c
   deleted:drivers/scsi/oktagon_io.S
   deleted:drivers/scsi/sun3x_esp.c
   
 - Remove above list from drivers/scsi/Kconfig 
   drivers/scsi/Makefile
  
  OK, I'll split this into four pieces for scsi-pending, since there are
  three separate interest groups with signoffs to collect (MCA, m68k and
  alpha) plus the core removal.
 
 Anybody who can look into converting the m68k NCR53C9x drivers and has
 hardware to test (some of) them? I don't think we can afford losing one
 third of our SCSI drivers...

I'll have a look at this. I can only test it on Blizzard 1260 hardware
though.


Kind regards,

Kars.


-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] m68k: switch to 53c700 driver

[Kars de Jong]

On di, 2006-12-19 at 03:09 +, Al Viro wrote:
  m68k-generic-io.diff
 
 Hmm...  That breaks when you have ISA  !PCI (e.g. amiga or q40 defconfig):
 
 lib/built-in.o: In function `ioread32_rep':
 (.text+0xc31a): undefined reference to `insl'
 lib/built-in.o: In function `iowrite32_rep':
 (.text+0xc43e): undefined reference to `outsl'
 lib/built-in.o: In function `ioread32':
 (.text+0xc7da): undefined reference to `readl'
 lib/built-in.o: In function `iowrite32':
 (.text+0xca6a): undefined reference to `writel'

Thanks for spotting that. I'll update the patch.

Kars.


-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html