Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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