Re: [RFC 0/5] microchip mpfs/pic64gx pinctrl questions

[Conor Dooley]

On Mon, Oct 13, 2025 at 03:27:57PM +0200, Linus Walleij wrote:
> On Thu, Oct 9, 2025 at 5:55 PM Conor Dooley <conor@xxxxxxxxxx> wrote:
> 
> > So, what I ended up doing is moving the "gpio2" stuff to use
> > functions/groups as your gemini stuff does, so each function contains
> > one group containing all the pins it needs - except for the gpio
> > function which contains analogues for each of the function's groups.
> 
> I don't know exactly what you mean by this, but if it entails any

All I meant is that the functions for non-gpio things contain a group
with the pins they need, up to 10 groups for 10 non-gpio functions, and
that the gpio function, since each pin can do gpio and exactly one other
function, contains 10 groups, all of which are identical to a group
already defined for the non-gpio function. That's instead of having one
huge group with all 32 pins.

> entanglement of the GPIO function with another function, then
> there is the recent patch from Bartosz in commit
> 11aa02d6a9c222260490f952d041dec6d7f16a92
> which makes it possible to give the pin control framework
> an awareness of what a GPIO function is by reading hardware
> properties, and that it is sometimes separate from other functions.

That is unrelated, but interesting. What I don't really understand from
the commit message itself is whether this is useful if the pinctrl
driver is not also acting as a gpiochip driver. In my case, the pinctrl
hardware is not capable of doing anything more than muxing functions,
and the gpio function I talk about means routing a "real" gpio
controller's IO to the pins controlled by the driver I am talking about.
The 2 in "gpio 2" refers to the specific controller.
The rest of that thread makes it seem like this is intended for some
qcom devices where the pinctrl hardware is also a gpiochip.

Cheers,
Conor.

Attachment: signature.asc
Description: PGP signature