I2C dummy adapter driver ?

I2C dummy adapter driver ?

[Sylwester Nawrocki]

Hi All,

I was wondering whether it would be reasonable to create a generic
Linux dummy I2C bus controller driver. The rationale behind it is
there might be hardware configurations where I2C communication is
handled by firmware but still it is useful to have I2C slave devices
instantiated by a Linux I2C bus adapter driver.
It would be useful to have the common devicetree I2C binding scheme
working regardless of where the I2C communication is handled - in
firmware or by the host CPU.

Currently we have a somewhat dummy I2C adapter driver at drivers/media/
platform/exynos4-is/fimc-is-i2c.c. But it is going to be needed by
multiple SoCs and I thought about separating it or creating a generic
dummy I2C adapter driver.

Thoughts, suggestions ?

Thanks,
Sylwester

I2C dummy adapter driver ?

[Stephen Warren]

On 02/19/2014 04:03 PM, Sylwester Nawrocki wrote:
> Hi All,
> 
> I was wondering whether it would be reasonable to create a generic
> Linux dummy I2C bus controller driver. The rationale behind it is
> there might be hardware configurations where I2C communication is
> handled by firmware but still it is useful to have I2C slave devices
             ^^^^^^^^

That doesn't sound like a dummy driver. Rather, it sounds like a driver
for the firmware(?) interface that's used to do the I2C transactions.

> instantiated by a Linux I2C bus adapter driver.
> It would be useful to have the common devicetree I2C binding scheme
> working regardless of where the I2C communication is handled - in
> firmware or by the host CPU.
> 
> Currently we have a somewhat dummy I2C adapter driver at drivers/media/
> platform/exynos4-is/fimc-is-i2c.c. But it is going to be needed by
> multiple SoCs and I thought about separating it or creating a generic
> dummy I2C adapter driver.

I2C dummy adapter driver ?

[Jassi Brar]

On 20 February 2014 04:33, Sylwester Nawrocki
<sylvester.nawrocki@gmail.com> wrote:
> Hi All,
>
> I was wondering whether it would be reasonable to create a generic
> Linux dummy I2C bus controller driver. The rationale behind it is
> there might be hardware configurations where I2C communication is
> handled by firmware but still it is useful to have I2C slave devices
> instantiated by a Linux I2C bus adapter driver.
> It would be useful to have the common devicetree I2C binding scheme
> working regardless of where the I2C communication is handled - in
> firmware or by the host CPU.
>
> Currently we have a somewhat dummy I2C adapter driver at drivers/media/
> platform/exynos4-is/fimc-is-i2c.c.
>
The driver does seem 'dummy' because it doesn't implement the
i2c_algorithm.master_xfer()
Perhaps your remote f/w contains the client driver for the slave chip
and it abstracts out the controls for you over mailbox? If so, I think
you can do even without this dummy driver.

OTOH if the remote doesn't know how to drive the slave and it simply
read/write the registers over i2c just as you ask it over mailbox,
then we do need a 'virtual pass-through' driver that maps Linux I2C
API onto remote's api in the i2c_algorithm.master_xfer()  Such a
virtual driver may indeed be shared across platforms but if it works
over some common mailbox api. (my platform will share that with yours)

Cheers,
Jassi

I2C dummy adapter driver ?

[Sylwester Nawrocki]

On 20/02/14 17:49, Stephen Warren wrote:
> On 02/19/2014 04:03 PM, Sylwester Nawrocki wrote:
[...]
>> I was wondering whether it would be reasonable to create a generic
>> Linux dummy I2C bus controller driver. The rationale behind it is
>> there might be hardware configurations where I2C communication is
>> handled by firmware but still it is useful to have I2C slave devices
>              ^^^^^^^^
> 
> That doesn't sound like a dummy driver. Rather, it sounds like a driver
> for the firmware(?) interface that's used to do the I2C transactions.

Hmm, I think you're right. Just to clarify a bit, as the I2C slave device
is part of a more complex data processing chain, it is not exposed by
the firmware on a I2C read/write like command interface.
So the only thing the Linux I2C client does currently is to enable some
voltage regulators and driver reset pin through a GPIO. 

