From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: alsa-devel@alsa-project.org, tiwai@suse.de,
liam.r.girdwood@linux.intel.com, broonie@kernel.org,
Bard liao <yung-chuan.liao@linux.intel.com>,
bard.liao@intel.com
Subject: Re: [alsa-devel] [PATCH RFC v2 0/4] ASoC: Add Multi CPU DAI support
Date: Wed, 15 Jan 2020 19:20:54 -0600 [thread overview]
Message-ID: <5f3318cd-4f9e-6c0f-b58f-53eb6271c69d@linux.intel.com> (raw)
In-Reply-To: <87pnfk1b2w.wl-kuninori.morimoto.gx@renesas.com>
>> After this series of patches is applied, we have this in soc.h:
>>
>> struct snd_soc_dai *codec_dai;
>> struct snd_soc_dai *cpu_dai;
>>
>> struct snd_soc_dai **codec_dais;
>> unsigned int num_codecs;
>>
>> struct snd_soc_dai **cpu_dais;
>> unsigned int num_cpus;
>>
>> What is the intent behind keeping the two fields codec_dai and cpu_dai?
>>
>> Shouldn't we use the multi-dai structures in all cases, possible
>> degraded to a single element rather than maintaining what looks like
>> duplicate ways of accessing the same element?
>>
>> If removing these fields across all drivers is just too invasive for
>> now, shouldn't we start defining access macros so that those fields
>> can be deprecated and removed at a later time, platform-by-platform?
>
> Actually, I have this patch (= remove cpu_dai/codec_dai from all drivers,
> and use macro for it), and have plan to post it.
>
> But, I have many extra cleanup patches in my tree,
> and I want to post it before that
> (to avoid extra re-ordering dpendency break).
ok, thanks for the precisions!
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
next prev parent reply other threads:[~2020-01-16 1:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-14 17:51 [alsa-devel] [PATCH RFC v2 0/4] ASoC: Add Multi CPU DAI support Bard liao
2020-01-14 17:51 ` [alsa-devel] [PATCH RFC v2 1/4] ASoC: Add initial support for multiple CPU DAIs Bard liao
2020-01-14 17:51 ` [alsa-devel] [PATCH RFC v2 2/4] ASoC: Add multiple CPU DAI support for PCM ops Bard liao
2020-01-16 1:48 ` Pierre-Louis Bossart
2020-01-16 2:05 ` Liao, Bard
2020-01-16 2:25 ` Pierre-Louis Bossart
2020-01-14 17:51 ` [alsa-devel] [PATCH RFC v2 3/4] ASoC: Add multiple CPU DAI support in DAPM Bard liao
2020-01-14 17:51 ` [alsa-devel] [PATCH RFC v2 4/4] ASoC: add warning if the function is not support multi cpu yet Bard liao
2020-01-16 1:49 ` Pierre-Louis Bossart
2020-01-16 7:42 ` Liao, Bard
2020-01-17 0:45 ` Kuninori Morimoto
2020-01-15 6:11 ` [alsa-devel] [PATCH RFC v2 0/4] ASoC: Add Multi CPU DAI support Kuninori Morimoto
2020-01-15 22:13 ` Pierre-Louis Bossart
2020-01-16 0:47 ` Kuninori Morimoto
2020-01-16 1:20 ` Pierre-Louis Bossart [this message]
2020-01-16 1:52 ` Pierre-Louis Bossart
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=5f3318cd-4f9e-6c0f-b58f-53eb6271c69d@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=bard.liao@intel.com \
--cc=broonie@kernel.org \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=liam.r.girdwood@linux.intel.com \
--cc=tiwai@suse.de \
--cc=yung-chuan.liao@linux.intel.com \
/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;
as well as URLs for NNTP newsgroup(s).