Commit Graph

92 Commits

Author SHA1 Message Date
George V. Neville-Neil
b2630c2934 Commit the change from FAST_IPSEC to IPSEC. The FAST_IPSEC
option is now deprecated, as well as the KAME IPsec code.
What was FAST_IPSEC is now IPSEC.

Approved by: re
Sponsored by: Secure Computing
2007-07-03 12:13:45 +00:00
Marius Strobl
f0d8df7bb2 - Move ofw_pci_alloc_busno() to the ofw_pci KOBJ interface,
allowing the driver for the host-PCI-bridge to indicate that
  reenumeration of the PCI busses isn't supported by returning
  -1 instead of a valid PCI bus number. This is needed in order
  support both Tomatillo, which don't support reenumeration and
  thus are apparently intended to be used for independently
  numbered PCI domains only, and Psycho bridges, whose busses
  need to be reenumerated on at least some E450, without the
  #ifndef currently used for sun4v in order to support multiple
  independently PCI domains. The actual allocation/incrementation
  of the PCI bus numbers is now done in psycho(4), though it
  no longer establish a mapping between bus numbers and device
  nodes like ofw_pci_alloc_busno() did as that functionality
  wasn't used (but can easily brought back if really needed).
  The now no longer used sys/sparc64/pci/ofw_pci.c is also
  removed from sys/conf/files.sun4v as ofw_pci_alloc_busno()
  wasn't used there in the first place.
- In ofw_pci_default_{adjust_busrange,intr_pending}() sanity
  check that the device has a parent before passing it on.
- Make psycho_softcs static to sys/sparc64/pci/psycho.c as
  it's not used outside of that module.
- In sys/sparc64/pci/ofw_pcib_subr.c remove the superfluous
  inclusion of opt_global.h and correct the debug output for
  adjusting the subordinate bus number.
2007-06-18 21:49:42 +00:00
Marius Strobl
c54e7ea989 Move the gallant 12 x 22 font data from a .h to a .c so it doesn't need
to be compiled into every driver making use of it. Use a const instance
of struct gfb_font for this as the font isn't intended to be changed at
run-time and in order to accompany the font data with height and width
info.
2007-06-16 21:48:50 +00:00
Marcel Moolenaar
2b39bb4f4f Use default options for default partitioning schemes, rather than
making the relevant files standard. This avoids duplication and
makes it easier to override/disable unwanted schemes. Since ARM
doesn't have a DEFAULTS configuration file, leave the source
files for the BSD and MBR partitioning schemes in files.arm for
now.
2007-06-11 00:38:06 +00:00
Marius Strobl
33368e9fe8 Rototill the sparc64 nexus(4) (actually this brings in the code the
sun4v nexus(4) in turn is based on):
o Change nexus(4) to manage the resources of its children so the
  respective device drivers don't need to figure them out of OFW
  themselves.
o Change nexus(4) to provide the ofw_bus KOBJ interface instead of
  using IVARs for supplying the OFW node and the subset of standard
  properties of its children. Together with the previous change this
  also allows to fully take advantage of newbus in that drivers like
  fhc(4), which attach on multiple parent busses, no longer require
  different bus front-ends as obtaining the OFW node and properties
  as well as resource allocation works the same for all supported
  busses. As such this change also is part 4/4 of allowing creator(4)
  to work in USIII-based machines as it allows this driver to attach
  on both nexus(4) and upa(4). On the other hand removing these IVARs
  breaks API compatibility with the powerpc nexus(4) but which isn't
  that bad as a) sparc64 currently doesn't share any device driver
  hanging off of nexus(4) with powerpc and b) they were no longer
  compatible regarding OFW-related extensions at the pci(4) level
  since quite some time.
o Provide bus_get_dma_tag methods in nexus(4) and its children in
  order to handle DMA tags in a hierarchical way and get rid of the
  sparc64_root_dma_tag kludge. Together with the previous two items
  this changes also allows to completely get rid of the nexus(4)
  IVAR interface. It also includes:
  - pushing the constraints previously specified by the nexus_dmatag
    down into the DMA tags of psycho(4) and sbus(4) as it's their
    IOMMUs which induce these restrictions (and nothing at the
    nexus(4) or anything that would warrant specifying them there),
  - fixing some obviously wrong constraints of the psycho(4) and
    sbus(4) DMA tags, which happened to not actually be used with
    the sparc64_root_dma_tag kludge in place and therefore didn't
    cause problems so far,
  - replacing magic constants for constraints with macros as far
    as it is obvious as to where they come from.
  This doesn't include taking advantage of the newbus way to get
  the parent DMA tags implemented by this change in order to divorce
  the IOTSBs of the PCI and SBus IOMMUs or for implementing the
  workaround for the DMA sync bug in Sabre (and Tomatillo) bridges,
  yet, though.
