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

[Frank Li]

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.

Frank

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