| Message ID | 20200918212832.249184-1-pierre-louis.bossart@linux.intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | alsa-lib/ASoC: use inclusive language for bclk/fsync/topology | expand |
On Fri, 18 Sep 2020 23:28:29 +0200, Pierre-Louis Bossart wrote: > > 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. thanks, Takashi > > Feedback welcome > ~Pierre > > [1] https://lkml.org/lkml/2020/7/4/229 > [2] https://github.com/plbossart/sound/tree/fix/inclusive-language-bclk-fsync > [3] https://github.com/plbossart/sof/tree/fix/inclusive-language-bclk-fsync > > Changes since RFC: > replaced 'follower' by 'consumer' as suggested by Jaroslav and Marc > minor cleanups > > Pierre-Louis Bossart (3): > topology: use inclusive language for bclk > topology: use inclusive language for fsync > topology: use inclusive language in documentation > > include/sound/uapi/asoc.h | 22 +++++++----- > include/topology.h | 8 ++--- > src/topology/pcm.c | 75 +++++++++++++++++++++++++++------------ > 3 files changed, 71 insertions(+), 34 deletions(-) > > -- > 2.25.1 >
>> 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.