Messages in this thread |  | | Date | Wed, 3 Dec 2025 16:27:25 +0530 | | Subject | Re: [PATCH v10 3/3] firmware: qcom_scm: Use TASK_IDLE state in wait_for_wq_completion() | | From | Shivendra Pratap <> |
| |
On 12/3/2025 2:01 PM, Mukesh Ojha wrote: > On Sun, Nov 30, 2025 at 08:11:04PM +0530, Shivendra Pratap wrote: >> From: Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com> >> >> When the kernel issues an SMC (Secure Monitor Call) and the firmware >> requests the kernel to wait, the waiting thread enters an >> uninterruptible (D) state. In case of an extended wait request by the >> firmware, any device suspend request, cannot proceed because of the >> thread stuck in D state. This blocks the device suspend. > > Not only that, it is stuck in D state after holding a mutex, which is > more severe because none of the SMC calls can go through. However, this > has been the case since the day the firmware started supporting waitq > with a single context, which is somewhat acceptable as the firmware does > not allow otherwise. Since, you are adding the multiple waitq context > supported by firmware with your other patches, > > Do you plan to support multiple waitq contexts i.e parallel SCM calls, > in SCM driver as well ?
Yes. Parallel SCM can be enabled once this waitq enablement support is in place.
thanks, Shivendra
|  |