Message-ID: <7e62e720ccc51fb5c7d023adae3eab35aecf0bba.camel@icenowy.me>
Date: Thu, 24 Apr 2025 17:38:16 +0800
From: Icenowy Zheng <uwu@...nowy.me>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Emil Renner Berthing <kernel@...il.dk>, Jianlong Huang
 <jianlong.huang@...rfivetech.com>, Hal Feng <hal.feng@...rfivetech.com>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, linux-gpio@...r.kernel.org,
 devicetree@...r.kernel.org,  linux-kernel@...r.kernel.org,
 linux-riscv@...ts.infradead.org
Subject: Re: [PATCH v2 1/3] dt-bindings: pinctrl: starfive,jh7110: add
 PAD_INTERNAL_* virtual pins

在 2025-04-24星期四的 10:51 +0200，Linus Walleij写道：
> On Thu, Apr 24, 2025 at 8:20 AM Icenowy Zheng <uwu@...nowy.me> wrote:
> 
> > The JH7110 SoC could support internal GPI signals to be routed to
> > not
> > external GPIO but internal low/high levels.
> > 
> > Add two macros, PAD_INTERNAL_LOW and PAD_INTERNAL_HIGH, as two
> > virtual
> > "pads" to represent internal GPI sources with fixed low/high
> > levels.
> > 
> > Signed-off-by: Icenowy Zheng <uwu@...nowy.me>
> 
> As per my other reply in the previous post, I think this should be
> handled internal in the kernel instead using a tighter integration
> between
> the GPIO and pin control parts of the driver and utilizing the
> gpio-specific struct pinmux_ops callbacks.

Well I cannot understand this -- these signals are not GPIOs, totally
not related to the GPIO subsystem (because they're only pinmux, not
related to GPIOs). This is described in my previous mail.

The pin mux of JH7110 strictly route its inputs to its outputs. For
signals from other SoC blocks (to external pins), the registers define
how OUT/OEn of IO buffers *are driven by* the signals; however for
signals to other SoC blocks (from external pins), the registers define
how IN of IO buffers *drive* the signals. (This follows the generic
signal-driving rule that one signal can drive multiple signals but
cannot be multi-driven).

In addition the situation I am trying to handle here is an addition to
the latter part of the previous paragraph -- in addition to 64 inputs
corresponding to 64 GPIOs, two extra inputs, one always 0 and another
always 1 are available to the pin controller for driving other SoC
blocks' input (as output of pin controller).

In fact this is why there is ` + 2` when calculating ival in
jh7110_set_gpiomux() -- the first two possible values are for always 0
and always 1, 3 represents the IN of GPIO0, etc.

> 
> This solution looks like software configuration disguised as hardware
> configuration.

Well this solution handles these internal wires in the same way as
signals from external GPIOs, excepting specifying special GPIO numbers.
If you are against the principle, maybe the current already-included
GPIOMUX system of the StarFive pinctrl is to be blamed instead of my
small extension to it.

I must admit that the current GPIOMUX system isn't a faithful
representation of the hardware because it's a pad-centric setup instead
of a register-field-centric one, which isn't very natural for input
signals. However configurating the mux in such a way is against people
reading, and we're not able to break the system because it's already
there.

Well in the situation that one GPIO used as input drives multiple
internal signals the pinmux looks a little confusing too, e.g. the I2S
clock situation I mentioned in my reply in the previous revision of the
patchset.

> 
> Yours,
> Linus Walleij

Powered by blists - more mailing lists