Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / Atom feed
From: Harald Geyer <harald@ccbib.org>
To: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	devicetree@vger.kernel.org, info@olimex.com,
	Mark Brown <broonie@kernel.org>, Chen-Yu Tsai <wens@csie.org>,
	Rob Herring <robh+dt@kernel.org>,
	ibu@radempa.de, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RFC] arm64: dts: allwinner: a64: teres-i: Enable audio
Date: Tue, 12 Feb 2019 20:37:36 +0100
Message-ID: <E1gtds8-0000NB-Re@stardust.g4.wien.funkfeuer.at> (raw)
In-Reply-To: <20190212100929.iqsxu443qrkl6myf@flea>

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply index

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20190211111245.GA18147@lst.de>
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 [this message]
2019-02-13  9:44               ` Maxime Ripard
2019-02-13 11:43                 ` Harald Geyer
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=E1gtds8-0000NB-Re@stardust.g4.wien.funkfeuer.at \
    --to=harald@ccbib.org \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=ibu@radempa.de \
    --cc=info@olimex.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=maxime.ripard@bootlin.com \
    --cc=robh+dt@kernel.org \
    --cc=wens@csie.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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

Linux-ARM-Kernel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/0 linux-arm-kernel/git/0.git
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/1 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/ https://lore.kernel.org/linux-arm-kernel \
		linux-arm-kernel@lists.infradead.org
	public-inbox-index linux-arm-kernel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-arm-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git