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

Robby Cai
2026-04-30T07:32:26Z

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 …