audio: dai-zephyr: migrate to use dai_get_properties_copy()#10991
audio: dai-zephyr: migrate to use dai_get_properties_copy()#10991kv2019i wants to merge 1 commit into
Conversation
There was a problem hiding this comment.
Pull request overview
This PR updates the Zephyr-native DAI implementation to support user-space LL execution by avoiding direct use of driver-owned dai_properties pointers and preferring dai_get_properties_copy() to copy properties into a caller-provided buffer.
Changes:
- Introduces a shared helper (
do_dai_get_properties()) that callsdai_get_properties_copy()and conditionally falls back todai_get_properties()for kernel-LL builds. - Migrates several property consumers (
dai_get_handshake(),dai_get_fifo_depth(),dai_get_stream_id(), FIFO address helper, anddai_get_init_delay_ms()) to use stack-allocatedstruct dai_propertiespopulated via the helper.
| props_p = dai_get_properties(dai->dev, direction, stream_id); | ||
| if (props_p) | ||
| *props = *props_p; | ||
| else | ||
| ret = -ENOENT; |
There was a problem hiding this comment.
Oops, fixed in V2.
|
For context, related to #10558 |
Modify code to allocate DAI properties object on stack and use dai_get_properties_copy() whenever available. Add a static helper function to share the implementation. This change is required to enable DAI code to run in user-space. In this scenario, it's not possible to directly use an object returned by driver, but instead data needs to be copied to user-space. As a side benefit, the need to use locking to protect the properties data is limited the fallback case when a driver does not implement the get_properties_copy() method and SOF is built with LL code running in kernel space. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
5c60f79 to
c7ff67f
Compare
|
V2 pushed:
|
| return dai_config_set(dev, &cfg, cfg_params, dai_cfg_size); | ||
| } | ||
|
|
||
| static int do_dai_get_properties(struct dai *dai, int direction, |
There was a problem hiding this comment.
naming is hard ;-) I'd at least keep dai_ as the prefix as a lesser evil dai_do_get_properties() perhaps. Cannot come up with better names either :-) Maybe dai_get_properties_safe()? As discussed elsewhere, I think it would be good to update Zephyr .get_properties_copy() implementations to use a common function, but that would be a Zephyr PR.
Modify code to allocate DAI properties object on stack and use dai_get_properties_copy() whenever available. Add a static helper function to share the implementation.
This change is required to enable DAI code to run in user-space. In this scenario, it's not possible to directly use an object returned by driver, but instead data needs to be copied to user-space.
As a side benefit, the need to use locking to protect the properties data is limited the fallback case when a driver does not implement the get_properties_copy() method and SOF is built with LL code running in kernel space.