Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 8 Sep 2008 20:20:44 +0000 (UTC)
From:      Marius Strobl <marius@FreeBSD.org>
To:        src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   cvs commit: src/sys/dev/esp esp_sbus.c ncr53c9x.c ncr53c9xreg.h ncr53c9xvar.h src/sys/dev/le if_le_ledma.c src/sys/sparc64/sbus dma_sbus.c lsi64854.c lsi64854var.h
Message-ID:  <200809082021.m88KLwN0055341@repoman.freebsd.org>

next in thread | raw e-mail | index | archive | help
marius      2008-09-08 20:20:44 UTC

  FreeBSD src repository

  Modified files:
    sys/dev/esp          esp_sbus.c ncr53c9x.c ncr53c9xreg.h 
                         ncr53c9xvar.h 
    sys/dev/le           if_le_ledma.c 
    sys/sparc64/sbus     dma_sbus.c lsi64854.c lsi64854var.h 
  Log:
  SVN rev 182876 on 2008-09-08 20:20:44Z by marius
  
  o Move the MODULE_DEPEND() for cam(4) from the esp_sbus.c front-end to
    the ncr53c9x.c core where it actually belongs so future front-ends
    don't need to add it.
  o Use the correct OFW property when looking for the initiator ID of the
    SBus device.
  o Don't specify an alignment when creating the parent DMA tag for
    SUNW,fas; their DMA engine doesn't require an alignment constraint
    and it's no inherited by the child DMA tags anyway (which probably
    is a bug though).
  o Drop the superfluous sc_maxsync and use sc_minsync instead. The
    former apparently was added due to a confusion with the maximum
    frequency used in cam(4), which basically corresponds to the
    inverse of minimum sync period.
  o Merge ncr53c9x.c from NetBSD:
    1.116: NCRDMA_SETUP() should be called before NCR_SET_COUNT() and
           NCRCMD_DMA command in ncr53c9x_select().
    1.125: free allocated resources on detach.
  o Static'ize ncr53c9x_action(), ncr53c9x_init() and ncr53c9x_reset()
    as these are not required outside of ncr53c9x.c.
  o In ncr53c9x_attach() don't leak the device mutex in case attaching
    fails.
  o Register an asynchronous notification handler so in case cam(4)
    reports a lost device we can cancel outstanding commands and
    restore the default parameters for the target in question.
  o For FAS366 correctly support 16-bit target IDs and let it know
    that we use 32-bit transfers.
  o Overhaul the negotiation of transfer settings. This includes
    distinguishing between current and goal transfer settings of the
    target so we can renegotiate their goal settings when necessary
    and correcting the order in which tagged, wide and synchronous
    transfers are negotiated.
  o If we are requesting sense, force a renegotiation if we are
    currently using anything different from asynchronous at 8 bit
    as the target might have lost our transfer negotiations.
  o In case of an XPT_RESET_BUS just directly call ncr53c9x_init()
    instead of issuing a NCRCMD_RSTSCSI, which in turn will issue an
    interrupt that is treated as an unexpected SCSI bus reset by
    ncr53c9x_intr() and thus calls ncr53c9x_init(). Remove the now
    no longer used ncr53c9x_scsi_reset().
  o Correct an off-by-one error when setting cpi->max_lun.
  o In replace printf(9) with device_printf(9) calls where appropriate
    and in ncr53c9x_action() remove some unnecessarily verbose messages.
  o In ncr53c9x_sched() use TAILQ_FOREACH() instead of reimplementing
    it and consolidate two tagging-related target info checks into one.
  o In ncr53c9x_done() set the CAM status to CAM_SCSI_STATUS_ERROR when
    appropriate, respect CAM_DIS_AUTOSENSE and teach it to return SCSI
    status information.
  o In ncr53c9x_dequeue() ensure the tags are cleared.
  o Use ulmin() instead of min() where appropriate.
  o In ncr53c9x_msgout() consistently use the reset label.
  o When we're interrupted during a data phase and the DMA engine is
    still active, don't panic but reset the core and the DMA engine as
    this should be sufficient. Also, the typical problem for triggering
    this was the lack of renegotiation when requesting sense.
  o Correctly handle DEVICE RESETs.
  o Adapt the locking of esp(4) to MPSAFE cam(4). This includes moving
    the calls of lsi64854_attach() to the bus front-ends so it can pass
    the esp(4) mutex to bus_dma_tag_create(9).
  o Change the LSI64854 driver to not create a DMA tag and map for the
    Ethernet channel as le(4) will handle these on its own as well as
    sync and unload the DMA maps for the SCSI and parallel port channel
    after a DMA transfer.
  o Cam(4)'ify some NetBSD-centric comments.
  o Use bus_{read,write}_*(9) instead of bus_space_{read,write}_*(9)
    and take advantage of rman_get_rid(9) in order to save some softc
    members.
  
  Reviewed by:    scottl
  MFC after:      1 month
  
  Revision  Changes    Path
  1.17      +114 -119  src/sys/dev/esp/esp_sbus.c
  1.19      +492 -341  src/sys/dev/esp/ncr53c9x.c
  1.6       +2 -2      src/sys/dev/esp/ncr53c9xreg.h
  1.10      +36 -28    src/sys/dev/esp/ncr53c9xvar.h
  1.5       +36 -26    src/sys/dev/le/if_le_ledma.c
  1.7       +11 -21    src/sys/sparc64/sbus/dma_sbus.c
  1.9       +71 -64    src/sys/sparc64/sbus/lsi64854.c
  1.7       +3 -12     src/sys/sparc64/sbus/lsi64854var.h



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