Message-ID: <20251208-headgear-header-e17e162f0f52@spud>
Date: Mon, 8 Dec 2025 18:00:55 +0000
From: Conor Dooley <conor@...nel.org>
To: "Lad, Prabhakar" <prabhakar.csengg@...il.com>
Cc: Geert Uytterhoeven <geert+renesas@...der.be>,
	Linus Walleij <linus.walleij@...aro.org>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Magnus Damm <magnus.damm@...il.com>,
	linux-renesas-soc@...r.kernel.org, linux-gpio@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	Biju Das <biju.das.jz@...renesas.com>,
	Fabrizio Castro <fabrizio.castro.jz@...esas.com>,
	Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [PATCH 1/2] dt-bindings: pinctrl: renesas,r9a09g077: Document
 pin configuration properties

On Mon, Dec 08, 2025 at 10:36:04AM +0000, Lad, Prabhakar wrote:
> Hi Conor,
> 
> Sorry for the delayed response. Ive got feedback from the HW team.
> 
> On Fri, Oct 17, 2025 at 4:33 PM Lad, Prabhakar
> <prabhakar.csengg@...il.com> wrote:
> >
> > Hi Conor,
> >
> > Thank you for the review.
> >
> > On Thu, Oct 16, 2025 at 5:41 PM Conor Dooley <conor@...nel.org> wrote:
> > >
> > > On Tue, Oct 14, 2025 at 08:11:20PM +0100, Prabhakar wrote:
> > > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
> > > >
> > > > Document the pin configuration properties supported by the RZ/T2H pinctrl
> > > > driver. The RZ/T2H SoC supports configuring various electrical properties
> > > > through the DRCTLm (I/O Buffer Function Switching) registers.
> > > >
> > > > Add documentation for the following standard properties:
> > > > - bias-disable, bias-pull-up, bias-pull-down: Control internal
> > > >   pull-up/pull-down resistors (3 options: no pull, pull-up, pull-down)
> > > > - input-schmitt-enable, input-schmitt-disable: Control Schmitt trigger
> > > >   input
> > > > - slew-rate: Control output slew rate (2 options: slow/fast)
> > > >
> > > > Add documentation for the custom property:
> > > > - renesas,drive-strength: Control output drive strength using discrete
> > > >   levels (0-3) representing low, medium, high, and ultra high strength.
> > > >   This custom property is needed because the hardware uses fixed discrete
> > > >   levels rather than configurable milliamp values.
> > > >
> > > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
> > > > ---
> > > >  .../bindings/pinctrl/renesas,r9a09g077-pinctrl.yaml | 13 +++++++++++++
> > > >  1 file changed, 13 insertions(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,r9a09g077-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,r9a09g077-pinctrl.yaml
> > > > index 36d665971484..9085d5cfb1c8 100644
> > > > --- a/Documentation/devicetree/bindings/pinctrl/renesas,r9a09g077-pinctrl.yaml
> > > > +++ b/Documentation/devicetree/bindings/pinctrl/renesas,r9a09g077-pinctrl.yaml
> > > > @@ -72,6 +72,19 @@ definitions:
> > > >        input: true
> > > >        input-enable: true
> > > >        output-enable: true
> > > > +      bias-disable: true
> > > > +      bias-pull-down: true
> > > > +      bias-pull-up: true
> > > > +      input-schmitt-enable: true
> > > > +      input-schmitt-disable: true
> > > > +      slew-rate:
> > > > +        enum: [0, 1]
> > >
> > > What are the meanings of "0" and "1" for slew rate? Why isn't this given
> > I'll add a description for it (0 = slow, 1 = fast) and the same values
> > are programmed in the register to configure the slew rate.
> >
> > > as the actual rates? The docs surely give more detail than just "slow"
> > > and "fast".
> > You mean to represent slew-rate in some sort of a unit?
> >
> Based on the comments from the HW team, there is no numerical
> definition to represent slow/fast It only defines a relative
> relationship.
> > >
> > > > +      renesas,drive-strength:
> > > > +        description:
> > > > +          Drive strength configuration value. Valid values are 0 to 3, representing
> > > > +          increasing drive strength from low, medium, high and ultra high.
> > >
> > > I see what you wrote in the commit message, but I don't really get why
> > > you need a custom property. I would imagine most devices only have some
> > > some small set of "fixed discrete levels", yet manage with milli- or
> > > micro-amps fine. Converting from mA to register values in a driver is
> > > not difficult, and I figure the documentation for the device probably
> > > doesn't just give vague strengths like "medium" or "ultra high", but
> > > probably provides currents?
> > >
> > > I dunno, I am just confused by the need to shove register values into
> > > these properties, rather than using the actual units.
> > >
> > I'm checking this with the HW team. I'll get back on this once I have
> > some feedback.
> >
> The current value is determined by the load on the external circuit
> and is not affected by the choice of drive strength. For example, if a
> 3.3V signal line (H = 3.3V, L = 0V) has a 3.3kΩ load, the resulting
> current will be 1mA, regardless of whether you select Low, Mid, High,
> or Ultra High drive strength. What changes with Low/Mid/High/Ultra
> High is the “slew rate” of the transitions (H --> L and L --> H), not
> the current itself.
> 
> Please share your thoughts on how to implement these properties.

ngl, sounds like both of these properties should be strings, but for the
fact that slew-rate is open ended and I am pretty sure used like you are
using it elsewhere.
The second property, I'm not sure what you're trying to say with your
example. Ignoring the specifics of your platform, and using the normal
drive-strength property, I wouldn't expect that, if a given drive strength
can provide 1 mA, that increasing the drive strength would increase the
current. It would be impossible for it to do so!
Remember, drive strength is the current that can be delivered through a
pin, not how much it is delivering at a given point in time.
I would also expect that increasing the drive strength (still using the
regular definition/property) would improve the rate of transition between
states, in addition to increasing the maximum drive, although not the
primary goal.

What I find weird about your explanation is that, taken at face value,
where this vendor specific property has no effect on steady-state drive
strength and only on slew rate, you have two different slew rate
controls. The regular slew-rate with 2 options and this one with 4.
That, combined with the example that doesn't make sense, casts doubt
over the explanation you're providing for what this actually is
controlling. If this truly has no impact on steady-state drive strength,
how do these two slew-rate controls actually interact? 

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)

Powered by blists - more mailing lists