Re: [PATCH RFC] arm64: dts: allwinner: a64: teres-i: Enable audio

Harald Geyer
2019-02-12T19:38:08Z

Hi Maxime!

Maxime Ripard writes:
> > > And pinctrl can be used dynamically as well if you need to
> >
> > Can you explain or point me to the relevant explanation in the docs? I
> > don't seem to know about it.
>
> pinctrl_select_state is what you would want to call,
> you would have a good example of that runtime change in
> drivers/i2c/muxes/i2c-mux-pinctrl.c.

I believe we have misunderstood each other somewhere. The above example
seems to be about one device (mux driver) requesting a set of pins and then
switching between different pinconfig states thereby activating
different subsets of pins. I don't see a way to have two devices
request the same set of pins. I could write gpio-mux-pinctrl, but I
don't see how this helps much either.

> > > > Instead I just got the original patch working, by implementing
> > > > "output-high" DT property in sunxi-pinctrl. I'll send a patch for
> > > > review soon.
> > >
> > > What do you want to do with output-high exactly?
> >
> > Exactly what I do in the patch that started this thread. (I'll resend
> > when wens' cpvdd patch is available for me to rebase onto.)
>
> There's a few issues with that approach as well:
>
> - We're actively trying to remove the pinctrl nodes for the GPIOs

For what reason? Maybe it doesn't apply to this usecase?

> - It's completely static: if one only wants to use the UART all the
> time, they would have to change the DTB, which might or might not be
> possible. Note that this could be trickier: why would you prevent the
> console from working for example if the audio support isn't built in?
> or as a module that might or might not be loaded?

No, it's not that static:
* Before the audio device probes, UART is active. (You want UART all the
time: Just prevent the audio module from loading.)
* When you have used audio and suddenly want to have UART instead: Just
unbind the audio device and set the gpio to low or input from userspace.
(I intended unbinding to be sufficient, but it seems pinctrl doesn't
set the pin back to input when it is freed and I don't see a straight
forward way to force that. I guess it is okay however: Somebody
switching between UART and audio regularly has to know about the
details anyway.)

I also tested suspend/resume/poweroff and it mostly works. The only
glitch is, that during suspend there is a short period of UART noise
on the HP. (But no such problem during resume or poweroff.) I suspect
the regulator supplying the gpio bank is shut down quite early when
suspending. It doesn't matter for this discussion: There likely would
be the same behaviour with any other approach too.

I think the real downside of this approach is, that using the UART
makes the internal speakers/mic unuseable too. But we need a way to
control the mux from userspace and aside from unbinding the ideas
proposed thus far are:
a) control the gpio directly
b) control the gpio via leds-gpio

(a) was dismissed because we can't set a default from DT
(b) was dismissed because some rogue app might try to blink it

The clean solution might be to write mux-gpio, which is actually
identical to leds-gpio but lives in /sys/class/mux_switches/ and
uses different filenames. But that's going down the "invent a new
subsystem road", which I believe is overkill for what is a debugging
facility for a single board.

Harald

--
If you want to support my work:
see http://friends.ccbib.org/harald/supporting/
or donate via CLAM to xASPBtezLNqj4cUe8MT5nZjthRSEjrRQXN
or via peercoin to P98LRdhit3gZbHDBe7ta5jtXrMJUms4p7w