On 8/22/2024 11:13 AM, Bart Van Assche wrote:
On 8/21/24 6:05 PM, Bao D. Nguyen wrote:
If I understand correctly, the link is hibernated because we had a
successful ufshcd_uic_hibern8_enter() earlier. Then the
ufshcd_uic_pwr_ctrl() is invoked probably from a power mode change
command? (a callstack would be helpful in this case).
Hi Bao,
ufshcd_uic_hibern8_enter() calls ufshcd_uic_pwr_ctrl() directly. The
former function causes the latter to send the UIC_CMD_DME_HIBER_ENTER
command. Although UIC_CMD_DME_HIBER_ENTER causes the link to enter the
hibernation state, the code in ufshcd_uic_pwr_ctrl() for re-enabling
interrupts causes the UFS host controller that I'm testing to exit the
hibernation state.
Anyway, accessing the UFSHCI host controller registers space somehow
affected the M-PHY link state? If my understanding is correct, it
seems like a hardware issue that we are trying to work around?
Yes, this is a workaround particular behavior of a particular UFS
controller.
Thank you for the clarification, Bart.
I am just curious about providing workaround for a hardware issue in the
ufs core driver. Sometimes I notice the community is not accepting such
a change and push the change to be implemented in the vendor/platform
drivers.
Now about your workaround, I have the same concern as Bean.
For a ufshcd_uic_pwr_ctrl() command, i.e PMC, hibern8_enter/exit()
commands, you will get 2 ufshcd_uic_cmd_compl() interrupts or 1 uic
completion interrupt with 2 status bits set at once.
a. UIC_COMMAND_COMPL is set
b. and one of these bits UIC_POWER_MODE || UIC_HIBERNATE_EXIT ||
UIC_HIBERNATE_ENTER is set, depending on the completed uic command.
In your proposed change to ufshcd_uic_cmd_compl(), you are signalling
both complete(&cmd->done) and complete(hba->uic_async_done) for a single
ufshcd_uic_pwr_ctrl() command which can cause issues.
Thanks, Bao
Thanks,
Bart.
