Re: [PATCH 2/2] media: ov9282: enable single-read I2C transactions

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Richard,

On Tue, Jul 21, 2026 at 05:15:06PM +0200, Richard Leitner wrote:
> On Tue, Jul 21, 2026 at 03:38:26PM +0200, Alexander Stein wrote:
> > Am Dienstag, 21. Juli 2026, 15:25:29 CEST schrieb Richard Leitner:
> > > Some OV9282 camera modules, such as those from Vision Components, fail
> > > multi-byte register reads with the default CCI I2C regmap access pattern
> > > and only work when single-register read transactions are used. This
> > > results in the driver being unable to probe due to a chip id mismatch.
> > > 
> > > As the driver has no reliable way to identify affected modules enable
> > > use_single_read for OV9282 unconditionally when creating the CCI regmap.
> > 
> > What about a property in the DT instead? In DT it should be clear if a
> > Vision Components camera is used.
> 
> I've talked to Laurent about this topic (I guess a year ago or so...)
> and he pointed me to his downstream work regarding the vc-mipi driver
> (which I am currently also using):
> 
> https://gitlab.com/ideasonboard/nxp/linux/-/commits/v7.0/sensors/vcmipi
> 
> There is a new driver (and therefore DT compatible) for the controller
> (without the sensor) on the Vision Components board implemented. This
> separates basically the "regulator" part of the VC microprocessor from
> the "forward I2C traffic to the sensor" part. AFAICT...
> 
> Talking about that separation I vaguely remember he argued against a
> new device-tree property or compatible for the vcmipi variants of the
> ov9282. Therefore I went for the "easy" approach of just enabling single
> register reads.
> 
> Nonetheless if I understood this wrong or "things" changed, please feel
> free to correct me.
> 
> Just to be clear: I'm also perfectly fine with introducing a new
> "vcmipi,ov9282" compatible or something like a "quirk-vision-components"
> property if that's preferred.

My main concern is that I don't want to see this being handled manually
in drivers. Whatever solution we decide to implement (I proposed two in
a separate e-mail in this thread) should not require modifying image
sensor drivers to implement logic specific to the Vision Components
module. I'm fine relying on drivers using specific helpers (for instance
requiring drivers to be ported to regmap or v4l2-cci in order to support
the quirk).

> > > Tested on an i.M8MP system with OV9282 modules from Vision Components.
> > > 
> > > Signed-off-by: Richard Leitner <richard.leitner@linux.dev>
> > > ---
> > >  drivers/media/i2c/ov9282.c | 7 ++++++-
> > >  1 file changed, 6 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/media/i2c/ov9282.c b/drivers/media/i2c/ov9282.c
> > > index 5b6f897a74fcd..8267a0a9c6f2d 100644
> > > --- a/drivers/media/i2c/ov9282.c
> > > +++ b/drivers/media/i2c/ov9282.c
> > > @@ -1283,6 +1283,11 @@ static int ov9282_probe(struct i2c_client *client)
> > >  	struct ov9282 *ov9282;
> > >  	int ret;
> > >  
> > > +	const struct cci_regmap_config config = {
> > > +		.reg_addr_bits = 16,
> > > +		.use_single_read = true,
> > > +	};
> > > +
> > >  	ov9282 = devm_kzalloc(&client->dev, sizeof(*ov9282), GFP_KERNEL);
> > >  	if (!ov9282)
> > >  		return -ENOMEM;
> > > @@ -1301,7 +1306,7 @@ static int ov9282_probe(struct i2c_client *client)
> > >  		return ret;
> > >  	}
> > >  
> > > -	ov9282->regmap = devm_cci_regmap_init_i2c(client, 16);
> > > +	ov9282->regmap = devm_cci_regmap_init_i2c_cfg(client, &config);
> > >  	if (IS_ERR(ov9282->regmap))
> > >  		return dev_err_probe(ov9282->dev, PTR_ERR(ov9282->regmap),
> > >  				     "Failed to init CCI\n");

-- 
Regards,

Laurent Pinchart