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
> +* trans
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 hence
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 wrote:
>> OK, in that case I'll need to wo
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 Fastlane/Blizzard1230II ID.
>
> Is the b
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
to
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. dev_set_drvdat
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 ...
I'v
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
problem?\n");
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
http://bitsavers.trailing-edge.com/components/ncr/scsi/53
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 fo
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
>>> +* to ctrl_reg. Always write a copy
>>> +
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 function get called twice
Hi Finn,
Am 06.03.2018 um 16:04 schrieb 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
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 __i
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 long dma_offset;
>> +
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 dr
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_
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
> @@ -0,0 +1,785 @@
> +static struct zorro_dri
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)&zorro_esp_driver_data[0],
> + },
> + {
> +
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
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 pa
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?
Hi Finn,
>> >> +#define ZORRO_ESP_GET_PRIV(esp) ((struct zorro_esp_priv *) \
>> >> + &zorro_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 ma
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 determ
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 of
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 (schm...@debian
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 patches be combined in
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 {
> > + ZORRO_ESP_PIO_LOOP("%0@+
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 based on board speci
From: Michael Schmitz
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)
30 matches
Mail list logo