o Get rid of the notion that nexus(4) (mostly) reflects an UPA bus
  by replacing ofw_upa.h and with ofw_nexus.h (which was repo-copied
  from ofw_upa.h) and renaming its content, which actually applies to
  all of Fireplane/Safari, JBus and UPA (in the host bus case), as
  appropriate.
o Just use M_DEVBUF instead of a separate M_NEXUS malloc type for
  allocating the device info for the children of nexus(4). This is
  done in order to not need to export M_NEXUS when deriving drivers
  for subordinate busses from the nexus(4) class.
o Use the DEFINE_CLASS_0() macro to declare the nexus(4) driver so
  we can derive subclasses from it.
o Const'ify the nexus_excl_name and nexus_excl_type arrays as well
  as add 'associations' and 'rsc', which are pseudo-devices without
  resources and therefore of no real interest for nexus(4), to the
  former.
o Let the nexus(4) device memory rman manage the entire 64-bit address
  space instead of just the UPA_MEMSTART to UPA_MEMEND subregion as
  Fireplane/Safari- and JBus-based machines use multiple ranges,
  which can't be as easily divided as in the case of UPA (limiting
  the address space only served for sanity checking anyway).
o Use M_WAITOK instead of M_NOWAIT when allocating the device info
  for children of nexus(4) in order to give one less opportunity
  for adding devices to nexus(4) to fail.
o While adapting the drivers affected by the above nexus(4) changes,
  change them to take advantage of rman_get_rid() instead of caching
  the RIDs assigned to allocated resources, now that the RIDs of
  resources are correctly set.
o In iommu(4) and nexus(4) replace hard-coded functions names, which
  actually became outdated in several places, in panic strings and
  status massages with __func__. [1]
o Use driver_filter_t in prototypes where appropriate.
o Add my copyright to creator(4), fhc(4), nexus(4), psycho(4) and
  sbus(4) as I changed considerable amounts of these drivers as well
  as added a bunch of new features, workarounds for silicon bugs etc.
o Fix some white space nits.

Due to lack of access to Exx00 hardware, these changes, i.e. central(4)
and fhc(4), couldn't be runtime tested on such a machine. Exx00 are
currently reported to panic before trying to attach nexus(4) anyway
though.

PR:		76052 [1]
Approved by:	re (kensmith)
2007-03-07 21:13:51 +00:00
Marius Strobl
0222c13479 Add front-ends for the 'lebuffer' variants found on some SBus cards.
These are shared-memory variants based on Am79C90-compatible chips
that apart from the missing DMA engine are similar to the 'ledma'
variant including using a (pseudo-)bus/device for the buffer that
the actual LANCE device hangs off from. The performance of these is
close to that of the 'ledma' one, like expected at a few times the
CPU load though.
2007-01-20 12:53:30 +00:00
Marius Strobl
0855a1ba50 Resurrect upa(4), now used for the subordinate/slave UPA bridge and
bus hanging off from the Fireplane/Safari bus in some USIII machines.
This is part 3/4 of allowing creator(4) to work in these machines.
The little info needed on how to configure the bridge and to work
around the incorrect values contained in the `interrupts' properties
of its children were obtained form OpenSolaris.
2007-01-16 22:08:27 +00:00
Marius Strobl
d3fc12aff9 - Merge sys/sparc64/creator/creator_upa.c into sys/dev/fb/creator.c.
The separate bus front-end was inherited from the OpenBSD creator(4),
  which at that time had a mainbus(4) (for USI/II machines, which use
  an UPA interconnection bus as the nexus) and an upa(4) (for USIII
  machines, which use a subordinate/slave UPA bus hanging off from the
  Fireplane/Safari interconnection bus) front-end. With FreeBSD and
  newbus there is/will be no need to have two separate bus front-ends
  for these busses, so we can easily coallapse the shared front-end
  and the back-end into a single source file (note that the FreeBSD
  creator_upa.c was misnomer anyway; based on what it actually attached
  to that should have been creator_nexus.c), actually OpenBSD meanwhile
  also has moved to a shared front-end and a single source file. Due
  to the low-level console support creator.c also wasn't free from bus
  related things before.
  While at it, also split sys/sparc64/creator/creator.h into a
  sys/dev/fb/creatorreg.h that only contains register macros and move
  the structures to the top of sys/dev/fb/creator.c as suggested by
  style(9) so creator(4) is no longer scattered over two directories.
- Use OF_decode_addr()/sparc64_fake_bustag() to obtain the bus tags and
  handles for the low-level console support instead of hardcoding
  support for AFB/FFB hanging off from nexus(4) only. This is part 2/4
  of allowing creator(4) to work in USIII machines (which have a UPA
  bus hanging off from the Fireplane/Safari bus reflected by the nexus),
  which already makes it work as the low-level console there.
- Allocate resources in the bus attach routine regardless of whether
  creator(4) is used as for the low-level console and thus the required
  bus tags and handles have been already obtained or not so the resources
  are marked as taken in the respective RMAN.
- For both obtaining the bus tags and handles for the low-level console
  support as well as allocating the corresponding resources in the
  regular bus attach routine don't bother to get all for the maximum of
  24 register banks but only (for) the two tag/handle pairs required for
  providing the video interface for syscons(4) support. If we can't
  allocate the rest of them just limit the memory range accessible via
  creator_fb_mmap() accordingly.
- Sanity check the memory range spanned by the first and last resources
  and the resources in between as far as possible, as the XFree86/Xorg
  sunffb(4) expects to be able to access the whole region, even though
  the backing resources are actually non-continuous. Limit and check
  the memory range accessible via creator_fb_mmap() accordingly.
- Reduce the size of buffers for OFW properties to what they actually
  need to hold.
- Rename some tables to creator_<foo> for consistency.
- Also for the sizes in the creator_fb_mmap() mapping table entries use
  macros for consistency, add macros for the remaining register banks
  for completeness.
2007-01-16 21:08:22 +00:00
Matt Jacob
2c298b17e3 opt_ah.h ends up copied into a kernelcompile directory in some
aches as a read-only file. In a number of cases this has led to
compiles failing- usually due to some strange NFS drift which thinks
that the opt_ah.h in the compile directory is out of date wrt the
source it is copied from. When the copy is executed again, it fails
because the target is read-only. Oops. Modify the compile hooks
avoid this.

Discussed with a while back with:	Sam Leffler
2006-12-18 05:45:23 +00:00
Marius Strobl
65deb9d947 - In sunkbd_probe_keyboard() don't bother to determine the keyboard layout
as we have no use for that info. Instead let this function return the
  keyboard ID and verify at its invocation in sunkbd_configure() that we're
  talking to a Sun type 4/5/6 keyboard, i.e. a keyboard supported by this
  driver.
- Add an option SUNKBD_EMULATE_ATKBD whose code is based on the respective
  code in ukbd(4) and like UKBD_EMULATE_ATSCANCODE causes this driver to
  emit AT keyboard/KB_101 compatible scan codes in K_RAW mode as assumed by
  kbdmux(4). Unlike UKBD_EMULATE_ATSCANCODE, SUNKBD_EMULATE_ATKBD also
  triggers the use of AT keyboard maps and thus allows to use the map files
  in share/syscons/keymaps with this driver at the cost of an additional
  translation (in ukbd(4) this just is the way of operation).
- Implement an option SUNKBD_DFLT_KEYMAP, which like the equivalent options
  of the other keyboard drivers allows to specify the default in-kernel
  keyboard map. For obvious reasons this made to only work when also using
  SUNKBD_EMULATE_ATKBD.
- Implement sunkbd_check(), sunkbd_check_char() and sunkbd_clear_state(),
  which are also required for interoperability with kbdmux(4).
- Implement K_CODE mode and FreeBSD keypad compose.
- As a minor hack define KBD_DFLT_KEYMAP also in the !SUNKBD_EMULATE_ATKBD
  case so we can obtain fkey_tab from <dev/kbd/kbdtables.h> rather than
  having to duplicate it and #ifdef some more code.
- Don't use the TX-buffer for writing the two command bytes for setting the
  keyboard LEDs as this consequently requires a hardware FIFO that is at
  least two bytes in depth, which the NMOS-variant of the Zilog SCCs doesn't
  have. Thus use an inlined version of uart_putc() to consecutively write
  the command bytes (a cleaner approach would be to do this via the soft
  interrupt handler but that variant wouldn't work while in ddb(4)). [1]
- Fix some minor style(9) bugs.

PR:		90316 [1]
Reviewed by:	marcel [1]
2006-11-02 00:01:15 +00:00
Ruslan Ermilov
837f167eb2 Move "device splash" back to MI NOTES and "files", it's MI. 2006-10-23 13:23:14 +00:00
Ruslan Ermilov
663cf7fed2 Move MI parts of syscons into MI "files". 2006-10-23 13:05:01 +00:00
Sam Leffler
d66735216f add ath_hal glue
MFC after:	3 days
2006-03-14 22:40:44 +00:00
Yaroslav Tykhiy
8d96e45531 Retire NETSMBCRYPTO as a kernel option and make its functionality
enabled by default in NETSMB and smbfs.ko.

With the most of modern SMB providers requiring encryption by
default, there is little sense left in keeping the crypto part
of NETSMB optional at the build time.

This will also return smbfs.ko to its former properties users
are rather accustomed to.

Discussed with:		freebsd-stable, re (scottl)
Not objected by:	bp, tjr (silence)
MFC after:		5 days
2006-03-05 22:52:17 +00:00
Marius Strobl
44ac0964e9 Hook up le(4) to the build. For now it's only added to the sparc64 GENERIC
in order to support the on-board LANCE in Ultra 1 and to the MI NOTES as
it should work just fine with the AMD PCnet family of chips on all archs
but is not yet meant to replace lnc(4). If a kernel includes all of le(4),
lnc(4) and pcn(4) precedence is given to lnc(4)/pcn(4) for now.
2006-01-31 22:34:13 +00:00
Ruslan Ermilov
a8e06f2a52 Make config(8) understand ORed dependecies in "files*" and
improve tracking of known devices.  Bump config(8) version.
2005-11-27 21:41:58 +00:00
Marius Strobl
b53c934a95 Conditionalize the compilation of the envctrl.c front-end of pcf(4)
additionally on ebus(4) as the 'SUNW,envctrl' devices (as well as
'SUNW,envctrltwo' and 'SUNW,rasctrl', which we might want to also
support in envctrl.c in the future) are only found on EBus.
2005-11-22 17:25:10 +00:00
Marius Strobl
bba6f0a901 - Add a new method ofw_bus_default_get_devinfo() that allows to retrieve
a newly introduced struct ofw_bus_devinfo which can hold the OFW info
  of a device recallable via the ofw_bus KOBJ interface. Introduce a set
  of functions ofw_bus_gen_get_*() which use ofw_bus_default_get_devinfo()
  to provide generic subroutines for implementing the rest of the ofw_bus
  KOBJ interface in a bus driver.
  This is inspired by bus_get_resource_list() and bus_generic_rl_*_resource()
  and allows to reduce code duplication in bus drivers as they only have
  to provide an ofw_bus_default_get_devinfo() implementation in order to
  provide the ofw_bus KOBJ interface via ofw_bus_gen_get_*().
- While here add a comment to ofw_bus_if.m describing the intention of
  the ofw_bus KOBJ interface.

Reviewed by:	marcel
2005-11-22 16:37:45 +00:00
Joerg Wunsch
9b229abc8f Finally complete some work on generalizing the PCF8584-based I2C
drivers I started quite some time before.

Retire the old i386-only pcf driver, and activate the new general
driver that has been sitting in the tree already for quite some
time.

Build the i2c modules for sparc64 architectures as well (where I've
been developing all this on).
2005-10-28 15:58:19 +00:00
Marcel Moolenaar
b16d349f1b Refactor the NETSMBCRYPTO option so that it does the same on all
platforms. ARM is excluded as it doesn't yet have any crypto
sources.

Approved by: re (dwhite)
MFC after: 1 day
2005-06-12 00:47:21 +00:00
Marius Strobl
c2722b8fcf - Hook up atkbdc(4), atkbd(4) and psm(4) to the sparc64 build, not
enabled in GENERIC by default, yet.
- While here remove the exclusion of ukbd(4) from the sparc64 NOTES
  as ukbd(4) compiles and works on sparc64.
2005-06-10 20:58:59 +00:00
Joseph Koshy
f263522a45 MFP4:
- Implement sampling modes and logging support in hwpmc(4).

- Separate MI and MD parts of hwpmc(4) and allow sharing of
  PMC implementations across different architectures.
  Add support for P4 (EMT64) style PMCs to the amd64 code.

- New pmcstat(8) options: -E (exit time counts) -W (counts
  every context switch), -R (print log file).

- pmc(3) API changes, improve our ability to keep ABI compatibility
  in the future.  Add more 'alias' names for commonly used events.

- bug fixes & documentation.
2005-06-09 19:45:09 +00:00
Marius Strobl
fef0b157a8 - Hook up machfb(4) to the sparc64 build, not enabled in GENERIC
by default, yet.
- Replace "graphics cards" with "framebuffers" in the description
  of creator(4) in order to make it uniform with the description of
  machfb(4) and the latter occur both on-board and as add-on cards.
2005-05-21 20:50:45 +00:00
Marius Strobl
a30881c7d7 Sync with the other files.<arch> files and put the keyboard map
generation stuff at the beginning of this file as well as add a
dependency on dev/kbd/kbd.c for ukbd(4).
2005-05-19 22:56:00 +00:00
Marius Strobl
a0b2f8d7fc - Collapse eeprom_ebus.c and eeprom_sbus.c into eeprom.c and
eeprom_ebus_attach() and eeprom_sbus_attach() into eeprom_attach()
  respectively. Since the introduction of the ofw_bus interface some
  time ago and now that ebus(4) also uses SYS_RES_MEMORY for the
  memory resources since ebus.c rev. 1.22 there is no longer a
  need to have separate front-ends for ebus(4), fhc(4) and sbus(4).
- Fail gracefully instead of panicing when the model can't be
  determined.
- Don't leak resources when mk48txx_attach() fails.
- Use FBSDID.
2005-05-19 18:15:37 +00:00
Marius Strobl
65fb49a994 - Try to not leak resources in the attach functions of the esp(4) SBus
front-end and the LSI64854 and NCR53C9x code in case one of these
  functions fails. Add detach functions to these parts and make esp(4)
  detachable.
- Revert rev. 1.7 of esp_sbus.c, since rev. 1.34 of sbus.c the clockfreq
  IVAR defaults to the per-child values.
- Merge ncr53c9x.c rev. 1.111 from NetBSD (partial):
  On reset, clear state flags and the msgout queue.
  In NetBSD code to notify the upper layer (i.e. CAM in FreeBSD) on reset
  was also added with this revision. This is believed to be not necessary
  in FreeBSD and was not merged.
  This makes ncr53c9x.c to be in sync with NetBSD up to rev. 1.114.
- Conditionalize the LSI64854 support on sbus(4) only instead of sbus(4)
  and esp(4) as it's also required for the 'dma', 'espdma' and 'ledma'
  busses/devices as well as the 'SUNW,bpp' device (printer port) which
  all hang off of sbus(4).
- Add a driver for the 'dma', 'espdma' and 'ledma' (pseudo-)busses/
  devices. These busses and devices actually represent the LSI64854 DMA
  engines for the ESP SCSI and LANCE Ethernet controllers found on the
  SBus of Ultra 1 and SBus add-on cards. With 'espdma' and 'ledma' the
  'esp' and 'le' devices hang off of the respective DMA bus instead of
  directly from the SBus. The 'dma' devices are either also used in this
  manner or on some add-on cards also as a companion device to an 'esp'
  device which also hangs off directly from the SBus. With the latter
  variant it's a bit tricky to glue the DMA engine to the core logic of
  the respective 'esp' device. With rev. 1.35 of sbus.c we are however
  guaranteed that such a 'dma' device is probed before the respective
  'esp' device which simplifies things a lot. [1]
- In the esp(4) SBus front-end read the part-unique ID code of Fast-SCSI
  capable chips the right way. This fixes erroneously detecting some
  chips as FAS366 when in fact they are not. Add explicit checks for the
  FAS100A, FAS216 and FAS236 variants instead treating all of these as
  ESP200. That way we can correctly set the respective Fast-SCSI config
  bits instead of driving them out of specs. This includes adding the
  FAS100A and FAS236 variants to the NCR53C9x core code. We probably
  still subsume some chip variants as ESP200 while in fact they are
  another variant which however shouldn't really matter as this will
  only happen when these chips are driven at 25MHz or less which implies
  not being able to run Fast-SCSI. [3]
- Add a workaround to the NCR53C9x interrupt handler which ignores the
  stray interrupt generated by FAS100A when doing path inquiry during
  boot and which otherwiese would trigger a panic.
- Add support for the 'esp' devices hanging off of a 'dma' or 'espdma'
  busses or which are companions of 'dma' devices to esp(4). In case of
  the variants that hang off of a DMA device this is a bit hackish as
  esp(4) then directly uses the softc of the respective parent to talk
  to the DMA engine. It might make sense to add an interface for this
  in order to implement this in a cleaner way however it's not yet clear
  how the requirements for the LANCE Ethernet controllers are and the
  hack works for now. [2]
  This effectively adds support for the onboard SCSI controller in
  Ultra 1 as well as most of the ESP-based SBus add-on cards to esp(4).
  With this the code for supporting the Performance Technologies SBS430
  SBus SCSI add-on cards is also largely in place the remaining bits
  were however omitted as it's unclear from the NetBSD how to couple
  the DMA engine and the core logic together for these cards.

Obtained from:	OpenBSD [1]
Obtained from:	NetBSD [2]
Clue from:	BSD/OS [3]
Reviewed by:	scottl (earlier version)
Tested with:	FSBE/S add-on card (FAS236), SSHA add-on card (ESP100A),
		Ultra 1 (onboard FAS100A), Ultra 2 (onboard FAS366)
2005-05-19 14:51:10 +00:00
John Baldwin
c6a37e8413 Divorce critical sections from spinlocks. Critical sections as denoted by
critical_enter() and critical_exit() are now solely a mechanism for
deferring kernel preemptions.  They no longer have any affect on
interrupts.  This means that standalone critical sections are now very
cheap as they are simply unlocked integer increments and decrements for the
common case.

Spin mutexes now use a separate KPI implemented in MD code: spinlock_enter()
and spinlock_exit().  This KPI is responsible for providing whatever MD
guarantees are needed to ensure that a thread holding a spin lock won't
be preempted by any other code that will try to lock the same lock.  For
now all archs continue to block interrupts in a "spinlock section" as they
did formerly in all critical sections.  Note that I've also taken this
opportunity to push a few things into MD code rather than MI.  For example,
critical_fork_exit() no longer exists.  Instead, MD code ensures that new
threads have the correct state when they are created.  Also, we no longer
try to fixup the idlethreads for APs in MI code.  Instead, each arch sets
the initial curthread and adjusts the state of the idle thread it borrows
in order to perform the initial context switch.

This change is largely a big NOP, but the cleaner separation it provides
will allow for more efficient alternative locking schemes in other parts
of the kernel (bare critical sections rather than per-CPU spin mutexes
for per-CPU data for example).

Reviewed by:	grehan, cognet, arch@, others
Tested on:	i386, alpha, sparc64, powerpc, arm, possibly more
2005-04-04 21:53:56 +00:00
Marius Strobl
be7a88bd72 Add a driver for the 'clock-board' device (the clock board is an
inevitable component in Sun Exx00 machines and provides serial ports,
NVRAM and TOD amongst others which are handled by uart(4) and eeprom(4)
respectively). This driver currently only prints out information about
the chassis on attach and allows to blink the 'Cycling' LED (which is
duplicated on the front panel) of the clock board just like fhc(4) does
for the other boards. The device name for the LED is /dev/led/clockboard.

Obtained from:	OpenBSD
Tested by:	joerg
2005-03-19 01:04:48 +00:00
Marius Strobl
82ec256c67 Back out no longer necessary work-arounds added in rev. 1.59 for building
SBus-only kernels regarding ofw_machdep.c.
2005-02-12 19:19:20 +00:00
Marius Strobl
906ca21abe Add a front-end for the `rtc' device which is a MC146818 compatible
clock found on the ISA bus (some USIIe, USIIi and USIIIi models) and
EBus (USIII models) instead of a MK48Txx clock.

