From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44523) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SAMNZ-00024b-5f for qemu-devel@nongnu.org; Wed, 21 Mar 2012 10:19:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SAMNR-0007Vk-Tj for qemu-devel@nongnu.org; Wed, 21 Mar 2012 10:19:08 -0400 Received: from mailout4.w1.samsung.com ([210.118.77.14]:32085) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SAMNR-0007VR-Np for qemu-devel@nongnu.org; Wed, 21 Mar 2012 10:19:01 -0400 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=UTF-8; format=flowed Received: from euspt2 ([210.118.77.14]) by mailout4.w1.samsung.com (Sun Java(tm) System Messaging Server 6.3-8.04 (built Jul 29 2009; 32bit)) with ESMTP id <0M1800DQ1NRNPR90@mailout4.w1.samsung.com> for qemu-devel@nongnu.org; Wed, 21 Mar 2012 14:18:59 +0000 (GMT) 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 <0M1800F3ANRHTU@spt2.w1.samsung.com> for qemu-devel@nongnu.org; Wed, 21 Mar 2012 14:18:54 +0000 (GMT) Date: Wed, 21 Mar 2012 18:18:54 +0400 From: Igor Mitsyanko In-reply-to: Message-id: <4F69E34E.1020300@samsung.com> References: <1331796924-30669-1-git-send-email-i.mitsyanko@samsung.com> <1331796924-30669-2-git-send-email-i.mitsyanko@samsung.com> <4F69D276.5070905@samsung.com> Subject: Re: [Qemu-devel] [PATCH V2 1/3] exynos4210: add Exynos4210 i2c implementation Reply-To: i.mitsyanko@samsung.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: e.voevodin@samsung.com, qemu-devel@nongnu.org, kyungmin.park@samsung.com, d.solodkiy@samsung.com, m.kozlov@samsung.com, afaerber@suse.de On 03/21/2012 05:09 PM, Peter Maydell wrote: > On 21 March 2012 13:07, Igor Mitsyanko wrote: >> On 03/21/2012 03:55 PM, Peter Maydell wrote: >>> I suspect that what's happening here is that the hardware >>> lets you put the i2c controller into slave mode so some >>> other device on the bus can be a master. But QEMU's >>> i2c bus abstraction doesn't cover that use case at all... > >> Yes, I saw this statement in hw/i2c.h (and probably cpu i2c controller will >> never be used as i2c slave device by anyone), but I think we still have to >> implement devices exactly like they described in documentation. > > I agree with the sentiment, I'm just not sure if the code you've > written is actually doing that. The right way to model this would > be if our i2c bus implementation provided an interface so you > could register as a device which is a master but can switch into > slave mode. I don't think we can do that without multiple inheritance, and it wouldn't worth an effort for a feature that never going to be used. Failing that, maybe we should just not support switching > into slave mode at all. Do you mean we shouldn't register EXYNOS4_I2C_SLAVE at all so some hypothetical bus master wouldn't even find EXYNOS4_I2C_SLAVE on a bus? Maybe the best solution is to make exynos4210_i2c_slave_send() and exynos4210_i2c_slave_recv() always return -1, so a hypothetical bus master will treat EXYNOS4_I2C_SLAVE as a broken device. But that seems to behave exactly like "not register at all" approach.. And are we really sure that slave interface wouldn't work correctly in a current implementation? For example, emulated Exynos CPU issues some command to a device A on SPI line and device A in turn issues data on i2c line connected to Exynos i2c controller configured as slave. EXYNOS4_I2C_SLAVE receives a data and raises interrupt flag. Registering as two separate devices on the > i2c bus doesn't sound right to me. > Why? That's how it's done in hardware, I think we can roughly consider it to be two separate devices multiplexing single bus. -- Mitsyanko Igor ASWG, Moscow R&D center, Samsung Electronics email: i.mitsyanko@samsung.com