Uh oh!
There was an error while loading. Please reload this page.
ASoC: SOF: topology: add support to smart amplifier - #1971
Conversation
The corresponding FW part PR is here: |
plbossart
commented
Apr 1, 2020
I think this is a dangerous path. the 'smart-amp' is by no means generic and the code is not available, it's 3rd-party IP and it should be classified as such. This is not a full-blown process maintained in the SOF tree. At the very least it should be an ID that belongs in the 3rd party range @lgirdwood what's your take on this? |
keyonjie
commented
Apr 1, 2020
@plbossart Thanks for reviewing. I am not sure if your "dangerous" means it could break the amplifier with bad algorithm, or adding more and more new component ID is not the correct path, but let me try to add some information about what we have been doing. Per my understanding, the FW team has been using the model for 3rd-party IP development like this:
@bkokoszx@mrajwa please correct me if I have written something wrong. |
ranj063
commented
Apr 1, 2020
@plbossart I agree that this isnt a scalable solution for supporting 3rd party modules. Do we have a process for adding new modules? |
plbossart
commented
Apr 1, 2020
That makes it impossible to know if the component is implemented with the dummy test version or the real one... Something is missing here really. |
keyonjie
commented
Apr 2, 2020
By default we are using dummy test version in upstream. We plan to add config item for 3rd-party version selection. |
kv2019i
commented
Apr 2, 2020
@keyonjie How does this relate to: |
keyonjie
commented
Apr 2, 2020
Yes they have relationship, the discussion/32 is something like framework refinement, but I had no time to do that yet, it need effort on both FW and driver side together. |
b5067bf to
0f1ca2aCompare
kv2019i
left a comment
There was a problem hiding this comment.
Smart amp seems to be generic enough. The is remaining work to identify the implementations with UUID, but that applies to all generic processing components, not just this one.
plbossart
commented
Apr 3, 2020
I am personally not comfortable with merging this Call me a grumpy old person if you want, but it's a recurring pattern really. There was plenty of time to do the right thing and we didn't. |
keyonjie
commented
Apr 7, 2020
Hi @plbossart There is discussion and extra work to implement the UUID in the driver side, we need to align on that before we can refine the generic processing components. |
lgirdwood
commented
Apr 16, 2020
@plbossart@keyonjie@kv2019i set to MINOR 15 like FW |
lgirdwood
commented
Apr 16, 2020
NAK 15, now at 16. @keyonjie please use MINOR 16. |
keyonjie
commented
Apr 17, 2020
Thanks for the information @lgirdwood . So should we add explicit ABI bump for this change or the MINOR 16 is for update with several other changes? I am not seeing the 16 bumping in the FW corresponding PR thesofproject/sof#1896. |
@lgirdwood@plbossart@kv2019i just checked the ABI MINOR in dirver side is already 16. |
kv2019i
commented
Apr 20, 2020
Update on this PR: the proposal is to use same approach as with EQ, KPB and others for Smart Amp. |
plbossart
left a comment
There was a problem hiding this comment.
let's hope this is the last one we add this way - but I wouldn't hold my breath.
0f1ca2a to
0bd4c1cCompareAdd smart amplifier component support, which is designed as another new type of process component and used for speaker protection algorithm integration. Signed-off-by: Keyon Jie <yang.jie@linux.intel.com>
| if (!strcmp(codec_dai->component->name, MAX_98373_DEV0_NAME)) { | ||
| /* DEV0 tdm slot configuration */ | ||
| snd_soc_dai_set_tdm_slot(codec_dai, 0x30, 3, 8, 16); | ||
| snd_soc_dai_set_tdm_slot(codec_dai, 0x3, 3, 8, 32); |
There was a problem hiding this comment.
unify code style to 0x3, 0x3, 8, 32 ? tx_mask and rx_mask should be in the same style.
There was a problem hiding this comment.
sorry, I just pushed wrong local change recently, this is for debug only so should not go to here :)
0bd4c1c to
7357efeComparekv2019i
commented
Apr 22, 2020
@plbossart wrote:
And you were right of course. Although this was so quick that you could have even held your breath for real while waiting for this one ;D More seriously, I think it is now pretty evident that we need to invest in the infra in this area. I.e. time to proceed with https://github.com/orgs/thesofproject/teams/sof-developers/discussions/32 |
keyonjie
commented
Apr 22, 2020
Thanks @plbossart@kv2019i , yes, that's true, I will put effort to the UUID implementation on driver side after freed from the release. |
plbossart
commented
Apr 24, 2020
@keyonjie and @sebcarlucci can you please chat and figure out which one of these two components goes in first and what ABI level this is. @lgirdwood FYI this is a mess |
keyonjie
commented
Apr 26, 2020
@sebcarlucci is it OK for you to let this smart amplifier one go first, it has been hold for quite long time and it is actually waited from the product. For the ABI version, I think @lgirdwood and @kv2019i has aligned to use Minor 16 for it? @kv2019i has initiated an discussion about ABI refinement in https://github.com/orgs/thesofproject/teams/sof-developers/discussions/35, but I am not sure will that impact this PR actually.
|
sebcarlucci
commented
Apr 26, 2020
@keyonjie Sounds good to me |
keyonjie
commented
Apr 26, 2020
Thanks. |
kv2019i
commented
Apr 27, 2020
There were errors on one machine in CI: https://sof-ci.01.org/linuxpr/PR1971/build3638/devicetest/ So basicly, I could merge this, but I'm a bit puzzled I see no approvals for the FW change thesofproject/sof#1896 .. what's up with that? |
kv2019i
commented
May 7, 2020
The FW change is still missing reviews, not merging this before it's at least approved. |
keyonjie
commented
May 9, 2020
@kv2019i the FW one is approved now: thesofproject/sof#1896 Let's merge it? |
kv2019i
commented
May 12, 2020
FW patch approved, merging this as well. |
Add smart amplifier component support, which is designed as another new
type of process component and used for Dynamic Speaker Management.
Signed-off-by: Keyon Jie yang.jie@linux.intel.com