ASoC: SOF: Intel: ptl: Move the mic privacy change IPC sending to a work#5371
Conversation
ujfalusi
requested review from
bardliao,
dbaluta,
kv2019i,
lgirdwood,
lyakh,
plbossart and
ranj063
as code owners
ujfalusi
changed the title
| if (nhlt) | ||
| intel_nhlt_free(nhlt); | ||
|
|
||
| if (!sdev->dspless_mode_selected) |
There was a problem hiding this comment.
typo in the commit message : to the firmware
ujfalusi
force-pushed
the
peter/sof/pr/ptl_sdw_mic_privacy_handling_04
branch
from
53203bf to
2fa25aa
Compare
|
Changes since v1:
|
|
|
||
| /* Cancel the microphone privacy work if it is active */ | ||
| if (hda->mic_privacy.active) | ||
| cancel_work_sync(&hda->mic_privacy.work); |
There was a problem hiding this comment.
as long as the container structure is 0-initialised (e.g. allocated per kcalloc() or similar) this won't represent a bisection breakage, because the if above won't be entered, but still it's a strange split of commits - cancel work here that's initialised and submitted in the next commit... I'm just merge the two.
There was a problem hiding this comment.
as long as the container structure is 0-initialised (e.g. allocated per
kcalloc()or similar) this won't represent a bisection breakage, because theifabove won't be entered
Yep, this is the idea. This will not affect pre PTL platforms and PTL+ where the work is not initialized (w/o the next patch or if the mic privacy is applicable)
but still it's a strange split of commits - cancel work here that's initialised and submitted in the next commit... I'm just merge the two.
I tend to prefer separate patch for the generic 'infra' and to the platform implementing the feature, but I see your point. Let me debate this a bit, or if @ranj063, @bardliao and @kv2019i prefers a single patch than I will merge them.
There was a problem hiding this comment.
I vote for separated patch
There was a problem hiding this comment.
I think a single patch is preferable but not a deal-breaker for me
ujfalusi
force-pushed
the
peter/sof/pr/ptl_sdw_mic_privacy_handling_04
branch
from
2fa25aa to
c3c09ea
Compare
|
Changes since v2:
|
ujfalusi
force-pushed
the
peter/sof/pr/ptl_sdw_mic_privacy_handling_04
branch
from
c3c09ea to
7639831
Compare
… work IPC message cannot be sent from the irq thread directly as the message will not receive the reply (interrupts are disabled) and it will time out - the reply is going to be received right after the we leave the irq thread. This is a different case compared to the delayed IPC messages due to DSP busy state. Add support for sending the mic privacy change notification to the firmware from a work instead of the process callback. The work needs to be canceled if there is a chance that it might be running on module remove or before system/runtime suspend. Fixes: 4a43c32 ("ASoC: SOF: Intel: ptl: Add support for mic privacy") Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
|
Changes since v3:
|
lgirdwood
left a comment
lgirdwood
left a comment
There was a problem hiding this comment.
Is this a "fix" patch i.e. do we need it back ported to certain kernels ?
The feature is heading for 6.15, I will need to send this patch asap to the current cycle. |
6 participants
IPCs cannot be sent directly form the irq thread as we would net get the reply (interrupt is disabled).
Introduce a new struct to handle to delayed notification handling.