All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <87hb86a5mm.fsf@ti.com>

diff --git a/a/1.txt b/N1/1.txt
index 636b8a9..d7673e0 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -27,7 +27,7 @@ Tomi Valkeinen <tomi.valkeinen@ti.com> writes:
 >
 > Yes, the counter. I don't think
 >
-> if (dispc.runtime_count++ = 0)
+> if (dispc.runtime_count++ == 0)
 >
 > is thread safe.
 
@@ -35,7 +35,7 @@ OK, if it's just the counter, you can drop the mutex and use an atomic
 variable and use atomic_inc(), atomic_dec() etc.  Then it will be clear
 from reading what exactly is protected.
 
->> > +	if (dispc.runtime_count++ = 0) {
+>> > +	if (dispc.runtime_count++ == 0) {
 >> 
 >> You shouldn't need your own use-counting here.  The runtime PM core is
 >> already doing usage counting.
@@ -64,7 +64,7 @@ Sorry about that.
 
 Just to clarify, what exactly does the opt clock have to be enabled for?
 
-From what I can gather, this particular opt clock has to be enabled for
+>From what I can gather, this particular opt clock has to be enabled for
 the hwmod itself to be enabled (or disabled), correct?
 
 This has been a known issue for reset[1], but I wasn't aware that it was
@@ -122,7 +122,7 @@ clocks in the hwmod enable/idle path.  We're doing it for reset[1], but
 not for anything else.  And based on the changelog there[1], it doesn't
 even sound like we fully understand the exact requirements around reset.
 
-From the contortions you've had to go through though, it sounds like the
+>From the contortions you've had to go through though, it sounds like the
 same optional clocks that are needed for reset are needed for a "normal"
 module enable/disable.
 
@@ -189,7 +189,7 @@ Now I'll wait for Benoit/Paul to enlighten us.
 >> > +{
 >> > +	mutex_lock(&dispc.runtime_lock);
 >> > +
->> > +	if (--dispc.runtime_count = 0) {
+>> > +	if (--dispc.runtime_count == 0) {
 >> > +		int r;
 >> 
 >> Same problem here.  
@@ -243,7 +243,7 @@ Date:   Tue Sep 21 18:57:58 2010 +0200
 
 
 [2]
-From d2806a4148fbed869eff8703b1137cd35d16ef53 Mon Sep 17 00:00:00 2001
+>From d2806a4148fbed869eff8703b1137cd35d16ef53 Mon Sep 17 00:00:00 2001
 From: Kevin Hilman <khilman@ti.com>
 Date: Fri, 3 Jun 2011 15:33:25 -0700
 Subject: [PATCH] OMAP2+: omap_hwmod: selectively manage optional clocks in enable/disable
diff --git a/a/content_digest b/N1/content_digest
index 99747ab..6613243 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -4,7 +4,7 @@
  "ref\01307122985.2016.72.camel@deskari\0"
  "From\0Kevin Hilman <khilman@ti.com>\0"
  "Subject\0Re: [PATCH 19/27] OMAP: DSS2: Use PM runtime & HWMOD support\0"
- "Date\0Fri, 03 Jun 2011 22:53:53 +0000\0"
+ "Date\0Fri, 03 Jun 2011 15:53:53 -0700\0"
  "To\0Tomi Valkeinen <tomi.valkeinen@ti.com>\0"
  "Cc\0linux-omap@vger.kernel.org"
   linux-fbdev@vger.kernel.org
@@ -41,7 +41,7 @@
  ">\n"
  "> Yes, the counter. I don't think\n"
  ">\n"
- "> if (dispc.runtime_count++ = 0)\n"
+ "> if (dispc.runtime_count++ == 0)\n"
  ">\n"
  "> is thread safe.\n"
  "\n"
@@ -49,7 +49,7 @@
  "variable and use atomic_inc(), atomic_dec() etc.  Then it will be clear\n"
  "from reading what exactly is protected.\n"
  "\n"
- ">> > +\tif (dispc.runtime_count++ = 0) {\n"
+ ">> > +\tif (dispc.runtime_count++ == 0) {\n"
  ">> \n"
  ">> You shouldn't need your own use-counting here.  The runtime PM core is\n"
  ">> already doing usage counting.\n"
@@ -78,7 +78,7 @@
  "\n"
  "Just to clarify, what exactly does the opt clock have to be enabled for?\n"
  "\n"
- "From what I can gather, this particular opt clock has to be enabled for\n"
+ ">From what I can gather, this particular opt clock has to be enabled for\n"
  "the hwmod itself to be enabled (or disabled), correct?\n"
  "\n"
  "This has been a known issue for reset[1], but I wasn't aware that it was\n"
@@ -136,7 +136,7 @@
  "not for anything else.  And based on the changelog there[1], it doesn't\n"
  "even sound like we fully understand the exact requirements around reset.\n"
  "\n"
- "From the contortions you've had to go through though, it sounds like the\n"
+ ">From the contortions you've had to go through though, it sounds like the\n"
  "same optional clocks that are needed for reset are needed for a \"normal\"\n"
  "module enable/disable.\n"
  "\n"
@@ -203,7 +203,7 @@
  ">> > +{\n"
  ">> > +\tmutex_lock(&dispc.runtime_lock);\n"
  ">> > +\n"
- ">> > +\tif (--dispc.runtime_count = 0) {\n"
+ ">> > +\tif (--dispc.runtime_count == 0) {\n"
  ">> > +\t\tint r;\n"
  ">> \n"
  ">> Same problem here.  \n"
@@ -257,7 +257,7 @@
  "\n"
  "\n"
  "[2]\n"
- "From d2806a4148fbed869eff8703b1137cd35d16ef53 Mon Sep 17 00:00:00 2001\n"
+ ">From d2806a4148fbed869eff8703b1137cd35d16ef53 Mon Sep 17 00:00:00 2001\n"
  "From: Kevin Hilman <khilman@ti.com>\n"
  "Date: Fri, 3 Jun 2011 15:33:25 -0700\n"
  "Subject: [PATCH] OMAP2+: omap_hwmod: selectively manage optional clocks in enable/disable\n"
@@ -304,4 +304,4 @@
  "-- \n"
  1.7.4
 
-d1c928a420c4cfb2f413c5cbb910edef1d4eaaecdb53e73c78f39126251bddb4
+a8ffb69931e68f6124154aaaba9ef6d16490f32d2f93822d714f4ede39e8fb82

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.