From: "Nícolas F. R. A. Prado" <nfraprado@collabora.com> To: Takashi Iwai <tiwai@suse.com> Cc: kernel@collabora.com, "Nícolas F. R. A. Prado" <nfraprado@collabora.com>, "AngeloGioacchino Del Regno" <angelogioacchino.delregno@collabora.com>, "Jaroslav Kysela" <perex@perex.cz>, "Mark Brown" <broonie@kernel.org>, "Matthias Brugger" <matthias.bgg@gmail.com>, "Shuah Khan" <shuah@kernel.org>, alsa-devel@alsa-project.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mediatek@lists.infradead.org Subject: [RFC PATCH] kselftest/alsa: Add configuration for mt8192-asurada-spherion Date: Thu, 21 Sep 2023 17:07:42 -0400 [thread overview] Message-ID: <20230921210800.230330-1-nfraprado@collabora.com> (raw) Add a configuration file for the mt8192-asurada-spherion platform to validate that the card and PCMs used for speaker, headphone and microphones (internal and headset) are correctly exposed to userspace. Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> --- Sending this patch as RFC because I'd like to ask a question. What would be the most suitable entry to identify the card in a future-proof way? I have used the card ID here, but given that it is generated at runtime with the purpose of being unique among the cards present on the system (and I couldn't find any documentation that states it is stable), I'm not sure it is supposed to be relied on. The card ID is derived from the driver name or card longname, which are themselves stable given userspace (alsa-ucm-conf) relies on them, but those aren't exposed through sysfs so I can't check for them here. Another option would be to look for the card number 0. But in the (very unlikely) case that another soundcard would be connected to the platform and detected first during boot, it wouldn't work. Yet another option would be to look at the device's uevent file for the compatible as defined in the Devicetree, ie path "device/uevent" regex "OF_COMPATIBLE_.*=mediatek,mt8192_mt6359_rt1015p_rt5682" Though it is possible (in rare circumstances) for the compatible in the Devicetree to need to be updated to enable a driver behavior that isn't backward compatible. I realize most of these issues are very rare and probably won't ever occur, but it seems worthwhile to use the most future-proof mechanism available to identify the card to avoid unnecessary maintenance, even more so considering the example would be followed by future configurations. Thanks, Nícolas .../alsa/conf.d/mt8192-asurada-spherion.conf | 32 +++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 tools/testing/selftests/alsa/conf.d/mt8192-asurada-spherion.conf diff --git a/tools/testing/selftests/alsa/conf.d/mt8192-asurada-spherion.conf b/tools/testing/selftests/alsa/conf.d/mt8192-asurada-spherion.conf new file mode 100644 index 000000000000..6a7e15dc17da --- /dev/null +++ b/tools/testing/selftests/alsa/conf.d/mt8192-asurada-spherion.conf @@ -0,0 +1,32 @@ +sysfs [ + { + path "firmware/devicetree/base/compatible" + regex "google,spherion" + } +] + +card.mt8192 { + sysfs [ + { + path "id" + regex "mt8192mt6359rt1" + } + ] + + pcm.0.0 { + PLAYBACK { + } + } + pcm.3.0 { + PLAYBACK { + } + } + pcm.10.0 { + CAPTURE { + } + } + pcm.11.0 { + CAPTURE { + } + } +} -- 2.42.0
WARNING: multiple messages have this Message-ID (diff)
From: "Nícolas F. R. A. Prado" <nfraprado@collabora.com> To: Takashi Iwai <tiwai@suse.com> Cc: kernel@collabora.com, "Nícolas F. R. A. Prado" <nfraprado@collabora.com>, "AngeloGioacchino Del Regno" <angelogioacchino.delregno@collabora.com>, "Jaroslav Kysela" <perex@perex.cz>, "Mark Brown" <broonie@kernel.org>, "Matthias Brugger" <matthias.bgg@gmail.com>, "Shuah Khan" <shuah@kernel.org>, alsa-devel@alsa-project.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mediatek@lists.infradead.org Subject: [RFC PATCH] kselftest/alsa: Add configuration for mt8192-asurada-spherion Date: Thu, 21 Sep 2023 17:07:42 -0400 [thread overview] Message-ID: <20230921210800.230330-1-nfraprado@collabora.com> (raw) Add a configuration file for the mt8192-asurada-spherion platform to validate that the card and PCMs used for speaker, headphone and microphones (internal and headset) are correctly exposed to userspace. Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> --- Sending this patch as RFC because I'd like to ask a question. What would be the most suitable entry to identify the card in a future-proof way? I have used the card ID here, but given that it is generated at runtime with the purpose of being unique among the cards present on the system (and I couldn't find any documentation that states it is stable), I'm not sure it is supposed to be relied on. The card ID is derived from the driver name or card longname, which are themselves stable given userspace (alsa-ucm-conf) relies on them, but those aren't exposed through sysfs so I can't check for them here. Another option would be to look for the card number 0. But in the (very unlikely) case that another soundcard would be connected to the platform and detected first during boot, it wouldn't work. Yet another option would be to look at the device's uevent file for the compatible as defined in the Devicetree, ie path "device/uevent" regex "OF_COMPATIBLE_.*=mediatek,mt8192_mt6359_rt1015p_rt5682" Though it is possible (in rare circumstances) for the compatible in the Devicetree to need to be updated to enable a driver behavior that isn't backward compatible. I realize most of these issues are very rare and probably won't ever occur, but it seems worthwhile to use the most future-proof mechanism available to identify the card to avoid unnecessary maintenance, even more so considering the example would be followed by future configurations. Thanks, Nícolas .../alsa/conf.d/mt8192-asurada-spherion.conf | 32 +++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 tools/testing/selftests/alsa/conf.d/mt8192-asurada-spherion.conf diff --git a/tools/testing/selftests/alsa/conf.d/mt8192-asurada-spherion.conf b/tools/testing/selftests/alsa/conf.d/mt8192-asurada-spherion.conf new file mode 100644 index 000000000000..6a7e15dc17da --- /dev/null +++ b/tools/testing/selftests/alsa/conf.d/mt8192-asurada-spherion.conf @@ -0,0 +1,32 @@ +sysfs [ + { + path "firmware/devicetree/base/compatible" + regex "google,spherion" + } +] + +card.mt8192 { + sysfs [ + { + path "id" + regex "mt8192mt6359rt1" + } + ] + + pcm.0.0 { + PLAYBACK { + } + } + pcm.3.0 { + PLAYBACK { + } + } + pcm.10.0 { + CAPTURE { + } + } + pcm.11.0 { + CAPTURE { + } + } +} -- 2.42.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2023-09-21 21:32 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-09-21 21:07 Nícolas F. R. A. Prado [this message] 2023-09-21 21:07 ` [RFC PATCH] kselftest/alsa: Add configuration for mt8192-asurada-spherion Nícolas F. R. A. Prado
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=20230921210800.230330-1-nfraprado@collabora.com \ --to=nfraprado@collabora.com \ --cc=alsa-devel@alsa-project.org \ --cc=angelogioacchino.delregno@collabora.com \ --cc=broonie@kernel.org \ --cc=kernel@collabora.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-kselftest@vger.kernel.org \ --cc=linux-mediatek@lists.infradead.org \ --cc=matthias.bgg@gmail.com \ --cc=perex@perex.cz \ --cc=shuah@kernel.org \ --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: linkBe 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.