Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Dec 2001 16:18:45 -0800 (PST)
From:      Matt Jacob <mjacob@FreeBSD.org>
To:        cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   cvs commit: src/sys/dev/isp isp.c isp_freebsd.c isp_freebsd.h isp_inline.h isp_pci.c isp_target.c isp_target.h ispmbox.h ispvar.h
Message-ID:  <200112110018.fBB0Ijf68663@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
mjacob      2001/12/10 16:18:45 PST

  Modified files:
    sys/dev/isp          isp.c isp_freebsd.c isp_freebsd.h 
                         isp_inline.h isp_pci.c isp_target.c 
                         isp_target.h ispmbox.h ispvar.h 
  Log:
  Major restructuring for swizzling to the request queue and unswizzling from
  the response queue. Instead of the ad hoc ISP_SWIZZLE_REQUEST, we now have
  a complete set of inline functions in isp_inline.h. Each platform is
  responsible for providing just one of a set of ISP_IOX_{GET,PUT}{8,16,32}
  macros.
  
  The reason this needs to be done is that we need to have a single set of
  functions that will work correctly on multiple architectures for both little
  and big endian machines. It also needs to work correctly in the case that
  we have the request or response queues in memory that has to be treated
  specially (e.g., have ddi_dma_sync called on it for Solaris after we update
  it or before we read from it). It also has to handle the SBus cards (for
  platforms that have them) which, while on a Big Endian machine, do *not*
  require *most* of the request/response queue entry fields to be swizzled
  or unswizzled.
  
  One thing that falls out of this is that we no longer build requests in the
  request queue itself. Instead, we build the request locally (e.g., on the
  stack) and then as part of the swizzling operation, copy it to the request
  queue entry we've allocated. I thought long and hard about whether this was
  too expensive a change to make as it in a lot of cases requires an extra
  copy. On balance, the flexbility is worth it. With any luck, the entry that
  we build locally stays in a processor writeback cache (after all, it's only
  64 bytes) so that the cost of actually flushing it to the memory area that is
  the shared queue with the PCI device is not all that expensive. We may examine
  this again and try to get clever in the future to try and avoid copies.
  
  Another change that falls out of this is that MEMORYBARRIER should be taken
  a lot more seriously. The macro ISP_ADD_REQUEST does a MEMORYBARRIER on the
  entry being added. But there had been many other places this had been missing.
  It's now very important that it be done.
  
  Additional changes:
  
  Fix a longstanding buglet of sorts. When we get an entry via isp_getrqentry,
  the iptr value that gets returned is the value we intend to eventually plug
  into the ISP registers as the entry *one past* the last one we've written-
  *not* the current entry we're updating. All along we've been calling sync
  functions on the wrong index value. Argh. The 'fix' here is to rename all
  'iptr' variables as 'nxti' to remember that this is the 'next' pointer-
  not the current pointer.
  
  Devote a single bit to mboxbsy- and set aside bits for output mbox registers
  that we need to pick up- we can have at least one command which does not
  have any defined output registers (MBOX_EXECUTE_FIRMWARE).
  
  MFC after:      2 weeks
  
  Revision  Changes    Path
  1.82      +135 -124  src/sys/dev/isp/isp.c
  1.74      +23 -20    src/sys/dev/isp/isp_freebsd.c
  1.57      +42 -9     src/sys/dev/isp/isp_freebsd.h
  1.17      +1049 -1   src/sys/dev/isp/isp_inline.h
  1.75      +149 -157  src/sys/dev/isp/isp_pci.c
  1.19      +46 -32    src/sys/dev/isp/isp_target.c
  1.17      +22 -195   src/sys/dev/isp/isp_target.h
  1.36      +11 -28    src/sys/dev/isp/ispmbox.h
  1.51      +32 -22    src/sys/dev/isp/ispvar.h

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200112110018.fBB0Ijf68663>