From: Cezary Rojewski <cezary.rojewski@intel.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
Kai Vehmanen <kai.vehmanen@linux.intel.com>
Cc: alsa-devel@alsa-project.org, upstream@semihalf.com,
harshapriya.n@intel.com, rad@semihalf.com, tiwai@suse.com,
hdegoede@redhat.com, broonie@kernel.org,
cujomalainey@chromium.org, lma@semihalf.com
Subject: Re: [PATCH 3/4] ALSA: hda: Update and expose codec register procedures
Date: Mon, 14 Feb 2022 10:54:45 +0100 [thread overview]
Message-ID: <4a2dcca4-0909-4937-4f3b-5444fd8d15ae@intel.com> (raw)
In-Reply-To: <9d90f640-041c-b29b-6161-c35c78d9250a@linux.intel.com>
On 2022-02-11 4:23 PM, Pierre-Louis Bossart wrote:
>
>> Again, we are not trying to force-expose stuff which does not work. In
>> majority of the cases, non-HDMI codecs we're dealing with notify about
>> just single analog endpoint. For now, it's 100% of the cases, but I'm
>> aware of fact that RVPs and a dozen of Dell/Lenovo/Acer laptops do not
>> equal to entire market.
>
> We are in agreement, but since we don't have any ability to test those
> alt/digital parts my take is 'don't even bother about them'.
>
>> Remember that you can always use topology to "gate" userspace from
>> streaming through endpoints which we do not work. And right now, we are
>> working with topologies supporting single endpoint for non-HDMI devices.
>
> May I ask how you 'gate' parts of a topology? Or did you mean that you
> use different topologies?
>
>>
>> So, this is a clear upgrade when compared to Analog/Alt
>> Analog/Digitalh-hardcoded configuration used currently. That's on top of
>> aligning with hda legacy behavior.
>
> Agree, but it still leaves the door open to exposing those paths which
> may or may not work - no one has ever tested them. It's better IMHO to
> only allow for the analog path. If we can detect the presence of this
> path, great.
You may define topology with lower number of FE, thus limiting number of
options available to user, possibly shielding them from untested
scenarios. E.g.: Have a 3-DAI HDMI codec yet provide 2-FE topology file
for it because you know 3rd endpoint is faulty. Only two devices will
show up in userspace effectively making users unable to play on the 3rd one.
Again, that's a default - expose fewer endpoints (here, just single
analog one) for non-HDMI codecs.
Of course, there is small number of users who may want to stream on
their Alt Analog/Digital endpoints. We do not want 'Conexant story' to
repeat all over again. So, for them, non-default (topology) could be
provided to enable streaming on whatever they want.
The chosen approach does not hinder either of the sides.
Regards,
Czarek
next prev parent reply other threads:[~2022-02-14 9:56 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-07 11:49 [PATCH 0/4] ALSA: hda: Expose codec organization functions Cezary Rojewski
2022-02-07 11:49 ` [PATCH 1/4] ALSA: hda: Add snd_hdac_ext_bus_link_at() helper Cezary Rojewski
2022-02-07 11:49 ` [PATCH 2/4] ALSA: hda: Update and expose snd_hda_codec_device_init() Cezary Rojewski
2022-02-07 11:49 ` [PATCH 3/4] ALSA: hda: Update and expose codec register procedures Cezary Rojewski
2022-02-08 15:54 ` Kai Vehmanen
2022-02-08 16:34 ` Cezary Rojewski
2022-02-08 17:14 ` Takashi Iwai
2022-02-09 10:21 ` Cezary Rojewski
2022-02-09 10:38 ` Cezary Rojewski
2022-02-09 14:19 ` Takashi Iwai
2022-02-08 17:46 ` Pierre-Louis Bossart
2022-02-09 12:05 ` Cezary Rojewski
2022-02-09 16:08 ` Pierre-Louis Bossart
2022-02-11 14:42 ` Cezary Rojewski
2022-02-11 15:23 ` Pierre-Louis Bossart
2022-02-14 9:54 ` Cezary Rojewski [this message]
2022-02-07 11:49 ` [PATCH 4/4] ALSA: hda: Expose codec cleanup and power-save functions Cezary Rojewski
2022-02-07 12:35 ` [PATCH 0/4] ALSA: hda: Expose codec organization functions Pierre-Louis Bossart
2022-02-08 10:00 ` Cezary Rojewski
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=4a2dcca4-0909-4937-4f3b-5444fd8d15ae@intel.com \
--to=cezary.rojewski@intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=cujomalainey@chromium.org \
--cc=harshapriya.n@intel.com \
--cc=hdegoede@redhat.com \
--cc=kai.vehmanen@linux.intel.com \
--cc=lma@semihalf.com \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=rad@semihalf.com \
--cc=tiwai@suse.com \
--cc=upstream@semihalf.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