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:
signature.asc
Description: PGP signature
