Re: [PATCH RFC 1/2] dt-bindings: regmap: add common schema for no-sequential-read

Re: [PATCH RFC 1/2] dt-bindings: regmap: add common schema for no-sequential-read

[Mark Brown]

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

On Wed, Jul 22, 2026 at 10:42:46AM +0200, Richard Leitner wrote:
> Introduce a common regmap dt-binding schema with an optional boolean
> property no-sequential-read to describe hardware integrations where
> reading multiple consecutive registers in a single operation is not
> reliable and registers must be read individually.

> A typical case are imaging sensors used on vendor-provided camera
> modules whose bus integration does not support reads that advance across
> consecutive register addresses. In such cases, single-register reads
> work, but bulk reads do not. This restriction is a property of the
> concrete hardware integration, not of the chip itself. It therefore
> cannot be identified from the device driver and duplicating firmware
> parsing in each affected driver does not scale.

No, this should not be a DT property.  We should discover this through
the bus, just like we do currently for the various I2C quirks that are
advertied by the I2C subsystem.

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

Re: [PATCH RFC 1/2] dt-bindings: regmap: add common schema for no-sequential-read

[Richard Leitner]

Hi Mark,

thanks the quick feedback.

On Wed, Jul 22, 2026 at 02:59:12PM +0100, Mark Brown wrote:
> On Wed, Jul 22, 2026 at 10:42:46AM +0200, Richard Leitner wrote:
> > Introduce a common regmap dt-binding schema with an optional boolean
> > property no-sequential-read to describe hardware integrations where
> > reading multiple consecutive registers in a single operation is not
> > reliable and registers must be read individually.
> 
> > A typical case are imaging sensors used on vendor-provided camera
> > modules whose bus integration does not support reads that advance across
> > consecutive register addresses. In such cases, single-register reads
> > work, but bulk reads do not. This restriction is a property of the
> > concrete hardware integration, not of the chip itself. It therefore
> > cannot be identified from the device driver and duplicating firmware
> > parsing in each affected driver does not scale.
> 
> No, this should not be a DT property.  We should discover this through
> the bus, just like we do currently for the various I2C quirks that are
> advertied by the I2C subsystem.

What do you mean "discover this through the bus"? As mentioned in the
commit message there is no possibility to detect that within the affected
I2C device drivers.

Or do you mean that it should be "discovered" by modelling the MCU which
"proxies" the I2C traffic between the host and the sensor/device as some
kind of "parent" device of the sensor?

Or something other?

Sorry, if I don't get it, but currently I see no other option than
providing this information somehow via device-tree. No matter if it's in
regmap or I2C.

thanks & regards;rl

Re: [PATCH RFC 1/2] dt-bindings: regmap: add common schema for no-sequential-read

[Laurent Pinchart]

On Wed, Jul 22, 2026 at 08:24:37PM +0200, Richard Leitner wrote:
> On Wed, Jul 22, 2026 at 02:59:12PM +0100, Mark Brown wrote:
> > On Wed, Jul 22, 2026 at 10:42:46AM +0200, Richard Leitner wrote:
> > > Introduce a common regmap dt-binding schema with an optional boolean
> > > property no-sequential-read to describe hardware integrations where
> > > reading multiple consecutive registers in a single operation is not
> > > reliable and registers must be read individually.
> > 
> > > A typical case are imaging sensors used on vendor-provided camera
> > > modules whose bus integration does not support reads that advance across
> > > consecutive register addresses. In such cases, single-register reads
> > > work, but bulk reads do not. This restriction is a property of the
> > > concrete hardware integration, not of the chip itself. It therefore
> > > cannot be identified from the device driver and duplicating firmware
> > > parsing in each affected driver does not scale.
> > 
> > No, this should not be a DT property.  We should discover this through
> > the bus, just like we do currently for the various I2C quirks that are
> > advertied by the I2C subsystem.
> 
> What do you mean "discover this through the bus"? As mentioned in the
> commit message there is no possibility to detect that within the affected
> I2C device drivers.
> 
> Or do you mean that it should be "discovered" by modelling the MCU which
> "proxies" the I2C traffic between the host and the sensor/device as some
> kind of "parent" device of the sensor?

Mark's comment wasn't totally clear to me. I think this is what he
meant.

