ASoC: SOF: Intel: Add support for hardware mic privacy change reporting #5312

ujfalusi · 2025-01-29T12:33:05Z

Hi,

ACE3 (Panther Lake) introduced support for microphone privacy feature which
can - in hardware - mute incoming audio data based on a state of a physical
switch.
The change in the privacy state is delivered through interface IP blocks
and can only be handled by the link owner.
In Intel platforms Soundwire is for example host owned, so the interrupt
can only be handled by the host.

Since the input stream is going to be muted by hardware, the host needs to
send a message to firmware about the change in privacy so it can execute a
fade out/in to enhance user experience.

The support for microphone privacy can be queried from the HW_CONFIG data
under the INTEL_MIC_PRIVACY_CAP tuple. This is Intel specific data, the
core will pass it to platform code if the intel_configure_mic_privacy()
callback is provided.

Platform code can call sof_ipc4_mic_privacy_state_change() to send the IPC
message to the firmware on state change.

This series will change how we set up dsp_ops for ACE versions to make it cleaner what needs to be handled differently in each iteration of the architecture and adds the needed definitions and code to handle the mic privacy via vendor specific SHIM register.

bardliao · 2025-02-03T13:19:05Z

include/sound/hda-mlink.h

+void hdac_bus_eml_set_mic_privacy_mask(struct hdac_bus *bus, bool alt, int elid,
+				       unsigned long mask);
+bool hdac_bus_eml_check_mic_privacy(struct hdac_bus *bus, bool alt, int elid);
+bool hdac_bus_eml_get_mic_privacy(struct hdac_bus *bus, bool alt, int elid);


What is the difference between check and get?

Ok, I got it after reading all the commits. Check if it is a mic privacy irq and get the mic privacy status.

Had to go all the way the register spec to get that, but then I did understand that too. A short comment somewhere would not hurt thou.

OK, let me do some renaming and commenting.

bardliao · 2025-02-03T13:28:16Z

sound/soc/sof/intel/ptl.c

+
+	hdac_bus_eml_set_mic_privacy_mask(sof_to_bus(sdev), true,
+					  AZX_REG_ML_LEPTR_ID_SDW,
+					  PTL_MICPVCP_GET_SDW_MASK(micpvcp));


Should we only call hdac_bus_eml_set_mic_privacy_mask when the mic privacy is changed?

hdac_bus_eml_set_mic_privacy_mask() can ignore unchanged mask if needed, but this function should be only called once when the stack is booted up and we have found the mic privacy support in hw config from the firmware.

jsarha

Only couple of not so important suggestions. LGTM.

jsarha · 2025-02-06T09:42:53Z

sound/soc/sof/intel/lnl.c

 {
 	struct hdac_bus *bus = sof_to_bus(sdev);

 	return hdac_bus_eml_check_interrupt(bus, true,  AZX_REG_ML_LEPTR_ID_SDW);
 }
+EXPORT_SYMBOL_NS(lnl_dsp_check_sdw_irq, "SND_SOC_SOF_INTEL_LNL");


Would it be worth mentioning in the commit message that it also unexports the few lnl specific ops and turns them into static?

It only changes the lnl functions that are needed for ptl from static to be exported, which is a must to create the separate ptl.c

jsarha · 2025-02-06T17:15:00Z

include/sound/hda-mlink.h

+void hdac_bus_eml_set_mic_privacy_mask(struct hdac_bus *bus, bool alt, int elid,
+				       unsigned long mask);
+bool hdac_bus_eml_check_mic_privacy(struct hdac_bus *bus, bool alt, int elid);
+bool hdac_bus_eml_get_mic_privacy(struct hdac_bus *bus, bool alt, int elid);


Had to go all the way the register spec to get that, but then I did understand that too. A short comment somewhere would not hurt thou.

Move the sof_mtl_ops and sof_mtl_ops_init() to pci-mtl.c as local static and add a 'generic' sof_mtl_set_ops() function as replacement exported function to fill the dsp_ops structure. Signed-off-by: Peter Ujfalusi <[email protected]>

LunarLake is a next generation in ACE architecture and most of the dsp_ops are the same as it is in previous generation. Use the sof_mtl_set_ops() to get the ops used for mtl and update the ones that needs different functions for LNL. Update pci-ptl at the same time to use the LNL dsp_ops as before. Signed-off-by: Peter Ujfalusi <[email protected]>

There is no need to export individual dsp_ops functions anymore as the callbacks are filled now by sof_mtl_set_ops() Signed-off-by: Peter Ujfalusi <[email protected]>

Create a minimal placeholder to make it possible to add code to handle the new features of Panther Lake compared to MTL/LNL. Signed-off-by: Peter Ujfalusi <[email protected]>

ACE3 (Panther Lake) introduced support for microphone privacy feature which can - in hardware - mute incoming audio data based on a state of a physical switch. The change in the privacy state is delivered through interface IP blocks and can only be handled by the link owner. In Intel platforms Soundwire is for example host owned, so the interrupt can only be handled by the host. Since the input stream is going to be muted by hardware, the host needs to send a message to firmware about the change in privacy so it can execute a fade out/in to enhance user experience. The support for microphone privacy can be queried from the HW_CONFIG data under the INTEL_MIC_PRIVACY_CAP tuple. This is Intel specific data, the core will pass it to platform code if the intel_configure_mic_privacy() callback is provided. Platform code can call sof_ipc4_mic_privacy_state_change() to send the IPC message to the firmware on state change. Signed-off-by: Peter Ujfalusi <[email protected]>

…egisters New register has been introduced with PTL in the vendor specific SHIM registers, outside of the IP itself to control the mic privacy change handling. Via the PVCCS registers it is possible to enable/disable the interrupt generation to the owner of the interface (DSP/host), check the mic privacy status. The PVCCS is provided for each sublink under the IP to make it possible to control the interrupt per sublink bases. The added functions are generic to be future proof if the mic privacy support is extended beyond Soundwire and DMIC links. The interrupt is routed to the IP's interrupt and it needs to be cleared in all links to be able to detect further changes. Signed-off-by: Peter Ujfalusi <[email protected]>

Add generic callback definitions for checking the mic privacy interrupt and status. Implement wrappers for mic privacy reported via the Soundwire interrupt and it's vendor specific SHIM registers. Signed-off-by: Peter Ujfalusi <[email protected]>

Implement the three callbacks that is needed to enable support for reporting the mic privacy change via soundwire. In PTL the mic privacy reporting is supported via soundwire and DMIC and the soundwire is owned by the host, it's interrupt is routed there. To enable the interrupt, the sublink mask needs to be passed to the multilink layer, the check_mic_privacy_irq/process_mic_privacy callbacks needs to be implemented to check and report the mic privacy change. Signed-off-by: Peter Ujfalusi <[email protected]>

ujfalusi · 2025-02-07T09:24:02Z

Changes since v1:

rename hdac_bus_eml_check_mic_privacy() to hdac_bus_eml_is_mic_privacy_changed()
rename hdac_bus_eml_get_mic_privacy() to hdac_bus_eml_get_mic_privacy_state()

kv2019i

On question inline, but no blockers.

kv2019i · 2025-02-07T10:40:33Z

sound/soc/sof/intel/ptl.c

+
+	/* No need to set the mic privacy if it is not enabled or forced */
+	if (!(micpvcp & PTL_MICPVCP_DDZE_ENABLED) ||
+	    micpvcp & PTL_MICPVCP_DDZE_FORCED)


So this is just the mask? I guess even in forced state, it is preferably to have FW manage the ramp in/out...?

