* Linux 2.4.20-pre1
@ 2002-08-05 22:40 Marcelo Tosatti
2002-08-06 0:20 ` Ben Greear
` (9 more replies)
0 siblings, 10 replies; 27+ messages in thread
From: Marcelo Tosatti @ 2002-08-05 22:40 UTC (permalink / raw)
To: lkml
So here goes -pre1, with a big -ac and x86-64 merges, plus other smaller
stuff.
2.4.20 will be a much faster release cycle than 2.4.19 was.
Summary of changes from v2.4.19 to v2.4.20-pre1
============================================
<jejb@mulgrave.(none)> (02/03/16 1.159.1.1)
53c700
<achirica@ttd.net> (02/05/31 1.445.1.13)
airo wireless net driver update:
<rob@osinvestor.com> (02/06/05 1.537.4.1)
Sparc32 code cleanups.
<rob@osinvestor.com> (02/06/05 1.537.4.2)
Sparc32 code cleanups.
<davem@nuts.ninka.net> (02/06/07 1.537.4.3)
Sparc: Fix copy_{to,from}_user return value handling.
<davem@nuts.ninka.net> (02/06/07 1.537.4.4)
Sparc64: readv/writev SuS compliance fix for sparc32 compat.
<baccala@vger.freesoft.org> (02/06/07 1.537.4.5)
DBRI driver: Add T7903 doc URL.
<kanojsarcar@yahoo.com> (02/06/07 1.537.4.6)
Sparc64: Fix module symbols when stack debugging is on.
<jejb@mulgrave.(none)> (02/06/09 1.159.1.2)
[SCSI 53c700] bux fix in tag starvation, cosmetic cleanup of set_depth
<jejb@mulgrave.(none)> (02/06/09 1.159.1.3)
[SCSI 53c700] update version to 2.8
<ak@muc.de> (02/06/12 1.537.1.8)
RTNETLINK: Allow non-root to receive.
<davem@nuts.ninka.net> (02/06/12 1.537.1.9)
MAINTAINERS: Remove Andi from networking as per his request.
<rusty@rustcorp.com.au> (02/06/12 1.537.1.10)
ipv4/route.c: Cleanup ip_rt_acct_read
<jgarzik@rum.normnet.org> (02/06/14 1.537.7.1)
net driver 8139cp updates:
<wstinson@infonie.fr> (02/06/14 1.537.9.1)
[janitor] update the isicom.c multiport serial driver to
<wstinson@infonie.fr> (02/06/14 1.537.7.3)
[janitor] update the ray_cs.c PCMCIA client driver for the Raylink wireless LAN card
<wstinson@infonie.fr> (02/06/14 1.537.7.4)
[janitor] update the ni65 network driver to
<wstinson@infonie.fr> (02/06/14 1.537.7.5)
[janitor] update the sdlamain Multiprotocol WAN Link Driver to
<wstinson@infonie.fr> (02/06/14 1.537.9.2)
[janitor] update the DAC960 Driver for Mylex DAC960/AcceleRAID/eXtremeRAID PCI RAID Controllers
<wstinson@infonie.fr> (02/06/14 1.537.7.6)
[janitor] update the eexpress.c net driver to
<wstinson@infonie.fr> (02/06/14 1.537.7.7)
[janitor] update the comx-hw-comx wan driver to remove call to check_region and check the status of call to
<wstinson@infonie.fr> (02/06/14 1.537.7.8)
[janitor] update the eepro Intel EtherExpress Pro/10 device driver to
<wstinson@infonie.fr> (02/06/14 1.537.7.9)
[janitor] update the atarilance Ethernet driver for VME Lance cards on the Atari to check the result of request_irq and exit in case of error.
<wstinson@infonie.fr> (02/06/14 1.537.7.10)
[janitor] update the yam hamradio driver to
<jgarzik@rum.normnet.org> (02/06/14 1.537.10.1)
Support dumping NIC-specific stats in 8139cp net driver
<jes@wildopensource.com> (02/06/15 1.537.1.11)
Tigon3: Use unsigned type for dest_idx_unmasked in tg3_recycle_rx.
<jes@wildopensource.com> (02/06/15 1.537.1.12)
Tigon3: MAX_WAIT_CNT is too large.
<edward_peng@dlink.com.tw> (02/06/15 1.537.7.12)
dl2k gige net driver updates:
<michaelw@foldr.org> (02/06/17 1.537.4.7)
sparc64: Use SUNW,power-off to power off some Ultra systems.
<ctindel@cup.hp.com> (02/06/18 1.537.1.13)
drivers/net/bonding.c: Check ethtool then mii ioctl to determine link status.
<davem@nuts.ninka.net> (02/06/18 1.537.1.14)
NET: Backport 2.5.x NAPI infrastructure to 2.4.x
<davem@nuts.ninka.net> (02/06/19 1.537.1.15)
Tigon3: On 32-bit just wrap low 32bits of stats if we overflow.
<jgarzik@mandrakesoft.com> (02/06/20 1.537.12.3)
Add register dumping and NIC-specific stats to 8139too net driver
<jgarzik@mandrakesoft.com> (02/06/20 1.537.12.4)
Fix 8139too net driver register dump
<wa@almesberger.net> (02/06/21 1.537.1.16)
include/net/dsfield.h: Remove dead code.
<jmorris@intercode.com.au> (02/06/25 1.537.1.17)
NETLINK: Add unicast release notifier.
<davem@nuts.ninka.net> (02/06/25 1.537.1.18)
SunHME: Register IRQ with netdev->name as string.
<davem@nuts.ninka.net> (02/07/11 1.537.1.19)
Add netif_receive_skb-like interface for VLAN hw accel.
<davem@nuts.ninka.net> (02/07/11 1.537.1.20)
Tigon3: Add NAPI support.
<kiran@in.ibm.com> (02/07/12 1.537.1.21)
net/core/dst.c: dst_total only needs to exist if RT_CACHE_DEBUG >= 2
<rml@tech9.net> (02/07/15 1.537.1.22)
net/socket.c: Kill memory leak in sock_fasync
<uzi@uzix.org> (02/07/16 1.537.4.8)
SunHME: Make module license visible when not-PCI.
<davem@nuts.ninka.net> (02/07/16 1.537.4.9)
arch/sparc64/defconfig: Update.
<robert.olsson@data.slu.se> (02/07/18 1.537.1.23)
PKTGEN: Updates to version 1.2, work mostly from Ben Greear.
<davem@nuts.ninka.net> (02/07/18 1.537.1.24)
PKTGEN: Use htonl instead of __constant_htonl.
<kuznet@ms2.inr.ac.ru> (02/07/18 1.537.1.25)
PKT SCHED: Add HTB scheduler by Martin Devera.
<ecd@skynet.be> (02/07/18 1.537.4.10)
SPARC64: Fix bugs in ioctl32 registration.
<szepe@pinerecords.com> (02/07/18 1.537.4.11)
SPARC: Dynamically size SRMMU nocache page pool.
<ebrower@resilience.com> (02/07/19 1.537.1.26)
SK98LIN: Fix oops in procfs handling if no cards probed.
<rob@osinvestor.com> (02/07/19 1.537.4.12)
SPARC: Minor header file cleanups.
<rob@osinvestor.com> (02/07/19 1.537.4.13)
floppy.h: Remove unused empty virtual_dma_init.
<robert.olsson@data.slu.se> (02/07/19 1.537.1.27)
PKTGEN: Update documentation.
<davem@nuts.ninka.net> (02/07/19 1.537.1.28)
TIGON3: Finish up NAPI implementation.
<davem@nuts.ninka.net> (02/07/19 1.537.1.29)
PKTGEN: u64 is not necessarily a long long
<davem@nuts.ninka.net> (02/07/19 1.537.1.30)
HTB PKTSCHED: u64 is not necessarily a long long
<davem@nuts.ninka.net> (02/07/19 1.537.1.31)
PKTGEN: Fix need_resched for 2.4.x, more u64 printf fixes.
<davem@nuts.ninka.net> (02/07/19 1.537.1.32)
PKTGEN: More need_resched 2.4.x fixes
<davem@nuts.ninka.net> (02/07/22 1.537.1.33)
net/ipv4/route.c: Handle large offsets properly in procfs read operation.
<davem@nuts.ninka.net> (02/07/22 1.537.4.14)
drivers/sbus/char/openprom.c: Verify user len in copyin_string.
<rob@osinvestor.com> (02/07/22 1.537.4.15)
arch/sparc/config.in: Remove commented out LVM bits.
<davem@nuts.ninka.net> (02/07/30 1.537.4.16)
Openprom: Cast nagative tests properly.
<davem@nuts.ninka.net> (02/07/30 1.537.4.17)
OpenPROM: Cast to ssize_t not int.
<davem@nuts.ninka.net> (02/07/30 1.537.4.18)
OpenPROM: Kill len check, it is pointless.
<davem@nuts.ninka.net> (02/07/31 1.537.4.19)
OpenPROM: Sigh, put the length overflow check back it is needed.
<rusty@rustcorp.com.au> (02/08/02 1.582.2.84)
[PATCH] wan/sdla_chdlc.c oops fix
<mauelshagen@sistina.com> (02/08/02 1.582.2.85)
[PATCH] LVM 1.0.5 driver update for 2.4.19-rc3
<hch@lst.de> (02/08/02 1.582.2.86)
[PATCH] remove unused label in fs/dnotify.c
<rusty@rustcorp.com.au> (02/08/02 1.582.2.87)
[PATCH] ip_nat_core.c - fix compiler warning
<rusty@rustcorp.com.au> (02/08/02 1.582.2.88)
[PATCH] 3c509.c - 1_2
<rusty@rustcorp.com.au> (02/08/02 1.582.2.89)
[PATCH] 2.4 i_size_high fixup
<rusty@rustcorp.com.au> (02/08/02 1.582.2.90)
[PATCH] remove agpgart_be.c unused variables
<rusty@rustcorp.com.au> (02/08/02 1.582.2.91)
[PATCH] namespace.c - compiler warning
<hch@infradead.org> (02/08/02 1.582.2.92)
[PATCH] small inline assembly fix for gcc 3.1 (ffs)
<szepe@pinerecords.com> (02/08/02 1.582.2.93)
[PATCH] reserve nocache based on RAM size
<flo@rfc822.org> (02/08/02 1.582.2.94)
[PATCH] 2.4.19-rc5 cyclades.c one liner
<garloff@suse.de> (02/08/02 1.582.2.95)
[PATCH] IDE: memset kmalloced gendisk structures
<agrover@groveronline.com> (02/08/02 1.582.2.96)
[PATCH] Put Intel cache-detection descriptors in a table
<hch@infradead.org> (02/08/02 1.582.2.97)
[PATCH] proper boot-time messages for P4 Xeon
<bunk@fs.tum.de> (02/08/02 1.582.2.98)
[PATCH] document that cmd64x.c supports the CMD649 and CMD680
<jo-lkml@suckfuell.net> (02/08/02 1.592)
[PATCH] Correct locking on IO stats accounting
<willy@w.ods.org> (02/08/03 1.594)
[PATCH] Reorder TOSHIBA TC35815 in Config.in
<rob@osinvestor.com> (02/08/03 1.595)
[PATCH] watchdog flags
<kaos@ocs.com.au> (02/08/03 1.596)
[PATCH] 2.4.19 include/linux/vmalloc.h for highmem
<marcel@holtmann.org> (02/08/03 1.596.2.1)
[PATCH] Bluetooth Subsystem PC Card drivers update
<felipewd@terra.com.br> (02/08/03 1.596.3.1)
Add Wake-On-Lan support to 8139cp net driver
<jgarzik@mandrakesoft.com> (02/08/03 1.596.3.2)
Temporarily disable MTU-change-while-active support in 8139cp
<felipewd@terra.com.br> (02/08/03 1.596.3.3)
Update 8139cp net driver to enable legacy Rx/TX command register
<felipewd@terra.com.br> (02/08/03 1.596.3.4)
Add suspend/resume support to 8139cp net driver
<davidm@hpl.hp.com> (02/08/03 1.596.3.5)
Update eepro100 net drvr to enable rx DMA without causing
<jgarzik@mandrakesoft.com> (02/08/03 1.596.3.6)
Add Intel e100 net driver.
<jgarzik@mandrakesoft.com> (02/08/03 1.596.3.7)
Add e1000 gige net driver.
<jgarzik@mandrakesoft.com> (02/08/03 1.596.3.8)
Move e100 net driver after eepro100, in kernel image link order.
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.601)
[PATCH] PATCH: 2.4.20-pre1 - parisc specific include files
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.602)
[PATCH] PATCH: 2.4.20pre1 - parisc gsc bus
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.603)
[PATCH] PATCH: 2.4.20-pre1 HP HIL drivers
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.604)
[PATCH] PATCH: Update the MPT fusion drivers to the vendors latest
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.605)
[PATCH] PATCH: 2.4/2.5 - Fix endianness on 3c503
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.606)
[PATCH] PATCH: remove unneeded parisc magic in acenic
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.607)
[PATCH] PATCH: depca update
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.608)
[PATCH] PATCH: 2.4/2.5 - Fix traps on alpha when using ewrk3
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.609)
[PATCH] PATCH: fix gcc warnings in baycom_epp
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.610)
[PATCH] PATCH: 2.4/2.5 Fix endianness in hp-plus
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.611)
[PATCH] PATCH: fix multiple gcc 3.1 warnings in irda
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.612)
[PATCH] PATCH: 2.4/2.5 fix endianness on smc boards
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.613)
[PATCH] PATCH: 2.4/2.5 fix endianness in wd.c
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.614)
[PATCH] PATCH: 2.4 - move nubus to static inline
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.615)
[PATCH] PATCH: 2.4 update gsc parallel port - from maintainer
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.616)
[PATCH] PATCH: update the aacraid driver
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.617)
[PATCH] PATCH: fix aic7xxx build when PCI=n
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.618)
[PATCH] PATCH: eata scsi - update from author
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.619)
[PATCH] PATCH: fix typo in ncr53c8xx
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.620)
[PATCH] PATCH: u14-34f scsi driver update from author
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.621)
[PATCH] PATCH: driver for harmony audio
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.622)
[PATCH] PATCH: trident audio updates
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.623)
[PATCH] PATCH: fix undefined C in ixj driver
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.624)
[PATCH] PATCH: fix gcc 3.1 warnings
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.625)
[PATCH] PATCH: update sti frame buffer
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.626)
[PATCH] PATCH: pull the rest of sti into a subdirectory and update it
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.627)
[PATCH] PATCH: Beos file systems (befs)
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.628)
[PATCH] PATCH: SOM binary load (parisc specific)
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.629)
[PATCH] PATCH: Add EFI partition support
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.630)
[PATCH] PATCH: more hp specific include files
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.631)
[PATCH] PATCH: Fix gcc 3.1 warnings in vlan
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.632)
[PATCH] PATCH: fix formatting
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.633)
[PATCH] PATCH: gcc 3.1 warning fixes for generic_serial
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.634)
[PATCH] PATCH: HP specific drivers
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.635)
[PATCH] PATCH: fix compiler warning in mxser
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.636)
[PATCH] PATCH: (resend for 2.4.20-pre1 as asked) synclink pcmcia
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.637)
[PATCH] PATCH: PDC (parisc bios) console driver
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.638)
[PATCH] PATCH: fix compiler warnings
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.639)
[PATCH] PATCH: fix stallion failing to load
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.640)
[PATCH] PATCH: fix sx driver compile warnings
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.641)
[PATCH] PATCH: fix standards compliance bugs in the tty layer
<alan@irongate.swansea.linux.org.uk> (02/08/05 1.642)
[PATCH] PATCH: clean up umem further
<marcelo@plucky.distro.conectiva> (02/08/05 1.643)
Changed makefile to .20-pre1
<marcelo@plucky.distro.conectiva> (02/08/05 1.644)
Import patch revert-acenic-change.patch
<ak@muc.de> (02/08/05 1.645)
[PATCH] AMD 8111 PCI IDS
<ak@muc.de> (02/08/05 1.646)
[PATCH] AMD 8111 sound support
<ak@muc.de> (02/08/05 1.647)
[PATCH] x86-64 auto_fs support
<ak@muc.de> (02/08/05 1.648)
[PATCH] bluetooth flags warning fixes
<ak@muc.de> (02/08/05 1.649)
[PATCH] cciss interrupt flags warnings
<ak@muc.de> (02/08/05 1.650)
[PATCH] CONFIG_ISA for drivers/char
<ak@muc.de> (02/08/05 1.651)
[PATCH] CONFIG_ISA for IDE
<ak@muc.de> (02/08/05 1.652)
[PATCH] CONFIG_ISA for radio drivers
<ak@muc.de> (02/08/05 1.653)
[PATCH] Configuration fixes for net drivers
<ak@muc.de> (02/08/05 1.654)
[PATCH] DRM 64bit fixes
<ak@muc.de> (02/08/05 1.655)
[PATCH] Early console support for x86-64
<ak@muc.de> (02/08/05 1.656)
[PATCH] x86-64 ELF format name
<ak@muc.de> (02/08/05 1.657)
[PATCH] Ftape 64bit/x86-64 fixes
<ak@muc.de> (02/08/05 1.658)
[PATCH] CONFIG_ISA for i386
<ak@muc.de> (02/08/05 1.659)
[PATCH] Interrupt flags fixes for IEEE1394
<ak@muc.de> (02/08/05 1.660)
[PATCH] x86-64 support in ipc/
<ak@muc.de> (02/08/05 1.661)
[PATCH] 64bit fixes for drivers/isdn
<ak@muc.de> (02/08/05 1.662)
[PATCH] 64bit fixes for the megaraid driver
<ak@muc.de> (02/08/05 1.663)
[PATCH] paride interrupt flags fixes
<ak@muc.de> (02/08/05 1.664)
[PATCH] 64bit warning fixes for PCI
<ak@muc.de> (02/08/05 1.665)
[PATCH] synclink interrupt flag fixes
<ak@muc.de> (02/08/05 1.666)
[PATCH] 64bit fixes for drivers/video
<ak@muc.de> (02/08/05 1.667)
[PATCH] vsyscall/HPET support for x86-64
<ak@muc.de> (02/08/05 1.668)
[PATCH] 64bit WAN driver fixes
<ak@muc.de> (02/08/05 1.669)
[PATCH] wavelan 64bit warning
<ak@muc.de> (02/08/05 1.670)
[PATCH] x86-64 core changes
<pkot@linuxnews.pl> (02/08/05 1.671)
[PATCH] remove the warning from include/linux/dcache.h
<ak@muc.de> (02/08/05 1.673)
[PATCH] 64bit dpt driver fixes
<elenstev@mesatop.com> (02/08/05 1.674)
[PATCH] 2.4.19,
<maxk@qualcomm.com> (02/08/05 1.675)
[PATCH] core fixes
<maxk@qualcomm.com> (02/08/05 1.676)
[PATCH] L2CAP fixes
<maxk@qualcomm.com> (02/08/05 1.677)
[PATCH] SCO fixes
<maxk@qualcomm.com> (02/08/05 1.678)
[PATCH] HCI USB driver update
<maxk@qualcomm.com> (02/08/05 1.679)
[PATCH] BNEP support
<Kai.Makisara@kolumbus.fi> (02/08/05 1.680)
[PATCH] SCSI tape patch for 2.4.19
<marcelo@plucky.distro.conectiva> (02/08/05 1.681)
Remove NAPI for now
^ permalink raw reply [flat|nested] 27+ messages in thread* Re: Linux 2.4.20-pre1 2002-08-05 22:40 Linux 2.4.20-pre1 Marcelo Tosatti @ 2002-08-06 0:20 ` Ben Greear 2002-08-06 11:32 ` Marcelo Tosatti 2002-08-06 14:58 ` Linux 2.4.20-pre1 Jason Lunz ` (8 subsequent siblings) 9 siblings, 1 reply; 27+ messages in thread From: Ben Greear @ 2002-08-06 0:20 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: lkml Marcelo Tosatti wrote: > So here goes -pre1, with a big -ac and x86-64 merges, plus other smaller > stuff. > > 2.4.20 will be a much faster release cycle than 2.4.19 was. Two questions: I see change logs about NAPI going in, and then NAPI being removed. I assume it is removed...but maybe it will be back soon? Second: Where is the patch? I looked on kernel.org and didn't find it. If it's going to be there shortly, that's fine, I'll keep checking back. Thanks, Ben -- Ben Greear <greearb@candelatech.com> <Ben_Greear AT excite.com> President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Linux 2.4.20-pre1 2002-08-06 0:20 ` Ben Greear @ 2002-08-06 11:32 ` Marcelo Tosatti 2002-08-06 12:26 ` David S. Miller ` (2 more replies) 0 siblings, 3 replies; 27+ messages in thread From: Marcelo Tosatti @ 2002-08-06 11:32 UTC (permalink / raw) To: Ben Greear; +Cc: lkml On Mon, 5 Aug 2002, Ben Greear wrote: > Marcelo Tosatti wrote: > > So here goes -pre1, with a big -ac and x86-64 merges, plus other smaller > > stuff. > > > > 2.4.20 will be a much faster release cycle than 2.4.19 was. > > Two questions: I see change logs about NAPI going in, and then > NAPI being removed. I assume it is removed...but maybe it will > be back soon? I want arguments from Davem to include NAPI. Changing the drivers is a reason for me to _not_ want it in. But lets see if Davem can convince me ;) > Second: Where is the patch? I looked on kernel.org and didn't > find it. If it's going to be there shortly, that's fine, I'll > keep checking back. Maybe at davem's CVS repo? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Linux 2.4.20-pre1 2002-08-06 11:32 ` Marcelo Tosatti @ 2002-08-06 12:26 ` David S. Miller 2002-08-06 16:45 ` Ben Greear 2002-08-06 17:12 ` NAPI (was Re: Linux 2.4.20-pre1) Jeff Garzik 2 siblings, 0 replies; 27+ messages in thread From: David S. Miller @ 2002-08-06 12:26 UTC (permalink / raw) To: marcelo; +Cc: greearb, linux-kernel From: Marcelo Tosatti <marcelo@conectiva.com.br> Date: Tue, 6 Aug 2002 08:32:59 -0300 (BRT) > Second: Where is the patch? I looked on kernel.org and didn't > find it. If it's going to be there shortly, that's fine, I'll > keep checking back. Maybe at davem's CVS repo? I don't use CVS anymore... ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Linux 2.4.20-pre1 2002-08-06 11:32 ` Marcelo Tosatti 2002-08-06 12:26 ` David S. Miller @ 2002-08-06 16:45 ` Ben Greear 2002-08-06 17:12 ` NAPI (was Re: Linux 2.4.20-pre1) Jeff Garzik 2 siblings, 0 replies; 27+ messages in thread From: Ben Greear @ 2002-08-06 16:45 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: lkml Marcelo Tosatti wrote: > > On Mon, 5 Aug 2002, Ben Greear wrote: > > >>Marcelo Tosatti wrote: >> >>>So here goes -pre1, with a big -ac and x86-64 merges, plus other smaller >>>stuff. >>> >>>2.4.20 will be a much faster release cycle than 2.4.19 was. >> >>Two questions: I see change logs about NAPI going in, and then >>NAPI being removed. I assume it is removed...but maybe it will >>be back soon? > > > I want arguments from Davem to include NAPI. Changing the drivers is a > reason for me to _not_ want it in. > > But lets see if Davem can convince me ;) Well, I hope he does, and I hope it really works :) The patch I was looking for was the pre-patch you put out. I see it's on kernel.org now, so no problem there. Ben > > >>Second: Where is the patch? I looked on kernel.org and didn't >>find it. If it's going to be there shortly, that's fine, I'll >>keep checking back. > > > Maybe at davem's CVS repo? > -- Ben Greear <greearb@candelatech.com> <Ben_Greear AT excite.com> President of Candela Technologies Inc http://www.candelatech.com ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear ^ permalink raw reply [flat|nested] 27+ messages in thread
* NAPI (was Re: Linux 2.4.20-pre1) 2002-08-06 11:32 ` Marcelo Tosatti 2002-08-06 12:26 ` David S. Miller 2002-08-06 16:45 ` Ben Greear @ 2002-08-06 17:12 ` Jeff Garzik 2002-08-07 14:09 ` Marcus Sundberg 2 siblings, 1 reply; 27+ messages in thread From: Jeff Garzik @ 2002-08-06 17:12 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: Ben Greear, lkml, David S. Miller Marcelo Tosatti wrote: > I want arguments from Davem to include NAPI. Changing the drivers is a > reason for me to _not_ want it in. > > But lets see if Davem can convince me ;) 8139too needs it for flood protection. I also have a patch for sundance which fixes the issue with the quad port and implements RX polling for flood protection. Basically, NAPI --should not-- affect any system that is not using a NAPI driver. Think of NAPI as a net driver libary -- if your driver doesn't use it, you don't know it's there at all. And currently tg3 is the only 2.4 driver using NAPI. NAPI saves people manually implementing polling in each driver, for flood and DoS protection that is needed in 2.4. The flood ceiling is much lower without NAPI, due to having the CPU overhead of interrupt handlers. NAPI also eliminates the need for lots of code to support all sorts of NIC hardware interrupt mitigation variants. Jeff ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: NAPI (was Re: Linux 2.4.20-pre1) 2002-08-06 17:12 ` NAPI (was Re: Linux 2.4.20-pre1) Jeff Garzik @ 2002-08-07 14:09 ` Marcus Sundberg 0 siblings, 0 replies; 27+ messages in thread From: Marcus Sundberg @ 2002-08-07 14:09 UTC (permalink / raw) To: Jeff Garzik; +Cc: lkml Jeff Garzik <jgarzik@mandrakesoft.com> writes: > I also have a patch for sundance which fixes the issue with > the quad port Which issue are you referring to? The DFE-580-doesn't-work-without-USE_IO_OPS-defined, or the drops-packets-even-under-moderate-load? If the latter I would be very interrested in testing that code. //Marcus -- ---------------------------------------+-------------------------- Marcus Sundberg <marcus@ingate.com> | Firewalls with SIP & NAT Firewall Developer, Ingate Systems AB | http://www.ingate.com/ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Linux 2.4.20-pre1 2002-08-05 22:40 Linux 2.4.20-pre1 Marcelo Tosatti 2002-08-06 0:20 ` Ben Greear @ 2002-08-06 14:58 ` Jason Lunz 2002-08-06 15:03 ` CaT 2002-08-06 21:05 ` Adrian Bunk ` (7 subsequent siblings) 9 siblings, 1 reply; 27+ messages in thread From: Jason Lunz @ 2002-08-06 14:58 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: linux-kernel Will you consider using one of those perl scripts to condense the changelogs a little bit? Jason ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Linux 2.4.20-pre1 2002-08-06 14:58 ` Linux 2.4.20-pre1 Jason Lunz @ 2002-08-06 15:03 ` CaT 0 siblings, 0 replies; 27+ messages in thread From: CaT @ 2002-08-06 15:03 UTC (permalink / raw) To: Jason Lunz; +Cc: Marcelo Tosatti, linux-kernel On Tue, Aug 06, 2002 at 10:58:03AM -0400, Jason Lunz wrote: > Will you consider using one of those perl scripts to condense the > changelogs a little bit? Please use them. -Please-... -- | You wake up. The room is spinning very gently | >i | round your head. Or at least it would be if | You have: | you could see it which you can't. | a splitting headache | | no tea | It is pitch black | ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Linux 2.4.20-pre1 2002-08-05 22:40 Linux 2.4.20-pre1 Marcelo Tosatti 2002-08-06 0:20 ` Ben Greear 2002-08-06 14:58 ` Linux 2.4.20-pre1 Jason Lunz @ 2002-08-06 21:05 ` Adrian Bunk 2002-08-07 11:09 ` David S. Miller 2002-08-07 0:21 ` J.A. Magallon ` (6 subsequent siblings) 9 siblings, 1 reply; 27+ messages in thread From: Adrian Bunk @ 2002-08-06 21:05 UTC (permalink / raw) To: Marcelo Tosatti, davem; +Cc: lkml The changes to drivers/net/tg3.c in -pre1 broke the compilation: <-- snip --> ... gcc -D__KERNEL__ -I/home/bunk/linux/kernel-2.4/linux-2.4.19-full/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=k6 -nostdinc -I /usr/lib/gcc-lib/i386-linux/2.95.4/include -DKBUILD_BASENAME=tg3 -c -o tg3.o tg3.c In file included from tg3.c:25: /home/bunk/linux/kernel-2.4/linux-2.4.19-full/include/linux/if_vlan.h: In function `__vlan_hwaccel_rx': /home/bunk/linux/kernel-2.4/linux-2.4.19-full/include/linux/if_vlan.h:186: warning: implicit declaration of function `netif_receive_skb' tg3.c: In function `tg3_poll': tg3.c:1936: structure has no member named `quota' tg3.c:1937: structure has no member named `quota' tg3.c:1942: structure has no member named `quota' tg3.c:1949: warning: implicit declaration of function `netif_rx_complete' tg3.c: In function `tg3_interrupt_main_work': tg3.c:1976: warning: implicit declaration of function `netif_rx_schedule_prep' tg3.c:1979: warning: implicit declaration of function `__netif_rx_schedule' tg3.c: In function `tg3_init_one': tg3.c:5991: structure has no member named `poll' tg3.c:5992: structure has no member named `weight' make[3]: *** [tg3.o] Error 1 make[3]: Leaving directory `/home/bunk/linux/kernel-2.4/linux-2.4.19-full/drivers/net' <-- snip --> cu Adrian -- You only think this is a free country. Like the US the UK spends a lot of time explaining its a free country because its a police state. Alan Cox ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Linux 2.4.20-pre1 2002-08-06 21:05 ` Adrian Bunk @ 2002-08-07 11:09 ` David S. Miller 0 siblings, 0 replies; 27+ messages in thread From: David S. Miller @ 2002-08-07 11:09 UTC (permalink / raw) To: bunk; +Cc: marcelo, linux-kernel Date: Tue, 6 Aug 2002 23:05:44 +0200 (CEST) From: Adrian Bunk <bunk@fs.tum.de> The changes to drivers/net/tg3.c in -pre1 broke the compilation: ... /home/bunk/linux/kernel-2.4/linux-2.4.19-full/include/linux/if_vlan.h:186: warning: implicit declaration of function `netif_receive_skb' tg3.c: In function `tg3_poll': Because Marcelo took the tg3 NAPI changes but not the NAPI infrastructure. :-) I'm hoping since he's decided to take the generic NAPI changes this compile failure will go away in -pre2 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Linux 2.4.20-pre1 2002-08-05 22:40 Linux 2.4.20-pre1 Marcelo Tosatti ` (2 preceding siblings ...) 2002-08-06 21:05 ` Adrian Bunk @ 2002-08-07 0:21 ` J.A. Magallon 2002-08-07 1:08 ` J.A. Magallon ` (5 subsequent siblings) 9 siblings, 0 replies; 27+ messages in thread From: J.A. Magallon @ 2002-08-07 0:21 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: lkml [-- Attachment #1: Type: text/plain, Size: 662 bytes --] On 2002.08.06 Marcelo Tosatti wrote: > >So here goes -pre1, with a big -ac and x86-64 merges, plus other smaller >stuff. > > ><jgarzik@mandrakesoft.com> (02/08/03 1.596.3.6) > Add Intel e100 net driver. > ><jgarzik@mandrakesoft.com> (02/08/03 1.596.3.7) > Add e1000 gige net driver. > Configure.help missing for those. Attached. btw, I don't like this also, but is the official one... -- J.A. Magallon \ Software is like sex: It's better when it's free mailto:jamagallon@able.es \ -- Linus Torvalds, FSF T-shirt Linux werewolf 2.4.19-jam0, Mandrake Linux 9.0 (Cooker) for i586 gcc (GCC) 3.2 (Mandrake Linux 9.0 3.2-0.2mdk) [-- Attachment #2: intel-eth-help.diff.gz --] [-- Type: application/x-gzip, Size: 1475 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Linux 2.4.20-pre1 2002-08-05 22:40 Linux 2.4.20-pre1 Marcelo Tosatti ` (3 preceding siblings ...) 2002-08-07 0:21 ` J.A. Magallon @ 2002-08-07 1:08 ` J.A. Magallon 2002-08-07 1:56 ` Bryan Whitehead ` (4 subsequent siblings) 9 siblings, 0 replies; 27+ messages in thread From: J.A. Magallon @ 2002-08-07 1:08 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: lkml On 2002.08.06 Marcelo Tosatti wrote: > >So here goes -pre1, with a big -ac and x86-64 merges, plus other smaller >stuff. > Something is missing in the network merge: werewolf:/usr/src/linux# grep -r netif_receive_skb * drivers/net/tg3.c: netif_receive_skb(skb); Binary file drivers/net/e1000/e1000_main.o matches Binary file drivers/net/e1000/e1000.o matches include/linux/if_vlan.h: //return (polling ? netif_receive_skb(skb) : netif_rx(skb)); So I had to: --- linux/include/linux/if_vlan.h.orig 2002-08-07 02:57:36.000000000 +0200 +++ linux/include/linux/if_vlan.h 2002-08-07 02:58:07.000000000 +0200 @@ -183,7 +183,8 @@ break; }; - return (polling ? netif_receive_skb(skb) : netif_rx(skb)); + //return (polling ? netif_receive_skb(skb) : netif_rx(skb)); + return netif_rx(skb); } static inline int vlan_hwaccel_rx(struct sk_buff *skb, To make e1000 build. But tg3 uses n_r_skb directly, so it is not useful for that. -- J.A. Magallon \ Software is like sex: It's better when it's free mailto:jamagallon@able.es \ -- Linus Torvalds, FSF T-shirt Linux werewolf 2.4.19-jam0, Mandrake Linux 9.0 (Cooker) for i586 gcc (GCC) 3.2 (Mandrake Linux 9.0 3.2-0.2mdk) ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Linux 2.4.20-pre1 2002-08-05 22:40 Linux 2.4.20-pre1 Marcelo Tosatti ` (4 preceding siblings ...) 2002-08-07 1:08 ` J.A. Magallon @ 2002-08-07 1:56 ` Bryan Whitehead 2002-08-07 3:35 ` Tim Hockin 2002-08-11 8:57 ` Erik Andersen ` (3 subsequent siblings) 9 siblings, 1 reply; 27+ messages in thread From: Bryan Whitehead @ 2002-08-07 1:56 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: lkml, thockin [-- Attachment #1: Type: text/plain, Size: 435 bytes --] Marcelo Tosatti wrote: > So here goes -pre1, with a big -ac and x86-64 merges, plus other smaller > stuff. > > 2.4.20 will be a much faster release cycle than 2.4.19 was. > > This didn't make 2.4.19. Just a spelling error. I tried the maintainer but got no reply... (yea yea... i just like clean logs... ) :) ;) -- Bryan Whitehead SysAdmin - JPL - Interferometry Systems and Technology Phone: 818 354 2903 driver@jpl.nasa.gov [-- Attachment #2: natsemi.patch --] [-- Type: text/plain, Size: 400 bytes --] --- linux/drivers/net/natsemi.c.orig Tue Aug 6 18:50:13 2002 +++ linux/drivers/net/natsemi.c Tue Aug 6 18:50:38 2002 @@ -1685,7 +1685,7 @@ np->tx_config += 2; if (netif_msg_tx_err(np)) printk(KERN_NOTICE - "%s: increased Tx theshold, txcfg %#08x.\n", + "%s: increased Tx threshold, txcfg %#08x.\n", dev->name, np->tx_config); writel(np->tx_config, ioaddr + TxConfig); } ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Linux 2.4.20-pre1 2002-08-07 1:56 ` Bryan Whitehead @ 2002-08-07 3:35 ` Tim Hockin 0 siblings, 0 replies; 27+ messages in thread From: Tim Hockin @ 2002-08-07 3:35 UTC (permalink / raw) To: Bryan Whitehead; +Cc: Marcelo Tosatti, lkml, thockin > This didn't make 2.4.19. Just a spelling error. I tried the maintainer > but got no reply... > > (yea yea... i just like clean logs... ) :) > > ;) ok, ok, It's going into my bk tree...sheesh :) ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Linux 2.4.20-pre1 2002-08-05 22:40 Linux 2.4.20-pre1 Marcelo Tosatti ` (5 preceding siblings ...) 2002-08-07 1:56 ` Bryan Whitehead @ 2002-08-11 8:57 ` Erik Andersen 2002-08-11 9:16 ` Christoph Hellwig 2002-08-11 19:46 ` Alan Cox 2002-08-11 10:56 ` Erik Andersen ` (2 subsequent siblings) 9 siblings, 2 replies; 27+ messages in thread From: Erik Andersen @ 2002-08-11 8:57 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: lkml On Mon Aug 05, 2002 at 07:40:56PM -0300, Marcelo Tosatti wrote: > > So here goes -pre1, with a big -ac and x86-64 merges, plus other smaller > stuff. [------------snip------------] > <alan@irongate.swansea.linux.org.uk> (02/08/05 1.629) > [PATCH] PATCH: Add EFI partition support Needs this to compile.... --- linux/include/asm-ia64/efi.h.orig Sun Aug 11 01:41:10 2002 +++ linux/include/asm-ia64/efi.h Sun Aug 11 01:43:38 2002 @@ -166,6 +166,9 @@ * EFI Configuration Table and GUID definitions */ +#define NULL_GUID \ + ((efi_guid_t) { 0x00000000, 0x0000, 0x0000, { 0x00, 0x00, 0x0, 0x00, 0x00, 0x00, 0x00, 0x00 }}) + #define MPS_TABLE_GUID \ ((efi_guid_t) { 0xeb9d2d2f, 0x2d88, 0x11d3, { 0x9a, 0x16, 0x0, 0x90, 0x27, 0x3f, 0xc1, 0x4d }}) > <rusty@rustcorp.com.au> (02/08/02 1.582.2.91) > [PATCH] namespace.c - compiler warning This patch is wrong.... --- linux/fs/namespace.c.orig Sun Aug 11 01:50:52 2002 +++ linux/fs/namespace.c Sun Aug 11 01:51:04 2002 @@ -29,8 +29,6 @@ static int hash_mask, hash_bits; static kmem_cache_t *mnt_cache; -extern void init_rootfs(void); - static inline unsigned long hash(struct vfsmount *mnt, struct dentry *dentry) { unsigned long tmp = ((unsigned long) mnt / L1_CACHE_BYTES); --- linux/include/linux/namespace.h.orig Sat Aug 3 17:14:31 2002 +++ linux/include/linux/namespace.h Sat Aug 3 18:46:43 2002 @@ -38,5 +38,6 @@ atomic_inc(&namespace->count); } +int __init init_rootfs(void); #endif #endif -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Linux 2.4.20-pre1 2002-08-11 8:57 ` Erik Andersen @ 2002-08-11 9:16 ` Christoph Hellwig 2002-08-11 9:40 ` Erik Andersen 2002-08-11 9:46 ` Erik Andersen 2002-08-11 19:46 ` Alan Cox 1 sibling, 2 replies; 27+ messages in thread From: Christoph Hellwig @ 2002-08-11 9:16 UTC (permalink / raw) To: Erik Andersen, Marcelo Tosatti, lkml On Sun, Aug 11, 2002 at 02:57:17AM -0600, Erik Andersen wrote: > > [PATCH] namespace.c - compiler warning > > This patch is wrong.... Why? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Linux 2.4.20-pre1 2002-08-11 9:16 ` Christoph Hellwig @ 2002-08-11 9:40 ` Erik Andersen 2002-08-11 9:46 ` Erik Andersen 1 sibling, 0 replies; 27+ messages in thread From: Erik Andersen @ 2002-08-11 9:40 UTC (permalink / raw) To: Christoph Hellwig, Marcelo Tosatti, lkml On Sun Aug 11, 2002 at 10:16:17AM +0100, Christoph Hellwig wrote: > On Sun, Aug 11, 2002 at 02:57:17AM -0600, Erik Andersen wrote: > > > [PATCH] namespace.c - compiler warning > > > > This patch is wrong.... > > Why? Because it adds function prototype that doesn't match the actual function.... -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Linux 2.4.20-pre1 2002-08-11 9:16 ` Christoph Hellwig 2002-08-11 9:40 ` Erik Andersen @ 2002-08-11 9:46 ` Erik Andersen 1 sibling, 0 replies; 27+ messages in thread From: Erik Andersen @ 2002-08-11 9:46 UTC (permalink / raw) To: Christoph Hellwig, Marcelo Tosatti, lkml On Sun Aug 11, 2002 at 10:16:17AM +0100, Christoph Hellwig wrote: > On Sun, Aug 11, 2002 at 02:57:17AM -0600, Erik Andersen wrote: > > > [PATCH] namespace.c - compiler warning > > > > This patch is wrong.... > > Why? I guess it would be more clear if I had said that namespace.c in 2.4.20-pre1 was broken my the above mentioned patch, and my patch fixes the problem... -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Linux 2.4.20-pre1 2002-08-11 8:57 ` Erik Andersen 2002-08-11 9:16 ` Christoph Hellwig @ 2002-08-11 19:46 ` Alan Cox 2002-08-11 18:49 ` Erik Andersen 2002-08-12 19:29 ` Paul P Komkoff Jr 1 sibling, 2 replies; 27+ messages in thread From: Alan Cox @ 2002-08-11 19:46 UTC (permalink / raw) To: andersen; +Cc: Marcelo Tosatti, lkml On Sun, 2002-08-11 at 09:57, Erik Andersen wrote: > On Mon Aug 05, 2002 at 07:40:56PM -0300, Marcelo Tosatti wrote: > > > > So here goes -pre1, with a big -ac and x86-64 merges, plus other smaller > > stuff. > [------------snip------------] > > <alan@irongate.swansea.linux.org.uk> (02/08/05 1.629) > > [PATCH] PATCH: Add EFI partition support > > Needs this to compile.... > > --- linux/include/asm-ia64/efi.h.orig Sun Aug 11 01:41:10 2002 > +++ linux/include/asm-ia64/efi.h Sun Aug 11 01:43:38 2002 > @@ -166,6 +166,9 @@ > * EFI Configuration Table and GUID definitions > */ > > +#define NULL_GUID \ > + ((efi_guid_t) { 0x00000000, 0x0000, 0x0000, { 0x00, 0x00, 0x0, 0x00, 0x00, 0x00, 0x00, 0x00 }}) > + Not a good plan. EFI can be used on non ia64 so NULL_GUID belongs somewhere else ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Linux 2.4.20-pre1 2002-08-11 19:46 ` Alan Cox @ 2002-08-11 18:49 ` Erik Andersen 2002-08-12 19:29 ` Paul P Komkoff Jr 1 sibling, 0 replies; 27+ messages in thread From: Erik Andersen @ 2002-08-11 18:49 UTC (permalink / raw) To: Alan Cox; +Cc: Marcelo Tosatti, lkml On Sun Aug 11, 2002 at 08:46:19PM +0100, Alan Cox wrote: > On Sun, 2002-08-11 at 09:57, Erik Andersen wrote: > > On Mon Aug 05, 2002 at 07:40:56PM -0300, Marcelo Tosatti wrote: > > > > > > So here goes -pre1, with a big -ac and x86-64 merges, plus other smaller > > > stuff. > > [------------snip------------] > > > <alan@irongate.swansea.linux.org.uk> (02/08/05 1.629) > > > [PATCH] PATCH: Add EFI partition support > > > > Needs this to compile.... > > > > --- linux/include/asm-ia64/efi.h.orig Sun Aug 11 01:41:10 2002 > > +++ linux/include/asm-ia64/efi.h Sun Aug 11 01:43:38 2002 > > @@ -166,6 +166,9 @@ > > * EFI Configuration Table and GUID definitions > > */ > > > > +#define NULL_GUID \ > > + ((efi_guid_t) { 0x00000000, 0x0000, 0x0000, { 0x00, 0x00, 0x0, 0x00, 0x00, 0x00, 0x00, 0x00 }}) > > + > > Not a good plan. EFI can be used on non ia64 so NULL_GUID belongs > somewhere else I know. But if you look at the source, the generic stuff is directly including asm-ia64/efi.h, so this makes it compile. I agree having the generic stuff include asm-ia64 code is really stupid, but changing that seemed far more invasive and frankly, I don't even know what an "EFI" is, so I didn't want to mess with it beyond making it compile per how it is currently doing things, -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Linux 2.4.20-pre1 2002-08-11 19:46 ` Alan Cox 2002-08-11 18:49 ` Erik Andersen @ 2002-08-12 19:29 ` Paul P Komkoff Jr 1 sibling, 0 replies; 27+ messages in thread From: Paul P Komkoff Jr @ 2002-08-12 19:29 UTC (permalink / raw) To: lkml; +Cc: Alan Cox Replying to Alan Cox: > Not a good plan. EFI can be used on non ia64 so NULL_GUID belongs > somewhere else maybe but even without NULL_GUID I still need to add asm-ia64 to KBUILD_INCLUDE_DIRS while trying to kbuild-25ify -ac (and marcelo now) hint-hint: maybe it IS worth moving to generic include ? hmm -- Paul P 'Stingray' Komkoff 'Greatest' Jr /// (icq)23200764 /// (http)stingr.net When you're invisible, the only one really watching you is you (my keychain) ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Linux 2.4.20-pre1 2002-08-05 22:40 Linux 2.4.20-pre1 Marcelo Tosatti ` (6 preceding siblings ...) 2002-08-11 8:57 ` Erik Andersen @ 2002-08-11 10:56 ` Erik Andersen 2002-08-11 21:22 ` [PATCH] radeonfb update vs 2.4.20-pre1 Erik Andersen 2002-08-17 19:51 ` Linux 2.4.20-pre1 Adrian Bunk 9 siblings, 0 replies; 27+ messages in thread From: Erik Andersen @ 2002-08-11 10:56 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: lkml On Mon Aug 05, 2002 at 07:40:56PM -0300, Marcelo Tosatti wrote: > <achirica@ttd.net> (02/05/31 1.445.1.13) > airo wireless net driver update: Doesn't this make more sense? --- linux/drivers/net/wireless/airo.c.orig Sun Aug 11 03:59:28 2002 +++ linux/drivers/net/wireless/airo.c Sun Aug 11 03:59:46 2002 @@ -191,12 +191,6 @@ #ifndef RUN_AT #define RUN_AT(x) (jiffies+(x)) #endif -#ifndef PDE -static inline struct proc_dir_entry *PDE(const struct inode *inode) -{ - return inode->u.generic_ip; -} -#endif /* These variables are for insmod, since it seems that the rates diff -urN linux-2.4.19.orig/include/linux/proc_fs.h linux-2.4.19/include/linux/proc_fs.h --- linux-2.4.19.orig/include/linux/proc_fs.h Fri Aug 2 18:39:45 2002 +++ linux-2.4.19/include/linux/proc_fs.h Sun Aug 11 00:23:55 2002 @@ -209,4 +209,9 @@ #endif /* CONFIG_PROC_FS */ +static inline struct proc_dir_entry *PDE(const struct inode *inode) +{ + return (struct proc_dir_entry *)inode->u.generic_ip; +} + -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH] radeonfb update vs 2.4.20-pre1 2002-08-05 22:40 Linux 2.4.20-pre1 Marcelo Tosatti ` (7 preceding siblings ...) 2002-08-11 10:56 ` Erik Andersen @ 2002-08-11 21:22 ` Erik Andersen 2002-08-12 10:18 ` Ani Joshi 2002-08-17 19:51 ` Linux 2.4.20-pre1 Adrian Bunk 9 siblings, 1 reply; 27+ messages in thread From: Erik Andersen @ 2002-08-11 21:22 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: lkml, Ani Joshi Here is an update to the radeonfb. This is based on a patch from Peter Horton that was posted to the lkml back in April http://www.uwsg.indiana.edu/hypermail/linux/kernel/0204.1/0364.html I have been carrying this patch along in my own tree since April and I find it a huge improvement. Using this patch, I find that the radeonfb is quite fast, and colors are correct. I have updated the patch to fit into 2.4.20-pre1, fixed a few obvious little things, and reworked the mtrr handling so it matches the behavior of the other framebuffers. Any chance we could get this into 2.4.20? -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- --- drivers/video/radeonfb.c.orig Sun Aug 11 03:43:12 2002 +++ drivers/video/radeonfb.c Sun Aug 11 03:43:18 2002 @@ -22,6 +22,13 @@ * * Special thanks to ATI DevRel team for their hardware donations. * + * 2002-04-02 Added MTRR support. Fixed 8bpp acceleration. Added + * acceleration for 16/32bpp. Applied fix from XFree86 + * for hard crash on accelerator reset. Fixed up the + * colour stuff. Peter Horton <pdh@colonel-panic.org> + * 2002-04-10 Make ypan work. More colour fixes, all modes >8bpp + * now DIRECTCOLOR. Match up CRTC and accelerator + * pitch. */ @@ -73,18 +80,24 @@ #include <video/fbcon.h> #include <video/fbcon-cfb8.h> #include <video/fbcon-cfb16.h> -#include <video/fbcon-cfb24.h> #include <video/fbcon-cfb32.h> +#ifdef CONFIG_MTRR +#include <asm/mtrr.h> +#endif #include "radeon.h" -#define DEBUG 0 +#define FIX_DEPTH_15 1 + +#define DEBUG 0 + +#define _RTRACE(f,a...) do{printk("radeonfb: " f "\n", ##a);}while(0) #if DEBUG -#define RTRACE printk +#define RTRACE(f,a...) _RTRACE(f,##a) #else -#define RTRACE if(0) printk +#define RTRACE(f,a...) #endif @@ -299,17 +312,16 @@ struct ram_info ram; +#if 0 u32 hack_crtc_ext_cntl; u32 hack_crtc_v_sync_strt_wid; +#endif #if defined(FBCON_HAS_CFB16) || defined(FBCON_HAS_CFB32) union { #if defined(FBCON_HAS_CFB16) u_int16_t cfb16[16]; #endif -#if defined(FBCON_HAS_CFB24) - u_int32_t cfb24[16]; -#endif #if defined(FBCON_HAS_CFB32) u_int32_t cfb32[16]; #endif @@ -474,11 +486,10 @@ } -static inline int var_to_depth(const struct fb_var_screeninfo *var) +static __inline__ int var_to_depth(const struct fb_var_screeninfo *var) { - if (var->bits_per_pixel != 16) - return var->bits_per_pixel; - return (var->green.length == 6) ? 16 : 15; + return (var->bits_per_pixel == 16 && var->green.length == 5)? + 15 : var->bits_per_pixel; } @@ -531,6 +542,7 @@ #define radeon_engine_reset() _radeon_engine_reset(rinfo) +#if 0 static __inline__ u8 radeon_get_post_div_bitval(int post_div) { switch (post_div) { @@ -552,6 +564,7 @@ return 0x02; } } +#endif @@ -594,14 +607,25 @@ static char fontname[40] __initdata; static char *mode_option __initdata; -static char noaccel __initdata = 0; +static char noaccel /*__initdata*/ = 0; +static char fb16fix = 0; static int panel_yres __initdata = 0; static char force_dfp __initdata = 0; static struct radeonfb_info *board_list = NULL; +#ifdef CONFIG_MTRR +static int enable_mtrr = 1; +static int mtrr_handle; +#endif #ifdef FBCON_HAS_CFB8 static struct display_switch fbcon_radeon8; #endif +#ifdef FBCON_HAS_CFB16 +static struct display_switch fbcon_radeon16; +#endif +#ifdef FBCON_HAS_CFB32 +static struct display_switch fbcon_radeon32; +#endif /* @@ -731,6 +755,12 @@ force_dfp = 1; } else if (!strncmp(this_opt, "panel_yres:", 11)) { panel_yres = simple_strtoul((this_opt+11), NULL, 0); + } else if (!strncmp(this_opt, "fb16fix", 7)) { + fb16fix = 1; +#ifdef CONFIG_MTRR + } else if (!strncmp(this_opt, "nomtrr", 6)) { + enable_mtrr = 0; +#endif } else mode_option = this_opt; } @@ -755,7 +785,7 @@ u32 tmp; int i, j; - RTRACE("radeonfb_pci_register BEGIN\n"); + RTRACE("radeonfb_pci_register BEGIN"); rinfo = kmalloc (sizeof (struct radeonfb_info), GFP_KERNEL); if (!rinfo) { @@ -915,7 +945,7 @@ rinfo->bios_seg = radeon_find_rom(rinfo); radeon_get_pllinfo(rinfo, rinfo->bios_seg); - RTRACE("radeonfb: probed %s %dk videoram\n", (rinfo->ram_type), (rinfo->video_ram/1024)); + RTRACE("probed %s %dk videoram", (rinfo->ram_type), (rinfo->video_ram/1024)); #if !defined(__powerpc__) radeon_get_moninfo(rinfo); @@ -998,6 +1028,15 @@ return -ENODEV; } +#ifdef CONFIG_MTRR + if (enable_mtrr) { + mtrr_handle = mtrr_add(rinfo->fb_base_phys, rinfo->video_ram, MTRR_TYPE_WRCOMB, 1); + printk("radeonfb: MTRR enabled\n"); + } +#endif + + /* XXX look at this re pitch :pdh */ + if (!noaccel) { /* initialize the engine */ radeon_engine_init (rinfo); @@ -1029,7 +1068,7 @@ GET_MON_NAME(rinfo->crtDisp_type)); } - RTRACE("radeonfb_pci_register END\n"); + RTRACE("radeonfb_pci_register END"); return 0; } @@ -1046,6 +1085,12 @@ /* restore original state */ radeon_write_mode (rinfo, &rinfo->init_state); +#ifdef CONFIG_MTRR + if (enable_mtrr) { + mtrr_del(mtrr_handle, rinfo->fb_base_phys, rinfo->video_ram); + printk("radeonfb: MTRR disabled\n"); + } +#endif unregister_framebuffer ((struct fb_info *) rinfo); iounmap ((void*)rinfo->mmio_base); @@ -1157,7 +1202,7 @@ rinfo->pll.ppll_min = pll.PCLK_min_freq; rinfo->pll.ppll_max = pll.PCLK_max_freq; - printk("radeonfb: ref_clk=%d, ref_div=%d, xclk=%d from BIOS\n", + _RTRACE("ref_clk=%d, ref_div=%d, xclk=%d from BIOS", rinfo->pll.ref_clk, rinfo->pll.ref_div, rinfo->pll.xclk); } else { #ifdef CONFIG_ALL_PPC @@ -1177,7 +1222,7 @@ rinfo->pll.ppll_min = 12000; rinfo->pll.ppll_max = 35000; - printk("radeonfb: ref_clk=%d, ref_div=%d, xclk=%d from OF\n", + _RTRACE("ref_clk=%d, ref_div=%d, xclk=%d from OF", rinfo->pll.ref_clk, rinfo->pll.ref_div, rinfo->pll.xclk); return; @@ -1212,7 +1257,7 @@ break; } - printk("radeonfb: ref_clk=%d, ref_div=%d, xclk=%d defaults\n", + _RTRACE("ref_clk=%d, ref_div=%d, xclk=%d defaults", rinfo->pll.ref_clk, rinfo->pll.ref_div, rinfo->pll.xclk); } } @@ -1271,7 +1316,7 @@ { #ifdef CONFIG_ALL_PPC if (!radeon_get_EDID_OF(rinfo)) - RTRACE("radeonfb: could not retrieve EDID from OF\n"); + RTRACE("radeonfb: could not retrieve EDID from OF"); #else /* XXX use other methods later */ #endif @@ -1503,6 +1548,8 @@ rinfo->vSync_width = (unsigned short) ((tmp & FP_V_SYNC_WID_MASK) >> FP_V_SYNC_WID_SHIFT); + /* XXX some more stuff needs to go here :pdh */ + return 1; } @@ -1542,13 +1589,10 @@ radeon_fifo_wait (1); OUTREG(DSTCACHE_MODE, 0); - /* XXX */ - rinfo->pitch = ((rinfo->xres * (rinfo->bpp / 8) + 0x3f)) >> 6; - radeon_fifo_wait (1); temp = INREG(DEFAULT_PITCH_OFFSET); OUTREG(DEFAULT_PITCH_OFFSET, ((temp & 0xc0000000) | - (rinfo->pitch << 0x16))); + (rinfo->pitch << 16))); radeon_fifo_wait (1); OUTREGP(DP_DATATYPE, 0, ~HOST_BIG_ENDIAN_EN); @@ -1703,30 +1747,22 @@ switch (disp->var.bits_per_pixel) { #ifdef FBCON_HAS_CFB8 case 8: - disp->dispsw = &fbcon_cfb8; + disp->dispsw = accel ? &fbcon_radeon8 : &fbcon_cfb8; disp->visual = FB_VISUAL_PSEUDOCOLOR; disp->line_length = disp->var.xres_virtual; break; #endif #ifdef FBCON_HAS_CFB16 case 16: - disp->dispsw = &fbcon_cfb16; + disp->dispsw = accel ? &fbcon_radeon16 : &fbcon_cfb16; disp->dispsw_data = &rinfo->con_cmap.cfb16; disp->visual = FB_VISUAL_DIRECTCOLOR; disp->line_length = disp->var.xres_virtual * 2; break; #endif -#ifdef FBCON_HAS_CFB32 - case 24: - disp->dispsw = &fbcon_cfb24; - disp->dispsw_data = &rinfo->con_cmap.cfb24; - disp->visual = FB_VISUAL_DIRECTCOLOR; - disp->line_length = disp->var.xres_virtual * 4; - break; -#endif #ifdef FBCON_HAS_CFB32 case 32: - disp->dispsw = &fbcon_cfb32; + disp->dispsw = accel ? &fbcon_radeon32 : &fbcon_cfb32; disp->dispsw_data = &rinfo->con_cmap.cfb32; disp->visual = FB_VISUAL_DIRECTCOLOR; disp->line_length = disp->var.xres_virtual * 4; @@ -1736,8 +1772,6 @@ printk ("radeonfb: setting fbcon_dummy renderer\n"); disp->dispsw = &fbcon_dummy; } - - return; } @@ -1759,6 +1793,7 @@ +#if 0 static int radeonfb_do_maximize(struct radeonfb_info *rinfo, struct fb_var_screeninfo *var, struct fb_var_screeninfo *v, @@ -1819,9 +1854,18 @@ return 0; } +#endif +static void set_palette_entry(struct radeonfb_info *rinfo, unsigned idx, unsigned red, unsigned grn, unsigned blu) +{ + OUTREG(PALETTE_INDEX, idx); + OUTREG(PALETTE_DATA, (red << 16) | (grn << 8) | blu); + + udelay(1); /* is this necessary ? */ +} + /* * fb ops */ @@ -1844,7 +1888,7 @@ fix->type_aux = disp->type_aux; fix->visual = disp->visual; - fix->xpanstep = 8; + fix->xpanstep = 0; fix->ypanstep = 1; fix->ywrapstep = 0; @@ -1880,7 +1924,7 @@ struct radeonfb_info *rinfo = (struct radeonfb_info *) info; struct display *disp; struct fb_var_screeninfo v; - int nom, den, accel; + int accel, bytpp, pitch; unsigned chgvar = 0; disp = (con < 0) ? rinfo->info.disp : &fb_display[con]; @@ -1903,110 +1947,97 @@ switch (v.bits_per_pixel) { case 0 ... 8: v.bits_per_pixel = 8; - break; - case 9 ... 16: - v.bits_per_pixel = 16; - break; - case 17 ... 24: - v.bits_per_pixel = 24; - break; - case 25 ... 32: - v.bits_per_pixel = 32; - break; - default: - return -EINVAL; - } - - switch (var_to_depth(&v)) { -#ifdef FBCON_HAS_CFB8 - case 8: - nom = den = 1; - disp->line_length = v.xres_virtual; - disp->visual = FB_VISUAL_PSEUDOCOLOR; v.red.offset = v.green.offset = v.blue.offset = 0; v.red.length = v.green.length = v.blue.length = 8; v.transp.offset = v.transp.length = 0; - break; -#endif - -#ifdef FBCON_HAS_CFB16 - case 15: - nom = 2; - den = 1; - disp->line_length = v.xres_virtual * 2; - disp->visual = FB_VISUAL_DIRECTCOLOR; - v.red.offset = 10; - v.green.offset = 5; - v.red.offset = 0; - v.red.length = v.green.length = v.blue.length = 5; - v.transp.offset = v.transp.length = 0; break; - case 16: - nom = 2; - den = 1; - disp->line_length = v.xres_virtual * 2; - disp->visual = FB_VISUAL_DIRECTCOLOR; - v.red.offset = 11; + case 9 ... 16: +#if FIX_DEPTH_15 + if(v.bits_per_pixel < 16) + v.green.length = 5; +#endif + if(v.green.length != 5 && v.green.length != 6) + v.green.length = 5; + v.bits_per_pixel = 16; + v.red.offset = v.green.length + 5; v.green.offset = 5; v.blue.offset = 0; v.red.length = 5; - v.green.length = 6; v.blue.length = 5; v.transp.offset = v.transp.length = 0; - break; -#endif - -#ifdef FBCON_HAS_CFB24 - case 24: - nom = 4; - den = 1; - disp->line_length = v.xres_virtual * 3; - disp->visual = FB_VISUAL_DIRECTCOLOR; + break; + case 17 ... 32: + v.bits_per_pixel = 32; v.red.offset = 16; v.green.offset = 8; v.blue.offset = 0; v.red.length = v.blue.length = v.green.length = 8; + /* v.transp.offset = 24; v.transp.length = 8; */ v.transp.offset = v.transp.length = 0; - break; -#endif -#ifdef FBCON_HAS_CFB32 - case 32: - nom = 4; - den = 1; - disp->line_length = v.xres_virtual * 4; - disp->visual = FB_VISUAL_DIRECTCOLOR; - v.red.offset = 16; - v.green.offset = 8; - v.blue.offset = 0; - v.red.length = v.blue.length = v.green.length = 8; - v.transp.offset = 24; - v.transp.length = 8; - break; -#endif - default: - printk ("radeonfb: mode %dx%dx%d rejected, color depth invalid\n", - var->xres, var->yres, var->bits_per_pixel); - return -EINVAL; - } + break; + default: + return -EINVAL; + } + + v.red.msb_right = v.green.msb_right = v.blue.msb_right = v.transp.msb_right = 0; + + bytpp = v.bits_per_pixel >> 3; + + if(v.xres > v.xres_virtual) + v.xres_virtual = v.xres; + if(v.yres > v.yres_virtual) + v.yres_virtual = v.yres; + + /* XXX this is probably wrong for 24bpp, if we ever get it working :pdh */ + + pitch = (v.xres_virtual * bytpp + 63) & ~63; + + if(pitch >= 8192) + return -EINVAL; + + v.xres_virtual = pitch / bytpp; + + if(v.xres_virtual < v.xres) + v.xres = v.xres_virtual; + + v.yres_virtual = rinfo->video_ram / pitch; + + /* XXX there is some limit here, I chose 8192 :pdh */ + if(v.yres_virtual >= 8192) + v.yres_virtual = 8191; + + if(v.yres_virtual < v.yres) + v.yres = v.yres_virtual; + +#if 0 if (radeonfb_do_maximize(rinfo, var, &v, nom, den) < 0) return -EINVAL; +#endif + if(v.xoffset) + return -EINVAL; + if (v.xoffset < 0) v.xoffset = 0; if (v.yoffset < 0) v.yoffset = 0; if (v.xoffset > v.xres_virtual - v.xres) - v.xoffset = v.xres_virtual - v.xres - 1; + return -EINVAL; if (v.yoffset > v.yres_virtual - v.yres) - v.yoffset = v.yres_virtual - v.yres - 1; - - v.red.msb_right = v.green.msb_right = v.blue.msb_right = - v.transp.offset = v.transp.length = - v.transp.msb_right = 0; + return -EINVAL; + /* XXX this shouldn't be here :pdh */ + + disp->visual = (v.bits_per_pixel == 8 ? FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_DIRECTCOLOR); + disp->line_length = v.xres_virtual * bytpp; + disp->ypanstep = 1; + disp->ywrapstep = 0; + disp->var.yres_virtual = v.yres_virtual; + + switch (v.activate & FB_ACTIVATE_MASK) { case FB_ACTIVATE_TEST: return 0; @@ -2018,15 +2049,13 @@ } memcpy (&disp->var, &v, sizeof (v)); - + if (chgvar) { - radeon_set_dispsw(rinfo, disp); - if (noaccel) - disp->scrollmode = SCROLL_YREDRAW; - else - disp->scrollmode = 0; - + disp->scrollmode = accel ? 0 : SCROLL_YREDRAW; + + radeon_set_dispsw(rinfo, disp); + if (info && info->changevar) info->changevar(con); } @@ -2093,6 +2122,8 @@ struct fb_info *info) { struct radeonfb_info *rinfo = (struct radeonfb_info *) info; + +#if 0 u32 offset, xoffset, yoffset; xoffset = (var->xoffset + 7) & ~7; @@ -2105,7 +2136,18 @@ offset = ((yoffset * var->xres + xoffset) * var->bits_per_pixel) >> 6; OUTREG(CRTC_OFFSET, offset); +#endif + + /* XXX no X pan for the moment :pdh */ + + if(var->xoffset) + return -EINVAL; + if(var->yoffset + var->yres > var->yres_virtual) + return -EINVAL; + + OUTREG(CRTC_OFFSET, var->yoffset * rinfo->pitch); + return 0; } @@ -2144,12 +2186,14 @@ do_install_cmap(con, info); } +#if 0 /* XXX absurd hack for X to restore console */ { OUTREGP(CRTC_EXT_CNTL, rinfo->hack_crtc_ext_cntl, CRTC_HSYNC_DIS | CRTC_VSYNC_DIS | CRTC_DISPLAY_DIS); OUTREG(CRTC_V_SYNC_STRT_WID, rinfo->hack_crtc_v_sync_strt_wid); } +#endif return 0; } @@ -2214,18 +2258,7 @@ static int radeon_get_cmap_len (const struct fb_var_screeninfo *var) { - int rc = 256; /* reasonable default */ - - switch (var_to_depth(var)) { - case 15: - rc = 32; - break; - case 16: - rc = 64; - break; - } - - return rc; + return var->bits_per_pixel == 8 ? 256 : 16; } @@ -2239,10 +2272,9 @@ if (regno > 255) return 1; - *red = (rinfo->palette[regno].red<<8) | rinfo->palette[regno].red; - *green = (rinfo->palette[regno].green<<8) | rinfo->palette[regno].green; - *blue = (rinfo->palette[regno].blue<<8) | rinfo->palette[regno].blue; - *transp = 0; + *red = (unsigned) rinfo->palette[regno].red << 8; + *green = (unsigned) rinfo->palette[regno].green << 8; + *blue = (unsigned) rinfo->palette[regno].blue << 8; return 0; } @@ -2250,79 +2282,95 @@ static int radeon_setcolreg (unsigned regno, unsigned red, unsigned green, - unsigned blue, unsigned transp, struct fb_info *info) + unsigned blue, unsigned alpha, struct fb_info *info) { struct radeonfb_info *rinfo = (struct radeonfb_info *) info; - u32 pindex; - if (regno > 255) + if(regno > 255) return 1; - red >>= 8; - green >>= 8; - blue >>= 8; - rinfo->palette[regno].red = red; - rinfo->palette[regno].green = green; - rinfo->palette[regno].blue = blue; + red >>= 8; + green >>= 8; + blue >>= 8; + alpha >>= 8; + + rinfo->palette[regno].red = red; + rinfo->palette[regno].green = green; + rinfo->palette[regno].blue = blue; + + /* ugly hack so that the software cursor works */ + + if(regno == 0) { + switch(rinfo->depth) { + + case 16: + radeon_setcolreg(63, ~0, ~0, ~0, 0, info); + /* */ - /* default */ - pindex = regno; - - if (rinfo->bpp == 16) { - pindex = regno * 8; + case 15: + radeon_setcolreg(31, ~0, ~0, ~0, 0, info); + break; - if (rinfo->depth == 16 && regno > 63) - return 1; - if (rinfo->depth == 15 && regno > 31) - return 1; + case 32: + radeon_setcolreg(255, ~0, ~0, ~0, 0, info); + break; + } + } - /* For 565, the green component is mixed one order below */ - if (rinfo->depth == 16) { - OUTREG(PALETTE_INDEX, pindex>>1); - OUTREG(PALETTE_DATA, (rinfo->palette[regno>>1].red << 16) | - (green << 8) | (rinfo->palette[regno>>1].blue)); - green = rinfo->palette[regno<<1].green; - } - } - - if (rinfo->depth != 16 || regno < 32) { - OUTREG(PALETTE_INDEX, pindex); - OUTREG(PALETTE_DATA, (red << 16) | (green << 8) | blue); + switch(rinfo->depth) { + + case 15: + if(regno > 31) + return 1; + if(regno < 16) + rinfo->con_cmap.cfb16[regno] = (regno << 10) | (regno << 5) | regno; + regno <<= 3; + break; + + case 16: + + if(fb16fix) { + + /* this is just another format of 15 bit mode, the LSB of the * + * green pixel data is ignored. this is required for "fbtv" and * + * other apps to work correctly at 16bpp, but it means you land * + * up with a sick looking boot logo. the real fix is to run at * + * 15bpp when you want to use those apps :pdh */ + + if(regno > 31) + return 1; + if(regno < 16) + rinfo->con_cmap.cfb16[regno] = (regno << 11) | (regno << 6) | regno; + regno <<= 3; + set_palette_entry(rinfo, regno | 4, red, green, blue); + + } else { + + if(regno > 63) + return 1; + if(regno < 16) + rinfo->con_cmap.cfb16[regno] = (regno << 11) | (regno << 5) | regno; + set_palette_entry(rinfo, regno << 2, rinfo->palette[regno >> 1].red, + green, rinfo->palette[regno >> 1].blue); + if(regno > 31) + return 0; + regno <<= 1; + green = rinfo->palette[regno].green; + regno <<= 2; + } + break; + + case 32: + if(regno < 16) + rinfo->con_cmap.cfb32[regno] = (regno << 16) | (regno << 8) | regno; + break; } - if (regno < 16) { - switch (rinfo->depth) { -#ifdef FBCON_HAS_CFB16 - case 15: - rinfo->con_cmap.cfb16[regno] = (regno << 10) | (regno << 5) | - regno; - break; - case 16: - rinfo->con_cmap.cfb16[regno] = (regno << 11) | (regno << 5) | - regno; - break; -#endif -#ifdef FBCON_HAS_CFB24 - case 24: - rinfo->con_cmap.cfb24[regno] = (regno << 16) | (regno << 8) | regno; - break; -#endif -#ifdef FBCON_HAS_CFB32 - case 32: { - u32 i; - - i = (regno << 8) | regno; - rinfo->con_cmap.cfb32[regno] = (i << 16) | i; - break; - } -#endif - } - } + set_palette_entry(rinfo, regno, red, green, blue); + return 0; } - - static void radeon_save_state (struct radeonfb_info *rinfo, struct radeon_regs *save) { @@ -2373,8 +2421,10 @@ int primary_mon = PRIMARY_MONITOR(rinfo); int depth = var_to_depth(mode); + bytpp = mode->bits_per_pixel >> 3; rinfo->xres = mode->xres; rinfo->yres = mode->yres; + rinfo->pitch = mode->xres_virtual * bytpp; rinfo->pixclock = mode->pixclock; hSyncStart = mode->xres + mode->right_margin; @@ -2404,9 +2454,9 @@ h_sync_pol = sync & FB_SYNC_HOR_HIGH_ACT ? 0 : 1; v_sync_pol = sync & FB_SYNC_VERT_HIGH_ACT ? 0 : 1; - RTRACE("hStart = %d, hEnd = %d, hTotal = %d\n", + RTRACE("hStart = %d, hEnd = %d, hTotal = %d", hSyncStart, hSyncEnd, hTotal); - RTRACE("vStart = %d, vEnd = %d, vTotal = %d\n", + RTRACE("vStart = %d, vEnd = %d, vTotal = %d", vSyncStart, vSyncEnd, vTotal); hsync_wid = (hSyncEnd - hSyncStart) / 8; @@ -2427,7 +2477,6 @@ cSync = mode->sync & FB_SYNC_COMP_HIGH_ACT ? (1 << 4) : 0; format = radeon_get_dstbpp(depth); - bytpp = mode->bits_per_pixel >> 3; if ((primary_mon == MT_DFP) || (primary_mon == MT_LCD)) hsync_fudge = hsync_fudge_fp[format-1]; @@ -2463,7 +2512,7 @@ newmode.crtc_v_sync_strt_wid = (((vSyncStart - 1) & 0xfff) | (vsync_wid << 16) | (v_sync_pol << 23)); - newmode.crtc_pitch = (mode->xres >> 3); + newmode.crtc_pitch = mode->xres_virtual >> 3; newmode.crtc_pitch |= (newmode.crtc_pitch << 16); #if defined(__BIG_ENDIAN) @@ -2479,12 +2528,9 @@ } #endif - rinfo->pitch = ((mode->xres * ((mode->bits_per_pixel + 1) / 8) + 0x3f) - & ~(0x3f)) / 64; - - RTRACE("h_total_disp = 0x%x\t hsync_strt_wid = 0x%x\n", + RTRACE("h_total_disp = 0x%x hsync_strt_wid = 0x%x", newmode.crtc_h_total_disp, newmode.crtc_h_sync_strt_wid); - RTRACE("v_total_disp = 0x%x\t vsync_strt_wid = 0x%x\n", + RTRACE("v_total_disp = 0x%x vsync_strt_wid = 0x%x", newmode.crtc_v_total_disp, newmode.crtc_v_sync_strt_wid); newmode.xres = mode->xres; @@ -2493,8 +2539,10 @@ rinfo->bpp = mode->bits_per_pixel; rinfo->depth = depth; +#if 0 rinfo->hack_crtc_ext_cntl = newmode.crtc_ext_cntl; rinfo->hack_crtc_v_sync_strt_wid = newmode.crtc_v_sync_strt_wid; +#endif if (freq > rinfo->pll.ppll_max) freq = rinfo->pll.ppll_max; @@ -2532,9 +2580,9 @@ newmode.ppll_div_3 = rinfo->fb_div | (post_div->bitvalue << 16); } - RTRACE("post div = 0x%x\n", rinfo->post_div); - RTRACE("fb_div = 0x%x\n", rinfo->fb_div); - RTRACE("ppll_div_3 = 0x%x\n", newmode.ppll_div_3); + RTRACE("post div = 0x%x", rinfo->post_div); + RTRACE("fb_div = 0x%x", rinfo->fb_div); + RTRACE("ppll_div_3 = 0x%x", newmode.ppll_div_3); /* DDA */ vclk_freq = round_div(rinfo->pll.ref_clk * rinfo->fb_div, @@ -2554,8 +2602,8 @@ xclk_per_trans) << (11 - useable_precision); roff = xclk_per_trans_precise * (32 - 4); - RTRACE("ron = %d, roff = %d\n", ron, roff); - RTRACE("vclk_freq = %d, per = %d\n", vclk_freq, xclk_per_trans_precise); + RTRACE("ron = %d, roff = %d", ron, roff); + RTRACE("vclk_freq = %d, per = %d", vclk_freq, xclk_per_trans_precise); if ((ron + rinfo->ram.rloop) >= roff) { printk("radeonfb: error ron out of range\n"); @@ -2621,6 +2669,11 @@ newmode.tmds_crc = rinfo->init_state.tmds_crc; newmode.tmds_transmitter_cntl = rinfo->init_state.tmds_transmitter_cntl; + /* XXX :pdh * + * this doesn't work with some DFPs. a different driver that * + * does work loads the FP CRTC registers from initial saved * + * values and doesn't tweak with tmds_transmitter_cntl ????? */ + if (primary_mon == MT_LCD) { newmode.lvds_gen_cntl |= (LVDS_ON | LVDS_BLON); newmode.fp_gen_cntl &= ~(FP_FPON | FP_TMDS_EN); @@ -2657,15 +2710,13 @@ int primary_mon = PRIMARY_MONITOR(rinfo); /* blank screen */ - OUTREGP(CRTC_EXT_CNTL, CRTC_DISPLAY_DIS | CRTC_VSYNC_DIS | CRTC_HSYNC_DIS, - ~(CRTC_DISPLAY_DIS | CRTC_VSYNC_DIS | CRTC_HSYNC_DIS)); + OUTREGP(CRTC_EXT_CNTL, mode->crtc_ext_cntl, + ~(CRTC_HSYNC_DIS | CRTC_VSYNC_DIS | CRTC_DISPLAY_DIS)); for (i=0; i<9; i++) OUTREG(common_regs[i].reg, common_regs[i].val); OUTREG(CRTC_GEN_CNTL, mode->crtc_gen_cntl); - OUTREGP(CRTC_EXT_CNTL, mode->crtc_ext_cntl, - CRTC_HSYNC_DIS | CRTC_VSYNC_DIS | CRTC_DISPLAY_DIS); OUTREGP(DAC_CNTL, mode->dac_cntl, DAC_RANGE_CNTL | DAC_BLANKING); OUTREG(CRTC_H_TOTAL_DISP, mode->crtc_h_total_disp); OUTREG(CRTC_H_SYNC_STRT_WID, mode->crtc_h_sync_strt_wid); @@ -2743,7 +2794,7 @@ } /* unblank screen */ - OUTREG8(CRTC_EXT_CNTL + 1, 0); + OUTREG(CRTC_EXT_CNTL, mode->crtc_ext_cntl); return; } @@ -2966,6 +3017,8 @@ width *= fontwidth(p); height *= fontheight(p); + dp_cntl = 0; + if (srcy < dsty) { srcy += height - 1; dsty += height - 1; @@ -2992,22 +3045,8 @@ } - -static void fbcon_radeon_clear(struct vc_data *conp, struct display *p, - int srcy, int srcx, int height, int width) +static void fbcon_radeon_clear(struct radeonfb_info *rinfo, int srcy, int srcx, int height, int width, u32 clr) { - struct radeonfb_info *rinfo = (struct radeonfb_info *)(p->fb_info); - u32 clr; - - clr = attr_bgcol_ec(p, conp); - clr |= (clr << 8); - clr |= (clr << 16); - - srcx *= fontwidth(p); - srcy *= fontheight(p); - width *= fontwidth(p); - height *= fontheight(p); - radeon_fifo_wait(6); OUTREG(DP_GUI_MASTER_CNTL, (rinfo->dp_gui_master_cntl | GMC_BRUSH_SOLID_COLOR | @@ -3021,12 +3060,24 @@ } - #ifdef FBCON_HAS_CFB8 +static void fbcon_radeon8_clear(struct vc_data *conp, struct display *p, + int srcy, int srcx, int height, int width) +{ + u32 clr; + + clr = attr_bgcol_ec(p, conp); + clr |= clr << 8; + + fbcon_radeon_clear((struct radeonfb_info *) p->fb_info, srcy * fontheight(p), srcx * fontwidth(p), + height * fontheight(p), width * fontwidth(p), clr | (clr << 16)); +} + + static struct display_switch fbcon_radeon8 = { setup: fbcon_cfb8_setup, bmove: fbcon_radeon_bmove, - clear: fbcon_radeon_clear, + clear: fbcon_radeon8_clear, putc: fbcon_cfb8_putc, putcs: fbcon_cfb8_putcs, revc: fbcon_cfb8_revc, @@ -3034,3 +3085,48 @@ fontwidthmask: FONTWIDTH(4)|FONTWIDTH(8)|FONTWIDTH(12)|FONTWIDTH(16) }; #endif + +#ifdef FBCON_HAS_CFB16 +static void fbcon_radeon16_clear(struct vc_data *conp, struct display *p, + int srcy, int srcx, int height, int width) +{ + u32 clr; + + clr = ((u16 *) p->dispsw_data)[attr_bgcol_ec(p, conp)]; + + fbcon_radeon_clear((struct radeonfb_info *) p->fb_info, srcy * fontheight(p), srcx * fontwidth(p), + height * fontheight(p), width * fontwidth(p), clr | (clr << 16)); +} + +static struct display_switch fbcon_radeon16 = { + setup: fbcon_cfb16_setup, + bmove: fbcon_radeon_bmove, + clear: fbcon_radeon16_clear, + putc: fbcon_cfb16_putc, + putcs: fbcon_cfb16_putcs, + revc: fbcon_cfb16_revc, + clear_margins: fbcon_cfb16_clear_margins, + fontwidthmask: FONTWIDTH(4)|FONTWIDTH(8)|FONTWIDTH(12)|FONTWIDTH(16) +}; +#endif + +#ifdef FBCON_HAS_CFB32 +static void fbcon_radeon32_clear(struct vc_data *conp, struct display *p, + int srcy, int srcx, int height, int width) +{ + fbcon_radeon_clear((struct radeonfb_info *) p->fb_info, srcy * fontheight(p), srcx * fontwidth(p), + height * fontheight(p), width * fontwidth(p), ((u32 *) p->dispsw_data)[attr_bgcol_ec(p, conp)]); +} + +static struct display_switch fbcon_radeon32 = { + setup: fbcon_cfb32_setup, + bmove: fbcon_radeon_bmove, + clear: fbcon_radeon32_clear, + putc: fbcon_cfb32_putc, + putcs: fbcon_cfb32_putcs, + revc: fbcon_cfb32_revc, + clear_margins: fbcon_cfb32_clear_margins, + fontwidthmask: FONTWIDTH(4)|FONTWIDTH(8)|FONTWIDTH(12)|FONTWIDTH(16) +}; +#endif + ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] radeonfb update vs 2.4.20-pre1 2002-08-11 21:22 ` [PATCH] radeonfb update vs 2.4.20-pre1 Erik Andersen @ 2002-08-12 10:18 ` Ani Joshi 2002-08-12 10:26 ` Erik Andersen 0 siblings, 1 reply; 27+ messages in thread From: Ani Joshi @ 2002-08-12 10:18 UTC (permalink / raw) To: Erik Andersen; +Cc: Marcelo Tosatti, lkml These issues are addressed (or should be) in version 0.1.5 of radeonfb which was posted to the fbdev list a month or so ago. I am waiting on a few other fixes I need to get done before I send an update to Marcelo, but rest assured this will happen in the 2.4.20 cycle. ani On Sun, 11 Aug 2002, Erik Andersen wrote: > Here is an update to the radeonfb. This is based on a patch > from Peter Horton that was posted to the lkml back in April > http://www.uwsg.indiana.edu/hypermail/linux/kernel/0204.1/0364.html > > I have been carrying this patch along in my own tree since April > and I find it a huge improvement. Using this patch, I find that > the radeonfb is quite fast, and colors are correct. > > I have updated the patch to fit into 2.4.20-pre1, fixed a few > obvious little things, and reworked the mtrr handling so it > matches the behavior of the other framebuffers. Any chance > we could get this into 2.4.20? > > -Erik > > -- > Erik B. Andersen http://codepoet-consulting.com/ > --This message was written using 73% post-consumer electrons-- > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH] radeonfb update vs 2.4.20-pre1 2002-08-12 10:18 ` Ani Joshi @ 2002-08-12 10:26 ` Erik Andersen 0 siblings, 0 replies; 27+ messages in thread From: Erik Andersen @ 2002-08-12 10:26 UTC (permalink / raw) To: Ani Joshi; +Cc: Marcelo Tosatti, lkml On Mon Aug 12, 2002 at 03:18:02AM -0700, Ani Joshi wrote: > > These issues are addressed (or should be) in version 0.1.5 of radeonfb > which was posted to the fbdev list a month or so ago. I am waiting on a > few other fixes I need to get done before I send an update to Marcelo, but > rest assured this will happen in the 2.4.20 cycle. Excellent thanks. Is the latest and greatest posted somewhere? -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Linux 2.4.20-pre1 2002-08-05 22:40 Linux 2.4.20-pre1 Marcelo Tosatti ` (8 preceding siblings ...) 2002-08-11 21:22 ` [PATCH] radeonfb update vs 2.4.20-pre1 Erik Andersen @ 2002-08-17 19:51 ` Adrian Bunk 9 siblings, 0 replies; 27+ messages in thread From: Adrian Bunk @ 2002-08-17 19:51 UTC (permalink / raw) To: Marcelo Tosatti, ak; +Cc: lkml, Alan Cox On Mon, 5 Aug 2002, Marcelo Tosatti wrote: >... > Summary of changes from v2.4.19 to v2.4.20-pre1 > ============================================ >... > <ak@muc.de> (02/08/05 1.657) > [PATCH] Ftape 64bit/x86-64 fixes >... This broke the modular building of ftape. In -pre3: <-- snip --> ... depmod: *** Unresolved symbols in /lib/modules/2.4.20-pre3/kernel/drivers/char/ftape/lowlevel/ftape.o depmod: i8253_lock ... <-- snip --> Alan made the following patch to fix it (already in -ac): --- linux.20pre2/arch/i386/kernel/time.c 2002-08-13 13:58:33.000000000 +0100 +++ linux.20pre2-ac3/arch/i386/kernel/time.c 2002-08-12 15:17:04.000000000 +0100 @@ -31,6 +31,7 @@ */ #include <linux/errno.h> +#include <linux/module.h> #include <linux/sched.h> #include <linux/kernel.h> #include <linux/param.h> @@ -116,6 +117,8 @@ spinlock_t i8253_lock = SPIN_LOCK_UNLOCKED; +EXPORT_SYMBOL(i8253_lock); + extern spinlock_t i8259A_lock; #ifndef CONFIG_X86_TSC cu Adrian ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2002-08-17 19:47 UTC | newest] Thread overview: 27+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2002-08-05 22:40 Linux 2.4.20-pre1 Marcelo Tosatti 2002-08-06 0:20 ` Ben Greear 2002-08-06 11:32 ` Marcelo Tosatti 2002-08-06 12:26 ` David S. Miller 2002-08-06 16:45 ` Ben Greear 2002-08-06 17:12 ` NAPI (was Re: Linux 2.4.20-pre1) Jeff Garzik 2002-08-07 14:09 ` Marcus Sundberg 2002-08-06 14:58 ` Linux 2.4.20-pre1 Jason Lunz 2002-08-06 15:03 ` CaT 2002-08-06 21:05 ` Adrian Bunk 2002-08-07 11:09 ` David S. Miller 2002-08-07 0:21 ` J.A. Magallon 2002-08-07 1:08 ` J.A. Magallon 2002-08-07 1:56 ` Bryan Whitehead 2002-08-07 3:35 ` Tim Hockin 2002-08-11 8:57 ` Erik Andersen 2002-08-11 9:16 ` Christoph Hellwig 2002-08-11 9:40 ` Erik Andersen 2002-08-11 9:46 ` Erik Andersen 2002-08-11 19:46 ` Alan Cox 2002-08-11 18:49 ` Erik Andersen 2002-08-12 19:29 ` Paul P Komkoff Jr 2002-08-11 10:56 ` Erik Andersen 2002-08-11 21:22 ` [PATCH] radeonfb update vs 2.4.20-pre1 Erik Andersen 2002-08-12 10:18 ` Ani Joshi 2002-08-12 10:26 ` Erik Andersen 2002-08-17 19:51 ` Linux 2.4.20-pre1 Adrian Bunk
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox