Re: [PATCH 1/2] arm64: dts: imx8mq: Correct MIPI CSI clocks

[Robby Cai <robby.cai@nxp.com>]

On Sat, Apr 18, 2026 at 03:12:24AM +0200, Sebastian Krzyszkowiak wrote:
> On piątek, 17 kwietnia 2026 13:01:59 czas środkowoeuropejski letni Robby Cai 
> wrote:
> > CSI capture may intermittently fail due to mismatched clock rates. The
> > previous configuration violated the timing requirement stated in the
> > i.MX8MQ Reference Manual:
> > 
> >   "The frequency of clk must be exactly equal to or greater than the RX
> >    byte clock coming from the RX DPHY."
> > 
> > Update the clock configuration to ensure that the CSI core clock rate is
> > equal to or greater than the incoming DPHY byte clock. The updated clock
> > ratios are consistent with those used in NXP's downstream BSP.
> 
> I believe this is a misreading of the docs.
> 
> IMX8MQ_CLK_CSIX_PHY_REF refers to the UI pixel clock (clk_ui), not the RX DPHY 
> byte clock. All this change would do is to break streaming with more than 100 
> Mpixels per second / 1064 Mbps per MIPI lane.
> 
> As mentioned in the reference manual:
> 
> "The frequency of clk_ui must be such that the data received on the data_out 
> output is greater than or equal to the total bandwidth of the physical MIPI 
> interface. Clk_ui has no relationship requirement with regards to ‘clk’ other 
> than the bandwidth requirement mentioned previously."
> 

You are right — thank you for the detailed clarification.

Given this, the commit message and the rationale behind this change are
incorrect, and the current patch could indeed break higher-bandwidth streaming
use cases. Thank you for catching this.

I will revisit the clock assumptions and drop or rework this change based
strictly on the documented bandwidth requirements in the next revision.

Regards,
Robby

[...]