diff for duplicates of <AANLkTikOEm=watbA1G-SFK3PZrntDc+Wun84nGio=YKv@mail.gmail.com>
diff --git a/a/1.txt b/N1/1.txt
index a2834a1..99c21e6 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -4,24 +4,24 @@ On Mon, Jan 24, 2011 at 11:35 AM, Mark Brown
>> On Mon, Jan 24, 2011 at 6:41 AM, Mark Brown
>
>> > Hrm, what's the situation where that happens and why does it cause
->> > problems? The regulator API doesn't care if suspend is going on, and
->> > nor do any of the current drivers for regulators. There is an issue
+>> > problems? ?The regulator API doesn't care if suspend is going on, and
+>> > nor do any of the current drivers for regulators. ?There is an issue
>> > with keeping things like I2C alive until the bitter end of suspend so
>> > you've got a control bus to the regulators but that's a generic issue
>> > which crops up with other subsystems too so a regulator-specific
>> > workaround seems dodgy.
>
>> The end result is that the regulator driver calls the i2c driver after
->> the i2c driver has been suspended. On Tegra, this happens because of
->> voltage scaling on the CPU regulator, which can be on the i2c bus. A
+>> the i2c driver has been suspended. ?On Tegra, this happens because of
+>> voltage scaling on the CPU regulator, which can be on the i2c bus. ?A
>> sleep in a suspend handler after the i2c bus has been suspended can
>> cause the cpufreq governor to lower the frequency, and try to lower
>> the voltage as well.
>
> OK, that's a general problem - you need to ensure that the I2C and SPI
-> controllers are suspended really late. The OMAP guys also have this
+> controllers are suspended really late. ?The OMAP guys also have this
> problem for some RTCs, though in their case things are slightly
-> different due to their use of runtime PM. Looking at your I2C driver
+> different due to their use of runtime PM. ?Looking at your I2C driver
> (BTW, I'd suggest reminding Ben on a more regular basis about that) I
> suspect that moving your suspend and resume callbacks to the _noirq
> varaints will cover a lot of this.
@@ -30,7 +30,7 @@ Even _noirq isn't late enough, if cpufreq keeps trying to change the
frequency (and thus voltage) until sysdev suspend.
>> The problem isn't limited to i2c busses, there are some regulators on
->> spi busses. You would need to ensure that any driver that has a
+>> spi busses. ?You would need to ensure that any driver that has a
>
> For all practical purposes in this sort of discussion you can typically
> do a s/I2C/I2C and SPI/ - in terms of system integration issues they're
@@ -43,11 +43,11 @@ True
>> sysdev suspend handler.
>
> So you actively need to push the processor into low power mode during
-> suspend? I'm still not 100% clear what's triggering the issues you're
-> seeing and why this seems to be Tegra-only. If there were a general
+> suspend? ?I'm still not 100% clear what's triggering the issues you're
+> seeing and why this seems to be Tegra-only. ?If there were a general
> cpufreq/regulator interaction here I'd expect to see all ARM cpufreq
> drivers needing to do the same thing (and probably some handling of this
-> in cpufreq core as a result). If it's not such an issue I'd expect
+> in cpufreq core as a result). ?If it's not such an issue I'd expect
> there's also entertaining suspend ordering issues elsewhere.
It's more of a voltage scaling issue than a cpufreq issue directly.
@@ -61,7 +61,7 @@ to go to frequencies that are not supported by the suspend voltage.
> they're active by the time I2C is off they normally get suspended by
> hardware handshakes from the CPU as that enters low power mode - right
> now we have no regulators at all in mainline that do anything in
-> software on suspend. We can get a long way by just ignoring what
+> software on suspend. ?We can get a long way by just ignoring what
> happens to regulators over suspend (there is some work to do here but
> it's orthogonal to this sort of issue).
diff --git a/a/content_digest b/N1/content_digest
index 8eae6e0..8822fba 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -14,24 +14,16 @@
"ref\00020110124193539.GI29925\@opensource.wolfsonmicro.com\0"
]
[
- "From\0Colin Cross <ccross\@android.com>\0"
+ "From\0ccross\@android.com (Colin Cross)\0"
]
[
- "Subject\0Re: [PATCH v2 20/28] ARM: tegra: cpufreq: Disable cpufreq during suspend\0"
+ "Subject\0[PATCH v2 20/28] ARM: tegra: cpufreq: Disable cpufreq during suspend\0"
]
[
"Date\0Mon, 24 Jan 2011 11:52:12 -0800\0"
]
[
- "To\0Mark Brown <broonie\@opensource.wolfsonmicro.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"
+ "To\0linux-arm-kernel\@lists.infradead.org\0"
]
[
"\0000:1\0"
@@ -46,24 +38,24 @@
">> On Mon, Jan 24, 2011 at 6:41 AM, Mark Brown\n",
">\n",
">> > Hrm, what's the situation where that happens and why does it cause\n",
- ">> > problems? \302\240The regulator API doesn't care if suspend is going on, and\n",
- ">> > nor do any of the current drivers for regulators. \302\240There is an issue\n",
+ ">> > problems? ?The regulator API doesn't care if suspend is going on, and\n",
+ ">> > nor do any of the current drivers for regulators. ?There is an issue\n",
">> > with keeping things like I2C alive until the bitter end of suspend so\n",
">> > you've got a control bus to the regulators but that's a generic issue\n",
">> > which crops up with other subsystems too so a regulator-specific\n",
">> > workaround seems dodgy.\n",
">\n",
">> The end result is that the regulator driver calls the i2c driver after\n",
- ">> the i2c driver has been suspended. \302\240On Tegra, this happens because of\n",
- ">> voltage scaling on the CPU regulator, which can be on the i2c bus. \302\240A\n",
+ ">> the i2c driver has been suspended. ?On Tegra, this happens because of\n",
+ ">> voltage scaling on the CPU regulator, which can be on the i2c bus. ?A\n",
">> sleep in a suspend handler after the i2c bus has been suspended can\n",
">> cause the cpufreq governor to lower the frequency, and try to lower\n",
">> the voltage as well.\n",
">\n",
"> OK, that's a general problem - you need to ensure that the I2C and SPI\n",
- "> controllers are suspended really late. \302\240The OMAP guys also have this\n",
+ "> controllers are suspended really late. ?The OMAP guys also have this\n",
"> problem for some RTCs, though in their case things are slightly\n",
- "> different due to their use of runtime PM. \302\240Looking at your I2C driver\n",
+ "> different due to their use of runtime PM. ?Looking at your I2C driver\n",
"> (BTW, I'd suggest reminding Ben on a more regular basis about that) I\n",
"> suspect that moving your suspend and resume callbacks to the _noirq\n",
"> varaints will cover a lot of this.\n",
@@ -72,7 +64,7 @@
"frequency (and thus voltage) until sysdev suspend.\n",
"\n",
">> The problem isn't limited to i2c busses, there are some regulators on\n",
- ">> spi busses. \302\240You would need to ensure that any driver that has a\n",
+ ">> spi busses. ?You would need to ensure that any driver that has a\n",
">\n",
"> For all practical purposes in this sort of discussion you can typically\n",
"> do a s/I2C/I2C and SPI/ - in terms of system integration issues they're\n",
@@ -85,11 +77,11 @@
">> sysdev suspend handler.\n",
">\n",
"> So you actively need to push the processor into low power mode during\n",
- "> suspend? \302\240I'm still not 100% clear what's triggering the issues you're\n",
- "> seeing and why this seems to be Tegra-only. \302\240If there were a general\n",
+ "> suspend? ?I'm still not 100% clear what's triggering the issues you're\n",
+ "> seeing and why this seems to be Tegra-only. ?If there were a general\n",
"> cpufreq/regulator interaction here I'd expect to see all ARM cpufreq\n",
"> drivers needing to do the same thing (and probably some handling of this\n",
- "> in cpufreq core as a result). \302\240If it's not such an issue I'd expect\n",
+ "> in cpufreq core as a result). ?If it's not such an issue I'd expect\n",
"> there's also entertaining suspend ordering issues elsewhere.\n",
"\n",
"It's more of a voltage scaling issue than a cpufreq issue directly.\n",
@@ -103,7 +95,7 @@
"> they're active by the time I2C is off they normally get suspended by\n",
"> hardware handshakes from the CPU as that enters low power mode - right\n",
"> now we have no regulators at all in mainline that do anything in\n",
- "> software on suspend. \302\240We can get a long way by just ignoring what\n",
+ "> software on suspend. ?We can get a long way by just ignoring what\n",
"> happens to regulators over suspend (there is some work to do here but\n",
"> it's orthogonal to this sort of issue).\n",
"\n",
@@ -112,4 +104,4 @@
"something needs to tell the regulator to go to the correct voltage."
]
-0e36767eda27ebe2ca880881d104dd7e474f7ddf55cc0ad041d96615228f4368
+1bb311fec39bdb9ba98eacdedb353638a903ff46cc483b9724559a007a5b58f3
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.