src/sys/dev/uart/uart_cpu_sparc64.c, branch release/6.0.0_cvs

This commit was manufactured by cvs2svn to create tag

2005-11-03T00:35:26Z

'RELENG_6_0_0_RELEASE'. This commit was manufactured to restore the state of the 6.0-RELEASE image.

MFC: sys/boot/sparc64/loader/metadata.c 1.14,

2005-08-27T15:52:05Z

sys/dev/uart/uart_cpu_sparc64.c 1.21 - Change the code that determines whether to use a serial console and which serial device to use in that case respectively to not rely on the OFW names of the input/output and stdin/stdout devices. While at it save on some variables and for sys/boot/sparc64/loader/metadata.c move the code in question to a new function md_bootserial() so it can be kept in sync with uart_cpu_getdev_console() more easily. - Adjust the size of some buffers. - Remove the package handle of the '/options' node from the argument list of uart_cpu_getdev_dbgport(). Approved by: re (scottl)

Change the semantics of uart_cpu_getdev_keyboard() to only match SCCs/

2005-06-04T21:33:18Z

UARTs used to connect keyboards and not also PS/2 keyboards and only return their package handle in case the keyboard is the preferred one according to the OFW but otherwise still regardless of whether the keyboard is used for stdin or not. This is simply achieved by looking at the 'keyboard' alias and returning the corresponding package handle in case it refers to a SCC/UART. This is change is done in order to give the keyboard which the OFW or the user selected in OFW on boards that support additional types of keyboards besides the RS232 ones also preference in FreeBSD. It will be also used to determine on Sun AXi and Sun AXmp boards whether a PS/2 or a RS232 is to be used as these are sort of mutual exclusive there (see upcoming commit to uart_bus_ebus.c). Note that Tatung AXi boards have the same issue but the former code happened to already give the PS/2 keyboard preference by not identifying the respective UART as keyboard system device there because the PS/2 keyboard node precedes the keyboard UART one in the OFW device tree of these boards (which isn't the case for the Sun AXi). Ok'ed by: marcel

In uart_cpu_getdev_console() when determinig whether we should use

2005-03-12T17:06:03Z

a serial console anyway because input-device is set to keyboard and output-device is set to screen but no keyboard is plugged in don't assume that a device node for the input-device alias exists. While this is true for RS232 keyboards (the node of the SCC and UART respectively which controls the keyboard doesn't disappear when no keyboard is plugged in) this assumption breaks for USB keyboards. It's most likely also not true for PS/2 keyboards but OFW doesn't reliably switch to a serial console when the potential keyboard is a PS/2 one which isn't plugged in so this couldn't be verified properly. Reported by: Will Andrews , obrien MFC after: 1 week

- Re-write OF_decode_addr() with a bus-neutral approach, adding support

2005-02-12T19:13:51Z

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)

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

2005-01-06T01:43:34Z

- Don't blindly use the return value of uart_cpu_channel() to calculate

2004-11-28T16:00:36Z

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]

Remove the whole uart_cpu_identify() stuff again. Now that it's no longer

2004-11-17T20:01:43Z

used on sparc64 they are only stubs on all architectures and it doesn't look like if we would need it in the near future again. Ok'ed by: marcel

o sparc64/isa/isa.c:

2004-11-17T14:44:10Z

- The claim in the commit log of rev. 1.11 of dev/uart/uart_cpu_sparc64.c etc. that UARTs are the only relevant ISA devices on sparc64 turned out to be false. While there are sparc64 models where UARTs are the only devices on the ISA bus there are in fact also low-cost models where all devices traditionally found on the EBus are hooked up to the ISA bus. There are also models that use a mix between EBus and ISA devices with things like an AT keyboard controller and other rather interesting devices that we might want to support in the futute hook up to the ISA bus. In order to not need to add sparc64 specific device_identify methods to all of the respective ISA drivers and also not add OFW specific code to the common ISA code make the sparc64 ISA bus code fake up PnP devices so most ISA drivers probe their devices without further changes. Unfortunately Sun doesn't adhere to the ISA bindings defined in IEEE 1275-1994 for the properties of most of the ISA devices which would allow to obtain the vendor and logical IDs from their properties. So we we just use a simple table which maps the name properties to PnP IDs. This could be done in a more sophisticated way but I courrently don't see the need for this. [1] - Add the children with fully mapped and specified resources (in the OFW sense) similar to what is done in the EBus code for the IRQ resources of the children as adjusting the resources and the resource list entries respectively in isa_alloc_resource() as done perviously causes trouble with drivers which use rman_get_start(), pass-through or allocate and release resources multiple times, etc. Adjusting the resources might be better off in a bus_activate_resource method but the common ISA code currently doesn't allow for an isa_activate_resource(). [2] With this change: - ppbus(4) and lpt(4) attach and work (modulo ECP mode, which requires real ISADMA code but it currently only consists of stubs on sparc64). - atkbdc(4) and atkbdc(4) attach, no further testing done. - fdc(4) itself attaches but causes a hang while attaching fd0 also when is DMA disabled, further work in fdc(4) is required here as e.g. fd0 uses the address of fd1 on sparc64 (not sure if sparc64 supports more than one floppy drive at all). All of these drivers previously caused panics in the sparc64 ISA code. - Minor changes, e.g. use __FBSDID, remove a dupe word in a comment and declare one global variable which isn't used outside of isa.c static. o dev/uart/uart_cpu_sparc64.c and modules/uart/Makefile: - Remove the code for registering the UARTs on the ISA bus from the sparc64 uart_cpu_identify() again and rely on probing them via PnP. Original idea by: tmm [1] No objections by: tmm [1], [2]

Fix a style(9) bug (variable definitions inside a nested scope) a patch

2004-08-15T02:17:20Z

of mine introduced in revision 1.10. Approved by: marcel Prodded by: marcel