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

[Laurent Pinchart]

On Tue, Jul 28, 2026 at 09:13:09AM +0200, Richard Leitner wrote:
> 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!

You could also simplify it to

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

		i2c@0 {
			reg = <0>;

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

and use a single driver that registers an I2C mux (and instantiate I2C
child devices) as well as a regulator, without using the MFD framework.
That could reduce the runtime complexity, which would be nice. If you
prefer using the MFD framework with more complex bindings I'm not
opposed to it though.

> > > 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