[PATCH v21 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs and transfer-mode properties

[Ryan Chen]

> Subject: Re: [PATCH v21 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs
> and transfer-mode properties
> 
> On 30/10/2025 02:48, Ryan Chen wrote:
> >> Subject: Re: [PATCH v21 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add
> >> global-regs and transfer-mode properties
> >>
> >> On 29/10/2025 10:25, Ryan Chen wrote:
> >>>> Subject: Re: [PATCH v21 2/4] dt-bindings: i2c: ast2600-i2c.yaml:
> >>>> Add global-regs and transfer-mode properties
> >>>>
> >>>> On 27/10/2025 07:12, Ryan Chen wrote:
> >>>>> The AST2600 I2C controller supports three transfer modes: byte,
> >>>>> buffer, and DMA. To allow board designers and firmware to
> >>>>> explicitly select the preferred transfer mode for each controller
> instance.
> >>>>> "aspeed,transfer-mode" to allow device tree to specify the desired
> >>>>> transfer method used by each I2C controller instance.
> >>>>>
> >>>>> And AST2600 i2c controller have two register mode, one is legacy
> >>>>> register layout which is mix controller/target register control
> >>>>> together, another is new mode which is separate controller/target
> >>>>> register control.
> >>>>>
> >>>>
> >>>> This implies your "reg" properties have now completely different
> >>>> meaning and this would be quite an ABI break. We discussed this
> >>>> probably
> >> 15 revisions ago.
> >>>> Where did you document the resolution of that discussion?
> >>>
> >>> Let me explain more about "reg"
> >>> The 'reg' property continues to describe the same register regions
> >>> (bus and buffer) as in the legacy layout. The selection between the
> >>> legacy and new register layout is controlled by a bit in the
> >>> SoC-level global register block, referenced through the new
> 'aspeed,global-regs'
> >> property.
> >>> Therefore, the meaning of the 'reg' property does not change and no
> >>> DT ABI break occurs.
> >>>
> >>> Should I add it in commit message about "reg" ?
> >>
> >> Then why does the address change from 0x40 to 0x80. If it is the
> >> same, it cannot change.
> >>
> >> You are describing the IO address space, total address space, as
> >> defined by datasheet. Not whatever is in the driver.
> >
> > Thanks for pointing that out.
> >
> > But to clarify: the address change from 0x40 to 0x80 in the example is
> > not arbitrary. It comes directly from the AST2600 SoC datasheet, where
> > the
> 
> How so? Binding has an example for ast2600 with address 0x40. You now claim
> the change is to adjust to ast2600. But it is ALREADY ast2600!
> 
Understood, I will keep the address.

And I can fix in previous split ast2600-i2c.yaml patch. am I right?

> 
> Best regards,
> Krzysztof