[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251001-backless-cattle-a98db634d7f0@spud>
Date: Wed, 1 Oct 2025 16:45:43 +0100
From: Conor Dooley <conor@...nel.org>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Conor Dooley <conor.dooley@...rochip.com>,
Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org,
devicetree@...r.kernel.org
Subject: Re: [RFC 3/5] pinctrl: add polarfire soc iomux0 pinmux driver
On Wed, Oct 01, 2025 at 01:36:49PM +0200, Linus Walleij wrote:
> On Wed, Oct 1, 2025 at 1:34 PM Linus Walleij <linus.walleij@...aro.org> wrote:
> > On Fri, Sep 26, 2025 at 4:33 PM Conor Dooley <conor@...nel.org> wrote:
> >
> > > +static const struct pinctrl_pin_desc mpfs_iomux0_pinctrl_pins[] = {
> > > + PINCTRL_PIN(0, "spi0"),
> > > + PINCTRL_PIN(1, "spi1"),
> > > + PINCTRL_PIN(2, "i2c0"),
> > > + PINCTRL_PIN(3, "i2c1"),
> > > + PINCTRL_PIN(4, "can0"),
> > > + PINCTRL_PIN(5, "can1"),
> > > + PINCTRL_PIN(6, "qspi"),
> > > + PINCTRL_PIN(7, "uart0"),
> > > + PINCTRL_PIN(8, "uart1"),
> > > + PINCTRL_PIN(9, "uart2"),
> > > + PINCTRL_PIN(10, "uart3"),
> > > + PINCTRL_PIN(11, "uart4"),
> > > + PINCTRL_PIN(12, "mdio0"),
> > > + PINCTRL_PIN(13, "mdio1"),
> >
> > This looks like it is abusing the API. These things do not look like
> > "pins" at all, rather these are all groups, right?
>
> Or maybe they are rather functions. Like there is a function spi0
> that can be mapped to a set of pins such as spi0_grp = <1, 2, 3, 4...>
They're not actually package pins at all that are being configured here,
it's internal routing inside the FPGA. It does operate on a function
level, but I don't think there's a neat mapping to the pinctrl subsystem
which (AFAIU) considers functions to contain groups, which in turn
contain pins. I suppose it could be thought of that, for example, spi0
is actually a function containing 4 (or 5, don't ask - or do if you want
to read a rant about pointlessly confusing design) "pins" in 1 group.
If I could just work in terms of functions only, and avoid groups or
pins at all, feels (to me ofc) like it'd maybe match the purpose of this
aspect of the hardware better.
> I recommend a refresher with
> https://docs.kernel.org/driver-api/pin-control.html
> and work from there, and avoid looking too much at other
> drivers that don't necessarily do the right thing.
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists