by adding the "nargs" argument to the macppc version, and fix the macppc
ports uses of OF_interpret() accordingly.
Also move the declaration of OF_interpt() from macppc's autoconf.h to
ofw/openfirm.h. This fixes the build of the macppc port.
Approved by macallan@.
* Support for the VIA VT8231 Hardware monitor.
* Power Management Timer available for timecounters in both
VT86C686A and VT8231 (code simplified thanks to dev/ic/acpipmtimer).
* Remove viapm(4) code and manpage (which was a link to viaenv.4 anyway).
From OpenBSD, tested by some users.
make the default values of bidirectional pins `output' because
they were often the main reason of no sound problems.
* add stac9221_mixer_init()
It has a code for Intel Mac but it is disabled for now.
values from the smbus before. amdpm_smbus_exec was using the values read
from the registers and using them as return values instead of filling in
the caller's buffer.
with other users who have been experiencing watchdog timeouts:
* Mask all interrupts while servicing a tx or rx interrupt.
* On init, clear IRQ status registers (workaround for buggy netbooters).
> Defer setting of the valid bit in the first TX descriptor after
> all descriptors have been setup. Otherwise, hardware may start
> processing descriptors faster than us and crap out.
> Fixes "watchdog timeout" errors.
>
> Original idea from Matthew Dillon @DragonFly.
- print PCI device name and revision
- print interrupt and Ethernet address like other devices
Before:
---
nfe0 at pci0 dev 5 function 0LKLN: Picked IRQ 20 with weight 1
: ioapic0 pin 20 (irq 9), address xx:xx:xx:xx:xx:xx
After:
---
nfe0 at pci0 dev 5 function 0: NVIDIA nForce3 ethernet #4 (rev. 0xa2)
LKLN: Picked IRQ 20 with weight 1
nfe0: interrupting at ioapic0 pin 20 (irq 9)
nfe0: Ethernet address xx:xx:xx:xx:xx:xx
(note "Picked IRQ" message is logged by aprint_verbose(9) in acpi(4))
bridge that precludes the ThunderLAN's DMA engine from performing segment
transfers across page boundaries. Add logic under #ifdef TL_SETENG_GFE to
split up these segment transfers appropriately.
It's unknown whether this issue could also affect the RX path, though no
problems have been observed yet.
- finish implementing splraiseipl (and makeiplcookie).
http://mail-index.NetBSD.org/tech-kern/2006/07/01/0000.html
- complete workqueue(9) and fix its ipl problem, which is reported
to cause audio skipping.
- fix netbt (at least compilation problems) for some ports.
- fix PR/33218.
- Mostly sync with OpenBSD
- Serialise sending commands to the firmware
- Remove redundant calls to bpfdetach.
- use bus_size_t where appropriate and not fetch iobase as it's not
used.
- improve 802.11 radiotap support (correct rx rate)
- add short preamble flag
- add short slot time support
- ignore parity errors (as per the Linux driver)
- Set Tx power for all channels.
- disable bluetooth co-existance
- Check that ni->ni_rates.rs_nrates is not greater than the maximum
handled by the firmware.
- Begin syncing with the FreeBSD driver by renaming a few things.
nonsense quirk that switched operating mode on ICH7 and ICH8.
I removed the obvious candidates for ahcisata(4), and I'll have a closer
look later if there are others to be removed; ahcisata(4) will take over
handling the device anyway, but there is no reason to keep AHCI devices in
that list.
Along the way, remove the code that tries to put the chip in Enhanced mode,
it makes absolutely no sense to do that, and some BIOSes might not have
prepared the BARs for that, as proven by PR#34885. If people want to use
all IDE and SATA channels, they have to tell the BIOS.
- checking if dmamap != NULL is not valid because dmamap is not cleared
in bus_dmamap_unload(9)
- no need check RX mbufs and call m_freem() and bus_dmamap_unload()
in vge_init() since it's done in prior vge_stop()
Now vge(4) works fine on Ultra5.
arithmetic on ILP32 (sizeof(bus_addr_t) == 4, exactly) hosts
- prepare and use VGE_PREV_TXDESC() macro
- use VGE_[TR]XDESCSYNC() calls more efficiently
- wrap a sanity check against VGE_RDSTS_OWN in vge_newbuf()
with #ifdef DIAGNOSTIC since it should not happen
- use sc->sc_tx_free (number of free TX descs) to check if TX packets are
queued or sent
- call vge_start() only if the interupt is actually handled by this driver
- some misc cosmetics
length and define VGE_RX_PAD (which is 4 bytes) for ETHER_ALIGN (2 bytes)
padding only in !__NO_STRICT_ALIGNMENT case to avoid confusion.
As per comments from Murata Shuuichirou in PR kern/31323.
Tested on i386 and macppc.
In OpenBSD's if_bgereg.h, CHIPID 0x4101000 is defined as BCM5750_B1
but our PR kern/31028 says it's BCM5751_A1 on BCM5751M on IBM T43p,
and the value seems reasonable.
> - Move TX ring full sanity check further up and check the number of DMA
> segments from the DMA map, instead of counting the DMA segments in the
> for loop and breaking out later.
> - Unload the DMA map if encountering an error condition.
committed in rev 1.22), save it before calling m_defrag().
I haven't confirmed whether the m_pkthdr.csum_flags is preserved during
m_defrag(), but the previous way sometimes makes vge(4) chip mad...
Perform hardware diagnostic only on the original RTL8169,
which was the only device that really needed it.
(i.e. a possible hardware bug when the NIC was put on a 64bit PCI slot)
Tested with on-board 8139C+ by Brian A. Seklecki.
Note this change might also fix PR kern/34952
(because re_diag() is no longer called on 8169S/8110S),
but I'm not sure if the re(4) chip was properly initialized in such case.
from FreeBSD's if_vr.c rev 1.52:
- check more error status in TX descriptor and restart TX module
appropriately in vr_txeof()
- check more error interrupt status in vr_intr()
I can't confirm whether these changes actually fix TX stalls because
I can't reproduce the problem I had about seven years ago (I guess
it might be caused by excessive collisions on a dumb hub), but at least
they don't seem to have bad side effects on normal operations on my macppc.
The commit log in FreeBSD's if_vr.c rev 1.43 says
"This is really only for the VT6102, but it doesn't hurt the older chips,"
but at least it hurts my VT86C100A (which returns a product ID of VT3043)
on macppc and causes kernel MCHK trap while the same board on i386
and VT6102 on macppc have no problem with it.
- in vr_rxeoc() (i.e. on RX error interrupts), disable RX before
calling vr_rxeof() and check it actually stopped
- no recovery is needed for VR_ISR_DROPPED, so just account ierrors
- also account ierrors in vr_rxeoc()
vge_encap() should bail out if there is not enough free
TX descriptor _OR_ TX descriptor is still owned by the chip.
Anyway, we already check if the TX descriptor already has an mbuf
to be sent in vge_start() so no need to bother to check sc_tx_free
and VGE_TDSTS_OWN in the descriptor in normal case, then make it use
KASSERT(9) or wrap with #ifdef DIAGNOSTIC.
XXX1: I don't know why original FreeBSD driver checks
if a number of free TX descriptors is more than two, not zero.
XXX2: Is it better to check a number of free descriptors in vge_start()
like other our drivers rather than mbuf chain for each descriptor?
Fix checksum error problem on sending fragmented large packets,
which was introduced in rev 1.14.
BTW, should we have m_defrag() in MI for other drivers?
- merge if_vgevar.h into if_vge.c since no other file refers it
- rename some macro (VGE_TX_DESC_CNT -> VGE_NTXDESC etc.) and structs
- change prefixes of structure members to represent parents
- put TX and RX descriptors into single struct vge_control_data and
allocate DMA memory at once
- no need to specify BUS_DMA_ALLOCNOW
- define appropriate macro for offsets and addresses of DMA descriptors
- define struct vge_txsoft and vge_rxsoft, and put common data for
each descriptor into them
- remove struct vge_list_data and move its members into struct vge_softc
- remove #ifdef DEVICE_POLLING code we don't support
- merge vge_[tr]x_list_init() functions into vge_init()
- use aprint_error() to print errors
- put splnet(9) where appropriate and remove unused VGE_{LOCK,UNLOCK}() macro
- clear TX timeout only if there is no pending descriptor
- check dm_nsegs properly otherwise padding short packets could fail
- prepare zero'ed DMA memory to pad short packets rather than putting
random data
- fix a wrong VGE_TXDESCSYNC() usage which should be VGE_TXFRAGSYNC()
Tested on my i386 which is my development machine.
(more bus_dmamap_sync(9) cleanup will be done later)
- Remove the PCN_NO_PROM option. Instead, query the am79c970-no-eeprom
property, and read the MAC address from the CSRs if that property is TRUE.
In the ibmnws port:
- Implement device_register().
- In device_register(), set the am79c970-no-eeprom property for the
built-in Ethernet.
- remove an empty statement in if() clause by inverting logic
- use KDASSERT(9) rather than #ifdef DEBUG + KASSERT(9)
- replace commented out M_WRITABLE() with !M_READONLY(9)
drives are probed using the SATA way (from FreeBSD). While here add the
VT8237A SATA Controller to the tables, should fix PR kern/34927.
Thanks to the César Catrián Carreño and paul (at) whooppee.com for
tests.
of using the old PATA way. Tested with a PDC20375 (2xSATA + 1xPATA).
While there add the PDC20618-621 products (Ultra/133 controllers);
untested. Yes, it's strange to support PATA-only devices in a driver
called pdcsata, but that's how it is ...
- On TX, vge(4) seems to assume that tags are written in little endian.
We already use htole32() to write values into descriptors,
so extra byteswap by htons() is not needed there.
- On RX, vge(4) seems to store tags in network byteorder.
We have to swap byteorder regardless of host's byteorder
(i.e. we have to use bswap16() rather than ntohs())
because we already use le32toh() to read values from descriptors.
Anyway, no need to use htons()/ntohs() because there is no stream data.
Tested on both i386 and macppc, and OK'ed by Pavel Cahyna.
newer server chipsets) to wm(4), from the FreeBSD em(4) driver.
While there, add a few other Intel Ethernet controller that should work as
is.
Properly update the RX error and TX collision counters.
Add ikphy(4), a driver for the Intel i82563 Kumeran 10/100/1000 Ethernet PHYs
right after vge_reset() could be corrupted. For workaround, add a
dummy EEPROM read in vge_reset() so that MAC address is properly
set on the machine.
While here, add a DELAY() in busy loop in vge_read_eeprom().
- use __NO_STRICT_ALIGNMENT directly rather than local VGE_FIXUP_RX
- no need to use BUS_DMA_ALLOCNOW
- remove unneeded members from softc
XXX: Is vge_fixup_rx() really more efficient than memmove(9),
XXX: or allocating a new buffer and memcpy(9) into it?
XXX: Anyway, vge(4) is not recommended for non-x86 hosts at all
XXX: because it requires copying buffers by CPU on RX.
blitting. Thanks to David Redman (Tadpole) for noticing it. This probably
escaped notice before, since we never do overlapping blits (in the X
direction), but this fix may prevent problems if someone ever does use it
for that.
This includes:
- fixing various structure definitions so that the ioctl parameter match
- adding a hw.twa*.driver_version sysctl
- do not refuse multiple device openings, as the management tool will do it.
I'm not sure we are safe. FreeBSD allows multiple openings, and use the
open flag only when an attempt to detach the device is done.
So far it only uses the blitter for scrolling and rectangle filling,
characters are still drawn in software and there's no support for video
mode switching. Virtual consoles are supported via vcons.
Works fine on a PowerBook 3400c.
now since some chipset revisions will freak out on the aparent
half-initialisation. Even on my machine i can't seem to get the SPDIF led
to light up so something is wrong.
Also delay the setting of the DMA bits until after the codec detection but
before the enabling of interrupts. Note that the dma has to be explicitly
started when the device is opened.
from Mark Kettenis of OpenBSD. There are still some outstanding
issues with this driver, namely:
- Checksum offload is unsupported
- There is a significant amount of code duplication from sk(4)
- There remain some 'magic numbers'
- Performance is not heavily tested, and likely to be lower than
the chip is capable of in some cases. Syncing some of the
aforementioned 'magic numbers' with the Marvell FreeBSD driver
should help here.
Tested on a motherboard with Marvell 88E8053 ethernet, under NetBSD/i386
and NetBSD/amd64.
The PIOBM is used by only one driver (will be added later,
stay tuned) and intruduce an attribute "ata_piobm" so that
it will be conditionally compiled in.
The "ata_dma" (busmastering transfer using ATA DMA mode) and
"ata_udma" (busmastering transfer using ATA Ultra DMA mode)
attributes are also added for consistency, but unused for now.
* If the controller is in AHCI, ask for SATA IDE mode of operation.
jsg@openbsd says:
"X60/T60 Thinkpads are shipped in AHCI configuration by default,
this makes them work without changing a BIOS option."
Tested by eye of the beholder. From OpenBSD.
Ok'ed tls.
- remove unused code
- KNF
- ANSI function declarations
- replace printf() with aprint_error() except in debug functions
- a few minor indentation/whitespace changes
Place the securelevel checks in their logical locations.
This will be clearer in the future when code changes to use kauth(9) calls.
input and okay ad@
evidence that this is actually needed except for the existence of the
code itself, but if it's going to be here, it should compile. Tested
briefly on my ASUS motherboard with built-in sk interface.
fixes and caveats:
- will switch to 32bit colour, 8bit support needs some more work
- added support for fonts with widths that aren't multiples of 8
- for now the driver will always try to become system console
- mode switching works but is ugly
- all the acceleration bits work
- X should work with wsfb, mmap() needs some more work
- it still needs a hack to allow wsdisplay_cnattach to be called twice
Most of the testing was done on MIPS hardware -- it probably needs work before
it will be useful with x86 hardware, and it is probably incompatible with
the X11 server.
"ATI Technologies Inc. ("ATI") has not assisted in the creation of, and
does not endorse, this software. ATI will not be responsible or liable
for any actual or alleged damage or loss caused by or in connection with
the use of or reliance on this software."
Enjoy!
This support is not based on a datasheet, because a datasheet is not readily
available for this chip. However, Promise have partially open sourced their
driver for Linux, and all suggestions are that the PDC20771 is pretty similar
to other recent SATA chips.
The TX2300 has two ports, but there is unoccupied space on the board for a
third PATA port. It isn't entirely obvious how many channels the PDC20771 can
support.
The pdc205xx_drv_probe probe is necessary to avoid probing two wd* devices for
every physical device.
macallan