d/freebsd-nq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
572f347d9f
freebsd-nq/sys/dev/uart/uart_cpu_pc98.c

107 lines
3.2 KiB
C
Raw Normal View History

Start each of the license/copyright comments with /*-, minor shuffle of lines
2005-01-06 01:43:34 +00:00
/*-
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.
2003-09-07 04:59:15 +00:00
* Copyright (c) 2003 M. Warner Losh, Marcel Moolenaar
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
* IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
#include <sys/cdefs.h>
__FBSDID("$FreeBSD$");
#include <sys/param.h>
#include <sys/systm.h>
#include <sys/bus.h>
#include <machine/bus.h>
#include <dev/uart/uart.h>
#include <dev/uart/uart_cpu.h>
- Initialize uart_bus_space_io and uart_bus_space_mem. - Fix wrong comment.
2004-05-16 14:12:05 +00:00
bus_space_tag_t uart_bus_space_io = I386_BUS_SPACE_IO;
bus_space_tag_t uart_bus_space_mem = I386_BUS_SPACE_MEM;
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
2004-03-20 02:14:02 +00:00
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...
2003-09-07 21:51:03 +00:00
int
uart_cpu_eqres(struct uart_bas *b1, struct uart_bas *b2)
{
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
2003-09-26 05:14:56 +00:00
return (0); /* XXX */
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...
2003-09-07 21:51:03 +00:00
}
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.
2003-09-07 04:59:15 +00:00
int
uart_cpu_getdev(int devtype, struct uart_devinfo *di)
{
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.
2007-04-02 22:00:22 +00:00
struct uart_class *class;
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.
2003-09-07 04:59:15 +00:00
unsigned int i, ivar, flags;
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.
2007-04-02 22:00:22 +00:00
class = &uart_ns8250_class;
if (class == NULL)
return (ENXIO);
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
2004-03-20 02:14:02 +00:00
/* Check the environment. */
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.
2007-04-02 22:00:22 +00:00
if (uart_getenv(devtype, di, class) == 0)
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
2004-03-20 02:14:02 +00:00
return (0);
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.
2003-09-07 04:59:15 +00:00
/*
- Initialize uart_bus_space_io and uart_bus_space_mem. - Fix wrong comment.
2004-05-16 14:12:05 +00:00
* There is a serial port on all pc98 hardware. It is 8251 or
* an enhance version of that. Some pc98 have the second serial
* port which is 16550A compatible. However, for the sio driver,
* flags selected which type of uart was in the sytem. We use
* something similar to sort things out.
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.
2003-09-07 04:59:15 +00:00
*/
for (i = 0; i < 1; i++) {
if (resource_int_value("uart", i, "flags", &flags))
continue;
if (devtype == UART_DEV_CONSOLE && !UART_FLAGS_CONSOLE(flags))
continue;
if (devtype == UART_DEV_DBGPORT && !UART_FLAGS_DBGPORT(flags))
continue;
/*
* We have a possible device. Make sure it's enabled and
* that we have an I/O port.
*/
if (resource_int_value("uart", i, "disabled", &ivar) == 0 &&
ivar != 0)
continue;
if (resource_int_value("uart", i, "port", &ivar) != 0 ||
ivar == 0)
continue;
uart_i8251_ops is gone.
2004-11-21 15:18:35 +00:00
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.
2007-04-02 22:00:22 +00:00
di->ops = uart_getops(class);
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
2003-09-26 05:14:56 +00:00
di->bas.chan = 0;
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
2004-03-20 02:14:02 +00:00
di->bas.bst = uart_bus_space_io;
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.
2007-04-02 22:00:22 +00:00
if (bus_space_map(di->bas.bst, ivar, uart_getrange(class), 0,
&di->bas.bsh) != 0)
Don't return to search another ports even if bus_space_map() fails.
2003-09-23 13:03:22 +00:00
continue;
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.
2003-09-07 04:59:15 +00:00
di->bas.regshft = 0;
di->bas.rclk = 0;
if (resource_int_value("uart", i, "baud", &ivar) != 0)
ivar = 0;
di->baudrate = ivar;
di->databits = 8;
di->stopbits = 1;
di->parity = UART_PARITY_NONE;
return (0);
}
return (ENXIO);
}
Reference in New Issue Copy Permalink