Re: [PATCH 1/3] dt-bindings: i3c: renesas,i3c: Document analog noise filter control
From: Diogo Ivo
Date: Thu Oct 29 2026 - 05:54:41 EST
Hi Frank,
On 10/28/2026 2:46 PM, Frank Li wrote:
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.
In the end we got confirmation from the HW team that the SYS_I3C_CFG register does not actually "exist" and was unintentionally left in the HW manual, meaning that we cannot control if the filter is ON/OFF so this whole discussion and patch series becomes moot. The only patch needed on this topic is removing the SYS_I3C_CFG register definition from the SYSC driver as per the HW team's recommendation.
Sorry for the noise and thank you for the discussion and your time!
Best regards,
Diogo
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?