All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <1491774092.4166.195.camel@kernel.crashing.org>

diff --git a/a/1.txt b/N1/1.txt
index b344f3d..3117d9c 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,12 +1,12 @@
 On Sun, 2017-04-09 at 16:22 -0500, Christopher Bostic wrote:
-> A 3 microsecond delay is required, however, to prevent occasional issues?
+> A 3 microsecond delay is required, however, to prevent occasional issues 
 > during heavy FSI bus load stress testing.
-> A 1 nanosecond delay using ndelay(1) had been specified prior to this?
-> but after looking more closely at real time performance it turned out to?
-> actually be roughly 1-2 microseconds.?? This appears to be the minimum?
-> resolution using the delay() linux libraries on the AST2400/2500.???
-> Given this, increasing delay to 3 microseconds doesn't impact?
-> performance much considering I can now remove the sample input delay?
+> A 1 nanosecond delay using ndelay(1) had been specified prior to this 
+> but after looking more closely at real time performance it turned out to 
+> actually be roughly 1-2 microseconds.   This appears to be the minimum 
+> resolution using the delay() linux libraries on the AST2400/2500.   
+> Given this, increasing delay to 3 microseconds doesn't impact 
+> performance much considering I can now remove the sample input delay 
 > based on your recommendations to re-order the two clock delays.
 
 This is huge delays. We should consider a AST2xxx specific variant of
@@ -21,3 +21,8 @@ long enough in the transitions from write to read ?
 
 Cheers,
 Ben.
+
+_______________________________________________
+linux-arm-kernel mailing list
+linux-arm-kernel@lists.infradead.org
+http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
diff --git a/a/content_digest b/N1/content_digest
index 15890fb..0283474 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -6,21 +6,35 @@
  "ref\093b21624-11fc-b71b-aa78-6cb4371c87ae@linux.vnet.ibm.com\0"
  "ref\01491344360.4166.68.camel@kernel.crashing.org\0"
  "ref\05344146a-f450-7959-4688-a83ee022574b@linux.vnet.ibm.com\0"
- "From\0benh@kernel.crashing.org (Benjamin Herrenschmidt)\0"
- "Subject\0[PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master\0"
+ "From\0Benjamin Herrenschmidt <benh@kernel.crashing.org>\0"
+ "Subject\0Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master\0"
  "Date\0Mon, 10 Apr 2017 07:41:32 +1000\0"
- "To\0linux-arm-kernel@lists.infradead.org\0"
+ "To\0Christopher Bostic <cbostic@linux.vnet.ibm.com>"
+ " Joel Stanley <joel@jms.id.au>\0"
+ "Cc\0Mark Rutland <mark.rutland@arm.com>"
+  devicetree@vger.kernel.org
+  Andrew Jeffery <andrew@aj.id.au>
+  Greg KH <gregkh@linuxfoundation.org>
+  Russell King <linux@armlinux.org.uk>
+  rostedt@goodmis.org
+  Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
+  Rob Herring <robh+dt@kernel.org>
+  Jeremy Kerr <jk@ozlabs.org>
+  Edward A . James <eajames@us.ibm.com>
+  Alistair Popple <alistair@popple.id.au>
+  mingo@redhat.com
+ " linux-arm-kernel@lists.infradead.org\0"
  "\00:1\0"
  "b\0"
  "On Sun, 2017-04-09 at 16:22 -0500, Christopher Bostic wrote:\n"
- "> A 3 microsecond delay is required, however, to prevent occasional issues?\n"
+ "> A 3 microsecond delay is required, however, to prevent occasional issues\302\240\n"
  "> during heavy FSI bus load stress testing.\n"
- "> A 1 nanosecond delay using ndelay(1) had been specified prior to this?\n"
- "> but after looking more closely at real time performance it turned out to?\n"
- "> actually be roughly 1-2 microseconds.?? This appears to be the minimum?\n"
- "> resolution using the delay() linux libraries on the AST2400/2500.???\n"
- "> Given this, increasing delay to 3 microseconds doesn't impact?\n"
- "> performance much considering I can now remove the sample input delay?\n"
+ "> A 1 nanosecond delay using ndelay(1) had been specified prior to this\302\240\n"
+ "> but after looking more closely at real time performance it turned out to\302\240\n"
+ "> actually be roughly 1-2 microseconds.\302\240\302\240 This appears to be the minimum\302\240\n"
+ "> resolution using the delay() linux libraries on the AST2400/2500.\302\240\302\240\302\240\n"
+ "> Given this, increasing delay to 3 microseconds doesn't impact\302\240\n"
+ "> performance much considering I can now remove the sample input delay\302\240\n"
  "> based on your recommendations to re-order the two clock delays.\n"
  "\n"
  "This is huge delays. We should consider a AST2xxx specific variant of\n"
@@ -34,6 +48,11 @@
  "long enough in the transitions from write to read ?\n"
  "\n"
  "Cheers,\n"
- Ben.
+ "Ben.\n"
+ "\n"
+ "_______________________________________________\n"
+ "linux-arm-kernel mailing list\n"
+ "linux-arm-kernel@lists.infradead.org\n"
+ http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
 
-3b349b6d59d90357d46f7aa8cd6cd4937089dd20fa8d8f8a57cd23dfe57f6906
+7c4176be7e9285ff252fdf81696ace856d74616ae0f056129e3b6e8f0c14de36

diff --git a/a/1.txt b/N2/1.txt
index b344f3d..d611503 100644
--- a/a/1.txt
+++ b/N2/1.txt
@@ -1,12 +1,12 @@
 On Sun, 2017-04-09 at 16:22 -0500, Christopher Bostic wrote:
-> A 3 microsecond delay is required, however, to prevent occasional issues?
+> A 3 microsecond delay is required, however, to prevent occasional issues 
 > during heavy FSI bus load stress testing.
-> A 1 nanosecond delay using ndelay(1) had been specified prior to this?
-> but after looking more closely at real time performance it turned out to?
-> actually be roughly 1-2 microseconds.?? This appears to be the minimum?
-> resolution using the delay() linux libraries on the AST2400/2500.???
-> Given this, increasing delay to 3 microseconds doesn't impact?
-> performance much considering I can now remove the sample input delay?
+> A 1 nanosecond delay using ndelay(1) had been specified prior to this 
+> but after looking more closely at real time performance it turned out to 
+> actually be roughly 1-2 microseconds.   This appears to be the minimum 
+> resolution using the delay() linux libraries on the AST2400/2500.   
+> Given this, increasing delay to 3 microseconds doesn't impact 
+> performance much considering I can now remove the sample input delay 
 > based on your recommendations to re-order the two clock delays.
 
 This is huge delays. We should consider a AST2xxx specific variant of
diff --git a/a/content_digest b/N2/content_digest
index 15890fb..ad41479 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -6,21 +6,35 @@
  "ref\093b21624-11fc-b71b-aa78-6cb4371c87ae@linux.vnet.ibm.com\0"
  "ref\01491344360.4166.68.camel@kernel.crashing.org\0"
  "ref\05344146a-f450-7959-4688-a83ee022574b@linux.vnet.ibm.com\0"
- "From\0benh@kernel.crashing.org (Benjamin Herrenschmidt)\0"
- "Subject\0[PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master\0"
+ "From\0Benjamin Herrenschmidt <benh@kernel.crashing.org>\0"
+ "Subject\0Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master\0"
  "Date\0Mon, 10 Apr 2017 07:41:32 +1000\0"
- "To\0linux-arm-kernel@lists.infradead.org\0"
+ "To\0Christopher Bostic <cbostic@linux.vnet.ibm.com>"
+ " Joel Stanley <joel@jms.id.au>\0"
+ "Cc\0Rob Herring <robh+dt@kernel.org>"
+  Mark Rutland <mark.rutland@arm.com>
+  Russell King <linux@armlinux.org.uk>
+  rostedt@goodmis.org
+  mingo@redhat.com
+  Greg KH <gregkh@linuxfoundation.org>
+  devicetree@vger.kernel.org
+  linux-arm-kernel@lists.infradead.org
+  Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
+  Andrew Jeffery <andrew@aj.id.au>
+  Alistair Popple <alistair@popple.id.au>
+  Edward A . James <eajames@us.ibm.com>
+ " Jeremy Kerr <jk@ozlabs.org>\0"
  "\00:1\0"
  "b\0"
  "On Sun, 2017-04-09 at 16:22 -0500, Christopher Bostic wrote:\n"
- "> A 3 microsecond delay is required, however, to prevent occasional issues?\n"
+ "> A 3 microsecond delay is required, however, to prevent occasional issues\302\240\n"
  "> during heavy FSI bus load stress testing.\n"
- "> A 1 nanosecond delay using ndelay(1) had been specified prior to this?\n"
- "> but after looking more closely at real time performance it turned out to?\n"
- "> actually be roughly 1-2 microseconds.?? This appears to be the minimum?\n"
- "> resolution using the delay() linux libraries on the AST2400/2500.???\n"
- "> Given this, increasing delay to 3 microseconds doesn't impact?\n"
- "> performance much considering I can now remove the sample input delay?\n"
+ "> A 1 nanosecond delay using ndelay(1) had been specified prior to this\302\240\n"
+ "> but after looking more closely at real time performance it turned out to\302\240\n"
+ "> actually be roughly 1-2 microseconds.\302\240\302\240 This appears to be the minimum\302\240\n"
+ "> resolution using the delay() linux libraries on the AST2400/2500.\302\240\302\240\302\240\n"
+ "> Given this, increasing delay to 3 microseconds doesn't impact\302\240\n"
+ "> performance much considering I can now remove the sample input delay\302\240\n"
  "> based on your recommendations to re-order the two clock delays.\n"
  "\n"
  "This is huge delays. We should consider a AST2xxx specific variant of\n"
@@ -36,4 +50,4 @@
  "Cheers,\n"
  Ben.
 
-3b349b6d59d90357d46f7aa8cd6cd4937089dd20fa8d8f8a57cd23dfe57f6906
+43cb1aa18a4bcad5bc93feb42d8cc2ab44db1cc530eff9239e2b93784b93a824

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.