m68k v3.16 status update

m68k v3.16 status update

[Geert Uytterhoeven]

m68k v3.16 is out!
git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git

m68k-queue is getting smaller, but there are still a few commits left:

$ git cherry -v for-3.17 m68k-queue v3.16
- 7e87ff970f7116e46025f226b5aa47bd19e1229b zorro: Use ARRAY_SIZE
- 8e1bf8df8b6db30f2e78c029d488e5482b7d28d4 m68k/sun3: Remove define
statement no longer needed
+ 82560cb180860d93f5b83ac3e4048f53a1989b2d m68k/atari: EtherNAT -
ethernet support (smc91x)
+ 224ce049f71577d6ec380aeb94a4d25c3c4016a7 m68k/atari: EtherNEC -
ethernet support (ne)
+ db69080d04f14fbbd1021ac80916f8889beedab6 m68k/defconfig: Enable
Atari EtherNAT and EtherNEC Ethernet support
+ 87704cc39f16315f64c73afa19631a224322504c m68k/atari: USB - add
ISP1160 USB host controller support
+ 10b42d48867deea3c9b3ec0286e1377fe50ce616 m68k/defconfig: Enable
Atari EtherNAT and NetUSBee USB support
+ 88875720f0391465e2116defd7e050b31083734f fs/fat: Revert "msdos fs:
remove unsettable atari option"
+ 258a402647910eed4081cc23e62e4482467e1d68 fs/fat: Atari FAT updates
+ 84f65eef567df9a147073bcc240f8821af966cef fs/fat: Use correct logical
sector size for Atari GEMDOS FAT

The first two will be in v3.17.

The defconfig commits are blocked on functionality commits above them.

That leaves us with:
  - Atari EtherNAT: Should be fairly easy to get in. Is the current driver still
    working? If yes, I'm willing to send the patch to netdev myself.
  - Atari EtherNEC: idem ditto.
  - Atari ISP1160: I'm afraid this one needs a bit more care.
  - Atari FAT: No comments ;-)

May I remind you that patches touching areas outside arch/m68k must be
submitted to the appropriate maintainer (use scripts/get_maintainer.pl).

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: m68k v3.16 status update

[Ingo Jürgensmann]

Am 05.08.2014 um 21:40 schrieb Geert Uytterhoeven <geert@linux-m68k.org>:

> m68k v3.16 is out!
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git
> m68k-queue is getting smaller, but there are still a few commits left:

Hmm, what about the Blizzard 2060 SCSI driver from Michael & Tuomas? It runs since then on Akire... 

-- 
Ciao...          //        http://blog.windfluechter.net
      Ingo     \X/     XMPP: ij@jabber.windfluechter.net


gpg pubkey:  http://www.juergensmann.de/ij_public_key.asc

Re: m68k v3.16 status update

[John Paul Adrian Glaubitz]

On Tue, Aug 05, 2014 at 09:52:58PM +0200, Ingo Jürgensmann wrote:
> Am 05.08.2014 um 21:40 schrieb Geert Uytterhoeven <geert@linux-m68k.org>:
> 
> > m68k v3.16 is out!
> > git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git
> > m68k-queue is getting smaller, but there are still a few commits left:
> 
> Hmm, what about the Blizzard 2060 SCSI driver from Michael & Tuomas? It runs since then on Akire... 

Add to that the X-Surf100 driver that Michael Karcher wrote [1] but
unfortunately he hasn't cleaned up the code yet and submitted it for
inclusion in the mainline kernel.

I'll put Michael in the CC to try to ping him again :).

Cheers,
Adrian

> [1] git://z6.physik.fu-berlin.de/xsurf100.git

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: m68k v3.16 status update

[Geert Uytterhoeven]

On Tue, Aug 5, 2014 at 10:29 PM, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> On Tue, Aug 05, 2014 at 09:52:58PM +0200, Ingo Jürgensmann wrote:
>> Am 05.08.2014 um 21:40 schrieb Geert Uytterhoeven <geert@linux-m68k.org>:
>>
>> > m68k v3.16 is out!
>> > git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git
>> > m68k-queue is getting smaller, but there are still a few commits left:
>>
>> Hmm, what about the Blizzard 2060 SCSI driver from Michael & Tuomas? It runs since then on Akire...
>
> Add to that the X-Surf100 driver that Michael Karcher wrote [1] but
> unfortunately he hasn't cleaned up the code yet and submitted it for
> inclusion in the mainline kernel.

"May I remind you that patches touching areas outside arch/m68k must be
submitted to the appropriate maintainer (use scripts/get_maintainer.pl)."

The current policy is to not add drivers to the m68k repository if they should
go in through other maintainers.

The Atari ROM Port ISA-based EtherNEC, EtherNAT, and NetUSBee drivers
are there because the Atari ROM Port ISA support originated in the old
Linux/m68k CVS repository.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: m68k v3.16 status update

[John Paul Adrian Glaubitz]

On 08/06/2014 09:35 AM, Geert Uytterhoeven wrote:
>> Add to that the X-Surf100 driver that Michael Karcher wrote [1] but
>> unfortunately he hasn't cleaned up the code yet and submitted it for
>> inclusion in the mainline kernel.
> 
> "May I remind you that patches touching areas outside arch/m68k must be
> submitted to the appropriate maintainer (use scripts/get_maintainer.pl)."
> 
> The current policy is to not add drivers to the m68k repository if they should
> go in through other maintainers.

I know, I was not implying that, sorry :). I am just still waiting for
the xsurf100 driver to be included in the mainline kernel.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: m68k v3.16 status update

[Michael Schmitz]

Hi Geert,
> m68k v3.16 is out!
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git
>
> m68k-queue is getting smaller, but there are still a few commits left:
>
> $ git cherry -v for-3.17 m68k-queue v3.16
> - 7e87ff970f7116e46025f226b5aa47bd19e1229b zorro: Use ARRAY_SIZE
> - 8e1bf8df8b6db30f2e78c029d488e5482b7d28d4 m68k/sun3: Remove define
> statement no longer needed
> + 82560cb180860d93f5b83ac3e4048f53a1989b2d m68k/atari: EtherNAT -
> ethernet support (smc91x)
> + 224ce049f71577d6ec380aeb94a4d25c3c4016a7 m68k/atari: EtherNEC -
> ethernet support (ne)
> + db69080d04f14fbbd1021ac80916f8889beedab6 m68k/defconfig: Enable
> Atari EtherNAT and EtherNEC Ethernet support
> + 87704cc39f16315f64c73afa19631a224322504c m68k/atari: USB - add
> ISP1160 USB host controller support
> + 10b42d48867deea3c9b3ec0286e1377fe50ce616 m68k/defconfig: Enable
> Atari EtherNAT and NetUSBee USB support
> + 88875720f0391465e2116defd7e050b31083734f fs/fat: Revert "msdos fs:
> remove unsettable atari option"
> + 258a402647910eed4081cc23e62e4482467e1d68 fs/fat: Atari FAT updates
> + 84f65eef567df9a147073bcc240f8821af966cef fs/fat: Use correct logical
> sector size for Atari GEMDOS FAT
>
> The first two will be in v3.17.
>
> The defconfig commits are blocked on functionality commits above them.
>
> That leaves us with:
>   - Atari EtherNAT: Should be fairly easy to get in. Is the current driver still
>     working? If yes, I'm willing to send the patch to netdev myself.
>   

Last time I had a chance to try this on a non-broken EtherNAT, it was 
fine (two years ago IIRC). Need to ask Christian again to test the 
current one. There was one change you suggested after that time 
(dropping a dodgy cast was part of it) - that bit got never tested. It 
should work from what we discussed, but that's not a strong enough 
argument.

I'll leave it up to you to decide whether this is fit to submit.

>   - Atari EtherNEC: idem ditto.
>   

That one's fine. Paul had objections to the way I handled the shared 
interrupt and polling issue but that has been resolved a while ago.

Time for me to resubmit that one.

>   - Atari ISP1160: I'm afraid this one needs a bit more care.
>   

Agreed - it works but  there has to be a cleaner way to do this. I need 
to sit down and understand how it is that the current code works. (Last 
time I tried, the USB chip still worked on my EtherNAT so I can keep 
handling this.)

>   - Atari FAT: No comments ;-)
>   

I have a hard time remembering what these were about. Setting the 
'atari' option to either no or yes makes no difference, the mount works 
either way on my GEMDOS partition. The other two I suspect are needed 
(can be merged into one, anyway). I'll try to drop them and see where 
that leaves me.

