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: Fri, 11 Feb 2022 15:42:40 +0100 [thread overview]
Message-ID: <1dab33cb-c20e-1134-cdf2-e03209018318@intel.com> (raw)
In-Reply-To: <4d90d851-753e-3e6d-b51a-eefb2159a48c@linux.intel.com>
On 2022-02-09 5:08 PM, Pierre-Louis Bossart wrote:
>
>
> On 2/9/22 06:05, Cezary Rojewski wrote:
>> I believe our goals align. Rather than hardcoding Analog/Alt
>> Analog/Digital endpoints as it's done currently, when codec most of the
>> time do not have them working anyway, rely on behavior found in
>> sound/hda and sound/pci/hda. If there are some problems there it's
>> win:win for us and legacy driver. Fix one spot, have both drivers happy.
>
> I don't quite see the alignment: the only thing that we've seen work
> reliably and that we do need is the analog part, and we want to get rid
> of the other paths which we can't test in the first place. I must admit
> I don't recall why we bothered to expose those alt analog and digital
> paths back in 2018, they have not been used nor tested by anyone.
>
> Now if this patch helped to make sure we do indeed have an analog path,
> that'd be fine. That would indeed avoid a hard-coded decision and report
> configuration errors.
>
> I just don't see what exposing additional paths brings, they never
> worked reliably for us when we tried. IIRC half of our team gets an
> error with the Digital playback stream on Up Extreme and the other half
> can play just fine - albeit with no connector to actually see what the
> output is.
>
> FWIW there are many things made possible by HDaudio, in practice we
> often have to limit ourselves to what is known to work and what is
> needed by end-products. You could spend all your time chasing
> configuration issues, missing NIDS and bad verbs. Been there, done that.
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.
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.
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.
Regards,
Czarek
next prev parent reply other threads:[~2022-02-11 14:43 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 [this message]
2022-02-11 15:23 ` Pierre-Louis Bossart
2022-02-14 9:54 ` Cezary Rojewski
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=1dab33cb-c20e-1134-cdf2-e03209018318@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