Message-ID: <0606c146d97ff98ff1412b98f49e6da0071801d1.camel@icenowy.me>
Date: Thu, 24 Apr 2025 20:25:35 +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星期四的 12:30 +0200，Linus Walleij写道：
> On Thu, Apr 24, 2025 at 11:38 AM Icenowy Zheng <uwu@...nowy.me>
> wrote:
> > 在 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.
> 
> OK sorry if I'm a bit dumb at times :(
> 
> I guess I was falling into the common confusion of "something named
> general purpose" such as your GPI and GPO registers, is also
> related to GPIO which it is not, at least not always.

Ah, sorry, these GPI/GPO names are directly taken from the StarFive TRM
from the register field names. They CAN be routed to the external
GPIOs, but is not required so.

> 
> > 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).
> 
> OK ... maybe I get it now.
> 
> > > 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.
> 
> I guess what rubs me the wrong way is why the external users
> (devices, device drivers or even pin hogs) cannot trigger the chain
> of
> events leading to this configuration, instead of different "magic"
> configurations that are just set up in the pin controller itself.

Well I am just extending what's already in use...

Currently it's already supported to route GPIOs to GPI signals, I added
the support to route fixed level sources to them, in a similar way.

If any external users ever have the need of banging the internal
signals instead of tying it fixedly, maybe switching between different
pinctrl configuration sets is enough? (Because this kind of operation
could never be as high speed enough as real hardware pins)

> 
> But if you are positively convinced that there is no other way,
> I guess I have to live with it.
> 
> Yours,
> Linus Walleij

Powered by blists - more mailing lists