From: Mark Brown <broonie@kernel.org>
To: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.de>,
ALSA development <alsa-devel@alsa-project.org>,
Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Subject: Re: ASoC driver names
Date: Fri, 24 Apr 2020 19:15:10 +0100 [thread overview]
Message-ID: <20200424181510.GJ5850@sirena.org.uk> (raw)
In-Reply-To: <0a1b7396-f7d9-b6a9-2e85-70517b5dc718@perex.cz>
[-- Attachment #1: Type: text/plain, Size: 2139 bytes --]
On Fri, Apr 24, 2020 at 07:11:46PM +0200, Jaroslav Kysela wrote:
> Dne 24. 04. 20 v 18:49 Mark Brown napsal(a):
> > So if it's not really going to be used for anything particularly
> > concrete then I'm having a hard time summoning the enthusiasm for a
> > change.
> The driver name is used as the directory name in UCM / UCM2. For DT, it
> means thousands possible directories (one per board / board + codec variant
> and so on..). The generic simple asoc card is a good example.
Sure, then you end up with a few directories with huge numbers of files
which seems similar? TBH if UCM weren't doing the directory thing it'd
be easier to see fixing the neatness issue, what UCM is doing means that
it's much more likely that people will notice a problem.
> > It feels more like a neatness thing than anything else and the
> > postitive case just isn't jumping out at me, certainly not as a thing to
> > force for everything. New stuff, sure. I guess I'm not bothered enough
> > to block any platform that has a burning desire to convert either though
> > if users start coming and complaining about kernel upgrades breaking
> > things we'd have to revert.
> :-( I don't propose to force one way. We can conditionally change the driver
> names using a well documented CONFIG_ option to keep compatibility with the
> older user space code. The new driver names may be selected manually in the
> kernel config.
That does provide some mitigation, though there's some potential for
confusion too. We could try it and see I guess.
> > > I would prefer to have the sound hardware description in the long name field
> > > than the whole hardware platform info here, too.
> > Does it also cope with the DT equivalents (and I guess there's nothing
> > we can do for board file based systems)? This stuff does get used for
> > embedded systems where the plastics are often important for the
> > configuration.
> The author of DT config knows what hardware is described, thus this person
> should be resposible for the nice GUI sound part name.
Assuming they're working on a system where the sound card name will be
displayed in a GUI.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-04-24 18:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-22 17:04 ASoC driver names Jaroslav Kysela
2020-04-22 20:23 ` Takashi Iwai
2020-04-23 11:04 ` Mark Brown
2020-04-23 11:19 ` Jaroslav Kysela
2020-04-23 16:13 ` Mark Brown
2020-04-23 16:17 ` Pierre-Louis Bossart
2020-04-23 18:40 ` Mark Brown
2020-04-24 8:52 ` Jaroslav Kysela
2020-04-24 16:49 ` Mark Brown
2020-04-24 17:11 ` Jaroslav Kysela
2020-04-24 18:15 ` Mark Brown [this message]
2020-04-24 19:03 ` Jaroslav Kysela
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=20200424181510.GJ5850@sirena.org.uk \
--to=broonie@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=perex@perex.cz \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=srinivas.kandagatla@linaro.org \
--cc=tiwai@suse.de \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox