From mboxrd@z Thu Jan 1 00:00:00 1970 From: Torsten Duwe Subject: Re: [PATCH RFC] arm64: dts: allwinner: a64: teres-i: Enable audio Date: Sun, 17 Feb 2019 12:30:05 +0100 Message-ID: <20190217123005.6684abf9@blackhole.lan> References: <20190211153945.e34fpwkuk67l7lc6@flea> <20190212083850.7genwc6ipnxtl7eo@flea> <20190212100929.iqsxu443qrkl6myf@flea> <20190213094442.da2dy6d5bb527nft@flea> <20190213155311.ovkpim3lxwyvuhhj@flea> <20190215142029.GB32618@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Harald Geyer Cc: Mark Rutland , devicetree@vger.kernel.org, info@olimex.com, Maxime Ripard , Mark Brown , Chen-Yu Tsai , Rob Herring , ibu@radempa.de, linux-arm-kernel@lists.infradead.org List-Id: devicetree@vger.kernel.org On Sat, 16 Feb 2019 21:47:13 +0100 Harald Geyer 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