Re: [PATCH 9/9] arm64: dts: renesas: rzg3s-smarc-som: Enable I3C

[Claudiu Beznea <claudiu.beznea@kernel.org>]

Hi, Wolfram,

On 5/26/26 19:55, Wolfram Sang wrote:
> Hi Claudiu,
> 
>> Could you please let me know what do you consider we should do here? Do you
>> think we could drop these pin controller setting and do some particular I3C
>> controller settings instead?
> 
> My original thought was: If it was a boolean state which is active when
> suspending and disabled when resuming, then we wouldn't need a customer
> specific binding for it and just do this in the suspend/resume functions
> of the pin-controller...
> 
> ... BUT ...
> 
> reading more about this in the manual, just raises more questions for
> me.
> 
>> The output is fixed at Hi-Z and no data is transmitted to the inside even if
>> data is input from outside. “Standby mode” is available when using I2C mode
>> only. (Not available when using I3C mode).
>>
>> The current driver proposal don't take into account the IP mode when setting
>> STBN though
>> pinctrl_pm_select_sleep_state()/pinctrl_pm_select_default_state() to keep
>> the code simpler, relying on the "Not available when using I3C mode" part of
>> the note, and considering setting it when the IP is in I3C mode is harmless.
> 
> This is one question I also had: What does "not available" actually
> mean? Did you confirm with HW guys that it is really harmles?
> 
> I also wonder about the intended use-case of this mode. "no data is
> transmitted to the inside even if data is input from outside" doesn't
> really sound like a mode intended when the whole SoC goes to sleep. Why
> or how would input be even transmitted to the inside if everything is in
> a deep-sleep state? I could also imagine that this mode is rather used
> to hide from the bus for a while for some corner-case reason.
> 
> And finally: does this really save energy? Could you measure a benefit?
> Maybe there is nothing driven at all in the sleep state? Then, nothing
> is gained? Not clear from the datasheet.
> 
> Because the datasheet is so sparse with information and because it
> doesn't say how STBN is intended to be used, I would argue we should
> skip it until we know what it is for and how it is used. If we know this
> somewhen, we can still add this in a second step.
> 
> But for now, enabling I3C realiably is the first step, and for that we
> surley need the POC bit to select the voltage. This is easily
> understandable and straightforward to do. So, my suggestion is to pick
> this low-hanging fruit now and reach for the other one once we have more
> information about it.

This is what I've got from the HW team:

The purpose of STBN is to control the standby state on the I2C side. It is not 
intended to control transitions to a low power consumption mode such as VBAT mode.

In I2C mode, enabling standby mode places the device in a non-communicating 
standby state while maintaining the I2C configuration. The outputs are set to 
Hi-Z, internal transmission is stopped, and communication is disabled. As a 
result, the bus is effectively not actively driven.

In I3C mode, standby control via STBN is ignored even if configured. STBN can 
therefore remain set to 1 while the clock is turned on and off. In I2C mode as 
well, it is acceptable to keep STBN = 1 while toggling the clock on and off. It 
is also possible to change the STBN setting while the clock remains enabled.

Standby mode is not intended for power consumption control, but rather for 
placing the I2C interface into a standby (non-communicating) state.

-- 
Thank you,
Claudiu