Message-ID: <20251119-citadel-shrine-fabc3fb309ac@spud>
Date: Wed, 19 Nov 2025 18:06:46 +0000
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, Valentina.FernandezAlanis@...rochip.com
Subject: Re: [RFC v1 0/4] Microchip mpfs/pic64gx pinctrl part 2

On Wed, Nov 19, 2025 at 01:16:16PM +0100, Linus Walleij wrote:
> On Wed, Nov 12, 2025 at 3:33 PM Conor Dooley <conor@...nel.org> wrote:
> 
> > Got the other driver that I was talking about here for you...
> > It's in RFC state because I'd like to get some feedback on the approach
> > while I try to figure out a) what ibufmd is
> 
> I was going to ask about that :D
> 
> > and b) how the bank voltage
> > interacts with the schmitt trigger setting.
> 
> Please check if "bank voltage" is somewhat analogous to
> this generic config:
> 
> * @PIN_CONFIG_POWER_SOURCE: if the pin can select between different power
>  *      supplies, the argument to this parameter (on a custom format) tells
>  *      the driver which alternative power source to use.

It's not pin based, the whole bank it is connected to has to be changed.
I'm not entirely sure if I want the driver to be able to control this at
all (at least not right now) because I don't know exactly what the
ramifications of changing it away from what the configuration tool
decided that it was are. Probably it could be done, but I don't know how
safe it is to change, as I think most of these kinds of settings were
never really seen as something "application" software would change
(linux is an application from the perspective of the design folks),
since it was all modifiable from the MSS configuration tool.

> > There's some specific @Linus questions in the driver, mostly where I was
> > unsure about how config bits should be handled and looking around at
> > other drivers wasn't sufficient because they did different things.
> 
> I tried to answer as best I could.

Cool, thanks.

> > Finally, on the dt side, this was using the pinmux property before the
> > other drivers were submitted, but I didn't really like it to begin with
> > (shoving two things into entries of the same property gives me the ick).
> > I moved to using pins + function which at least looks prettier in the
> > devicetree.
> 
> I think this looks way better than any pinmux properties.
> 
> > I had been hoping that I could move to some sort of generic
> > dt_node_to_map function, but I couldn't figure out one that'd work
> > without creating groups in the driver. If there is, I'd love to get rid
> > of the custom dt_node_to_map stuff.
> 
> It seems like something that could be added to the core
> (drivers/pinctrl/devicetree.c), if you feel like and have time for going
> the extra mile. Maybe it would be simple to move some drivers
> over to using it if done right.

Yeah I might, especially if it pushes people away from these pinmux
properties! Might also just submit this as-is and do it on top, depends
on what stuff I have going on.

> 
> > I want to avoid doing having set groups, because of the number of
> > possible configurations in the MSS Configurator FPGA tool is fairly
> > large, and I believe that MSS Configurator actually undersells the
> > number of possible combinations for ease of use.
> 
> FPGA:s often have this "phone exchange" property.
> 
> > I haven't tested that
> > and the driver technically doesn't support it, but I feel like not trying
> > to define groups statically and using pins instead would permit those
> > combos in the future should that use case ever materialise.
> 
> It makes sense for a driver for this type of very flexible hardware.


Thanks for taking a look.

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

Powered by blists - more mailing lists