More pinmux feedback, and GPIO vs. pinmux interaction

[Linus Walleij]

On Fri, Jun 24, 2011 at 5:51 AM, Mike Frysinger <vapier.adi at gmail.com> wrote:

> can you guys start cc-ing uclinux-dist-devel at blackfin.uclinux.org on
> future pinmux discussions?

OK!
Please refer to the LKML thread:
[PATCH 1/2] drivers: create a pinmux subsystem v3

For now, I'll include blackfin for the v4 post.

> we already have a thin layer in the
> Blackfin tree for handling pin muxing that has served us well for a
> few years, so we want to keep tabs on where this is going.  i just
> happened to stumble across this today.

Aha now it's yet another name, portmux, to add to the happy family
of pinmux, padmux, fingermux, alternate functions and mission mode
terminology soup ;-)

> arch/blackfin/include/asm/portmux.h:
> peripheral_request()
> peripheral_request_list()
> peripheral_free()
> peripheral_free_list()
>
> this lets you pass in an array of pins and it returns success only if
> all were available.  we find the array request method gets used the
> vast majority of the time, so any proposed API should include that.

I think if you look at the Documentation/pinctrl.txt file from the
last iteration of the framework you find that this is exactly what
the pinmux part of the pinctrl subsystem does. It avoids pin
clashes in a discrete number space.

If I'm not mistaken. (Which happens a lot.)

> we also handle pins that can only be used in peripheral mode.  this
> allows us to write code that requests UART pins without having to know
> whether the pin is muxed or dedicated or somewhere in between.

This is done with pinmux_get() and pinmux_enable() in this
framework.

>>> Grant does not seem to like the idea of the gpio subsystem
>>> meddeling with all this stuff anyway, so I intend to take all that
>>> into pinctrl, and then gpio only deal with, well GPIO. Setting
>>> bits quickly and such.
>
> but there has to be resource management between the two subsystems
> somewhere.  on the Blackfin side, if you request a pin as a GPIO using
> the GPIO api, and then try to request it in peripheral mode, you get
> EBUSY back.  you cant have the two blocks stepping on each others
> toes.

Yes. Avoiding this is exactly the idea behind the
int (*gpio_request_enable) (struct pinmux_dev *pmxdev, unsigned offset);
member in the pinmux_ops vtable. We're discussing the exact
semantics of this call here.

We all agree we need something that can allocate a single pin for
GPIO in the number space, I think.

> some Blackfin parts have this to ease the conflicts between devices
> that customers want.  if UART0 and SPI0 share PF0, PF1, and PF2,
> sometimes UART0 can be routed to PG3 and PG4 so that SPI0 can be used.

This kind usecase is covered extensively in the documentation
and previous discussion IIUC.

> atm we've made this a Kconfig option.  obviously that wont fly in the
> "build one image to run on all platforms", but that isnt a problem for
> Blackfin systems today, and customers have been OK with this minor
> limitation.

I think we may be able to fix that limitation, and would like to make sure
we're not engineering in some limitation for Blackfin, so hit us.

> we implemented this on the Blackfin side by encoding things into the
> pin data.  but that's because we had enough space in u16 to cover all
> of our parts so far.
>
> for example, the PA1 pin can act as GPIO, or as a timer pin, or as
> part of our high speed peripheral SPORT.
> #define P_SPORT2_DTSEC (P_DEFINED | P_IDENT(GPIO_PA1) | P_FUNCT(0))
> #define P_TMR4 (P_DEFINED | P_IDENT(GPIO_PA1) | P_FUNCT(1))
> when someone does peripheral_request(P_TMR4), the code first reserves
> itself with the GPIO core, and then configures the pinmux logic to set
> this pin as "function 1" (it's a 2 bit field).

In ARM we're at the stage now where each mach-foo under arch/arm/*
is running its own show in this regard. For example mach-ux500
magically stuff all its pin configuration into a u32 cleverly reusing bits
here and there.

Everyone is special, just like everybody else...

Basically there are as many pinmux implementations as there are
machines, and then we end up with that other Linus beating us on the
head for not consolidating our stuff into something generic.

So I'm doing this framework using some structs and radix trees
and no magic bitstuffing for now.

> we also have pin grouping logic implemented for the parts which dont
> have per-pin muxing so you cant request different pins in the same
> group for the same mode.

We should be able to solve that I think!

Yours,
Linus Walleij