Re: [Qemu-devel] [PATCH v3 12/14] hw/sd.c, hw/sd.h: add receive ready query routine to SD/MMC API

[Mitsyanko Igor <i.mitsyanko@samsung.com>]

On 12/13/2011 08:22 PM, Peter Maydell wrote:
> On 13 December 2011 15:11, Peter Maydell<peter.maydell@linaro.org>  wrote:
>> On 12 December 2011 06:43, Evgeny Voevodin<e.voevodin@samsung.com>  wrote:
>>> From: Mitsyanko Igor<i.mitsyanko@samsung.com>
>>>
>>> Data transfer direction between host controller and SD/MMC card is selected by
>>> host controller configuration registers, but whether we actually need or need
>>> not perform data transfer depends on type of last issued command. To avoid
>>> memorization of which type of command host controller issued the last time, we
>>> can use simple query procedures, to make sure that SD/MMC card is in the
>>> right state. The only query routine currently presented in SD/MMC card
>>> emulation is sd_data_ready(), this patch adds sd_receive_ready() routine.
>>
>> I've thought about this a bit more and spent some time poking through
>> the standards docs. I'm kind of suspicious of both this function and
>> the existing sd_data_ready(). Real hardware doesn't have these signals,
>> both ends of the sd-controller-to-card connection just do their thing
>> and trust that the other end is in the state it is supposed to be.
>> If you (in the controller model) don't already know whether you are
>> OK to send/receive data then you haven't modelled some part of the
>> controller's state properly.
>
> Having thought even more :-), sd_data_ready() is actually modelling a
> real hardware behaviour: "have we seen the start bit on the data line?".
> So it is justifiable. I still don't think sd_receive_ready() is, though.
>
> -- PMM
>
>

I thought it's a good idea to protect user data from corruption because 
of inappropriate driver behaviour, even though it's obviously not a 
controller's concern. But after your comment about start bit it started 
to make sense to me that sd_data_ready() exists in current 
implementation, while other query functions don't :)