All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <1493932034.25397.37.camel@buserror.net>

diff --git a/a/1.txt b/N1/1.txt
index cc8f689..90d21ed 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,19 +1,19 @@
 On Thu, 2017-05-04 at 06:58 +0200, Karim Eshapa wrote:
 > +	stop = jiffies + 10000;
 > +	/*
-> +	 * if MR was full and h/w had other FQRNI entries to produce, we
-> +	 * need to allow it time to produce those entries once the
-> +	 * existing entries are consumed. A worst-case situation
-> +	 * (fully-loaded system) means h/w sequencers may have to do 3-4
-> +	 * other things before servicing the portal's MR pump, each of
-> +	 * which (if slow) may take ~50 qman cycles (which is ~200
-> +	 * processor cycles). So rounding up and then multiplying this
-> +	 * worst-case estimate by a factor of 10, just to be
-> +	 * ultra-paranoid, goes as high as 10,000 cycles. NB, we consume
-> +	 * one entry at a time, so h/w has an opportunity to produce new
-> +	 * entries well before the ring has been fully consumed, so
-> +	 * we're being *really* paranoid here.
-> +	 */
+> +	?* if MR was full and h/w had other FQRNI entries to produce, we
+> +	?* need to allow it time to produce those entries once the
+> +	?* existing entries are consumed. A worst-case situation
+> +	?* (fully-loaded system) means h/w sequencers may have to do 3-4
+> +	?* other things before servicing the portal's MR pump, each of
+> +	?* which (if slow) may take ~50 qman cycles (which is ~200
+> +	?* processor cycles). So rounding up and then multiplying this
+> +	?* worst-case estimate by a factor of 10, just to be
+> +	?* ultra-paranoid, goes as high as 10,000 cycles. NB, we consume
+> +	?* one entry at a time, so h/w has an opportunity to produce new
+> +	?* entries well before the ring has been fully consumed, so
+> +	?* we're being *really* paranoid here.
+> +	?*/
 
 OK, upon reading this more closely it seems the intent was to delay for 10,000
 *processor cycles* and somehow that got turned into 10,000 jiffies (which is
diff --git a/a/content_digest b/N1/content_digest
index 57b2461..22d3c9f 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -1,33 +1,27 @@
  "ref\01493508775.25397.26.camel@buserror.net\0"
  "ref\01493873917-7484-1-git-send-email-karim.eshapa@gmail.com\0"
- "From\0Scott Wood <oss@buserror.net>\0"
- "Subject\0Re: [PATCH v2] drivers:soc:fsl:qbman:qman.c: Sleep instead of stuck hacking jiffies.\0"
+ "From\0oss@buserror.net (Scott Wood)\0"
+ "Subject\0[PATCH v2] drivers:soc:fsl:qbman:qman.c: Sleep instead of stuck hacking jiffies.\0"
  "Date\0Thu, 04 May 2017 16:07:14 -0500\0"
- "To\0Karim Eshapa <karim.eshapa@gmail.com>\0"
- "Cc\0claudiu.manoil@nxp.com"
-  roy.pledge@nxp.com
-  colin.king@canonical.com
-  linuxppc-dev@lists.ozlabs.org
-  linux-arm-kernel@lists.infradead.org
- " linux-kernel@vger.kernel.org\0"
+ "To\0linux-arm-kernel@lists.infradead.org\0"
  "\00:1\0"
  "b\0"
  "On Thu, 2017-05-04 at 06:58 +0200, Karim Eshapa wrote:\n"
  "> +\tstop = jiffies + 10000;\n"
  "> +\t/*\n"
- "> +\t\302\240* if MR was full and h/w had other FQRNI entries to produce, we\n"
- "> +\t\302\240* need to allow it time to produce those entries once the\n"
- "> +\t\302\240* existing entries are consumed. A worst-case situation\n"
- "> +\t\302\240* (fully-loaded system) means h/w sequencers may have to do 3-4\n"
- "> +\t\302\240* other things before servicing the portal's MR pump, each of\n"
- "> +\t\302\240* which (if slow) may take ~50 qman cycles (which is ~200\n"
- "> +\t\302\240* processor cycles). So rounding up and then multiplying this\n"
- "> +\t\302\240* worst-case estimate by a factor of 10, just to be\n"
- "> +\t\302\240* ultra-paranoid, goes as high as 10,000 cycles. NB, we consume\n"
- "> +\t\302\240* one entry at a time, so h/w has an opportunity to produce new\n"
- "> +\t\302\240* entries well before the ring has been fully consumed, so\n"
- "> +\t\302\240* we're being *really* paranoid here.\n"
- "> +\t\302\240*/\n"
+ "> +\t?* if MR was full and h/w had other FQRNI entries to produce, we\n"
+ "> +\t?* need to allow it time to produce those entries once the\n"
+ "> +\t?* existing entries are consumed. A worst-case situation\n"
+ "> +\t?* (fully-loaded system) means h/w sequencers may have to do 3-4\n"
+ "> +\t?* other things before servicing the portal's MR pump, each of\n"
+ "> +\t?* which (if slow) may take ~50 qman cycles (which is ~200\n"
+ "> +\t?* processor cycles). So rounding up and then multiplying this\n"
+ "> +\t?* worst-case estimate by a factor of 10, just to be\n"
+ "> +\t?* ultra-paranoid, goes as high as 10,000 cycles. NB, we consume\n"
+ "> +\t?* one entry at a time, so h/w has an opportunity to produce new\n"
+ "> +\t?* entries well before the ring has been fully consumed, so\n"
+ "> +\t?* we're being *really* paranoid here.\n"
+ "> +\t?*/\n"
  "\n"
  "OK, upon reading this more closely it seems the intent was to delay for 10,000\n"
  "*processor cycles* and somehow that got turned into 10,000 jiffies (which is\n"
@@ -38,4 +32,4 @@
  "\n"
  -Scott
 
-0e9f2ec4c11bf2b961420adeca888eadae14301517461511c37681047486523e
+237681a6975914da3d7a7c33dd35a224ed50f2955b6ab818e5dd79f392f6e8a8

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.