Re: [PATCH 1/3] dt-bindings: i3c: renesas,i3c: Document analog noise filter control

[Diogo Ivo]

On 10/27/2026 2:27 PM, Frank Li wrote:
> On Tue, Oct 27, 2026 at 10:34:54AM +0000, Diogo Ivo wrote:
> > On 10/26/2026 8:33 PM, Frank Li wrote:
> > > On Mon, Oct 26, 2026 at 04:21:06PM +0000, Diogo Ivo wrote:
> > > > Hi Frank,
> > > >
> > > > On 10/20/2026 8:18 PM, Frank Li wrote:
> > > > > On Tue, Oct 20, 2026 at 10:36:26AM +0100, Diogo Ivo wrote:
> > > > > > The analog noise filter for the input terminals (I3C_SDA, I3C_SCL) of
> > > > > > the Renesas I3C controller is controlled through the SYS_I3C_CFG
> > > > > > register of the system controller. Document the
> > > > > > renesas,analog-noise-filter property, which references the system
> > > > > > controller together with the offset of the SYS_I3C_CFG register and
> > > > > > the state of the filter: 1 enables the filter and 0 bypasses it.
> > > > > >
> > > > > > The property is optional: device trees not providing it keep the
> > > > > > filter at its reset value.
> > > > > >
> > > > > > Signed-off-by: Diogo Ivo <diogo.ivo.sx@xxxxxxxxxxx>
> > > > > > ---
> > > > > >     .../devicetree/bindings/i3c/renesas,i3c.yaml          | 19 +++++++++++++++++++
> > > > > >     1 file changed, 19 insertions(+)
> > > > > >
> > > > > > diff --git a/Documentation/devicetree/bindings/i3c/renesas,i3c.yaml b/Documentation/devicetree/bindings/i3c/renesas,i3c.yaml
> > > > > > index 08fcea89a015..381807844351 100644
> > > > > > --- a/Documentation/devicetree/bindings/i3c/renesas,i3c.yaml
> > > > > > +++ b/Documentation/devicetree/bindings/i3c/renesas,i3c.yaml
> > > > > > @@ -96,6 +96,25 @@ properties:
> > > > > >           - const: presetn
> > > > > >           - const: tresetn
> > > > > >
> > > > > > +  renesas,analog-noise-filter:
> > > > > > +    $ref: /schemas/types.yaml#/definitions/phandle-array
> > > > >
> > > > > I don't like this syscon property, look like it is one kind pad propterty.
> > > > > Is it possible model as pinctrl?
> > > >
> > > > On the RZ/G3L and RZ/G3S this filter is not controlled on the pin
> > > > controller's address space but in the SYSC address space (hence the
> > > > need for the sysc phandle).
> > > >
> > > > There are a few factors weighing against modeling this as pinctrl.
> > > >
> > > > The first is that the physical pads used by I3C are multiplexed between it
> > > > and for example RIIC3, so we are not filtering the pad but the internal path
> > > > of the I3C IP. The pinctrl does indeed have some controls for the pad's
> > > > digital filters, that apply to whatever block is multiplexed to the pad.
> > > >
> > > > Besides this, even if it were moved to pinctrl we would still need the sysc
> > > > reference, as the pfc driver would need a way to reference the sysc address
> > > > space.
> > >
> > > System allows multi pinctrl devices. your syscon can work as pinctrl provider
> > >
> > > pinctrl-0 = <&your nomral pinctrl>, <&syscon i3c ... > ;
> > >
> > > The key problem is if model is resonable. Syscon is simple, but have not
> > > good abstract.
> >
> > Doing this in pinctrl is feasible, especially since the pinctrl driver on
> > G3L already has a reference to syscon for clone channels. The question
> > really is if this is what makes the most sense, as again we are not really
> > controlling an external pin but something inside the IP
> > block,
>
> I don't think so. Generally, PAD some property, like pull up/down, driver
> strength, some include glitch filter (capacitor or schmitter trigger),
>
> 'renesas,analog-noise-filter' like adjust some capacitor at PAD, only
> controler signal (register) is not in your pinctrl region.
>
> There are not analog-noise in side SOC's digtial part (Or we can't care it).
> Analog sigal generally existed in PHY and PAD.

On the RZ/G3L the analog filter is located after the pinmux, at the 
input of each I2C/I3C block. Each I2C and I3C block in G3L has a single
register bit that controls if the analog filter is enabled for that 
specific block (so we have SYS_I2C0_CFG, SYS_I2C1_CFG, ..., SYS_I3C_CFG)
each with a single bit that controls if the filter is enabled or not.

However, for the I2C blocks they can be multiplexed to dozens of pads, 
and these pads don't each contain an i2c analog filter. Rather, the 
signal passes first by the external pad and pinmux and then it reaches 
the intended I2C or I3C IP block, where the analog filter is then 
located. For example, the P2_0 and P2_1 pads can be multiplexed between 
I3C and RIIC3, and each of these blocks then has its filter at the input 
of the IP block, and a single bit in the SYS register controls the 
filter for SDA and SCL together. Then, there is the problem that if we 
model this with pinctrl with a pad property then pinconf would not know 
which block's SYS register to write without coupling to pinmux. In this 
specific case of P2_0 and P2_1 pads without coupling pinconf and pinmux 
we could not determine whether we should write to SYS_I3C_CFG or 
SYS_I2C3_CFG.

Then there is also the precedent of i2c-analog-filter being a controller 
node property rather than a pad/pinctrl property.

For these reasons I believe that pinctrl is not the best way to model 
the I2C/I3C analog filters but please do let me know your thoughts.

Geert, DT maintainers, do you have any preferences on what the best way 
to model this is?

Best regards,
Diogo


> Frank
>
> > so I'm still not fully convinced. Are there more opinions on this?