On 8/22/2024 7:06 PM, Bart Van Assche wrote:
On 8/22/24 4:34 PM, Bao D. Nguyen wrote:
Let's say you are sending a ufshcd_uic_pwr_ctrl() command. You will
get 2 uic completion interrupts:
[1] ufshcd_uic_cmd_compl() is called for the first interrupt which
happens to be UFSHCD_UIC_PWR_MASK only. At the end of the
ufshcd_uic_pwr_ctrl(), you would set the hba->active_uic_cmd to NULL.
That's not correct. ufshcd_uic_pwr_ctrl() only clears
hba->active_uic_cmd after the power mode change interrupt has been
processed.
Agree.
[2]The second uic completion interrupt for UIC_COMMAND_COMP is delayed.
This interrupt is newly introduced by this patch.
If UIC_COMMAND_COMPL is delivered after UFSHCD_UIC_PWR_MASK then the
UIC_COMMAND_COMPL interrupt will be ignored because hba->active_uic_cmd
is cleared by ufshcd_uic_pwr_ctrl() after it has processed the
power mode change interrupt.
Agree.
Now let's say you have a new UIC command coming via
ufshcd_send_uic_cmd(). The ufshcd_dispatch_uic_cmd() will update your
hba->active_uic_cmd to the new uic_cmd.
UIC command processing is serialized by hba->uic_cmd_mutex. Hence only
one UIC command is processed at any given time.
Does this address your concerns?
Not really. I agree that the uic commands are serialized by the
hba->uic_cmd_mutex. However, the UIC_COMMAND_COMPL extra interrupt
belonging to the previous PMC/hibern8_enter/exit() command can come late
and causes the ufshcd_uic_cmd_compl() to complete the current uic
command incorrectly.
Thanks, Bao
Thanks,
Bart.
