All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <20110124210833.GK29925@opensource.wolfsonmicro.com>

diff --git a/a/1.txt b/N1/1.txt
index 233f421..d684674 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -30,7 +30,7 @@ runtime management than this stuff.
 
 > > It sounds like for your systems what's happening is that the resume is
 > > restoring the previously configured voltages for the core rails rather
-> > than going to a known good state. ?Is my understanding correct here?
+> > than going to a known good state.  Is my understanding correct here?
 > > While your fix is good and I don't see any reason not to do it this does
 > > sound like something we should have a solution for in common code as I'd
 > > not be surprised if there were other hardware out there which did a
diff --git a/a/content_digest b/N1/content_digest
index b32d3e4..694e903 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -6,10 +6,16 @@
  "ref\0AANLkTikOEm=watbA1G-SFK3PZrntDc+Wun84nGio=YKv@mail.gmail.com\0"
  "ref\020110124202610.GJ29925@opensource.wolfsonmicro.com\0"
  "ref\0AANLkTinY5mJtC2fiV1iBnPbgwH9v3AmQQ7RR3pYJVACL@mail.gmail.com\0"
- "From\0broonie@opensource.wolfsonmicro.com (Mark Brown)\0"
- "Subject\0[PATCH v2 20/28] ARM: tegra: cpufreq: Disable cpufreq during suspend\0"
+ "From\0Mark Brown <broonie@opensource.wolfsonmicro.com>\0"
+ "Subject\0Re: [PATCH v2 20/28] ARM: tegra: cpufreq: Disable cpufreq during suspend\0"
  "Date\0Mon, 24 Jan 2011 21:08:34 +0000\0"
- "To\0linux-arm-kernel@lists.infradead.org\0"
+ "To\0Colin Cross <ccross@android.com>\0"
+ "Cc\0linux-tegra@vger.kernel.org"
+  Russell King <linux@arm.linux.org.uk>
+  konkers@android.com
+  linux-kernel@vger.kernel.org
+  olof@lixom.net
+ " linux-arm-kernel@lists.infradead.org\0"
  "\00:1\0"
  "b\0"
  "On Mon, Jan 24, 2011 at 12:52:51PM -0800, Colin Cross wrote:\n"
@@ -44,7 +50,7 @@
  "\n"
  "> > It sounds like for your systems what's happening is that the resume is\n"
  "> > restoring the previously configured voltages for the core rails rather\n"
- "> > than going to a known good state. ?Is my understanding correct here?\n"
+ "> > than going to a known good state. \302\240Is my understanding correct here?\n"
  "> > While your fix is good and I don't see any reason not to do it this does\n"
  "> > sound like something we should have a solution for in common code as I'd\n"
  "> > not be surprised if there were other hardware out there which did a\n"
@@ -61,4 +67,4 @@
  "off base there, most of the regulator API stuff has been done with\n"
  integrated PMICs.
 
-eefb55e96459d0c6695f65ce4270fc48ab7c3ff2b8d4e3ad3a6b5529834fe1ca
+0210dc23f6258662d4179dcd0969e9912c2b73ac96aa95420fbf6046568b2a77

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.