From: Mark Brown <broonie@kernel.org>
To: Claudiu.Beznea@microchip.com
Cc: Nicolas.Ferre@microchip.com, alexandre.belloni@bootlin.com,
Ludovic.Desroches@microchip.com, linux@armlinux.org.uk,
lgirdwood@gmail.com, rjw@rjwysocki.net, pavel@ucw.cz,
len.brown@intel.com, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org
Subject: Re: [PATCH v2 2/3] regulator: core: add helper to check if regulator is disabled in suspend
Date: Fri, 11 Jan 2019 12:39:13 +0000 [thread overview]
Message-ID: <20190111123913.GA2804@sirena.org.uk> (raw)
In-Reply-To: <76298993-c1e8-1b00-6a54-5d41c48bc2d3@microchip.com>
[-- Attachment #1: Type: text/plain, Size: 1303 bytes --]
On Thu, Jan 10, 2019 at 10:24:26AM +0000, Claudiu.Beznea@microchip.com wrote:
> On 09.01.2019 18:57, Mark Brown wrote:
> > regulator state which feels fragile. But based on the cover letter
> > that's kind of like what the initial proposal about target states was so
> > perhaps this is the way we end up going...
> Are you talking about [1] ?
I can't follow that link right now, I'm working offline.
> I can get rid of this patch, take advantage of [3] and [4] and introduce
> also the regulator standby states. In this case, no matter the mapping b/w
> Linux power saving modes and AT91 SoC's power saving modes, we will be
> covered on misconfiguration (at least on SAMA5D2 Xplained board).
> And in patch 3/3 I could get rid of regulator checks and rely on DT (bad
> thing would be that in case of no input for regulator's state in
> mem/standby the board could not properly suspended/resumed), if any.
> What do you think about this?
Like I say I'm working offline so I can't check the links but it sounds
like you're saying that the existing suspend mode configuration features
are enough for your systems? If so that's great - certainly what you're
saying above sounds sensible to me but it's possible I misunderstood
something based on not having the links.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org>
To: Claudiu.Beznea@microchip.com
Cc: len.brown@intel.com, alexandre.belloni@bootlin.com,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
rjw@rjwysocki.net, lgirdwood@gmail.com,
Ludovic.Desroches@microchip.com, pavel@ucw.cz,
linux@armlinux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 2/3] regulator: core: add helper to check if regulator is disabled in suspend
Date: Fri, 11 Jan 2019 12:39:13 +0000 [thread overview]
Message-ID: <20190111123913.GA2804@sirena.org.uk> (raw)
In-Reply-To: <76298993-c1e8-1b00-6a54-5d41c48bc2d3@microchip.com>
[-- Attachment #1.1: Type: text/plain, Size: 1303 bytes --]
On Thu, Jan 10, 2019 at 10:24:26AM +0000, Claudiu.Beznea@microchip.com wrote:
> On 09.01.2019 18:57, Mark Brown wrote:
> > regulator state which feels fragile. But based on the cover letter
> > that's kind of like what the initial proposal about target states was so
> > perhaps this is the way we end up going...
> Are you talking about [1] ?
I can't follow that link right now, I'm working offline.
> I can get rid of this patch, take advantage of [3] and [4] and introduce
> also the regulator standby states. In this case, no matter the mapping b/w
> Linux power saving modes and AT91 SoC's power saving modes, we will be
> covered on misconfiguration (at least on SAMA5D2 Xplained board).
> And in patch 3/3 I could get rid of regulator checks and rely on DT (bad
> thing would be that in case of no input for regulator's state in
> mem/standby the board could not properly suspended/resumed), if any.
> What do you think about this?
Like I say I'm working offline so I can't check the links but it sounds
like you're saying that the existing suspend mode configuration features
are enough for your systems? If so that's great - certainly what you're
saying above sounds sensible to me but it's possible I misunderstood
something based on not having the links.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-01-11 12:39 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-08 10:56 [PATCH v2 0/3] add support for power off check in suspend Claudiu.Beznea
2019-01-08 10:56 ` Claudiu.Beznea
2019-01-08 10:56 ` [PATCH v2 1/3] PM / Suspend: Add support to check if platform's power is off " Claudiu.Beznea
2019-01-08 10:56 ` Claudiu.Beznea
2019-01-09 14:14 ` Pavel Machek
2019-01-09 14:14 ` Pavel Machek
2019-01-10 10:24 ` Claudiu.Beznea
2019-01-10 10:24 ` Claudiu.Beznea
2019-01-08 10:56 ` [PATCH v2 2/3] regulator: core: add helper to check if regulator is disabled " Claudiu.Beznea
2019-01-08 10:56 ` Claudiu.Beznea
2019-01-09 16:57 ` Mark Brown
2019-01-10 10:24 ` Claudiu.Beznea
2019-01-10 10:24 ` Claudiu.Beznea
2019-01-11 12:39 ` Mark Brown [this message]
2019-01-11 12:39 ` Mark Brown
2019-01-11 14:08 ` Claudiu.Beznea
2019-01-11 14:08 ` Claudiu.Beznea
2019-01-14 22:53 ` Mark Brown
2019-01-15 9:19 ` Claudiu.Beznea
2019-01-15 9:19 ` Claudiu.Beznea
2019-01-08 10:56 ` [PATCH v2 3/3] ARM: at91: pm: add support for .off_in_suspend Claudiu.Beznea
2019-01-08 10:56 ` Claudiu.Beznea
2019-01-08 11:46 ` [PATCH v2 0/3] add support for power off check in suspend Rafael J. Wysocki
2019-01-08 11:46 ` Rafael J. Wysocki
2019-01-08 14:07 ` Claudiu.Beznea
2019-01-08 14:07 ` Claudiu.Beznea
2019-01-28 9:50 ` Claudiu.Beznea
2019-01-28 9:50 ` Claudiu.Beznea
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=20190111123913.GA2804@sirena.org.uk \
--to=broonie@kernel.org \
--cc=Claudiu.Beznea@microchip.com \
--cc=Ludovic.Desroches@microchip.com \
--cc=Nicolas.Ferre@microchip.com \
--cc=alexandre.belloni@bootlin.com \
--cc=len.brown@intel.com \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=pavel@ucw.cz \
--cc=rjw@rjwysocki.net \
/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.