mirror/freebsd
1
0
Fork 0
mirror of https://git.FreeBSD.org/src.git synced 2024-12-23 11:18:54 +00:00
Code Issues Releases Activity
d052a1cc33
freebsd/sys/modules/uart/Makefile

30 lines
887 B
Makefile
Raw Normal View History

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
# $FreeBSD$
.PATH: ${.CURDIR}/../../dev/uart
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
.if ${MACHINE_CPUARCH} == "sparc64"
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
uart_bus_ebus= uart_bus_ebus.c
- 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
ofw_bus_if= ofw_bus_if.h
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
.endif
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
KMOD= uart
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
SRCS= uart_bus_acpi.c ${uart_bus_ebus} uart_bus_isa.c uart_bus_pccard.c \
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
uart_bus_pci.c uart_bus_puc.c uart_bus_scc.c \
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
uart_core.c uart_dbg.c \
Include the QUICC backend in the kernel module. PR: 127120
2008-11-22 21:24:07 +00:00
uart_dev_ns8250.c uart_dev_quicc.c uart_dev_sab82532.c \
uart_dev_z8530.c \
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
uart_if.c uart_if.h uart_subr.c uart_tty.c
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
.if ${MACHINE} == "sun4v"
SRCS+= uart_cpu_sparc64.c
Correct the path to the MD source so r206569 actually works as intended.
2010-05-23 20:08:41 +00:00
.elif exists(${.CURDIR}/../../dev/uart/uart_cpu_${MACHINE}.c)
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
SRCS+= uart_cpu_${MACHINE}.c
.endif
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
SRCS+= bus_if.h card_if.h device_if.h isa_if.h ${ofw_bus_if} pci_if.h \
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
power_if.h pccarddevs.h serdev_if.h
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
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
MFILES= dev/pccard/card_if.m dev/pccard/power_if.m dev/pci/pci_if.m \
dev/ofw/ofw_bus_if.m dev/uart/uart_if.m isa/isa_if.m kern/bus_if.m \
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
kern/device_if.m kern/serdev_if.m
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
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
.include <bsd.kmod.mk>
Reference in New Issue Copy Permalink