Testet by:	Matthew T. Lager" <freebsd@trinetworks.com> on Sun Fire V100,
		Xavier Beaudouin <kiwi@oav.net> on Netra X1 (initial version)
2004-11-17 16:41:42 +00:00
Tom Rhodes
acad338196 Fix paths after repocopies done by scottl
Reviewed by:	marius
OK'ed by:	scottl
2004-11-10 14:09:52 +00:00
Pyun YongHyeon
7a7386a3e2 Device driver for onboard CS4231 audio controller which is found
on UltraSPARC workstations. The driver is based on OpenBSD's SBus
cs4231 driver and heavily modified to incorporate into sound(4)
infrastructure. Due to the lack of APCDMA documentation, the DMA
code of SBus cs4231 came from OpenBSD's driver.
The driver runs without Giant lock and supports both SBus and EBus
based CS4231 audio controller. Special thanks to marius for providing
feedbacks during the driver writing. His feedback made it possible
to write hiccup free playback code under high system loads.

Approved by:	jake (mentor)
Reviewed by:	marius (initial version)
Tested by:	marius, kwm, Julian C. Dunn(jdunn AT opentrend DOT net)
2004-10-25 10:29:57 +00:00
Pyun YongHyeon
e60fc88fa6 Port NetBSD auxio driver. The driver was modified to use led(4) and can
be used to announce various system activity.
The auxio device provides auxiliary I/O functions and is found on various
SBus/EBus UltraSPARC models. At present, only front panel LED is
controlled by this driver.

