From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54755) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RakDC-0007Xe-4j for qemu-devel@nongnu.org; Wed, 14 Dec 2011 03:29:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RakD6-0003aD-C4 for qemu-devel@nongnu.org; Wed, 14 Dec 2011 03:29:14 -0500 Received: from mailout1.w1.samsung.com ([210.118.77.11]:54494) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RakD6-0003Zg-7u for qemu-devel@nongnu.org; Wed, 14 Dec 2011 03:29:08 -0500 Received: from euspt1 (mailout1.w1.samsung.com [210.118.77.11]) by mailout1.w1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0LW60037OQ8FPU@mailout1.w1.samsung.com> for qemu-devel@nongnu.org; Wed, 14 Dec 2011 08:29:03 +0000 (GMT) Received: from [106.109.8.52] by spt1.w1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0LW600GWSQ8EPP@spt1.w1.samsung.com> for qemu-devel@nongnu.org; Wed, 14 Dec 2011 08:29:03 +0000 (GMT) Date: Wed, 14 Dec 2011 12:29:01 +0400 From: Mitsyanko Igor In-reply-to: Message-id: <4EE85E4D.6030006@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT References: <1323672206-11891-1-git-send-email-e.voevodin@samsung.com> <1323672206-11891-13-git-send-email-e.voevodin@samsung.com> Subject: Re: [Qemu-devel] [PATCH v3 12/14] hw/sd.c, hw/sd.h: add receive ready query routine to SD/MMC API Reply-To: i.mitsyanko@samsung.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 12/13/2011 08:22 PM, Peter Maydell wrote: > On 13 December 2011 15:11, Peter Maydell wrote: >> On 12 December 2011 06:43, Evgeny Voevodin wrote: >>> From: Mitsyanko Igor >>> >>> 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 :)