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

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	[thread overview]
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