Richard, do you know if the MCU (which is actually an FPGA if I'm not
mistaken) intercepts the I2C signals (i.e. is interposed between the
host and the image sensor), or is "just" connected on the same I2C bus
and messes up the I2C transfer when it detects a condition it dislikes
(for instance by pulling the SDA line down when it detects a read from a
protected register) ?

> Or something other?
> 
> Sorry, if I don't get it, but currently I see no other option than
> providing this information somehow via device-tree. No matter if it's in
> regmap or I2C.

-- 
Regards,

Laurent Pinchart

Re: [PATCH RFC 1/2] dt-bindings: regmap: add common schema for no-sequential-read

[Richard Leitner]

On Wed, Jul 22, 2026 at 11:16:22PM +0300, Laurent Pinchart wrote:
> On Wed, Jul 22, 2026 at 08:24:37PM +0200, Richard Leitner wrote:
> > On Wed, Jul 22, 2026 at 02:59:12PM +0100, Mark Brown wrote:
> > > On Wed, Jul 22, 2026 at 10:42:46AM +0200, Richard Leitner wrote:
> > > > Introduce a common regmap dt-binding schema with an optional boolean
> > > > property no-sequential-read to describe hardware integrations where
> > > > reading multiple consecutive registers in a single operation is not
> > > > reliable and registers must be read individually.
> > > 
> > > > A typical case are imaging sensors used on vendor-provided camera
> > > > modules whose bus integration does not support reads that advance across
> > > > consecutive register addresses. In such cases, single-register reads
> > > > work, but bulk reads do not. This restriction is a property of the
> > > > concrete hardware integration, not of the chip itself. It therefore
> > > > cannot be identified from the device driver and duplicating firmware
> > > > parsing in each affected driver does not scale.
> > > 
> > > No, this should not be a DT property.  We should discover this through
> > > the bus, just like we do currently for the various I2C quirks that are
> > > advertied by the I2C subsystem.
> > 
> > What do you mean "discover this through the bus"? As mentioned in the
> > commit message there is no possibility to detect that within the affected
> > I2C device drivers.
> > 
> > Or do you mean that it should be "discovered" by modelling the MCU which
> > "proxies" the I2C traffic between the host and the sensor/device as some
> > kind of "parent" device of the sensor?
> 
> Mark's comment wasn't totally clear to me. I think this is what he
> meant.
> 
> Richard, do you know if the MCU (which is actually an FPGA if I'm not
> mistaken) intercepts the I2C signals (i.e. is interposed between the
> host and the image sensor), or is "just" connected on the same I2C bus
> and messes up the I2C transfer when it detects a condition it dislikes
> (for instance by pulling the SDA line down when it detects a read from a
> protected register) ?

Tbh. I don't know. The VC MIPI Camera Module Hardware Operating manual
suggests both, the controller and the sensor sit on the same I2C bus:

https://www.mipi-modules.com/fileadmin/external/documentation/hardware/VC_MIPI_Camera_Module/index.html#mipi-sensor-module-circuit

But that's just a block diagram and nothing is written down really.

I tried some reverse-engineering and probed most of the accessible pads
of the camera module with my scope. I found no evidence that there is "a
second I2C bus" with "delayed" signals as I would suspect if the FPGA
really intercepts the I2C traffic.

