-
Notifications
You must be signed in to change notification settings - Fork 349
Add device posture feature #9238
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
|
can I ask what this has to do with 'posture' in its traditional sense of extended landscape/portrait configuration? |
The PR adds support to IPC4_COPIER_MODULE_CFG_PARAM_CHANNEL_MAP IPC request. When user rotates tablet-like device by 180 degree, driver sends this IPC to gateway(s) with new channel map to switch left and right channels on speakers and microphones. |
|
Right, but this capability is usually handled in external devices - for SDCA long term I don't see anyone requesting posture changes at the Intel firmware level. |
6ca8668 to
e49c47d
Compare
e49c47d to
b5c58f1
Compare
8822849 to
ce1fdf2
Compare
de671d3 to
4c8036f
Compare
| uint32_t ooffset, uint32_t source_samples, uint32_t chmap); | ||
|
|
||
| /* A channel map that does not perform any remapping. */ | ||
| #define DUMMY_CHMAP 0x76543210 |
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.
should this be the "identity mapping" maybe?
|
|
||
| /* Unfortunately, all these nice "if"s were commented out to suppress | ||
| * CI "defined but not used" warnings. | ||
| */ |
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.
cannot you put those functions under the same #ifs too?
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.
That is not that easy. For example, for remap_c16_to_c32() it would be:
#if CONFIG_PCM_CONVERTER_FORMAT_S16LE && (CONFIG_PCM_CONVERTER_FORMAT_S32LE || CONFIG_PCM_CONVERTER_FORMAT_S24_4LE || CONFIG_PCM_CONVERTER_FORMAT_S24_4LE_MSB || CONFIG_PCM_CONVERTER_FORMAT_S16_4LE)
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.
yeah, well, it's nothing critical - just thinking out loud. You could define some intermediate flags like
#define X_IS_NEEDED (CONFIG_X1 || CONFIG_X2...)
but doesn't seem too important to me, up to you basically
| out_fmt->channels_count = dma_buf_channels; | ||
|
|
||
| if (!(dma_buf_container_bits == out_fmt->depth && | ||
| out_fmt->depth != out_fmt->valid_bit_depth)) { |
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.
is this because out_fmt->valid_bit_depth hasn't been set up yet or is it because it must be changed? So what we previously thought was a valid bit depth, now it's a different one? Something is a bit strange here. Your if is the same as
if (dma_buf_container_bits != out_fmt->depth || out_fmt->depth == out_fmt->valid_bit_depth)
So we can enter this branch also if dma_buf_container_bits == out_fmt->depth and then you set out_fmt->depth = dma_buf_container_bits again... Could you double-check this?
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 setup of DMA buffer format and conversoin func is somewhat confusing. I wrote a big comment above this code trying to explain. The second part of the comment is about this weird logic.
DMA buffer format is set in dai-zephyr from dev->ipc_config.frame_fmt, which comes from topology. That is enum sof_ipc_frame type like SOF_IPC_FRAME_S16_LE, SOF_IPC_FRAME_S32_LE, etc. There is no way to use this value to setup DMA buffer, for example, for 16-bit valid in 32-bit container -- no such enum value. Such format is used in our CI for SSP gateway.
So before my PR we had this code to fix the problem (see line 466 in copier_dai.c in version before my PR):
/*
* dai_zephyr_params assigns the conversion function
* based on the input/output formats but does not take
* the valid bits into account. So change the conversion
* function if the valid bits are different from the
* container size.
*/
audio_stream_fmt_conversion(in_fmt->depth,
in_fmt->valid_bit_depth,
&in_bits, &in_valid_bits,
in_fmt->s_type);
audio_stream_fmt_conversion(out_fmt->depth,
out_fmt->valid_bit_depth,
&out_bits, &out_valid_bits,
out_fmt->s_type);
if (in_bits != in_valid_bits || out_bits != out_valid_bits)
cd->dd[0]->process =
cd->converter[IPC4_COPIER_GATEWAY_PIN];
The code overwrites cd->dd[0]->process previously set in dai-zephyr based on dev->ipc_config.frame_fmt and other pin format with new value based on coper input and output formats in case of if (in_bits != in_valid_bits || out_bits != out_valid_bits).
That condition looks strange to me but we lived with it for quite a sometime.
The condition in my PR (also looking very confusing) works like this:
- if dma_buf_container_bits != in_fmt->depth, then in_fmt values cannot be trusted and are ignored (format from topology takes precedence over copier's input/output formats).
- if dma_buf_container_bits == in_fmt->depth, we still prefer value from topology except for in_fmt->depth != in_fmt->valid_bit_depth. This is to handle that 16-bit valid in 32-bit container SSP case. Topology cannot specify such format, so we have to rely on copier's input/output format in this case.
Of course, it would be much simpler if we just always use copier's input/output formats -- they contain all the required info. However, on our CI we have test that actually sends different container sizes for topology format and copier input/output format. So that weird logic is required.
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.
if dma_buf_container_bits != in_fmt->depth, then in_fmt values cannot be trusted and are ignored (format from topology takes precedence over copier's input/output formats).
if dma_buf_container_bits == in_fmt->depth, we still prefer value from topology except for in_fmt->depth != in_fmt->valid_bit_depth. This is to handle that 16-bit valid in 32-bit container SSP case. Topology cannot specify such format, so we have to rely on copier's input/output format in this case.
Right, this logic fits well the format:
if (dma_buf_container_bits != in_fmt->depth || in_fmt->depth == in_fmt->valid_bit_depth)
which is equivalent to yours, but has 1 operation fewer and is therefore easier to read IMHO.
4c8036f to
4aefb69
Compare
lgirdwood
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.
Looks good after Makefile open addressed.
4aefb69 to
767337f
Compare
…copy The multi-gateway channel copy function and the DAI process function serve distinct purposes. Although they currently share the same number of arguments of the same type, this similarity is coincidental and might be changed during future refactoring. Signed-off-by: Serhiy Katsyuba <serhiy.katsyuba@intel.com>
Copier may have multiple sinks connected to different pipelines. While the copier pipeline might already be running, the sink pipeline has not yet initialized stream parameters of the buffer connected to copier's sink. It appears that checking for the sink component state is not enough. Signed-off-by: Serhiy Katsyuba <serhiy.katsyuba@intel.com>
Prepare DAI gateway to support channel remapping conversion functions that can modify number of channels. Consequently, frames, not samples, should be used for DMA copy bytes calculation. Signed-off-by: Serhiy Katsyuba <serhiy.katsyuba@intel.com>
Adds a channel map parameter to conversion functions, allowing for the introduction of conversions that can handle both format conversion and channel remapping. Signed-off-by: Serhiy Katsyuba <serhiy.katsyuba@intel.com>
Adds a set of conversion functions that perform both format conversion and channel remapping. These are required to swap channels for the device posture feature. Signed-off-by: Serhiy Katsyuba <serhiy.katsyuba@intel.com>
When the hardware is able to return a valid number of DMA buffer audio channels (e.g., extracted from a blob), give the returned number of channels higher precedence over the number supplied via the base config params. Signed-off-by: Serhiy Katsyuba <serhiy.katsyuba@intel.com>
Adds channel map parameter to get_convertion_func() to support remapping conversion functions. Signed-off-by: Serhiy Katsyuba <serhiy.katsyuba@intel.com>
Adds IPC4_COPIER_MODULE_CFG_PARAM_CHANNEL_MAP handler that applies channel map to DAI gateway audio conversion function. Signed-off-by: Serhiy Katsyuba <serhiy.katsyuba@intel.com>
767337f to
cecd8a6
Compare
|
Rebased to fix merge conflict. |
Adds a device posture feature. The driver sends IPC4_COPIER_MODULE_CFG_PARAM_CHANNEL_MAP with a channel map to be used for swapping channels according to the device orientation.
IPC4_COPIER_MODULE_CFG_PARAM_CHANNEL_MAP is applied only for the DAI gateway.