summaryrefslogtreecommitdiffstats
path: root/sys/pc98/cbus
Commit message (Collapse)AuthorAgeFilesLines
* Comply with the new cyclic dtrace module variable namerpaulo2010-04-211-2/+2
| | | | (cyclic_clock_func).
* Default the machdep.lapic_allclocks to be enabled in order to cope withattilio2010-04-091-1/+1
| | | | | | | | | | broken atrtc. Now if you want more correct stats on profhz and stathz it may be disabled by setting to 0. Reported by: A. Akephalos <akephalos dot akephalos at gmail dot com>, Jakub Lach <jakub_lach at mailplus dot pl> MFC: 1 week
* MFx86: the part of r204641nyan2010-03-051-2/+7
| | | | | | | | | In order to do that cleanly, lapic_setup_clock(), on both ia32 and amd64, now accepts as arguments the desired sources to handle, and returns the actual ones (LAPIC_CLOCK_NONE is forbidden because otherwise there is no meaning in calling such function). This allows to bring out into commont x86 code the handling part for machdep.lapic_allclocks tunable, which is retained.
* - Allow clock subsystem to be compiled without the apic support [0]attilio2010-01-171-2/+0
| | | | | | | | - ATPIC, on pc98 is never defined somewhere, differently from i386. Turn its compilation to be conditional as i386 does. [1] [0] Reported by: nyan [1] Submitted by: nyan
* Handling all the three clocks (hardclock, softclock, profclock) with theattilio2010-01-151-4/+5
| | | | | | | | | | | | | | | | | | LAPIC may lead to aliasing for softclock and profclock because frequencies are sized in order to fit mainly hardclock. atrtc used to take care of the softclock and profclock and it does still do, if the LAPIC can't handle the clocks properly. Revert the change when the LAPIC started taking charge of all three of them and let atrtc handle softclock and profclock if not explicitly requested. Such request can be made setting != 0 the new tunable machdep.lapic_allclocks or if the new device ATPIC is not present within the i386 kernel config (atrtc is linked to atpic presence). Diagnosed by: Sandvine Incorporated Reviewed by: jhb, emaste Sponsored by: Sandvine Incorporated MFC: 3 weeks
* Update d_mmap() to accept vm_ooffset_t and vm_memattr_t.rnoland2009-12-291-4/+5
| | | | | | | | | | | | | This replaces d_mmap() with the d_mmap2() implementation and also changes the type of offset to vm_ooffset_t. Purge d_mmap2(). All driver modules will need to be rebuilt since D_VERSION is also bumped. Reviewed by: jhb@ MFC after: Not in this lifetime...
* MFi386: revision 199104nyan2009-11-121-16/+62
| | | | Make isa_dma functions MPSAFE by introducing its own private lock.
* Allow Syscons terminal emulators to provide function key strings.ed2009-11-111-8/+17
| | | | | | | | | xterm and cons25 have some incompatibilities when it comes to escape sequences for special keys, such as F1 to F12, home, end, etc. Add a new te_fkeystr() that can be used to override the strings. scterm-sck won't do anything with this, but scterm-teken will use teken_get_sequences() to obtain the proper sequence.
* Temporarily revert the new-bus locking for 8.0 release. It will bejhb2009-08-201-6/+0
| | | | | | reintroduced after HEAD is reopened for commits by re@. Approved by: re (kib), attilio
* Make the newbus subsystem Giant free by adding the new newbus sxlock.attilio2009-08-021-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The newbus lock is responsible for protecting newbus internIal structures, device states and devclass flags. It is necessary to hold it when all such datas are accessed. For the other operations, softc locking should ensure enough protection to avoid races. Newbus lock is automatically held when virtual operations on the device and bus are invoked when loading the driver or when the suspend/resume take place. For other 'spourious' operations trying to access/modify the newbus topology, newbus lock needs to be automatically acquired and dropped. For the moment Giant is also acquired in some key point (modules subsystem) in order to avoid problems before the 8.0 release as module handlers could make assumptions about it. This Giant locking should go just after the release happens. Please keep in mind that the public interface can be expanded in order to provide more support, if there are really necessities at some point and also some bugs could arise as long as the patch needs a bit of further testing. Bump __FreeBSD_version in order to reflect the newbus lock introduction. Reviewed by: ed, hps, jhb, imp, mav, scottl No answer by: ariff, thompsa, yongari Tested by: pho, G. Trematerra <giovanni dot trematerra at gmail dot com>, Brandon Gooch <jamesbrandongooch at gmail dot com> Sponsored by: Yahoo! Incorporated Approved by: re (ksmith)
* Reduce diffs against i386.nyan2009-05-061-4/+1
| | | | Use the hardclockintr function.
* Rename statclock_disable variable to atrtcclock_disable that it actually is,mav2009-05-031-1/+0
| | | | | | | | | | | | | and hide it inside of atrtc driver. Add new tunable hint.atrtc.0.clock controlling it. Setting it to 0 disables using RTC clock as stat-/ profclock sources. Teach i386 and amd64 SMP platforms to emulate stat-/profclocks using i8254 hardclock, when LAPIC and RTC clocks are disabled. This allows to reduce global interrupt rate of idle system down to about 100 interrupts per core, permitting C3 and deeper C-states provide maximum CPU power efficiency.
* MFi386: revision 191745nyan2009-05-031-1/+35
| | | | | Add support for using i8254 and rtc timers as event sources for i386 SMP system. Redistribute hard-/stat-/profclock events to other CPUs using IPI.
* Migrate the olpt(4) driver to si_drv1 instead of using dev2unit().ed2009-04-151-19/+13
| | | | Approved by: nyan
* Make a 1:1 mapping between syscons stats and terminal emulators.ed2009-03-101-1/+9
| | | | | | | | | | | | | | | | | | | | After I imported libteken into the source tree, I noticed syscons didn't store the cursor position inside the terminal emulator, but inside the virtual terminal stat. This is not very useful, because when you implement more complex forms of line wrapping, you need to keep track of more state than just the cursor position. Because the kernel messages didn't share the same terminal emulator as ttyv0, this caused a lot of strange things, like kernel messages being misplaced and a missing notification to resize the terminal emulator for kernel messages never to be resized when using vidcontrol. This patch just removes kernel_console_ts and adds a special parameter to te_puts to determine whether messages should be printed using regular colors or the ones for kernel messages. Reported by: ache Tested by: nyan, garga (older version)
* MFi386: part of 189421nyan2009-03-061-2/+4
| | | | | - If there are no syscons hints at all, assume there is a single sc0 device anyway. The console probe will still fail unless a VGA adapter is found.
* Replace syscons terminal renderer by a new renderer that uses libteken.ed2009-01-012-5/+433
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some time ago I started working on a library called libteken, which is terminal emulator. It does not buffer any screen contents, but only keeps terminal state, such as cursor position, attributes, etc. It should implement all escape sequences that are implemented by the cons25 terminal emulator, but also a fair amount of sequences that are present in VT100 and xterm. A lot of random notes, which could be of interest to users/developers: - Even though I'm leaving the terminal type set to `cons25', users can do experiments with placing `xterm-color' in /etc/ttys. Because we only implement a subset of features of xterm, this may cause artifacts. We should consider extending libteken, because in my opinion xterm is the way to go. Some missing features: - Keypad application mode (DECKPAM) - Character sets (SCS) - libteken is filled with a fair amount of assertions, but unfortunately we cannot go into the debugger anymore if we fail them. I've done development of this library almost entirely in userspace. In sys/dev/syscons/teken there are two applications that can be helpful when debugging the code: - teken_demo: a terminal emulator that can be started from a regular xterm that emulates a terminal using libteken. This application can be very useful to debug any rendering issues. - teken_stress: a stress testing application that emulates random terminal output. libteken has literally survived multiple terabytes of random input. - libteken also includes support for UTF-8, but unfortunately our input layer and font renderer don't support this. If users want to experiment with UTF-8 support, they can enable `TEKEN_UTF8' in teken.h. If you recompile your kernel or the teken_demo application, you can hold some nice experiments. - I've left PC98 the way it is right now. The PC98 platform has a custom syscons renderer, which supports some form of localised input. Maybe we should port PC98 to libteken by the time syscons supports UTF-8? - I've removed the `dumb' terminal emulator. It has been broken for years. It hasn't survived the `struct proc' -> `struct thread' conversion. - To prevent confusion among people that want to hack on libteken: unlike syscons, the state machines that parse the escape sequences are machine generated. This means that if you want to add new escape sequences, you have to add an entry to the `sequences' file. This will cause new entries to be added to `teken_state.h'. - Any rendering artifacts that didn't occur prior to this commit are by accident. They should be reported to me, so I can fix them. Discussed on: current@, hackers@ Discussed with: philip (at 25C3)
* Replace all calls to minor() with dev2unit().ed2008-09-272-6/+6
| | | | | | | | | | | | | | | After I removed all the unit2minor()/minor2unit() calls from the kernel yesterday, I realised calling minor() everywhere is quite confusing. Character devices now only have the ability to store a unit number, not a minor number. Remove the confusion by using dev2unit() everywhere. This commit could also be considered as a bug fix. A lot of drivers call minor(), while they should actually be calling dev2unit(). In -CURRENT this isn't a problem, but it turns out we never had any problem reports related to that issue in the past. I suspect not many people connect more than 256 pieces of the same hardware. Reviewed by: kib
* - Cleanup i8251 related defines.nyan2008-09-071-34/+32
| | | | - Move i8255 related defines into a separate file.
* Integrate the new MPSAFE TTY layer to the FreeBSD operating system.ed2008-08-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The last half year I've been working on a replacement TTY layer for the FreeBSD kernel. The new TTY layer was designed to improve the following: - Improved driver model: The old TTY layer has a driver model that is not abstract enough to make it friendly to use. A good example is the output path, where the device drivers directly access the output buffers. This means that an in-kernel PPP implementation must always convert network buffers into TTY buffers. If a PPP implementation would be built on top of the new TTY layer (still needs a hooks layer, though), it would allow the PPP implementation to directly hand the data to the TTY driver. - Improved hotplugging: With the old TTY layer, it isn't entirely safe to destroy TTY's from the system. This implementation has a two-step destructing design, where the driver first abandons the TTY. After all threads have left the TTY, the TTY layer calls a routine in the driver, which can be used to free resources (unit numbers, etc). The pts(4) driver also implements this feature, which means posix_openpt() will now return PTY's that are created on the fly. - Improved performance: One of the major improvements is the per-TTY mutex, which is expected to improve scalability when compared to the old Giant locking. Another change is the unbuffered copying to userspace, which is both used on TTY device nodes and PTY masters. Upgrading should be quite straightforward. Unlike previous versions, existing kernel configuration files do not need to be changed, except when they reference device drivers that are listed in UPDATING. Obtained from: //depot/projects/mpsafetty/... Approved by: philip (ex-mentor) Discussed: on the lists, at BSDCan, at the DevSummit Sponsored by: Snow B.V., the Netherlands dcons(4) fixed by: kan
* MFi386: revision 1.249nyan2008-05-241-0/+17
| | | | Add a cyclic hook for DTrace.
* Expand kdb_alt_break a little, most commonly used with the optionpeter2008-05-041-4/+23
| | | | | | | | | | | | | | | | | | | ALT_BREAK_TO_DEBUGGER. In addition to "Enter ~ ctrl-B" (to enter the debugger), there is now "Enter ~ ctrl-P" (force panic) and "Enter ~ ctrl-R" (request clean reboot, ala ctrl-alt-del on syscons). We've used variations of this at work. The force panic sequence is best used with KDB_UNATTENDED for when you just want it to dump and get on with it. The reboot request is a safer way of getting into single user than a power cycle. eg: you've hosed the ability to log in (pam, rtld, etc). It gives init the reboot signal, which causes an orderly reboot. I've taken my best guess at what the !x86 and non-sio code changes should be. This also makes sio release its spinlock before calling KDB/DDB.
* Now that all platforms use genclock, shuffle things around slightlyphk2008-04-221-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | for better structure. Much of this is related to <sys/clock.h>, which should really have been called <sys/calendar.h>, but unless and until we need the name, the repocopy can wait. In general the kernel does not know about minutes, hours, days, timezones, daylight savings time, leap-years and such. All that is theoretically a matter for userland only. Parts of kernel code does however care: badly designed filesystems store timestamps in local time and RTC chips almost universally track time in a YY-MM-DD HH:MM:SS format, and sometimes in local timezone instead of UTC. For this we have <sys/clock.h> <sys/time.h> on the other hand, deals with time_t, timeval, timespec and so on. These know only seconds and fractions thereof. Move inittodr() and resettodr() prototypes to <sys/time.h>. Retain the names as it is one of the few surviving PDP/VAX references. Move startrtclock() to <machine/clock.h> on relevant platforms, it is a MD call between machdep.c/clock.c. Remove references to it elsewhere. Remove a lot of unnecessary <sys/clock.h> includes. Move the machdep.disable_rtc_set sysctl to subr_rtc.c where it belongs. XXX: should be kern.disable_rtc_set really, it's not MD.
* MFi386: Merge yet another the RTC related work.nyan2008-04-192-739/+15
| | | | Split the pcrtc driver into pcrtc.c which is repo-copied from clock.c
* MFi386: RTC related cleanups.nyan2008-04-132-282/+428
| | | | | | | | - Use generic RTC handling code. - Make clock_if.m and subr_rtc.c standard. - Nuke MD inittodr(), resettodr() functions. - Add new "pcrtc" device driver. - Add hints for "pcrtc" driver.
* Always set the bell_pitch to 800. This catch up with the sysbeep() argumentnyan2008-04-082-8/+1
| | | | changing.
* Back in the good old days, PC's had random pieces of rock forphk2008-03-262-196/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | frequency generation and what frequency the generated was anyones guess. In general the 32.768kHz RTC clock x-tal was the best, because that was a regular wrist-watch Xtal, whereas the X-tal generating the ISA bus frequency was much lower quality, often costing as much as several cents a piece, so it made good sense to check the ISA bus frequency against the RTC clock. The other relevant property of those machines, is that they typically had no more than 16MB RAM. These days, CPU chips croak if their clocks are not tightly within specs and all necessary frequencies are derived from the master crystal by means if PLL's. Considering that it takes on average 1.5 second to calibrate the frequency of the i8254 counter, that more likely than not, we will not actually use the result of the calibration, and as the final clincher, we seldom use the i8254 for anything besides BEL in syscons anyway, it has become time to drop the calibration code. If you need to tell the system what frequency your i8254 runs, you can do so from the loader using hw.i8254.freq or using the sysctl kern.timecounter.tc.i8254.frequency.
* Further cleanup of sound generation in syscons:phk2008-03-261-8/+0
| | | | | | | | The timer_spkr_*() functions take care of the enabling/disabling of the speaker. Test on the existence of timer_spkr_*() functions, rather than architectures.
* The "free-lance" timer in the i8254 is only used for the speakerphk2008-03-263-127/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | these days, so de-generalize the acquire_timer/release_timer api to just deal with speakers. The new (optional) MD functions are: timer_spkr_acquire() timer_spkr_release() and timer_spkr_setfreq() the last of which configures the timer to generate a tone of a given frequency, in Hz instead of 1/1193182th of seconds. Drop entirely timer2 on pc98, it is not used anywhere at all. Move sysbeep() to kern/tty_cons.c and use the timer_spkr*() if they exist, and do nothing otherwise. Remove prototypes and empty acquire-/release-timer() and sysbeep() functions from the non-beeping archs. This eliminate the need for the speaker driver to know about i8254frequency at all. In theory this makes the speaker driver MI, contingent on the timer_spkr_*() functions existing but the driver does not know this yet and still attaches to the ISA bus. Syscons is more tricky, in one function, sc_tone(), it knows the hz and things are just fine. In the other function, sc_bell() it seems to get the period from the KDMKTONE ioctl in terms if 1/1193182th second, so we hardcode the 1193182 and leave it at that. It's probably not important. Change a few other sysbeep() uses which obviously knew that the argument was in terms of i8254 frequency, and leave alone those that look like people thought sysbeep() took frequency in hertz. This eliminates the knowledge of i8254_freq from all but the actual clock.c code and the prof_machdep.c on amd64 and i386, where I think it would be smart to ask for help from the timecounters anyway [TBD].
* Rename timer0_max_count to i8254_max_count.phk2008-03-263-99/+101
| | | | | Rename timer0_real_max_count to i8254_real_max_count and make it static. Rename timer_freq to i8254_freq and make it a loader tunable.
* The RTC related pscnt and psdiv variables have no business being public.phk2008-03-262-4/+0
|
* Merged from sys/dev/sio/sio.c revision 1.472nyan2008-02-291-1/+1
| | | | Stop serial console and gdb serial port from getting all screwed up.
* Use kbdd_* macros.nyan2007-12-301-6/+6
|
* Replace explicit calls to video methods with their respective variantswkoszek2007-12-292-12/+10
| | | | | | | | | | | | | | | implemented with macros. This patch improves code readability. Reasoning behind vidd_* is a sort of "video discipline". List of macros is supposed to be complete--all methods of video_switch ought to have their respective macros from now on. Functionally, this code should be no-op. My intention is to leave current behaviour of touched code as is. No objections: rwatson Silence on: freebsd-current@ Approved by: cognet
* Add a new 'why' argument to kdb_enter(), and a set of constants to userwatson2007-12-251-2/+4
| | | | | | | | | for that argument. This will allow DDB to detect the broad category of reason why the debugger has been entered, which it can use for the purposes of deciding which DDB script to run. Assign approximate why values to all current consumers of the kdb_enter() interface.
* Spelling fix for interupt -> interruptkevlo2007-10-121-1/+1
|
* Mfi386 revision 1.239 of src/sys/i386/isa/clock.c. Seemingly somedwmalone2007-07-292-2/+4
| | | | | | | | | pc98 motherboards do not provide us with the correct day of week either. Ignore the day of week when setting the clock here too. Approved by: re (bmah) Requested from: nyan MFC after: 3 weeks
* If clock_ct_to_ts fails to convert time time from the real time clock,dwmalone2007-07-232-2/+10
| | | | | | | | | print a one line error message. Add some comments on not being able to trust the day of week field (I'll act on these comments in a follow up commit). Approved by: re MFC after: 3 weeks
* In the function pc98_check_if_type for the non-8251 casemjacob2007-07-111-0/+4
| | | | | | | | make sure we initialize fileds in the iod that otherwise would have been initialized. Reviewed by: nate, ken, warner Approved by: re (ken)
* Despite several examples in the kernel, the third argument ofdwmalone2007-06-042-2/+2
| | | | | | | | | | | | | sysctl_handle_int is not sizeof the int type you want to export. The type must always be an int or an unsigned int. Remove the instances where a sizeof(variable) is passed to stop people accidently cut and pasting these examples. In a few places this was sysctl_handle_int was being used on 64 bit types, which would truncate the value to be exported. In these cases use sysctl_handle_quad to export them and change the format to Q so that sysctl(1) can still print them.
* Don't call bus_deactivate_resource() explicitly before callingnyan2007-03-211-12/+0
| | | | | bus_release_resource(). This is needed for pc98 by upcoming nexus related change.
* - Use mtx_{lock,unlock}_spin rather than {disable,enable}_intr.nyan2007-03-042-58/+30
| | | | | | - Remove unnecessary findcpuspeed() function. - Initialize the timer_freq in i8254_init(). - Fix inittodr() and resettodr(). These are broken by rev.1.154.
* Reduce diffs with i386.nyan2007-03-042-12/+20
|
* Use pause() rather than tsleep() on explicit global dummy variables.jhb2007-02-271-2/+1
|
* Garbage collect a reference to INTR_FAST.piso2007-02-252-2/+2
|
* o break newbus api: add a new argument of type driver_filter_t topiso2007-02-231-1/+1
| | | | | | | | | | | | bus_setup_intr() o add an int return code to all fast handlers o retire INTR_FAST/IH_FAST For more info: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=465712+0+current/freebsd-current Approved by: re (implicit?)
* o break newbus api: add a new argument of type driver_filter_t topiso2007-02-235-13/+17
| | | | | | | | | | | | | bus_setup_intr() o add an int return code to all fast handlers o retire INTR_FAST/IH_FAST For more info: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=465712+0+current/freebsd-current Reviewed by: many Approved by: re@
* Oops, pc98 is independent of i386 for clock.c and machdep.c but notbde2007-01-232-24/+18
| | | | | | | | | | | | | | | | | | | | | | | for clock.h, so changing th i386 clock.h broke it. MFi386 (not tested): Cleaned up declaration and initialization of clock_lock. It is only used by clock code, so don't export it to the world for machdep.c to initialize. There is a minor problem initializing it before it is used, since although clock initialization is split up so that parts of it can be done early, the first part was never done early enough to actually work. Split it up a bit more and do the first part as late as possible to document the necessary order. The functions that implement the split are still bogusly exported. Cleaned up initialization of the i8254 clock hardware using the new split. Actually initialize it early enough, and don't work around it not being initialized in DELAY() when DELAY() is called early for initialization of some console drivers. This unfortunately moves a little more code before the early debugger breakpoint so that it is harder to debug. The ordering of console and related initialization is delicate because we want to do as little as possible before the breakpoint, but must initialize a console.
* Sweep kernel replacing suser(9) calls with priv(9) calls, assigningrwatson2006-11-061-3/+4
| | | | | | | | | | | | | specific privilege names to a broad range of privileges. These may require some future tweaking. Sponsored by: nCircle Network Security, Inc. Obtained from: TrustedBSD Project Discussed on: arch@ Reviewed (at least in part) by: mlaier, jmg, pjd, bde, ceri, Alex Lyashkov <umka at sevcity dot net>, Skip Ford <skip dot ford at verizon dot net>, Antoine Brodin <antoine dot brodin at laposte dot net>
* Use Calendrical Calculations from subr_clock.c instead of home copy&pasted.phk2006-10-022-184/+46
|
OpenPOWER on IntegriCloud