Messages in this thread |  | | Date | Thu, 4 Dec 2025 13:06:01 +0530 | | From | Mukesh Ojha <> | | Subject | Re: [PATCH v10 3/3] firmware: qcom_scm: Use TASK_IDLE state in wait_for_wq_completion() |
| |
On Wed, Dec 03, 2025 at 04:27:25PM +0530, Shivendra Pratap wrote: > > > 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.
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> > thanks, > Shivendra
-- -Mukesh Ojha
|  |