I don't think I still have the test disk image I got from Petr to test 
these patches on. The patches were needed in 2009 so probably are still 
needed now. What were the objections from the FAT maintainers here?

> May I remind you that patches touching areas outside arch/m68k must be
> submitted to the appropriate maintainer (use scripts/get_maintainer.pl).
>   

There's still the Amiga Zorro ESP patch out in limbo - DaveM suggested a 
change to enable SCSI-2 features to help with extended message bytes but 
that did not work as intended. Haven't had time to follow that one up. 
Tuomas' fix to the driver to bypass DMA for message in works OK though - 
do you want it submitted back to linux-scsi as is, or wait for a perfect 
solution (pun on me ...)?

Support for more Amiga ESP cards needs to be added (got dropped in 
overlapping edits between Tuomas and me, better to make a clean break 
there). More testers needed at any rate.
Conclusion - I see good chances on the EtherNEC one, ditto on the 
EtherNAT if we can get it tested. Need to go back and check the FAT 
stuff but would suspect it is still needed - if no one but me needs this 
it could keep living in my local tree though.

Leaves USB to clean up, and SCSI stuff (which is what I have mostly been 
working on (Atari), if any).

Not much help, I know. I need a clone or two.

Cheers,

    Michael

> Thanks!
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   

Re: m68k v3.16 status update

[Michael Schmitz]

Hi Ingo,
> Am 05.08.2014 um 21:40 schrieb Geert Uytterhoeven <geert@linux-m68k.org>:
>
>   
>> m68k v3.16 is out!
>> git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git
>> m68k-queue is getting smaller, but there are still a few commits left:
>>     
>
> Hmm, what about the Blizzard 2060 SCSI driver from Michael & Tuomas? It runs since then on Akire... 
>   

So it still runs OK - good to know.

I understand Geert's reply to Adrian to please take this patch through 
the SCSI maintainer, not m68k. Fair enough. We'll leave it as 2060 only 
driver for now and add other boards later.

Cheers,

    Michael

Re: m68k v3.16 status update

[Christian T. Steigies]

On Fri, Aug 08, 2014 at 08:38:28PM +1200, Michael Schmitz wrote:
> Last time I had a chance to try this on a non-broken EtherNAT, it
> was fine (two years ago IIRC). Need to ask Christian again to test
> the current one.

Ask me again when the summer is over. Last I tried I had troubles to power
on the Falcon. Plus I had problems transfering the booting image from the
IDE-CF card to a real-harddisk so that I could actually use the Falcon
again. When it is getting cooler, I may want to sit in the attic again and
should find some time for playing with the Falcon (and the Blizzard2060).

Christian

Re: m68k v3.16 status update

[Tuomas Vainikka]

On 08.08.2014 11:58, Michael Schmitz wrote:
> Hi Ingo,
>> Am 05.08.2014 um 21:40 schrieb Geert Uytterhoeven 
>> <geert@linux-m68k.org>:
>>
>>> m68k v3.16 is out!
>>> git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git
>>> m68k-queue is getting smaller, but there are still a few commits left:
>>
>> Hmm, what about the Blizzard 2060 SCSI driver from Michael & Tuomas? 
>> It runs since then on Akire... 
>
> So it still runs OK - good to know.
>
> I understand Geert's reply to Adrian to please take this patch through 
> the SCSI maintainer, not m68k. Fair enough. We'll leave it as 2060 
> only driver for now and add other boards later.

I tested it on a Blizzard 1260 with the SCSI-expansion, so it actually 
supports two setups; [blz1230-IV, blz1240/60] + SCSI-kit, and blz2040/60.

-Tuomas

Re: m68k v3.16 status update

[Tuomas Vainikka]

On 08.08.2014 11:38, Michael Schmitz wrote:
>
> There's still the Amiga Zorro ESP patch out in limbo - DaveM suggested 
> a change to enable SCSI-2 features to help with extended message bytes 
> but that did not work as intended. Haven't had time to follow that one 
> up. Tuomas' fix to the driver to bypass DMA for message in works OK 
> though - do you want it submitted back to linux-scsi as is, or wait 
> for a perfect solution (pun on me ...)?
>
> Support for more Amiga ESP cards needs to be added (got dropped in 
> overlapping edits between Tuomas and me, better to make a clean break 
> there). More testers needed at any rate.
> Conclusion - I see good chances on the EtherNEC one, ditto on the 
> EtherNAT if we can get it tested. Need to go back and check the FAT 
> stuff but would suspect it is still needed - if no one but me needs 
> this it could keep living in my local tree though.
>
Just to refresh your memory, the final fix was not to bypass DMA at any 
level (I did that for the command transfer, but that didn't help), but 
to have a dedicated slave_configure() function in the Amiga Zorro ESP 
driver that would not enable TCQ.

-Tuomas

Re: m68k v3.16 status update

[Michael Schmitz]

Hi Tuomas,
>>
>> There's still the Amiga Zorro ESP patch out in limbo - DaveM 
>> suggested a change to enable SCSI-2 features to help with extended 
>> message bytes but that did not work as intended. Haven't had time to 
>> follow that one up. Tuomas' fix to the driver to bypass DMA for 
>> message in works OK though - do you want it submitted back to 
>> linux-scsi as is, or wait for a perfect solution (pun on me ...)?
>>
>>
> Just to refresh your memory, the final fix was not to bypass DMA at 
> any level (I did that for the command transfer, but that didn't help), 
> but to have a dedicated slave_configure() function in the Amiga Zorro 
> ESP driver that would not enable TCQ.

You guessed right about memory failing me - it wasn't about DMA in the 
end (for some reason, I seem to have DMA stuck in my mind at the 
moment), Do you see any other avenues to try and enable tagged commands 
in the ESP chip? We tried one config register only so far...

Cheers,

    Michael

Re: m68k v3.16 status update

[Michael Schmitz]

Hi Christian,

>> Last time I had a chance to try this on a non-broken EtherNAT, it
>> was fine (two years ago IIRC). Need to ask Christian again to test
>> the current one.
>>     
>
> Ask me again when the summer is over. Last I tried I had troubles to power
> on the Falcon. Plus I had problems transfering the booting image from the
> IDE-CF card to a real-harddisk so that I could actually use the Falcon
> again. When it is getting cooler, I may want to sit in the attic again and
> should find some time for playing with the Falcon (and the Blizzard2060).
>
>   
I'll do that - right now it's a bit cool in my basement so I try to 
avoid anything that needs access to the hardware reset button :-) Though 
a Raspberry Pi digital I/O board should be suitable to remote control 
even that :-)

I need to get a IDE-CF card pretty soon now, too. I'll send a detailed 
description on how to transfer the image over (probably using ARAnyM) 
when I've figured it out.

Enjoy your summer,

Cheers,

    Michael

Re: m68k v3.16 status update

[Michael Schmitz]

Hi Geert,
>>
>> That leaves us with:
>>   - Atari EtherNAT: Should be fairly easy to get in. Is the current 
>> driver still
>>     working? If yes, I'm willing to send the patch to netdev myself.
>>   
>
> Last time I had a chance to try this on a non-broken EtherNAT, it was 
> fine (two years ago IIRC). Need to ask Christian again to test the 
> current one. There was one change you suggested after that time 
> (dropping a dodgy cast was part of it) - that bit got never tested. It 
> should work from what we discussed, but that's not a strong enough 
> argument.

I should clarify - the current code does detect the SMC chip OK, it just 
doesn't receive any  MII interrupts on my card. I probably fried my MII 
interface. I am quite confident it will still work on a fully functional 
EtherNAT.

Cheers,

    Michael

Re: m68k v3.16 status update

[Tuomas Vainikka]

On 09.08.2014 01:25, Michael Schmitz wrote:
> Hi Tuomas,
>>>
>>> There's still the Amiga Zorro ESP patch out in limbo - DaveM 
>>> suggested a change to enable SCSI-2 features to help with extended 
>>> message bytes but that did not work as intended. Haven't had time to 
>>> follow that one up. Tuomas' fix to the driver to bypass DMA for 
>>> message in works OK though - do you want it submitted back to 
>>> linux-scsi as is, or wait for a perfect solution (pun on me ...)?
>>>
>>>
>> Just to refresh your memory, the final fix was not to bypass DMA at 
>> any level (I did that for the command transfer, but that didn't 
>> help), but to have a dedicated slave_configure() function in the 
>> Amiga Zorro ESP driver that would not enable TCQ.
>
> You guessed right about memory failing me - it wasn't about DMA in the 
> end (for some reason, I seem to have DMA stuck in my mind at the 
> moment), Do you see any other avenues to try and enable tagged 
> commands in the ESP chip? We tried one config register only so far...
>
I think I've tested almost all possible register settings for the chip, 
but it occurred to me that it is not enough to enable some chip features 
by flipping bits. The code in esp_scsi would need to be modified to 
handle the behaviour of these enabled features also.

