Re: [PATCH 6/8] arm64: dts: freescale: imx8mm-verdin: Add Toradex OV5640 CSI Cameras

[Ernest Van Hoecke]

On Wed, Jul 22, 2026 at 09:43:37AM -0500, Frank Li wrote:
> On Wed, Jul 22, 2026 at 12:59:14PM +0200, Francesco Dolcini wrote:
> > Hello Kieran,
> >
> > On Wed, Jul 22, 2026 at 11:30:29AM +0100, Kieran Bingham wrote:
> > > Quoting Ernest Van Hoecke (2026-07-22 10:27:32)
> > > > On Mon, Jul 20, 2026 at 02:16:46PM -0400, Frank Li wrote:
> > > > > On Mon, Jul 13, 2026 at 05:06:27PM +0200, Ernest Van Hoecke wrote:
> > > > > > From: Ernest Van Hoecke <ernest.vanhoecke@xxxxxxxxxxx>
> > > > > >
> > > > > > Add device tree overlays for the Toradex OV5640 CSI Camera on Verdin CSI_1.
> > > > > >
> > > > > > The default overlay describes the current CSI Camera Set 5MP OV5640 with a
> > > > > > 27 MHz on-board oscillator. Add a separate 24 MHz overlay for the legacy
> > > > > > camera module.
> > > > > >
> > > > > > Link: https://developer.toradex.com/hardware/accessories/cameras/csi-camera-module-5mp-ov5640-arducam
> > > > > > Link: https://www.toradex.com/accessories/csi-camera-ov5640
> > > > > > Link: https://developer.toradex.com/hardware/legacy-products/other/csi-camera-module-5mp-ov5640/
> > > > > > Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@xxxxxxxxxxx>
> > > > > > ---
> > > > > >  arch/arm64/boot/dts/freescale/Makefile             |  6 ++
> > > > > >  .../dts/freescale/imx8mm-verdin-ov5640-24mhz.dtso  | 17 +++++
> > > > > >  .../boot/dts/freescale/imx8mm-verdin-ov5640.dtsi   | 78 ++++++++++++++++++++++
> > > > > >  .../boot/dts/freescale/imx8mm-verdin-ov5640.dtso   | 18 +++++
> > > > > >  4 files changed, 119 insertions(+)
> > ...
> > > I think with the Toradex ecosystem there would be some value in
> > > supporting or helping with the ongoing dt-connectors or dt-addons topics
> > > so that we can abstract the hardware which is being 'added'.
> > >
> > > I think it's important that we tackle the problem of combinatorial
> > > explosions of overlays when we can add a component to multiple
> > > platforms.
> > >
> > > For example, your OV5640 camera could be added to many different boards
> > > - and each board could have many different cameras - in different ports.
> > >
> > > We should not be copy/pasting overlays for each combination, or we'll
> > > have 'thousands' of identical overlays.
> >
> > I see your point, and I agree that it would be valuable to move this
> > topic forward. I will raise it internally at Toradex and see how we can
> > contribute.
> >
> > At the same time, quoting Marex (https://lore.kernel.org/all/dec2a7f6-80fd-4692-8936-969f8837a555@xxxxxxxxxxxx/):
> >
> >  | DT connectors have been discussed for the last 10 or so years and three
> >  | is still no real progress.
> >  |
> >  | I would be happy to send a follow up patchset which would convert the
> >  | DTOs to whatever connector implementation format lands in the future,
> >  | but I am concerned that waiting for DT connectors will block this
> >  | patchset from landing for a long time.
> >
> 
> I do quick check for ov5640, we can use partial connectors, which already
> in kernel tree.
> 
> use duplicate label like
> 
> in mainboard
> csi_io_i2c: &i2c3 {
> 	...
> }
> 
> csi_io_regualotor_3v3: ....
> 
> 
> csi_io: connector_csi {
> 	compatible = "...";
> 	gpio-map = <0 0 &gpio1 3 3>;
> 	...
> 	irq-map =<0 &gpio1 4 1>;
> 	...
> }
> 
> in 5640 overlay
> 
> &csi_io_i2c {
> 	camera@xx {
> 
> 		reset-gpios = <&csi_io 0 ACTIVE_HIGHT>;
> 	}
> }
> 
> https://lore.kernel.org/imx/AM9PR04MB8353AC7DF91C5F73C34019E0E3F72@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
> 
> Only clock part have dependence. other parts. I am working mipi dsi for
> display, almost work except panel show have some problem, which is not
> related with connector.
> 
> Frank

This is very interesting and I agree with both you and Kieran that it
would be great to abstract these connections away and kill the need for
so many variations.

Certainly I will read up on this and spread it internally as well.

That said, since there are still unresolved dependencies, I am not
convinced that we should already head this way with this series. It
supports hardware that exists today in the currently standard and clean
way.

Can we consider moving to this once these patches are merged and we see
benefit?

Kind regards,
Ernest