Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / Atom feed
From: Harald Geyer <harald@ccbib.org>
To: Torsten Duwe <duwe@lst.de>
Cc: Mark Rutland <mark.rutland@arm.com>,
	devicetree@vger.kernel.org, info@olimex.com,
	Maxime Ripard <maxime.ripard@bootlin.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: Sat, 16 Feb 2019 21:47:13 +0100
Message-ID: <E1gv6rh-0000Km-U8@stardust.g4.wien.funkfeuer.at> (raw)
In-Reply-To: <20190215142029.GB32618@lst.de>

Hi Torsten!

Torsten Duwe writes:

> > > > > > 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
> 
> Hey, this is a debugging hack. If some rogue app tries to blink it, so be it.
> 
> > I suspect some distributions will pick up the patch I posted anyway, if
> > it doesn't get merged mainline. (This is how I forgot missing backlight
> > support - it just worked for too many people ...) If we ship
> > sun50i-a64-teres-i.dts with the proper nodes (but disabled), their
> > patches will be much easier to maintain as the official DT evolves.
> 
> As I wrote (held by the list admin), I consider the whole console mux
> GPIO an U-Boot hack, and would put it into sun50i-a64-teres-i-u-boot.dtsi.
> (As a LED, see above :-)

The thing is, one of the quite strict rules in kernel development is:
Never break userspace. That means: If we provide a way to userspace to
do something (ie switch between debug and audio), we are expected to
keep it around forever. So since there is a decent chance that someday
somebody might write a driver that handles this situation properly, we
don't want chain ourselves to some dirty hack.

(I'm not totally against writing such a driver myself, if there are
enough use cases. However, I think that TERES alone is not enough.)

> Would you care to submit a patch version without that GPIO handled?
> I think it's very useful and has the potential to be agreed upon.

That would enable audio from the internal speakers but select debug
output on the HP jack by default. I would be okay with that, despite
still thinking that audio on the head phones should be the default.

Maxime and Wens are the maintainers, so it's their call in the end.

HTE,
Harald

_______________________________________________
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
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 [this message]
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=E1gv6rh-0000Km-U8@stardust.g4.wien.funkfeuer.at \
    --to=harald@ccbib.org \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=duwe@lst.de \
    --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