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

[Richard Leitner]

On Fri, Jul 24, 2026 at 12:28:12PM +0300, Laurent Pinchart wrote:
> On Thu, Jul 23, 2026 at 08:55:18PM +0200, Richard Leitner 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.
> > 
> > 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'm afraid I won't have time for the time being, as I will soon start my
> summer holidays. The patches in the git tree you mentioned are all I
> have.

Ok. Thanks. Then I will give it a try.

I did some more research on that module and it features a Lattice FPGA
(LCMXO3LF-1300E) which to all of my measurement intercepts the I2C bus
as expected.

As it additionally manages the regulators my approach would be to
implement a Multi-Function Devices (MFD) driver for it.

The resulting DTS layout would then be something like:

&i2c1 {
	fpga@10 {
		compatible = "visioncomponents,vc-mipi-controller";
		reg = <0x10>;

		i2c-mux {
			compatible = "visioncomponents,vc-mipi-i2c-mux";

			i2c@0 {
				reg = <0>;

				ov9282: camera-sensor@60 {
					compatible = "ovti,ov9282";
					reg = <0x60>;
					...
				};
			};
		};

		vc_mipi_reg: regulator {
			compatible = "visioncomponents,vc-mipi-regulator";
		};
	};
};

Mark, Laurent, if that's incorrect or otherwise not acceptable,
please reach out. Thanks a lot!

regards;rl

> 
> > 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,
> 
> Laurent Pinchart