Copy stable/9 to releng/9.3 as part of the 9.3-RELEASE cycle.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Copy head to stable/9 as part of 9.0-RELEASE release cycle.

Approved by: re (implicit)

Merge amd64 and i386 bus.h and move the resulting header to x86. Replace
the original amd64 and i386 headers with stubs.

Rename (AMD64|I386)_BUS_SPACE_* to X86_BUS_SPACE_* everywhere.

Reviewed by: imp (previous version), jhb
Approved by: kib (mentor)

Use bus_space_compare() rather than i386_memio_compare() directly.

Add the 2nd CCU and PnP devices support on pc98.

Reviewed by: imp
Obtained from: //depot/projects/uart with some fixes

Don't expose the uart_ops structure directly, but instead have
it obtained through the uart_class structure. This allows us
to declare the uart_class structure as weak and as such allows
us to reference it even when it's not compiled-in.
It also allows is to get the uart_ops structure by name, which
makes it possible to implement the dt tag handling in uart_getenv().
The side-effect of all this is that we're using the uart_class
structure more consistently which means that we now also have
access to the size of the bus space block needed by the hardware
when we map the bus space, eliminating any hardcoding.

Make uart_getenv() not be ns8250 dependent. This will allow, in the future,
compilation of kernels without ns8250 support but using the uart framework.
These kernels will be for machines where size matters more, so including code
that can never be executed is undesriable...

Start each of the license/copyright comments with /*-, minor shuffle of lines

uart_i8251_ops is gone.

Remove the whole uart_cpu_identify() stuff again. Now that it's no longer
used on sparc64 they are only stubs on all architectures and it doesn't
look like if we would need it in the near future again.

Ok'ed by: marcel

- 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

- Initialize uart_bus_space_io and uart_bus_space_mem.
- Fix wrong comment.

Introduce the hw.uart.console and hw.uart.dbgport environment variables
to select a serial console and debug port (resp). On ia64 these replace
the use of hints completely and take precedence over hints on alpha,
amd64 and i386. On sparc64 these variables are not yet recognised.

The reasons for introducing these variables are:
1. Hints have side-effects. They reserve the unit number for use by
isa or acpi devices and therefore cannot be used to select a pci
device. Also, the use of a unit number to select a device prior
to bus enumeration is nonsense. The new variables have no side-
effects and are not based on unit numbers.
2. Hints don't have the expression power to allow the sysadmin to
select UARTs that are not legacy PC devices and need the support
of compile-time constants to give the sysadmin some level of
flexibility.

The hw.uart.console and hw.uart.dbgport variables specify a list of
attributes. An attribute is a tag-value pair, seperated by a colon.
Attributes are seperated by a comma. Where possible, tags are the
same as those in /etc/remote (only br and pa in practice). Details
can be found in the manpage (not part of this commit).

Not tested on: amd64, pc98

Revert the introduction of iobase in struct uart_bas. Both the SAB82532
and the Z8530 drivers used the I/O address as a quick and dirty way to
determine which channel they operated on, but formalizing this by
introducing iobase is not a solution. How for example would a driver
know which channel it controls for a multi-channel UART that only has a
single I/O range?

Instead, add an explicit field, called chan, to struct uart_bas that
holds the channel within a device, or 0 otherwise. The chan field is
initialized both by the system device probing (i.e. a system console)
or it is passed down to uart_bus_probe() by any of the bus front-ends.
As such, it impacts all platforms and bus drivers and makes it a rather
large commit.

Remove the use of iobase in uart_cpu_eqres() for pc98. It is expected
that platforms have the capability to compare tag and handle pairs for
equality; as to determine whether two pairs access the same device or
not. The use of iobase for pc98 makes it impossible to formalize this
and turn it into a real newbus function later. This commit reverts
uart_cpu_eqres() for pc98 to an unimplemented function. It has to be
reimplemented using only the tag and handle fields in struct uart_bas.

Rewrite the SAB82532 and Z8530 drivers to use the chan field in struct
uart_bas. Remove the IS_CHANNEL_A and IS_CHANNEL_B macros. We don't
need to abstract anything anymore.

Discussed with: nyan
Tested on: i386, ia64, sparc64

Don't return to search another ports even if bus_space_map() fails.

Compare base address instead of bus_handle.

- Keep the base address in struct uart_bas for sab82532 and z8530 modules.
- Remove buggy uart_cpu_busaddr() function.

Use bus_space_map() to initialize a bus_handle.

Minor commentary cleanup, since I didn't understand the comments that
I wrote.

Fix compile on pc98. Maybe this is correct.

Remove the assumption that a bus_space_handle_t is an I/O address
from the SAB82532 and the Z8530 hardware drivers by introducing
uart_cpu_busaddr(). The assumption is not true on pc98 where
bus_space_handle_t is a pointer to a structure.
The uart_cpu_busaddr() function will return the bus address
corresponding the tag and handle given to it by the BAS.

WARNING: the intend of the function is STRICTLY to allow hardware
drivers to determine which logical channel they control and is NOT
to be used for actual I/O. It is therefore EXPLICITLY allowed that
uart_cpu_busaddr() returns only the lower 8 bits of the address
and garbage in all other bits. No mistakes...

Better stab at MD code for pc98. The 8251 stuff is a total lie
(ns8250 copied and s/ns8250/i8251/g), but there for linkage purposes.
Real code to follow, once I get past some boot issues on my pc98 boxes
with recent current.