So, rethinking the code in esp_scsi would be one option.

The second possibility is that I have a buggy chip in my setup. Removing 
a sticker from my SCSI-board revealed the chip to be an AMD AM53CF94.
There are different versions of the SCSI-boards out there with different 
chips; NCR, AMD, and QLogic, so if we had more people testing the driver 
we would find out if the chip is actually the problem. (Is anyone even 
testing the ISA/PCI cards that use esp_scsi?)

Those are my suggestions at the TCQ problem.

But do we really need TCQ?

-Tuomas

Re: m68k v3.16 status update

[Michael Schmitz]

Tuomas,
>>
>> You guessed right about memory failing me - it wasn't about DMA in 
>> the end (for some reason, I seem to have DMA stuck in my mind at the 
>> moment), Do you see any other avenues to try and enable tagged 
>> commands in the ESP chip? We tried one config register only so far...
>>
> I think I've tested almost all possible register settings for the 
> chip, but it occurred to me that it is not enough to enable some chip 
> features by flipping bits. The code in esp_scsi would need to be 
> modified to handle the behaviour of these enabled features also.
>
> So, rethinking the code in esp_scsi would be one option.

Other versions of ESP SCSI cards do appear to handle TCQ correctly with 
the default configuration of the chip, i.e. pass on the additional 
message bytes without any problem. From that I'd guess reading the tag 
message works OK in the current esp_scsi code. Other features (target 
mode) we are not really interested in, and without a second initiator on 
the bus, nothing should ever try to select our ESP host. What else is 
there to look out for?

> The second possibility is that I have a buggy chip in my setup. 
> Removing a sticker from my SCSI-board revealed the chip to be an AMD 
> AM53CF94.
> There are different versions of the SCSI-boards out there with 
> different chips; NCR, AMD, and QLogic, so if we had more people 
> testing the driver we would find out if the chip is actually the 
> problem. (Is anyone even testing the ISA/PCI cards that use esp_scsi?)

Some Macs/PowerMacs use esp_scsi IIRC - I suspect we would have heard if 
the driver was broken altogether.

> Those are my suggestions at the TCQ problem.
>
> But do we really need TCQ?

Maybe not - if no one's missed the feature in the original Amiga ESP 
drivers, we probably shouldn't worry.

Cheers,

    Michael

Re: m68k v3.16 status update

[Michael Schmitz]

Tuomas,

are you still in the position to test tagged queue messages on Zorro ESP
hardware?

I've modified the Zorro ESP driver based on the work Finn Thain did for
the Mac ESP driver (handling message in transfer by PIO, with special
handshaking provisions for the message in case) and tried to test this
on elgar (CyberStorm I ESP) but the original bug does not show up there.
Might be to do with the SCSI disk used, or the CyberStorm I board.

Might be better to test the new code on your hardware where we know the
bug happened in the first place.

Cheers,

	Michael

Am 09.08.2014 um 18:45 schrieb Tuomas Vainikka:
> On 09.08.2014 01:25, Michael Schmitz wrote:
>> Hi Tuomas,
>>>>
>>>> There's still the Amiga Zorro ESP patch out in limbo - DaveM
>>>> suggested a change to enable SCSI-2 features to help with extended
>>>> message bytes but that did not work as intended. Haven't had time to
>>>> follow that one up. Tuomas' fix to the driver to bypass DMA for
>>>> message in works OK though - do you want it submitted back to
>>>> linux-scsi as is, or wait for a perfect solution (pun on me ...)?
>>>>
>>>>
>>> Just to refresh your memory, the final fix was not to bypass DMA at
>>> any level (I did that for the command transfer, but that didn't
>>> help), but to have a dedicated slave_configure() function in the
>>> Amiga Zorro ESP driver that would not enable TCQ.
>>
>> You guessed right about memory failing me - it wasn't about DMA in the
>> end (for some reason, I seem to have DMA stuck in my mind at the
>> moment), Do you see any other avenues to try and enable tagged
>> commands in the ESP chip? We tried one config register only so far...
>>
> I think I've tested almost all possible register settings for the chip,
> but it occurred to me that it is not enough to enable some chip features
> by flipping bits. The code in esp_scsi would need to be modified to
> handle the behaviour of these enabled features also.
> 
> So, rethinking the code in esp_scsi would be one option.
> 
> The second possibility is that I have a buggy chip in my setup. Removing
> a sticker from my SCSI-board revealed the chip to be an AMD AM53CF94.
> There are different versions of the SCSI-boards out there with different
> chips; NCR, AMD, and QLogic, so if we had more people testing the driver
> we would find out if the chip is actually the problem. (Is anyone even
> testing the ISA/PCI cards that use esp_scsi?)
> 
> Those are my suggestions at the TCQ problem.
> 
> But do we really need TCQ?
> 
> -Tuomas

Re: m68k v3.16 status update

[Vainikka Tuomas]

Hello,

I do have the hardware, but unfortunately I do not have the time to test it.

-Tuomas
________________________________________
From: linux-m68k-owner@vger.kernel.org <linux-m68k-owner@vger.kernel.org> on behalf of Michael Schmitz <schmitzmic@gmail.com>
Sent: 14 December 2017 06:47
To: Tuomas Vainikka
Cc: Geert Uytterhoeven; linux-m68k
Subject: Re: m68k v3.16 status update

Tuomas,

are you still in the position to test tagged queue messages on Zorro ESP
hardware?

I've modified the Zorro ESP driver based on the work Finn Thain did for
the Mac ESP driver (handling message in transfer by PIO, with special
handshaking provisions for the message in case) and tried to test this
on elgar (CyberStorm I ESP) but the original bug does not show up there.
Might be to do with the SCSI disk used, or the CyberStorm I board.

Might be better to test the new code on your hardware where we know the
bug happened in the first place.

Cheers,

        Michael

Am 09.08.2014 um 18:45 schrieb Tuomas Vainikka:
> On 09.08.2014 01:25, Michael Schmitz wrote:
>> Hi Tuomas,
>>>>
>>>> There's still the Amiga Zorro ESP patch out in limbo - DaveM
>>>> suggested a change to enable SCSI-2 features to help with extended
>>>> message bytes but that did not work as intended. Haven't had time to
>>>> follow that one up. Tuomas' fix to the driver to bypass DMA for
>>>> message in works OK though - do you want it submitted back to
>>>> linux-scsi as is, or wait for a perfect solution (pun on me ...)?
>>>>
>>>>
>>> Just to refresh your memory, the final fix was not to bypass DMA at
>>> any level (I did that for the command transfer, but that didn't
>>> help), but to have a dedicated slave_configure() function in the
>>> Amiga Zorro ESP driver that would not enable TCQ.
>>
>> You guessed right about memory failing me - it wasn't about DMA in the
>> end (for some reason, I seem to have DMA stuck in my mind at the
>> moment), Do you see any other avenues to try and enable tagged
>> commands in the ESP chip? We tried one config register only so far...
>>
> I think I've tested almost all possible register settings for the chip,
> but it occurred to me that it is not enough to enable some chip features
> by flipping bits. The code in esp_scsi would need to be modified to
> handle the behaviour of these enabled features also.
>
> So, rethinking the code in esp_scsi would be one option.
>
> The second possibility is that I have a buggy chip in my setup. Removing
> a sticker from my SCSI-board revealed the chip to be an AMD AM53CF94.
> There are different versions of the SCSI-boards out there with different
> chips; NCR, AMD, and QLogic, so if we had more people testing the driver
> we would find out if the chip is actually the problem. (Is anyone even
> testing the ISA/PCI cards that use esp_scsi?)
>
> Those are my suggestions at the TCQ problem.
>
> But do we really need TCQ?
>
> -Tuomas

Re: m68k v3.16 status update

[John Paul Adrian Glaubitz]

Hi!

On 12/14/2017 01:07 PM, Vainikka Tuomas wrote:
> I do have the hardware, but unfortunately I do not have the time to test it.
I would suggest not waiting for this particular test then and rather get
the driver prepared for being upstreamed.

