Commit Graph

26 Commits

Author SHA1 Message Date
Yoshihiro Takahashi
3280345272 Build uart_dev_lpc.c on arm only. This fixes pc98 build. 2013-04-22 13:02:41 +00:00
Justin Hibbits
6ba2699056 Fix the uart(4) module build. Without uart_dev_lpc the module cannot be loaded. 2013-04-19 05:46:16 +00:00
Andrew Turner
de5b074bf5 In the uart module build ofw_bus_if.h on arm along with sparc64 as LINT
fails when built locally without it.
2013-03-17 06:33:49 +00:00
Ulrich Spörlein
7732eaccce Fix 'make depend' 2013-03-06 11:44:19 +00:00
Marcel Moolenaar
1eaf8e042c Compensate for the replacement of uart_cpu_{amd64|i386}.c with
uart_cpu_x86.c

Pointy hat: marcel
2012-04-18 17:44:05 +00:00
Attilio Rao
4b547324c0 Disconnect sun4v architecture from the three.
Some files keep the SUN4V tags as a code reference, for the future,
if any rewamped sun4v support wants to be added again.

Reviewed by:	marius
Tested by:	sbruno
Approved by:	re
2011-05-14 01:53:38 +00:00
Warner Losh
c09808d0d6 MFtbemd:
Use MACHINE_CPUARCH in preference to MACHINE_ARCH.  The former is the
source code location of the machine, the latter the binary output.  In
general, we want to use MACHINE_CPUARCH instead of MACHINE_ARCH unless
we're tesitng for a specific target.  The isn't even moot for
i386/amd64 where there's momemntum towards a MACHINE_CPUARCH == x86,
although a specific cleanup for that likely would be needed...
2010-08-23 06:13:29 +00:00
Marius Strobl
de2ebd2e0d Correct the path to the MD source so r206569 actually works as intended. 2010-05-23 20:08:41 +00:00
Warner Losh
b74668b1df Only compile in uart_cpu_$MACHINE.c if it exists. I'm not sure how
useful it will be, but we really need to be keying off something other
than MACHINE for this anyway since on arm and mips we have lots of
these running around (one for each SoC family)...
2010-04-13 21:32:06 +00:00
Marcel Moolenaar
df1cb3b734 Include the QUICC backend in the kernel module.
PR:		127120
2008-11-22 21:24:07 +00:00
John Birrell
951c63bc3a In sun4v, use the sparc64 version. We haven't used the serial port on
sun4v yet, so this is a 'best-guess'.
2006-10-16 22:11:53 +00:00
Marcel Moolenaar
af2e25a6d2 o Add scc(4) to the build.
o  Add the scc(4) manpage to the build.
o  Update the uart(4) manpage to account for scc(4).
o  Update the uart(4) module build to include support for scc(4).
2006-03-30 18:39:24 +00:00
Marcel Moolenaar
9465d7f13a Remove dev/uart/uart_if.m from the default MFILES (in kmod.mk) and
instead define MFILES appropriately for the uart(4) module build.
2006-02-24 01:49:36 +00:00
Marcel Moolenaar
694f13aaff Stop building uart_dev_i8251.c. It was copied from uart_dev_ns8250.c
without ever being changed to actually work with an i8251. Nobody is
working on this either at the moment, so it's not about to change
soon.
When the code necessary to support the i8251 is committed, this can
be reverted again.
2004-11-20 23:38:48 +00:00
Marius Strobl
8ff995cc5f o sparc64/isa/isa.c:
- The claim in the commit log of rev. 1.11 of dev/uart/uart_cpu_sparc64.c
    etc. that UARTs are the only relevant ISA devices on sparc64 turned out
    to be false. While there are sparc64 models where UARTs are the only
    devices on the ISA bus there are in fact also low-cost models where all
    devices traditionally found on the EBus are hooked up to the ISA bus.
    There are also models that use a mix between EBus and ISA devices with
    things like an AT keyboard controller and other rather interesting
    devices that we might want to support in the futute hook up to the ISA
    bus.
    In order to not need to add sparc64 specific device_identify methods to
    all of the respective ISA drivers and also not add OFW specific code to
    the common ISA code make the sparc64 ISA bus code fake up PnP devices so
    most ISA drivers probe their devices without further changes.
    Unfortunately Sun doesn't adhere to the ISA bindings defined in IEEE
    1275-1994 for the properties of most of the ISA devices which would
    allow to obtain the vendor and logical IDs from their properties. So we
    we just use a simple table which maps the name properties to PnP IDs.
    This could be done in a more sophisticated way but I courrently don't
    see the need for this. [1]
  - Add the children with fully mapped and specified resources (in the OFW
    sense) similar to what is done in the EBus code for the IRQ resources
    of the children as adjusting the resources and the resource list entries
    respectively in isa_alloc_resource() as done perviously causes trouble
    with drivers which use rman_get_start(), pass-through or allocate and
    release resources multiple times, etc.
    Adjusting the resources might be better off in a bus_activate_resource
    method but the common ISA code currently doesn't allow for an
    isa_activate_resource(). [2]
    With this change:
    - ppbus(4) and lpt(4) attach and work (modulo ECP mode, which requires
      real ISADMA code but it currently only consists of stubs on sparc64).
    - atkbdc(4) and atkbdc(4) attach, no further testing done.
    - fdc(4) itself attaches but causes a hang while attaching fd0 also
      when is DMA disabled, further work in fdc(4) is required here as e.g.
      fd0 uses the address of fd1 on sparc64 (not sure if sparc64 supports
      more than one floppy drive at all).
    All of these drivers previously caused panics in the sparc64 ISA code.
  - Minor changes, e.g. use __FBSDID, remove a dupe word in a comment and
    declare one global variable which isn't used outside of isa.c static.
