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

[Conor Dooley]

On Tue, Jul 28, 2026 at 12:28:56PM +0300, Laurent Pinchart wrote:
> 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 prefer this version, however I think it becomes problematic because
there are different types of child nodes, Richard mentioned regulators
plural and even a single regulator I think should have a dedicated node.


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

Attachment: signature.asc
Description: PGP signature