I will then ask the Amiga community from the German a1k.org forum to extensively
test the driver with Debian m68k. Most of the people there prefer just having
an installation CD they can just test instead of having to compile their own
kernel and so on.

Adrian

-- 
  .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: m68k v3.16 status update

[Michael Schmitz]

Hi Tuomas,

fair enough - I'll get the PIO code tested by forcing PIO transfers on
elgar, and submit the driver for review once that's done. Maybe
someone else has a chance to test the fix in the meantime.

Cheers,

  Michael


On Fri, Dec 15, 2017 at 1:07 AM, Vainikka Tuomas
<tuomas.vainikka@aalto.fi> wrote:
> Hello,
>
> I do have the hardware, but unfortunately I do not have the time to test it.
>
> -Tuomas
> ________________________________________
> From: linux-m68k-owner@vger.kernel.org <linux-m68k-owner@vger.kernel.org> on behalf of Michael Schmitz <schmitzmic@gmail.com>
> Sent: 14 December 2017 06:47
> To: Tuomas Vainikka
> Cc: Geert Uytterhoeven; linux-m68k
> Subject: Re: m68k v3.16 status update
>
> Tuomas,
>
> are you still in the position to test tagged queue messages on Zorro ESP
> hardware?
>
> I've modified the Zorro ESP driver based on the work Finn Thain did for
> the Mac ESP driver (handling message in transfer by PIO, with special
> handshaking provisions for the message in case) and tried to test this
> on elgar (CyberStorm I ESP) but the original bug does not show up there.
> Might be to do with the SCSI disk used, or the CyberStorm I board.
>
> Might be better to test the new code on your hardware where we know the
> bug happened in the first place.
>
> Cheers,
>
>         Michael
>
> Am 09.08.2014 um 18:45 schrieb Tuomas Vainikka:
>> On 09.08.2014 01:25, Michael Schmitz wrote:
>>> Hi Tuomas,
>>>>>
>>>>> There's still the Amiga Zorro ESP patch out in limbo - DaveM
>>>>> suggested a change to enable SCSI-2 features to help with extended
>>>>> message bytes but that did not work as intended. Haven't had time to
>>>>> follow that one up. Tuomas' fix to the driver to bypass DMA for
>>>>> message in works OK though - do you want it submitted back to
>>>>> linux-scsi as is, or wait for a perfect solution (pun on me ...)?
>>>>>
>>>>>
>>>> Just to refresh your memory, the final fix was not to bypass DMA at
>>>> any level (I did that for the command transfer, but that didn't
>>>> help), but to have a dedicated slave_configure() function in the
>>>> Amiga Zorro ESP driver that would not enable TCQ.
>>>
>>> You guessed right about memory failing me - it wasn't about DMA in the
>>> end (for some reason, I seem to have DMA stuck in my mind at the
>>> moment), Do you see any other avenues to try and enable tagged
>>> commands in the ESP chip? We tried one config register only so far...
>>>
>> I think I've tested almost all possible register settings for the chip,
>> but it occurred to me that it is not enough to enable some chip features
>> by flipping bits. The code in esp_scsi would need to be modified to
>> handle the behaviour of these enabled features also.
>>
>> So, rethinking the code in esp_scsi would be one option.
>>
>> The second possibility is that I have a buggy chip in my setup. Removing
>> a sticker from my SCSI-board revealed the chip to be an AMD AM53CF94.
>> There are different versions of the SCSI-boards out there with different
>> chips; NCR, AMD, and QLogic, so if we had more people testing the driver
>> we would find out if the chip is actually the problem. (Is anyone even
>> testing the ISA/PCI cards that use esp_scsi?)
>>
>> Those are my suggestions at the TCQ problem.
>>
>> But do we really need TCQ?
>>
>> -Tuomas
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: m68k v3.16 status update

[Finn Thain]

On Fri, 15 Dec 2017, Michael Schmitz wrote:

> Hi Tuomas,
> 
> fair enough - I'll get the PIO code tested by forcing PIO transfers on 
> elgar, and submit the driver for review once that's done.

You might need to instrument the esp_reconnect_with_tag() code path to 
confirm that elgar's scsi disks exercise the new code. I'd probably just 
set esp_scsi.esp_debug=0x200 (that is, ESP_DEBUG_RECONNECT). But watch out 
for /var/log/kern.log, in case it is on a scsi disk...

-- 

> Maybe someone else has a chance to test the fix in the meantime.
> 
> Cheers,
> 
>   Michael
> 
> 

Re: m68k v3.16 status update

[Vainikka Tuomas]

Hello,

Just bear in mind that there was no need for the PIO transfers when the TCQ was hacked off. Commands over DMA worked fine then at least on my Blizzard SCSI-IV...

-Tuomas

________________________________________
From: Michael Schmitz <schmitzmic@gmail.com>
Sent: 14 December 2017 20:40
To: Vainikka Tuomas
Cc: Geert Uytterhoeven; linux-m68k
Subject: Re: m68k v3.16 status update

Hi Tuomas,

fair enough - I'll get the PIO code tested by forcing PIO transfers on
elgar, and submit the driver for review once that's done. Maybe
someone else has a chance to test the fix in the meantime.

Cheers,

  Michael


On Fri, Dec 15, 2017 at 1:07 AM, Vainikka Tuomas
<tuomas.vainikka@aalto.fi> wrote:
> Hello,
>
> I do have the hardware, but unfortunately I do not have the time to test it.
>
> -Tuomas
> ________________________________________
> From: linux-m68k-owner@vger.kernel.org <linux-m68k-owner@vger.kernel.org> on behalf of Michael Schmitz <schmitzmic@gmail.com>
> Sent: 14 December 2017 06:47
> To: Tuomas Vainikka
> Cc: Geert Uytterhoeven; linux-m68k
> Subject: Re: m68k v3.16 status update
>
> Tuomas,
>
> are you still in the position to test tagged queue messages on Zorro ESP
> hardware?
>
> I've modified the Zorro ESP driver based on the work Finn Thain did for
> the Mac ESP driver (handling message in transfer by PIO, with special
> handshaking provisions for the message in case) and tried to test this
> on elgar (CyberStorm I ESP) but the original bug does not show up there.
> Might be to do with the SCSI disk used, or the CyberStorm I board.
>
> Might be better to test the new code on your hardware where we know the
> bug happened in the first place.
>
> Cheers,
>
>         Michael
>
> Am 09.08.2014 um 18:45 schrieb Tuomas Vainikka:
>> On 09.08.2014 01:25, Michael Schmitz wrote:
>>> Hi Tuomas,
>>>>>
>>>>> There's still the Amiga Zorro ESP patch out in limbo - DaveM
>>>>> suggested a change to enable SCSI-2 features to help with extended
>>>>> message bytes but that did not work as intended. Haven't had time to
>>>>> follow that one up. Tuomas' fix to the driver to bypass DMA for
>>>>> message in works OK though - do you want it submitted back to
>>>>> linux-scsi as is, or wait for a perfect solution (pun on me ...)?
>>>>>
>>>>>
>>>> Just to refresh your memory, the final fix was not to bypass DMA at
>>>> any level (I did that for the command transfer, but that didn't
>>>> help), but to have a dedicated slave_configure() function in the
>>>> Amiga Zorro ESP driver that would not enable TCQ.
>>>
>>> You guessed right about memory failing me - it wasn't about DMA in the
>>> end (for some reason, I seem to have DMA stuck in my mind at the
>>> moment), Do you see any other avenues to try and enable tagged
>>> commands in the ESP chip? We tried one config register only so far...
>>>
>> I think I've tested almost all possible register settings for the chip,
>> but it occurred to me that it is not enough to enable some chip features
>> by flipping bits. The code in esp_scsi would need to be modified to
>> handle the behaviour of these enabled features also.
>>
>> So, rethinking the code in esp_scsi would be one option.
>>
>> The second possibility is that I have a buggy chip in my setup. Removing
>> a sticker from my SCSI-board revealed the chip to be an AMD AM53CF94.
>> There are different versions of the SCSI-boards out there with different
>> chips; NCR, AMD, and QLogic, so if we had more people testing the driver
>> we would find out if the chip is actually the problem. (Is anyone even
>> testing the ISA/PCI cards that use esp_scsi?)
>>
>> Those are my suggestions at the TCQ problem.
>>
>> But do we really need TCQ?
>>
>> -Tuomas
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

TCQ with zorro_esp, was Re: m68k v3.16 status update

[Finn Thain]