Approved by:    jake (mentor)
Reviewed by:    joerg
Tested by:      joerg
2004-10-09 07:31:03 +00:00
Marius Strobl
9c0c82c161 Add a kludge for building SBus-only kernels, i.e. kernels without support
for EBus, ISA and PCI, by compiling ofw_isa.c and ofw_pci_if.m unconditio-
nally. The correct way is to rewrite OF_decode_addr() in ofw_machdep.c in
a bus-neutral way. That's certainly possible but we unfortunately didn't
make it for FreeBSD 5.3.

Approved by:	tmm
2004-08-15 22:59:34 +00:00
Marius Strobl
adb03c6788 sio(4), which never really worked on sparc64, was removed in favour of
uart(4) in sparc64/conf/GENERIC revision 1.63 about 9 months ago. Remove
its source files here, too.
2004-08-15 00:10:59 +00:00
Marius Strobl
26280d88d7 - Introduce an ofw_bus kobj-interface for retrieving the OFW node and a
subset ("compatible", "device_type", "model" and "name") of the standard
  properties in drivers for devices on Open Firmware supported busses. The
  standard properties "reg", "interrupts" und "address" are not covered by
  this interface because they are only of interest in the respective bridge
  code. There's a remaining standard property "status" which is unclear how
  to support properly but which also isn't used in FreeBSD at present.
  This ofw_bus kobj-interface allows to replace the various (ebus_get_node(),
  ofw_pci_get_node(), etc.) and partially inconsistent (central_get_type()
  vs. sbus_get_device_type(), etc.) existing IVAR ones with a common one.
  This in turn allows to simplify and remove code-duplication in drivers for
  devices that can hang off of more than one OFW supported bus.
