diff mbox series

[11/11] ASoC: SOF: topology: Add new DAI type entry for SOF_DAI_AMD_BT

Message ID 20231209205351.880797-12-cristian.ciocaltea@collabora.com (mailing list archive)
State Superseded
Headers show
Series Improve SOF support for Steam Deck OLED | expand

Commit Message

Cristian Ciocaltea Dec. 9, 2023, 8:53 p.m. UTC
Commit efb931cdc4b9 ("ASoC: SOF: topology: Add support for AMD ACP
DAIs") registered "ACP" name for SOF_DAI_AMD_BT DAI type.  However, some
boards, i.e. Steam Deck OLED, seem to require "ACPBT" for the same type:

[  467.489680] snd_sof_amd_vangogh 0000:04:00.5: ipc tx error for 0x30030000 (msg/reply size: 16/0): -22
[  467.492775] snd_sof_amd_vangogh 0000:04:00.5: sof_ipc3_route_setup: route ACPBT2.IN -> BUF5.0 failed
[  467.495839] snd_sof_amd_vangogh 0000:04:00.5: sof_ipc3_set_up_all_pipelines: route set up failed
[  467.499128] snd_sof_amd_vangogh 0000:04:00.5: error: tplg component load failed -22
[  467.502210] snd_sof_amd_vangogh 0000:04:00.5: error: failed to load DSP topology -22
[  467.505289] snd_sof_amd_vangogh 0000:04:00.5: ASoC: error at snd_soc_component_probe on 0000:04:00.5: -22
[  467.508430] sof_mach nau8821-max: ASoC: failed to instantiate card -22
[  467.511725] sof_mach nau8821-max: error -EINVAL: Failed to register card(sof-nau8821-max)
[  467.514861] sof_mach: probe of nau8821-max failed with error -22

Add "ACPBT" alias for "ACP" SOF DAI type.

Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
 sound/soc/sof/topology.c | 1 +
 1 file changed, 1 insertion(+)

Comments

Venkata Prasad Potturu Dec. 10, 2023, 3:30 a.m. UTC | #1
On 12/10/23 02:23, Cristian Ciocaltea wrote:
> Commit efb931cdc4b9 ("ASoC: SOF: topology: Add support for AMD ACP
> DAIs") registered "ACP" name for SOF_DAI_AMD_BT DAI type.  However, some
> boards, i.e. Steam Deck OLED, seem to require "ACPBT" for the same type:
>
> [  467.489680] snd_sof_amd_vangogh 0000:04:00.5: ipc tx error for 0x30030000 (msg/reply size: 16/0): -22
> [  467.492775] snd_sof_amd_vangogh 0000:04:00.5: sof_ipc3_route_setup: route ACPBT2.IN -> BUF5.0 failed
> [  467.495839] snd_sof_amd_vangogh 0000:04:00.5: sof_ipc3_set_up_all_pipelines: route set up failed
> [  467.499128] snd_sof_amd_vangogh 0000:04:00.5: error: tplg component load failed -22
> [  467.502210] snd_sof_amd_vangogh 0000:04:00.5: error: failed to load DSP topology -22
> [  467.505289] snd_sof_amd_vangogh 0000:04:00.5: ASoC: error at snd_soc_component_probe on 0000:04:00.5: -22
> [  467.508430] sof_mach nau8821-max: ASoC: failed to instantiate card -22
> [  467.511725] sof_mach nau8821-max: error -EINVAL: Failed to register card(sof-nau8821-max)
> [  467.514861] sof_mach: probe of nau8821-max failed with error -22
>
> Add "ACPBT" alias for "ACP" SOF DAI type.
>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
>   sound/soc/sof/topology.c | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/sound/soc/sof/topology.c b/sound/soc/sof/topology.c
> index e3e7fbe40fa6..73bf791e7520 100644
> --- a/sound/soc/sof/topology.c
> +++ b/sound/soc/sof/topology.c
> @@ -290,6 +290,7 @@ static const struct sof_dai_types sof_dais[] = {
>   	{"SAI", SOF_DAI_IMX_SAI},
>   	{"ESAI", SOF_DAI_IMX_ESAI},
>   	{"ACP", SOF_DAI_AMD_BT},
> +	{"ACPBT", SOF_DAI_AMD_BT},
No need to create the alias name, we can directly modify ACP to ACPBT as 
ACP is not using anywhere.
>   	{"ACPSP", SOF_DAI_AMD_SP},
>   	{"ACPDMIC", SOF_DAI_AMD_DMIC},
>   	{"ACPHS", SOF_DAI_AMD_HS},
Cristian Ciocaltea Dec. 10, 2023, 9:08 a.m. UTC | #2
On 12/10/23 05:30, Venkata Prasad Potturu wrote:
> 
> On 12/10/23 02:23, Cristian Ciocaltea wrote:
>> Commit efb931cdc4b9 ("ASoC: SOF: topology: Add support for AMD ACP
>> DAIs") registered "ACP" name for SOF_DAI_AMD_BT DAI type.  However, some
>> boards, i.e. Steam Deck OLED, seem to require "ACPBT" for the same type:
>>
>> [  467.489680] snd_sof_amd_vangogh 0000:04:00.5: ipc tx error for
>> 0x30030000 (msg/reply size: 16/0): -22
>> [  467.492775] snd_sof_amd_vangogh 0000:04:00.5: sof_ipc3_route_setup:
>> route ACPBT2.IN -> BUF5.0 failed
>> [  467.495839] snd_sof_amd_vangogh 0000:04:00.5:
>> sof_ipc3_set_up_all_pipelines: route set up failed
>> [  467.499128] snd_sof_amd_vangogh 0000:04:00.5: error: tplg component
>> load failed -22
>> [  467.502210] snd_sof_amd_vangogh 0000:04:00.5: error: failed to load
>> DSP topology -22
>> [  467.505289] snd_sof_amd_vangogh 0000:04:00.5: ASoC: error at
>> snd_soc_component_probe on 0000:04:00.5: -22
>> [  467.508430] sof_mach nau8821-max: ASoC: failed to instantiate card -22
>> [  467.511725] sof_mach nau8821-max: error -EINVAL: Failed to register
>> card(sof-nau8821-max)
>> [  467.514861] sof_mach: probe of nau8821-max failed with error -22
>>
>> Add "ACPBT" alias for "ACP" SOF DAI type.
>>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>> ---
>>   sound/soc/sof/topology.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/sound/soc/sof/topology.c b/sound/soc/sof/topology.c
>> index e3e7fbe40fa6..73bf791e7520 100644
>> --- a/sound/soc/sof/topology.c
>> +++ b/sound/soc/sof/topology.c
>> @@ -290,6 +290,7 @@ static const struct sof_dai_types sof_dais[] = {
>>       {"SAI", SOF_DAI_IMX_SAI},
>>       {"ESAI", SOF_DAI_IMX_ESAI},
>>       {"ACP", SOF_DAI_AMD_BT},
>> +    {"ACPBT", SOF_DAI_AMD_BT},
> No need to create the alias name, we can directly modify ACP to ACPBT as
> ACP is not using anywhere.

Great, thanks, will do in v2.

>>       {"ACPSP", SOF_DAI_AMD_SP},
>>       {"ACPDMIC", SOF_DAI_AMD_DMIC},
>>       {"ACPHS", SOF_DAI_AMD_HS},
Venkata Prasad Potturu Dec. 10, 2023, 9:51 a.m. UTC | #3
On 12/10/23 14:38, Cristian Ciocaltea wrote:
> On 12/10/23 05:30, Venkata Prasad Potturu wrote:
>> On 12/10/23 02:23, Cristian Ciocaltea wrote:
>>> Commit efb931cdc4b9 ("ASoC: SOF: topology: Add support for AMD ACP
>>> DAIs") registered "ACP" name for SOF_DAI_AMD_BT DAI type.  However, some
>>> boards, i.e. Steam Deck OLED, seem to require "ACPBT" for the same type:
>>>
>>> [  467.489680] snd_sof_amd_vangogh 0000:04:00.5: ipc tx error for
>>> 0x30030000 (msg/reply size: 16/0): -22
>>> [  467.492775] snd_sof_amd_vangogh 0000:04:00.5: sof_ipc3_route_setup:
>>> route ACPBT2.IN -> BUF5.0 failed
>>> [  467.495839] snd_sof_amd_vangogh 0000:04:00.5:
>>> sof_ipc3_set_up_all_pipelines: route set up failed
>>> [  467.499128] snd_sof_amd_vangogh 0000:04:00.5: error: tplg component
>>> load failed -22
>>> [  467.502210] snd_sof_amd_vangogh 0000:04:00.5: error: failed to load
>>> DSP topology -22
>>> [  467.505289] snd_sof_amd_vangogh 0000:04:00.5: ASoC: error at
>>> snd_soc_component_probe on 0000:04:00.5: -22
>>> [  467.508430] sof_mach nau8821-max: ASoC: failed to instantiate card -22
>>> [  467.511725] sof_mach nau8821-max: error -EINVAL: Failed to register
>>> card(sof-nau8821-max)
>>> [  467.514861] sof_mach: probe of nau8821-max failed with error -22
>>>
>>> Add "ACPBT" alias for "ACP" SOF DAI type.
>>>
>>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>>> ---
>>>    sound/soc/sof/topology.c | 1 +
>>>    1 file changed, 1 insertion(+)
>>>
>>> diff --git a/sound/soc/sof/topology.c b/sound/soc/sof/topology.c
>>> index e3e7fbe40fa6..73bf791e7520 100644
>>> --- a/sound/soc/sof/topology.c
>>> +++ b/sound/soc/sof/topology.c
>>> @@ -290,6 +290,7 @@ static const struct sof_dai_types sof_dais[] = {
>>>        {"SAI", SOF_DAI_IMX_SAI},
>>>        {"ESAI", SOF_DAI_IMX_ESAI},
>>>        {"ACP", SOF_DAI_AMD_BT},
>>> +    {"ACPBT", SOF_DAI_AMD_BT},
>> No need to create the alias name, we can directly modify ACP to ACPBT as
>> ACP is not using anywhere.
> Great, thanks, will do in v2.
This should send to SOF git repo for rewiew, once SOF reviewers approved 
this, again need to send to broonie git.
All the changes in sound/soc/sof/ path should go to SOF git.
>
>>>        {"ACPSP", SOF_DAI_AMD_SP},
>>>        {"ACPDMIC", SOF_DAI_AMD_DMIC},
>>>        {"ACPHS", SOF_DAI_AMD_HS},
Cristian Ciocaltea Dec. 10, 2023, 10:12 a.m. UTC | #4
On 12/10/23 11:51, Venkata Prasad Potturu wrote:
> 
> On 12/10/23 14:38, Cristian Ciocaltea wrote:
>> On 12/10/23 05:30, Venkata Prasad Potturu wrote:
>>> On 12/10/23 02:23, Cristian Ciocaltea wrote:
>>>> Commit efb931cdc4b9 ("ASoC: SOF: topology: Add support for AMD ACP
>>>> DAIs") registered "ACP" name for SOF_DAI_AMD_BT DAI type.  However,
>>>> some
>>>> boards, i.e. Steam Deck OLED, seem to require "ACPBT" for the same
>>>> type:
>>>>
>>>> [  467.489680] snd_sof_amd_vangogh 0000:04:00.5: ipc tx error for
>>>> 0x30030000 (msg/reply size: 16/0): -22
>>>> [  467.492775] snd_sof_amd_vangogh 0000:04:00.5: sof_ipc3_route_setup:
>>>> route ACPBT2.IN -> BUF5.0 failed
>>>> [  467.495839] snd_sof_amd_vangogh 0000:04:00.5:
>>>> sof_ipc3_set_up_all_pipelines: route set up failed
>>>> [  467.499128] snd_sof_amd_vangogh 0000:04:00.5: error: tplg component
>>>> load failed -22
>>>> [  467.502210] snd_sof_amd_vangogh 0000:04:00.5: error: failed to load
>>>> DSP topology -22
>>>> [  467.505289] snd_sof_amd_vangogh 0000:04:00.5: ASoC: error at
>>>> snd_soc_component_probe on 0000:04:00.5: -22
>>>> [  467.508430] sof_mach nau8821-max: ASoC: failed to instantiate
>>>> card -22
>>>> [  467.511725] sof_mach nau8821-max: error -EINVAL: Failed to register
>>>> card(sof-nau8821-max)
>>>> [  467.514861] sof_mach: probe of nau8821-max failed with error -22
>>>>
>>>> Add "ACPBT" alias for "ACP" SOF DAI type.
>>>>
>>>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>>>> ---
>>>>    sound/soc/sof/topology.c | 1 +
>>>>    1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/sound/soc/sof/topology.c b/sound/soc/sof/topology.c
>>>> index e3e7fbe40fa6..73bf791e7520 100644
>>>> --- a/sound/soc/sof/topology.c
>>>> +++ b/sound/soc/sof/topology.c
>>>> @@ -290,6 +290,7 @@ static const struct sof_dai_types sof_dais[] = {
>>>>        {"SAI", SOF_DAI_IMX_SAI},
>>>>        {"ESAI", SOF_DAI_IMX_ESAI},
>>>>        {"ACP", SOF_DAI_AMD_BT},
>>>> +    {"ACPBT", SOF_DAI_AMD_BT},
>>> No need to create the alias name, we can directly modify ACP to ACPBT as
>>> ACP is not using anywhere.
>> Great, thanks, will do in v2.
> This should send to SOF git repo for rewiew, once SOF reviewers approved
> this, again need to send to broonie git.
> All the changes in sound/soc/sof/ path should go to SOF git.

Unfortunately I'm not familiar with the SOF dev workflow. So it's not
enough to have this patch cc-ed to sound-open-firmware@alsa-project.org?

>>>>        {"ACPSP", SOF_DAI_AMD_SP},
>>>>        {"ACPDMIC", SOF_DAI_AMD_DMIC},
>>>>        {"ACPHS", SOF_DAI_AMD_HS},
Mark Brown Dec. 10, 2023, 2:01 p.m. UTC | #5
On Sun, Dec 10, 2023 at 12:12:53PM +0200, Cristian Ciocaltea wrote:
> On 12/10/23 11:51, Venkata Prasad Potturu wrote:

> > This should send to SOF git repo for rewiew, once SOF reviewers approved
> > this, again need to send to broonie git.
> > All the changes in sound/soc/sof/ path should go to SOF git.

> Unfortunately I'm not familiar with the SOF dev workflow. So it's not
> enough to have this patch cc-ed to sound-open-firmware@alsa-project.org?

The SOF people basically do their own thing in github at

   https://github.com/thesofproject/linux

with a github workflow and submit their patches upstream in batches a
few times a release, however my understanding is that their workflow can
cope with things going in directly upstream as well.
Cristian Ciocaltea Dec. 10, 2023, 3:50 p.m. UTC | #6
On 12/10/23 16:01, Mark Brown wrote:
> On Sun, Dec 10, 2023 at 12:12:53PM +0200, Cristian Ciocaltea wrote:
>> On 12/10/23 11:51, Venkata Prasad Potturu wrote:
> 
>>> This should send to SOF git repo for rewiew, once SOF reviewers approved
>>> this, again need to send to broonie git.
>>> All the changes in sound/soc/sof/ path should go to SOF git.
> 
>> Unfortunately I'm not familiar with the SOF dev workflow. So it's not
>> enough to have this patch cc-ed to sound-open-firmware@alsa-project.org?
> 
> The SOF people basically do their own thing in github at
> 
>    https://github.com/thesofproject/linux
> 
> with a github workflow and submit their patches upstream in batches a
> few times a release, however my understanding is that their workflow can
> cope with things going in directly upstream as well.

Thanks for clarifying, Mark!  That would greatly simplify and speedup
the whole process, at least for trivial patches like this one.
Venkata Prasad Potturu Dec. 11, 2023, 5:58 a.m. UTC | #7
On 12/10/23 21:20, Cristian Ciocaltea wrote:
> On 12/10/23 16:01, Mark Brown wrote:
>> On Sun, Dec 10, 2023 at 12:12:53PM +0200, Cristian Ciocaltea wrote:
>>> On 12/10/23 11:51, Venkata Prasad Potturu wrote:
>>>> This should send to SOF git repo for rewiew, once SOF reviewers approved
>>>> this, again need to send to broonie git.
>>>> All the changes in sound/soc/sof/ path should go to SOF git.
>>> Unfortunately I'm not familiar with the SOF dev workflow. So it's not
>>> enough to have this patch cc-ed to sound-open-firmware@alsa-project.org?
>> The SOF people basically do their own thing in github at
>>
>>     https://github.com/thesofproject/linux
>>
>> with a github workflow and submit their patches upstream in batches a
>> few times a release, however my understanding is that their workflow can
>> cope with things going in directly upstream as well.
> Thanks for clarifying, Mark!  That would greatly simplify and speedup
> the whole process, at least for trivial patches like this one.

Hi Cristian,

We have created a Pull request in SOF git hub for I2S BT support.
please hold v2 version SOF patches till below PR get's merged.
PR:- https://github.com/thesofproject/linux/pull/4742
Vijendar Mukunda Dec. 12, 2023, 6:41 a.m. UTC | #8
On 10/12/23 19:31, Mark Brown wrote:
> On Sun, Dec 10, 2023 at 12:12:53PM +0200, Cristian Ciocaltea wrote:
>> On 12/10/23 11:51, Venkata Prasad Potturu wrote:
>>> This should send to SOF git repo for rewiew, once SOF reviewers approved
>>> this, again need to send to broonie git.
>>> All the changes in sound/soc/sof/ path should go to SOF git.
>> Unfortunately I'm not familiar with the SOF dev workflow. So it's not
>> enough to have this patch cc-ed to sound-open-firmware@alsa-project.org?
> The SOF people basically do their own thing in github at
>
>    https://github.com/thesofproject/linux
>
> with a github workflow and submit their patches upstream in batches a
> few times a release, however my understanding is that their workflow can
> cope with things going in directly upstream as well.
If patches are directly pushed to alsa devel list instead of creating pull request for SOF patches
It will break SOF github work flow.
Validation across all the platforms is a potential challenge, and it will also create an overhead
to pull the patches which got merged in to for-next branch, before the all the patches pulled in to SOF
GitHub.
Cristian Ciocaltea Dec. 14, 2023, 12:23 p.m. UTC | #9
On 12/11/23 07:58, Venkata Prasad Potturu wrote:
> 
> On 12/10/23 21:20, Cristian Ciocaltea wrote:
>> On 12/10/23 16:01, Mark Brown wrote:
>>> On Sun, Dec 10, 2023 at 12:12:53PM +0200, Cristian Ciocaltea wrote:
>>>> On 12/10/23 11:51, Venkata Prasad Potturu wrote:
>>>>> This should send to SOF git repo for rewiew, once SOF reviewers
>>>>> approved
>>>>> this, again need to send to broonie git.
>>>>> All the changes in sound/soc/sof/ path should go to SOF git.
>>>> Unfortunately I'm not familiar with the SOF dev workflow. So it's not
>>>> enough to have this patch cc-ed to
>>>> sound-open-firmware@alsa-project.org?
>>> The SOF people basically do their own thing in github at
>>>
>>>     https://github.com/thesofproject/linux
>>>
>>> with a github workflow and submit their patches upstream in batches a
>>> few times a release, however my understanding is that their workflow can
>>> cope with things going in directly upstream as well.
>> Thanks for clarifying, Mark!  That would greatly simplify and speedup
>> the whole process, at least for trivial patches like this one.
> 
> Hi Cristian,
> 
> We have created a Pull request in SOF git hub for I2S BT support.
> please hold v2 version SOF patches till below PR get's merged.
> PR:- https://github.com/thesofproject/linux/pull/4742

Hi Venkata,

If this is going to be handled via the github workflow, this patch
should be removed from the series.  Since there is no dependency on it,
I cannot see a reason to put v2 on hold.

Do I miss something?

Thanks,
Cristian
Venkata Prasad Potturu Dec. 14, 2023, 12:36 p.m. UTC | #10
On 12/14/23 17:53, Cristian Ciocaltea wrote:
> On 12/11/23 07:58, Venkata Prasad Potturu wrote:
>> On 12/10/23 21:20, Cristian Ciocaltea wrote:
>>> On 12/10/23 16:01, Mark Brown wrote:
>>>> On Sun, Dec 10, 2023 at 12:12:53PM +0200, Cristian Ciocaltea wrote:
>>>>> On 12/10/23 11:51, Venkata Prasad Potturu wrote:
>>>>>> This should send to SOF git repo for rewiew, once SOF reviewers
>>>>>> approved
>>>>>> this, again need to send to broonie git.
>>>>>> All the changes in sound/soc/sof/ path should go to SOF git.
>>>>> Unfortunately I'm not familiar with the SOF dev workflow. So it's not
>>>>> enough to have this patch cc-ed to
>>>>> sound-open-firmware@alsa-project.org?
>>>> The SOF people basically do their own thing in github at
>>>>
>>>>      https://github.com/thesofproject/linux
>>>>
>>>> with a github workflow and submit their patches upstream in batches a
>>>> few times a release, however my understanding is that their workflow can
>>>> cope with things going in directly upstream as well.
>>> Thanks for clarifying, Mark!  That would greatly simplify and speedup
>>> the whole process, at least for trivial patches like this one.
>> Hi Cristian,
>>
>> We have created a Pull request in SOF git hub for I2S BT support.
>> please hold v2 version SOF patches till below PR get's merged.
>> PR:- https://github.com/thesofproject/linux/pull/4742
> Hi Venkata,
>
> If this is going to be handled via the github workflow, this patch
> should be removed from the series.  Since there is no dependency on it,
> I cannot see a reason to put v2 on hold.
>
> Do I miss something?
Yes, need to drop this patch.

And it's better to follow the github workflow by creating a Pull request 
in SOF github

  for all sof driver related patches, rather than sending patches to 
broonie git directly.

>
> Thanks,
> Cristian
Venkata Prasad Potturu Dec. 14, 2023, 1:15 p.m. UTC | #11
On 12/14/23 17:53, Cristian Ciocaltea wrote:
> On 12/11/23 07:58, Venkata Prasad Potturu wrote:
>> On 12/10/23 21:20, Cristian Ciocaltea wrote:
>>> On 12/10/23 16:01, Mark Brown wrote:
>>>> On Sun, Dec 10, 2023 at 12:12:53PM +0200, Cristian Ciocaltea wrote:
>>>>> On 12/10/23 11:51, Venkata Prasad Potturu wrote:
>>>>>> This should send to SOF git repo for rewiew, once SOF reviewers
>>>>>> approved
>>>>>> this, again need to send to broonie git.
>>>>>> All the changes in sound/soc/sof/ path should go to SOF git.
>>>>> Unfortunately I'm not familiar with the SOF dev workflow. So it's not
>>>>> enough to have this patch cc-ed to
>>>>> sound-open-firmware@alsa-project.org?
>>>> The SOF people basically do their own thing in github at
>>>>
>>>>      https://github.com/thesofproject/linux
>>>>
>>>> with a github workflow and submit their patches upstream in batches a
>>>> few times a release, however my understanding is that their workflow can
>>>> cope with things going in directly upstream as well.
>>> Thanks for clarifying, Mark!  That would greatly simplify and speedup
>>> the whole process, at least for trivial patches like this one.
>> Hi Cristian,
>>
>> We have created a Pull request in SOF git hub for I2S BT support.
>> please hold v2 version SOF patches till below PR get's merged.
>> PR:- https://github.com/thesofproject/linux/pull/4742
> Hi Venkata,
>
> If this is going to be handled via the github workflow, this patch
> should be removed from the series.  Since there is no dependency on it,
> I cannot see a reason to put v2 on hold.
>
> Do I miss something?
Non-sof driver related patches can directly send to broonie git ad v2 
series.
SOF driver patches should send to SOF github to avoid merge conflicts 
as  per guidelines of SOF community.
>
> Thanks,
> Cristian
Cristian Ciocaltea Dec. 14, 2023, 4:42 p.m. UTC | #12
On 12/14/23 15:15, Venkata Prasad Potturu wrote:
> 
> On 12/14/23 17:53, Cristian Ciocaltea wrote:
>> On 12/11/23 07:58, Venkata Prasad Potturu wrote:
>>> On 12/10/23 21:20, Cristian Ciocaltea wrote:
>>>> On 12/10/23 16:01, Mark Brown wrote:
>>>>> On Sun, Dec 10, 2023 at 12:12:53PM +0200, Cristian Ciocaltea wrote:
>>>>>> On 12/10/23 11:51, Venkata Prasad Potturu wrote:
>>>>>>> This should send to SOF git repo for rewiew, once SOF reviewers
>>>>>>> approved
>>>>>>> this, again need to send to broonie git.
>>>>>>> All the changes in sound/soc/sof/ path should go to SOF git.
>>>>>> Unfortunately I'm not familiar with the SOF dev workflow. So it's not
>>>>>> enough to have this patch cc-ed to
>>>>>> sound-open-firmware@alsa-project.org?
>>>>> The SOF people basically do their own thing in github at
>>>>>
>>>>>      https://github.com/thesofproject/linux
>>>>>
>>>>> with a github workflow and submit their patches upstream in batches a
>>>>> few times a release, however my understanding is that their
>>>>> workflow can
>>>>> cope with things going in directly upstream as well.
>>>> Thanks for clarifying, Mark!  That would greatly simplify and speedup
>>>> the whole process, at least for trivial patches like this one.
>>> Hi Cristian,
>>>
>>> We have created a Pull request in SOF git hub for I2S BT support.
>>> please hold v2 version SOF patches till below PR get's merged.
>>> PR:- https://github.com/thesofproject/linux/pull/4742
>> Hi Venkata,
>>
>> If this is going to be handled via the github workflow, this patch
>> should be removed from the series.  Since there is no dependency on it,
>> I cannot see a reason to put v2 on hold.
>>
>> Do I miss something?
> Non-sof driver related patches can directly send to broonie git ad v2
> series.
> SOF driver patches should send to SOF github to avoid merge conflicts
> as  per guidelines of SOF community.

Honestly, I don't really see a high risk of conflicts, the patches are
not that complex and can be simply cherry-picked when needed.  Moreover,
as we already had people reviewing this, splitting this up will only add
confusion and unnecessary burden.

Are there any specific changes you are concerned about and cannot be
really handled here?
Venkata Prasad Potturu Dec. 15, 2023, 9:58 a.m. UTC | #13
On 12/14/23 22:12, Cristian Ciocaltea wrote:
> On 12/14/23 15:15, Venkata Prasad Potturu wrote:
>> On 12/14/23 17:53, Cristian Ciocaltea wrote:
>>> On 12/11/23 07:58, Venkata Prasad Potturu wrote:
>>>> On 12/10/23 21:20, Cristian Ciocaltea wrote:
>>>>> On 12/10/23 16:01, Mark Brown wrote:
>>>>>> On Sun, Dec 10, 2023 at 12:12:53PM +0200, Cristian Ciocaltea wrote:
>>>>>>> On 12/10/23 11:51, Venkata Prasad Potturu wrote:
>>>>>>>> This should send to SOF git repo for rewiew, once SOF reviewers
>>>>>>>> approved
>>>>>>>> this, again need to send to broonie git.
>>>>>>>> All the changes in sound/soc/sof/ path should go to SOF git.
>>>>>>> Unfortunately I'm not familiar with the SOF dev workflow. So it's not
>>>>>>> enough to have this patch cc-ed to
>>>>>>> sound-open-firmware@alsa-project.org?
>>>>>> The SOF people basically do their own thing in github at
>>>>>>
>>>>>>       https://github.com/thesofproject/linux
>>>>>>
>>>>>> with a github workflow and submit their patches upstream in batches a
>>>>>> few times a release, however my understanding is that their
>>>>>> workflow can
>>>>>> cope with things going in directly upstream as well.
>>>>> Thanks for clarifying, Mark!  That would greatly simplify and speedup
>>>>> the whole process, at least for trivial patches like this one.
>>>> Hi Cristian,
>>>>
>>>> We have created a Pull request in SOF git hub for I2S BT support.
>>>> please hold v2 version SOF patches till below PR get's merged.
>>>> PR:- https://github.com/thesofproject/linux/pull/4742
>>> Hi Venkata,
>>>
>>> If this is going to be handled via the github workflow, this patch
>>> should be removed from the series.  Since there is no dependency on it,
>>> I cannot see a reason to put v2 on hold.
>>>
>>> Do I miss something?
>> Non-sof driver related patches can directly send to broonie git ad v2
>> series.
>> SOF driver patches should send to SOF github to avoid merge conflicts
>> as  per guidelines of SOF community.
> Honestly, I don't really see a high risk of conflicts, the patches are
> not that complex and can be simply cherry-picked when needed.  Moreover,
> as we already had people reviewing this, splitting this up will only add
> confusion and unnecessary burden.
>
> Are there any specific changes you are concerned about and cannot be
> really handled here?
This is not the concern about this patch series,
Generally sof driver patches sends to SOF git hub as a PR, these are the 
guidelines by SOF maintainers.
If you still want to send alsa devel list directly, please discuss with 
SOF maintainers.
Cristian Ciocaltea Dec. 15, 2023, 10:57 a.m. UTC | #14
On 12/15/23 11:58, Venkata Prasad Potturu wrote:
> 
> On 12/14/23 22:12, Cristian Ciocaltea wrote:
>> On 12/14/23 15:15, Venkata Prasad Potturu wrote:
>>> On 12/14/23 17:53, Cristian Ciocaltea wrote:
>>>> On 12/11/23 07:58, Venkata Prasad Potturu wrote:
>>>>> On 12/10/23 21:20, Cristian Ciocaltea wrote:
>>>>>> On 12/10/23 16:01, Mark Brown wrote:
>>>>>>> On Sun, Dec 10, 2023 at 12:12:53PM +0200, Cristian Ciocaltea wrote:
>>>>>>>> On 12/10/23 11:51, Venkata Prasad Potturu wrote:
>>>>>>>>> This should send to SOF git repo for rewiew, once SOF reviewers
>>>>>>>>> approved
>>>>>>>>> this, again need to send to broonie git.
>>>>>>>>> All the changes in sound/soc/sof/ path should go to SOF git.
>>>>>>>> Unfortunately I'm not familiar with the SOF dev workflow. So
>>>>>>>> it's not
>>>>>>>> enough to have this patch cc-ed to
>>>>>>>> sound-open-firmware@alsa-project.org?
>>>>>>> The SOF people basically do their own thing in github at
>>>>>>>
>>>>>>>       https://github.com/thesofproject/linux
>>>>>>>
>>>>>>> with a github workflow and submit their patches upstream in
>>>>>>> batches a
>>>>>>> few times a release, however my understanding is that their
>>>>>>> workflow can
>>>>>>> cope with things going in directly upstream as well.
>>>>>> Thanks for clarifying, Mark!  That would greatly simplify and speedup
>>>>>> the whole process, at least for trivial patches like this one.
>>>>> Hi Cristian,
>>>>>
>>>>> We have created a Pull request in SOF git hub for I2S BT support.
>>>>> please hold v2 version SOF patches till below PR get's merged.
>>>>> PR:- https://github.com/thesofproject/linux/pull/4742
>>>> Hi Venkata,
>>>>
>>>> If this is going to be handled via the github workflow, this patch
>>>> should be removed from the series.  Since there is no dependency on it,
>>>> I cannot see a reason to put v2 on hold.
>>>>
>>>> Do I miss something?
>>> Non-sof driver related patches can directly send to broonie git ad v2
>>> series.
>>> SOF driver patches should send to SOF github to avoid merge conflicts
>>> as  per guidelines of SOF community.
>> Honestly, I don't really see a high risk of conflicts, the patches are
>> not that complex and can be simply cherry-picked when needed.  Moreover,
>> as we already had people reviewing this, splitting this up will only add
>> confusion and unnecessary burden.
>>
>> Are there any specific changes you are concerned about and cannot be
>> really handled here?
> This is not the concern about this patch series,
> Generally sof driver patches sends to SOF git hub as a PR, these are the
> guidelines by SOF maintainers.
> If you still want to send alsa devel list directly, please discuss with
> SOF maintainers.

I think this series makes sense as a whole and it's best to be handled
here, as it only provides trivial fixes to issues found on mainline.

If the SOF workflow is unable to integrate fixes submitted upstream, I
would perceive that as a significant drawback of adhering to that
process.  It is hard to believe, though, that this is really the case.

Hence, I kindly ask everyone here to shed some light and help move this
forward.

Thank you,
Cristian
Mark Brown Dec. 15, 2023, 12:53 p.m. UTC | #15
On Fri, Dec 15, 2023 at 12:57:34PM +0200, Cristian Ciocaltea wrote:

> If the SOF workflow is unable to integrate fixes submitted upstream, I
> would perceive that as a significant drawback of adhering to that
> process.  It is hard to believe, though, that this is really the case.

As far as I'm aware they can cope fine with that, though it does help if
people try to avoid needless collisions.  It *does* cause trouble to use
both github and upstream flows simultaneously and there's a preference
for pushing anything substantial through github but picking one or the
other works as far as I know.
diff mbox series

Patch

diff --git a/sound/soc/sof/topology.c b/sound/soc/sof/topology.c
index e3e7fbe40fa6..73bf791e7520 100644
--- a/sound/soc/sof/topology.c
+++ b/sound/soc/sof/topology.c
@@ -290,6 +290,7 @@  static const struct sof_dai_types sof_dais[] = {
 	{"SAI", SOF_DAI_IMX_SAI},
 	{"ESAI", SOF_DAI_IMX_ESAI},
 	{"ACP", SOF_DAI_AMD_BT},
+	{"ACPBT", SOF_DAI_AMD_BT},
 	{"ACPSP", SOF_DAI_AMD_SP},
 	{"ACPDMIC", SOF_DAI_AMD_DMIC},
 	{"ACPHS", SOF_DAI_AMD_HS},