-
Notifications
You must be signed in to change notification settings - Fork 349
[Do Not Review][For Test Only] Multi-core Test #4893
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
7669e28 to
76cf1b2
Compare
|
closing this. rolled into #4702 |
|
sorry closed the wrong one. meant to close mine :) |
ffb5385 to
9e23888
Compare
c83bdf4 to
42a0197
Compare
8d6c2b8 to
a01579a
Compare
src/drivers/dw/dma.c
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.
no, this breaks atomicity. The original code made sure that no IRQ could interrupt execution between line 353 and the call to dw_dma_stop(). After that patch this atomicity is broken. Nested calls to irq_local_disable() or irq_local_enable() are fine as long as they're done with different flags. Those names are a bit misleading, in the kernel they're called local_irq_save() and local_irq_restore(). But the important point is, that if you call irq_local_disable() twice with different flags, if interrupts are enabled during the first call, it will save the CPU interrupt state with enabled interrupts into flags and disable interrupts. The next call to irq_local_disable() will save already disabled interrupts into a different copy of flags. Then the first call to irq_local_enable() with the second copy of the flags will restore that CPU state, which still had interrupts disabled. And only the second call to irq_local_enable() with the first copy of flags will re-enable the interrupts.
It is a different question though whether atomicity is important here.
|
Can one of the admins verify this patch? |
a01579a to
f98c23e
Compare
Only for test at the moment. Signed-off-by: Keyon Jie <yang.jie@linux.intel.com>
f98c23e to
8a459c7
Compare
|
@keyonjie what's the ETA to merge this ? |
|
this was only for test, closing it now. |
No description provided.