src-test2/sys/dev/uart/uart_cpu.h, branch release/10.0.0FreeBSD source treehttps://cgit-dev.freebsd.org/src-test2/atom?h=release%2F10.0.02007-04-02T22:00:22ZDon't expose the uart_ops structure directly, but instead have2007-04-02T22:00:22ZMarcel Moolenaarmarcel@FreeBSD.org2007-04-02T22:00:22Zurn:sha1:f8100ce2a70db5c60672578fee913d986ac1cf01
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.
- Add a uart_rxready() and corresponding device-specific implementations2007-01-18T22:01:19ZMarius Stroblmarius@FreeBSD.org2007-01-18T22:01:19Zurn:sha1:97202af2dca1942e1873e9ef8feb527a2e58fa7b
that can be used to check whether receive data is ready, i.e. whether
the subsequent call of uart_poll() should return a char, and unlike
uart_poll() doesn't actually receive data.
- Remove the device-specific implementations of uart_poll() and implement
uart_poll() in terms of uart_getc() and the newly added uart_rxready()
in order to minimize code duplication.
- In sunkbd(4) take advantage of uart_rxready() and use it to implement
the polled mode part of sunkbd_check() so we don't need to buffer a
potentially read char in the softc.
- Fix some mis-indentation in sunkbd_read_char().
Discussed with: marcel
Don't hold the hardware mutex across getc(). It can wait indefinitely2006-04-01T19:04:54ZMarcel Moolenaarmarcel@FreeBSD.org2006-04-01T19:04:54Zurn:sha1:634e63c986ba07fd015e3854392d44eec6e0ad35
for a character to be received. Instead let getc() do any necesary
locking.
Add support for scc(4).2006-03-30T18:37:03ZMarcel Moolenaarmarcel@FreeBSD.org2006-03-30T18:37:03Zurn:sha1:8af03381d8a55b75320465312ee779c11c7dcaf5Start each of the license/copyright comments with /*-, minor shuffle of lines2005-01-06T01:43:34ZWarner Loshimp@FreeBSD.org2005-01-06T01:43:34Zurn:sha1:098ca2bda93c701c5331d4e6aace072495b4caaaRemove the whole uart_cpu_identify() stuff again. Now that it's no longer2004-11-17T20:01:43ZMarius Stroblmarius@FreeBSD.org2004-11-17T20:01:43Zurn:sha1:37f37506de8f6eb65759e8604c38465185eadae4
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>.c2004-08-14T23:54:27ZMarius Stroblmarius@FreeBSD.org2004-08-14T23:54:27Zurn:sha1:efa79eb77e9583863d9f6e8c0c935ae90ca1c2b1
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
Introduce the hw.uart.console and hw.uart.dbgport environment variables2004-03-20T02:14:02ZMarcel Moolenaarmarcel@FreeBSD.org2004-03-20T02:14:02Zurn:sha1:2ae4f1fd16329a591fad7e1da5a2fe0ac8769db5
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
- Keep the base address in struct uart_bas for sab82532 and z8530 modules.2003-09-23T09:25:38ZYoshihiro Takahashinyan@FreeBSD.org2003-09-23T09:25:38Zurn:sha1:c423dba33446cdad2bea753403c9520ceb9ac488
- Remove buggy uart_cpu_busaddr() function.
Remove the assumption that a bus_space_handle_t is an I/O address2003-09-07T21:51:03ZMarcel Moolenaarmarcel@FreeBSD.org2003-09-07T21:51:03Zurn:sha1:5cc705512d61b0e69a92da59a5d034a0e882a6fd
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...