All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chanwoo Choi <cw00.choi@samsung.com>
To: Grygorii Strashko <grygorii.strashko@ti.com>,
	Roger Quadros <rogerq@ti.com>,
	myungjoo.ham@samsung.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] extcon: usb-gpio: Don't miss event during suspend/resume
Date: Mon, 11 Apr 2016 20:12:06 +0900	[thread overview]
Message-ID: <570B8686.3050306@samsung.com> (raw)
In-Reply-To: <570B6248.6080905@ti.com>

On 2016년 04월 11일 17:37, Grygorii Strashko wrote:
> On 04/11/2016 03:31 AM, Chanwoo Choi wrote:
>> Hi Roger,
>>
>> On 2016년 04월 08일 16:34, Roger Quadros wrote:
>>> Pin state might have changed during suspend/resume while
>>> our interrupts were disabled and if device doesn't support wakeup.
>>>
>>> Scan for change during resume for such case.
>>>
>>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>>> ---
>>> v2:
>>> - only check for state change during resume if device wakeup is not supported
>>>
>>>   drivers/extcon/extcon-usb-gpio.c | 2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/extcon/extcon-usb-gpio.c b/drivers/extcon/extcon-usb-gpio.c
>>> index bc61d11..118f8ab 100644
>>> --- a/drivers/extcon/extcon-usb-gpio.c
>>> +++ b/drivers/extcon/extcon-usb-gpio.c
>>> @@ -185,6 +185,8 @@ static int usb_extcon_resume(struct device *dev)
>>>   	int ret = 0;
>>>   
>>>   	enable_irq(info->id_irq);
>>> +	if (!device_may_wakeup(dev))
>>> +		usb_extcon_detect_cable(&info->wq_detcable.work);
>>
>> The device_may_wakeup() check the following two states:
>> - dev->power.can_wakeup - device_init_wakeup() function set the this field.
>> - dev->power.wakeup - device_wakeup_enable() function set the this field.
>>
>> The probe function of extcon-usb-gpio.c always call the 'device_init_wakeup(dev,true).
>> But, anywhere in extcon-usb-gpio.c don't handle the device_wakeup_enable() for dev->power.wakeup.
> 
> 
> device_init_wakeup()
>  |-> device_wakeup_enable()
> 
>>
>> In the extcon-usb-gpio.c, device_may_wakeup(dev) return always 'false'.
>> If you use the only device_may_wakeup(),
>> device_may_wakeup() is not able to check whether interrupt is wakeup source or not.
>>
> 
> This check is correct and it also will take into account wake up settings changes
> which can be made through sysfs: /sys/.../devX/power/wakeup
> 

To Grygorii,

You're right. I was mistaken. Again, I analyzed the sequence about wakeup.
Thanks for your reply.

1. Register device as wakeup_source.
 device_init_wakeup(dev, true) on probe()
	device_wakeup_enable(dev)
		device_source_register(const char *name)
			struct wakeup_source *ws;
			ws = wakeup_source_create(name)
			if (ws)
				wakeup_source_add(ws);
					...
					list_add_rcu(&ws->entry, &wakeup_sources);
					...
			return ws;
			
			
2. Register the interrupt as wake_irq
dev_pm_set_wake_irq(struct device *dev, int irq) on probe()
	struct wake_irq *wirq;
	wirq->dev = dev;
	wirq->irq = irq;
	dev_pm_attach_wake_irq(dev, irq, wirq);
		device_wakeup_attach_irq(*dev, *wakeirq)
			struct wakeup_source *ws;
			ws = dev->power.wakeup;
			ws->wakeirq = wakeirq;


3. Enable irq wake if device is already registed to wakeup_sources.
dpm_suspend_noirq()
	device_wakeup_arm_wake_irqs()
		list_for_each_entry_rcu(ws, &wakeup_sources, entry) {
			if (ws->wakeirq)
				dev_pm_arm_wake_irq(sw->wakeirq);
					if (device_may_wakeup(wirq->dev))
						enable_irq_wake(wirq->irq);


To Roger,

How about using the queue_delayed_work() instead of direct call function?
Because the spent time of wakeup from suspend state should be fast.
So, I think that you better to use the queue_delayed_work().

diff --git a/drivers/extcon/extcon-usb-gpio.c b/drivers/extcon/extcon-usb-gpio.c
index 118f8ab3be73..f6cbdfe31519 100644
--- a/drivers/extcon/extcon-usb-gpio.c
+++ b/drivers/extcon/extcon-usb-gpio.c
@@ -186,7 +186,9 @@ static int usb_extcon_resume(struct device *dev)
 
        enable_irq(info->id_irq);
        if (!device_may_wakeup(dev))
-               usb_extcon_detect_cable(&info->wq_detcable.work);
+               queue_delayed_work(system_power_efficient_wq,
+                               &info->wq_detcable,
+                               info->debounce_jiffies);
 
        return ret;
 }


Thanks,
Chanwoo Choi

  reply	other threads:[~2016-04-11 11:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-06 14:01 [PATCH] extcon: usb-gpio: Don't miss event during suspend/resume Roger Quadros
2016-04-07 23:39 ` Chanwoo Choi
2016-04-08  7:34 ` [PATCH v2] " Roger Quadros
2016-04-11  0:31   ` Chanwoo Choi
2016-04-11  8:37     ` Grygorii Strashko
2016-04-11 11:12       ` Chanwoo Choi [this message]
2016-04-11 11:39         ` Roger Quadros
2016-04-11 13:17           ` Chanwoo Choi
2016-04-11 14:02             ` Roger Quadros
2016-04-11 14:04   ` [PATCH v3] " Roger Quadros
2016-04-11 22:43     ` Chanwoo Choi

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=570B8686.3050306@samsung.com \
    --to=cw00.choi@samsung.com \
    --cc=grygorii.strashko@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=myungjoo.ham@samsung.com \
    --cc=rogerq@ti.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: link
Be 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.