Nonetheless this is by far no proof that this isn't the case, as the I2C
lanes of the imaging sensor are not accessible without destroying the PCB
:-(

So any help/feedback/information is greatly appreciated.


@Mark: I understood that if the fpga really intercepts the I2C bus, it
should be modelled accordingly in device tree. But what would be the
preferred implementation if both devices sit on the same I2C bus, but
one is messing up some register reads on purpose?

thanks & regards;rl

> 
> > Or something other?
> > 
> > Sorry, if I don't get it, but currently I see no other option than
> > providing this information somehow via device-tree. No matter if it's in
> > regmap or I2C.
> 
> -- 
> Regards,
> 
> Laurent Pinchart

Re: [PATCH RFC 1/2] dt-bindings: regmap: add common schema for no-sequential-read

[Mark Brown]

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

On Wed, Jul 22, 2026 at 11:58:46PM +0200, Richard Leitner wrote:

> @Mark: I understood that if the fpga really intercepts the I2C bus, it
> should be modelled accordingly in device tree. But what would be the
> preferred implementation if both devices sit on the same I2C bus, but
> one is messing up some register reads on purpose?

I think we would need to have a coherent understanding and description
of the actual issue to know how to describe it.

Please do not add random characters to my name.

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

Re: [PATCH RFC 1/2] dt-bindings: regmap: add common schema for no-sequential-read

[Laurent Pinchart]

On Thu, Jul 23, 2026 at 01:01:11PM +0200, Richard Leitner wrote:
> On Wed, Jul 22, 2026 at 11:03:09PM +0100, Mark Brown wrote:
> > On Wed, Jul 22, 2026 at 11:58:46PM +0200, Richard Leitner wrote:
> > 
> > > @Mark: I understood that if the fpga really intercepts the I2C bus, it
> > > should be modelled accordingly in device tree. But what would be the
> > > preferred implementation if both devices sit on the same I2C bus, but
> > > one is messing up some register reads on purpose?
> > 
> > I think we would need to have a coherent understanding and description
> > of the actual issue to know how to describe it.
> 
> Understood. I will try to figure out how the hardware is really wired
> and come back to you.

Based on the information I have received so far, the FPGA is interposed
between the host and sensor. It could therefore be modelled in DT as
child of the I2C bus and a parent of the sensor.

New version of some of the Vision Components modules have fixed the
multi-read bug, so we will still need a property in the FPGA DT node to
indicate if the quirk should be activated.

> > Please do not add random characters to my name.
> 
> Sorry, I didn’t mean any harm.

-- 
Regards,

Laurent Pinchart

Re: [PATCH RFC 1/2] dt-bindings: regmap: add common schema for no-sequential-read

[Conor Dooley]

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

On Thu, Jul 23, 2026 at 06:45:41PM +0300, Laurent Pinchart wrote:
> On Thu, Jul 23, 2026 at 01:01:11PM +0200, Richard Leitner wrote:
> > On Wed, Jul 22, 2026 at 11:03:09PM +0100, Mark Brown wrote:
> > > On Wed, Jul 22, 2026 at 11:58:46PM +0200, Richard Leitner wrote:
> > > 
> > > > @Mark: I understood that if the fpga really intercepts the I2C bus, it
> > > > should be modelled accordingly in device tree. But what would be the
> > > > preferred implementation if both devices sit on the same I2C bus, but
> > > > one is messing up some register reads on purpose?
> > > 
> > > I think we would need to have a coherent understanding and description
> > > of the actual issue to know how to describe it.
> > 
> > Understood. I will try to figure out how the hardware is really wired
> > and come back to you.
> 
> Based on the information I have received so far, the FPGA is interposed
> between the host and sensor. It could therefore be modelled in DT as
> child of the I2C bus and a parent of the sensor.
> 
> New version of some of the Vision Components modules have fixed the
> multi-read bug, so we will still need a property in the FPGA DT node to
> indicate if the quirk should be activated.

Or come up with a compatible for the FPGA DT node that uniquely
identifies the revision of the RTL in use.
That's my preference for things that use some custom RTL that aren't
configuration parameters.

> 
> > > Please do not add random characters to my name.
> > 
> > Sorry, I didn’t mean any harm.
> 
> -- 
> Regards,
> 
> Laurent Pinchart

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

Re: [PATCH RFC 1/2] dt-bindings: regmap: add common schema for no-sequential-read

[Laurent Pinchart]

On Thu, Jul 23, 2026 at 05:02:42PM +0100, Conor Dooley wrote:
> On Thu, Jul 23, 2026 at 06:45:41PM +0300, Laurent Pinchart wrote:
> > On Thu, Jul 23, 2026 at 01:01:11PM +0200, Richard Leitner wrote:
> > > On Wed, Jul 22, 2026 at 11:03:09PM +0100, Mark Brown wrote:
> > > > On Wed, Jul 22, 2026 at 11:58:46PM +0200, Richard Leitner wrote:
> > > > 
> > > > > @Mark: I understood that if the fpga really intercepts the I2C bus, it
> > > > > should be modelled accordingly in device tree. But what would be the
> > > > > preferred implementation if both devices sit on the same I2C bus, but
> > > > > one is messing up some register reads on purpose?
> > > > 
> > > > I think we would need to have a coherent understanding and description
> > > > of the actual issue to know how to describe it.
> > > 
> > > Understood. I will try to figure out how the hardware is really wired
> > > and come back to you.
> > 
> > Based on the information I have received so far, the FPGA is interposed
> > between the host and sensor. It could therefore be modelled in DT as
> > child of the I2C bus and a parent of the sensor.
> > 
> > New version of some of the Vision Components modules have fixed the
> > multi-read bug, so we will still need a property in the FPGA DT node to
> > indicate if the quirk should be activated.
> 
> Or come up with a compatible for the FPGA DT node that uniquely
> identifies the revision of the RTL in use.
> That's my preference for things that use some custom RTL that aren't
> configuration parameters.

I'm afraid we won't be able to get that information. We have limited
visibility on the ecosystem of modules and what the FPGA does in each of
them.

> > > > Please do not add random characters to my name.
> > > 
> > > Sorry, I didn’t mean any harm.

-- 
Regards,

Laurent Pinchart

Re: [PATCH RFC 1/2] dt-bindings: regmap: add common schema for no-sequential-read

[Conor Dooley]

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

On Thu, Jul 23, 2026 at 07:10:48PM +0300, Laurent Pinchart wrote:
> On Thu, Jul 23, 2026 at 05:02:42PM +0100, Conor Dooley wrote:
> > On Thu, Jul 23, 2026 at 06:45:41PM +0300, Laurent Pinchart wrote:
> > > On Thu, Jul 23, 2026 at 01:01:11PM +0200, Richard Leitner wrote:
> > > > On Wed, Jul 22, 2026 at 11:03:09PM +0100, Mark Brown wrote:
> > > > > On Wed, Jul 22, 2026 at 11:58:46PM +0200, Richard Leitner wrote:
> > > > > 
> > > > > > @Mark: I understood that if the fpga really intercepts the I2C bus, it
> > > > > > should be modelled accordingly in device tree. But what would be the
> > > > > > preferred implementation if both devices sit on the same I2C bus, but
> > > > > > one is messing up some register reads on purpose?
> > > > > 
> > > > > I think we would need to have a coherent understanding and description
> > > > > of the actual issue to know how to describe it.
> > > > 
> > > > Understood. I will try to figure out how the hardware is really wired
> > > > and come back to you.
> > > 
> > > Based on the information I have received so far, the FPGA is interposed
> > > between the host and sensor. It could therefore be modelled in DT as
> > > child of the I2C bus and a parent of the sensor.
> > > 
> > > New version of some of the Vision Components modules have fixed the
> > > multi-read bug, so we will still need a property in the FPGA DT node to
> > > indicate if the quirk should be activated.
> > 
> > Or come up with a compatible for the FPGA DT node that uniquely
> > identifies the revision of the RTL in use.
> > That's my preference for things that use some custom RTL that aren't
> > configuration parameters.
> 
> I'm afraid we won't be able to get that information. We have limited
> visibility on the ecosystem of modules and what the FPGA does in each of
> them.

Oh well, I tried..

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

Re: [PATCH RFC 1/2] dt-bindings: regmap: add common schema for no-sequential-read

[Laurent Pinchart]

On Thu, Jul 23, 2026 at 05:31:25PM +0100, Conor Dooley wrote:
> On Thu, Jul 23, 2026 at 07:10:48PM +0300, Laurent Pinchart wrote:
> > On Thu, Jul 23, 2026 at 05:02:42PM +0100, Conor Dooley wrote:
> > > On Thu, Jul 23, 2026 at 06:45:41PM +0300, Laurent Pinchart wrote:
> > > > On Thu, Jul 23, 2026 at 01:01:11PM +0200, Richard Leitner wrote:
> > > > > On Wed, Jul 22, 2026 at 11:03:09PM +0100, Mark Brown wrote:
> > > > > > On Wed, Jul 22, 2026 at 11:58:46PM +0200, Richard Leitner wrote:
> > > > > > 
> > > > > > > @Mark: I understood that if the fpga really intercepts the I2C bus, it
> > > > > > > should be modelled accordingly in device tree. But what would be the
> > > > > > > preferred implementation if both devices sit on the same I2C bus, but
> > > > > > > one is messing up some register reads on purpose?
> > > > > > 
> > > > > > I think we would need to have a coherent understanding and description
> > > > > > of the actual issue to know how to describe it.
> > > > > 
> > > > > Understood. I will try to figure out how the hardware is really wired
> > > > > and come back to you.
> > > > 
> > > > Based on the information I have received so far, the FPGA is interposed
> > > > between the host and sensor. It could therefore be modelled in DT as
> > > > child of the I2C bus and a parent of the sensor.
> > > > 
> > > > New version of some of the Vision Components modules have fixed the
> > > > multi-read bug, so we will still need a property in the FPGA DT node to
> > > > indicate if the quirk should be activated.
> > > 
> > > Or come up with a compatible for the FPGA DT node that uniquely
> > > identifies the revision of the RTL in use.
> > > That's my preference for things that use some custom RTL that aren't
> > > configuration parameters.
> > 
> > I'm afraid we won't be able to get that information. We have limited
> > visibility on the ecosystem of modules and what the FPGA does in each of
> > them.
> 
> Oh well, I tried..

Let's look at the bright side: the vendor has fixed the issue after we
reported them, so DT for newer modules will be better :-)

-- 
Regards,

Laurent Pinchart

Re: [PATCH RFC 1/2] dt-bindings: regmap: add common schema for no-sequential-read

[Richard Leitner]

On Thu, Jul 23, 2026 at 07:10:48PM +0300, Laurent Pinchart wrote:
> On Thu, Jul 23, 2026 at 05:02:42PM +0100, Conor Dooley wrote:
> > On Thu, Jul 23, 2026 at 06:45:41PM +0300, Laurent Pinchart wrote:
> > > On Thu, Jul 23, 2026 at 01:01:11PM +0200, Richard Leitner wrote:
> > > > On Wed, Jul 22, 2026 at 11:03:09PM +0100, Mark Brown wrote:
> > > > > On Wed, Jul 22, 2026 at 11:58:46PM +0200, Richard Leitner wrote:
> > > > > 
> > > > > > @Mark: I understood that if the fpga really intercepts the I2C bus, it
> > > > > > should be modelled accordingly in device tree. But what would be the
> > > > > > preferred implementation if both devices sit on the same I2C bus, but
> > > > > > one is messing up some register reads on purpose?
> > > > > 
> > > > > I think we would need to have a coherent understanding and description
> > > > > of the actual issue to know how to describe it.
> > > > 
> > > > Understood. I will try to figure out how the hardware is really wired
> > > > and come back to you.
> > > 
> > > Based on the information I have received so far, the FPGA is interposed
> > > between the host and sensor. It could therefore be modelled in DT as
> > > child of the I2C bus and a parent of the sensor.
> > > 
> > > New version of some of the Vision Components modules have fixed the
> > > multi-read bug, so we will still need a property in the FPGA DT node to
> > > indicate if the quirk should be activated.
> > 
> > Or come up with a compatible for the FPGA DT node that uniquely
> > identifies the revision of the RTL in use.
> > That's my preference for things that use some custom RTL that aren't
> > configuration parameters.
> 
> I'm afraid we won't be able to get that information. We have limited
> visibility on the ecosystem of modules and what the FPGA does in each of
> them.

