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

[Diogo Ivo <diogo.ivo.sx@renesas.com>]

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@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,
>>>
>>> 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?
>>