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

[Maxime Ripard <maxime.ripard@bootlin.com>]

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