- Convert the sparc64 Central, EBus, FHC, PCI and SBus bus drivers and the
  drivers for their children to use the ofw_bus kobj-interface. The IVAR-
  interfaces of the Central, EBus and FHC are entirely replaced by this. The
  PCI bus driver used its own kobj-interface and now also uses the ofw_bus
  one. The IVARs special to the SBus, e.g. for retrieving the burst size,
  remain.
  Beware: this causes an ABI-breakage for modules of drivers which used the
  IVAR-interfaces, i.e. esp(4), hme(4), isp(4) and uart(4), which need to be
  recompiled.
  The style-inconsistencies introduced in some of the bus drivers will be
  fixed by tmm@ in a generic clean-up of the respective drivers later (he
  requested to add the changes in the "new" style).
- Convert the powerpc MacIO bus driver and the drivers for its children to
  use the ofw_bus kobj-interface. This invloves removing the IVARs related
  to the "reg" property which were unused and a leftover from the NetBSD
  origini of the code. There's no ABI-breakage caused by this because none
  of these driver are currently built as modules.
  There are other powerpc bus drivers which can be converted to the ofw_bus
  kobj-interface, e.g. the PCI bus driver, which should be done together
  with converting powerpc to use the OFW PCI code from sparc64.
- Make the SBus and FHC front-end of zs(4) and the sparc64 eeprom(4) take
  advantage of the ofw_bus kobj-interface and simplify them a bit.

