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

2018-03-09 Thread Michael Schmitz
Hi Finn, Geert, > + /* We are passed DMA addresses i.e. physical addresses, but must > use > +* kernel virtual addresses here, so remap to virtual. This is > easy > +* enough for the case of residual bytes of an extended message in > +*

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

2018-03-07 Thread Michael Schmitz
Tuomas, Am 06.03.2018 um 04:31 schrieb Tuomas Vainikka: >>> 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

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

2018-03-07 Thread Michael Schmitz
Hi Geert, fine, I'll rely on the base address and the z->rom.er_Type value to pick the correct config data. Cheers, Michael On Wed, Mar 7, 2018 at 9:06 PM, Geert Uytterhoeven wrote: > Hi Michael, > > On Wed, Mar 7, 2018 at 8:55 AM, Michael Schmitz

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

2018-03-07 Thread Geert Uytterhoeven
Hi Michael, On Wed, Mar 7, 2018 at 8:55 AM, Michael Schmitz wrote: > OK, in that case I'll need to work out something similar to the test for > optional SCSI function on the Blizzard 1230/1260 to find out what board > I have when dealing with the duplicate

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

2018-03-06 Thread Michael Schmitz
Hi Geert, OK, in that case I'll need to work out something similar to the test for optional SCSI function on the Blizzard 1230/1260 to find out what board I have when dealing with the duplicate Fastlane/Blizzard1230II ID. Is the board base address as returned by zorro_resource_start() reliable

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

2018-03-06 Thread Michael Schmitz
Hi Finn, Am 07.03.2018 um 13:54 schrieb Finn Thain: > On Wed, 7 Mar 2018, Michael Schmitz wrote: > >> The major obstacle now seems to be dynamic allocation of the driver >> private data and storing a pointer to that in a way that it can be >> retrieved using just the esp pointer.

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

2018-03-06 Thread Finn Thain
On Wed, 7 Mar 2018, Michael Schmitz wrote: > The major obstacle now seems to be dynamic allocation of the driver > private data and storing a pointer to that in a way that it can be > retrieved using just the esp pointer. dev_set_drvdata(esp->dev, zep) > causes the module load to crash ...

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

2018-03-06 Thread Michael Schmitz
Hi Geert, On Tue, Mar 6, 2018 at 8:48 PM, Geert Uytterhoeven wrote: > BTW, please call the probe/remove functions zorro_esp_probe() resp. > zorro_esp_remove(). Fair enough. + if (!host) { + pr_err(PFX "No host detected; board configuration

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

2018-03-06 Thread Michael Schmitz
Hi Finn, I'll leave the unused !write branch in the original condition. I'd rather keep the address conversion inside the PIO code than duplicating it in each DMA setup routine though. You had asked what manual I had used a while ago: it's

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

2018-03-06 Thread Finn Thain
On Tue, 6 Mar 2018, Michael Schmitz wrote: > The whole !write branch will never be executed, and I could just omit it > entirely for now, or leave it as it was in the Mac driver. > We could make use of the !write branch in zorro_esp, even if it was only to figure out the SELAS/MSG OUT issue

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

2018-03-05 Thread Geert Uytterhoeven
Hi Michael, On Tue, Mar 6, 2018 at 2:33 AM, Michael Schmitz wrote: > On Tue, Mar 6, 2018 at 12:29 AM, Geert Uytterhoeven > wrote: >>> +static unsigned char ctrl_data;/* Keep backup of the stuff written >>> +*

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

2018-03-05 Thread Geert Uytterhoeven
Hi Michael, On Tue, Mar 6, 2018 at 2:11 AM, Michael Schmitz wrote: > Index 1 should have been ZORRO_PROD_PHASE5_CYBERSTORM_MK_II, I've > corrected that in the meantime. > > Fastlane / Blizzard 1230_II distinction is something I an not quite > sure about - does the probe

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

2018-03-05 Thread Finn Thain
On Tue, 6 Mar 2018, Michael Schmitz wrote: > >> +static void zorro_esp_send_pio_cmd(struct esp *esp, u32 addr, u32 > >> esp_count, > >> +u32 dma_count, int write, u8 cmd) > >> +{ > >> + struct zorro_esp_priv *zep = ZORRO_ESP_GET_PRIV(esp); > >> + u8

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

2018-03-05 Thread Michael Schmitz
Hi Geert, thanks, will comment on a few points that were not already raised by Finn below. On Tue, Mar 6, 2018 at 12:29 AM, Geert Uytterhoeven wrote: >> +static struct zorro_driver_data { >> + const char *name; >> + unsigned long offset; >> + unsigned

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

2018-03-05 Thread Michael Schmitz
Hi Kars, Index 1 should have been ZORRO_PROD_PHASE5_CYBERSTORM_MK_II, I've corrected that in the meantime. Fastlane / Blizzard 1230_II distinction is something I an not quite sure about - does the probe function get called twice if the device table contains the same ID twice but with different

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

2018-03-05 Thread 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

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

2018-03-05 Thread Geert Uytterhoeven
Hi Michael, On Sun, Mar 4, 2018 at 12:54 AM, Michael Schmitz wrote: > From: Michael Schmitz > > New combined SCSI driver for all ESP based Zorro SCSI boards for > m68k Amiga. Thanks for your patch! > --- /dev/null > +++ b/drivers/scsi/zorro_esp.c > @@

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

2018-03-05 Thread 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], > + }, > + {

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

2018-03-04 Thread Finn Thain
On Mon, 5 Mar 2018, Michael Schmitz wrote: > All Zorro-3 boards have to have both their regs and dma_regs remapped. > I see. > 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

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

2018-03-04 Thread Finn Thain
On Mon, 5 Mar 2018, Michael Schmitz wrote: > > The TCQ issue showed up on the AV Quadras becasue mac_esp doesn't know > > how to do PDMA or DMA on that hardware, and so it always uses PIO. It > > sounds like this bug would show up too given the right kind of target. > > If so, I will need to

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

2018-03-04 Thread Michael Schmitz
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

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

2018-03-04 Thread Michael Schmitz
Hi Finn, >> >> +#define ZORRO_ESP_GET_PRIV(esp) ((struct zorro_esp_priv *) \ >> >> + _esp_private_data[(esp->host->host_no)]) >> >> + >> > >> > How do you know that host_no won't exceed the array bounds? >> > Why not use dev_{set,get}_drvdata(esp->dev)? -- much as mac_esp

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

2018-03-04 Thread Finn Thain
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

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

2018-03-04 Thread Michael Schmitz
Hi Finn, >> +/* zorro_esp.c: ESP front-end for Amiga ZORRO SCSI systems. >> + * >> + * Copyright (C) 1996 Jesper Skov (js...@cygnus.co.uk) >> + * >> + * Copyright (C) 2011,2018 Michael Schmitz (schm...@debian.org) for >> + * migration to ESP SCSI core > > You can blame me for some

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

2018-03-04 Thread Finn Thain
On Sun, 4 Mar 2018, Michael Schmitz wrote: > Am 04.03.2018 um 15:55 schrieb Finn Thain: > >> +/* zorro_esp.c: ESP front-end for Amiga ZORRO SCSI systems. > >> + * > >> + * Copyright (C) 1996 Jesper Skov (js...@cygnus.co.uk) > >> + * > >> + * Copyright (C) 2011,2018 Michael Schmitz

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

2018-03-04 Thread Michael Schmitz
Hi Finn, thanks for your review! Am 04.03.2018 um 15:55 schrieb Finn Thain: > On Sun, 4 Mar 2018, Michael Schmitz wrote: > >> From: Michael Schmitz >> >> New combined SCSI driver for all ESP based Zorro SCSI boards for >> m68k Amiga. >> > > Nice work! > > Shouldn't both

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

2018-03-03 Thread Finn Thain
On Sun, 4 Mar 2018, I wrote: > > + } else { > > + scsi_esp_cmd(esp, ESP_CMD_FLUSH); > > + > > + if (esp_count >= ZORRO_ESP_FIFO_SIZE) { > > + ZORRO_ESP_PIO_FILL("%0@+,%2@", esp_count); > > + } else { > > +

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

2018-03-03 Thread Finn Thain
On Sun, 4 Mar 2018, Michael Schmitz wrote: > From: Michael Schmitz > > New combined SCSI driver for all ESP based Zorro SCSI boards for > m68k Amiga. > Nice work! Shouldn't both patches be combined into one? The first patch can't be used without this one. > Code largely