[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC 0/2] macio: split out unaligned DMA access into se

From: John Snow
Subject: Re: [Qemu-devel] [RFC 0/2] macio: split out unaligned DMA access into separate functions
Date: Fri, 22 May 2015 14:20:23 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

On 05/22/2015 02:16 PM, Mark Cave-Ayland wrote:
> On 22/05/15 18:55, John Snow wrote:
>> On 03/09/2015 06:24 PM, Mark Cave-Ayland wrote:
>>> This patchset attempts to separate out the IDE/ATAPI logic from the 
>>> unaligned
>>> DMA access logic for macio which provides the following benefits:
>>> 1) Reduced code complexity
>>> The existing macio IDE/ATAPI functions were becoming extremely difficult to
>>> follow through the various callbacks. By splitting up the functions in this
>>> way it becomes much easier to follow the DMA-specific sections of code.
>>> 2) Future-proofing
>>> If/when the block layer becomes able to handle unaligned DMA accesses 
>>> directly
>>> then it should be possible to switch out pmac_dma_read() and 
>>> pmac_dma_write()
>>> with their unaligned-capable bdrv_*() equivalents without having to change 
>>> any
>>> other logic.
>>> 3) Fix intermittent CDROM detection under -M g3beige
>>> The code refactoring now correctly handles non-block ATAPI transfers which
>>> fixes the problem with intermittent CDROM detection with Darwin under
>>> -M g3beige.
>>> Signed-off-by: Mark Cave-Ayland <address@hidden>
>>> Mark Cave-Ayland (2):
>>>   macio: move unaligned DMA read code into separate pmac_dma_read()
>>>     function
>>>   macio: move unaligned DMA write code into separate pmac_dma_write()
>>>     function
>>>  hw/ide/macio.c             |  487 
>>> +++++++++++++++++++++++---------------------
>>>  include/hw/ppc/mac_dbdma.h |    4 -
>>>  2 files changed, 254 insertions(+), 237 deletions(-)
>> Code fails 32 bit build due to %lx debug prints. I'll edit them
>> accordingly if that is OK by you.
> Please go right ahead :)  Do you need a proper re-spin without the RFC
> prefix? If so, I can make the changes there if that helps?
> ATB,
> Mark.

Nah, the tags seem to get dropped when you pull everything into git
anyway, so it's no biggie.


As a post-script, can Darwin/PPC use a different mechanism for ATA at
all, or is macio the sole ATA interface we support here?

I want to see if I can pinpoint when a "good" bath and when a bad path
diverges with respect to the disk contents ...

Or if you have other ideas on how to identify the transfer that causes
the issue, I'm all ears.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]