ASoC: SOF: fix return values for mandatory ops by ranj063 · Pull Request #539 · thesofproject/linux

ranj063 · 2019-01-14T20:28:48Z

Fix return value for mandatory ops.

Signed-off-by: Ranjani Sridharan ranjani.sridharan@linux.intel.com

ranj063 · 2019-01-14T20:29:41Z

@plbossart this leaves only the PCM ops but I'm not sure whether they are mandotory or not. Could you please comment?

plbossart

this looks ok but I'd like error messages to reflect the name of the function with the _ included. That helps for searches.
Also it'd be good to tag the callbacks in the header file as mandatory/optional so that the information is in one place.

ranj063 · 2019-01-16T03:17:27Z

@plbossart fixed now. Could you please cross-check if the list of mandatory and optional ops is correct?

plbossart

@lgirdwood @keyonjie can you look at the list of mandatory ops and comment? I am afraid we have no documentation of what is expected in a minimal case?

plbossart · 2019-01-16T20:06:03Z

it's not very easy to figure out where the list stops. maybe for each op so that is can be searched whether it's optional or mandatory?

keyonjie

we don't have .remove yet for skl- platforms(please fix that).
stall, core_power_up/down should be optional.
write, read, write64, read64, block_read, block_write are same for all our platforms so let's remove them from struct snd_sof_dsp_ops.

Others looks fine.

keyonjie · 2019-01-17T04:59:04Z

I agree we should make .remove mandatory, but the fact is that we don't have it on skl- platforms yet, better to fix them together at one shot(e.g. define an empty one at least).

why should .remove be mandatory? if all your driver uses devm_ stuff and the hardware is reset correctly in the .probe, why would we care?

@plbossart going by what remove() does for SKL+, we also disable the DSP in remove(). Given that we are not really unloading the topology from the DSP like we do in the case of load, shouldnt we also be turning off the DSP here?

@plbossart i believe for module load/unload to work in SOF, we should make remove() mandatory so that the DSP can be turned OFF here. Please let me know if you disagree and I'll make changes accordingly.

ranj063 · 2019-01-17T06:33:28Z

we don't have .remove yet for skl- platforms(please fix that).
stall, core_power_up/down should be optional.

@keyonjie With SMP enabled in the driver, they are no long optional.

write, read, write64, read64, block_read, block_write are same for all our platforms so let's remove them from struct snd_sof_dsp_ops.
Others looks fine.

keyonjie · 2019-01-17T06:44:10Z

we don't have .remove yet for skl- platforms(please fix that).
stall, core_power_up/down should be optional.
@keyonjie With SMP enabled in the driver, they are no long optional.

for SKL- platforms, we don't have SMP there, I meant those callbacks are not mandatory for snd_sof_dsp_ops (e.g. no need for byt), but they are mandatory for apl/cnl?

write, read, write64, read64, block_read, block_write are same for all our platforms so let's remove them from struct snd_sof_dsp_ops.
Others looks fine.

ranj063 · 2019-01-17T06:52:35Z

we don't have .remove yet for skl- platforms(please fix that).
stall, core_power_up/down should be optional.
@keyonjie With SMP enabled in the driver, they are no long optional.
for SKL- platforms, we don't have SMP there, I meant those callbacks are not mandatory for snd_sof_dsp_ops (e.g. no need for byt), but they are mandatory for apl/cnl?
write, read, write64, read64, block_read, block_write are same for all our platforms so let's remove them from struct snd_sof_dsp_ops.
Others looks fine.

@keyonjie ok Makes sense

ranj063 · 2019-01-17T06:57:21Z

we don't have .remove yet for skl- platforms(please fix that).
stall, core_power_up/down should be optional.
write, read, write64, read64, block_read, block_write are same for all our platforms so let's remove them from struct snd_sof_dsp_ops.

@keyonjie hsw-spi.c has a different set of ops!

Others looks fine.

ranj063 · 2019-01-17T07:32:38Z

@keyonjie @plbossart PR updated now.

plbossart · 2019-01-17T17:03:12Z

@ranj063 can you rebase, there is conflict. Also please mark each function as mandatory/optional, you are mixing the two styles (per function and per block) which will make searches more complicated.
Thanks!

ranj063 · 2019-01-22T19:54:28Z

@plbossart this one has been updated too. There are 2 lines over 80 chars which checkpatch complains about but I think there's no simple way to address it while keeping the style consistent for marking the ops are madatory/optional.

plbossart

Humm, I am not sure I agree with the mandatory support for PCM (SueCreek being the counter example) and there are some inconsistencies between the errors and tags. Maybe we should shoot for a lower bar of what is really mandatory?

plbossart · 2019-01-24T02:42:51Z

Are PCM operations actually required? Take the example of Sue Creek, you may have all the processing done on the device itself with no PCM being passed back to the host?

@plbossart ok i will make these optional

plbossart · 2019-01-24T02:44:41Z

