d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
70d20ed34f
freebsd-dev/sys/sparc64/pci/firevar.h

92 lines
2.9 KiB
C
Raw Normal View History

Add a driver for the `Fire' JBus to PCIe bridges found in at least the Sun Fire V215/V245 and Sun Ultra 25/45 machines. This driver also already includes all the code to support the `Oberon' Uranus to PCIe bridges found in the Fujitsu-Siemens based Mx000 machines but due to lack of access to such a system for testing, probing of these bridges is currently disabled. Unfortunately, the event queue mechanism of these bridges for MSIs/ MSI-Xs matches our current MD and MI interrupt frameworks like square pegs fit into round holes so for now we are generous and use one event queue per MSI, which limits us to 35 MSIs/MSI-Xs per Host-PCIe-bridge (we use one event queue for the PCIe error messages). This seems tolerable as long as most devices just use one MSI/MSI-X anyway. Adding knowledge about MSIs/MSI-Xs to the MD interrupt code should allow us to decouple the 1:1 mapping at the cost of no longer being able to bind MSIs/MSI-Xs to specific CPUs as we currently have no reliable way to quiesce a device during the transition of its MSIs/ MSI-Xs to another event queue. This would still require the problem of interrupt storms generated by devices which have no one-shot behavior or can't/don't mask interrupts while the filter/handler is executed (like the older PCIe NICs supported by bge(4)) to be solved though. Committed from: 26C3
2009-12-27 16:55:44 +00:00
/*-
sys/sparc64: further adoption of SPDX licensing ID tags. Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.
2017-11-27 15:10:39 +00:00
* SPDX-License-Identifier: BSD-2-Clause-FreeBSD
*
Add a driver for the `Fire' JBus to PCIe bridges found in at least the Sun Fire V215/V245 and Sun Ultra 25/45 machines. This driver also already includes all the code to support the `Oberon' Uranus to PCIe bridges found in the Fujitsu-Siemens based Mx000 machines but due to lack of access to such a system for testing, probing of these bridges is currently disabled. Unfortunately, the event queue mechanism of these bridges for MSIs/ MSI-Xs matches our current MD and MI interrupt frameworks like square pegs fit into round holes so for now we are generous and use one event queue per MSI, which limits us to 35 MSIs/MSI-Xs per Host-PCIe-bridge (we use one event queue for the PCIe error messages). This seems tolerable as long as most devices just use one MSI/MSI-X anyway. Adding knowledge about MSIs/MSI-Xs to the MD interrupt code should allow us to decouple the 1:1 mapping at the cost of no longer being able to bind MSIs/MSI-Xs to specific CPUs as we currently have no reliable way to quiesce a device during the transition of its MSIs/ MSI-Xs to another event queue. This would still require the problem of interrupt storms generated by devices which have no one-shot behavior or can't/don't mask interrupts while the filter/handler is executed (like the older PCIe NICs supported by bge(4)) to be solved though. Committed from: 26C3
2009-12-27 16:55:44 +00:00
* Copyright (c) 2009 by Marius Strobl <marius@FreeBSD.org>.
* All rights reserved.
*
* 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,
* without modification, immediately at the beginning of the file.
* 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.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR 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 AUTHOR 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$
*/
#ifndef _SPARC64_PCI_FIREVAR_H_
#define _SPARC64_PCI_FIREVAR_H_
struct fire_softc {
- Factor out the common and generic parts of the sparc64 host-PCI-bridge drivers into the revived sys/sparc64/pci/ofw_pci.c, previously already serving a similar purpose. This has been done with sun4v in mind, which explains a) the otherwise not that obvious scheme employed and b) why reusing sys/powerpc/ofw/ofw_pci.c was even lesser an option. - Add a workaround for QEMU once again not emulating real machines, in this case by not providing the OFW_PCI_CS_MEM64 range. [1] Submitted by: jhb [1] MFC after: 1 week
2015-09-12 22:49:32 +00:00
/*
* This is here so that we can hook up the common bus interface
* methods in ofw_pci.c directly.
*/
struct ofw_pci_softc sc_ops;
Add a driver for the `Fire' JBus to PCIe bridges found in at least the Sun Fire V215/V245 and Sun Ultra 25/45 machines. This driver also already includes all the code to support the `Oberon' Uranus to PCIe bridges found in the Fujitsu-Siemens based Mx000 machines but due to lack of access to such a system for testing, probing of these bridges is currently disabled. Unfortunately, the event queue mechanism of these bridges for MSIs/ MSI-Xs matches our current MD and MI interrupt frameworks like square pegs fit into round holes so for now we are generous and use one event queue per MSI, which limits us to 35 MSIs/MSI-Xs per Host-PCIe-bridge (we use one event queue for the PCIe error messages). This seems tolerable as long as most devices just use one MSI/MSI-X anyway. Adding knowledge about MSIs/MSI-Xs to the MD interrupt code should allow us to decouple the 1:1 mapping at the cost of no longer being able to bind MSIs/MSI-Xs to specific CPUs as we currently have no reliable way to quiesce a device during the transition of its MSIs/ MSI-Xs to another event queue. This would still require the problem of interrupt storms generated by devices which have no one-shot behavior or can't/don't mask interrupts while the filter/handler is executed (like the older PCIe NICs supported by bge(4)) to be solved though. Committed from: 26C3
2009-12-27 16:55:44 +00:00
struct iommu_state sc_is;
struct bus_dma_methods sc_dma_methods;
struct mtx sc_msi_mtx;
struct mtx sc_pcib_mtx;
struct resource *sc_mem_res[FIRE_NREG];
struct resource *sc_irq_res[FIRE_NINTR];
void *sc_ihand[FIRE_NINTR];
device_t sc_dev;
uint64_t *sc_msiq;
u_char *sc_msi_bitmap;
uint32_t *sc_msi_msiq_table;
u_char *sc_msiq_bitmap;
uint64_t sc_msi_addr32;
uint64_t sc_msi_addr64;
uint32_t sc_msi_count;
uint32_t sc_msi_first;
uint32_t sc_msi_data_mask;
uint32_t sc_msix_data_width;
uint32_t sc_msiq_count;
uint32_t sc_msiq_size;
uint32_t sc_msiq_first;
uint32_t sc_msiq_ino_first;
u_int sc_mode;
#define FIRE_MODE_FIRE 0
#define FIRE_MODE_OBERON 1
u_int sc_flags;
#define FIRE_MSIX (1 << 0)
uint32_t sc_ign;
uint32_t sc_stats_ilu_err;
uint32_t sc_stats_jbc_ce_async;
uint32_t sc_stats_jbc_unsol_int;
uint32_t sc_stats_jbc_unsol_rd;
uint32_t sc_stats_mmu_err;
uint32_t sc_stats_tlu_ce;
uint32_t sc_stats_tlu_oe_non_fatal;
uint32_t sc_stats_tlu_oe_rx_err;
uint32_t sc_stats_tlu_oe_tx_err;
uint32_t sc_stats_ubc_dmardue;
};
#endif /* !_SPARC64_PCI_FIREVAR_H_ */
Reference in New Issue Copy Permalink