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

[Igor Mitsyanko]

On 03/21/2012 05:09 PM, Peter Maydell wrote:
> On 21 March 2012 13:07, Igor Mitsyanko<address@hidden>  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: address@hidden