Re: A bit confused on i2c communication between modules

Re: A bit confused on i2c communication between modules

[Kieran Bingham]

+cc: linux-i2c@vger.kernel.org
Moving /this/ to the linux-i2c list ;-)

Thanks Wolfram,

On 24/03/2020 10:27, Wolfram Sang wrote:
> 
>> Maybe we should have a whole virtual I2C bus for virtual devices :-)
>>
>> (Hrm, that started out as a joke, and now I'm not sure if it's a real
>> option or not...)
> 
> Just one final thought: I think this is actually the best option. Zero
> chance of address collisions (which could happen if you have a not
> perfectly-described real HW bus). No RPM mangling of real and virtual
> devices. A clear seperation what is real and what is virtual. Plus, you
> can implement it right away, no need to wait for the dynamic address
> assignment.

Agreed - even better all round! But I presume we don't yet have a
'virtual' i2c bus? So it's a patch-set to do first? Or is it already
feasible?

I see references to 'i2c-virtual.c' and 'i2c-virt.c', but I can't find
those files or any config options themselves...

-- 
Regards

Re: A bit confused on i2c communication between modules

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]

On Tue, Mar 24, 2020 at 10:49:55AM +0000, Kieran Bingham wrote:
> +cc: linux-i2c@vger.kernel.org
> Moving /this/ to the linux-i2c list ;-)
> 
> Thanks Wolfram,
> 
> On 24/03/2020 10:27, Wolfram Sang wrote:
> > 
> >> Maybe we should have a whole virtual I2C bus for virtual devices :-)
> >>
> >> (Hrm, that started out as a joke, and now I'm not sure if it's a real
> >> option or not...)
> > 
> > Just one final thought: I think this is actually the best option. Zero
> > chance of address collisions (which could happen if you have a not
> > perfectly-described real HW bus). No RPM mangling of real and virtual
> > devices. A clear seperation what is real and what is virtual. Plus, you
> > can implement it right away, no need to wait for the dynamic address
> > assignment.
> 
> Agreed - even better all round! But I presume we don't yet have a
> 'virtual' i2c bus? So it's a patch-set to do first? Or is it already
> feasible?

From what I understand, you won't need an API for that. What I
understand:

There will be a master device (a DVB or something). This will register
its own i2c_adapter with a dummy .xfer callback. The sub-devices will be
i2c_clients, then. I don't know how you want communication between
those. Maybe the .xfer callback will need to do some message parsing?


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: A bit confused on i2c communication between modules

[Mauro Carvalho Chehab]

Em Tue, 24 Mar 2020 12:01:22 +0100
Wolfram Sang <wsa@the-dreams.de> escreveu:

> On Tue, Mar 24, 2020 at 10:49:55AM +0000, Kieran Bingham wrote:
> > +cc: linux-i2c@vger.kernel.org
> > Moving /this/ to the linux-i2c list ;-)
> > 
> > Thanks Wolfram,
> > 
> > On 24/03/2020 10:27, Wolfram Sang wrote:  
> > >   
> > >> Maybe we should have a whole virtual I2C bus for virtual devices :-)
> > >>
> > >> (Hrm, that started out as a joke, and now I'm not sure if it's a real
> > >> option or not...)  
> > > 
> > > Just one final thought: I think this is actually the best option. Zero
> > > chance of address collisions (which could happen if you have a not
> > > perfectly-described real HW bus). No RPM mangling of real and virtual
> > > devices. A clear seperation what is real and what is virtual. Plus, you
> > > can implement it right away, no need to wait for the dynamic address
> > > assignment.  
> > 
> > Agreed - even better all round! But I presume we don't yet have a
> > 'virtual' i2c bus? So it's a patch-set to do first? Or is it already
> > feasible?  
> 
> From what I understand, you won't need an API for that. What I
> understand:
> 
> There will be a master device (a DVB or something). This will register
> its own i2c_adapter with a dummy .xfer callback. The sub-devices will be
> i2c_clients, then. 

Yes. That's what the current drivers that have integrated hardware
at the same silicon (like rtl28xx) do: their .xfer callback splits the
I2C addresses reserved for "internal" devices, and use a different set
of registers to handle those, instead of the normal ones used to
communicate with a real I2C hardware.

The cx231xx uses a different strategy: it has multiple I2C buses, being
one of them reserved for its own integrated I2C like bus.

> I don't know how you want communication between
> those. Maybe the .xfer callback will need to do some message parsing?
> 



Thanks,
Mauro

Re: A bit confused on i2c communication between modules

[Mauro Carvalho Chehab]

Em Tue, 24 Mar 2020 10:49:55 +0000
Kieran Bingham <kieran.bingham@ideasonboard.com> escreveu:

> +cc: linux-i2c@vger.kernel.org
> Moving /this/ to the linux-i2c list ;-)

+cc: linux-media@vger.kernel.org

The discussion of having a virtual i2C bus can be interesting at
linux-media as well, as other virtual drivers could eventually need
it.

Just placing some context here, we're developing a DVB virtual driver,
in order to allow testing Digital TV applications without requiring
a real hardware.

The DVB driver model is that there's a main driver ("bridge" driver)
with creates a digital TV adapter and (at least) two other drivers,
responsible for tuning into a channel and decoding the digital TV
protocols. The output of a DVB driver is a MPEG-TS stream.

A typical TV board looks like this:

	https://linuxtv.org/downloads/v4l-dvb-apis-new/_images/typical_media_device.svg

Those drivers are:

- a tuner driver, usually at address 0x61 (7-bit notation)
- a demodulator driver, usually at address 0x0e (although there are
  other addresses also used by different drivers).

As shown at the picture, the vast majority of devices use I2C. There are
even some chips with have an internal I2C like bus with some internal 
devices, like cx231xx.

As one of the goals of a virtual driver is to serve as a basis for new
developments, we'd like to keep the virtual DVB drivers as close as
possible of real drivers.

> 
> Thanks Wolfram,
> 
> On 24/03/2020 10:27, Wolfram Sang wrote:
> >   
> >> Maybe we should have a whole virtual I2C bus for virtual devices :-)
> >>
> >> (Hrm, that started out as a joke, and now I'm not sure if it's a real
> >> option or not...)  
> > 
> > Just one final thought: I think this is actually the best option. Zero
> > chance of address collisions (which could happen if you have a not
> > perfectly-described real HW bus). No RPM mangling of real and virtual
> > devices. A clear seperation what is real and what is virtual. Plus, you
> > can implement it right away, no need to wait for the dynamic address
> > assignment.  

We don't need dynamic address assignment here. At least for now,
all digital TV drivers we have use fixed I2C assignments.

> Agreed - even better all round! But I presume we don't yet have a
> 'virtual' i2c bus? So it's a patch-set to do first? Or is it already
> feasible?
> 
> I see references to 'i2c-virtual.c' and 'i2c-virt.c', but I can't find
> those files or any config options themselves...

FYI, there are some drivers that have the demodulated device for some
TV standards integrated with the bridge one. that's the case, for
example, of rtl28xx. It may either use its internal demodulator or
an external one (via I2C). Right now, the driver handles its 
internal demodulator using I2C support (as this makes easier for it
to also support external demods, by just changing the I2C address).

So, right now we actually mix "virtual" and "real hardware" support,
at least on some drivers.

So, I'm not so sure if we need any new feature at I2C side.

Thanks,
Mauro