Re: [PATCH v5 7/7] media: ipu-bridge: Request non-continuous clock for ov5693 on IPU6

[D. Manresa]

Hi Fernando,

On Wed, 2 Sep 2026, Fernando Rimoli wrote:
> +	if (cfg->flags & IPU_BR_FL_CSI2_CLK_NONCONTINUOUS)
> +		sensor->ep_properties[IPU_BRIDGE_NEXT_PROPERTY(i, IPU_BRIDGE_EP_CLOCK_NONCONTINUOUS)] =
> +			PROPERTY_ENTRY_BOOL("clock-noncontinuous");

One small thing, coming from the ipu-bridge series I have under review in
parallel ("media: ipu-bridge: survive module unload and reuse the software
nodes on rebind", <20260831140304.45940-1-dmanresa@xxxxxxxxx>): the software
nodes ipu-bridge registers are deliberately never unregistered and must
survive the module being unloaded, so every string a registered property
points at has to live in the bridge's own allocation, not in the module
image. That is why the other endpoint property names all go through the
char[] members of struct ipu_property_names, copied into sensor->prop_names.

"clock-noncontinuous" above is a string literal in ipu-bridge's rodata, so
after an unload the surviving node carries a dangling property name - the
same class of problem my 1/2 fixes for the "lens-focus" literal. The fix is
one line in your design: add a `char clock_noncontinuous[sizeof("clock-
noncontinuous")]` to struct ipu_property_names, initialise it in
prop_names, and use `sensor->prop_names.clock_noncontinuous` here. I have
that variant applied locally on top of your v5 and it is what I am testing.

Two related notes:

- Your 5/7 and my 1/2 touch the same link-frequencies block in
  ipu_bridge_create_fwnode_properties(); the merge is trivial (your
  IPU_BRIDGE_NEXT_PROPERTY() indexing, my copy of cfg->link_freqs into the
  bridge allocation). Your series is further along, so I will rebase mine
  on top of yours once it is applied - no action needed on your side.

- The MIPI_CTRL00 gate supersedes the unconditional 0x4800 = 0x2d write the
  Surface Pro 7+ downstream drivers carry (mine included); Fil's Pro 8
  sweep showing bit 5 is the only one that matters agrees with everything
  I have measured here. What nobody has covered yet is bit 5 alone in the
  sensor's 2x2 binned 1296x972 readout and through the IPU6 hardware ISP
  (PSYS) path, which is how the Pro 7+ front camera is used in practice; I
  am running exactly that on this machine with your v5 (backported to a
  6.19 tree, with the downstream 0x2d write removed) and will follow up with
  a Tested-by for 4-7 covering it if it holds.

Thanks for the series - it turns a hack several of us were carrying into the
right thing.

D. Manresa <dmanresa@xxxxxxxxx>