I2C dummy adapter driver ?

Mark Brown broonie at kernel.org
Tue Mar 4 20:15:30 EST 2014


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>


More information about the linux-arm-kernel mailing list