-
Notifications
You must be signed in to change notification settings - Fork 349
Power management and other comments + constify ipc_buffer_new #4441
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
The only checkpatch warning is |
src/include/sof/audio/buffer.h
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are probably missing other const usage wrt IPC too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably, this one just came up when looking at your valgrind fixes.
So CI is building and running successfully here with the new assert. I assume you have checked the binary size difference with XCC (assume GCC will be the same). |
marc-hb
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So CI is building and running successfully here with the new assert.
No, it's commented out.
I assume you have checked the binary size difference with XCC (assume GCC will be the same).
I checked only with gcc10 and only with the default flags, that's why I left it commented out.
src/include/sof/audio/buffer.h
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably, this one just came up when looking at your valgrind fixes.
ok, lets check with XCC before we merge this as we can remove the conditional or have an |
oh - CI probably has the info for XCC builds ? |
Does not silently succeeds when passed variables. Not enabled by default in the unlikely case it wastes memory with some compiler and/or compiler flags. Issue found while testing tracing mismatch thesofproject#4388 Signed-off-by: Marc Herbert <marc.herbert@intel.com>
'const' documents APIs and catches bugs. This came while discussing thesofproject#4408 Signed-off-by: Marc Herbert <marc.herbert@intel.com>
As requested in previous PR thesofproject#4428 Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Pure comments, no code change. Follow-up to commit 8633d5f ("cavs: pm: improve PM_RUNTIME_HOST_DMA_L1 documentation") Signed-off-by: Marc Herbert <marc.herbert@intel.com>
8ff495c to
c48ddf6
Compare
|
I tested gcc and xcc with various -O levels. I found only one case where the array-based assert increases the Comment updated accordingly. |
| #else | ||
| #define STATIC_ASSERT(COND, MESSAGE) \ | ||
| __attribute__((unused)) \ | ||
| static char META_CONCAT(arr_assertion_failed_, MESSAGE)[(COND) ? 1 : -1] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does it have to be static? And there's an additional space there
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does it have to be static?
Depends where you prefer to waste a few bytes per assertion at the -O0 level. I suspect the .bss is likely to have less performance impact.
And there's an additional space there
That was for aligning with the other one but not very useful, I can remove.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Depends where you prefer to waste a few bytes per assertion at the -O0 level. I suspect the .bss is likely to have less performance impact.
Actually: I didn't check whether gcc -O0 allocates unused local variables or not.
This is the reason this is disabled by default: it's very tedious and more importantly: unreliable to test every optimization level for every compiler.
Do we still need the |
I don't like On one hand I discovered that the On the other hand the array based solution is 100% reliable BUT it can waste some memory with some compilers at the |
|
CI showung a non booting DUT and a know alsabat issue on APL nocodec, both unrelated. |
See commit messages.