Reviewed by:	grehan, tmm
Approved by:	re (scottl)
Discussed with:	tmm
Tested with:	Sun AX1105, AXe, Ultra 2, Ultra 60; PPC cross-build on i386
2004-08-12 17:41:33 +00:00
Mark Murray
8ab2f5ecc5 Break out the MI part of the /dev/[k]mem and /dev/io drivers into
their own directory and module, leaving the MD parts in the MD
area (the MD parts _are_ part of the modules). /dev/mem and /dev/io
are now loadable modules, thus taking us one step further towards
a kernel created entirely out of modules. Of course, there is nothing
preventing the kernel from having these statically compiled.
2004-08-01 11:40:54 +00:00
Marcel Moolenaar
5971a234e5 Hook the GDB backend into the build. 2004-07-10 23:31:17 +00:00
Scott Long
12c6be05d1 Add the esp(4) files. Two of them are sbus-specific and therefore only
apply to sparc64.
2004-06-10 05:21:44 +00:00
Marius Strobl
66a79ac95d - Remove the old sparc64 OFW PCI code (as opposed to the former
"options OFW_NEWPCI").
  This is a bit overdue, the new sparc64 OFW PCI code which is
  meant to replace the old one is in place for 10 months and
  enabled by default in GENERIC for 8 months. FreeBSD 5.2 and
  5.2.1 also shipped with the new code enabled by default.
- Some minor clean-up, e.g. remove functions that encapsulated
  the #ifdefs for OFW_NEWPCI, remove unused resp. no longer
  required includes, etc.

Approved by:	tmm, no objections on freebsd-sparc64
2004-05-08 13:53:47 +00:00
Marius Strobl
e9e3f95d4a Remove the separate kernel option for Sun APB PCI-PCI bridges and make
support for them conditional on the pci(4) kernel option instead.

OK'ed by:	tmm
2004-04-30 15:00:41 +00:00
Alan Cox
1c5043680e Add an implementation of uiomove_fromphys() to sparc64. This
implementation could be characterized as a hybrid of the amd64 and i386
implementations.  Specifically, the direct virtual-to-physical mapping is
used if possible and sf_buf_alloc() is used if the direct map cannot.
2004-03-22 08:08:25 +00:00
Dag-Erling Smørgrav
7f3155aab1 Re-add libkern/ffs.c. I thought sparc64 had an inline version, but
failed to notice that it's #if 0'ed out.
2004-01-14 08:38:13 +00:00
Dag-Erling Smørgrav
1de30b60cb Add ffsl(), fls() flsl() to platforms that don't already have them. 2004-01-13 15:37:23 +00:00
Warner Losh
c33df8b251 Copy ukbdmap.h rules from .i386.
# maybe this should be in files.

# This may fix sparc64 tinderbox.  I'll kinow in a few hours.
2003-11-17 04:38:14 +00:00
Jake Burkholder
d2f154c95e Add a uart attachment/syscons keyboard driver for sun keyboards. In theory
this will work with any uart backend, currently supported hardware uses
either ns8250 or z8530.
2003-11-11 07:33:24 +00:00
Marcel Moolenaar
2bec1c8919 Hook-up the uart(4) driver to the build. For a detailed description
of what uart(4) is and/or is not see the initial commit log of one
of the files in sys/dev/uart (or see share/man/man4/uart.4).

Note that currently pc98 shares the MD file with i386. This needs
to change when pc98 support is fleshed-out to properly support the
various UARTs. A good example is sparc64 in this respect.

We build uart(4) as a module on all platforms. This may break
the ppc port. That depends on whether they do actually build
modules.

To use uart(4) on alpha, one must use the NO_SIO option.
2003-09-06 23:23:26 +00:00
Jake Burkholder
e16255d3f0 Hook syscons and the creator driver up to the sparc64. This compiles but
will not link due to missing keyboard drivers.
2003-08-24 01:54:06 +00:00
Thomas Moestl
1d80cb1b37 Add the new sparc64 OFW PCI framework, conditional on options OFW_NEWPCI
for now. It introduces a OFW PCI bus driver and a generic OFW PCI-PCI
bridge driver. By utilizing these, the PCI handling is much more elegant
now.

The advantages of the new approach are:
- Device enumeration should hopefully be more like on Solaris now,
  so unit numbers should match what's printed on the box more
  closely.
- Real interrupt routing is implemented now, so cardbus bridges
  etc. have at least a chance to work.
- The quirk tables are gone and have been replaced by (hopefully
  sufficient) heuristics.
- Much cleaner code.

There was also a report that previously bogus interrupt assignments
are fixed now, which can be attributed to the new heuristics.

A pitfall, and the reason why this is not the default yet, is that
it changes device enumeration, as mentioned above, which can make
it necessary to change the system configuration if more than one
unit of a device type is present (on a system with two hme cars,
for example, it is possible that hme0 becomes hme1 and vice versa
after enabling the option). Systems with multiple disk controllers
may need to be booted into single user (and require manual specification
of the root file system on boot) to adjust the fstab.
Nevertheless, I would like to encourage users to use this option,
so that it can be made the default soon.

In detail, the changes are:
- Introduce an OFW PCI bus driver; it inherits most methods from the
  generic PCI bus driver, but uses the firmware for enumeration,
  performs additional initialization for devices and firmware-specific
  interrupt routing. It also implements an OFW-specific method to allow
  child devices to get their firmware nodes.
- Introduce an OFW PCI-PCI bridge driver; again, it inherits most
  of the generic PCI-PCI bridge driver; it has it's own method for
  interrupt routing, as well as some sparc64-specific methods (one to
  get the node again, and one to adjust the bridge bus range, since
  we need to reenumerate all PCI buses).
- Convert the apb driver to the new way of handling things.
- Provide a common framework for OFW bridge drivers, used be the two
  drivers above.
- Provide a small common framework for interrupt routing (for all
  bridge types).
- Convert the psycho driver to the new framework; this gets rid of a
  bunch of old kludges in pci_read_config(), and the whole
  preinitialization  (ofw_pci_init()).
- Convert the ISA MD part and the EBus driver to the new way
  interrupts and nodes are handled.
- Introduce types for firmware interrupt properties.
- Rename the old sparcbus_if to ofw_pci_if by repo copy (it is only
  required for PCI), and move it to a more correct location (new
  support methodsx were also added, and an old one was deprecated).
- Fix a bunch of minor bugs, perform some cleanups.

In some cases, I introduced some minor code duplication to keep the
new code clean, in hopes that the old code will be unifdef'ed soon.

Reviewed in part by:	imp
Tested by:	jake, Marius Strobl <marius@alchemy.franken.de>,
		Sergey Mokryshev <mokr@mokr.net>,
		Chris Jackman <cjackNOSPAM@klatsch.org>
Info on u30 firmware provided by:	kris
2003-07-01 14:52:47 +00:00
Jake Burkholder
d6c28affbd Hook openpromio up to the build. 2003-06-19 18:06:58 +00:00