From: Cezary Rojewski <cezary.rojewski@intel.com>
To: "Jaroslav Kysela" <perex@perex.cz>,
"Amadeusz Sławiński" <amadeuszx.slawinski@linux.intel.com>,
"Takashi Iwai" <tiwai@suse.com>,
"Mark Brown" <broonie@kernel.org>
Cc: <linux-sound@vger.kernel.org>
Subject: Re: [PATCH] ASoC: core: Change device numbering
Date: Wed, 29 Jan 2025 10:25:50 +0100 [thread overview]
Message-ID: <811c03ef-03a2-44a3-969b-5a2d55f2f876@intel.com> (raw)
In-Reply-To: <6fcbc9d3-93d4-4485-9f9f-5bef61476ef3@perex.cz>
On 2025-01-27 3:54 PM, Jaroslav Kysela wrote:
> On 27. 01. 25 15:45, Amadeusz Sławiński wrote:
>> On 1/27/2025 3:44 PM, Amadeusz Sławiński wrote:
>>> Currently ASoC cards when enumerating create CPUs rtds first and CODECs
>>> rtds second. This causes device number on cards to not start from 0, but
>>> from number of present CPUs. During that it does count number of rtds
>>> and uses it as device number visible in userspace.
>>>
>>> This patch changes device visible to userspace, when listing cards:
>>>
>>> Before:
>>> card 0: hdaudioB0D0 [hdaudioB0D0], device 1: HDAudio Analog (*) []
>>> card 1: hdaudioB0D2 [hdaudioB0D2], device 1: HDMI1 (*) []
>>> card 1: hdaudioB0D2 [hdaudioB0D2], device 2: HDMI2 (*) []
>>> card 1: hdaudioB0D2 [hdaudioB0D2], device 3: HDMI3 (*) []
>>>
>>> After:
>>> card 0: hdaudioB0D0 [hdaudioB0D0], device 0: HDAudio Analog (*) []
>>> card 1: hdaudioB0D2 [hdaudioB0D2], device 0: HDMI1 (*) []
>>> card 1: hdaudioB0D2 [hdaudioB0D2], device 1: HDMI2 (*) []
>>> card 1: hdaudioB0D2 [hdaudioB0D2], device 2: HDMI3 (*) []
>>>
>>> It is done by skipping back end devices and only counting front end
>>> ones.
>>>
>>> Now there are few concerns I have:
>>> - while rtd->id is not used much, few drivers seem to be using it as
>>> index into a table, above may break this use (although
>>> "include/sound/simple_card_utils.h: * the ID stored in rtd->id
>>> may not be a valid array index."
>>> suggests that maybe it is a bad idea anyway, but I'm not sure how
>>> generic that comment is)
>>> - this will break user scripts, with hardcoded device IDs
>>> - this will also break some UCMs with hardcoded IDs
>>>
>>> Now my main question is, if such patch would even be considered?
>>> Perhaps device IDs are not considered as "stable" interface and can be
>>> changed and my above worries are unnecessary.
>>>
>>> Patch is a result of discussion from:
>>> https://github.com/alsa-project/alsa-ucm-conf/pull/499
>>> and as such I may consider others ways of fixing the problem.
>>
>> And it should've been RFC in topic... :( Sorry about that.
>
> Looking to UCM configs, most of ASoC cards have PCM devices starting
> from zero. So this id is not used for all ASoC cards.
Most of the ASoC does not utilize topology and there is no strict
guideline: initialize FE first, BE last. What Amadeusz proposes is to
skip BEs when counting the 'devices' for the userspace as these are not
touchable by them anyway. I believe this is a good direction and does
not limit one's action when playing with the ASoC-topology feature.
> Also, a bit off-topic, but the driver name (hdaudioB?D?) for this
> particular driver should be corrected, too. It should be like 'hda-avs-
> dsp' or so. If I am not wrong, the SST driver name was 'hda-dsp'.
We had a discussion or two within the team and yes, we do agree that a
more user-friendly pattern should be provided. Currently card names are
mostly based on machine board device (platform_device) name. There is no
strong technical argument for that - the development was/is simply
focused on bringing new functionality and we did not prioritize the card
naming.
The task touches all interfaces though, not just HDA. We would like to
streamline or fix the naming for all the interfaces. This time we will
specifically request a review for that : )
Kind regards,
Czarek
next prev parent reply other threads:[~2025-01-29 9:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-27 14:44 [PATCH] ASoC: core: Change device numbering Amadeusz Sławiński
2025-01-27 14:45 ` Amadeusz Sławiński
2025-01-27 14:54 ` Jaroslav Kysela
2025-01-29 9:25 ` Cezary Rojewski [this message]
2025-01-29 14:51 ` Amadeusz Sławiński
2025-01-31 9:03 ` Jaroslav Kysela
2025-01-31 12:41 ` Amadeusz Sławiński
2025-01-31 16:18 ` Jaroslav Kysela
2025-02-11 10:53 ` Amadeusz Sławiński
2025-02-11 13:30 ` Jaroslav Kysela
2025-02-11 13:33 ` Takashi Iwai
2025-02-11 13:56 ` Amadeusz Sławiński
2025-02-11 14:50 ` Jaroslav Kysela
2025-02-11 15:12 ` Amadeusz Sławiński
2025-02-12 13:39 ` Jaroslav Kysela
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=811c03ef-03a2-44a3-969b-5a2d55f2f876@intel.com \
--to=cezary.rojewski@intel.com \
--cc=amadeuszx.slawinski@linux.intel.com \
--cc=broonie@kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=perex@perex.cz \
--cc=tiwai@suse.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