| Message ID | 1461204293-18243-1-git-send-email-chunfeng.yun@mediatek.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Mathias, 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 > lasted. Another reason is that the SPM is not enabled before system > suspend compeltion, this causes SPM also not notice the resume signal. > So in order to reduce the duration less than 20ms, make use of > syscore's suspend/resume interface. > In fact it is a work around solution which only reduces the > probability of failure, because we can't ensure that the duration from > syscore's suspend completion to SPM working is always less than 20ms. > > 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. > > Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> > --- > drivers/usb/host/xhci-mtk.c | 31 ++++++++++++++++++++++++++++++- > 1 file changed, 30 insertions(+), 1 deletion(-) > > diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c > index 79959f1..8277f02 100644 > --- a/drivers/usb/host/xhci-mtk.c > +++ b/drivers/usb/host/xhci-mtk.c > @@ -28,6 +28,7 @@ > #include <linux/pm_runtime.h> > #include <linux/regmap.h> > #include <linux/regulator/consumer.h> > +#include <linux/syscore_ops.h> > > #include "xhci.h" > #include "xhci-mtk.h" > @@ -490,6 +491,8 @@ static int xhci_mtk_setup(struct usb_hcd *hcd) > return xhci_gen_setup(hcd, xhci_mtk_quirks); > } > > +static struct device *xhci_mtk_syscore_dev; > + > static int xhci_mtk_probe(struct platform_device *pdev) > { > struct device *dev = &pdev->dev; > @@ -512,6 +515,7 @@ static int xhci_mtk_probe(struct platform_device *pdev) > if (!mtk) > return -ENOMEM; > > + xhci_mtk_syscore_dev = dev; > mtk->dev = dev; > mtk->vbus = devm_regulator_get(dev, "vbus"); > if (IS_ERR(mtk->vbus)) { > @@ -740,6 +744,29 @@ static int __maybe_unused xhci_mtk_resume(struct device *dev) > return 0; > } > > +static int xhci_mtk_syscore_suspend(void) > +{ > + local_irq_enable(); > + xhci_mtk_suspend(xhci_mtk_syscore_dev); > + local_irq_disable(); > + > + return 0; > +} > + > +static void xhci_mtk_syscore_resume(void) > +{ > + local_irq_enable(); > + xhci_mtk_resume(xhci_mtk_syscore_dev); > + local_irq_disable(); > + > + return; > +} > + > +static struct syscore_ops xhci_mtk_syscore_ops = { > + .suspend = xhci_mtk_syscore_suspend, > + .resume = xhci_mtk_syscore_resume, > +}; > + > static const struct dev_pm_ops xhci_mtk_pm_ops = { > SET_SYSTEM_SLEEP_PM_OPS(xhci_mtk_suspend, xhci_mtk_resume) > }; > @@ -758,7 +785,7 @@ static struct platform_driver mtk_xhci_driver = { > .remove = xhci_mtk_remove, > .driver = { > .name = "xhci-mtk", > - .pm = DEV_PM_OPS, > + /*.pm = DEV_PM_OPS,*/ > .of_match_table = of_match_ptr(mtk_xhci_of_match), > }, > }; > @@ -766,6 +793,7 @@ MODULE_ALIAS("platform:xhci-mtk"); > > static int __init xhci_mtk_init(void) > { > + register_syscore_ops(&xhci_mtk_syscore_ops); > xhci_init_driver(&xhci_mtk_hc_driver, &xhci_mtk_overrides); > return platform_driver_register(&mtk_xhci_driver); > } > @@ -774,6 +802,7 @@ module_init(xhci_mtk_init); > static void __exit xhci_mtk_exit(void) > { > platform_driver_unregister(&mtk_xhci_driver); > + unregister_syscore_ops(&xhci_mtk_syscore_ops); > } > module_exit(xhci_mtk_exit); Do you have any suggestions about the patch? Thanks >
Hi, 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 ? >> lasted. Another reason is that the SPM is not enabled before system what's SPM ? >> 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 >> In fact it is a work around solution which only reduces the >> probability of failure, because we can't ensure that the duration from >> syscore's suspend completion to SPM working is always less than 20ms. right, which means you're not really fixing anything. Morevoer, you make it so that this won't work with multiple instances of the XHCI IP in your SoC. >> 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. >> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> >> --- >> drivers/usb/host/xhci-mtk.c | 31 ++++++++++++++++++++++++++++++- >> 1 file changed, 30 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c >> index 79959f1..8277f02 100644 >> --- a/drivers/usb/host/xhci-mtk.c >> +++ b/drivers/usb/host/xhci-mtk.c >> @@ -28,6 +28,7 @@ >> #include <linux/pm_runtime.h> >> #include <linux/regmap.h> >> #include <linux/regulator/consumer.h> >> +#include <linux/syscore_ops.h> >> >> #include "xhci.h" >> #include "xhci-mtk.h" >> @@ -490,6 +491,8 @@ static int xhci_mtk_setup(struct usb_hcd *hcd) >> return xhci_gen_setup(hcd, xhci_mtk_quirks); >> } >> >> +static struct device *xhci_mtk_syscore_dev; now, what happens when you have more than one XHCI instance ?
On Tue, 2016-05-03 at 10:51 +0300, Felipe Balbi wrote: > Hi, > > 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 > > >> 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. > > >> 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 > > >> In fact it is a work around solution which only reduces the > >> probability of failure, because we can't ensure that the duration from > >> syscore's suspend completion to SPM working is always less than 20ms. > > right, which means you're not really fixing anything. Morevoer, you make > it so that this won't work with multiple instances of the XHCI IP in > your SoC. > It can be easily fixed up from hardware side by latching resume signal until SPM is powered on. I forgot to take into account of multiple instances > >> 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. Thanks a lot > > >> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> > >> --- > >> drivers/usb/host/xhci-mtk.c | 31 ++++++++++++++++++++++++++++++- > >> 1 file changed, 30 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c > >> index 79959f1..8277f02 100644 > >> --- a/drivers/usb/host/xhci-mtk.c > >> +++ b/drivers/usb/host/xhci-mtk.c > >> @@ -28,6 +28,7 @@ > >> #include <linux/pm_runtime.h> > >> #include <linux/regmap.h> > >> #include <linux/regulator/consumer.h> > >> +#include <linux/syscore_ops.h> > >> > >> #include "xhci.h" > >> #include "xhci-mtk.h" > >> @@ -490,6 +491,8 @@ static int xhci_mtk_setup(struct usb_hcd *hcd) > >> return xhci_gen_setup(hcd, xhci_mtk_quirks); > >> } > >> > >> +static struct device *xhci_mtk_syscore_dev; > > now, what happens when you have more than one XHCI instance ? >
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 ? >> >> 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. >> >> 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 :-)
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) > > >> >> 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 > > >> >> 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. >
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. >> > >
Hi, On Wed, 2016-05-04 at 11:03 +0300, Felipe Balbi wrote: > 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 ? Yes, you are 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) Thanks > > >> >> >> 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... Yes, it's a requirement. If the wakeup source is level trigger, and will keep it until SPM notice it. Although USB wakeup is level trigger, but it just last at most 20ms and clear itself automatically. > > >> >> >> 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. > >> > > > > >
Hi, chunfeng yun <chunfeng.yun@mediatek.com> writes: >> 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 ? > Yes, you are 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) > Thanks >> >> >> >> >> 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... > Yes, it's a requirement. > > If the wakeup source is level trigger, and will keep it until SPM notice > it. Although USB wakeup is level trigger, but it just last at most 20ms > and clear itself automatically. who's clearing USB wakeup after 20ms ? Sure, it's a requirement by the USB spec that host should drive reset for *at least* 20ms, but I don't remember the exact wordings WRT remote wakeup /me reads Okay, here it is, section 7.1.7.7 of USB 2.0 Spec states: "The remote wakeup device must hold the resume signaling for at least 1 ms but for no more than 15 ms (TDRSMUP). At the end of this period, the device stops driving the bus (puts its drivers into the high-impedance state and does not drive the bus to the J state)." IOW, the mouse is not at fault here. Remote wakeup can last anywhere between 1ms and 15ms. If your system can't cope with it, then I'd say it's a problem with your system and you shouldn't allow XHCI to go to such deep power states until SPM is enabled. I really tried finding the correct piece of code which does this for PCI devices, but basically it's treated as an IRQ and as long as enable_irq_wake() or the sysfs file is set to true, then PME gets enabled (hopefully PCI folks can confirm this statement). Very recently Tony Lindgren added proper handling of wakeup signals as IRQs for non-PCI systems too (see 4990d4fe327b PM / Wakeirq: Add automated device wake IRQ handling), wonder if you could treat SPM similarly.
On Wed, 2016-05-04 at 14:56 +0300, Felipe Balbi wrote: > Hi, > > chunfeng yun <chunfeng.yun@mediatek.com> writes: > >> 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 ? > > Yes, you are 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) > > Thanks > >> > >> >> >> >> 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... > > Yes, it's a requirement. > > > > If the wakeup source is level trigger, and will keep it until SPM notice > > it. Although USB wakeup is level trigger, but it just last at most 20ms > > and clear itself automatically. > > who's clearing USB wakeup after 20ms ? Sure, it's a requirement by the > USB spec that host should drive reset for *at least* 20ms, but I don't > remember the exact wordings WRT remote wakeup > > /me reads > > Okay, here it is, section 7.1.7.7 of USB 2.0 Spec states: > > "The remote wakeup device must hold the resume signaling for at > least 1 ms but for no more than 15 ms (TDRSMUP). At the end of > this period, the device stops driving the bus (puts its drivers > into the high-impedance state and does not drive the bus to the > J state)." > > IOW, the mouse is not at fault here. Remote wakeup can last anywhere > between 1ms and 15ms. If your system can't cope with it, then I'd say > it's a problem with your system and you shouldn't allow XHCI to go to > such deep power states until SPM is enabled. Yes > > I really tried finding the correct piece of code which does this for PCI > devices, but basically it's treated as an IRQ and as long as > enable_irq_wake() or the sysfs file is set to true, then PME gets > enabled (hopefully PCI folks can confirm this statement). > > Very recently Tony Lindgren added proper handling of wakeup signals as > IRQs for non-PCI systems too (see 4990d4fe327b PM / Wakeirq: Add > automated device wake IRQ handling), wonder if you could treat SPM > similarly. We can't make use of device's interrupt as wake IRQ, because there is no IRQ when xHCI enters suspend mode. Thanks >
diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c index 79959f1..8277f02 100644 --- a/drivers/usb/host/xhci-mtk.c +++ b/drivers/usb/host/xhci-mtk.c @@ -28,6 +28,7 @@ #include <linux/pm_runtime.h> #include <linux/regmap.h> #include <linux/regulator/consumer.h> +#include <linux/syscore_ops.h> #include "xhci.h" #include "xhci-mtk.h" @@ -490,6 +491,8 @@ static int xhci_mtk_setup(struct usb_hcd *hcd) return xhci_gen_setup(hcd, xhci_mtk_quirks); } +static struct device *xhci_mtk_syscore_dev; + static int xhci_mtk_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; @@ -512,6 +515,7 @@ static int xhci_mtk_probe(struct platform_device *pdev) if (!mtk) return -ENOMEM; + xhci_mtk_syscore_dev = dev; mtk->dev = dev; mtk->vbus = devm_regulator_get(dev, "vbus"); if (IS_ERR(mtk->vbus)) { @@ -740,6 +744,29 @@ static int __maybe_unused xhci_mtk_resume(struct device *dev) return 0; } +static int xhci_mtk_syscore_suspend(void) +{ + local_irq_enable(); + xhci_mtk_suspend(xhci_mtk_syscore_dev); + local_irq_disable(); + + return 0; +} + +static void xhci_mtk_syscore_resume(void) +{ + local_irq_enable(); + xhci_mtk_resume(xhci_mtk_syscore_dev); + local_irq_disable(); + + return; +} + +static struct syscore_ops xhci_mtk_syscore_ops = { + .suspend = xhci_mtk_syscore_suspend, + .resume = xhci_mtk_syscore_resume, +}; + static const struct dev_pm_ops xhci_mtk_pm_ops = { SET_SYSTEM_SLEEP_PM_OPS(xhci_mtk_suspend, xhci_mtk_resume) }; @@ -758,7 +785,7 @@ static struct platform_driver mtk_xhci_driver = { .remove = xhci_mtk_remove, .driver = { .name = "xhci-mtk", - .pm = DEV_PM_OPS, + /*.pm = DEV_PM_OPS,*/ .of_match_table = of_match_ptr(mtk_xhci_of_match), }, }; @@ -766,6 +793,7 @@ MODULE_ALIAS("platform:xhci-mtk"); static int __init xhci_mtk_init(void) { + register_syscore_ops(&xhci_mtk_syscore_ops); xhci_init_driver(&xhci_mtk_hc_driver, &xhci_mtk_overrides); return platform_driver_register(&mtk_xhci_driver); } @@ -774,6 +802,7 @@ module_init(xhci_mtk_init); static void __exit xhci_mtk_exit(void) { platform_driver_unregister(&mtk_xhci_driver); + unregister_syscore_ops(&xhci_mtk_syscore_ops); } module_exit(xhci_mtk_exit);
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 lasted. Another reason is that the SPM is not enabled before system suspend compeltion, this causes SPM also not notice the resume signal. So in order to reduce the duration less than 20ms, make use of syscore's suspend/resume interface. In fact it is a work around solution which only reduces the probability of failure, because we can't ensure that the duration from syscore's suspend completion to SPM working is always less than 20ms. 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. Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> --- drivers/usb/host/xhci-mtk.c | 31 ++++++++++++++++++++++++++++++- 1 file changed, 30 insertions(+), 1 deletion(-)