From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org, broonie@kernel.org
Subject: Re: [PATCH 0/3] alsa-lib/ASoC: use inclusive language for bclk/fsync/topology
Date: Tue, 29 Sep 2020 08:44:36 -0500 [thread overview]
Message-ID: <70ed2326-3271-e237-323e-09e17d501b7f@linux.intel.com> (raw)
In-Reply-To: <s5hlfgtkq4r.wl-tiwai@suse.de>
>> The SOF (Sound Open Firmware) tree contains a lot of references in
>> topology files to 'codec_slave'/'codec_master' terms, which in turn
>> come from alsa-lib and ALSA/ASoC topology support at the kernel
>> level. These terms are no longer compatible with the guidelines
>> adopted by the kernel community [1] and need to change in
>> backwards-compatible ways.
>>
>> The main/secondary terms typically suggested in guidelines don't mean
>> anything for clocks, this patchset suggests instead the use of
>> 'provider' and 'consumer' terms, with the 'codec' prefix kept to make
>> it clear that the codec is the reference. The CM/CS suffixes are also
>> replaced by CP/CC.
>>
>> It can be argued that the change of suffix is invasive, but finding a
>> replacement that keeps the M and S shortcuts has proven difficult in
>> quite a few contexts.
>>
>> The previous definitions are kept for backwards-compatibility so this
>> change should not have any functional impact. It is suggested that new
>> contributions only use the new terms but there is no requirement to
>> transition immediately to the new definitions for existing code. Intel
>> will however update all its past contributions related to bit
>> clock/frame sync configurations immediately.
>>
>> This suggestion is easier to review first at the alsa-lib level, and
>> if agreed follow-up contributions for the Linux kernel [2] and SOF
>> firmware [3] will be provided.
>
> It's OK from alsa-lib POV; although the uapi header change isn't 100%
> safe, the user of this header is really our ones, so it's practically
> acceptable, I suppose.
>
> Could you submit the changes for kernel, so that it can be merged in
> time? Basically alsa-lib is synced with kernel, so the kernel should
> be changed at first.
Ack, will do, thanks for the review.
prev parent reply other threads:[~2020-09-29 15:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-18 21:28 [PATCH 0/3] alsa-lib/ASoC: use inclusive language for bclk/fsync/topology Pierre-Louis Bossart
2020-09-18 21:28 ` [PATCH 1/3] topology: use inclusive language for bclk Pierre-Louis Bossart
2020-09-18 21:28 ` [PATCH 2/3] topology: use inclusive language for fsync Pierre-Louis Bossart
2020-09-18 21:28 ` [PATCH 3/3] topology: use inclusive language in documentation Pierre-Louis Bossart
2020-09-29 7:18 ` [PATCH 0/3] alsa-lib/ASoC: use inclusive language for bclk/fsync/topology Takashi Iwai
2020-09-29 13:44 ` Pierre-Louis Bossart [this message]
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=70ed2326-3271-e237-323e-09e17d501b7f@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.