Re: [Qemu-ppc] [PULL 075/118] macio: handle non-block ATAPI DMA transfers

[Mark Cave-Ayland]

On 04/06/14 13:44, Alexander Graf wrote:

> From: Mark Cave-Ayland <address@hidden>
>
> Currently the macio DMA routines assume that all DMA requests are for read/write
> block transfers. This is not always the case for ATAPI, for example when
> requesting a TOC where the response is generated directly in the IDE buffer.
>
> Detect these non-block ATAPI DMA transfers (where no lba is specified in the
> command) and copy the results directly into RAM as indicated by the DBDMA
> descriptor. This fixes CDROM access under MorphOS.
>
> Signed-off-by: Mark Cave-Ayland <address@hidden>
> Signed-off-by: Alexander Graf <address@hidden>

I've just done a complete round of OpenBIOS tests and it looks as if 
this patch introduces random hang failures (60% or so) into my Darwin 
image boot tests.

The issue seems to be related as to the timing of the DMA callback 
relative to reception of the IDE command; if the IDE transfer is invoked 
first (as happens in Darwin) then we hang after sending the IDE command 
which is likely because the DMA is not being completed correctly. There 
is also another difference with MorphOS in that when the IDE transfer 
callback is invoked first then s->packet_transfer_size == 0 and so the 
memory copy would always copy 0 bytes.

After some experimentation, I've come up with the attached patch which 
should retain the DMA memory copy, but instead invokes a further round 
of pmac_ide_atapi_transfer_cb() with io->len == 0 and s->io_buffer_size 
== 0 which should terminate the DMA request correctly. At the very least 
it seems to fix the hang on boot with my Darwin images.

Zoltan, please can you test the attached patch to see if this still 
allows MorphOS to boot?


ATB,

Mark.

qemu-macio-ppc.patch
Description: Text Data