this is inconsistent with the fact that those functions return 0 if not supported?

ranj063 · 2019-01-26T01:25:30Z

@plbossart i've updated the PR based on your comments.

wenqingfu · 2019-01-29T03:51:00Z

ping @plbossart

plbossart · 2019-01-29T04:30:36Z

ping @plbossart <https://github.com/plbossart>

Ranjani and I are working on PM stuff, this can wait.

…

ranj063 · 2019-02-05T02:16:02Z

@plbossart I've updated this PR now to address your comment about the is_ready() op. There will be conflicts between this one and my other PR where I have changed the name for this op. I will update them depending on which one gets merged first.

ranj063 · 2019-02-05T04:02:34Z

@plbossart please dont merge this. with the return value of undefined values change to < 0, I need to ensure the check is done correctly.

ranj063 · 2019-02-06T02:56:01Z

@plbossart this one has been updated now.

plbossart

Sorry, this still needs more work, some of the mandatory parts are not used so something's wrong.

plbossart · 2019-02-06T14:47:12Z

sorry, what does this do?
The is_ready op is marked a mandatory
int (*is_ready)(struct snd_sof_dev sof_dev); / mandatory */
The comment seems wrong?

plbossart · 2019-02-06T14:51:03Z

meh, this is not defined for HDAudio.

plbossart · 2019-02-06T14:54:17Z

meh. not defined for HDaudio.

@plbossart all 3 comments addressed and PR updated now.

plbossart

minor nit-pick on dev_err when we return void, looks ok otherwise

plbossart · 2019-02-07T19:04:33Z

Ah sorry, I just thought about this one. Since this will not interrupt the flow, we may want to add a _once or _ratelimited qualifier to avoid polluting dmesg. Same remark for all cases where we return void.

@plbossart done

Clarify the mandatory and optional dsp ops and fix return value for mandatory ops. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>

plbossart

Thanks, merging now.

As arm64 JIT now supports timed may_goto instruction, make sure all relevant tests run on this architecture. Some tests were enabled and other required modifications to work properly on arm64. $ ./test_progs -a "stream*","*may_goto*",verifier_bpf_fastcall thesofproject#404 stream_errors:OK [...] thesofproject#406/2 stream_success/stream_cond_break:OK [...] thesofproject#494/23 verifier_bpf_fastcall/may_goto_interaction_x86_64:SKIP thesofproject#494/24 verifier_bpf_fastcall/may_goto_interaction_arm64:OK [...] thesofproject#539/1 verifier_may_goto_1/may_goto 0:OK thesofproject#539/2 verifier_may_goto_1/batch 2 of may_goto 0:OK thesofproject#539/3 verifier_may_goto_1/may_goto batch with offsets 2/1/0:OK thesofproject#539/4 verifier_may_goto_1/may_goto batch with offsets 2/0:OK thesofproject#539 verifier_may_goto_1:OK thesofproject#540/1 verifier_may_goto_2/C code with may_goto 0:OK thesofproject#540 verifier_may_goto_2:OK Summary: 7/16 PASSED, 25 SKIPPED, 0 FAILED Signed-off-by: Puranjay Mohan <puranjay@kernel.org> Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Acked-by: Xu Kuohai <xukuohai@huawei.com> Link: https://lore.kernel.org/r/20250827113245.52629-3-puranjay@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>

Puranjay Mohan says: ==================== bpf, arm64: support for timed may_goto Changes in v2->v3: v2: https://lore.kernel.org/all/20250809204833.44803-1-puranjay@kernel.org/ - Rebased on bpf-next/master - Added Acked-by: tags from Xu and Kumar Changes in v1->v2: v1: https://lore.kernel.org/bpf/20250724125443.26182-1-puranjay@kernel.org/ - Added comment in arch_bpf_timed_may_goto() about BPF_REG_FP setup (Xu Kuohai) This set adds support for the timed may_goto instruction for the arm64. The timed may_goto instruction is implemented by the verifier by reserving 2 8byte slots in the program stack and then calling arch_bpf_timed_may_goto() in a loop with the stack offset of these two slots in BPF_REG_AX. It expects the function to put a timestamp in the first slot and the returned count in BPF_REG_AX is put into the second slot by a store instruction emitted by the verifier. arch_bpf_timed_may_goto() is special as it receives the parameter in BPF_REG_AX and is expected to return the result in BPF_REG_AX as well. It can't clobber any caller saved registers because verifier doesn't save anything before emitting the call. So, arch_bpf_timed_may_goto() is implemented in assembly so the exact registers that are stored/restored can be controlled (BPF caller saved registers here) and it also needs to take care of moving arguments and return values to and from BPF_REG_AX <-> arm64 R0. So, arch_bpf_timed_may_goto() acts as a trampoline to call bpf_check_timed_may_goto() which does the main logic of placing the timestamp and returning the count. All tests that use may_goto instruction pass after the changing some of them in patch 2 thesofproject#404 stream_errors:OK [...] thesofproject#406/2 stream_success/stream_cond_break:OK [...] thesofproject#494/23 verifier_bpf_fastcall/may_goto_interaction_x86_64:SKIP thesofproject#494/24 verifier_bpf_fastcall/may_goto_interaction_arm64:OK [...] thesofproject#539/1 verifier_may_goto_1/may_goto 0:OK thesofproject#539/2 verifier_may_goto_1/batch 2 of may_goto 0:OK thesofproject#539/3 verifier_may_goto_1/may_goto batch with offsets 2/1/0:OK thesofproject#539/4 verifier_may_goto_1/may_goto batch with offsets 2/0:OK thesofproject#539 verifier_may_goto_1:OK thesofproject#540/1 verifier_may_goto_2/C code with may_goto 0:OK thesofproject#540 verifier_may_goto_2:OK Summary: 7/16 PASSED, 25 SKIPPED, 0 FAILED ==================== Link: https://patch.msgid.link/20250827113245.52629-1-puranjay@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>

