From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51666) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SEhko-0008VV-0r for qemu-devel@nongnu.org; Mon, 02 Apr 2012 09:57:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SEhkb-0000Mf-Ak for qemu-devel@nongnu.org; Mon, 02 Apr 2012 09:57:05 -0400 Received: from mailout2.w1.samsung.com ([210.118.77.12]:14239) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SEhkb-0000MI-50 for qemu-devel@nongnu.org; Mon, 02 Apr 2012 09:56:53 -0400 Received: from euspt2 (mailout2.w1.samsung.com [210.118.77.12]) by mailout2.w1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0M1U00GL6UQLCA@mailout2.w1.samsung.com> for qemu-devel@nongnu.org; Mon, 02 Apr 2012 14:56:45 +0100 (BST) Received: from [106.109.8.162] by spt2.w1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0M1U00HVTUQKKI@spt2.w1.samsung.com> for qemu-devel@nongnu.org; Mon, 02 Apr 2012 14:56:45 +0100 (BST) Date: Mon, 02 Apr 2012 17:56:45 +0400 From: Igor Mitsyanko In-reply-to: Message-id: <4F79B01D.5090501@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT References: <4F795CB7.9060404@suse.de> <4F796593.1080306@samsung.com> Subject: Re: [Qemu-devel] [PATCH v1 1/2] SDHCI: inital version Reply-To: i.mitsyanko@samsung.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Kevin Wolf , vpalatin@chromium.org, qemu-devel@nongnu.org, "Peter A. G. Crosthwaite" , paul@codesourcery.com, duyl@xilinx.com, linnj@xilinx.com, edgar.iglesias@gmail.com, =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , john.williams@petalogix.com, Dmitry Solodkiy On 04/02/2012 05:46 PM, Peter Maydell wrote: > On 2 April 2012 09:38, Igor Mitsyanko wrote: >> It looks like this sdhc implements version 1 of standard SDHC specification, >> while ours implements second version. Second version should be backwards >> compatible with first, I didn't want to submit it yet to see if vmstate >> issue will be resolved or not. > Which vmstate issue is this? I know we've been having discussions about > how to implement save/load for sd.c, but that shouldn't affect an SD > controller model I think. > during save/load I wanted to derive buffer size with switch statement from bits 16-17 of controller's capabilities register: 0 - 512 bytes, 1 - 1024, 2 - 2048. -- Mitsyanko Igor ASWG, Moscow R&D center, Samsung Electronics email: i.mitsyanko@samsung.com