On Fri, 15 Dec 2017, Vainikka Tuomas wrote:

> Hello,
> 
> Just bear in mind that there was no need for the PIO transfers when the 
> TCQ was hacked off. Commands over DMA worked fine then at least on my 
> Blizzard SCSI-IV...

Inhibiting TCQ also affects performance.

If you want to, you can measure the difference (compared to Michael's 
patch) by using a patch like the one below, with the option 
esp_scsi.esp_no_tcq=1.

The use of PIO for short transfers should cost nothing in the absence of 
TCQ because there should be no short tranfers.

-- 

> 
> -Tuomas
> 

diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index c3fc34b9964d..69c3de96b79c 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -37,6 +37,8 @@
 /* SCSI bus reset settle time in seconds.  */
 static int esp_bus_reset_settle = 3;
 
+static int esp_no_tcq = -1;
+
 static u32 esp_debug;
 #define ESP_DEBUG_INTR		0x00000001
 #define ESP_DEBUG_SCSICMD	0x00000002
@@ -698,7 +700,7 @@ static struct esp_cmd_entry *find_and_prep_issuable_command(struct esp *esp)
 			return ent;
 		}
 
-		if (!spi_populate_tag_msg(&ent->tag[0], cmd)) {
+		if (esp_no_tcq > 0 || !spi_populate_tag_msg(&ent->tag[0], cmd)) {
 			ent->tag[0] = 0;
 			ent->tag[1] = 0;
 		}
@@ -2476,7 +2478,7 @@ static int esp_slave_configure(struct scsi_device *dev)
 	struct esp *esp = shost_priv(dev->host);
 	struct esp_target_data *tp = &esp->target[dev->id];
 
-	if (dev->tagged_supported)
+	if (esp_no_tcq <= 0 && dev->tagged_supported)
 		scsi_change_queue_depth(dev, esp->num_tags);
 
 	tp->flags |= ESP_TGT_DISCONNECT;
@@ -2768,6 +2770,9 @@ MODULE_AUTHOR("David S. Miller (davem@davemloft.net)");
 MODULE_LICENSE("GPL");
 MODULE_VERSION(DRV_VERSION);
 
+module_param(esp_no_tcq, int, 0);
+MODULE_PARM_DESC(esp_no_tcq, "Send no command tags");
+
 module_param(esp_bus_reset_settle, int, 0);
 MODULE_PARM_DESC(esp_bus_reset_settle,
 		 "ESP scsi bus reset delay in seconds");

Re: m68k v3.16 status update

[Michael Schmitz]

Hi Finn,

thanks, doing that now. The log is on IDE so no danger there. My debug
code along with esp_debug = ESP_DEBUG_RECONNECT shows the code path is
exercised by the single disk attached to elgar.

Contrary to the Mac driver, esp->command_block and
esp->command_block_dma are not identical addresses on Amiga. Is there
a generic way to map a DMA address (i.e., physical address AFAIK) to a
kernel virtual one? (I can use esp->command_block in the reconnect
message special case but not otherwise ...)

Cheers,

  Michael


On Fri, Dec 15, 2017 at 12:49 PM, Finn Thain <fthain@telegraphics.com.au> wrote:
> On Fri, 15 Dec 2017, Michael Schmitz wrote:
>
>> Hi Tuomas,
>>
>> fair enough - I'll get the PIO code tested by forcing PIO transfers on
>> elgar, and submit the driver for review once that's done.
>
> You might need to instrument the esp_reconnect_with_tag() code path to
> confirm that elgar's scsi disks exercise the new code. I'd probably just
> set esp_scsi.esp_debug=0x200 (that is, ESP_DEBUG_RECONNECT). But watch out
> for /var/log/kern.log, in case it is on a scsi disk...
>
> --
>
>> Maybe someone else has a chance to test the fix in the meantime.
>>
>> Cheers,
>>
>>   Michael
>>
>>

Re: m68k v3.16 status update

[Michael Schmitz]

Hi Tuomas,

sending commands to the disk over DMA does work fine indeed. It's
receiving extended message bytes that does require additional
handshake which is not present in your zorro_esp_pio_cmd() function
that you probably used for testing.

I will add these handshake bits into your PIO function if I can't make
Finn's more generic work in the general case (i.e. for boards where we
haven't got th DMA interface sorted out yet).

Cheers,

  Michael


On Fri, Dec 15, 2017 at 9:34 PM, Vainikka Tuomas
<tuomas.vainikka@aalto.fi> wrote:
> Hello,
>
> Just bear in mind that there was no need for the PIO transfers when the TCQ was hacked off. Commands over DMA worked fine then at least on my Blizzard SCSI-IV...
>
> -Tuomas
>
> ________________________________________
> From: Michael Schmitz <schmitzmic@gmail.com>
> Sent: 14 December 2017 20:40
> To: Vainikka Tuomas
> Cc: Geert Uytterhoeven; linux-m68k
> Subject: Re: m68k v3.16 status update
>
> Hi Tuomas,
>
> fair enough - I'll get the PIO code tested by forcing PIO transfers on
> elgar, and submit the driver for review once that's done. Maybe
> someone else has a chance to test the fix in the meantime.
>
> Cheers,
>
>   Michael
>
>
> On Fri, Dec 15, 2017 at 1:07 AM, Vainikka Tuomas
> <tuomas.vainikka@aalto.fi> wrote:
>> Hello,
>>
>> I do have the hardware, but unfortunately I do not have the time to test it.
>>
>> -Tuomas
>> ________________________________________
>> From: linux-m68k-owner@vger.kernel.org <linux-m68k-owner@vger.kernel.org> on behalf of Michael Schmitz <schmitzmic@gmail.com>
>> Sent: 14 December 2017 06:47
>> To: Tuomas Vainikka
>> Cc: Geert Uytterhoeven; linux-m68k
>> Subject: Re: m68k v3.16 status update
>>
>> Tuomas,
>>
>> are you still in the position to test tagged queue messages on Zorro ESP
>> hardware?
>>
>> I've modified the Zorro ESP driver based on the work Finn Thain did for
>> the Mac ESP driver (handling message in transfer by PIO, with special
>> handshaking provisions for the message in case) and tried to test this
>> on elgar (CyberStorm I ESP) but the original bug does not show up there.
>> Might be to do with the SCSI disk used, or the CyberStorm I board.
>>
>> Might be better to test the new code on your hardware where we know the
>> bug happened in the first place.
>>
>> Cheers,
>>
>>         Michael
>>
>> Am 09.08.2014 um 18:45 schrieb Tuomas Vainikka:
>>> On 09.08.2014 01:25, Michael Schmitz wrote:
>>>> Hi Tuomas,
>>>>>>
>>>>>> There's still the Amiga Zorro ESP patch out in limbo - DaveM
>>>>>> suggested a change to enable SCSI-2 features to help with extended
>>>>>> message bytes but that did not work as intended. Haven't had time to
>>>>>> follow that one up. Tuomas' fix to the driver to bypass DMA for
>>>>>> message in works OK though - do you want it submitted back to
>>>>>> linux-scsi as is, or wait for a perfect solution (pun on me ...)?
>>>>>>
>>>>>>
>>>>> Just to refresh your memory, the final fix was not to bypass DMA at
>>>>> any level (I did that for the command transfer, but that didn't
>>>>> help), but to have a dedicated slave_configure() function in the
>>>>> Amiga Zorro ESP driver that would not enable TCQ.
>>>>
>>>> You guessed right about memory failing me - it wasn't about DMA in the
>>>> end (for some reason, I seem to have DMA stuck in my mind at the
>>>> moment), Do you see any other avenues to try and enable tagged
>>>> commands in the ESP chip? We tried one config register only so far...
>>>>
>>> I think I've tested almost all possible register settings for the chip,
>>> but it occurred to me that it is not enough to enable some chip features
>>> by flipping bits. The code in esp_scsi would need to be modified to
>>> handle the behaviour of these enabled features also.
>>>
>>> So, rethinking the code in esp_scsi would be one option.
>>>
>>> The second possibility is that I have a buggy chip in my setup. Removing
>>> a sticker from my SCSI-board revealed the chip to be an AMD AM53CF94.
>>> There are different versions of the SCSI-boards out there with different
>>> chips; NCR, AMD, and QLogic, so if we had more people testing the driver
>>> we would find out if the chip is actually the problem. (Is anyone even
>>> testing the ISA/PCI cards that use esp_scsi?)
>>>
>>> Those are my suggestions at the TCQ problem.
>>>
>>> But do we really need TCQ?
>>>
>>> -Tuomas
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: m68k v3.16 status update

[Finn Thain]

On Tue, 19 Dec 2017, Michael Schmitz wrote:

> Contrary to the Mac driver, esp->command_block and 
> esp->command_block_dma are not identical addresses on Amiga.

Why not make them identical, depending on the length of the tranfer? (Then 
choose PIO or DMA by testing for the same threshold.)

> Is there a generic way to map a DMA address (i.e., physical address 
> AFAIK) to a kernel virtual one?
> 

I don't know of a good way to do that.

> (I can use esp->command_block in the reconnect message special case but 
> not otherwise ...)

Maybe something like this...

	struct esp_cmd_entry *ent = esp->active_cmd;
	struct esp_cmd_priv *spriv = ESP_CMD_PRIV(ent->cmd);
	struct scatterlist *sg = spriv->cur_sg;
	unsigned long addr = sg_page(sg) + sg->offset;

but that doesn't work for the esp_autosense() case, which doesn't involve 
esp->ops->map_sg...

HTH

-- 

> Cheers,
> 
>   Michael

Re: m68k v3.16 status update

[Michael Schmitz]

Hi Finn,

Am 19.12.2017 um 16:35 schrieb Finn Thain:
> On Tue, 19 Dec 2017, Michael Schmitz wrote:
> 
>> Contrary to the Mac driver, esp->command_block and 
>> esp->command_block_dma are not identical addresses on Amiga.
> 
> Why not make them identical, depending on the length of the tranfer? (Then 
> choose PIO or DMA by testing for the same threshold.)

esp->command_block_dma is mapped at driver init time so we don't get to
chose at command submission time. I suspect it's due to a different
memory layout on Amiga (no 1:1 correspondence of physical and kernel
virtual addresses). But Geert ought to be able to answer that.

>> Is there a generic way to map a DMA address (i.e., physical address 
>> AFAIK) to a kernel virtual one?
>>
> 
> I don't know of a good way to do that.
> 
>> (I can use esp->command_block in the reconnect message special case but 
>> not otherwise ...)
> 
> Maybe something like this...
> 
> 	struct esp_cmd_entry *ent = esp->active_cmd;
> 	struct esp_cmd_priv *spriv = ESP_CMD_PRIV(ent->cmd);
> 	struct scatterlist *sg = spriv->cur_sg;
> 	unsigned long addr = sg_page(sg) + sg->offset;
> 
> but that doesn't work for the esp_autosense() case, which doesn't involve 
> esp->ops->map_sg...
> 
> HTH

I'll give that a try to see if this works for regular transfers. Will
look at ways to identify autosense as well (do sense data fit into the
ESP FIFO usually?)

Cheers,

	Michael

Re: m68k v3.16 status update

[Geert Uytterhoeven]

Hi Michael,

On Tue, Dec 19, 2017 at 1:40 AM, Michael Schmitz <schmitzmic@gmail.com> wrote:
> Contrary to the Mac driver, esp->command_block and
> esp->command_block_dma are not identical addresses on Amiga. Is there
> a generic way to map a DMA address (i.e., physical address AFAIK) to a
> kernel virtual one? (I can use esp->command_block in the reconnect
> message special case but not otherwise ...)

The only generic way is to use the virtual and DMA addresses as returned
by the dma_map_*() functions.

There may be some platform-specific legacy conversion routines around...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

zorro_esp, was Re: m68k v3.16 status update

[Finn Thain]

On Tue, 19 Dec 2017, Michael Schmitz wrote:

> > 
> > > Contrary to the Mac driver, esp->command_block and 
> > > esp->command_block_dma are not identical addresses on Amiga.
> > 
> > Why not make them identical, depending on the length of the tranfer? 
> > (Then choose PIO or DMA by testing for the same threshold.)
> 
> esp->command_block_dma is mapped at driver init time so we don't get to 
> chose at command submission time.

You could set esp->command_block_dma to an address like 0xffffffff. Then 
when zorro_esp's ops->send_dma_cmd method is to do a DMA to or from that 
address, check the transfer length. If the length is small, use 
esp->command_block as the address for a PIO transfer. Otherwise, use the 
mapped esp->command_block (which you saved somewhere at driver init time) 
for a DMA transfer.

This is a hack, of course. Perhaps we can avoid the hack if we pass the 
virtual address as an argument to ops->send_dma_cmd.

(Or *sg could be passed, if we cook up a couple of scattergather structs 
to replace ent->sense_ptr and esp->command_block. This might allow for the 
elimination of ops->map_single and ops->unmap_single altogether...)

> > 
> > > (I can use esp->command_block in the reconnect message special case 
> > > but not otherwise ...)
> > 
> > Maybe something like this...
> > 
> > 	struct esp_cmd_entry *ent = esp->active_cmd;
> > 	struct esp_cmd_priv *spriv = ESP_CMD_PRIV(ent->cmd);
> > 	struct scatterlist *sg = spriv->cur_sg;
> > 	unsigned long addr = sg_page(sg) + sg->offset;
> > 
> > but that doesn't work for the esp_autosense() case, which doesn't 
> > involve esp->ops->map_sg...
> > 
> > HTH
> 
> I'll give that a try to see if this works for regular transfers.
> 
> Will look at ways to identify autosense as well (do sense data fit into 
> the ESP FIFO usually?)

You can identify the autosense case easily enough,

	struct esp_cmd_entry *ent = esp->active_cmd;
	struct esp_cmd_priv *spriv = ESP_CMD_PRIV(ent->cmd);
	unsigned long addr;

	if (ent->flags & ESP_CMD_FLAG_AUTOSENSE)
		addr = spriv->sense_ptr;
	else {
		struct scatterlist *sg = spriv->cur_sg;

		addr = sg_page(sg) + sg->offset;
	}

But that still leaves the command_block case unhandled (I don't think we 
can use spriv->cur_sg for that, so we'd need a hack like the one above). 

All this complexity doesn't really belong in the ops->send_dma_cmd method, 
so I think we are back to passing in the virtual pointer as a parameter. 

That change would touch every esp driver. But it could improve mac_esp, 
since mac_esp would no longer have to do any fake dma mapping. Maybe I 
should do a patch for this?

-- 

> 
> Cheers,
> 
> 	Michael
> 
> 

Re: m68k v3.16 status update

[Finn Thain]

On Tue, 19 Dec 2017, Michael Schmitz wrote:

> 
> esp->command_block_dma is mapped at driver init time so we don't get to 
> chose at command submission time.

When the command is submitted, ops->send_dma_cmd() can do something like 
this,

static void zorro_esp_send_dma_cmd(struct esp *esp, u32 dma_addr, u32 esp_count,
                                   u32 dma_count, int write, u8 cmd);
{
	if ((dma_addr_t)dma_addr == esp->command_block_dma && esp_count < 4) {
		zorro_esp_send_pio_cmd(esp, (u32)esp->command_block, esp_count,
		                       dma_count, write, cmd);
		return;
	}

	/* do the usual DMA... */
}

This logic completely ignores data transfers (including sense transfers) 
but it is simple and self-contained and should get the job done.

>From what you said, I think you already arrived at this code (or something 
equivalent). Is there a problem? Do we have to do PIO data transfers too?

-- 

Re: m68k v3.16 status update

[Michael Schmitz]

Hi Finn,

On Wed, Dec 20, 2017 at 12:01 PM, Finn Thain <fthain@telegraphics.com.au> wrote:
> On Tue, 19 Dec 2017, Michael Schmitz wrote:
>
>>
>> esp->command_block_dma is mapped at driver init time so we don't get to
>> chose at command submission time.
>
> When the command is submitted, ops->send_dma_cmd() can do something like
> this,
>
> static void zorro_esp_send_dma_cmd(struct esp *esp, u32 dma_addr, u32 esp_count,
>                                    u32 dma_count, int write, u8 cmd);
> {
>         if ((dma_addr_t)dma_addr == esp->command_block_dma && esp_count < 4) {
>                 zorro_esp_send_pio_cmd(esp, (u32)esp->command_block, esp_count,
>                                        dma_count, write, cmd);
>                 return;
>         }
>
>         /* do the usual DMA... */
> }
>
> This logic completely ignores data transfers (including sense transfers)
> but it is simple and self-contained and should get the job done.

That's one way to do this, yes.

> From what you said, I think you already arrived at this code (or something
> equivalent). Is there a problem? Do we have to do PIO data transfers too?

I test for phase == ESP_MIP and direct to the PIO routine, and use the
following code to fix up the transfer address there:

+       /* extended message in transfer? need to fixup addr */
+       if (cmd == ESP_CMD_TI && addr == esp->command_block_dma)
+               addr = (u32) esp->command_block;
+

Note that addr = phys_to_virt((u32) esp->command_block_dma) works just
the same (even though phys_to_virt((u32) esp->command_block_dma) !=
esp->command_block).

We don't have to do PIO data transfers - would have been useful to
debug DMA issues on 'new' boards but not essential.

Your solution is simpler and more generic so I'll try that one and
will probably use it.

Cheers,

  Michael


>
> --

Re: m68k v3.16 status update

[Finn Thain]

On Wed, 20 Dec 2017, Michael Schmitz wrote:

> 
> I test for phase == ESP_MIP and direct to the PIO routine,

I'm more pessimistic and expect short DMA transfers to fail in any phase 
(though in practice that may never happen).

> and use the following code to fix up the transfer address there:
> 
> +       /* extended message in transfer? need to fixup addr */
> +       if (cmd == ESP_CMD_TI && addr == esp->command_block_dma)
> +               addr = (u32) esp->command_block;
> +
> 
> Note that addr = phys_to_virt((u32) esp->command_block_dma) works just
> the same (even though phys_to_virt((u32) esp->command_block_dma) !=
> esp->command_block).
> 
> We don't have to do PIO data transfers - would have been useful to
> debug DMA issues on 'new' boards but not essential.
> 

Yes. I think it would be good to add a comment to say that the problem was 
only observed for 2-byte MESSAGE IN transfers (so far), and also that in 
general short transfers will not be caught this way because they may 
involve cmd->sense_buffer or scsi_sglist(cmd) and not esp->command_block.

> Your solution is simpler and more generic so I'll try that one and will 
> probably use it.
> 

Like you, I'd also prefer a complete solution but it can wait until the 
need arises.

-- 

> Cheers,
> 
>   Michael
> 

zorro_esp, was: Re: m68k v3.16 status update

[Michael Schmitz]

Hi Geert,

Am 19.12.2017 um 21:19 schrieb Geert Uytterhoeven:
> Hi Michael,
> 
> On Tue, Dec 19, 2017 at 1:40 AM, Michael Schmitz <schmitzmic@gmail.com> wrote:
>> Contrary to the Mac driver, esp->command_block and
>> esp->command_block_dma are not identical addresses on Amiga. Is there
>> a generic way to map a DMA address (i.e., physical address AFAIK) to a
>> kernel virtual one? (I can use esp->command_block in the reconnect
>> message special case but not otherwise ...)
> 
> The only generic way is to use the virtual and DMA addresses as returned
> by the dma_map_*() functions.

Yes, but there is no way to find the mapped virtual address given the
DMA handle (=physical address). I suppose that would mean walking the
page tables, looking for a mapping that bears the hallmarks of a DMA
mapping?

> There may be some platform-specific legacy conversion routines around...

phys_to_virt() does return _a_ mapping but it is not the DMA virtual
mapping itself. Since we are doing PIO, the cache bits in the mapping
may not matter at all here so this may be safe in general. It's a hack I
would not want to submit for review though.

Anyway - both using esp->command_block and the address returned by
phys_to_virt() work, that's good enough for now. At least we can get rid
of the slave_configure hack ...

(Tested on CyberStorm I only so far, of course, And only handles message
in, not other short transfers ...).

Cheers,

	Michael

> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds
> 

Re: zorro_esp, was: Re: m68k v3.16 status update

[Geert Uytterhoeven]

Hi Michael,

On Wed, Dec 20, 2017 at 8:33 AM, Michael Schmitz <schmitzmic@gmail.com> wrote:
> Am 19.12.2017 um 21:19 schrieb Geert Uytterhoeven:
>> On Tue, Dec 19, 2017 at 1:40 AM, Michael Schmitz <schmitzmic@gmail.com> wrote:
>>> Contrary to the Mac driver, esp->command_block and
>>> esp->command_block_dma are not identical addresses on Amiga. Is there
>>> a generic way to map a DMA address (i.e., physical address AFAIK) to a
>>> kernel virtual one? (I can use esp->command_block in the reconnect
>>> message special case but not otherwise ...)
>>
>> The only generic way is to use the virtual and DMA addresses as returned
>> by the dma_map_*() functions.
>
> Yes, but there is no way to find the mapped virtual address given the
> DMA handle (=physical address). I suppose that would mean walking the
> page tables, looking for a mapping that bears the hallmarks of a DMA
> mapping?

Right. Not taking into account that some regions (e.g. Zorro II) may be mapped
using a fixed large mapping.

That'w why you should keep the DMA address returned by dma_map_*().

>> There may be some platform-specific legacy conversion routines around...
>
> phys_to_virt() does return _a_ mapping but it is not the DMA virtual
> mapping itself. Since we are doing PIO, the cache bits in the mapping
> may not matter at all here so this may be safe in general. It's a hack I
> would not want to submit for review though.

That's meant for RAM mapped by the kernel.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: m68k v3.16 status update

[Michael Schmitz]

Hi Finn,

Am 20.12.2017 um 12:01 schrieb Finn Thain:
> On Tue, 19 Dec 2017, Michael Schmitz wrote:
> 
>>
>> esp->command_block_dma is mapped at driver init time so we don't get to 
>> chose at command submission time.
> 
> When the command is submitted, ops->send_dma_cmd() can do something like 
> this,
> 
> static void zorro_esp_send_dma_cmd(struct esp *esp, u32 dma_addr, u32 esp_count,
>                                    u32 dma_count, int write, u8 cmd);
> {
> 	if ((dma_addr_t)dma_addr == esp->command_block_dma && esp_count < 4) {
> 		zorro_esp_send_pio_cmd(esp, (u32)esp->command_block, esp_count,
> 		                       dma_count, write, cmd);
> 		return;
> 	}
> 
> 	/* do the usual DMA... */
> }
> 
> This logic completely ignores data transfers (including sense transfers) 
> but it is simple and self-contained and should get the job done.

Oddly enough, this does not quite work. Due to my settings in the
adapter probe function (I don't set the ESP_FLAG_DISABLE_SYNC flag), the
ESP core uses 'select with attention and stop' instead of the normal
select with attention command, which attempts to send just a single byte
IDENTIFY message, and defers sending tag bytes to a later separate
message out phase. The PIO routine I lifted from the Mac ESP driver
apparently does not sucessfully send such a short message (or the select
with attention and stop command requires special handshake).

Setting the ESP_FLAG_DISABLE_SYNC avoids triggering this behaviour.

You should be able to reproduce this on Mac by omitting the
ESP_FLAG_DISABLE_SYNC in the PIO case (just for testing - I don't
advocate letting the driver negotiate sync transfers that PIO can't
actually handle).

I think I'll give up on trying to make PIO transfers work in the general
case on Amiga, at least for now. I'll add comments to the Zorro PIO code
warning that this is only meant as a workaround for extended message in
transfer, and will fail on ESP_CMD_SELAS commands.

Cheers,

	Michael

Re: m68k v3.16 status update

[Finn Thain]

On Thu, 28 Dec 2017, Michael Schmitz wrote:

> 
> Oddly enough, this does not quite work. Due to my settings in the 
> adapter probe function (I don't set the ESP_FLAG_DISABLE_SYNC flag), the 
> ESP core uses 'select with attention and stop' instead of the normal 
> select with attention command,

I don't know why the driver would need to use ESP_CMD_SELAS over 
ESP_CMD_SA3. It might be interesting to bypass the ESP_FLAG_DOING_SLOWCMD 
test entirely.

> which attempts to send just a single byte IDENTIFY message, and defers 
> sending tag bytes to a later separate message out phase. The PIO routine 
> I lifted from the Mac ESP driver apparently does not sucessfully send 
> such a short message (or the select with attention and stop command 
> requires special handshake).
> 

That routine does not expect esp->ireg & ~ESP_INTR_BSERV when sending. But 
with ESP_CMD_SELAS, you'll get ESP_INTR_FDONE | ESP_INTR_BSERV. One 
datasheet says,

        Select with ATN and Stop

        This command should be used in place of [Select with ATN] when 
        multiple message phase bytes are to be sent. The command will 
        select a target with ATN asserted, send one message byte, and 
        generate bus service and function complete interrupts, and stop.

A different datasheet (probably a more appropriate one) says,

        The Select with ATN and Stop Steps Command is used by the 
        Initiator to send messages with lengths other than 1 or 3 bytes. 
        When this command is issued, the device executes the Selection 
        process, transfers the first message byte, then STOPS the 
        sequence. ATN is not deasserted at this time, allowing the 
        Initiator to send additional message bytes after the ID message. 
        To send these additional bytes, the Initiator must write the 
        transfer counter with the number of bytes which will follow, then 
        issue an information transfer command. (Note: the Target is still 
        in the message out phase when this command is issued). ATN will 
        remain asserted until the transfer counter decrements to zero.

This suggests to me that the interrupt needs to be cleared and handled 
before the transfer of the extra message bytes.

> Setting the ESP_FLAG_DISABLE_SYNC avoids triggering this behaviour.
> 
> You should be able to reproduce this on Mac by omitting the 
> ESP_FLAG_DISABLE_SYNC in the PIO case (just for testing - I don't 
> advocate letting the driver negotiate sync transfers that PIO can't 
> actually handle).
> 

My Quadras aren't here with me at the moment. But I have some esp_scsi 
debug logs that Stan captured on his Mac (I have a script to decode 
these):

scsi host0: cmd[01 = ESP_CMD_FLUSH]
scsi host0: cmd[c3 = ESP_CMD_SELAS ESP_CMD_DMA]
scsi host0: intr        sreg[96 = ESP_STAT_TCNT ESP_STAT_INTR ESP_MOP]  seqreg[91]      sreg2[00 =]     ireg[18 = ESP_INTR_FDONE ESP_INTR_BSERV]
scsi host0: cmd[00 = ESP_CMD_NULL]
scsi host0: cmd[01 = ESP_CMD_FLUSH]
scsi host0: event[0d = ESP_EVENT_CHECK_PHASE]   phase[06 = ESP_MOP]
scsi host0: event[09 = ESP_EVENT_MSGOUT]        phase[06 = ESP_MOP]
scsi host0: cmd[01 = ESP_CMD_FLUSH]
ESP: Sending message [
01
03
01
4c
0f
]
scsi host0: cmd[01 = ESP_CMD_FLUSH]
scsi host0: cmd[90 = ESP_CMD_TI ESP_CMD_DMA]

I can't see why that wouldn't work in the PIO case. The interrupt flags 
would have been cleared well before ESP_EVENT_MSGOUT.

Perhaps ESP_FLAG_DOING_SLOWCMD never happens on Quadras.

> I think I'll give up on trying to make PIO transfers work in the general 
> case on Amiga, at least for now.

Yes, I agree. AFAICT we can't handle the general case without core driver 
concerns leaking into the wrapper driver (which harms modularity), unless
we refactor all of the wrapper drivers (mac_esp, jazz_esp, am53c974 etc).

-- 

> I'll add comments to the Zorro PIO code warning that this is only meant 
> as a workaround for extended message in transfer, and will fail on 
> ESP_CMD_SELAS commands.
> 
> Cheers,
> 
> 	Michael
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: m68k v3.16 status update

[Michael Schmitz]

Hi Finn,

Am 29.12.2017 um 13:02 schrieb Finn Thain:
> On Thu, 28 Dec 2017, Michael Schmitz wrote:
> 
>>
>> Oddly enough, this does not quite work. Due to my settings in the 
>> adapter probe function (I don't set the ESP_FLAG_DISABLE_SYNC flag), the 
>> ESP core uses 'select with attention and stop' instead of the normal 
>> select with attention command,
> 
> I don't know why the driver would need to use ESP_CMD_SELAS over 
> ESP_CMD_SA3. It might be interesting to bypass the ESP_FLAG_DOING_SLOWCMD 
> test entirely.

As far as I understand the code, this is done when sync transfer
parameters or wide transfer hasn't been negotiated for a target yet. A
precaution, IOW.

> 
>> which attempts to send just a single byte IDENTIFY message, and defers 
>> sending tag bytes to a later separate message out phase. The PIO routine 
>> I lifted from the Mac ESP driver apparently does not sucessfully send 
>> such a short message (or the select with attention and stop command 
>> requires special handshake).
>>
> 
> That routine does not expect esp->ireg & ~ESP_INTR_BSERV when sending. But 
> with ESP_CMD_SELAS, you'll get ESP_INTR_FDONE | ESP_INTR_BSERV. One 
> datasheet says,
> 
>         Select with ATN and Stop
> 
>         This command should be used in place of [Select with ATN] when 
>         multiple message phase bytes are to be sent. The command will 
>         select a target with ATN asserted, send one message byte, and 
>         generate bus service and function complete interrupts, and stop.
> 
> A different datasheet (probably a more appropriate one) says,
> 
>         The Select with ATN and Stop Steps Command is used by the 
>         Initiator to send messages with lengths other than 1 or 3 bytes. 
>         When this command is issued, the device executes the Selection 
>         process, transfers the first message byte, then STOPS the 
>         sequence. ATN is not deasserted at this time, allowing the 
>         Initiator to send additional message bytes after the ID message. 
>         To send these additional bytes, the Initiator must write the 
>         transfer counter with the number of bytes which will follow, then 
>         issue an information transfer command. (Note: the Target is still 
>         in the message out phase when this command is issued). ATN will 
>         remain asserted until the transfer counter decrements to zero.
> 
> This suggests to me that the interrupt needs to be cleared and handled 
> before the transfer of the extra message bytes.

Yes, I had seen that in the data sheet. Changing the interrupt mask to
ignore ESP_INTR_FDONE in PIO read (i.e. message out) to account for
ESP_CMD_SELAS does still not give a working selection. I might have to
clear the interrupt some way.

>> Setting the ESP_FLAG_DISABLE_SYNC avoids triggering this behaviour.
>>
>> You should be able to reproduce this on Mac by omitting the 
>> ESP_FLAG_DISABLE_SYNC in the PIO case (just for testing - I don't 
>> advocate letting the driver negotiate sync transfers that PIO can't 
>> actually handle).
>>
> 
> My Quadras aren't here with me at the moment. But I have some esp_scsi 
> debug logs that Stan captured on his Mac (I have a script to decode 
> these):
> 
> scsi host0: cmd[01 = ESP_CMD_FLUSH]
> scsi host0: cmd[c3 = ESP_CMD_SELAS ESP_CMD_DMA]

Yes, that's the one.

> scsi host0: intr        sreg[96 = ESP_STAT_TCNT ESP_STAT_INTR ESP_MOP]  seqreg[91]      sreg2[00 =]     ireg[18 = ESP_INTR_FDONE ESP_INTR_BSERV]

And that's the interrupt conditions expected. I think I had seqreg c3,
can't remember the ireg values. Kernel log messages are not captured in
syslog on elgar at the moment so I haven't got a saved log.

> scsi host0: cmd[00 = ESP_CMD_NULL]
> scsi host0: cmd[01 = ESP_CMD_FLUSH]
> scsi host0: event[0d = ESP_EVENT_CHECK_PHASE]   phase[06 = ESP_MOP]
> scsi host0: event[09 = ESP_EVENT_MSGOUT]        phase[06 = ESP_MOP]
> scsi host0: cmd[01 = ESP_CMD_FLUSH]
> ESP: Sending message [
> 01
> 03
> 01
> 4c
> 0f
> ]
> scsi host0: cmd[01 = ESP_CMD_FLUSH]
> scsi host0: cmd[90 = ESP_CMD_TI ESP_CMD_DMA]
> 
> I can't see why that wouldn't work in the PIO case. The interrupt flags 
> would have been cleared well before ESP_EVENT_MSGOUT.

I can't see why either. Works OK in the DMA case (as in the PDMA case,
on Mac).

> Perhaps ESP_FLAG_DOING_SLOWCMD never happens on Quadras.

I think it doesn't happen on PIO Macs because esp->flags has
ESP_FLAG_DISABLE_SYNC set, suppressing sync negotiation (and wide
negotiation can't happen).

> 
>> I think I'll give up on trying to make PIO transfers work in the general 
>> case on Amiga, at least for now.
> 
> Yes, I agree. AFAICT we can't handle the general case without core driver 
> concerns leaking into the wrapper driver (which harms modularity), unless
> we refactor all of the wrapper drivers (mac_esp, jazz_esp, am53c974 etc).

Best not go there - all known ESP boards support DMA, or PIO out of the
box as in the Mac case. (Making sure PIO drivers use the identity
mapping as DMA mapping as you do on Mac might still be a way out though).

Cheers,

	Michael