ranj063 requested a review from plbossart January 14, 2019 20:29

ranj063 force-pushed the upstream/ops_fixes branch from 78173e0 to cce1f76Compare January 14, 2019 20:31

ranj063 mentioned this pull request Jan 14, 2019
Upstream: fix ops (comments from Mark Brown) #525
Closed

plbossart requested changes Jan 15, 2019
View reviewed changes

Comment threadsound/soc/sof/ops.h Outdated

ranj063 force-pushed the upstream/ops_fixes branch from cce1f76 to 63c49e4Compare January 16, 2019 03:14

plbossart reviewed Jan 16, 2019
View reviewed changes

keyonjie reviewed Jan 17, 2019
View reviewed changes

ranj063 closed this Jan 17, 2019

ranj063 deleted the upstream/ops_fixes branch January 17, 2019 07:27

ranj063 restored the upstream/ops_fixes branch January 17, 2019 07:29

ranj063 reopened this Jan 17, 2019

ranj063 closed this Jan 17, 2019

ranj063 deleted the upstream/ops_fixes branch January 17, 2019 07:30

ranj063 restored the upstream/ops_fixes branch January 17, 2019 07:30

ranj063 reopened this Jan 17, 2019

ranj063 force-pushed the upstream/ops_fixes branch from 63c49e4 to 55b9699Compare January 17, 2019 07:31

ranj063 force-pushed the upstream/ops_fixes branch from 55b9699 to f8ab4fcCompare January 22, 2019 19:52

plbossart reviewed Jan 24, 2019
View reviewed changes

ranj063 force-pushed the upstream/ops_fixes branch from f8ab4fc to 84e8463Compare January 26, 2019 01:24

ranj063 force-pushed the upstream/ops_fixes branch from 84e8463 to 960860bCompare February 5, 2019 02:14

ranj063 force-pushed the upstream/ops_fixes branch from 960860b to 75d52e6Compare February 5, 2019 04:08

plbossart reviewed Feb 6, 2019
View reviewed changes

ranj063 force-pushed the upstream/ops_fixes branch from 75d52e6 to a88576eCompare February 7, 2019 17:53

plbossart reviewed Feb 7, 2019
View reviewed changes

ASoC: SOF: fix return values for mandatory ops
421e6e5
Clarify the mandatory and optional dsp ops and fix return value for mandatory ops. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>

ranj063 force-pushed the upstream/ops_fixes branch from a88576e to 421e6e5Compare February 7, 2019 19:15

plbossart approved these changes Feb 7, 2019
View reviewed changes

plbossart merged commit 4066063 into thesofproject:topic/sof-devFeb 7, 2019

ranj063 deleted the upstream/ops_fixes branch February 8, 2019 06:36

Uh oh!

Conversation

ranj063 commented Jan 14, 2019

Uh oh!

ranj063 commented Jan 14, 2019

Uh oh!

plbossart left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ranj063 commented Jan 16, 2019

Uh oh!

plbossart left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

keyonjie left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ranj063 commented Jan 17, 2019

Uh oh!

keyonjie commented Jan 17, 2019

Uh oh!

ranj063 commented Jan 17, 2019

Uh oh!

ranj063 commented Jan 17, 2019

Uh oh!

ranj063 commented Jan 17, 2019

Uh oh!

plbossart commented Jan 17, 2019

Uh oh!

ranj063 commented Jan 22, 2019

Uh oh!

plbossart left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ranj063 commented Jan 26, 2019

Uh oh!

wenqingfu commented Jan 29, 2019

Uh oh!

plbossart commented Jan 29, 2019 via email

Uh oh!

ranj063 commented Feb 5, 2019

Uh oh!

ranj063 commented Feb 5, 2019

Uh oh!

ranj063 commented Feb 6, 2019

Uh oh!

plbossart left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

plbossart left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!