Re: [PATCH 1/3] dt-bindings: i3c: renesas,i3c: Document analog noise filter control
From: Diogo Ivo
Date: Tue Oct 27 2026 - 06:36:32 EST
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, so I'm still not fully convinced. Are there more opinions on this?
Thanks,
Diogo
Frank
With this, I think that having a DT property is the best approach. However,
the form of the property can be changed if you are against this particular
one. For example, the register offset can be moved to platform_data in the
I3C driver:
- renesas,analog-noise-filter = <&sysc 0/1> at the SoC level
or I can also split it into two properties.
What approach would work better here? Me I'm leaning towards having
renesas,analog-digital-filter.
Best regards,
Diogo
Frank
+ description:
+ Analog noise filter for the I3C input signals (I3C_SDA, I3C_SCL),
+ controlled through the SYS_I3C_CFG register of the system
+ controller (SYSC). Three entries specifying the system controller,
+ the offset of the SYS_I3C_CFG register and the state of the filter.
+ If not present, the filter keeps its reset state.
+ items:
+ - items:
+ - description: phandle to the system controller node
+ - description: offset of the SYS_I3C_CFG register within the SYSC
+ - enum: [0, 1]
+ description: |
+ state of the analog noise filter:
+ - 1: enable the filter, performing noise reduction on the
+ I3C_SDA and I3C_SCL input signals
+ - 0: bypass the filter
+
required:
- compatible
- reg
--
2.56.0