However it depends on the firmware for the MCU controlling the whole
camera data processing chain, currently the I2C slave control transactions
are being handled in an opaque way by the firmware, it just exposes (very 
few) high level commands specifically related to the I2C slave.
It could be also that the firmware leaves out the I2C bus controller and
I2C slave handling solely to the host CPU. In such case a regular I2C
bus controller driver is needed. Hence the exact role of the I2C bus 
controller driver highly depends on the firmware loaded.

I assume the "driver for the firmware interface" is a good definition.
I'm just not sure what best location of such an I2C bus driver, supposedly
drivers/media/i2c would be a good fit, rather than drivers/i2c/busses.

I2C dummy adapter driver ?

[Sylwester Nawrocki]

On 21/02/14 06:57, Jassi Brar wrote:
> On 20 February 2014 04:33, Sylwester Nawrocki
> <sylvester.nawrocki@gmail.com> wrote:
>> Hi All,
>>
>> I was wondering whether it would be reasonable to create a generic
>> Linux dummy I2C bus controller driver. The rationale behind it is
>> there might be hardware configurations where I2C communication is
>> handled by firmware but still it is useful to have I2C slave devices
>> instantiated by a Linux I2C bus adapter driver.
>> It would be useful to have the common devicetree I2C binding scheme
>> working regardless of where the I2C communication is handled - in
>> firmware or by the host CPU.
>>
>> Currently we have a somewhat dummy I2C adapter driver at drivers/media/
>> platform/exynos4-is/fimc-is-i2c.c.
>>
> The driver does seem 'dummy' because it doesn't implement the
> i2c_algorithm.master_xfer()
> Perhaps your remote f/w contains the client driver for the slave chip
> and it abstracts out the controls for you over mailbox? If so, I think
> you can do even without this dummy driver.

Yes, you got it right. I could do without this driver, but it simplifies
code of the whole camera subsystem driver. Since normally image sensors
are I2C clients, for these F/W controller sensors I would have to introduce
additional code, which might have complicated the camera subsystem driver
a bit. And there is a push to write image sensor drivers in V4L2 as
reusable modules, and I2C is one of the standard interfaces already used
there.
The I2C bus driver with empty i2c_algorithm.master_xfer() helps WRT to
using standard DT binding and v4l2_subdev interface.

> OTOH if the remote doesn't know how to drive the slave and it simply
> read/write the registers over i2c just as you ask it over mailbox,
> then we do need a 'virtual pass-through' driver that maps Linux I2C
> API onto remote's api in the i2c_algorithm.master_xfer()  Such a
> virtual driver may indeed be shared across platforms but if it works
> over some common mailbox api. (my platform will share that with yours)

Hmm, that's (unfortunately;)) not my case. If the host was to access the
I2C slave over I2C the I2C bus controller and the I2C slave drivers could
be well implemented as regular drivers on the host CPU side.
However it could be also possible that the firmware exposes fine grained
control interface for an I2C slave, alongside the higher level interface.
Then what you describe above could be useful. Presumably that wouldn't
be very practical though.

--
Regards,
Sylwester

I2C dummy adapter driver ?

[Mark Brown]

On Fri, Feb 21, 2014 at 12:45:21PM +0100, Sylwester Nawrocki wrote:

> The I2C bus driver with empty i2c_algorithm.master_xfer() helps WRT to
> using standard DT binding and v4l2_subdev interface.

Wouldn't a platform device do just as well here if there's no actual
control?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140228/376a4f72/attachment.sig>

I2C dummy adapter driver ?

[Sylwester Nawrocki]

On 28/02/14 07:07, Mark Brown wrote:
> On Fri, Feb 21, 2014 at 12:45:21PM +0100, Sylwester Nawrocki wrote:
> 
>> The I2C bus driver with empty i2c_algorithm.master_xfer() helps WRT to
>> using standard DT binding and v4l2_subdev interface.
> 
> Wouldn't a platform device do just as well here if there's no actual
> control?

Then the I2C client devices would have to be instantiated manually, 
I think it's more trouble.
I could as well create custom I2C client drivers per ISP, but then the 
I2C devices would have to be represented somehow in DT, to pass stuff 
like voltage regulators and GPIOs. Anyway, it's not something could be 
done in mainline.

