-
Notifications
You must be signed in to change notification settings - Fork 140
Add rate and channels to ALH config #1943
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
singalsu
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
A similar update is needed also for HDA.
|
I will push the FW change next monday. Our CI is still being in the process of clean up. |
|
Can someone please explain why this is needed for ALH, and why it is needed for the HDaudio link DMA? we've worked for other 6 months without the information, why is this needed and why now? |
|
@singalsu wrote:
@singalsu can explain better, but I've understood these parameters are used by some audio processing elements in the pipeline, e.g. ASRC. So if you don't have those in the pipeline, things have worked ok. But e.g. AHL + ASRC pipeline will hit this. |
We are just trying to make ALH work for now, ASRC is not needed in the foreseable future on such platforms, all clocks are owned by the Intel chip. same for HDAudio, the clock is owned by the controller so why worry about ASRC? |
|
@plbossart demux also suffers from this. Not just ASRC. And we need demux for synchronized playback. |
|
@plbossart Also normal SRC needs the parameters from downstream. DAI parameters are propagated to pipeline from downstream. |
sound/soc/sof/intel/hda.c
Outdated
| config.dai_index = (link_id << 8) | (d->id); | ||
| config.alh.stream_id = alh_stream_id; | ||
| config.alh.rate = params_rate(params_data->hw_params); | ||
| config.alh.channels = params_channels(params_data->hw_params); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bardliao who configures the rate and channels present in the hw_params? it's not part of the topology definitions, so where does this come from? the front-end?
Say e.g. that you want to push 1ch on ALH1.2 and 1ch on ALH 2.2, how would this work?
I am not against providing the info to the firmware, but it seems a bit too magical for now. Thanks for details.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bardliao who configures the rate and channels present in the hw_params? it's not part of the topology definitions, so where does this come from? the front-end?
Say e.g. that you want to push 1ch on ALH1.2 and 1ch on ALH 2.2, how would this work?
It comes from soc core. The flow is soc_pcm_hw_params() -> soc_soc_dai_hw_params() ->intel_hw_params() -> intel_params_stream() -> sdw_params_stream().
All ALH dais on the same PCM will get the same hw_params. But, we can configure it to what we want in sdw_params_stream().
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bardliao aren't you making big assumptions about what the demux does here and how it's configured? The SOC code does not have any notion of demux/aggregration, so if the demux configuration was to pass 1 channel to ALH1.2 and 1 channel to ALH2.2, then what would the firmware do?
We also need to consider the capture case, if you have multiple devices that capture from 2 or more devices, then do you really want to send to each ALH DAI the configuration that comes from the SOC core?
I must be missing something here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bardliao aren't you making big assumptions about what the demux does here and how it's configured? The SOC code does not have any notion of demux/aggregration, so if the demux configuration was to pass 1 channel to ALH1.2 and 1 channel to ALH2.2, then what would the firmware do?
We also need to consider the capture case, if you have multiple devices that capture from 2 or more devices, then do you really want to send to each ALH DAI the configuration that comes from the SOC core?
I must be missing something here.
Let's config it on topology :)
kv2019i
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bardliao Code change looks sensible to me. Where's the matching FW change? I couldn't find it in fw PR list and it's not listed in ABI classifier.
|
FW change wasn't up yet. It is now: |
85744b5
|
@bardliao definitely at least channels. Maybe rate too. Dunno about bit depth, I'm not familiar with HDA enough to be able to tell. |
|
@slawblauciak wrote:
Ok that raises a concern. For @singalsu as well. If the FW arch assumes that DAIs can tell the channel count and rate to pipeline components to work correctly, wouldn't these parameters belong to sof_ipc_dai_config? I mean if we now fix ALH and HDA to have this data, how about IMX DAIs (@dbaluta )? |
|
I added the HDA change to this PR with ABI change. @lgirdwood Could you confirm the ABI number? |
include/uapi/sound/sof/abi.h
Outdated
| /* SOF ABI version major, minor and patch numbers */ | ||
| #define SOF_ABI_MAJOR 3 | ||
| #define SOF_ABI_MINOR 15 | ||
| #define SOF_ABI_MINOR 16 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The FW change was made with minor version 15
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The FW change was made with minor version 15
Isn't minor version 15 for "ipc: cc_version: use fixed length for CC_DESC"? And I think the HDA change is not ready on FW side, right? I am not sure if we can use the same minor version with more than one ipc changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The FW change for ALH has already been merged and it uses minor version 15. Maybe better to split this change in that case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can still go in 15. Please update to use 15.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can still go in 15. Please update to use 15.
Got it. Thanks @lgirdwood
Aligned with FW change. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> (backported from thesofproject#1943) Signed-off-by: Hui Wang <hui.wang@canonical.com>
FW will need these params. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> (backported from thesofproject#1943) Signed-off-by: Hui Wang <hui.wang@canonical.com>
|
Updated @plbossart @kv2019i @ranj063 @slawblauciak @singalsu |
Aligned with FW change. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
FW will need these params Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
|
HDA part removed. @plbossart @kv2019i @ranj063 I think the PR is ready for merge now. @lgirdwood has confirmed that this can still go in ABI 3.15.0. I will create another PR for the HDA part. |
|
For some reason the FW change does not show on the ABI classifier, but it's indeed merged: thesofproject/sof#2666 |
|
Note to @bardliao -- I didn't notice this before, but the git commit messages are really, really short. I think we should have a summary of why the change is needed, on the Linux side commits as well. Now we have good description of the problem and solution in FW side commit messages, but on Linux side we just have a "FW needs these params" with no reference to what problem is being solved. As I didn't catch this before and other reviewer's seem ok, I'll go ahead and merge. But let's pay more attention this ins future patches. |
BugLink: https://bugs.launchpad.net/bugs/1872916 Aligned with FW change. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> (backported from thesofproject#1943) Signed-off-by: Hui Wang <hui.wang@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1872916 FW will need these params. Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> (backported from thesofproject#1943) Signed-off-by: Hui Wang <hui.wang@canonical.com>
FW needs to know rate and channels for ALH dai. @slawblauciak will create the corresponding PR on FW side.