Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1619560

Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master

From Benjamin Herrenschmidt <benh@au1.ibm.com>
Newsgroups linux.kernel
Subject Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master
Date 2017-04-10 00:00 +0200
Message-ID <tut2i-8vx-9@gated-at.bofh.it> (permalink)
References (4 earlier) <tqPkK-3s9-13@gated-at.bofh.it> <tsAAW-7Yu-23@gated-at.bofh.it> <tsF7A-2v6-11@gated-at.bofh.it> <tuszg-8ld-7@gated-at.bofh.it> <tut2i-8vx-7@gated-at.bofh.it>
Organization IBM Australia

Show all headers | View raw


On Mon, 2017-04-10 at 07:41 +1000, Benjamin Herrenschmidt wrote:
> On Sun, 2017-04-09 at 16:22 -0500, Christopher Bostic wrote:
> > 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 
> > based on your recommendations to re-order the two clock delays.
> 
> This is huge delays. We should consider a AST2xxx specific variant of
> the backend that uses nops or similar lab-calibrated constructs
> instead. Otherwise we are stuck in the kHz range, this is a >200Mhz
> bus
> :)
> 
> I don't understand why 3us delay would thus be necessary.
> 
> Where about did you observe issues ? Could it be that you don't wait
> long enough in the transitions from write to read ?

FYI. pdbg in userspace operates without any  delays in practice, the
overhead between the various load/store instructions seems sufficient.

The only delay that's needed is when going through the FSI2PIB (to do
SCOMs) where it seems like back-2-back accesses can be problematic.

Cheers,
Ben

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master Christopher Bostic <cbostic@linux.vnet.ibm.com> - 2017-03-29 19:50 +0200
  Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master Joel Stanley <joel@jms.id.au> - 2017-03-30 08:00 +0200
    Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master Christopher Bostic <cbostic@linux.vnet.ibm.com> - 2017-03-30 20:20 +0200
      Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2017-03-30 23:00 +0200
        Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master Christopher Bostic <cbostic@linux.vnet.ibm.com> - 2017-04-04 19:40 +0200
          Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2017-04-05 00:30 +0200
            Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master Christopher Bostic <cbostic@linux.vnet.ibm.com> - 2017-04-05 03:30 +0200
            Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master Christopher Bostic <cbostic@linux.vnet.ibm.com> - 2017-04-09 23:30 +0200
              Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master Benjamin Herrenschmidt <benh@au1.ibm.com> - 2017-04-10 00:00 +0200
              Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master Benjamin Herrenschmidt <benh@au1.ibm.com> - 2017-04-10 00:00 +0200
              Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2017-04-10 00:50 +0200
      Re: [PATCH v4 19/23] drivers/fsi: Add GPIO based FSI master Joel Stanley <joel@jms.id.au> - 2017-03-31 01:00 +0200

csiph-web