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

[Frank Li]

On Wed, Oct 28, 2026 at 11:10:07AM +0000, Diogo Ivo wrote:
> 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.

The location in hardware is not important. What's most consider is choose/use
which software model to descript your hardware.

> 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.

coupling pinconf and pinmux is quite common. I remember pinctrl framework
already consider that.


>
> 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.

But syscon is also not good, which basic have not any abstaction.

Frank
>
> 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?
>