o dev/uart/uart_cpu_sparc64.c and modules/uart/Makefile:
  - Remove the code for registering the UARTs on the ISA bus from the
    sparc64 uart_cpu_identify() again and rely on probing them via PnP.

Original idea by:	tmm [1]
No objections by:	tmm [1], [2]
2004-11-17 14:44:10 +00:00
Marius Strobl
efa79eb77e - Introduce an uart_cpu_identify() which is implemented in uart_cpu_<arch>.c
and that can be used as an identify function for all kinds of busses on a
  certain platform. Expect for sparc64 these are only stubs right now. [1]
- For sparc64, add code to its uart_cpu_identify() for registering the on-
  board ISA UARTs and their resources based on information obtained from
  Open Firmware.
  It would be better if this would be done in the OFW ISA code. However, due
  to the common FreeBSD ISA code and PNP-IDs not always being present in the
  properties of the ISA nodes there seems to be no good way to implement that.
  Therefore special casing UARTs as the sole really relevant ISA devices on
  sparc64 seemed reasonable. [2]

Approved by:	marcel
Discussed with:	marcel [1], tmm [2]
Tested by:	make universe
2004-08-14 23:54:27 +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
Marcel Moolenaar
3096307b3d Build uart_dbg.c for remote GDB support. 2004-07-10 23:01:35 +00:00
Warner Losh
dba6dd177b Move to generating pccarddevs.h on the fly, both for the kernel and
the modules.

Also generate usbdevs.h automatically now, but a non-kernel file is
stopping that at the moment.
2004-05-26 00:53:10 +00:00
Marcel Moolenaar
562174ff37 Add uart_subr.c 2004-03-20 22:41:52 +00:00
Marcel Moolenaar
8225548ebf Only build the ebus driver on sparc64. It includes a header directly
from the sparc64 subtree, which breaks building non-sparc64 platforms
in the event the sparc64 subtree does not exist.
The problem is specific to the module, because non-module builds are
affected by the presence or absence of "device ebus" in the kernel
configuration.

PR: kern/56869
2003-09-17 03:00:08 +00:00
Marcel Moolenaar
991e61c934 Sort: build uart_bus_pccard.c before uart_bus_pci.c. 2003-09-15 04:53:11 +00:00
Takanori Watanabe
a9f6e997b5 Add uart pccard bus attachment,based on sio_pccard.c .
Wrote at: Hakone.
Powered by: Warner Losh's scotch whisky.
Tested by: nork
2003-09-14 16:21:06 +00:00
Marcel Moolenaar
763d340b43 Now that PC98 has it's own MD file, use uart_cpu_${MACHINE}.c and
not uart_cpu_${MACHINE_ARCH}.c.
2003-09-07 06:50:08 +00:00
Warner Losh
080684ba71 add i8251 2003-09-07 05:00:32 +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