Re: [Qemu-devel] [PATCH V2 1/3] exynos4210: add Exynos4210 i2c implementation

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

On 03/21/2012 05:09 PM, Peter Maydell wrote:
> On 21 March 2012 13:07, Igor Mitsyanko<i.mitsyanko@samsung.com>  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