public inbox for alsa-devel@alsa-project.org
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Cezary Rojewski <cezary.rojewski@intel.com>,
	Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org, upstream@semihalf.com,
	Kai Vehmanen <kai.vehmanen@linux.intel.com>,
	harshapriya.n@intel.com, rad@semihalf.com, tiwai@suse.com,
	hdegoede@redhat.com, amadeuszx.slawinski@linux.intel.com,
	cujomalainey@chromium.org, lma@semihalf.com
Subject: Re: [PATCH 02/14] ASoC: codecs: Add HD-Audio codec driver
Date: Fri, 6 May 2022 09:56:55 -0500	[thread overview]
Message-ID: <2849fc32-83b8-4727-0aea-aa20b4d3557a@linux.intel.com> (raw)
In-Reply-To: <4a808f4c-83fc-747d-1536-d276138e57b8@intel.com>



On 5/6/22 08:39, Cezary Rojewski wrote:
> On 2022-05-06 3:12 PM, Mark Brown wrote:
>> On Wed, Apr 27, 2022 at 10:47:12AM -0500, Pierre-Louis Bossart wrote:
>>> On 4/27/22 03:18, Cezary Rojewski wrote:
>>
>>>> Add generic ASoC equivalent of ALSA HD-Audio codec. This codec is
>>>> designed to follow HDA_DEV_LEGACY convention. Driver wrapps existing
>>>> hda_codec.c handlers to prevent code duplication within the newly added
>>
>>> I am surprised the explanations don't even mention the existence of
>>> hdac_hda.c
>>
>>> I thought the series was about adding machine drivers, but this
>>> also adds code on the sound/soc/codecs/ side which I didn't see
>>> coming.
>>
>>> I am not qualified to review this part of the code, I just
>>> wonder about duplication of functionality.
>>
>>> At the very least an explanation on why you decided to NOT use
>>> hdac_hda.c would be useful to reviewers and maintainers.
>>
>> Right, why the duplication here?  Can't we fix or extend the
>> existing code to do whatever it's not currently doing which
>> compels reimplementation?
> 
> Sorry for the late response, did not realize there is an unanswered
> comment here.
> 
> So, the rough list goes as:
> - hdac_hda.c hardcodes codec capabilities rather than aligning with what
> sound/pci/hda/ code does
> - merges HDMI (i.e. Intel i915 audio component) and HDA DAIs together
> whereas these are two separate devices
> - because of above, implements custom search/matching mechanism for PCM/DAI
> - cont. because of above, its header hosts private data struct,
> unnecessary complication
> - follows HDA_DEV_ASOC convention rather than HDA_DEV_LEGACY causing
> misalignments between sound/pci/hda and sound/soc/ behaviour
> - has basic PM runtime support and does not survive scenarios where
> resume/suspend + denylist + rmmod/modprobe are mixed together or invoked
> in unordered fashion between this module and several others in the audio
> stack
> 
> My suggestion is different: have all HD-Audio ASoC users switch to this
> implementation when possible and remove the existing code along with
> skylake-driver.

I am not against change and will agree that HDaudio support is far from
perfect, but it's been released for multiple generations from dozens of
OEMs and mostly works. All the issues reported to us are related to
codec configurations that also don't work with the legacy HDaudio
driver, DMIC configurations, CSME authentication or system hangs that
have not been root-caused [1]. HDaudio/ASoC interfaces are not on our
radar as problematic.

Disrupting basic HDaudio support to do things better has to be handled
with extreme caution and a ton of testing involving distro maintainers
and community members, so we are talking about an opt-in transition, not
an immediate switch. We've done a similar transition in the past to stop
using a dedicated hdac_hdmi.c codec, see all references to the
'use_common_hdmi' parameter in the SOF code. That transition seems to go
exactly against your second point above on HDMI and HDA being different
devices, so this could be an interesting debate.

Changes to the HDAudio/ASoC support would need to be handled with a
separate patchset anyways, and the SOF side changes done after we are
finished with the IPC4 and MeteorLake upstreaming. No one in our team
has any bandwidth to help with reviews or tests on this topic at the moment.

I will also re-state that the removal of the skylake driver can only
happen after a long period of deprecation, when firmware and topologies
have been picked by distributions and all users are known to have
switched, so it's very likely that any alignment between "all HD-Audio
ASoC users" mentioned above does include the Skylake driver, doesn't it?

So to circle back: is there anything preventing the use of the existing
hdac_hda.c codec in this "ASoC: Intel: avs: Machine boards and HDA codec
support" series and can the HDaudio codec change be done "later" in a
more organized way?

Thanks!
-Pierre

[1]
https://github.com/thesofproject/linux/issues?q=is%3Aissue+is%3Aopen+label%3ACommunity+-label%3A%22codec+ES8336%22

  reply	other threads:[~2022-05-06 15:04 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-27  8:18 [PATCH 00/14] ASoC: Intel: avs: Machine boards and HDA codec support Cezary Rojewski
2022-04-27  8:18 ` [PATCH 01/14] ALSA: Add snd_pcm_direction_name() helper Cezary Rojewski
2022-04-27  8:18 ` [PATCH 02/14] ASoC: codecs: Add HD-Audio codec driver Cezary Rojewski
2022-04-27 15:47   ` Pierre-Louis Bossart
2022-05-06 13:12     ` Mark Brown
2022-05-06 13:39       ` Cezary Rojewski
2022-05-06 14:56         ` Pierre-Louis Bossart [this message]
2022-05-06 15:28           ` Cezary Rojewski
2022-05-06 16:17             ` Pierre-Louis Bossart
2022-05-09 14:33               ` Kai Vehmanen
2022-05-09 15:55                 ` Pierre-Louis Bossart
2022-05-10  7:36                   ` Cezary Rojewski
2022-04-27  8:18 ` [PATCH 03/14] ASoC: Intel: avs: Add HDAudio machine board Cezary Rojewski
2022-04-27  8:18 ` [PATCH 04/14] ASoC: Intel: avs: Add DMIC " Cezary Rojewski
2022-04-27  8:18 ` [PATCH 05/14] ASoC: Intel: avs: Add ssp-test " Cezary Rojewski
2022-05-10 11:12   ` Cezary Rojewski
2022-04-27  8:18 ` [PATCH 06/14] ASoC: Intel: avs: Add rt274 " Cezary Rojewski
2022-04-27  8:18 ` [PATCH 07/14] ASoC: Intel: avs: Add rt286 " Cezary Rojewski
2022-04-27  8:18 ` [PATCH 08/14] ASoC: Intel: avs: Add rt298 " Cezary Rojewski
2022-04-27  8:18 ` [PATCH 09/14] ASoC: Intel: avs: Add rt5682 " Cezary Rojewski
2022-04-27  8:18 ` [PATCH 10/14] ASoC: Intel: avs: Add nau8825 " Cezary Rojewski
2022-04-27  8:18 ` [PATCH 11/14] ASoC: Intel: avs: Add ssm4567 " Cezary Rojewski
2022-04-27  8:19 ` [PATCH 12/14] ASoC: Intel: avs: Add max98357a " Cezary Rojewski
2022-04-27  8:19 ` [PATCH 13/14] ASoC: Intel: avs: Add max98373 " Cezary Rojewski
2022-04-27  8:19 ` [PATCH 14/14] ASoC: Intel: avs: Add da7219 " 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=2849fc32-83b8-4727-0aea-aa20b4d3557a@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=amadeuszx.slawinski@linux.intel.com \
    --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