Hi,
On Bugzilla, Daniel <[email protected]> reported topology regression
on Steam Deck OLED [1]. He wrote:
> I'm adding this here, I hope it's the correct place.
>
> Currently the Steam Deck OLED fails with Kernel 6.8.2 when trying to initialise the topology for the device.
> I'm using the `sof-vangogh-nau8821-max.tplg` file from the Steam Deck OLED and associated firmware.
>
> When I manually patched support for the 6.6 or 6.7 mainline kernel it worked fine.
> Now the official implementation fails as per below.
>
> Do we need an updated topology file?
>
> dmesg info...
>
> [ 12.844720] snd_hda_intel 0000:04:00.1: enabling device (0000 -> 0002)
> [ 12.846177] snd_hda_intel 0000:04:00.1: Handle vga_switcheroo audio client
> [ 12.853045] max98388 i2c-ADS8388:00: MAX98388 revisionID: 0x41
> [ 12.854798] max98388 i2c-ADS8388:01: MAX98388 revisionID: 0x41
> [ 13.049834] input: HD-Audio Generic HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:08.1/0000:04:00.1/sound/card0/input10
> [ 13.095674] input: FTS3528:00 2808:1015 as /devices/platform/AMDI0010:01/i2c-1/i2c-FTS3528:00/0018:2808:1015.0003/input/input16
> [ 13.114799] input: HD-Audio Generic HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:08.1/0000:04:00.1/sound/card0/input11
> [ 13.115023] input: Valve Software Steam Controller as /devices/pci0000:00/0000:00:08.1/0000:04:00.4/usb1/1-3/1-3:1.0/0003:28DE:1205.0001/input/input19
> [ 13.120952] snd_sof_amd_vangogh 0000:04:00.5: enabling device (0000 -> 0002)
> [ 13.167809] snd_sof_amd_vangogh 0000:04:00.5: Firmware paths/files for ipc type 0:
> [ 13.169329] snd_sof_amd_vangogh 0000:04:00.5: Topology file: amd/sof-tplg/sof-vangogh-nau8821-max.tplg
> [ 13.171103] input: FTS3528:00 2808:1015 UNKNOWN as /devices/platform/AMDI0010:01/i2c-1/i2c-FTS3528:00/0018:2808:1015.0003/input/input18
> [ 13.171619] input: HD-Audio Generic HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:08.1/0000:04:00.1/sound/card0/input12
> [ 13.172518] hid-steam 0003:28DE:1205.0001: input,hidraw2: USB HID v1.10 Mouse [Valve Software Steam Controller] on usb-0000:04:00.4-3/input0
> [ 13.172556] input: HD-Audio Generic HDMI/DP,pcm=9 as /devices/pci0000:00/0000:00:08.1/0000:04:00.1/sound/card0/input13
> [ 13.173623] hid-steam 0003:28DE:1205.0004: hiddev0: USB HID v1.10 Device [Valve Software Steam Controller] on usb-0000:04:00.4-3/input2
> [ 13.215330] snd_sof_amd_vangogh 0000:04:00.5: Firmware info: version 0:0:0-7863d
> [ 13.217053] snd_sof_amd_vangogh 0000:04:00.5: Firmware: ABI 3:26:0 Kernel ABI 3:23:0
> [ 13.234447] hid-steam 0003:28DE:1205.0004: Steam Controller 'FYZZ34102C64' connected
> [ 13.242606] input: Steam Deck as /devices/pci0000:00/0000:00:08.1/0000:04:00.4/usb1/1-3/1-3:1.2/0003:28DE:1205.0004/input/input20
> [ 13.289530] snd_sof_amd_vangogh 0000:04:00.5: Topology: ABI 3:26:0 Kernel ABI 3:23:0
> [ 13.291262] hid-multitouch 0018:2808:1015.0003: input,hidraw1: I2C HID v1.00 Device [FTS3528:00 2808:1015] on i2c-FTS3528:00
> [ 13.291402] sof_mach nau8821-max: ASoC: physical link acp-bt-codec (id 2) not exist
> [ 13.291500] input: Valve Software Steam Controller as /devices/pci0000:00/0000:00:08.1/0000:04:00.4/usb1/1-3/1-3:1.1/0003:28DE:1205.0002/input/input21
> [ 13.296647] sof_mach nau8821-max: ASoC: topology: could not load header: -22
> [ 13.298510] snd_sof_amd_vangogh 0000:04:00.5: error: tplg component load failed -22
> [ 13.300270] snd_sof_amd_vangogh 0000:04:00.5: error: failed to load DSP topology -22
> [ 13.302008] snd_sof_amd_vangogh 0000:04:00.5: ASoC: error at snd_soc_component_probe on 0000:04:00.5: -22
> [ 13.303785] sof_mach nau8821-max: ASoC: failed to instantiate card -22
> [ 13.305586] sof_mach nau8821-max: error -EINVAL: Failed to register card(sof-nau8821-max)
See Bugzilla for the full thread.
Thanks.
[1]: https://bugzilla.kernel.org/show_bug.cgi?id=218677
--
An old man doll... just what I always wanted! - Clara
On 06.04.24 15:08, Bagas Sanjaya wrote:
>
> On Bugzilla, Daniel <[email protected]> reported topology regression
> on Steam Deck OLED [1]. He wrote:
Bagas, why didn't you forward this to me in private first, as we agreed
on as general procedure for cases like this?
Anyway:
>> I'm adding this here, I hope it's the correct place.
>>
>> Currently the Steam Deck OLED fails with Kernel 6.8.2 when trying to initialise the topology for the device.
>> I'm using the `sof-vangogh-nau8821-max.tplg` file from the Steam Deck OLED and associated firmware.
>
> See Bugzilla for the full thread.
>
> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=218677
A quick search made me find these posts/threads that foreshadow the problem:
https://lore.kernel.org/lkml/[email protected]/
https://lore.kernel.org/all/[email protected]/
From a quick look at the second discussion it seems a bit like we are
screwed, as iiutc topology files are out in the wild for one or the
other approach. So we might have to bite a bullet there and accept the
regression -- but I might easily be totally mistaken here. Would be good
in one of the experts (Venkata Prasad Potturu maybe?) could quickly
explain what's up here.
Ciao, Thorsten
On Sun, Apr 07, 2024 at 09:47:00AM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 06.04.24 15:08, Bagas Sanjaya wrote:
> >
> > On Bugzilla, Daniel <[email protected]> reported topology regression
> > on Steam Deck OLED [1]. He wrote:
>
> Bagas, why didn't you forward this to me in private first, as we agreed
> on as general procedure for cases like this?
At skim it was a rather (subtle) regression, so I forwarded it myself.
Thanks for the reminder!
--
An old man doll... just what I always wanted! - Clara
On 4/7/24 10:47 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 06.04.24 15:08, Bagas Sanjaya wrote:
>>
>> On Bugzilla, Daniel <[email protected]> reported topology regression
>> on Steam Deck OLED [1]. He wrote:
>
> Bagas, why didn't you forward this to me in private first, as we agreed
> on as general procedure for cases like this?
>
> Anyway:
>
>>> I'm adding this here, I hope it's the correct place.
>>>
>>> Currently the Steam Deck OLED fails with Kernel 6.8.2 when trying to initialise the topology for the device.
>>> I'm using the `sof-vangogh-nau8821-max.tplg` file from the Steam Deck OLED and associated firmware.
>>
>> See Bugzilla for the full thread.
>>
>> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=218677
>
> A quick search made me find these posts/threads that foreshadow the problem:
>
> https://lore.kernel.org/lkml/[email protected]/
> https://lore.kernel.org/all/[email protected]/
>
> From a quick look at the second discussion it seems a bit like we are
> screwed, as iiutc topology files are out in the wild for one or the
> other approach. So we might have to bite a bullet there and accept the
> regression -- but I might easily be totally mistaken here. Would be good
> in one of the experts (Venkata Prasad Potturu maybe?) could quickly
> explain what's up here.
The problem here is that Steam Deck OLED provides a topology file which
uses an incorrect DAI link ID for BT codec.
Patch [1] moves BT_BE_ID to position 2 in the enum, as expected by the
topology, but this is not a change that can be accepted upstream as it
would break other devices which rely on BT_BE_ID set to 3.
The proper solution would be to update the topology file on Steam Deck,
but this is probably not straightforward to be accomplished as it would
break the compatibility with the currently released (downstream)
kernels.
Hopefully, this sheds some more light on the matter.
Regards,
Cristian
[1]: https://lore.kernel.org/all/[email protected]/
On 09.04.24 01:44, Cristian Ciocaltea wrote:
> On 4/7/24 10:47 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
>> On 06.04.24 15:08, Bagas Sanjaya wrote:
>>>
>>> On Bugzilla, Daniel <[email protected]> reported topology regression
>>> on Steam Deck OLED [1]. He wrote:
>
>>>> I'm adding this here, I hope it's the correct place.
>>>>
>>>> Currently the Steam Deck OLED fails with Kernel 6.8.2 when trying to initialise the topology for the device.
>>>> I'm using the `sof-vangogh-nau8821-max.tplg` file from the Steam Deck OLED and associated firmware.
>>>
>>> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=218677
>>
>> A quick search made me find these posts/threads that foreshadow the problem:
>>
>> https://lore.kernel.org/lkml/[email protected]/
>> https://lore.kernel.org/all/[email protected]/
>>
>> From a quick look at the second discussion it seems a bit like we are
>> screwed, as iiutc topology files are out in the wild for one or the
>> other approach. So we might have to bite a bullet there and accept the
>> regression -- but I might easily be totally mistaken here. Would be good
>> in one of the experts (Venkata Prasad Potturu maybe?) could quickly
>> explain what's up here.
>
> The problem here is that Steam Deck OLED provides a topology file which
> uses an incorrect DAI link ID for BT codec.
>
> Patch [1] moves BT_BE_ID to position 2 in the enum, as expected by the
> topology, but this is not a change that can be accepted upstream as it
> would break other devices which rely on BT_BE_ID set to 3.
>
> The proper solution would be to update the topology file on Steam Deck,
> but this is probably not straightforward to be accomplished as it would
> break the compatibility with the currently released (downstream)
> kernels.
>
> Hopefully, this sheds some more light on the matter.
>
> [1]: https://lore.kernel.org/all/[email protected]/
Many thx, yes, this sheds some light on the matter. But there is one
remaining question: can we make both camps happy somehow? E.g. something
along the lines of "first detect if the topology file has BT_BE_ID in
position 2 or 3 and then act accordingly?
Ciao, Thorsten
On 4/9/24 7:44 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 09.04.24 01:44, Cristian Ciocaltea wrote:
>> On 4/7/24 10:47 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
>>> On 06.04.24 15:08, Bagas Sanjaya wrote:
>>>>
>>>> On Bugzilla, Daniel <[email protected]> reported topology regression
>>>> on Steam Deck OLED [1]. He wrote:
>>
>>>>> I'm adding this here, I hope it's the correct place.
>>>>>
>>>>> Currently the Steam Deck OLED fails with Kernel 6.8.2 when trying to initialise the topology for the device.
>>>>> I'm using the `sof-vangogh-nau8821-max.tplg` file from the Steam Deck OLED and associated firmware.
>>>>
>>>> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=218677
>>>
>>> A quick search made me find these posts/threads that foreshadow the problem:
>>>
>>> https://lore.kernel.org/lkml/[email protected]/
>>> https://lore.kernel.org/all/[email protected]/
>>>
>>> From a quick look at the second discussion it seems a bit like we are
>>> screwed, as iiutc topology files are out in the wild for one or the
>>> other approach. So we might have to bite a bullet there and accept the
>>> regression -- but I might easily be totally mistaken here. Would be good
>>> in one of the experts (Venkata Prasad Potturu maybe?) could quickly
>>> explain what's up here.
>>
>> The problem here is that Steam Deck OLED provides a topology file which
>> uses an incorrect DAI link ID for BT codec.
>>
>> Patch [1] moves BT_BE_ID to position 2 in the enum, as expected by the
>> topology, but this is not a change that can be accepted upstream as it
>> would break other devices which rely on BT_BE_ID set to 3.
>>
>> The proper solution would be to update the topology file on Steam Deck,
>> but this is probably not straightforward to be accomplished as it would
>> break the compatibility with the currently released (downstream)
>> kernels.
>>
>> Hopefully, this sheds some more light on the matter.
>>
>> [1]: https://lore.kernel.org/all/[email protected]/
>
> Many thx, yes, this sheds some light on the matter. But there is one
> remaining question: can we make both camps happy somehow? E.g. something
> along the lines of "first detect if the topology file has BT_BE_ID in
> position 2 or 3 and then act accordingly?
Right, I have this on my TODOs list but haven't managed to dig into it
yet. However, that would be most likely just another hack to be carried
on until the transition to a fixed topology is completed.
Regards,
Cristian
On 09.04.24 09:42, Cristian Ciocaltea wrote:
> On 4/9/24 7:44 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
>> On 09.04.24 01:44, Cristian Ciocaltea wrote:
>>> On 4/7/24 10:47 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
>>>> On 06.04.24 15:08, Bagas Sanjaya wrote:
>>>>> On Bugzilla, Daniel <[email protected]> reported topology regression
>>>>> on Steam Deck OLED [1]. He wrote:
>>>
>>>>>> I'm adding this here, I hope it's the correct place.
>>>>>> Currently the Steam Deck OLED fails with Kernel 6.8.2 when trying to initialise the topology for the device.
>>>>>> I'm using the `sof-vangogh-nau8821-max.tplg` file from the Steam Deck OLED and associated firmware.
>>>>> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=218677
>>>> A quick search made me find these posts/threads that foreshadow the problem:
>>>>
>>>> https://lore.kernel.org/lkml/[email protected]/
>>>> https://lore.kernel.org/all/[email protected]/
>>>>
>>>> From a quick look at the second discussion it seems a bit like we are
>>>> screwed, as iiutc topology files are out in the wild for one or the
>>>> other approach. So we might have to bite a bullet there and accept the
>>>> regression -- but I might easily be totally mistaken here. Would be good
>>>> in one of the experts (Venkata Prasad Potturu maybe?) could quickly
>>>> explain what's up here.
>>>
>>> The problem here is that Steam Deck OLED provides a topology file which
>>> uses an incorrect DAI link ID for BT codec.
>>>
>>> Patch [1] moves BT_BE_ID to position 2 in the enum, as expected by the
>>> topology, but this is not a change that can be accepted upstream as it
>>> would break other devices which rely on BT_BE_ID set to 3.
>>>
>>> The proper solution would be to update the topology file on Steam Deck,
>>> but this is probably not straightforward to be accomplished as it would
>>> break the compatibility with the currently released (downstream)
>>> kernels.
>>>
>>> Hopefully, this sheds some more light on the matter.
>>>
>>> [1]: https://lore.kernel.org/all/[email protected]/
>>
>> Many thx, yes, this sheds some light on the matter. But there is one
>> remaining question: can we make both camps happy somehow? E.g. something
>> along the lines of "first detect if the topology file has BT_BE_ID in
>> position 2 or 3 and then act accordingly?
>
> Right, I have this on my TODOs list but haven't managed to dig into it
> yet. However, that would be most likely just another hack to be carried
> on until the transition to a fixed topology is completed.
Well, sure it's a hack, but the thing is, our number one rule is "no
regressions" and the reporter apparently faces one (see start of the
thread). So to fulfill this rule it would be ideal to have a fix
available soonish or revert the culprit and reply it later together with
the fix.
Do we know which change that went into 6.8 caused this? Or is a revert
out-of-the question as it will likely break things for other users that
already upgraded to 6.8 and have a matching topology file? (/me fears
the answer to the latter question is "yes", but I have to ask :-/)
Ciao, Thorsten
Why this was changed in the first place could do with some explaining,
as Valve had this implemented first in the SteamDeck (probably
collabora dev).
There were no other implementations out in the wild AFAIK & now with
the 6.8.x kernel, this issue has manifested because of an enum change.
I cannot for the life of me find an alternative topology file. Where
are the other implementations? Therefore it makes sense aligning to
what was done before on the Steam Deck OLED.
Alternatively, if Valve could provide an updated topology file for
6.8+ kernels, that would be great too.
Just my two cents from a humble OS dev, trying to make stuff work.
On Tue, 9 Apr 2024 at 18:04, Linux regression tracking (Thorsten
Leemhuis) <[email protected]> wrote:
>
> On 09.04.24 09:42, Cristian Ciocaltea wrote:
> > On 4/9/24 7:44 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
> >> On 09.04.24 01:44, Cristian Ciocaltea wrote:
> >>> On 4/7/24 10:47 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
> >>>> On 06.04.24 15:08, Bagas Sanjaya wrote:
> >>>>> On Bugzilla, Daniel <[email protected]> reported topology regression
> >>>>> on Steam Deck OLED [1]. He wrote:
> >>>
> >>>>>> I'm adding this here, I hope it's the correct place.
> >>>>>> Currently the Steam Deck OLED fails with Kernel 6.8.2 when trying to initialise the topology for the device.
> >>>>>> I'm using the `sof-vangogh-nau8821-max.tplg` file from the Steam Deck OLED and associated firmware.
> >>>>> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=218677
> >>>> A quick search made me find these posts/threads that foreshadow the problem:
> >>>>
> >>>> https://lore.kernel.org/lkml/[email protected]/
> >>>> https://lore.kernel.org/all/[email protected]/
> >>>>
> >>>> From a quick look at the second discussion it seems a bit like we are
> >>>> screwed, as iiutc topology files are out in the wild for one or the
> >>>> other approach. So we might have to bite a bullet there and accept the
> >>>> regression -- but I might easily be totally mistaken here. Would be good
> >>>> in one of the experts (Venkata Prasad Potturu maybe?) could quickly
> >>>> explain what's up here.
> >>>
> >>> The problem here is that Steam Deck OLED provides a topology file which
> >>> uses an incorrect DAI link ID for BT codec.
> >>>
> >>> Patch [1] moves BT_BE_ID to position 2 in the enum, as expected by the
> >>> topology, but this is not a change that can be accepted upstream as it
> >>> would break other devices which rely on BT_BE_ID set to 3.
> >>>
> >>> The proper solution would be to update the topology file on Steam Deck,
> >>> but this is probably not straightforward to be accomplished as it would
> >>> break the compatibility with the currently released (downstream)
> >>> kernels.
> >>>
> >>> Hopefully, this sheds some more light on the matter.
> >>>
> >>> [1]: https://lore.kernel.org/all/[email protected]/
> >>
> >> Many thx, yes, this sheds some light on the matter. But there is one
> >> remaining question: can we make both camps happy somehow? E.g. something
> >> along the lines of "first detect if the topology file has BT_BE_ID in
> >> position 2 or 3 and then act accordingly?
> >
> > Right, I have this on my TODOs list but haven't managed to dig into it
> > yet. However, that would be most likely just another hack to be carried
> > on until the transition to a fixed topology is completed.
>
> Well, sure it's a hack, but the thing is, our number one rule is "no
> regressions" and the reporter apparently faces one (see start of the
> thread). So to fulfill this rule it would be ideal to have a fix
> available soonish or revert the culprit and reply it later together with
> the fix.
>
> Do we know which change that went into 6.8 caused this? Or is a revert
> out-of-the question as it will likely break things for other users that
> already upgraded to 6.8 and have a matching topology file? (/me fears
> the answer to the latter question is "yes", but I have to ask :-/)
>
> Ciao, Thorsten
--
Kind Regards,
Daniel
+61 (0)409611884
On 4/9/24 10:54 AM, Daniel Martin wrote:
> Why this was changed in the first place could do with some explaining,
> as Valve had this implemented first in the SteamDeck (probably collabora
> dev).
> There were no other implementations out in the wild AFAIK & now with the
> 6.8.x kernel, this issue has manifested because of an enum change.
The OLED model was launched with a 6.1-based kernel which relied on a
downstream implementation of the Vangogh SOF drivers. Those were
mainlined by AMD way later, in v6.6, but during the upstreaming process
we ended up with this unfortunate ID assignments incompatibility.
> I cannot for the life of me find an alternative topology file. Where are
> the other implementations? Therefore it makes sense aligning to what was
> done before on the Steam Deck OLED.
I'm not aware of an alternative topology file available so far.
> Alternatively, if Valve could provide an updated topology file for 6.8+
> kernels, that would be great too.
> Just my two cents from a humble OS dev, trying to make stuff work.
I think that would be the long-term goal, so until that is figured out,
the easiest workaround to get this working with mainline is to apply the
enum change patch.
Regards,
Cristian
On 4/9/24 11:04 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 09.04.24 09:42, Cristian Ciocaltea wrote:
>> On 4/9/24 7:44 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
>>> On 09.04.24 01:44, Cristian Ciocaltea wrote:
>>>> On 4/7/24 10:47 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
>>>>> On 06.04.24 15:08, Bagas Sanjaya wrote:
>>>>>> On Bugzilla, Daniel <[email protected]> reported topology regression
>>>>>> on Steam Deck OLED [1]. He wrote:
>>>>
>>>>>>> I'm adding this here, I hope it's the correct place.
>>>>>>> Currently the Steam Deck OLED fails with Kernel 6.8.2 when trying to initialise the topology for the device.
>>>>>>> I'm using the `sof-vangogh-nau8821-max.tplg` file from the Steam Deck OLED and associated firmware.
>>>>>> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=218677
>>>>> A quick search made me find these posts/threads that foreshadow the problem:
>>>>>
>>>>> https://lore.kernel.org/lkml/[email protected]/
>>>>> https://lore.kernel.org/all/[email protected]/
>>>>>
>>>>> From a quick look at the second discussion it seems a bit like we are
>>>>> screwed, as iiutc topology files are out in the wild for one or the
>>>>> other approach. So we might have to bite a bullet there and accept the
>>>>> regression -- but I might easily be totally mistaken here. Would be good
>>>>> in one of the experts (Venkata Prasad Potturu maybe?) could quickly
>>>>> explain what's up here.
>>>>
>>>> The problem here is that Steam Deck OLED provides a topology file which
>>>> uses an incorrect DAI link ID for BT codec.
>>>>
>>>> Patch [1] moves BT_BE_ID to position 2 in the enum, as expected by the
>>>> topology, but this is not a change that can be accepted upstream as it
>>>> would break other devices which rely on BT_BE_ID set to 3.
>>>>
>>>> The proper solution would be to update the topology file on Steam Deck,
>>>> but this is probably not straightforward to be accomplished as it would
>>>> break the compatibility with the currently released (downstream)
>>>> kernels.
>>>>
>>>> Hopefully, this sheds some more light on the matter.
>>>>
>>>> [1]: https://lore.kernel.org/all/[email protected]/
>>>
>>> Many thx, yes, this sheds some light on the matter. But there is one
>>> remaining question: can we make both camps happy somehow? E.g. something
>>> along the lines of "first detect if the topology file has BT_BE_ID in
>>> position 2 or 3 and then act accordingly?
>>
>> Right, I have this on my TODOs list but haven't managed to dig into it
>> yet. However, that would be most likely just another hack to be carried
>> on until the transition to a fixed topology is completed.
>
> Well, sure it's a hack, but the thing is, our number one rule is "no
> regressions" and the reporter apparently faces one (see start of the
> thread). So to fulfill this rule it would be ideal to have a fix
> available soonish or revert the culprit and reply it later together with
> the fix.
Hmm, unless I'm missing something, this shouldn't been considered a
regression. As I explained previously, the OLED model was launched with
a downstream implementation of the Vangogh SOF drivers on top of v6.1,
as there was no upstream support back then.
When AMD eventually completed the upstreaming process of their SOF
drivers in v6.6, we ended up with this unfortunate ID assignments
incompatibility. Hence I cannot see how the mainline kernel would have
worked without applying patch [1] above, unless the reporter
experimented with a different topology (which is not the case if I got
this right).
> Do we know which change that went into 6.8 caused this? Or is a revert
> out-of-the question as it will likely break things for other users that
> already upgraded to 6.8 and have a matching topology file? (/me fears
> the answer to the latter question is "yes", but I have to ask :-/)
We need to understand how the reporter got this working with mainline
kernels without applying any out-of-tree patches.
Regards,
Cristian
On 09.04.24 10:47, Cristian Ciocaltea wrote:
> On 4/9/24 11:04 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
>> On 09.04.24 09:42, Cristian Ciocaltea wrote:
>>> On 4/9/24 7:44 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
>>>> On 09.04.24 01:44, Cristian Ciocaltea wrote:
>>>>> On 4/7/24 10:47 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
>>>>>> On 06.04.24 15:08, Bagas Sanjaya wrote:
>>>>>>> On Bugzilla, Daniel <[email protected]> reported topology regression
>>>>>>> on Steam Deck OLED [1]. He wrote:
>>>>>
>>>>>>>> I'm adding this here, I hope it's the correct place.
>>>>>>>> Currently the Steam Deck OLED fails with Kernel 6.8.2 when trying to initialise the topology for the device.
>>>>>>>> I'm using the `sof-vangogh-nau8821-max.tplg` file from the Steam Deck OLED and associated firmware.
>>>>>>> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=218677
>>>>>> A quick search made me find these posts/threads that foreshadow the problem:
>>>>>>
>>>>>> https://lore.kernel.org/lkml/[email protected]/
>>>>>> https://lore.kernel.org/all/[email protected]/
>>>>>>
>>>>>> From a quick look at the second discussion it seems a bit like we are
>>>>>> screwed, as iiutc topology files are out in the wild for one or the
>>>>>> other approach. So we might have to bite a bullet there and accept the
>>>>>> regression -- but I might easily be totally mistaken here. Would be good
>>>>>> in one of the experts (Venkata Prasad Potturu maybe?) could quickly
>>>>>> explain what's up here.
>>>>>
>>>>> The problem here is that Steam Deck OLED provides a topology file which
>>>>> uses an incorrect DAI link ID for BT codec.
>>>>>
>>>>> Patch [1] moves BT_BE_ID to position 2 in the enum, as expected by the
>>>>> topology, but this is not a change that can be accepted upstream as it
>>>>> would break other devices which rely on BT_BE_ID set to 3.
>>>>>
>>>>> The proper solution would be to update the topology file on Steam Deck,
>>>>> but this is probably not straightforward to be accomplished as it would
>>>>> break the compatibility with the currently released (downstream)
>>>>> kernels.
>>>>>
>>>>> Hopefully, this sheds some more light on the matter.
>>>>>
>>>>> [1]: https://lore.kernel.org/all/[email protected]/
>>>>
>>>> Many thx, yes, this sheds some light on the matter. But there is one
>>>> remaining question: can we make both camps happy somehow? E.g. something
>>>> along the lines of "first detect if the topology file has BT_BE_ID in
>>>> position 2 or 3 and then act accordingly?
>>>
>>> Right, I have this on my TODOs list but haven't managed to dig into it
>>> yet. However, that would be most likely just another hack to be carried
>>> on until the transition to a fixed topology is completed.
>>
>> Well, sure it's a hack, but the thing is, our number one rule is "no
>> regressions" and the reporter apparently faces one (see start of the
>> thread). So to fulfill this rule it would be ideal to have a fix
>> available soonish or revert the culprit and reply it later together with
>> the fix.
>
> Hmm, unless I'm missing something, this shouldn't been considered a
> regression. As I explained previously, the OLED model was launched with
> a downstream implementation of the Vangogh SOF drivers on top of v6.1,
> as there was no upstream support back then.
>
> When AMD eventually completed the upstreaming process of their SOF
> drivers in v6.6, we ended up with this unfortunate ID assignments
> incompatibility. Hence I cannot see how the mainline kernel would have
> worked without applying patch [1] above, unless the reporter
> experimented with a different topology (which is not the case if I got
> this right).
>
>> Do we know which change that went into 6.8 caused this? Or is a revert
>> out-of-the question as it will likely break things for other users that
>> already upgraded to 6.8 and have a matching topology file? (/me fears
>> the answer to the latter question is "yes", but I have to ask :-/)
>
> We need to understand how the reporter got this working with mainline
> kernels without applying any out-of-tree patches.
Ahh, okay, thx, now I understand this better. You are most likely
correct. It also made me look at the initial report again where I
noticed "When *I manually patched support* for the 6.6 or 6.7 mainline
kernel it worked fine.", so yes, this likely is not a regression.
Thx for your help and sorry for the trouble I caused!
Ciao, Thorsten
On 4/9/24 12:19 PM, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 09.04.24 10:47, Cristian Ciocaltea wrote:
>> On 4/9/24 11:04 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
>>> On 09.04.24 09:42, Cristian Ciocaltea wrote:
>>>> On 4/9/24 7:44 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
>>>>> On 09.04.24 01:44, Cristian Ciocaltea wrote:
>>>>>> On 4/7/24 10:47 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
>>>>>>> On 06.04.24 15:08, Bagas Sanjaya wrote:
>>>>>>>> On Bugzilla, Daniel <[email protected]> reported topology regression
>>>>>>>> on Steam Deck OLED [1]. He wrote:
>>>>>>
>>>>>>>>> I'm adding this here, I hope it's the correct place.
>>>>>>>>> Currently the Steam Deck OLED fails with Kernel 6.8.2 when trying to initialise the topology for the device.
>>>>>>>>> I'm using the `sof-vangogh-nau8821-max.tplg` file from the Steam Deck OLED and associated firmware.
>>>>>>>> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=218677
>>>>>>> A quick search made me find these posts/threads that foreshadow the problem:
>>>>>>>
>>>>>>> https://lore.kernel.org/lkml/[email protected]/
>>>>>>> https://lore.kernel.org/all/[email protected]/
>>>>>>>
>>>>>>> From a quick look at the second discussion it seems a bit like we are
>>>>>>> screwed, as iiutc topology files are out in the wild for one or the
>>>>>>> other approach. So we might have to bite a bullet there and accept the
>>>>>>> regression -- but I might easily be totally mistaken here. Would be good
>>>>>>> in one of the experts (Venkata Prasad Potturu maybe?) could quickly
>>>>>>> explain what's up here.
>>>>>>
>>>>>> The problem here is that Steam Deck OLED provides a topology file which
>>>>>> uses an incorrect DAI link ID for BT codec.
>>>>>>
>>>>>> Patch [1] moves BT_BE_ID to position 2 in the enum, as expected by the
>>>>>> topology, but this is not a change that can be accepted upstream as it
>>>>>> would break other devices which rely on BT_BE_ID set to 3.
>>>>>>
>>>>>> The proper solution would be to update the topology file on Steam Deck,
>>>>>> but this is probably not straightforward to be accomplished as it would
>>>>>> break the compatibility with the currently released (downstream)
>>>>>> kernels.
>>>>>>
>>>>>> Hopefully, this sheds some more light on the matter.
>>>>>>
>>>>>> [1]: https://lore.kernel.org/all/[email protected]/
>>>>>
>>>>> Many thx, yes, this sheds some light on the matter. But there is one
>>>>> remaining question: can we make both camps happy somehow? E.g. something
>>>>> along the lines of "first detect if the topology file has BT_BE_ID in
>>>>> position 2 or 3 and then act accordingly?
>>>>
>>>> Right, I have this on my TODOs list but haven't managed to dig into it
>>>> yet. However, that would be most likely just another hack to be carried
>>>> on until the transition to a fixed topology is completed.
>>>
>>> Well, sure it's a hack, but the thing is, our number one rule is "no
>>> regressions" and the reporter apparently faces one (see start of the
>>> thread). So to fulfill this rule it would be ideal to have a fix
>>> available soonish or revert the culprit and reply it later together with
>>> the fix.
>>
>> Hmm, unless I'm missing something, this shouldn't been considered a
>> regression. As I explained previously, the OLED model was launched with
>> a downstream implementation of the Vangogh SOF drivers on top of v6.1,
>> as there was no upstream support back then.
>>
>> When AMD eventually completed the upstreaming process of their SOF
>> drivers in v6.6, we ended up with this unfortunate ID assignments
>> incompatibility. Hence I cannot see how the mainline kernel would have
>> worked without applying patch [1] above, unless the reporter
>> experimented with a different topology (which is not the case if I got
>> this right).
>>
>>> Do we know which change that went into 6.8 caused this? Or is a revert
>>> out-of-the question as it will likely break things for other users that
>>> already upgraded to 6.8 and have a matching topology file? (/me fears
>>> the answer to the latter question is "yes", but I have to ask :-/)
>>
>> We need to understand how the reporter got this working with mainline
>> kernels without applying any out-of-tree patches.
>
> Ahh, okay, thx, now I understand this better. You are most likely
> correct. It also made me look at the initial report again where I
> noticed "When *I manually patched support* for the 6.6 or 6.7 mainline
> kernel it worked fine.", so yes, this likely is not a regression.
It would be interesting to find out what the *manually patched support*
involved. FWIW, to get audio working with v6.8, it's also necessary to
backport several patches from v6.9-rc1 - I would consider the following:
Fixes: f0f1021fc9cb ("ASoC: amd: acp: Drop redundant initialization of machine driver data")
Fixes: 68ab29426d88 ("ASoC: amd: acp: Make use of existing *_CODEC_DAI macros")
Fixes: d0ada20279db ("ASoC: amd: acp: Add missing error handling in sof-mach")
Fixes: 222be59e5eed ("ASoC: SOF: amd: Fix memory leak in amd_sof_acp_probe()")
Fixes: a13f0c3c0e8f ("ASoC: SOF: amd: Optimize quirk for Valve Galileo")
Fixes: 369b997a1371 ("ASoC: SOF: core: Skip firmware test for custom loaders")
Fixes: d9cacc1a2af2 ("ASoC: SOF: amd: Compute file paths on firmware load")
Fixes: 33c3d8133307 ("ASoC: SOF: amd: Move signed_fw_image to struct acp_quirk_entry")
Fixes: 094d11768f74 ("ASoC: SOF: amd: Skip IRAM/DRAM size modification for Steam Deck OLED")
I think most if not all of the mandatory fixes from the list above have been
already included in the latest v6.8 stable updates, but I haven't actually
tested.
>
> Thx for your help and sorry for the trouble I caused!
No problem at all!
Regards,
Cristian
The manual patches were worked from the Steam Deck kernel, trial &
error with partial support in 6.6 at the time.
6.8 sources where this has been implemented recently were not yet
available or in linux-next.
Suffice to say the code matches up almost perfectly apart from the
enum issues which are thus being discussed.
I still go back to the point, apart from the Steam Deck, who else is
using this named topology file?
I don't think anyone is, therefore the enum numbering should match the
current Steam Deck kernel implementation & topology file.
On Tue, 9 Apr 2024 at 19:55, Cristian Ciocaltea
<[email protected]> wrote:
>
> On 4/9/24 12:19 PM, Linux regression tracking (Thorsten Leemhuis) wrote:
> > On 09.04.24 10:47, Cristian Ciocaltea wrote:
> >> On 4/9/24 11:04 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
> >>> On 09.04.24 09:42, Cristian Ciocaltea wrote:
> >>>> On 4/9/24 7:44 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
> >>>>> On 09.04.24 01:44, Cristian Ciocaltea wrote:
> >>>>>> On 4/7/24 10:47 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
> >>>>>>> On 06.04.24 15:08, Bagas Sanjaya wrote:
> >>>>>>>> On Bugzilla, Daniel <[email protected]> reported topology regression
> >>>>>>>> on Steam Deck OLED [1]. He wrote:
> >>>>>>
> >>>>>>>>> I'm adding this here, I hope it's the correct place.
> >>>>>>>>> Currently the Steam Deck OLED fails with Kernel 6.8.2 when trying to initialise the topology for the device.
> >>>>>>>>> I'm using the `sof-vangogh-nau8821-max.tplg` file from the Steam Deck OLED and associated firmware.
> >>>>>>>> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=218677
> >>>>>>> A quick search made me find these posts/threads that foreshadow the problem:
> >>>>>>>
> >>>>>>> https://lore.kernel.org/lkml/[email protected]/
> >>>>>>> https://lore.kernel.org/all/[email protected]/
> >>>>>>>
> >>>>>>> From a quick look at the second discussion it seems a bit like we are
> >>>>>>> screwed, as iiutc topology files are out in the wild for one or the
> >>>>>>> other approach. So we might have to bite a bullet there and accept the
> >>>>>>> regression -- but I might easily be totally mistaken here. Would be good
> >>>>>>> in one of the experts (Venkata Prasad Potturu maybe?) could quickly
> >>>>>>> explain what's up here.
> >>>>>>
> >>>>>> The problem here is that Steam Deck OLED provides a topology file which
> >>>>>> uses an incorrect DAI link ID for BT codec.
> >>>>>>
> >>>>>> Patch [1] moves BT_BE_ID to position 2 in the enum, as expected by the
> >>>>>> topology, but this is not a change that can be accepted upstream as it
> >>>>>> would break other devices which rely on BT_BE_ID set to 3.
> >>>>>>
> >>>>>> The proper solution would be to update the topology file on Steam Deck,
> >>>>>> but this is probably not straightforward to be accomplished as it would
> >>>>>> break the compatibility with the currently released (downstream)
> >>>>>> kernels.
> >>>>>>
> >>>>>> Hopefully, this sheds some more light on the matter.
> >>>>>>
> >>>>>> [1]: https://lore.kernel.org/all/[email protected]/
> >>>>>
> >>>>> Many thx, yes, this sheds some light on the matter. But there is one
> >>>>> remaining question: can we make both camps happy somehow? E.g. something
> >>>>> along the lines of "first detect if the topology file has BT_BE_ID in
> >>>>> position 2 or 3 and then act accordingly?
> >>>>
> >>>> Right, I have this on my TODOs list but haven't managed to dig into it
> >>>> yet. However, that would be most likely just another hack to be carried
> >>>> on until the transition to a fixed topology is completed.
> >>>
> >>> Well, sure it's a hack, but the thing is, our number one rule is "no
> >>> regressions" and the reporter apparently faces one (see start of the
> >>> thread). So to fulfill this rule it would be ideal to have a fix
> >>> available soonish or revert the culprit and reply it later together with
> >>> the fix.
> >>
> >> Hmm, unless I'm missing something, this shouldn't been considered a
> >> regression. As I explained previously, the OLED model was launched with
> >> a downstream implementation of the Vangogh SOF drivers on top of v6.1,
> >> as there was no upstream support back then.
> >>
> >> When AMD eventually completed the upstreaming process of their SOF
> >> drivers in v6.6, we ended up with this unfortunate ID assignments
> >> incompatibility. Hence I cannot see how the mainline kernel would have
> >> worked without applying patch [1] above, unless the reporter
> >> experimented with a different topology (which is not the case if I got
> >> this right).
> >>
> >>> Do we know which change that went into 6.8 caused this? Or is a revert
> >>> out-of-the question as it will likely break things for other users that
> >>> already upgraded to 6.8 and have a matching topology file? (/me fears
> >>> the answer to the latter question is "yes", but I have to ask :-/)
> >>
> >> We need to understand how the reporter got this working with mainline
> >> kernels without applying any out-of-tree patches.
> >
> > Ahh, okay, thx, now I understand this better. You are most likely
> > correct. It also made me look at the initial report again where I
> > noticed "When *I manually patched support* for the 6.6 or 6.7 mainline
> > kernel it worked fine.", so yes, this likely is not a regression.
>
> It would be interesting to find out what the *manually patched support*
> involved. FWIW, to get audio working with v6.8, it's also necessary to
> backport several patches from v6.9-rc1 - I would consider the following:
>
> Fixes: f0f1021fc9cb ("ASoC: amd: acp: Drop redundant initialization of machine driver data")
> Fixes: 68ab29426d88 ("ASoC: amd: acp: Make use of existing *_CODEC_DAI macros")
> Fixes: d0ada20279db ("ASoC: amd: acp: Add missing error handling in sof-mach")
> Fixes: 222be59e5eed ("ASoC: SOF: amd: Fix memory leak in amd_sof_acp_probe()")
> Fixes: a13f0c3c0e8f ("ASoC: SOF: amd: Optimize quirk for Valve Galileo")
> Fixes: 369b997a1371 ("ASoC: SOF: core: Skip firmware test for custom loaders")
> Fixes: d9cacc1a2af2 ("ASoC: SOF: amd: Compute file paths on firmware load")
> Fixes: 33c3d8133307 ("ASoC: SOF: amd: Move signed_fw_image to struct acp_quirk_entry")
> Fixes: 094d11768f74 ("ASoC: SOF: amd: Skip IRAM/DRAM size modification for Steam Deck OLED")
>
> I think most if not all of the mandatory fixes from the list above have been
> already included in the latest v6.8 stable updates, but I haven't actually
> tested.
>
> >
> > Thx for your help and sorry for the trouble I caused!
>
> No problem at all!
>
> Regards,
> Cristian
--
Kind Regards,
Daniel
+61 (0)409611884
On 4/9/24 1:57 PM, Daniel Martin wrote:
> The manual patches were worked from the Steam Deck kernel, trial &
> error with partial support in 6.6 at the time.
> 6.8 sources where this has been implemented recently were not yet
> available or in linux-next.
> Suffice to say the code matches up almost perfectly apart from the
> enum issues which are thus being discussed.
> I still go back to the point, apart from the Steam Deck, who else is
> using this named topology file?
> I don't think anyone is, therefore the enum numbering should match the
> current Steam Deck kernel implementation & topology file.
The entries of enum be_id cannot be changed in mainline without breaking
devices which are not part of the Steam Deck family.
I do not have additional details other than the information provided by
AMD in the context of the initial patch submission:
https://lore.kernel.org/all/[email protected]/
>
> On Tue, 9 Apr 2024 at 19:55, Cristian Ciocaltea
> <[email protected]> wrote:
>>
>> On 4/9/24 12:19 PM, Linux regression tracking (Thorsten Leemhuis) wrote:
>>> On 09.04.24 10:47, Cristian Ciocaltea wrote:
>>>> On 4/9/24 11:04 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
>>>>> On 09.04.24 09:42, Cristian Ciocaltea wrote:
>>>>>> On 4/9/24 7:44 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
>>>>>>> On 09.04.24 01:44, Cristian Ciocaltea wrote:
>>>>>>>> On 4/7/24 10:47 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
>>>>>>>>> On 06.04.24 15:08, Bagas Sanjaya wrote:
>>>>>>>>>> On Bugzilla, Daniel <[email protected]> reported topology regression
>>>>>>>>>> on Steam Deck OLED [1]. He wrote:
>>>>>>>>
>>>>>>>>>>> I'm adding this here, I hope it's the correct place.
>>>>>>>>>>> Currently the Steam Deck OLED fails with Kernel 6.8.2 when trying to initialise the topology for the device.
>>>>>>>>>>> I'm using the `sof-vangogh-nau8821-max.tplg` file from the Steam Deck OLED and associated firmware.
>>>>>>>>>> [1]: https://bugzilla.kernel.org/show_bug.cgi?id=218677
>>>>>>>>> A quick search made me find these posts/threads that foreshadow the problem:
>>>>>>>>>
>>>>>>>>> https://lore.kernel.org/lkml/[email protected]/
>>>>>>>>> https://lore.kernel.org/all/[email protected]/
>>>>>>>>>
>>>>>>>>> From a quick look at the second discussion it seems a bit like we are
>>>>>>>>> screwed, as iiutc topology files are out in the wild for one or the
>>>>>>>>> other approach. So we might have to bite a bullet there and accept the
>>>>>>>>> regression -- but I might easily be totally mistaken here. Would be good
>>>>>>>>> in one of the experts (Venkata Prasad Potturu maybe?) could quickly
>>>>>>>>> explain what's up here.
>>>>>>>>
>>>>>>>> The problem here is that Steam Deck OLED provides a topology file which
>>>>>>>> uses an incorrect DAI link ID for BT codec.
>>>>>>>>
>>>>>>>> Patch [1] moves BT_BE_ID to position 2 in the enum, as expected by the
>>>>>>>> topology, but this is not a change that can be accepted upstream as it
>>>>>>>> would break other devices which rely on BT_BE_ID set to 3.
>>>>>>>>
>>>>>>>> The proper solution would be to update the topology file on Steam Deck,
>>>>>>>> but this is probably not straightforward to be accomplished as it would
>>>>>>>> break the compatibility with the currently released (downstream)
>>>>>>>> kernels.
>>>>>>>>
>>>>>>>> Hopefully, this sheds some more light on the matter.
>>>>>>>>
>>>>>>>> [1]: https://lore.kernel.org/all/[email protected]/
>>>>>>>
>>>>>>> Many thx, yes, this sheds some light on the matter. But there is one
>>>>>>> remaining question: can we make both camps happy somehow? E.g. something
>>>>>>> along the lines of "first detect if the topology file has BT_BE_ID in
>>>>>>> position 2 or 3 and then act accordingly?
>>>>>>
>>>>>> Right, I have this on my TODOs list but haven't managed to dig into it
>>>>>> yet. However, that would be most likely just another hack to be carried
>>>>>> on until the transition to a fixed topology is completed.
>>>>>
>>>>> Well, sure it's a hack, but the thing is, our number one rule is "no
>>>>> regressions" and the reporter apparently faces one (see start of the
>>>>> thread). So to fulfill this rule it would be ideal to have a fix
>>>>> available soonish or revert the culprit and reply it later together with
>>>>> the fix.
>>>>
>>>> Hmm, unless I'm missing something, this shouldn't been considered a
>>>> regression. As I explained previously, the OLED model was launched with
>>>> a downstream implementation of the Vangogh SOF drivers on top of v6.1,
>>>> as there was no upstream support back then.
>>>>
>>>> When AMD eventually completed the upstreaming process of their SOF
>>>> drivers in v6.6, we ended up with this unfortunate ID assignments
>>>> incompatibility. Hence I cannot see how the mainline kernel would have
>>>> worked without applying patch [1] above, unless the reporter
>>>> experimented with a different topology (which is not the case if I got
>>>> this right).
>>>>
>>>>> Do we know which change that went into 6.8 caused this? Or is a revert
>>>>> out-of-the question as it will likely break things for other users that
>>>>> already upgraded to 6.8 and have a matching topology file? (/me fears
>>>>> the answer to the latter question is "yes", but I have to ask :-/)
>>>>
>>>> We need to understand how the reporter got this working with mainline
>>>> kernels without applying any out-of-tree patches.
>>>
>>> Ahh, okay, thx, now I understand this better. You are most likely
>>> correct. It also made me look at the initial report again where I
>>> noticed "When *I manually patched support* for the 6.6 or 6.7 mainline
>>> kernel it worked fine.", so yes, this likely is not a regression.
>>
>> It would be interesting to find out what the *manually patched support*
>> involved. FWIW, to get audio working with v6.8, it's also necessary to
>> backport several patches from v6.9-rc1 - I would consider the following:
>>
>> Fixes: f0f1021fc9cb ("ASoC: amd: acp: Drop redundant initialization of machine driver data")
>> Fixes: 68ab29426d88 ("ASoC: amd: acp: Make use of existing *_CODEC_DAI macros")
>> Fixes: d0ada20279db ("ASoC: amd: acp: Add missing error handling in sof-mach")
>> Fixes: 222be59e5eed ("ASoC: SOF: amd: Fix memory leak in amd_sof_acp_probe()")
>> Fixes: a13f0c3c0e8f ("ASoC: SOF: amd: Optimize quirk for Valve Galileo")
>> Fixes: 369b997a1371 ("ASoC: SOF: core: Skip firmware test for custom loaders")
>> Fixes: d9cacc1a2af2 ("ASoC: SOF: amd: Compute file paths on firmware load")
>> Fixes: 33c3d8133307 ("ASoC: SOF: amd: Move signed_fw_image to struct acp_quirk_entry")
>> Fixes: 094d11768f74 ("ASoC: SOF: amd: Skip IRAM/DRAM size modification for Steam Deck OLED")
>>
>> I think most if not all of the mandatory fixes from the list above have been
>> already included in the latest v6.8 stable updates, but I haven't actually
>> tested.
>>
>>>
>>> Thx for your help and sorry for the trouble I caused!
>>
>> No problem at all!
>>
>> Regards,
>> Cristian
>
>
>