-
Notifications
You must be signed in to change notification settings - Fork 325
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
topology2: force all SoundWire link-side copiers to use S24_LE #9282
topology2: force all SoundWire link-side copiers to use S24_LE #9282
Conversation
looks like this topology change is enough, according to kernel logs this changes the format
|
Yes, we did it at https://github.com/thesofproject/linux/blob/topic/sof-dev/sound/soc/sof/ipc4-pcm.c#L713. |
@bardliao I vaguely recall that the RT713/1713 configuration would give us one playback stream for the heaphone and two capture streams for headset and mic. Did we have any other cases where we ran out of bandwidth with a 4.8MHz clock? |
Not sure what I did but now I have zero valid bits haha
|
e32b01c
to
c1487a0
Compare
v2: fixed the jack capture. the output format was missing. |
rt713/1713 uses a separated SDW interfaces for mic which is 1713. And rt713 is headset only. rt712 is rt713 + speaker playback. So, rt712 has up to 2 playback streams (headphone and speaker) and 1 capture stream (headset). IOW, the 4.8MHz bandwidth is enough for rt712/713 series. However, rt722 uses the same SDW interface for mic, and has up to 2 playback streams (headphone and speaker) and 2 capture streams (headset and mic). So, rt722 needs 9.6MHz or multilane. Same as rt712-VB. @shumingfan Please correct me if I am wrong. |
Just to be clear @bardliao "the 4.8MHz bandwidth is enough for rt712/713 series" is only true with this topology modification. If we use 32-bits, then we don't have enough bandwidth for 3 streams at 4.8 MHz with a 50x4 frame shape. |
Oh, yes, that's right. I assume 24 bit format is used. |
I am having second-thoughts on the PR, maybe we should avoid hard-coding the valid bits to 24, e.g. if we use 12.288 MHz 32 bits would be just fine since we'd have 64 rows. Probably a macro would be better. |
Then we just need to set SDW_AMP_FMT_24 and SDW_JACK_FMT_24 = true by default. |
Humm... the configuration does not really depend on the type of function but rather on the bus/link configuration. it's really SDW_LINK_BITS or something, and we want this to be a value not a boolean to make the code simpler. |
Be a value is definitely better. I just don't know how to do it. :) |
Using S32_LE wastes bandwdith for no good reason, we should use 24 bits on the link to maximize bus efficiency with the 9.6 MHz bus clock. There is no need for a kernel-side change, the dailink fixup already changes the dailink format based on the topology information. Link: thesofproject#8960 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
in_sample_type $SAMPLE_TYPE_MSB_INTEGER | ||
in_fmt_cfg "$[($in_channels | ($in_valid_bit_depth * 256))]" | ||
} | ||
] | ||
Object.Base.output_audio_format [ | ||
{ | ||
out_bit_depth 32 | ||
out_valid_bit_depth 32 | ||
out_sample_type $SAMPLE_TYPE_MSB_INTEGER | ||
out_valid_bit_depth 24 |
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 is wrong....
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.
fixed now
c1487a0
to
08efff3
Compare
v3: added SDW_LINK_VALID_BITS macro and fixed bad edit for output format. |
Do we need to consider about in_bit_depth and out_bit_depth, too? For example, in_bit_depth and out_bit_depth can be 16 if the valid bit is 16. |
The in_bit_depth is always 32 for the capture dai copier and the output_bit_depth is always 32 for the playback dai copier, isn't it? The options for 16 bits are only on the host-copier side |
I am not sure about it. We have for example out_bit_depth 16 in current |
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.
LGTM, and will get plenty of PR testing prior to v2.11
I removed all this to have a single bit depth on the link side. This configuration of 16 bits in 16 bit words makes no sense for SoundWire, the FIFOs only work for 32 bits. The only variable is the word length i.e. the number of bits pushed on the bus. |
@kv2019i @lgirdwood this PR is not urgent, it should only be merged after re-testing all the SoundWire devices we have in the daily tests. |
@ssavati @fredoh9 can someone help here with soundwire testing using this PR ? |
Sure @lgirdwood I will run more test on SDW |
@lgirdwood I have completed soundwire functional and stress tests for MTL and LNL . no new regression observed. |
Thanks @ssavati, all good to merge then. |
Using S32_LE wastes bandwdith for no good reason, we should use 24 bits on the link to maximize bus efficiency with the 9.6 MHz bus clock.
FIXME: it's likely we need a kernel-side change as well to configure the hw_params to S24_LE, currently the stream/port is configured withsconfig.bps = snd_pcm_format_width(params_format(params));Link: #8960