Re: m68k v3.16 status update

[Finn Thain <fthain@telegraphics.com.au>]

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
>