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

[-- Attachment #1.1: Type: text/plain, Size: 3148 bytes --]

On Mon, Feb 11, 2019 at 02:36:53PM +0100, Harald Geyer wrote:
> > > debug console multiplexing:
> > > Olimex have a userspace script that controls gpio PL9 during boot,
> > > to select between HP and serial console. I guess this is not acceptable
> > > for mainline.
> > 
> > > The best solution I can see is to switch the HP jack from serial console
> > > to audio once the audio drivers load. With this people can still capture
> > > the bootlogs but everybody gets audio once the system is up and
> > > switching back to console output is as simple as unloading the audio
> > > drivers.
> > 
> > IMO it is really not the audio driver's business to mess with this switch.
> > You could argue as well that the serial driver should get a flag to claim
> > the HP jack, which would be similarily unjustified.
> 
> Not the audio driver's business, but perheps the audio card's DT node.
> Which is why I came up with the pinctrl idea.

I know that the nexus7 is quite well supported, and iirc they were
using a similar trick on their UART. Have you looked at how they were
doing that?

> > My solution is to confine this choice inside U-Boot:
> > in sun50i-a64-teres-i-u-boot.dtsi I put
> > 
> > / {
> >         leds {
> >                 compatible = "gpio-leds";
> >                 /* Not really a LED, but the least intrusive workaround */
> >                 audioconsole {
> >                         label = "teres-i:audio:console";
> >                         gpio = <&r_pio 0 9 GPIO_ACTIVE_LOW>; /* PL9 */
> >                         default-state = "on";
> >                 };
> >         };
> > [...]
> > 
> > and place a "gpio set PL9;" somewhere in the bootcmd_* logic. Otherwise there's
> > a *lot* of chirping on the right ear during boot ;-)
> > The switch is for early boot debugging, so it's best to have U-Boot enable it
> > when required, and keep it off by default.
> 
> I agree that some quirk in u-boot will be required for those who want
> to boot with headphones plugged in.
> 
> But I still think we need a proper description of the HW in the linux DT:
> * When linux doesn't know about the pin at all, there are no guarantees
>   that it won't accidentally touch the pin during some operations like
>   suspend/resume, etc.
> * There is the usecase where somebody puts the system console on ttyS1
>   and uses ttyS0 to connect to some other board. (Actually I believe this
>   is a quite likely usecase given Olimex' usual target market.) I'd like
>   to support this.

Agreed.

> Using something like your leds hack in the linux DT would be fine for
> me, if the maintainers are willing to accept it.

Not really. The side-effects of that is that any user-space stack is
free to come by and treat it like an LED as well which would be quite
horrible as far as audio or UART reliability is concerned :)

We want to model this properly. I guess using a pinctrl driver
controlled through GPIO (similar to what regulator-gpio is) would be a
good first step.

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
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 [this message]
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
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=20190211153945.e34fpwkuk67l7lc6@flea \
    --to=maxime.ripard@bootlin.com \
    --cc=20190201113743.10058-1-harald@ccbib.org \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=harald@ccbib.org \
    --cc=ibu@radempa.de \
    --cc=info@olimex.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.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