From: Cezary Rojewski <cezary.rojewski@intel.com>
To: Mark Brown <broonie@kernel.org>,
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Linux-ALSA <alsa-devel@alsa-project.org>,
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Subject: Re: About Cleanup ASoC
Date: Tue, 24 May 2022 17:06:49 +0200 [thread overview]
Message-ID: <41033b5b-5bde-10a2-70e8-aa7482992235@intel.com> (raw)
In-Reply-To: <YozcfjgvFfQa/HxS@sirena.org.uk>
On 2022-05-24 3:24 PM, Mark Brown wrote:
> On Tue, May 24, 2022 at 04:40:24AM +0000, Kuninori Morimoto wrote:
>
>> I have very interesting to clean up ASoC.
>> I think it is still very complex, thus, non flexible.
>> I'm thinking that we want to cleanup...
>>
>> - Component with multi Card connection
>
> I'm really not certain that we want components in multiple cards at all,
> I know the Intel AVS people wanted this but I'm concerned that if a
> single component is in multiple cards we'll inevitably have connections
> between the cards which each needs to take into consideration, that
> could be routing or something else like clock configuration.
Hello,
It seems explanation of design of the avs-driver had some shortcomings.
The AVS people (like me) are to blame for this :S
The exact opposite is true - we do not want 1:N component:card relation.
Separate set of components and a separate card (machine board) per
logically separate audio device is the approach of choice here. It has
its benefits of simplifying PM and allowing for better user experience -
probe() failure of one device does not prevent other devices from
enumerating.
Regards,
Czarek
next prev parent reply other threads:[~2022-05-24 15:08 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-24 4:40 About Cleanup ASoC Kuninori Morimoto
2022-05-24 11:17 ` Amadeusz Sławiński
2022-05-24 14:53 ` Cezary Rojewski
2022-05-25 2:54 ` Kuninori Morimoto
2022-05-25 16:11 ` Pierre-Louis Bossart
2022-05-26 2:13 ` Kuninori Morimoto
2022-05-26 9:57 ` Amadeusz Sławiński
2022-05-26 13:48 ` Pierre-Louis Bossart
2022-05-26 13:58 ` Mark Brown
2022-05-26 14:17 ` Cezary Rojewski
2022-05-26 14:45 ` Pierre-Louis Bossart
2022-05-27 6:50 ` Kuninori Morimoto
2022-05-31 12:25 ` Mark Brown
2022-06-01 6:13 ` Kuninori Morimoto
2022-06-02 9:26 ` Cezary Rojewski
2022-06-02 23:57 ` Kuninori Morimoto
2022-06-07 7:46 ` Cezary Rojewski
2022-06-09 0:07 ` Kuninori Morimoto
2022-05-27 8:38 ` Cezary Rojewski
2022-05-31 14:37 ` Pierre-Louis Bossart
2022-05-24 13:24 ` Mark Brown
2022-05-24 15:06 ` Cezary Rojewski [this message]
2022-05-24 16:11 ` Pierre-Louis Bossart
2022-05-25 3:02 ` Kuninori Morimoto
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=41033b5b-5bde-10a2-70e8-aa7482992235@intel.com \
--to=cezary.rojewski@intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=pierre-louis.bossart@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 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.