qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] SD card subsystem synchronous I/O


From: andrzej zaborowski
Subject: Re: [Qemu-devel] SD card subsystem synchronous I/O
Date: Fri, 20 Apr 2012 13:29:10 +0200

On 20 April 2012 11:50, Stefan Hajnoczi <address@hidden> wrote:
> On Fri, Apr 20, 2012 at 12:21 AM, andrzej zaborowski <address@hidden> wrote:
>> Yes, controllers would be affected, but there are various ways to go
>> about it.  Some could be simple to implement (looking at
>> pxa2xx_mmci.c).  First of all the SD specification pretty much assumes
>> the storage medium is flash and data is available "immediately" after
>> it is requested.  The host drives the clock and there's a fixed number
>> of cycles that pass between a command and the response.  There's a
>> mechanism for the card to indicate it is busy programming after data
>> is written, but it doesn't apply to some types of writes.
>>
>> However the number of cycles between command and response can be
>> different between card manufacturers, so it looks like the card can
>> pull either the CMD and the DAT line high before starting to send the
>> command response or the data.  In qemu you could either make the data
>> transfers async, or the response transfers async, there's no need to
>> do both.
>>
>> If the image is on a network filesystem then there could be problems
>> caused by the synchronous IO.  Anything else, I'd guess that the
>> caches, readahead and what not make sync IO the same or unnoticeably
>> faster overall.  pxa2xx_mmci.c would be easy to convert to async, but
>> some host controllers that are more software than hardware might
>> theoretically give up if the card doesn't respond in N cycles.
>
> Even in a case where the bus specification is strict about timing it's
> possible that the controllers that guest drivers talk to hide those
> details and instead work on an interrupt-driven basis.

Yep.

>
> In other words, maybe most of the work will be converting controllers
> to implement the busy state while we do actual block I/O.  Is this
> possible or do SD controllers expose the real low-level timing aspects
> of the bus to the guest drivers?

The PXA270 one does not and it would be quite easy to convert, as
mentioned.  It's probably true for most SoCs' controllers.  Many
devices (not necessarily emulated in Qemu) just have the SD card's
pads wired to GPIOs and driven in software or other solutions between
fully software and fully hardware.  Linux doesn't have any generic
"bit banging" driver for them as far as I can see.

Cheers



reply via email to

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