From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43055) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SEhLo-0006lz-4O for qemu-devel@nongnu.org; Mon, 02 Apr 2012 09:31:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SEhLl-0000ae-PW for qemu-devel@nongnu.org; Mon, 02 Apr 2012 09:31:15 -0400 Received: from mailout3.w1.samsung.com ([210.118.77.13]:27364) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SEhLl-0000aM-Gl for qemu-devel@nongnu.org; Mon, 02 Apr 2012 09:31:13 -0400 Received: from euspt2 ([210.118.77.13]) by mailout3.w1.samsung.com (Sun Java(tm) System Messaging Server 6.3-8.04 (built Jul 29 2009; 32bit)) with ESMTP id <0M1U00J1YTJHMD70@mailout3.w1.samsung.com> for qemu-devel@nongnu.org; Mon, 02 Apr 2012 14:30:54 +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 <0M1U00HDRTJSKI@spt2.w1.samsung.com> for qemu-devel@nongnu.org; Mon, 02 Apr 2012 14:31:05 +0100 (BST) Date: Mon, 02 Apr 2012 17:31:04 +0400 From: Igor Mitsyanko In-reply-to: Message-id: <4F79AA18.9070202@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE 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 Crosthwaite Cc: Kevin Wolf , Peter Maydell , vpalatin@chromium.org, qemu-devel@nongnu.org, paul@codesourcery.com, duyl@xilinx.com, linnj@xilinx.com, edgar.iglesias@gmail.com, =?ISO-8859-1?Q?Andreas_F=E4rber?= , john.williams@petalogix.com, Dmitry Solodkiy On 04/02/2012 03:05 PM, Peter Crosthwaite wrote: > On Mon, Apr 2, 2012 at 6:38 PM, Igor Mitsyanko wrote: >> On 04/02/2012 12:00 PM, Andreas F=E4rber wrote: >>> >>> Am 02.04.2012 09:20, schrieb Peter Maydell: >>>> >>>> On 2 April 2012 07:24, Peter A. G. Crosthwaite >>>> wrote: >>>>> >>>>> device more for standard SD host controller interface (SDHCI). >>>>> >>>>> Signed-off-by: Peter A. G. Crosthwaite >>>> >>>> >>>> So how does this compare with Vincent Palatin's version? >>>> (http://patchwork.ozlabs.org/patch/106767/) I'm guessing from >>>> the copyright string that it's a modified version -- it would >>>> be nice to say what the differences are. >>> >>> >>> ...and what the differences to Samsung's version are. >>> >>> We should probably also cc Kevin on the topic. >>> >>> Andreas >> >> >> It looks like this sdhc implements version 1 of standard SDHC spec= ification, >> while ours implements second version. > > The implementation is not a fully 100% complete SDHCI (indeed very = few > QEMU models of anything are 100% true to the hardware), Id have t= o > have a good look through the spec to give you what v2 features are = and > arent implemented, but this is supposed to have some level of v2 > support. > > Second version should be backwards >> compatible with first, > > Yes, I had to add somebackward compatibility to Vincents model arou= nd > the ADMA stuff. > > I didn't want to submit it yet to see if vmstate >> issue will be resolved or not. And also the whole QEMU SD emulatio= n scheme >> needs some refactoring which I've been busy with for a while now. = The >> biggest issues are that currently we cannot hot-insert SD card int= o virtual >> board interface and we do not take any advantage of QOM (which is = hard until >> Paolo's and Andrea's patches land in master). >> The one advantage of our SDHCI implementation is that it provides = interface >> to implement SoC-specific successors of standart SDHCI. I'll send = these >> patches today (even though I wanted to do a lot more refactoring w= ith them), >> Peter, could you please test them to find out if you can use them = instead of >> your SDHCI implementation? > > Yes i can but will they these patches be immediately mergable? > > My primary motivation for pushing this is to get my platform upstre= am > and maintained. To that end, if major construction effort is requir= ed > to get your SDHCI up to acceptable (which you have indicated in you= r > comments) then can we push this anyway, and then when your refactor= ing > happens, your model can replace this model. Yes, I've been trying to get my sdhc accepted since last year :) I tr= ied=20 to comply with specification entirely, your implementation is obvious= ly=20 much smaller but enough for use with Linux driver (i've tested it wit= h=20 exynos board emulation). I have some comments though: 1) It doesn't compile because adma_stride could be used uninitialized= in=20 sdhci_dma_transfer() (QEMU is compiled with -Werror); 2) You shouldn't hw_error() on bad reads/writes. 3) Why do you register memory region with 0x200 size and then print= =20 error messages on read and writes in a range 0x100-0x200? 4) Controller transfers data in blocks of blksize (512 usually) bytes= ,=20 but you transfer data immediately on writes to registers, you probabl= y=20 should use a buffer for this. 5) You assume that BUFFER_DATAPORT register is always accessed with 4= =20 byte system bus transfers, but it's not true in general. 6) SDMA transfer must continue when you write to the upper byte of= =20 SDMA_SYSAD register if it was stoped at page boundary. 7) Maybe it's not important, but you have no support of 64-bit target= =20 emulation. 8) Why "sysbus_sdhci" instead of simple "sdhci"? --=20 Mitsyanko Igor ASWG, Moscow R&D center, Samsung Electronics email: i.mitsyanko@samsung.com