linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Marco Felsch <m.felsch@pengutronix.de>
Cc: devicetree@vger.kernel.org, alexandre.belloni@bootlin.com,
	simon.budig@kernelconcepts.de, mripard@kernel.org,
	bparrot@ti.com, hdegoede@redhat.com, andy.shevchenko@gmail.com,
	robh+dt@kernel.org, kernel@pengutronix.de,
	linux-input@vger.kernel.org, andriy.shevchenko@linux.intel.com,
	shawnguo@kernel.org, fcooper@ti.com
Subject: Re: [PATCH v3 6/6] Input: edt-ft5x06 - improve power management operations
Date: Tue, 21 Jan 2020 22:00:17 -0800	[thread overview]
Message-ID: <20200122060017.GC110084@dtor-ws> (raw)
In-Reply-To: <20200116133219.xtp3wkkcefbcumca@pengutronix.de>

Hi Marco,

On Thu, Jan 16, 2020 at 02:32:19PM +0100, Marco Felsch wrote:
> Hi Dmitry,
> 
> On 20-01-10 08:18, Marco Felsch wrote:
> > On 20-01-10 08:16, Marco Felsch wrote:
> > > Hi Dmitry,
> > > 
> > > On 20-01-09 17:09, Dmitry Torokhov wrote:
> > > > Hi Marco,
> > > > 
> > > > On Wed, Jan 08, 2020 at 12:10:50PM +0100, Marco Felsch wrote:
> > > > > +static int __maybe_unused edt_ft5x06_ts_resume(struct device *dev)
> > > > > +{
> > > > > +	struct i2c_client *client = to_i2c_client(dev);
> > > > > +	struct edt_ft5x06_ts_data *tsdata = i2c_get_clientdata(client);
> > > > > +	int ret;
> > > > > +
> > > > > +	if (device_may_wakeup(dev))
> > > > > +		return 0;
> > > > > +
> > > > > +	ret = regulator_enable(tsdata->vcc);
> > > > > +	if (ret)
> > > > > +		dev_warn(dev, "Failed to enable vcc\n");
> > > > 
> > > > I wonder if we should not return error here instead of continuing. If
> > > > device is not powered up properly we'll have hard time communicating
> > > > with it.
> > > 
> > > That's a reasonable point.
> > > 
> > > > The same is for suspend: maybe we should abort if we can't switch off
> > > > regulator or write to the device.
> > > 
> > > I have no strong opinion about that case but IMHO it's okay to go further
> > > if we can't switch it off. Instead we should print a warning.
> > 
> > I just noticed that we do that already.. So the suspend case should be
> > okay.
> 
> 
> Is it okay to check the return val for the resume case only? I want to
> prepare a v4 of this patch to get this done.

OK, I now remember my issues with power management in this driver. It
supports factory mode vs operational/normal mode, and updating register
settings at runtime. If you want to cut power off at suspend, then you
need to make sure you restore the mode and register settings at resume
time, not simply revert to normal mode.

Thanks.

-- 
Dmitry

      reply	other threads:[~2020-01-22  6:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-08 11:10 [PATCH v3 0/6] EDT-FT5x06 improvements Marco Felsch
2020-01-08 11:10 ` [PATCH v3 1/6] Input: edt-ft5x06: work around first register access error Marco Felsch
2020-01-10  1:06   ` Dmitry Torokhov
2020-01-08 11:10 ` [PATCH v3 2/6] Input: edt-ft5x06 - alphabetical include reorder Marco Felsch
2020-01-10  1:06   ` Dmitry Torokhov
2020-01-08 11:10 ` [PATCH v3 3/6] dt-bindings: Input: edt-ft5x06 - document wakeup-source capability Marco Felsch
2020-01-10  1:07   ` Dmitry Torokhov
2020-01-08 11:10 ` [PATCH v3 4/6] Input: edt-ft5x06 - make wakeup-source switchable Marco Felsch
2020-01-10  1:07   ` Dmitry Torokhov
2020-01-08 11:10 ` [PATCH v3 5/6] Input: edt-ft5x06 - use pm core to enable/disable the wake irq Marco Felsch
2020-01-10  1:07   ` Dmitry Torokhov
2020-01-08 11:10 ` [PATCH v3 6/6] Input: edt-ft5x06 - improve power management operations Marco Felsch
2020-01-10  1:09   ` Dmitry Torokhov
2020-01-10  7:16     ` Marco Felsch
2020-01-10  7:18       ` Marco Felsch
2020-01-16 13:32         ` Marco Felsch
2020-01-22  6:00           ` Dmitry Torokhov [this message]

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=20200122060017.GC110084@dtor-ws \
    --to=dmitry.torokhov@gmail.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=bparrot@ti.com \
    --cc=devicetree@vger.kernel.org \
    --cc=fcooper@ti.com \
    --cc=hdegoede@redhat.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-input@vger.kernel.org \
    --cc=m.felsch@pengutronix.de \
    --cc=mripard@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=shawnguo@kernel.org \
    --cc=simon.budig@kernelconcepts.de \
    /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).