d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
cefcecbefd
freebsd-skq/sys/dev/uart/uart_cpu_sparc64.c

267 lines
8.0 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
/*-
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
* Copyright (c) 2003, 2004 Marcel Moolenaar
The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten.
2003-09-06 23:13:47 +00:00
* 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 <machine/bus.h>
#include <machine/bus_private.h>
#include <dev/ofw/openfirm.h>
#include <machine/ofw_machdep.h>
#include <dev/uart/uart.h>
#include <dev/uart/uart_cpu.h>
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
bus_space_tag_t uart_bus_space_io;
bus_space_tag_t uart_bus_space_mem;
The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten.
2003-09-06 23:13:47 +00:00
static struct bus_space_tag bst_store[3];
- Don't blindly use the return value of uart_cpu_channel() to calculate the address of a channel on a SCC, it returns 0 on failure. [1] - Hardcode channel 1 for the keyboard on Z8530, the information present in the Open Firmware device tree doesn't allow to determine this via uart_cpu_channel(). This makes the keyboard (if one backs out rev. 1.5 of sys/dev/puc/puc_sbus.c and has both keyboard and mouse plugged in to avoid the hang that revision works around) and consequently syscons(4) on Ultra 2 work. There's a problem with the keyboard LEDs similar to the one on Ultra 60 (LEDs don't get lit under X) though, instead of lighting just a specific single one all get lit and can't be turned off again. [1] - Add comments about what uart_cpu_channel() and uart_cpu_getdev_keyboard() do and their constraints. - Improve the comments about what uart_cpu_getdev_[console,dbgport]() do, they don't return an address (as in bus) but an Open Firmware package handle. Reviewed by: marcel (modulo the comments) [1]
2004-11-28 16:00:36 +00:00
/*
* Determine which channel of a SCC a device referenced by an alias is.
* The information present in the OF device tree only allows to do this
* for "ttyX" aliases. If a device is a channel of a SCC its property
* in the /aliases node looks like one of these:
* ttya: '/central/fhc/zs@0,902000:a'
* ttyc: '/pci@1f,0/pci@1,1/ebus@1/se@14,400000:a'
*/
The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten.
2003-09-06 23:13:47 +00:00
static int
uart_cpu_channel(char *dev)
{
char alias[64];
phandle_t aliases;
int len;
strcpy(alias, dev);
if ((aliases = OF_finddevice("/aliases")) != -1)
OF_getprop(aliases, dev, alias, sizeof(alias));
len = strlen(alias);
if (len < 2 || alias[len - 2] != ':' || alias[len - 1] < 'a' ||
alias[len - 1] > 'b')
return (0);
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 (alias[len - 1] - 'a' + 1);
The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten.
2003-09-06 23:13:47 +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)
{
return ((b1->bsh == b2->bsh) ? 1 : 0);
}
Allow the selection of a debug port with hw.uart.dbgport. Unlike other architectures (like ia64), the variable has to be set to an OpenFirmware device name.
2004-04-02 07:33:35 +00:00
/*
- Don't blindly use the return value of uart_cpu_channel() to calculate the address of a channel on a SCC, it returns 0 on failure. [1] - Hardcode channel 1 for the keyboard on Z8530, the information present in the Open Firmware device tree doesn't allow to determine this via uart_cpu_channel(). This makes the keyboard (if one backs out rev. 1.5 of sys/dev/puc/puc_sbus.c and has both keyboard and mouse plugged in to avoid the hang that revision works around) and consequently syscons(4) on Ultra 2 work. There's a problem with the keyboard LEDs similar to the one on Ultra 60 (LEDs don't get lit under X) though, instead of lighting just a specific single one all get lit and can't be turned off again. [1] - Add comments about what uart_cpu_channel() and uart_cpu_getdev_keyboard() do and their constraints. - Improve the comments about what uart_cpu_getdev_[console,dbgport]() do, they don't return an address (as in bus) but an Open Firmware package handle. Reviewed by: marcel (modulo the comments) [1]
2004-11-28 16:00:36 +00:00
* Get the package handle of the UART that is selected as the console, if
* the console is an UART of course. Note that we enforce that both stdin
* and stdout are selected.
Allow the selection of a debug port with hw.uart.dbgport. Unlike other architectures (like ia64), the variable has to be set to an OpenFirmware device name.
2004-04-02 07:33:35 +00:00
* Note that the currently active console (i.e. /chosen/stdout and
* /chosen/stdin) may not be the same as the device selected in the
* environment (ie /options/output-device and /options/input-device) because
To quote submitter: "... uart_cpu_sparc64.c currently only looks at /options if ttyX is the selected console. However, there's one case where it should additionally look at /chosen. If "keyboard" is the selected input- device and "screen" the output-device (both via /options) but the keyboard is unplugged, OF automatically switches to ttya for the console. It even prints a line telling so on "screen". Solaris respects this behaviour and uses ttya as the console in this case and people probably expect FreeBSD to do the same (it's also very handy to temporarily switch consoles)..." Submitted by: Marius Strobl <marius@alchemy.franken.de> Has no doubt the change is correct: marcel
2004-04-04 05:06:26 +00:00
* keyboard and screen were selected but the keyboard was unplugged or the
* user has changed the environment. In the latter case I would assume that
* the user expects that FreeBSD uses the new console setting.
* For weirder configurations, use ofw_console(4).
Allow the selection of a debug port with hw.uart.dbgport. Unlike other architectures (like ia64), the variable has to be set to an OpenFirmware device name.
2004-04-02 07:33:35 +00:00
*/
Allow uart to attach to keyboards that are not the firmware's notion of stdin, such as when using a serial console. We must recognize these devices here so that we can override the tty attach routine.
2003-11-11 06:52:04 +00:00
static phandle_t
Allow the selection of a debug port with hw.uart.dbgport. Unlike other architectures (like ia64), the variable has to be set to an OpenFirmware device name.
2004-04-02 07:33:35 +00:00
uart_cpu_getdev_console(phandle_t options, char *dev, size_t devsz)
Allow uart to attach to keyboards that are not the firmware's notion of stdin, such as when using a serial console. We must recognize these devices here so that we can override the tty attach routine.
2003-11-11 06:52:04 +00:00
{
char buf[32];
Fix a style(9) bug (variable definitions inside a nested scope) a patch of mine introduced in revision 1.10. Approved by: marcel Prodded by: marcel
2004-08-15 02:17:20 +00:00
ihandle_t stdin, stdout;
phandle_t chosen, input;
Allow the selection of a debug port with hw.uart.dbgport. Unlike other architectures (like ia64), the variable has to be set to an OpenFirmware device name.
2004-04-02 07:33:35 +00:00
if (OF_getprop(options, "input-device", dev, devsz) == -1)
return (-1);
if ((input = OF_finddevice(dev)) == -1)
return (-1);
To quote submitter: "... uart_cpu_sparc64.c currently only looks at /options if ttyX is the selected console. However, there's one case where it should additionally look at /chosen. If "keyboard" is the selected input- device and "screen" the output-device (both via /options) but the keyboard is unplugged, OF automatically switches to ttya for the console. It even prints a line telling so on "screen". Solaris respects this behaviour and uses ttya as the console in this case and people probably expect FreeBSD to do the same (it's also very handy to temporarily switch consoles)..." Submitted by: Marius Strobl <marius@alchemy.franken.de> Has no doubt the change is correct: marcel
2004-04-04 05:06:26 +00:00
if (OF_getprop(options, "output-device", buf, sizeof(buf)) == -1)
Allow the selection of a debug port with hw.uart.dbgport. Unlike other architectures (like ia64), the variable has to be set to an OpenFirmware device name.
2004-04-02 07:33:35 +00:00
return (-1);
To quote submitter: "... uart_cpu_sparc64.c currently only looks at /options if ttyX is the selected console. However, there's one case where it should additionally look at /chosen. If "keyboard" is the selected input- device and "screen" the output-device (both via /options) but the keyboard is unplugged, OF automatically switches to ttya for the console. It even prints a line telling so on "screen". Solaris respects this behaviour and uses ttya as the console in this case and people probably expect FreeBSD to do the same (it's also very handy to temporarily switch consoles)..." Submitted by: Marius Strobl <marius@alchemy.franken.de> Has no doubt the change is correct: marcel
2004-04-04 05:06:26 +00:00
if (!strcmp(dev, "keyboard") && !strcmp(buf, "screen")) {
if ((chosen = OF_finddevice("/chosen")) == -1)
return (-1);
if (OF_getprop(chosen, "stdin", &stdin, sizeof(stdin)) == -1)
return (-1);
if ((input = OF_instance_to_package(stdin)) == -1)
return (-1);
if (OF_getprop(chosen, "stdout", &stdout, sizeof(stdout)) == -1)
return (-1);
if (OF_instance_to_package(stdout) != input)
return (-1);
snprintf(dev, devsz, "ttya");
} else if (OF_finddevice(buf) != input)
Allow the selection of a debug port with hw.uart.dbgport. Unlike other architectures (like ia64), the variable has to be set to an OpenFirmware device name.
2004-04-02 07:33:35 +00:00
return (-1);
To quote submitter: "... uart_cpu_sparc64.c currently only looks at /options if ttyX is the selected console. However, there's one case where it should additionally look at /chosen. If "keyboard" is the selected input- device and "screen" the output-device (both via /options) but the keyboard is unplugged, OF automatically switches to ttya for the console. It even prints a line telling so on "screen". Solaris respects this behaviour and uses ttya as the console in this case and people probably expect FreeBSD to do the same (it's also very handy to temporarily switch consoles)..." Submitted by: Marius Strobl <marius@alchemy.franken.de> Has no doubt the change is correct: marcel
2004-04-04 05:06:26 +00:00
if (OF_getprop(input, "device_type", buf, sizeof(buf)) == -1)
Allow the selection of a debug port with hw.uart.dbgport. Unlike other architectures (like ia64), the variable has to be set to an OpenFirmware device name.
2004-04-02 07:33:35 +00:00
return (-1);
To quote submitter: "... uart_cpu_sparc64.c currently only looks at /options if ttyX is the selected console. However, there's one case where it should additionally look at /chosen. If "keyboard" is the selected input- device and "screen" the output-device (both via /options) but the keyboard is unplugged, OF automatically switches to ttya for the console. It even prints a line telling so on "screen". Solaris respects this behaviour and uses ttya as the console in this case and people probably expect FreeBSD to do the same (it's also very handy to temporarily switch consoles)..." Submitted by: Marius Strobl <marius@alchemy.franken.de> Has no doubt the change is correct: marcel
2004-04-04 05:06:26 +00:00
if (strcmp(buf, "serial") != 0)
Allow the selection of a debug port with hw.uart.dbgport. Unlike other architectures (like ia64), the variable has to be set to an OpenFirmware device name.
2004-04-02 07:33:35 +00:00
return (-1);
return (input);
}
Allow uart to attach to keyboards that are not the firmware's notion of stdin, such as when using a serial console. We must recognize these devices here so that we can override the tty attach routine.
2003-11-11 06:52:04 +00:00
Allow the selection of a debug port with hw.uart.dbgport. Unlike other architectures (like ia64), the variable has to be set to an OpenFirmware device name.
2004-04-02 07:33:35 +00:00
/*
- Don't blindly use the return value of uart_cpu_channel() to calculate the address of a channel on a SCC, it returns 0 on failure. [1] - Hardcode channel 1 for the keyboard on Z8530, the information present in the Open Firmware device tree doesn't allow to determine this via uart_cpu_channel(). This makes the keyboard (if one backs out rev. 1.5 of sys/dev/puc/puc_sbus.c and has both keyboard and mouse plugged in to avoid the hang that revision works around) and consequently syscons(4) on Ultra 2 work. There's a problem with the keyboard LEDs similar to the one on Ultra 60 (LEDs don't get lit under X) though, instead of lighting just a specific single one all get lit and can't be turned off again. [1] - Add comments about what uart_cpu_channel() and uart_cpu_getdev_keyboard() do and their constraints. - Improve the comments about what uart_cpu_getdev_[console,dbgport]() do, they don't return an address (as in bus) but an Open Firmware package handle. Reviewed by: marcel (modulo the comments) [1]
2004-11-28 16:00:36 +00:00
* Get the package handle of the UART that's selected as the debug port.
* Since there's no place for this in the OF, we use the kernel environment
Allow the selection of a debug port with hw.uart.dbgport. Unlike other architectures (like ia64), the variable has to be set to an OpenFirmware device name.
2004-04-02 07:33:35 +00:00
* variable "hw.uart.dbgport". Note however that the variable is not a
* list of attributes. It's single device name or alias, as known by
* the OF.
*/
static phandle_t
uart_cpu_getdev_dbgport(phandle_t options, char *dev, size_t devsz)
{
char buf[32];
phandle_t input;
if (!getenv_string("hw.uart.dbgport", dev, devsz))
return (-1);
if ((input = OF_finddevice(dev)) == -1)
return (-1);
if (OF_getprop(input, "device_type", buf, sizeof(buf)) == -1)
return (-1);
if (strcmp(buf, "serial") != 0)
return (-1);
return (input);
}
- Don't blindly use the return value of uart_cpu_channel() to calculate the address of a channel on a SCC, it returns 0 on failure. [1] - Hardcode channel 1 for the keyboard on Z8530, the information present in the Open Firmware device tree doesn't allow to determine this via uart_cpu_channel(). This makes the keyboard (if one backs out rev. 1.5 of sys/dev/puc/puc_sbus.c and has both keyboard and mouse plugged in to avoid the hang that revision works around) and consequently syscons(4) on Ultra 2 work. There's a problem with the keyboard LEDs similar to the one on Ultra 60 (LEDs don't get lit under X) though, instead of lighting just a specific single one all get lit and can't be turned off again. [1] - Add comments about what uart_cpu_channel() and uart_cpu_getdev_keyboard() do and their constraints. - Improve the comments about what uart_cpu_getdev_[console,dbgport]() do, they don't return an address (as in bus) but an Open Firmware package handle. Reviewed by: marcel (modulo the comments) [1]
2004-11-28 16:00:36 +00:00
/*
* Get the package handle of the device that is selected as the keyboard
* port.
* XXX this also matches PS/2 keyboard controllers and most likely also
* USB keyboards.
*/
Allow the selection of a debug port with hw.uart.dbgport. Unlike other architectures (like ia64), the variable has to be set to an OpenFirmware device name.
2004-04-02 07:33:35 +00:00
static phandle_t
uart_cpu_getdev_keyboard(phandle_t root, char *dev, size_t devsz)
{
char buf[32];
phandle_t child, node;
child = OF_child(root);
while (child != 0 && child != -1) {
Allow uart to attach to keyboards that are not the firmware's notion of stdin, such as when using a serial console. We must recognize these devices here so that we can override the tty attach routine.
2003-11-11 06:52:04 +00:00
if (OF_getprop(child, "device_type", buf, sizeof(buf)) != -1 &&
!strcmp(buf, "serial") &&
Allow the selection of a debug port with hw.uart.dbgport. Unlike other architectures (like ia64), the variable has to be set to an OpenFirmware device name.
2004-04-02 07:33:35 +00:00
OF_getprop(child, "keyboard", buf, sizeof(buf)) != -1) {
OF_getprop(child, "name", dev, devsz);
Allow uart to attach to keyboards that are not the firmware's notion of stdin, such as when using a serial console. We must recognize these devices here so that we can override the tty attach routine.
2003-11-11 06:52:04 +00:00
return (child);
Allow the selection of a debug port with hw.uart.dbgport. Unlike other architectures (like ia64), the variable has to be set to an OpenFirmware device name.
2004-04-02 07:33:35 +00:00
}
if ((node = uart_cpu_getdev_keyboard(child, dev, devsz)) != -1)
Allow uart to attach to keyboards that are not the firmware's notion of stdin, such as when using a serial console. We must recognize these devices here so that we can override the tty attach routine.
2003-11-11 06:52:04 +00:00
return (node);
Allow the selection of a debug port with hw.uart.dbgport. Unlike other architectures (like ia64), the variable has to be set to an OpenFirmware device name.
2004-04-02 07:33:35 +00:00
child = OF_peer(child);
Allow uart to attach to keyboards that are not the firmware's notion of stdin, such as when using a serial console. We must recognize these devices here so that we can override the tty attach routine.
2003-11-11 06:52:04 +00:00
}
return (-1);
}
The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten.
2003-09-06 23:13:47 +00:00
int
uart_cpu_getdev(int devtype, struct uart_devinfo *di)
{
When determining the device class to use for the serial console, check the "compatible" property too in the ns8250 case. This gets the serial console to work on Blade 100s, where the device name is just "serial". Reviewed by: marcel
2003-09-12 20:13:23 +00:00
char buf[32], dev[32], compat[32];
Allow the selection of a debug port with hw.uart.dbgport. Unlike other architectures (like ia64), the variable has to be set to an OpenFirmware device name.
2004-04-02 07:33:35 +00:00
phandle_t input, options;
The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten.
2003-09-06 23:13:47 +00:00
bus_addr_t addr;
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
int baud, bits, error, space, stop;
The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten.
2003-09-06 23:13:47 +00:00
char flag, par;
Allow the selection of a debug port with hw.uart.dbgport. Unlike other architectures (like ia64), the variable has to be set to an OpenFirmware device name.
2004-04-02 07:33:35 +00:00
if ((options = OF_finddevice("/options")) == -1)
return (ENXIO);
switch (devtype) {
case UART_DEV_CONSOLE:
input = uart_cpu_getdev_console(options, dev, sizeof(dev));
break;
case UART_DEV_DBGPORT:
input = uart_cpu_getdev_dbgport(options, dev, sizeof(dev));
break;
case UART_DEV_KEYBOARD:
input = uart_cpu_getdev_keyboard(OF_peer(0), dev, sizeof(dev));
break;
default:
input = -1;
break;
}
if (input == -1)
return (ENXIO);
- Re-write OF_decode_addr() with a bus-neutral approach, adding support for nodes hanging off of Central (untested), FireHose (untested) and PCI (tested) busses. - Add an additional parameter to OF_decode_addr() which specifies the index of the register bank to decode. These should allow to eventually add support for the Z8530 hanging off of FireHose to uart(4) and to write support for PCI-based graphics adapters. Suggested by: tmm (back in '03)
2005-02-12 19:13:51 +00:00
error = OF_decode_addr(input, 0, &space, &addr);
The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten.
2003-09-06 23:13:47 +00:00
if (error)
return (error);
/* Get the device class. */
if (OF_getprop(input, "name", buf, sizeof(buf)) == -1)
return (ENXIO);
When determining the device class to use for the serial console, check the "compatible" property too in the ns8250 case. This gets the serial console to work on Blade 100s, where the device name is just "serial". Reviewed by: marcel
2003-09-12 20:13:23 +00:00
if (OF_getprop(input, "compatible", compat, sizeof(compat)) == -1)
compat[0] = '\0';
The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten.
2003-09-06 23:13:47 +00:00
di->bas.regshft = 0;
di->bas.rclk = 0;
if (!strcmp(buf, "se")) {
di->ops = uart_sab82532_ops;
- Don't blindly use the return value of uart_cpu_channel() to calculate the address of a channel on a SCC, it returns 0 on failure. [1] - Hardcode channel 1 for the keyboard on Z8530, the information present in the Open Firmware device tree doesn't allow to determine this via uart_cpu_channel(). This makes the keyboard (if one backs out rev. 1.5 of sys/dev/puc/puc_sbus.c and has both keyboard and mouse plugged in to avoid the hang that revision works around) and consequently syscons(4) on Ultra 2 work. There's a problem with the keyboard LEDs similar to the one on Ultra 60 (LEDs don't get lit under X) though, instead of lighting just a specific single one all get lit and can't be turned off again. [1] - Add comments about what uart_cpu_channel() and uart_cpu_getdev_keyboard() do and their constraints. - Improve the comments about what uart_cpu_getdev_[console,dbgport]() do, they don't return an address (as in bus) but an Open Firmware package handle. Reviewed by: marcel (modulo the comments) [1]
2004-11-28 16:00:36 +00:00
/* SAB82532 are only known to be used for TTYs. */
if ((di->bas.chan = uart_cpu_channel(dev)) == 0)
return (ENXIO);
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
addr += 64 * (di->bas.chan - 1);
The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten.
2003-09-06 23:13:47 +00:00
} else if (!strcmp(buf, "zs")) {
di->ops = uart_z8530_ops;
- Don't blindly use the return value of uart_cpu_channel() to calculate the address of a channel on a SCC, it returns 0 on failure. [1] - Hardcode channel 1 for the keyboard on Z8530, the information present in the Open Firmware device tree doesn't allow to determine this via uart_cpu_channel(). This makes the keyboard (if one backs out rev. 1.5 of sys/dev/puc/puc_sbus.c and has both keyboard and mouse plugged in to avoid the hang that revision works around) and consequently syscons(4) on Ultra 2 work. There's a problem with the keyboard LEDs similar to the one on Ultra 60 (LEDs don't get lit under X) though, instead of lighting just a specific single one all get lit and can't be turned off again. [1] - Add comments about what uart_cpu_channel() and uart_cpu_getdev_keyboard() do and their constraints. - Improve the comments about what uart_cpu_getdev_[console,dbgport]() do, they don't return an address (as in bus) but an Open Firmware package handle. Reviewed by: marcel (modulo the comments) [1]
2004-11-28 16:00:36 +00:00
if ((di->bas.chan = uart_cpu_channel(dev)) == 0) {
/*
* There's no way to determine from OF which
* channel has the keyboard. Should always be
* on channel 1 however.
*/
if (devtype == UART_DEV_KEYBOARD)
di->bas.chan = 1;
else
return (ENXIO);
}
The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten.
2003-09-06 23:13:47 +00:00
di->bas.regshft = 1;
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
addr += 4 - 4 * (di->bas.chan - 1);
When determining the device class to use for the serial console, check the "compatible" property too in the ns8250 case. This gets the serial console to work on Blade 100s, where the device name is just "serial". Reviewed by: marcel
2003-09-12 20:13:23 +00:00
} else if (!strcmp(buf, "su") || !strcmp(buf, "su_pnp") ||
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
!strcmp(compat, "su") || !strcmp(compat, "su16550")) {
The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten.
2003-09-06 23:13:47 +00:00
di->ops = uart_ns8250_ops;
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;
} else
The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten.
2003-09-06 23:13:47 +00:00
return (ENXIO);
/* Fill in the device info. */
di->bas.bst = &bst_store[devtype];
di->bas.bsh = sparc64_fake_bustag(space, addr, di->bas.bst);
/* Get the line settings. */
Set the baud rate to 1200 if the device is a keyboard.
2003-09-28 07:06:34 +00:00
if (devtype == UART_DEV_KEYBOARD)
di->baudrate = 1200;
else
di->baudrate = 9600;
The uart(4) driver is an universal driver for various UART hardware. It improves on sio(4) in the following areas: o Fully newbusified to allow for memory mapped I/O. This is a must for ia64 and sparc64, o Machine dependent code to take full advantage of machine and firm- ware specific ways to define serial consoles and/or debug ports. o Hardware abstraction layer to allow the driver to be used with various UARTs, such as the well-known ns8250 family of UARTs, the Siemens sab82532 or the Zilog Z8530. This is especially important for pc98 and sparc64 where it's common to have different UARTs, o The notion of system devices to unkludge low-level consoles and remote gdb ports and provides the mechanics necessary to support the keyboard on sparc64 (which is UART based). o The notion of a kernel interface so that a UART can be tied to something other than the well-known TTY interface. This is needed on sparc64 to present the user with a device and ioctl handling suitable for a keyboard, but also allows us to cleanly hide an UART when used as a debug port. Following is a list of features and bugs/flaws specific to the ns8250 family of UARTs as compared to their support in sio(4): o The uart(4) driver determines the FIFO size and automaticly takes advantages of larger FIFOs and/or additional features. Note that since I don't have sufficient access to 16[679]5x UARTs, hardware flow control has not been enabled. This is almost trivial to do, provided one can test. The downside of this is that broken UARTs are more likely to not work correctly with uart(4). The need for tunables or knobs may be large enough to warrant their creation. o The uart(4) driver does not share the same bumpy history as sio(4) and will therefore not provide the necessary hooks, tweaks, quirks or work-arounds to deal with once common hardware. To that extend, uart(4) supports a subset of the UARTs that sio(4) supports. The question before us is whether the subset is sufficient for current hardware. o There is no support for multiport UARTs in uart(4). The decision behind this is that uart(4) deals with one EIA RS232-C interface. Packaging of multiple interfaces in a single chip or on a single expansion board is beyond the scope of uart(4) and is now mostly left for puc(4) to deal with. Lack of hardware made it impossible to actually implement such a dependency other than is present for the dual channel SAB82532 and Z8350 SCCs. The current list of missing features is: o No configuration capabilities. A set of tunables and sysctls is being worked out. There are likely not going to be any or much compile-time knobs. Such configuration does not fit well with current hardware. o No support for the PPS API. This is partly dependent on the ability to configure uart(4) and partly dependent on having sufficient information to implement it properly. As usual, the manpage is present but lacks the attention the software has gotten.
2003-09-06 23:13:47 +00:00
di->databits = 8;
di->stopbits = 1;
di->parity = UART_PARITY_NONE;
snprintf(buf, sizeof(buf), "%s-mode", dev);
if (OF_getprop(options, buf, buf, sizeof(buf)) == -1)
return (0);
if (sscanf(buf, "%d,%d,%c,%d,%c", &baud, &bits, &par, &stop, &flag)
!= 5)
return (0);
di->baudrate = baud;
di->databits = bits;
di->stopbits = stop;
di->parity = (par == 'n') ? UART_PARITY_NONE :
(par == 'o') ? UART_PARITY_ODD : UART_PARITY_EVEN;
return (0);
}
Reference in New Issue Copy Permalink