The firmware will pass the raw value of the MICPVCP register (don't ask). This is configured by a secure entity (BIOS) in case of HW managed mode and contains the link mask of SDW and DMIC that the hardware will mute.
The firmware will only do fade for these links.
If the hardware mute is forced then it is unconditionally muted -> the position of the switch does not matter, always muted.

In FW managed case the mask is not defined and on top, the host does not need to handle interrupts for this as everything is managed in FW (except that the host could send an IPC message to change the mask, to exclude some links since it is expected that all incoming links are FW muted on privacy ON case by default).

So yes, we only enable the interrupt if the policy is HW managed and it is not forced to always mute.

I know...

ujfalusi · 2025-02-07T11:34:07Z

SOFCI TEST

plbossart · 2025-02-11T19:10:17Z

include/sound/sof/ipc4/header.h

@@ -396,6 +396,7 @@ enum sof_ipc4_base_fw_params {
 	SOF_IPC4_FW_PARAM_MODULES_INFO_GET,
 	SOF_IPC4_FW_PARAM_LIBRARIES_INFO_GET = 16,
 	SOF_IPC4_FW_PARAM_SYSTEM_TIME = 20,
+	SOF_IPC4_FW_PARAM_MIC_PRIVACY_STATE_CHANGE = 35,


This is very controversial.
In the case of DMICs, the mute can be completely handled by firmware since it also processes the GPIO that toggles the privacy.
In the case of SoundWire, the mute is expected to be handled in the external codec.

In other words, this IPC does not seem to have a purpose other than academic - and it's mind-blowing that such a split implementation for a 'secure' solution relies on an IPC from the host. Recompile your kernel and the privacy is crippled... That does not sound good, does it.

plbossart · 2025-02-11T19:13:01Z

include/sound/hda-mlink.h

+				       unsigned long mask);
+bool hdac_bus_eml_is_mic_privacy_changed(struct hdac_bus *bus, bool alt, int elid);
+bool hdac_bus_eml_get_mic_privacy_state(struct hdac_bus *bus, bool alt, int elid);
+


I think the commit message should be clearer that the information is from hardware to host only. This is different to the previous patch in the sense that the host can select to receive information on the privacy changes, but it is not involved in the privacy flows.

ujfalusi requested review from jsarha, abonislawski and mbukowsk January 29, 2025 12:33

ujfalusi requested review from bardliao, lgirdwood, plbossart, ranj063, kv2019i and dbaluta as code owners January 29, 2025 12:33

bardliao reviewed Feb 3, 2025

View reviewed changes

jsarha approved these changes Feb 6, 2025

View reviewed changes

ujfalusi changed the title ~~ASoC: SOF: Intel: Add support for hardware mic privacy change reproting~~ ASoC: SOF: Intel: Add support for hardware mic privacy change reporting Feb 7, 2025

ujfalusi force-pushed the peter/sof/pr/ptl_sdw_mic_privacy_handling_01 branch from 3ff7eef to 85814f7 Compare February 7, 2025 09:22

ujfalusi requested a review from lyakh as a code owner February 7, 2025 09:22

ujfalusi added 8 commits February 7, 2025 11:23

ASoC: SOF: Intel: mtl: Split up dsp_ops setup code

33d35c3

Move the sof_mtl_ops and sof_mtl_ops_init() to pci-mtl.c as local static and add a 'generic' sof_mtl_set_ops() function as replacement exported function to fill the dsp_ops structure. Signed-off-by: Peter Ujfalusi <[email protected]>

ASoC: SOF: Intel: mtl: Stop exporting dsp_ops callback functions

3321dc0

There is no need to export individual dsp_ops functions anymore as the callbacks are filled now by sof_mtl_set_ops() Signed-off-by: Peter Ujfalusi <[email protected]>

ASoC: SOF: Intel: Create ptl.c as placeholder for Panther Lake features

c33ab5b

Create a minimal placeholder to make it possible to add code to handle the new features of Panther Lake compared to MTL/LNL. Signed-off-by: Peter Ujfalusi <[email protected]>

kv2019i approved these changes Feb 7, 2025

View reviewed changes

bardliao approved these changes Feb 7, 2025

View reviewed changes

plbossart reviewed Feb 11, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ASoC: SOF: Intel: Add support for hardware mic privacy change reporting #5312

ASoC: SOF: Intel: Add support for hardware mic privacy change reporting #5312

ujfalusi commented Jan 29, 2025

bardliao Feb 3, 2025

bardliao Feb 3, 2025

jsarha Feb 6, 2025

ujfalusi Feb 7, 2025

bardliao Feb 3, 2025

ujfalusi Feb 3, 2025

jsarha left a comment

jsarha Feb 6, 2025

ujfalusi Feb 7, 2025

jsarha Feb 6, 2025

ujfalusi commented Feb 7, 2025

kv2019i left a comment

kv2019i Feb 7, 2025

ujfalusi Feb 7, 2025

ujfalusi commented Feb 7, 2025

plbossart Feb 11, 2025

plbossart Feb 11, 2025

ASoC: SOF: Intel: Add support for hardware mic privacy change reporting #5312

Are you sure you want to change the base?

ASoC: SOF: Intel: Add support for hardware mic privacy change reporting #5312

Conversation

ujfalusi commented Jan 29, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jsarha left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ujfalusi commented Feb 7, 2025

kv2019i left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ujfalusi commented Feb 7, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment