Linux-ARM-Kernel Archive on
 help / color / Atom feed
From: Harald Geyer <>
To: Maxime Ripard <>
Cc: Mark Rutland <>,,,
	Mark Brown <>, Chen-Yu Tsai <>,
	Rob Herring <>, Torsten Duwe <>,,
Subject: Re: [PATCH RFC] arm64: dts: allwinner: a64: teres-i: Enable audio
Date: Wed, 13 Feb 2019 12:43:46 +0100
Message-ID: <> (raw)
In-Reply-To: <20190213094442.da2dy6d5bb527nft@flea>

Hi Maxime!

Maxime Ripard writes:
> On Tue, Feb 12, 2019 at 08:37:36PM +0100, Harald Geyer wrote:
> > > 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?
> This is kind of separate. At the moment, on all our SoCs but the H6,
> requesting a pin to a separate state using pinctrl doesn't mark the
> GPIO muxed on that pin as reserved, so through the GPIO userspace
> interface (or calling gpio_request from within the kernel, but that
> seems less of a risk) anyone is free to just request a GPIO on a pin
> already requested, behind the consumer drivers' back. Which is pretty
> bad.

Really, I'm surprised. This is not the behaviour I remember from A20
and A64. Indeed, testing this on teres with the debug detect pin claimed
by audio, I get:

root@teres:/sys/kernel/debug/pinctrl/1f02c00.pinctrl# cat pinmux-pins
Pinmux settings per pin
Format: pin (name): mux_owner|gpio_owner (strict) hog?
pin 352 (PL0): device 1f03400.rsb function s_rsb group PL0
pin 353 (PL1): device 1f03400.rsb function s_rsb group PL1
pin 354 (PL2): GPIO 1f02c00.pinctrl:354
pin 355 (PL3): UNCLAIMED
pin 356 (PL4): UNCLAIMED
pin 357 (PL5): UNCLAIMED
pin 358 (PL6): UNCLAIMED
pin 359 (PL7): GPIO 1f02c00.pinctrl:359
pin 360 (PL8): GPIO 1f02c00.pinctrl:360
pin 361 (PL9): device sound function gpio_out group PL9
pin 362 (PL10): UNCLAIMED
pin 363 (PL11): UNCLAIMED
pin 364 (PL12): GPIO 1f02c00.pinctrl:364

root@teres:/sys/class/gpio# echo 361 >export
bash: echo: Schreibfehler: Das Argument ist ungültig.

So I can't access this from sysfs, even though the error code is a
bit odd: I'd expect EBUSY instead of EINVAL. I can export any of the
UNCLAIMED pins/gpios.

Trying with libgpiod as well, I see that the state of the pin is reported
incorretly, but I still can't access it:

gpiochip0 - 32 lines:
        line   0:      unnamed       unused   input  active-high
        line   1:      unnamed       unused   input  active-high
        line   2:      unnamed      "reset"  output   active-low [used]
        line   3:      unnamed       unused   input  active-high
        line   4:      unnamed       unused   input  active-high
        line   5:      unnamed       unused   input  active-high
        line   6:      unnamed       unused   input  active-high
        line   7:      unnamed  "usb1-vbus"  output  active-high [used]
        line   8:      unnamed "Lid Switch"   input   active-low [used]
        line   9:      unnamed       unused   input  active-high
        line  10:      unnamed      "sysfs"   input  active-high [used]
        line  11:      unnamed       unused   input  active-high
        line  12:      unnamed     "enable"  output  active-high [used]
        line  13:      unnamed       unused   input  active-high

root@teres:~# gpioget 1f02c00.pinctrl 9
gpioget: error reading GPIO values: Invalid argument

On a pin exported to sysfs I get EBUSY as expected:
root@teres:~# gpioget 1f02c00.pinctrl 10
gpioget: error reading GPIO values: Device or resource busy

And reading an unclaimed pin works as expected too:
root@teres:~# gpioget 1f02c00.pinctrl 11

Either I misunderstood what you have written or it isn't true.

> There's support for such a check in pinctrl, and we did enable it for
> the H6. However, one of its side effect is that you can't have a
> pinctrl node for a GPIO anymore (at least without significantly
> reworking the GPIO API in the kernel).

Can you point me to some background reading?

> We did enable it for the H6, since it didn't have any backward
> compatibility to take care of, but it's disabled at the moment for all
> the other SoCs to be able to flip that switch at some point. And
> that's why we're moving away from it as well.

Well ... that's good to know, because I have a couple of custom DTs
with pinctrl nodes for a GPIO. I think it should be documented as
deprecated in the binding then.

Also I wonder how I can select drive strength or bias on a gpio line when
I can't use pinctrl with them anymore.

> > I think the real downside of this approach is, that using the UART
> > makes the internal speakers/mic unuseable too.
> That's also a pretty big issue.

I certainly agree it's unfortunate.

> > 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.
> I still believe we should aim at supporting this through pinctrl, and
> adding an userspace API is definitely easier than a full subsystem.

Getting everybody to agree on a new API (especially a userspace ABI)
is a major headache (and rightly so, we want to get something right on
the first attempt that is going to stay around forever). I don't think
some quirky debugging feature is worth the effort.

And frankly I don't care much about audio on the teres. I started
working on this because I feel kind of responsible for keeping the
teres DT up-to-date with what the kernel can support. But if the
kernel can't support it ATM: so be it.

As a compromise I think we could add all the nodes to the DT but mark
their status as "disabled". That would help everybody wanting to enable
audio but still be technically correct.


If you want to support my work:
or donate via CLAM to xASPBtezLNqj4cUe8MT5nZjthRSEjrRQXN
or via peercoin to P98LRdhit3gZbHDBe7ta5jtXrMJUms4p7w

linux-arm-kernel mailing list

  reply index

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2019-02-11 13:36 ` Harald Geyer
2019-02-11 15:39   ` Maxime Ripard
2019-02-11 19:32     ` Harald Geyer
2019-02-12  8:38       ` Maxime Ripard
2019-02-12  9:42         ` Harald Geyer
2019-02-12 10:09           ` Maxime Ripard
2019-02-12 19:37             ` Harald Geyer
2019-02-13  9:44               ` Maxime Ripard
2019-02-13 11:43                 ` Harald Geyer [this message]
2019-02-13 15:53                   ` Maxime Ripard
2019-02-14  0:12                     ` Harald Geyer
2019-02-15 14:20                       ` Torsten Duwe
2019-02-16 20:47                         ` Harald Geyer
2019-02-17 11:30                           ` Torsten Duwe
2019-02-18 10:24                           ` Maxime Ripard
2019-04-30 13:32                             ` Torsten Duwe
2019-05-02  7:46                               ` Maxime Ripard
2019-05-02 14:48                                 ` Harald Geyer
2019-02-01 11:37 Harald Geyer
2019-02-12  8:34 ` Chen-Yu Tsai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-ARM-Kernel Archive on

Archives are clonable:
	git clone --mirror linux-arm-kernel/git/0.git
	git clone --mirror linux-arm-kernel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-arm-kernel linux-arm-kernel/ \
	public-inbox-index linux-arm-kernel

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone