From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Mark Brown <broonie@kernel.org>
Cc: tiwai@suse.de, alsa-devel@alsa-project.org
Subject: Re: [RFC PATCH 0/3] alsa-lib/ASoC: use inclusive language for bclk/fsync/topology
Date: Tue, 8 Sep 2020 08:36:03 -0500 [thread overview]
Message-ID: <d5682ba4-c487-ef68-ff15-fd51ec655cf1@linux.intel.com> (raw)
In-Reply-To: <20200904085058.GA4625@sirena.org.uk>
On 9/4/20 3:50 AM, Mark Brown wrote:
> On Thu, Sep 03, 2020 at 04:32:22PM -0500, Pierre-Louis Bossart wrote:
>> On 9/3/20 3:42 PM, Jaroslav Kysela wrote:
>
>>>
>>> Only my 2 cents: It's just another word combo. See bellow for sources for others.
>>>
>>> I would prefer probably provider/consumer . It sounds more technic.
>
>> Thanks Jaroslav for chiming in. I had a similar set of comments in internal
>> reviews, but we didn't really have any consensus and I have not seen good
>> guidance specifically for clocks.
>
>> Provider/consumer is typically used for discrete data exchange with some
>> sort of locking and buffer fullness metric, but for clocks we'd want
>> something that hints at one device following the timing defined by another.
>
>> "follow" or "track" seem clearer than 'consume' IMHO, but I will side with
>> the majority, this is an RFC which can be modified at will.
>
> Producer/consumer is already quite widely used for clocks (possibly
> following the regulator API which was templated off the clock API and
> uses consumer). The follow/track stuff definitely seems awkward to me.
> Have we seen any movement from anyone like CODEC vendors on this?
No, I haven't seen any input from CODEC vendors.
I'll use consumer then since that's preferred by both Jaroslav and Mark.
Thanks for the feedback.
prev parent reply other threads:[~2020-09-08 14:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-03 20:10 [RFC PATCH 0/3] alsa-lib/ASoC: use inclusive language for bclk/fsync/topology Pierre-Louis Bossart
2020-09-03 20:10 ` [RFC PATCH 1/3] topology: use inclusive language for bclk Pierre-Louis Bossart
2020-09-04 9:10 ` Takashi Iwai
2020-09-08 13:39 ` Pierre-Louis Bossart
2020-09-08 14:35 ` Mark Brown
2020-09-08 14:41 ` Pierre-Louis Bossart
2020-09-08 14:45 ` Jaroslav Kysela
2020-09-08 17:28 ` Mark Brown
2020-09-03 20:10 ` [RFC PATCH 2/3] topology: use inclusive language for fsync Pierre-Louis Bossart
2020-09-03 20:10 ` [RFC PATCH 3/3] topology: use inclusive language in documentation Pierre-Louis Bossart
2020-09-03 20:42 ` [RFC PATCH 0/3] alsa-lib/ASoC: use inclusive language for bclk/fsync/topology Jaroslav Kysela
2020-09-03 21:32 ` Pierre-Louis Bossart
2020-09-04 8:50 ` Mark Brown
2020-09-08 13:36 ` 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=d5682ba4-c487-ef68-ff15-fd51ec655cf1@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox