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.