From: Felipe Balbi <felipe.balbi@linux.intel.com> To: chunfeng yun <chunfeng.yun@mediatek.com> Cc: Mathias Nyman <mathias.nyman@intel.com>, Matthias Brugger <matthias.bgg@gmail.com>, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-usb@vger.kernel.org, linux-mediatek@lists.infradead.org, Daniel Kurtz <djkurtz@chromium.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, linux-pm@vger.kernel.org Subject: Re: [PATCH] usb: xhci-mtk: fixup mouse wakeup failure during system suspend Date: Wed, 04 May 2016 11:03:03 +0300 [thread overview] Message-ID: <871t5ifdxk.fsf@intel.com> (raw) In-Reply-To: <1462324873.11651.57.camel@mhfsdcap03> [-- Attachment #1: Type: text/plain, Size: 3414 bytes --] Hi, chunfeng yun <chunfeng.yun@mediatek.com> writes: > On Tue, 2016-05-03 at 12:33 +0300, Felipe Balbi wrote: >> Hi, >> >> chunfeng yun <chunfeng.yun@mediatek.com> writes: >> >> chunfeng yun <chunfeng.yun@mediatek.com> writes: >> >> > On Thu, 2016-04-21 at 10:04 +0800, Chunfeng Yun wrote: >> >> >> Click mouse after xhci suspend completion but before system suspend >> >> >> completion, system will not be waken up by mouse if the duration of >> >> >> them is larger than 20ms which is the device UFP's resume signaling >> >> >> >> what is "them" here ? The duration of what is longer than 20ms ? >> > They are "xhci suspend completion" and "system suspend completion"; >> > >> > It's time duration >> >> okay. So if xhci suspend takes longer than 20ms your SPM doesn't see a >> wakeup ? > It is not the time of xhci suspend consumed, but is the time of duration > from xhci suspend completion to system suspend completion(after BOOT-CPU > is turned off, SPM will be enabled to receive wakeup event) Okay, so SPM will be the entity actually handling wakeups, right ? I'm assuming something like this happens: echo mem > /sys/power/state /* start suspending devices */ xhci_suspend() /* all devices suspended */ enable_spm() so, if a mouse button is pressed after xhci_suspend() returns but before enable_spm() runs, then we're gonna miss that event, am I right ? I can't think of any way to sort this out. Let's ask on linux-pm (I've added linux-pm to Cc list) >> >> >> lasted. Another reason is that the SPM is not enabled before system >> >> >> >> what's SPM ? >> > It is System Power Management which is powered off when system is >> > running in normal mode, and is powered on when system enters suspend >> > mode. It is used to wakeup system when some wakeup sources, such as >> > bluetooth or powerkey etc, tigger wakeup event. >> >> okay, thanks >> >> >> >> suspend compeltion, this causes SPM also not notice the resume signal. >> >> ^^^^^^^^^^ >> >> completion >> >> >> >> >> So in order to reduce the duration less than 20ms, make use of >> >> >> syscore's suspend/resume interface. >> >> >> >> no, this is the wrong approach >> > But it seems only one workable approach from software side >> >> I wouldn't say that. It seems to me SPM should be enabled earlier. > Yes, but normally SPM should be enabled after all CPUS are turned off, > so it's difficult to do that, I mean enable SPM before turning off CPUS is it a requirement that SPM should be enabled only after all CPUs are turned off ? If that's the case, then any device in the system might have missed wakeups. This doesn't seem like a good design to me; unless I'm missing something... >> >> >> Because the syscore runs on irq disabled context, and xhci's >> >> >> suspend/resume calls some sleeping functions, enable local irq >> >> >> and then disable it during suspend/resume. This may be not a problem, >> >> >> since only boot CPU is runing. >> >> >> >> another problem :) calling local_irq_{enable,disable}() is an indication >> >> that something's wrong. >> > Oh! >> > >> > BTW: There will be warning logs if they are not called. >> >> yeah, I got that :-) But it's still wrong to use >> local_irq_{enable,disable}() the way you're using them :-) > Yes > > Thank you very much. >> > > -- balbi [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: felipe.balbi@linux.intel.com (Felipe Balbi) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH] usb: xhci-mtk: fixup mouse wakeup failure during system suspend Date: Wed, 04 May 2016 11:03:03 +0300 [thread overview] Message-ID: <871t5ifdxk.fsf@intel.com> (raw) In-Reply-To: <1462324873.11651.57.camel@mhfsdcap03> Hi, chunfeng yun <chunfeng.yun@mediatek.com> writes: > On Tue, 2016-05-03 at 12:33 +0300, Felipe Balbi wrote: >> Hi, >> >> chunfeng yun <chunfeng.yun@mediatek.com> writes: >> >> chunfeng yun <chunfeng.yun@mediatek.com> writes: >> >> > On Thu, 2016-04-21 at 10:04 +0800, Chunfeng Yun wrote: >> >> >> Click mouse after xhci suspend completion but before system suspend >> >> >> completion, system will not be waken up by mouse if the duration of >> >> >> them is larger than 20ms which is the device UFP's resume signaling >> >> >> >> what is "them" here ? The duration of what is longer than 20ms ? >> > They are "xhci suspend completion" and "system suspend completion"; >> > >> > It's time duration >> >> okay. So if xhci suspend takes longer than 20ms your SPM doesn't see a >> wakeup ? > It is not the time of xhci suspend consumed, but is the time of duration > from xhci suspend completion to system suspend completion(after BOOT-CPU > is turned off, SPM will be enabled to receive wakeup event) Okay, so SPM will be the entity actually handling wakeups, right ? I'm assuming something like this happens: echo mem > /sys/power/state /* start suspending devices */ xhci_suspend() /* all devices suspended */ enable_spm() so, if a mouse button is pressed after xhci_suspend() returns but before enable_spm() runs, then we're gonna miss that event, am I right ? I can't think of any way to sort this out. Let's ask on linux-pm (I've added linux-pm to Cc list) >> >> >> lasted. Another reason is that the SPM is not enabled before system >> >> >> >> what's SPM ? >> > It is System Power Management which is powered off when system is >> > running in normal mode, and is powered on when system enters suspend >> > mode. It is used to wakeup system when some wakeup sources, such as >> > bluetooth or powerkey etc, tigger wakeup event. >> >> okay, thanks >> >> >> >> suspend compeltion, this causes SPM also not notice the resume signal. >> >> ^^^^^^^^^^ >> >> completion >> >> >> >> >> So in order to reduce the duration less than 20ms, make use of >> >> >> syscore's suspend/resume interface. >> >> >> >> no, this is the wrong approach >> > But it seems only one workable approach from software side >> >> I wouldn't say that. It seems to me SPM should be enabled earlier. > Yes, but normally SPM should be enabled after all CPUS are turned off, > so it's difficult to do that, I mean enable SPM before turning off CPUS is it a requirement that SPM should be enabled only after all CPUs are turned off ? If that's the case, then any device in the system might have missed wakeups. This doesn't seem like a good design to me; unless I'm missing something... >> >> >> Because the syscore runs on irq disabled context, and xhci's >> >> >> suspend/resume calls some sleeping functions, enable local irq >> >> >> and then disable it during suspend/resume. This may be not a problem, >> >> >> since only boot CPU is runing. >> >> >> >> another problem :) calling local_irq_{enable,disable}() is an indication >> >> that something's wrong. >> > Oh! >> > >> > BTW: There will be warning logs if they are not called. >> >> yeah, I got that :-) But it's still wrong to use >> local_irq_{enable,disable}() the way you're using them :-) > Yes > > Thank you very much. >> > > -- balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160504/43c16e2f/attachment-0001.sig>
next prev parent reply other threads:[~2016-05-04 8:05 UTC|newest] Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-04-21 2:04 [PATCH] usb: xhci-mtk: fixup mouse wakeup failure during system suspend Chunfeng Yun 2016-04-21 2:04 ` Chunfeng Yun 2016-04-21 2:04 ` Chunfeng Yun 2016-05-03 7:44 ` chunfeng yun 2016-05-03 7:44 ` chunfeng yun 2016-05-03 7:44 ` chunfeng yun 2016-05-03 7:51 ` Felipe Balbi 2016-05-03 7:51 ` Felipe Balbi 2016-05-03 9:09 ` chunfeng yun 2016-05-03 9:09 ` chunfeng yun 2016-05-03 9:09 ` chunfeng yun 2016-05-03 9:33 ` Felipe Balbi 2016-05-03 9:33 ` Felipe Balbi 2016-05-03 9:33 ` Felipe Balbi 2016-05-04 1:21 ` chunfeng yun 2016-05-04 1:21 ` chunfeng yun 2016-05-04 1:21 ` chunfeng yun 2016-05-04 8:03 ` Felipe Balbi [this message] 2016-05-04 8:03 ` Felipe Balbi 2016-05-04 10:54 ` chunfeng yun 2016-05-04 10:54 ` chunfeng yun 2016-05-04 10:54 ` chunfeng yun 2016-05-04 11:56 ` Felipe Balbi 2016-05-04 11:56 ` Felipe Balbi 2016-05-17 2:00 ` chunfeng yun 2016-05-17 2:00 ` chunfeng yun 2016-05-17 2:00 ` chunfeng yun
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=871t5ifdxk.fsf@intel.com \ --to=felipe.balbi@linux.intel.com \ --cc=chunfeng.yun@mediatek.com \ --cc=djkurtz@chromium.org \ --cc=gregkh@linuxfoundation.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mediatek@lists.infradead.org \ --cc=linux-pm@vger.kernel.org \ --cc=linux-usb@vger.kernel.org \ --cc=mathias.nyman@intel.com \ --cc=matthias.bgg@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.