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

[Torsten Duwe <duwe@lst.de>]

On Sat, 16 Feb 2019 21:47:13 +0100
Harald Geyer <harald@ccbib.org> wrote:
> Torsten Duwe writes:

> > 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.

No, that rule applies to mechanisms, not configuration. It's not a
problem if a device disappears completely, especially when it's
optional. For clarity's sake, imagine to drop a .dtbo on the fdt that
disables or removes it, after U-Boot has set it.

> > 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.

The kernel driver will use whatever the boot preset is; and a
production U-Boot should set that to audio.

> I would be okay with that, despite
> still thinking that audio on the head phones should be the default.

Yes, for production use. For kernel debugging, hack it in U-Boot.
The audio driver should be the last to care.

Imagine you are debugging a boot problem on the serial console and all
of a sudden it stops working just because the audio driver kicks in!

Should any driver ever be in control of that GPIO, it must not be
audio, IMO.

	Torsten