[PATCH 08/17] ASoC: Intel: avs: Add power management requests
Cezary Rojewski
cezary.rojewski at intel.com
Mon Feb 28 16:28:07 CET 2022
On 2022-02-25 9:46 PM, Pierre-Louis Bossart wrote:
>
>>
>>>> + msg.ext.set_d0ix.wake = enable_pg;
>>>
>>> simplify the argument? Not sure anyone could understand what wake and
>>> enable_pg mean.
>>
>>
>> Well, CG and PG are popular shortcuts among Intel audio team and stand
>> for clock gating and power gating respectively. 'wake' is firmware
>> specific. I can provide a comment, but not all question are going to be
>> answered by it. Firmware specification is the place to find the answer
>> for most of these.
>
> again please do not assume that anyone reviewing this code has access to
> the firmware specification.
Provided simple description for the SET_D0IX message.
>>
>>> int avs_ipc_set_d0ix(struct avs_dev *adev, bool wake, bool streaming)
>>>
>>>> + msg.ext.set_d0ix.streaming = streaming;
>>>> +
>>>> + request.header = msg.val;
>>>> +
>>>> + ret = avs_dsp_send_pm_msg(adev, &request, NULL, false);
>>>> + if (ret)
>>>> + avs_ipc_err(adev, &request, "set d0ix", ret);
>>>> +
>>>> + return ret;
>>>> +}
>>>> diff --git a/sound/soc/intel/avs/messages.h
>>>> b/sound/soc/intel/avs/messages.h
>>>> index 1dabd1005327..bbdba4631b1f 100644
>>>> --- a/sound/soc/intel/avs/messages.h
>>>> +++ b/sound/soc/intel/avs/messages.h
>>>> @@ -101,6 +101,8 @@ enum avs_module_msg_type {
>>>> AVS_MOD_LARGE_CONFIG_SET = 4,
>>>> AVS_MOD_BIND = 5,
>>>> AVS_MOD_UNBIND = 6,
>>>> + AVS_MOD_SET_DX = 7,
>>>> + AVS_MOD_SET_D0IX = 8,
>>>> AVS_MOD_DELETE_INSTANCE = 11,
>>>> };
>>>> @@ -137,6 +139,11 @@ union avs_module_msg {
>>>> u32 dst_queue:3;
>>>> u32 src_queue:3;
>>>> } bind_unbind;
>>>> + struct {
>>>> + /* cAVS < 2.0 */
>>>> + u32 wake:1;
>>>> + u32 streaming:1;
>>>
>>> you probably want to explain how a 'streaming' flag is set at the module
>>> level? One would think all modules connected in a pipeline would need to
>>> use the same flag value.
>>
>>
>> Some of the fields are confusing and I agree, but driver has to adhere
>> to FW expectations if it wants to be a working one. I would like to
>> avoid judging the firmware architecture here, regardless of how
>> confusing we think it is.
>
> it's not about judging, just explaining what is expected on the firmware
> side and what the driver needs to do.
Dropped all the "cavs < 2.0" unclear comments.
>>
>> 'wake' and 'streaming' fields are part of SET_D0ix message is which part
>> of MODULE-type message interface. Base firmware is, from architecture
>> point of view, a module of type=0 (module_id) and instance id=0
>> (instance_id).
>>
>>>> + } set_d0ix;
>>>> } ext;
>>>> };
>>>> } __packed;
>>>> @@ -298,4 +305,13 @@ int avs_ipc_get_large_config(struct avs_dev
>>>> *adev, u16 module_id, u8 instance_id
>>>> u8 param_id, u8 *request_data, size_t request_size,
>>>> u8 **reply_data, size_t *reply_size);
>>>> +/* DSP cores and domains power management messages */
>>>> +struct avs_dxstate_info {
>>>> + u32 core_mask;
>>>> + u32 dx_mask;
>>>
>>> what is the convention for D0 and D3 in the mask ? which one is 0 or 1?
>>>
>>> Is this also handled in a hierarchical way where only the bits set in
>>> core_mask matter?
>>
>>
>> Can provide a short kernel-doc for these two, sure.
Provided a short comments instead.
More information about the Alsa-devel
mailing list