Even if there is no actual I2C communication on the host CPU side, the 
power up/down sequence is handled there. The intention is to keep this 
common per an I2C client, regardless of whether I2C communication is 
done by firmware or the host the CPU.

I2C dummy adapter driver ?

[Mark Brown]

On Tue, Mar 04, 2014 at 12:38:28PM +0100, Sylwester Nawrocki wrote:
> On 28/02/14 07:07, Mark Brown wrote:
> > On Fri, Feb 21, 2014 at 12:45:21PM +0100, Sylwester Nawrocki wrote:

> >> The I2C bus driver with empty i2c_algorithm.master_xfer() helps WRT to
> >> using standard DT binding and v4l2_subdev interface.

> > Wouldn't a platform device do just as well here if there's no actual
> > control?

> Then the I2C client devices would have to be instantiated manually, 
> I think it's more trouble.

I2C is not that much more enumerable than platform bus, I don't see the
difference here?  To the extent I2C is enumerable a dummy adaptor isn't
going to support that.

> I could as well create custom I2C client drivers per ISP, but then the 
> I2C devices would have to be represented somehow in DT, to pass stuff 
> like voltage regulators and GPIOs. Anyway, it's not something could be 
> done in mainline.

Why not?

> Even if there is no actual I2C communication on the host CPU side, the 
> power up/down sequence is handled there. The intention is to keep this 
> common per an I2C client, regardless of whether I2C communication is 
> done by firmware or the host the CPU.

The way you're talking it sounds like your code is very hard coded to
use I2C here.  What happens if someone uses SPI or some other bus to
control an ISP?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140305/38a5366d/attachment.sig>

I2C dummy adapter driver ?

[Sylwester Nawrocki]

On 05/03/14 02:15, Mark Brown wrote:
> On Tue, Mar 04, 2014 at 12:38:28PM +0100, Sylwester Nawrocki wrote:
>> On 28/02/14 07:07, Mark Brown wrote:
>>> On Fri, Feb 21, 2014 at 12:45:21PM +0100, Sylwester Nawrocki wrote:
> 
>>>> The I2C bus driver with empty i2c_algorithm.master_xfer() helps WRT to
>>>> using standard DT binding and v4l2_subdev interface.
> 
>>> Wouldn't a platform device do just as well here if there's no actual
>>> control?
> 
>> Then the I2C client devices would have to be instantiated manually, 
>> I think it's more trouble.
> 
> I2C is not that much more enumerable than platform bus, I don't see the
> difference here?  To the extent I2C is enumerable a dummy adaptor isn't
> going to support that.

Yes, it won't be enumerable, I just meant allocating client devices 
would need to be taken care of, rather that having this handled entirely 
by, e.g. i2c-core. 

>> I could as well create custom I2C client drivers per ISP, but then the 
>> I2C devices would have to be represented somehow in DT, to pass stuff 
>> like voltage regulators and GPIOs. Anyway, it's not something could be 
>> done in mainline.
> 
> Why not?

Well, my concern was that existing sub-device drivers would need to be
extended to handle other bus types, like the platform bus.

And since that very same device could be controlled by the host CPU or
not, it just depends what host interface/SoC it is linked to, such
a complication may not be justified.  It's like introducing bridge/host 
details to the client drivers. In general the sub-devices should be
host-agnostic.

>> Even if there is no actual I2C communication on the host CPU side, the 
>> power up/down sequence is handled there. The intention is to keep this 
>> common per an I2C client, regardless of whether I2C communication is 
>> done by firmware or the host the CPU.
> 
> The way you're talking it sounds like your code is very hard coded to
> use I2C here.  What happens if someone uses SPI or some other bus to
> control an ISP?

The other busses, like SPI, are also handled the V4L2 subdev in 
a standard way.  The host just need to be aware on what control bus 
a subdev is located on, to get hold of it.

Let me add that for image sensors I2C is used as a control bus in 
majority of cases.  An I2C-compatible (CCI) bus is specified as 
a control bus by the MIPI CSI-2 specification. With newer version 
of the standard we may need to create a MIPI CSI (control) bus.