2005-04-17 17:41:32 +00:00
|
|
|
/* $NetBSD: lsi64854var.h,v 1.6 2005/02/04 02:10:36 perry Exp $ */
|
2004-06-10 05:11:39 +00:00
|
|
|
|
|
|
|
|
/*-
|
|
|
|
|
* Copyright (c) 1998 The NetBSD Foundation, Inc.
|
|
|
|
|
* All rights reserved.
|
|
|
|
|
*
|
|
|
|
|
* This code is derived from software contributed to The NetBSD Foundation
|
|
|
|
|
* by Paul Kranenburg.
|
|
|
|
|
*
|
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
|
* are met:
|
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
|
* 3. All advertising materials mentioning features or use of this software
|
|
|
|
|
* must display the following acknowledgement:
|
|
|
|
|
* This product includes software developed by the NetBSD
|
|
|
|
|
* Foundation, Inc. and its contributors.
|
|
|
|
|
* 4. Neither the name of The NetBSD Foundation nor the names of its
|
|
|
|
|
* contributors may be used to endorse or promote products derived
|
|
|
|
|
* from this software without specific prior written permission.
|
|
|
|
|
*
|
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
|
|
|
|
|
* ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
|
|
|
|
|
* TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
|
|
|
|
|
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
|
|
|
|
|
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
|
|
|
|
|
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
|
|
|
|
|
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
|
|
|
|
|
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
|
|
|
|
|
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
|
|
|
|
|
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
|
|
|
|
* POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* $FreeBSD$ */
|
|
|
|
|
|
|
|
|
|
struct lsi64854_softc {
|
|
|
|
|
device_t sc_dev;
|
|
|
|
|
|
|
|
|
|
struct resource *sc_res;
|
|
|
|
|
u_int sc_rev; /* revision */
|
|
|
|
|
int sc_burst; /* max suported burst size */
|
|
|
|
|
|
|
|
|
|
int sc_channel;
|
|
|
|
|
#define L64854_CHANNEL_SCSI 1
|
|
|
|
|
#define L64854_CHANNEL_ENET 2
|
|
|
|
|
#define L64854_CHANNEL_PP 3
|
|
|
|
|
void *sc_client;
|
|
|
|
|
|
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
2008-09-08 20:20:44 +00:00
|
|
|
int sc_active; /* DMA active? */
|
2004-06-10 05:11:39 +00:00
|
|
|
bus_dmamap_t sc_dmamap; /* DMA map for bus_dma_* */
|
|
|
|
|
|
|
|
|
|
bus_dma_tag_t sc_parent_dmat;
|
|
|
|
|
bus_dma_tag_t sc_buffer_dmat;
|
|
|
|
|
int sc_datain;
|
|
|
|
|
size_t sc_dmasize;
|
|
|
|
|
caddr_t *sc_dmaaddr;
|
|
|
|
|
size_t *sc_dmalen;
|
|
|
|
|
|
|
|
|
|
void (*reset)(struct lsi64854_softc *);/* reset routine */
|
|
|
|
|
int (*setup)(struct lsi64854_softc *, caddr_t *, size_t *,
|
|
|
|
|
int, size_t *); /* DMA setup */
|
|
|
|
|
int (*intr)(void *); /* interrupt handler */
|
|
|
|
|
|
|
|
|
|
u_int sc_dmactl;
|
2006-01-31 12:50:02 +00:00
|
|
|
int sc_dodrain;
|
2004-06-10 05:11:39 +00:00
|
|
|
};
|
|
|
|
|
|
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
2008-09-08 20:20:44 +00:00
|
|
|
#define L64854_GCSR(sc) bus_read_4((sc)->sc_res, L64854_REG_CSR)
|
|
|
|
|
#define L64854_SCSR(sc, csr) bus_write_4((sc)->sc_res, L64854_REG_CSR, csr)
|
2004-06-10 05:11:39 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* DMA engine interface functions.
|
|
|
|
|
*/
|
|
|
|
|
#define DMA_RESET(sc) (((sc)->reset)(sc))
|
|
|
|
|
#define DMA_INTR(sc) (((sc)->intr)(sc))
|
|
|
|
|
#define DMA_SETUP(sc, a, l, d, s) (((sc)->setup)(sc, a, l, d, s))
|
|
|
|
|
#define DMA_ISACTIVE(sc) ((sc)->sc_active)
|
|
|
|
|
|
|
|
|
|
#define DMA_ENINTR(sc) do { \
|
2005-04-17 12:45:20 +00:00
|
|
|
uint32_t csr = L64854_GCSR(sc); \
|
2004-06-10 05:11:39 +00:00
|
|
|
csr |= L64854_INT_EN; \
|
|
|
|
|
L64854_SCSR(sc, csr); \
|
|
|
|
|
} while (0)
|
|
|
|
|
|
|
|
|
|
#define DMA_ISINTR(sc) (L64854_GCSR(sc) & (D_INT_PEND|D_ERR_PEND))
|
|
|
|
|
|
|
|
|
|
#define DMA_GO(sc) do { \
|
2005-04-17 12:45:20 +00:00
|
|
|
uint32_t csr = L64854_GCSR(sc); \
|
2004-06-10 05:11:39 +00:00
|
|
|
csr |= D_EN_DMA; \
|
|
|
|
|
L64854_SCSR(sc, csr); \
|
|
|
|
|
sc->sc_active = 1; \
|
|
|
|
|
} while (0)
|
|
|
|
|
|
2005-05-19 14:51:10 +00:00
|
|
|
int lsi64854_attach(struct lsi64854_softc *);
|
|
|
|
|
int lsi64854_detach(struct lsi64854_softc *);
|
