From: Diogo Ivo <diogo.ivo.sx@renesas.com>
To: Frank Li <Frank.li@oss.nxp.com>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>,
Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
Frank Li <Frank.Li@nxp.com>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Magnus Damm <magnus.damm@gmail.com>,
linux-i3c@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
Linus Walleij <linusw@kernel.org>
Subject: Re: [PATCH 1/3] dt-bindings: i3c: renesas,i3c: Document analog noise filter control
Date: Tue, 27 Oct 2026 10:34:54 +0000 [thread overview]
Message-ID: <f4b8a714-dab8-45d4-b98f-717d010806de@renesas.com> (raw)
In-Reply-To: <at-5E3b_wKcnuJ9Z@lizhi-Precision-Tower-5810>
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@renesas.com>
>>>> ---
>>>> .../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
>>>>
>>
next prev parent reply other threads:[~2026-10-27 10:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-20 9:36 [PATCH 0/3] i3c: renesas: Add support for the analog noise filter Diogo Ivo
2026-10-20 9:36 ` [PATCH 1/3] dt-bindings: i3c: renesas,i3c: Document analog noise filter control Diogo Ivo
2026-10-20 19:18 ` Frank Li
2026-10-26 16:21 ` Diogo Ivo
2026-10-26 20:33 ` Frank Li
2026-10-27 10:34 ` Diogo Ivo [this message]
2026-10-27 14:27 ` Frank Li
2026-10-20 9:36 ` [PATCH 2/3] i3c: renesas: Add support for the analog noise filter Diogo Ivo
2026-10-20 9:36 ` [PATCH 3/3] arm64: dts: renesas: r9a08g046: Enable I3C " Diogo Ivo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f4b8a714-dab8-45d4-b98f-717d010806de@renesas.com \
--to=diogo.ivo.sx@renesas.com \
--cc=Frank.Li@nxp.com \
--cc=Frank.li@oss.nxp.com \
--cc=alexandre.belloni@bootlin.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=geert+renesas@glider.be \
--cc=krzk+dt@kernel.org \
--cc=linusw@kernel.org \
--cc=linux-i3c@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=robh@kernel.org \
--cc=tommaso.merciai.xr@bp.renesas.com \
--cc=wsa+renesas@sang-engineering.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®