linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: balbi@ti.com (Felipe Balbi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] gpio-vbus: support disabling D+ pullup on suspend
Date: Wed, 22 Jun 2011 17:01:28 +0300	[thread overview]
Message-ID: <20110622140127.GB27654@legolas.emea.dhcp.ti.com> (raw)
In-Reply-To: <BANLkTimK0B-620-3DfRY4yGURGs=Y4uDQA@mail.gmail.com>

Hi,

On Wed, Jun 22, 2011 at 05:52:18PM +0400, Dmitry Eremin-Solenikov wrote:
> On 6/22/11, Felipe Balbi <balbi@ti.com> wrote:
> > Hi,
> >
> > On Wed, Jun 22, 2011 at 04:20:16PM +0400, Dmitry Eremin-Solenikov wrote:
> >> Some platforms would like to disable D+ pullup on suspend, to drain as
> >> low power, as possible. E.g. this was requested by mioa701 board
> >> maintainers.
> >
> > I think this makes sense to many platforms, but by doing so, you would
> > loose connection to the Host PC, so you need to make sure your device
> > isn't been used before you go down this road.
> 
> I've thought about this. Should UDC driver should somehow call into OTG
> layer on suspend? My understanding is that otg_set_suspend isn't the call
> that should be done here, is it true?
> 
> My idea was that board can ask for D+ disabling, knowing itself the behaviour
> of the platform driver on suspend (e.g. PXA27x does disable UDC on suspend,
> but I dunno what effect this will cause on Host PC).

Host PC will only see the device disconnecting. So, what happens if the
user has mounted file systems when you decide to go into suspend ?

> 
> >> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> >> ---
> >>  drivers/usb/otg/gpio_vbus.c   |   32 ++++++++++++++++++++++++++++++++
> >>  include/linux/usb/gpio_vbus.h |    1 +
> >>  2 files changed, 33 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/usb/otg/gpio_vbus.c b/drivers/usb/otg/gpio_vbus.c
> >> index 52733d9..44527bd 100644
> >> --- a/drivers/usb/otg/gpio_vbus.c
> >> +++ b/drivers/usb/otg/gpio_vbus.c
> >> @@ -327,6 +327,34 @@ static int __exit gpio_vbus_remove(struct
> >> platform_device *pdev)
> >>  	return 0;
> >>  }
> >>
> >> +#ifdef CONFIG_PM
> >> +static int gpio_vbus_suspend(struct platform_device *pdev, pm_message_t
> >> state)
> >> +{
> >> +	struct gpio_vbus_data *gpio_vbus = platform_get_drvdata(pdev);
> >> +	struct gpio_vbus_mach_info *pdata = gpio_vbus->dev->platform_data;
> >> +
> >> +	if (gpio_vbus->otg.gadget && pdata->disconnect_on_suspend) {
> >> +		/* optionally disable D+ pullup */
> >> +		if (gpio_is_valid(pdata->gpio_pullup))
> >> +			gpio_set_value(pdata->gpio_pullup,
> >> +					pdata->gpio_pullup_inverted);
> >> +
> >> +		set_vbus_draw(gpio_vbus, 0);
> >> +	}
> >> +	return 0;
> >> +}
> >> +
> >> +static int gpio_vbus_resume(struct platform_device *pdev)
> >> +{
> >> +	struct gpio_vbus_data *gpio_vbus = platform_get_drvdata(pdev);
> >> +
> >> +	if (gpio_vbus->otg.gadget)
> >> +		schedule_work(&gpio_vbus->work);
> >> +
> >> +	return 0;
> >> +}
> >
> > actually, the correct way would be to use dev_pm_ops.
> 
> Could I use SIMPLE_DEV_PM_OPS here?

for sure ;-)

> >> +#endif
> >> +
> >>  /* NOTE:  the gpio-vbus device may *NOT* be hotplugged */
> >>
> >>  MODULE_ALIAS("platform:gpio-vbus");
> >> @@ -337,6 +365,10 @@ static struct platform_driver gpio_vbus_driver = {
> >>  		.owner = THIS_MODULE,
> >>  	},
> >>  	.remove  = __exit_p(gpio_vbus_remove),
> >> +#ifdef CONFIG_PM
> >> +	.suspend	= gpio_vbus_suspend,
> >> +	.resume		= gpio_vbus_resume
> >> +#endif
> >
> > also, avoid the ifdef on the driver structure.
> 
> Ack. Was just C&P from gpio-vbus, but it's not an excuse
> to follow bad style.

see what e.g the musb driver does to avoid the ifdef
(drivers/usb/musb/musb_core.c)

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110622/53a18614/attachment.sig>

  reply	other threads:[~2011-06-22 14:01 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-22 12:20 [PATCH 1/2] gpio-vbus: support disabling D+ pullup on suspend Dmitry Eremin-Solenikov
2011-06-22 12:20 ` [PATCH 2/2] mioa701: move gpio-pullup functionality to gpio-vbus Dmitry Eremin-Solenikov
2011-06-22 12:40   ` Dmitry Eremin-Solenikov
2011-06-22 13:23 ` [PATCH 1/2] gpio-vbus: support disabling D+ pullup on suspend Felipe Balbi
2011-06-22 13:52   ` Dmitry Eremin-Solenikov
2011-06-22 14:01     ` Felipe Balbi [this message]
2011-06-22 14:15       ` Dmitry Eremin-Solenikov
2011-06-22 14:20         ` Felipe Balbi
2011-06-22 14:26           ` Dmitry Eremin-Solenikov
2011-06-22 14:30             ` Felipe Balbi
2011-06-22 14:30   ` Alan Stern
2011-06-22 14:32     ` Felipe Balbi
2011-06-22 15:02       ` Alan Stern
2011-06-22 15:19         ` Felipe Balbi
2011-06-25  9:26           ` Robert Jarzmik
2011-06-25 10:33             ` Dmitry Eremin-Solenikov
2011-06-25 12:02             ` Alan Stern
2011-06-27 20:39               ` Robert Jarzmik
2011-06-28  2:41             ` Peter Chen

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=20110622140127.GB27654@legolas.emea.dhcp.ti.com \
    --to=balbi@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).