I have an application which calls the ioctl of the codec driver to know the status of the headset. The ioctl waits on a completion variable (using wait_for_completion_interruptible). The variable is completed in the interrupt handler, which happens on headset insertion/removal. Once the variable is completed, the ioctl returns (with appropriate value in the argument) and the application decides what to do with the event. Once done handling the event, the application then calls the ioctl once again (bascially it polls the audio driver) to know the status of the headset. The call is blocked until the headset status changes. I am running the system on linux-2.6.29 on a OMAP1 based board. All this works well when the OMAP is awake. The problem starts when we suspend the OMAP. The moment we suspend, the wait_for_completion_interruptible is interrupted and the ioctl returns. Application ends up thinking that the headset was either removed/inserted. Our system does an aggressive sleep (wakes up every 500 ms and sleeps again) and hence the application gets the event of headset every 500 ms. I tried wait_for_completion instead, but now the kernel refuses to suspend. I have tried wait queues and mutexs with no success. Could anyone please point me how I can resolve this issue? Is there any construct which can block inside the kernel during suspend/resume? Can there be a blocking call active while we suspend? Ideally I would resort to a method in which I would signal the process when there is a headset event, but I am not free to change the application. Its a legacy application and I have to make the kernel work for it. Thanks in advance, Suresh PS: It might be unrelated, but I am mentioning it here because I learnt this while debugging the issue. If I use an application scheduled as SCHED_FIFO to suspend the kernel (using a driver ioctl which in turn calls enter_state), the operation fails (kernel aborts the process of suspending after 20 seconds saying some applications failed to freeze). Just changing the application scheduling policy to SCHED_OTHER resolves the issue. I was unable to find an explaination for this. However, my current test applications are scheduled as SCHED_OTHER. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
