Commit Graph

8 Commits

Author SHA1 Message Date
Marius Strobl
099894cc96 Declare the sbus(4) front-end of puc(4) also for fhc(4), allowing
uart(4) to support the Zilog 8530 SCCs which hang off of a FireHose
bus on Sun E4000/E5000 class machines.
Beside the fact that a puc_fhc.c would just be a copy of puc_sbus.c
with s,sbus,fhc,g the reason why the declaration for fhc(4) was
sticked into puc_sbus.c is that both of these front-ends for puc(4)
will go away once there is a scc(4).

Discussed with:	marcel
Tested by:	hrs, kris
MFC after:	3 days
2005-02-26 00:25:43 +00:00
Marcel Moolenaar
2554d6b9b4 Revert rev. 1.5.
It should be safe to attach to all Z8530 controllers again. In fact,
the keyboard works on Ultra 2 machines.

MFC after: 5 days
2005-01-31 04:25:48 +00:00
Warner Losh
098ca2bda9 Start each of the license/copyright comments with /*-, minor shuffle of lines 2005-01-06 01:43:34 +00:00
Marcel Moolenaar
982ea33b89 Apply a bandaid to avoid hangs on Ultra 2 machines. The second Z8530
connects to the keyboard and mouse and needs some special treatment.
Until this is fully understood, implemented and tested, simply avoid
probing the second Z8530. This is also what the zs(4) driver does.
2004-11-15 02:47:37 +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
Poul-Henning Kamp
186f2b9e04 Add missing <sys/module.h> includes currently relying on nested include
in <sys/kernel.h>
2004-06-03 06:10:02 +00:00
Marcel Moolenaar
cc81fed63c Ever since rev 1.27 of puc.c, the port number that was exposed by puc(4)
and used by uart(4) for the channel conflicted with the port offset for
the Z8530. The Z8530 has the channels reversed (i.e. channel B is at
offset 0 and channel A is at offset 4). Assign the port offsets in the
right order so that uart(4) will properly attach to the channels.

Submitted by: Marius Strobl <marius@alchemy.franken.de>
2004-04-05 01:58:02 +00:00
Marcel Moolenaar
dc7d0dea12 Enhance puc(4) to support uart(4). This includes:
o  Introduce PUC_PORT_TYPE_UART so that we can attach to uart(4),
o  Introduce port sub-types (eg PUC_PORT_UART_NS8250, PUC_PORT_UART_Z8530)
   to handle different hardware and determine resource sizes.
o  Introduce two new IVARs: PUC_IVAR_SUBTYPE and PUC_IVAR_REGSHFT. Both
   are used by uart(4) to get sufficient information to talk to the HW.
o  Introduce PUC_FLAGS_ALTRES to tell puc(4) to try memory mapped I/O
   if I/O port space cannot be allocated, or vice versa.
o  Have ports of type PUC_PORT_TYPE_COM attach to uart(1) if attaching
   to sio(4) fails (due to not having the sio driver).
o  Put struct puc_device_description in struct puc_softc instead of
   having a pointer to a device description in the softc. This allows
   us to create device descriptions on the fly without having to use
   malloc() or otherwise have them staticly defined.
o  Move puc_find_description() from puc.c to puc_pci.c as it's specific
   to PCI.
o  Add EBUS and SBUS frontends for use on sparc64. Note that the P in
   puc stands for PCI, so we kinda mess things up here. It's too soon
   to worry about it though. We'll know what to do about it in time.

NOTE: This commit changes the behaviour of puc(4) to not quieten the
device probe and attach for child devices. The uart(4) driver provides
additional device description that is valuable to have.
2003-09-06 21:48:50 +00:00