Re: [PATCH] ASoC: Intel: avs: Provide support for fallback topology

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 9/5/23 09:58, Amadeusz Sławiński wrote:
> On 9/5/2023 2:42 PM, Pierre-Louis Bossart wrote:
>>
>>
>> On 9/5/23 05:31, Amadeusz Sławiński wrote:
>>> HDA and HDMI devices are simple enough that in case of user not having
>>> topology tailored to their device, they can use fallback topology.
>>>
>>> Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@xxxxxxxxxxxxxxx>
>>> ---
>>>   sound/soc/intel/avs/pcm.c | 22 ++++++++++++++++++++++
>>>   1 file changed, 22 insertions(+)
>>>
>>> diff --git a/sound/soc/intel/avs/pcm.c b/sound/soc/intel/avs/pcm.c
>>> index 1fbb2c2fadb5..8565a530706d 100644
>>> --- a/sound/soc/intel/avs/pcm.c
>>> +++ b/sound/soc/intel/avs/pcm.c
>>> @@ -796,6 +796,28 @@ static int avs_component_probe(struct
>>> snd_soc_component *component)
>>>         ret = avs_load_topology(component, filename);
>>>       kfree(filename);
>>> +    if (ret == -ENOENT && !strncmp(mach->tplg_filename, "hda-", 4)) {
>>> +        unsigned int vendor_id;
>>> +
>>> +        if (sscanf(mach->tplg_filename, "hda-%08x-tplg.bin",
>>> &vendor_id) != 1)
>>> +            return ret;
>>> +
>>> +        if (((vendor_id >> 16) & 0xFFFF) == 0x8086)
>>> +            mach->tplg_filename = devm_kasprintf(adev->dev, GFP_KERNEL,
>>> +                                 "hda-8086-generic-tplg.bin");
>>
>> it's very odd to test for 0x8086 in a driver that only supports Intel
>> devices, isn't it?
>>
>> One of these two branches is always-true or there's a missing
>> explanation on what this 0x8086 is used for?
>>
> 
> Differentiating between generic codecs
> (https://github.com/thesofproject/avs-topology-xml/tree/main/hda) and
> hdmi ones
> (https://github.com/thesofproject/avs-topology-xml/tree/main/hdmi), as
> topology targets codec.


Ah yes, 0x8086 for the codec vendor. I must admit I didn't click after a
4-day week-end...

BTW your list of topologies helps with my assertion that we are missing
a 'hardware layer' in the topology framework, it makes no sense to have
a proliferation of topology files that all look the same. We really need
the ability to tell which endpoints are active or not, and which
hardware interface to use on a given platform. copy-pasting and using
macros is going to lead us into a maintenance nightmare.



[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux