Re: 回覆: [PATCH 1/8] dt-bindings: i3c: Document the AST2700 I3C controller

[Alexandre Belloni <alexandre.belloni@bootlin.com>]

On 24/09/2026 05:39:47+0000, Billy Tsai wrote:
> > I guess we need to make them generic. Probably nobody needed them yet
> > and not all the controllers will have support anyway.
> > However, I would like to make sure we get enough commonality between
> > controllers that support setting the timings individually, can you
> > check?
> 
> I went through dw-i3c-master, i3c-master-cdns, and the AMD/Xilinx AXI
> I3C driver. Every property in this set has a direct counterpart in at
> least one of them:
> 
> - Open-drain and push-pull SCL high/low: dw-i3c-master has
>   SCL_I3C_OD_TIMING/SCL_I3C_PP_TIMING (high/low count each); the
>   AMD/Xilinx driver has separate SCL high/low and OD SCL high/low
>   registers.
> - SDA/data hold time: the AMD/Xilinx driver has its own hold-time
>   register computed as a percentage of the low period; cdns has a
>   data hold delay explicitly there to meet the MIPI I3C tHD_PP
>   minimum "regardless of PCB balancing", their words for the same
>   board-variance concern we have.
> - tCAS: dw-i3c-master's own comment says its MST_FREE register
>   represents tCAS in pure I3C mode; the AMD/Xilinx driver computes an
>   explicit tCAS minimum from the spec value.
> 
> None of the three expose any of this through a DT property today.
> They either derive it purely from the bus rate, or hardcode one fixed
> value per compatible (cdns's data hold delay is a flat 10ns baked
> into its per-SoC match data, the same default we picked
> independently). So there's no existing naming convention to be
> consistent with, but the underlying quantities are clearly common
> across implementations, not something specific to our controller.
> 

Thanks for the investigation, then let's have them in i3c.yaml.

> Thanks
> Billy

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com