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

[Billy Tsai]

> > The AST2700 I3C controller implements the MIPI I3C HCI programming
> > model, extended with an ASPEED in-house control block and a PHY
> > programming window advertised through an HCI vendor extended
> > capability. Follow the existing aspeed,ast2600-i3c precedent of
> > describing SoC integrations of a common I3C IP in their own schema.

> What precedent exactly?
>
> Are you now bringing some LLM slop arguments here?

My reason for proposing a separate schema was to keep the
AST2700-specific properties (reset lines, pull-up strength, and
timing overrides) and their validation together. Extending
mipi-i3c-hci.yaml with a conditional, as was done for
microchip,sama7d65-i3c-hci, is also a possible approach, but I think
the trade-off comes down to how much AST2700-specific content would
end up in the shared file. microchip only needed one conditional
property (clocks), so folding it in barely touches the shared schema.
AST2700 needs a constrained two-entry resets/reset-names pair,
pull-up strength and eight timing overrides, which would turn into a
much larger conditional block mixed into a file every other
mipi-i3c-hci vendor also has to read.

That said, this depends on where the timing properties end up. If
they move into i3c.yaml as generic properties, per the proposal
below, what's left AST2700-specific shrinks to the reset lines and
pull-up strength, closer to the same size as microchip's single
property. At that point I'd lean towards folding AST2700 into
mipi-i3c-hci.yaml via if/then too, rather than keeping a separate
file for such a small remainder.

> > +  aspeed,pp-scl-high-ns:
> > +    description:
> > +      Push-pull SCL high period. Overrides the value derived from the
> > +      i3c-scl-hz bus rate.
[...]
> > +  aspeed,sr-p-scl-low-ns:
> > +    default: 40
> > +    description:
> > +      SCL low period used while preparing a repeated START or STOP
> > +      condition, kept separate from the push-pull SCL low period to
> > +      satisfy the MIPI I3C clock stalling requirements.

> Probably I3C maintainers should weight in here and help - should these
> be made generic for all I3C controllers? I am surprised some
> "standard" I3C controller needs to configure this as the single one.
> No other ever needed...

I considered doing this to begin with, but chose to make them vendor-specific
for the initial proposal to keep the scope small. I can make them global
properties for i3c if we get consensus.

Billy