From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Cezary Rojewski <cezary.rojewski@intel.com>, broonie@kernel.org
Cc: alsa-devel@alsa-project.org, linux-sound@vger.kernel.org,
tiwai@suse.com, perex@perex.cz,
amadeuszx.slawinski@linux.intel.com, hdegoede@redhat.com
Subject: Re: [PATCH 1/5] ASoC: Intel: Disable route checks for Skylake boards
Date: Mon, 4 Mar 2024 15:02:46 -0600 [thread overview]
Message-ID: <eca552eb-9d5b-4990-a98f-85dc1da3a96c@linux.intel.com> (raw)
In-Reply-To: <87c39d2f-fac0-4414-9c9f-53e45de70e79@intel.com>
On 3/4/24 14:40, Cezary Rojewski wrote:
> On 2024-03-04 8:28 PM, Pierre-Louis Bossart wrote:
>> On 3/4/24 13:05, Cezary Rojewski wrote:
>>> Topology files that are propagated to the world and utilized by the
>>> skylake-driver carry shortcomings in their SectionGraphs.
>>>
>>> Since commit daa480bde6b3 ("ASoC: soc-core: tidyup for
>>> snd_soc_dapm_add_routes()") route checks are no longer permissive. Probe
>>> failures for Intel boards have been partially addressed by commit
>>> a22ae72b86a4 ("ASoC: soc-core: disable route checks for legacy devices")
>>> and its follow up but only skl_nau88l25_ssm4567.c is patched. Fix the
>>> problem for the rest of the boards.
>>>
>>> Link:
>>> https://lore.kernel.org/all/20200309192744.18380-1-pierre-louis.bossart@linux.intel.com/
>>> Fixes: daa480bde6b3 ("ASoC: soc-core: tidyup for
>>> snd_soc_dapm_add_routes()")
>>> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
>>> ---
>>> sound/soc/intel/boards/bxt_da7219_max98357a.c | 1 +
>>> sound/soc/intel/boards/bxt_rt298.c | 1 +
>>> sound/soc/intel/boards/glk_rt5682_max98357a.c | 1 +
>>> sound/soc/intel/boards/kbl_da7219_max98357a.c | 1 +
>>> sound/soc/intel/boards/kbl_da7219_max98927.c | 4 ++++
>>> sound/soc/intel/boards/kbl_rt5660.c | 1 +
>>> sound/soc/intel/boards/kbl_rt5663_max98927.c | 2 ++
>>> sound/soc/intel/boards/kbl_rt5663_rt5514_max98927.c | 1 +
>>> sound/soc/intel/boards/skl_hda_dsp_generic.c | 1 +
>>
>> This HDAudio machine driver is shared with the SOF-based solutions and I
>> see no reason to change the route checking...
>>
>> I don't agree with this change. Why can't you fix the broken topologies
>> instead, if indeed they 'carry shortcomings'?
>>
>> Same for glk, this an SOF-based solution.
>
> Perhaps the flag could be set conditionally for those two?
>
> Even when you address the problem in the topology file, you do not get
> any confirmation user replaced the invalid file. skylake-driver topology
> were not part of any firmware-alike package. Please note that I actually
> did all that I believe could be done to repair those topologies and
> provided valid references at avs-topology/for-skylake-driver [1].
Humm, the commit daa480bde6b3 ("ASoC: soc-core: tidyup for
snd_soc_dapm_add_routes()") dates from August 2019 and was included in
kernel 5.4.
Why are we seeing issues on route checks with the Skylake driver in
2024? Are we saying that the card creation failed for the last 5 years?
I must be missing something here.
next prev parent reply other threads:[~2024-03-04 21:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-04 19:05 [PATCH 0/5] ASoC: Harden DAPM route checks and Intel fixes Cezary Rojewski
2024-03-04 19:05 ` [PATCH 1/5] ASoC: Intel: Disable route checks for Skylake boards Cezary Rojewski
2024-03-04 19:28 ` Pierre-Louis Bossart
2024-03-04 20:40 ` Cezary Rojewski
2024-03-04 21:02 ` Pierre-Louis Bossart [this message]
2024-03-06 16:08 ` Cezary Rojewski
2024-03-04 19:05 ` [PATCH 2/5] ASoC: topology: Do not ignore route checks when parsing graphs Cezary Rojewski
2024-03-04 19:32 ` Pierre-Louis Bossart
2024-03-04 20:50 ` Cezary Rojewski
2024-03-04 21:25 ` Pierre-Louis Bossart
2024-03-06 16:11 ` Cezary Rojewski
2024-03-04 19:05 ` [PATCH 3/5] ASoC: Intel: avs: ssm4567: Do not ignore route checks Cezary Rojewski
2024-03-04 19:05 ` [PATCH 4/5] ASoC: Intel: avs: ssm4567: Board cleanup Cezary Rojewski
2024-03-04 19:05 ` [PATCH 5/5] ASoC: Intel: avs: i2s_test: Remove redundant dapm routes 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=eca552eb-9d5b-4990-a98f-85dc1da3a96c@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=hdegoede@redhat.com \
--cc=linux-sound@vger.kernel.org \
--cc=perex@perex.cz \
--cc=tiwai@suse.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.