Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / Atom feed
From: Harald Geyer <harald@ccbib.org>
To: 20190201113743.10058-1-harald@ccbib.org
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: Mon, 11 Feb 2019 14:36:53 +0100
Message-ID: <E1gtBlV-0000Wl-Cv@stardust.g4.wien.funkfeuer.at> (raw)
In-Reply-To: <20190211111245.GA18147@lst.de>

Hi Torsten!

Torsten Duwe writes:
> > hpvcc-supply vs. cpvdd-supply:
> > On the A64 manual the pin is called CPVDD and the binding documents
> > requires a cpvdd-supply property. However in the actual driver and
> > devicetrees so far hpvcc-supply is used. This is a very new binding,
> > so we have the luxury to decide either way, I think. Any input from
> > the devicetree maintainers would be appreciated.
> 
> I don't really have a strong opinion here, besides settling this ASAP,
> to minimise confusion.

Yeah, given that this issue was introduced only in 5.0 and 5.0 is
almost out of the door, I'd have believed people to be more eager to
get this fixed soon.

Well, if nobody speaks up, I'll just include a patch to change the
binding to match the source in the next version of my submission.

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

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

Using something like your leds hack in the linux DT would be fine for
me, if the maintainers are willing to accept it.

As it is, I'm currently working on supporting "output-high" property
in pinctrl-sunxi.
 
> > Testing:
> > I don't have a headset with combo connector, so I could only test the
> > headphones output, but not the headset mic. If somebody happens to
> > have a TERES-I and a suitable headset, testing this would be nice.
> 
> The pinout required is the "CTIA" one, *not* OMTP (standards are great...) see
> https://source.android.com/devices/accessories/headset/plug-headset-spec#mechanical
> 
> I do have a compatible headset, but was neither able to record from the HS mic
> nor from the internal mic, so I have to try harder, I guess ;-) I could hear
> both mics when choosing the mixer as output source though. Mute and boost
> worked for both mics, in alsamixer.

Probably you need to enable more controls in alsamixer.
"AIF1 Data Digital ADC" comes to mind as a plausible candidate.

> Kernel is 4.20.6, so ca0412a05756cd0b
> is missing; which shouldn't make a difference in this respect, right?

I suppose not, but I didn't actually test audio on 4.20.

Thanks,
Harald

-- 
If you want to support my work:
see http://friends.ccbib.org/harald/supporting/
or donate via CLAM to xASPBtezLNqj4cUe8MT5nZjthRSEjrRQXN
or via peercoin to P98LRdhit3gZbHDBe7ta5jtXrMJUms4p7w

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

       reply index

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20190211111245.GA18147@lst.de>
2019-02-11 13:36 ` Harald Geyer [this message]
2019-02-11 15:39   ` Maxime Ripard
2019-02-11 19:32     ` Harald Geyer
2019-02-12  8:38       ` Maxime Ripard
2019-02-12  9:42         ` Harald Geyer
2019-02-12 10:09           ` Maxime Ripard
2019-02-12 19:37             ` Harald Geyer
2019-02-13  9:44               ` Maxime Ripard
2019-02-13 11:43                 ` Harald Geyer
2019-02-13 15:53                   ` Maxime Ripard
2019-02-14  0:12                     ` Harald Geyer
2019-02-15 14:20                       ` Torsten Duwe
2019-02-16 20:47                         ` Harald Geyer
2019-02-17 11:30                           ` Torsten Duwe
2019-02-18 10:24                           ` Maxime Ripard
2019-04-30 13:32                             ` Torsten Duwe
2019-05-02  7:46                               ` Maxime Ripard
2019-05-02 14:48                                 ` Harald Geyer
2019-02-01 11:37 Harald Geyer
2019-02-12  8:34 ` Chen-Yu Tsai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E1gtBlV-0000Wl-Cv@stardust.g4.wien.funkfeuer.at \
    --to=harald@ccbib.org \
    --cc=20190201113743.10058-1-harald@ccbib.org \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=ibu@radempa.de \
    --cc=info@olimex.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=maxime.ripard@bootlin.com \
    --cc=robh+dt@kernel.org \
    --cc=wens@csie.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-ARM-Kernel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/0 linux-arm-kernel/git/0.git
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/1 linux-arm-kernel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-arm-kernel linux-arm-kernel/ https://lore.kernel.org/linux-arm-kernel \
		linux-arm-kernel@lists.infradead.org
	public-inbox-index linux-arm-kernel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-arm-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git