On Mon, Nov 17, 2014 at 11:20:01AM +0100, Oliver Neukum wrote: >On Mon, 2014-11-17 at 17:47 +0800, Wang, Yu wrote: >> On Mon, Nov 17, 2014 at 10:46:25AM +0100, Oliver Neukum wrote: >> >On Mon, 2014-11-17 at 13:51 +0800, Wang, Yu wrote: >> >> Hi Roger, >> >> >> >> I saw one old thread about your patch for wakeup IRQ support in USB >> >> core. We need it for Intel platform. And it is work well on intel >> >> platform. >> >> >> >> May I know why this patch haven't get merged so far? I saw everything >> >> was smooth during the discussion, and you had already fixed all comments >> >> from Alan. But somehow the discussion is stop. >> >> >> >> Old thread link: >> >> http://lkml.iu.edu//hypermail/linux/kernel/1307.1/01392.html >> > >> >Maybe this is just me, but this looks hackish. Why not clear >> >the IRQ and queue a work resuming the HC and calling the handler? >> >> The controller is in suspended state which is power gated. How to access >> its registers? We have to resume it first before clear IRQ. > >Sorry block was meant. You cannot clear the interrupt in a sleeping HC. >But why depend on the resume() handler to redo the interrupt? We know >there was an interrupt. We can call the handler. Due to we can't clear the IRQ before controller resume. So the IRQ will always trigger until we handled it. It will cause CPU aways be interrupted by this IRQ during. After get wakeup IRQ, until HC get resumed. There have a little bit long latency. 1, get wakeup IRQ. 2, call usb_hcd_resume_root_hub which will schedule the workqueue. 3, In the usb_remote_wakeup, it will call pm_runtime_get_sync. For step 2 and 3, they are all cost progresses scheduling latency. That is why roger disable it in the ISR, and re-enable it after controller get resumed. Thanks Yu > > Regards > Oliver > > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
