-current. It doesn't work yet as stable as the 3.x/PAO version of the
driver does, however, i get occasional `FDC direction bit not set' and
other weird messages, but it basically works at least.
The old (defunct) #ifdef FDC_YE stuff has been eliminated completely
now, PCMCIA-FDC specific functions have been implemented differently
where needed.
Unfortunately, due to the fact that the traditional PeeCee FDC with
its funny non-contiguous register space (one register for WD1003
harddisk controllers is interleaved into the FDC register set), and
Peter's subsequent changes involving two different bus space handles
for normal FDCs, the changes required for the Y-E stuff are more
complex than i'd love them to be. I've done my best to keep the logic
for normal FDCs intact.
Since the Y-E FDC seems to lose interrupts after a FDC reset
sometimes, i've also replaced the timeout logic in fd_turnoff() to
generate an artificial pseudo interrupt in case of a timeout while the
drive has still outstanding transfers waiting. This avoids the total
starvation of the driver that could be observed with highly damaged
media under 3.x/PAO. This part of the patch has been revied by bde
previously.
I've fixed a number of occasions where previous commits have been
missing the encapuslation of ISA DMA related functions inside
FDC_NODMA checks.
I've added one call to SET_BCDR() during preparation of the format
floppy operation. Floppy formatting has been totally broken before in
3.x/PAO (garbage ID fields have been written to the medium, causing
`wrong cylinder' errors upon media reading). This is just black
magic, i don't have the slightes idea _why_ this needs to be but just
copied over the hack that has been used by the PAO folks in the normal
read/write case anyway.
The entired device_busy() stuff seems to be pointless to me. In any
case, i had to add device_unbusy() calls symmetrical to the
device_busy() calls, otherwise the PCMCIA floppy driver could never be
deactivated. (As it used to be, it caused a `mark the device busier
and busier' situation.) IMHO, all block device drivers should be
marked busy based on active buffers still waiting for the driver, so
the device_unbusy() calls should probably go to biodone(). Only one
other driver (whose name escapes me at the moment) uses device_busy()
calls at all, so i question the value of all this...
I think this entire `device busy' logic simply doesn't fit for PCMCIA
&al. It cannot be the decision of some piece of kernel software to
declare a device `busy by now, you can't remove it', when the actual
physical power of removing it is the user pulling the card. The
kernel simply has to cope with the removal, however busy the device
might have been by the time of the removal, period. Perhaps a force
flag needs to be added?
Upon inserting the card a second time, i get:
WARNING: "fd" is usurping "fd"'s cdevsw[]
WARNING: "fd" is usurping "fd"'s bmaj
I suspect this is related to the XXX comment at the call to
cdevsw_add(). Does anybody know what the correct way is to cleanup
this?
- Microsoft IntelliMouse Explorer: 2 buttons on top, 2 side buttons
and a wheel which also acts as the middle button. The mouse is
recognized as "IntelliMouse Explorer".
- Genius NetScroll Optical: 2 buttons on top, 2 side buttons and a
wheel which also acts as the middle button. The mouse is recognized
as "NetMouse/NetScroll Optical".
- MouseSystems SmartScroll Mouse (OEM from Genius?): 3 buttons on top,
1 side button and a wheel. The mouse is recognized as Genius
"NetScroll".
- IBM ScrollPoint: 2 buttons on top and a stick between the buttons.
The stick can perform "horizontal scroll" in W*ndows environment.
The horizontal movement of the stick is detected. It is currently
mapped to the Z axis movement in the same way as the first wheel.
The mouse is recognized as "MouseMan+", as it is considered to be
a variation of MouseMan.
- A4 Tech 4D and 4D+ mice. These mice have two wheels! The movement
of the second wheel is reported as the Z axis movement in the
same way as the first wheel. These mice are recognized as "4D
Mouse" and "4D+ Mouse".
- Tweak IntelliMouse support code a bit so that less-than-compatible
wheel mice can work properly with the psm driver.
- Add driver configuration flags which correspond to the kernel
options PSM_HOOKRESUME and PSM_RESETAFTERSUSPEND, so that we don't
need to recompile the kernel when we need these functions.
- Properly keep track of the irq resource.
- Add a watchdog timer in case interrupts are lost (experimental).
- Add `detach' function (experimental).
we get the com address. If so, we go ahead and return. Bruce thinks
there's a bug in the pccard layer that it terminates devices with
extreme prejustice rather than letting them deside for themselves when
to terminate (and he's likely right). This fix doesn't change that,
but instead works around it by checking for NULL pointers at more
places than before.
The detach routine still calls functions at interrupt level that
aren't reentrant. In theory this could cause a problem, but none
showed up in practice. Future versions should correct this problem,
likely by making the detach process a thread/process at the pccard
level. NEWCARD will do this, and the current pccard layer should
likely be modified to that as well, should it live long enough.
A few style nits of the same form that were in my original patch sent
off to bde were also fixed as part of this process. Mostly use of
!ptr and return ENOPARENS.
This should prevent a crash on suspend with an active ppp link as
well, but that wasn't tested.
Reviewed by: bde
Approved by: jkh
is responsible for this and this will lead to malloc 'freeing already
free' type panics. One was in the probe code, the other was in the
pccard eject? code.
Not explicitly approved by: jkh (but the first is fallout from subr_bus.c
rev 1.54 which was an approved commit, the second is the same problem)
to us, subr_bus.c will free it. This bug (panic: freeing already free)
was exposed by kern/subr_bus.c rev 1.54
Not explicitly approved by: jkh (but this is a showstopper and fallout of
the above approved change)
Enable the driver in sys/conf/files.i386.
In isa/isavar.h increase ISA_NPORT from 32 to 50. This is required
because this brain-damaged card maps 49 (!) port ranges. This does
not have a negative impact because this value only specifies the maximum
number of entries in a linked list and not the size of an array which
is allocated in all drivers.
The register/fifo access routines were not newbus-ified because
1) I knew that the old code worked and is simpler and more efficient
2) the if_ed driver does something similar and
3) the newbus macros collapse to inb/outb anyway.
Reviewed and tested by: hm
Approved by: jkh
1) Non-AST4 multiport cards were broken by bypassing the code that changes
`idev' to the multiport master device.
2) AST4 multiport cards apparently were broken by inverting the test for
the master device having an irq.
3) Error handling for nonexistent master devices was broken by removing a
check for a null pointer.
4) `int' error codes returned by bus_get_resource() were assigned directly
to the boolean variable com->no_irq. Probably harmless, since the
boolean is implemented as a u_char.
Submitted by: part 1) by Chris Radek <cradek@in221.inetnebr.com>
part 2) by yokota
Approved by: jkh
- trying for a fit for a PnP configuration from a device
- soaking up resources from a configuration that were not allocated by
the driver
do not attempt to activate them. Only a device driver that is aware of
the nature of the resource and its suitability can be certain that
activating a resource, particularly a memory resource, is a safe thing
to do.
This was prompted by the discovery that many systems report all physical
memory through a PNP0c02 device; activating this resource maps all
physical memory into the kernel's virtual space, either blowing out the
kernel pagetable or in the worst case causing a panic in pmap_mapdev()
if the system has too much physical memory.
Authorised by: jkh
Reviewed by: dfr
the same vendor and logical ID. The rest I am not sure whether they
are vendor or logical, but it won't hurt if I've put a vendor ID here
as merely will not match. These came from the old sio-pnp code, hence
the uncertainty about which ID it is.
and there may be a good reason for them being unallocated (eg. they're
nonsensical or not useful). The goal here is simply to reserve them
against accidental use by other code.
things like sound cards can get called "Parallel port". A note to the
unwary; the isa-pnp devices in the system are probed like PCI - each
device ID is passed to *all* isa probe routines to find the best match.
If the driver is not prepared to deal with this, it must abort in this
scenario or it will try and claim all PnP devices.
Note1: the correct interrupt level is invoked correctly for each driver.
For this purpose, drivers request the bus before being able to
call BUS_SETUP_INTR and BUS_TEARDOWN_INTR call is forced by the ppbus
core when drivers release it. Thus, when BUS_SETUP_INTR is called
at ppbus driver level, ppbus checks that the caller owns the
bus and stores the interrupt handler cookie (in order to unregister
it later).
Printing is impossible while plip link is up is still TRUE.
vpo (ZIP driver) and lpt are make in such a way that
using the ZIP and printing concurrently is permitted is also TRUE.
Note2: specific chipset detection is not done by default. PPC_PROBE_CHIPSET
is now needed to force chipset detection. If set, the flags 0x40
still avoid detection at boot.
Port of the pcf(4) driver to the newbus system (was previously directly
connected to the rootbus and attached by a bogus pcf_isa_probe function).
ddb is entered. Don't refer to `in_Debugger' to see if we
are in the debugger. (The variable used to be static in Debugger()
and wasn't updated if ddb is entered via traps and panic anyway.)
- Don't refer to `in_Debugger'.
- Add `db_active' to i386/i386/db_interface.d (as in
alpha/alpha/db_interface.c).
- Remove cnpollc() stub from ddb/db_input.c.
- Add the dbctl function to syscons, pcvt, and sio. (The function for
pcvt and sio is noop at the moment.)
Jointly developed by: bde and me
(The final version was tweaked by me and not reviewed by bde. Thus,
if there is any error in this commit, that is entirely of mine, not
his.)
Some changes were obtained from: NetBSD
It seems that the IDE system uses 0x3f6 for itself, which conflicts with
fdc's default 0x3f0-3f7 allocation range. Sigh. Work around this.
Use bus_set_resource() rather than allocating specific areas, it makes
the code a little cleaner.
Based on work by: dfr
o Rename FDC_PCMCIA to FDC_NODMA to allow systems that don't have dma
for floppies.
o Remove all but two FDC_YE ifdefs. They aren't needed.
o Move defines for YE_DATAPORT to fdreg.h.
Not fixed:
o The pccard probe/attach. However, motivated individuals can more
easily add this now.
This is a merge of changes I've had in my tree for a long time. These
fixes were tested on my VAIO with its normal floppy. Please let me
know if I broke anything.
Prodded by: Peter Wemm <peter@freebsd.org>
This is the hack that compensates for when bios vendors "forget" to
include the fdc control (0x3f7) port in their io port mappings. Instead
of accessing ports outside of a range allocated to a handle, simply
allocate the port directly. It even shows up in the probe..
In particular:
- Don't leave resources allocated in the probe routine. Allocate them
during probe and release them. Probe's job is to identify devices only.
- Don't abuse the ivars pointer.. (!). Create real ivars and use the
proper access system. (the bus_read_ivar method)
- Don't add the children until attach() has successfully grabbed the
hardware, otherwise there are potential leaks if attach fails.
the low level interrupt handler number should be used. Change
setup_apic_irq_mapping() to allocate low level interrupt handler X (Xintr${X})
for any ISA interrupt X mentioned in the MP table.
Remove an assumption in the driver for the system clock (clock.c) that
interrupts mentioned in the MP table as delivered to IOAPIC #0 intpin Y
is handled by low level interrupt handler Y (Xintr${Y}) but don't assume
that low level interrupt handler 0 (Xintr0) is used.
Don't allocate two low level interrupt handlers for the system clock.
Reviewed by: NOKUBI Hirotaka <hnokubi@yyy.or.jp>
is an application space macro and the applications are supposed to be free
to use it as they please (but cannot). This is consistant with the other
BSD's who made this change quite some time ago. More commits to come.
5in HD 2 heads, 77 cylinders, 8 sectors/track, 1024 bytes/sector
5/3.5in DD 2 heads, 80 cylinders, 8 sectors/track, 512 bytes/sector
Meanings of the rogrammer-readeble fd name were explained by Brian
Fundakowski Feldman and Peter Wemm in hackers list and NOKUBI
Hirotaka.
Reviewed by: nyan
apm_default_resume() to sometimes set a very wrong time.
(1) Accesses to the RTC index and data registers were not atomic enough.
Interrupts were not masked. This was only good enough until an
interrupt handler (rtcintr()) started accessing the RTC in FreeBSD-2.0.
(2) Access to the block of time registers in inittodr() was not atomic
enough. inittodr() has 244us to read the time registers. Interrupts
were not masked. This was only good enough until something (apm)
started calling inittodr() after boot time in FreeBSD-2.0.
The fix for (2) also makes the timecounter update more atomic, although
this is currently unimportant due to the low resolution of the RTC.
Problem reported by: mckay
of these are bound to have a PNP05xx compatid, but there's no easy way to
tell. Since it's just an ID list and uses the pnp header's description
strings rather than encoding strings here, it doesn't seem to be too
expensive to err on the safe side.
misdetecting FIFO capabilities, at least on my girlfriend's Thinkpad 755,
the driver doesn't work using the FIFO.
While i was at it, i (partially) fixed option FCC_YE since it would no
longer have compiled at all under -current. I've also made an attempt
to document the device driver flags value (ab-)used internally by this
option.
RELENG_3 candidate, but with a slightly different patch there (will go
to jkh in email).
o fix return type of sio_pccard_detach
o don't free softc in deatch, since that is done by newbus
o disconnect interrupt we used to have. Add cookie to com so that we can
tear down the interrupt on unload
o Set gone earlier, but likely doesn't matter
This makes sio pccards work again. Cards that are active when ejects may
not work (but they might, softc goes away quickly).
These changes are unreviewed by bde. I'll make any style changes he wants.
programming practices. It seems that newer fdc chips have an
alternative way of setting the transfer speed (including high speed
modes for floppy tape) that doesn't use the control register (which
we don't support - we use the old way only). So, they (the BIOS
programmers) sometimes leave out the 0x3f6 control register from
the PnP ports descriptor(!!). "Hey, it works with windows, so
what's the problem?" :-( Anyway, this hack tries to compensate
for that. This was discussed with dfr (who did the pnp attachment).
returns "0" on failure, which is indistinguishable from (say) irq 0. This
should stop a couple of stray messages that turn up.
Also, if a BUS_SETUP_INTR() fails with INTR_TYPE_FAST, try falling back to
a normal interrupt. This might help pccard folks with a shared slot
interrupt. This whole thing needs to be revisited.
joystick port on PnP sound cards that have a suitable device ID on them.
Doug Rabson added timer code so it didn't have to beat on the isa timer.
Submitted by: Takanori Watanabe <takawata@shidahara1.planet.sci.kobe-u.ac.jp>
device_add_child_ordered(). 'ivars' may now be set using the
device_set_ivars() function.
This makes it easier for us to change how arbitrary data structures are
associated with a device_t. Eventually we won't be modifying device_t
to add additional pointers for ivars, softc data etc.
Despite my best efforts I've probably forgotten something so let me know
if this breaks anything. I've been running with this change for months
and its been quite involved actually isolating all the changes from
the rest of the local changes in my tree.
Reviewed by: peter, dfr
