From: Harald Geyer <harald@ccbib.org> To: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Mark Rutland <mark.rutland@arm.com>, devicetree@vger.kernel.org, info@olimex.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: Tue, 12 Feb 2019 10:42:03 +0100 Message-ID: <E1gtUZn-0000NW-MA@stardust.g4.wien.funkfeuer.at> (raw) In-Reply-To: <20190212083850.7genwc6ipnxtl7eo@flea> Maxime Ripard writes: > On Mon, Feb 11, 2019 at 08:32:35PM +0100, Harald Geyer wrote: > > > 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. > > > > I considered this too, but didn't like it: > > > > 1) Seems like a bit of overkill. > > > > 2) The HW at hand is a rather different kind of multiplexer than > > what pinctrl assumes. We don't want two mutually exclusive devices, > > (Ie don't make the kernel unbind /dev/console for the sake of audio.) > > but we want switch the jack between two devices, that might both be > > active at the same time. This looks more like the channel multiplexers > > used with many ADCs and such. I guess, I could start a new subsystem > > around this. Seems like even more overkill. > > I'm not quite sure about how that's different from what pinctrl > assumes. pinctrl assumes to handle devices that have multiple signals > as input, and one as output. Isn't that exactly what you have? I think the pinctrl way would be to have the audio card device request the HP jack and the uart node request the HP jack and only once device could probe successfully. Ie it is about ressource allocation, not true multiplexing where both devices can use the ressource at the same time. Am I wrong? Or course we don't actually want true multiplexing for audio quality reasons, but I don't see how we could use pinctrl without doing nasty things to /dev/console ... > And pinctrl can be used dynamically as well if you need to Can you explain or point me to the relevant explanation in the docs? I don't seem to know about it. > > Instead I just got the original patch working, by implementing > > "output-high" DT property in sunxi-pinctrl. I'll send a patch for > > review soon. > > What do you want to do with output-high exactly? Exactly what I do in the patch that started this thread. (I'll resend when wens' cpvdd patch is available for me to rebase onto.) 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
next prev parent 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 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 [this message] 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=E1gtUZn-0000NW-MA@stardust.g4.wien.funkfeuer.at \ --to=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