Re: A bit confused on i2c communication between modules

[Mauro Carvalho Chehab <mchehab+huawei@kernel.org>]

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