Thanks for the clarification. Should I continue working on this topic
(i.e. modelling the FPGA as I2C controller with the sensor as a
"subdevice")? Or do you want to take over Laurent? Do you have any other
downstream work on the vc-mipi stuff, except the patches in your gitlab
repo?

I've additionally wrote "my Vision Components contact" an email asking
for clarification of the I2C bus layout on the modules yesterday. If I
get any new information from that path I will of course take it into account.

Thanks a lot, Laurent!

regards;rl

Re: [PATCH RFC 1/2] dt-bindings: regmap: add common schema for no-sequential-read

[Mark Brown]

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

On Wed, Jul 22, 2026 at 08:24:37PM +0200, Richard Leitner wrote:
> On Wed, Jul 22, 2026 at 02:59:12PM +0100, Mark Brown wrote:

> > No, this should not be a DT property.  We should discover this through
> > the bus, just like we do currently for the various I2C quirks that are
> > advertied by the I2C subsystem.

> What do you mean "discover this through the bus"? As mentioned in the
> commit message there is no possibility to detect that within the affected
> I2C device drivers.

> Or do you mean that it should be "discovered" by modelling the MCU which
> "proxies" the I2C traffic between the host and the sensor/device as some
> kind of "parent" device of the sensor?

If there is hardware there that rewrites the traffic then obviously that
hardware should be described in the device tree, yes.  It sounds like
this is the actual I2C controller and is what is imposing the limits.

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