Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Cezary Rojewski <cezary.rojewski@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: Wed, 9 Feb 2022 10:08:09 -0600	[thread overview]
Message-ID: <4d90d851-753e-3e6d-b51a-eefb2159a48c@linux.intel.com> (raw)
In-Reply-To: <23f36ba1-277c-6998-f569-2861887720dd@intel.com>



On 2/9/22 06:05, Cezary Rojewski wrote:
>> FWIW, in our latest SOF work we went back to handling ONE DAI with
>> analog playback and capture and ditched the 'digital playback'. Trying
>> to do more led us to too many issues of 'works on platform A' and 'does
>> not work on platform B', and sometimes with different answers depending
>> on which BIOS version is used.
>>
>> IMHO what's really problematic for HDaudio is the support for amplifiers
>> located behind the HDaudio codec, for which we more often than not are
>> missing the I2C configuration sequences. Suspend-resume is a recurring
>> problem as well.
>>
>> I am not saying no for the sake of saying no, I have just never heard of
>> anyone complain about restrictions on the number of DAIs in the HDaudio
>> world.
> 
> 
> 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.

  reply	other threads:[~2022-02-09 16:21 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 [this message]
2022-02-11 14:42             ` Cezary Rojewski
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=4d90d851-753e-3e6d-b51a-eefb2159a48c@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=cezary.rojewski@intel.com \
    --cc=cujomalainey@chromium.org \
    --cc=harshapriya.n@intel.com \
    --cc=hdegoede@redhat.com \
    --cc=kai.vehmanen@linux.intel.com \
    --cc=lma@semihalf.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