* Re: Stable Linux kernel 2.6 for MPC8XX
From: David Jander @ 2006-03-14 7:50 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060310153341.080163525CB@atlas.denx.de>
On Friday 10 March 2006 16:33, Wolfgang Denk wrote:
> > I believe most of those observations and measurements are not valid
> > anymore. Kernel 2.6 for 8xx has come a long way since this article was
> > written. It might have been true back then, but it surely isn't anymore.
>
> So did you actually run any benchmarks? Specilations on what might be
> or should be are not really helpful.
Of course I did. Otherwise I wouldn't say this.
Here's some benchmark data from nbench (sorry didn't try lmbench yet):
The same ELDK (version 3.1.1) for both kernels, running on exactly the same
board (MPC852T 100MHz, with 32Mbyte SDRAM and 32Mbyte Flash running from NFS
root). I removed some FPU benchmarks, as they are pretty meaningless for this
board and take an ethernity otherwise.
Results for Kernel 2.4.25 (Denx CVS from around sept-oct or so, 2005):
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 30.438 : 0.78 : 0.26
STRING SORT : 1.5842 : 0.71 : 0.11
BITFIELD : 7.9506e+06 : 1.36 : 0.28
FP EMULATION : 3.258 : 1.56 : 0.36
IDEA : 108.89 : 1.67 : 0.49
HUFFMAN : 26.281 : 0.73 : 0.23
LU DECOMPOSITION : 0.32765 : 0.02 : 0.01
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 1.052
FLOATING-POINT INDEX: 0.257
Now the results for 2.6.14 (Denx git released 2.6.14):
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 32.654 : 0.84 : 0.28
STRING SORT : 1.7408 : 0.78 : 0.12
BITFIELD : 8.3466e+06 : 1.43 : 0.30
FP EMULATION : 3.506 : 1.68 : 0.39
IDEA : 115.3 : 1.76 : 0.52
HUFFMAN : 27.855 : 0.77 : 0.25
LU DECOMPOSITION : 0.35932 : 0.02 : 0.01
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 1.115
FLOATING-POINT INDEX: 0.265
I don't know why, but while everyone still says 2.6 is slower, I am
consistently getting results that seem to prove the opposite. Why?
Is the TLB/cache stuff better optimized for 8xx in 2.6?
IMHO it is quite a difference.
Btw, I also wrote different small "speed-measurement" tools (to measure
loop-speed, memory throughput for different block sizes, etc...) and they all
show aproximately the same increase.
I was careful to strip both kernels of all unnecessary drivers and features
that could hamper performance. If you wish I could try to dig up the .config
files for you, but I am not sure I'll find them anymore (I did this when
2.6.14 was just released).
Greetings,
--
David Jander
Protonic Holland.
^ permalink raw reply
* RE: Where to define IO ports
From: iseno @ 2006-03-14 6:01 UTC (permalink / raw)
To: edjubenville, linuxppc-embedded
Hi Ed,
I think you should change the "u-boot".
- include/configs/IceCube.h
- board/icecube/icecube.h
1st, put a constant like (CFG_CS1_START, CFG_CS1_STOP, CFG_CS1_CFG) to
IceCube.h.
And then, write some code to configure registers like (MPC5XXX_CS0_START,
MPC5XXX_CS0_STOP, MPC5XXX_CS0_CFG).
After that, you will be able to use ioremap() in your driver.
>We have added a peripheral to the LocalPlus bus, and I'm trying to figure
Is this address kernel space?
If this is so, you have to change "TEXT_BASE" in u-boot's Makefile and etc.
Akihiro Iseno
=================================
Akihiro Iseno <iseno@tomen-ele.co.jp>
TOMEN Electronics Corp.
System Engineering Dept. II
=================================
-----Original Message-----
From: Edward Jubenville [mailto:edjubenville@adelphia.net]
Sent: Tuesday, March 14, 2006 1:41 PM
To: linuxppc-embedded@ozlabs.org
Subject: Where to define IO ports
We are building a board similar to the Freescale Lite5200 (IceCube) board,
using ELDK 3.0 with Linux 2.4.25.
We have added a peripheral to the LocalPlus bus, and I'm trying to figure
out how to modify the kernel startup code to define a memory address range
and generate the proper chip select signal.
Can someone point me to where that sort of thing is done in the kernel
source?
Ed
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Where to define IO ports
From: Edward Jubenville @ 2006-03-14 4:40 UTC (permalink / raw)
To: linuxppc-embedded
We are building a board similar to the Freescale Lite5200 (IceCube) board,
using ELDK 3.0 with Linux 2.4.25.
We have added a peripheral to the LocalPlus bus, and I'm trying to figure
out how to modify the kernel startup code to define a memory address range
and generate the proper chip select signal.
Can someone point me to where that sort of thing is done in the kernel
source?
Ed
^ permalink raw reply
* Re: Help: How to search for previous topics
From: Ron Kellam @ 2006-03-14 3:33 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <DJEKKNGPKJJHLCHIBHDAEEIPCCAA.kris@slokatelecom.com>
Using your favourite news reader, subscribe to
gmane.linux.ports.ppc.embedded newsgroup at server news.gmane.org, and
get it to suck back all the messages it can (you'll get in the order
of 11800 - back to about Feb 2002). Then use your news reader's
search features - a decent one will allow regex searches, etc.
See www.gmane.org for more info on how it makes mailing lists
available as newsgroups.
Cheers,
Ron
^ permalink raw reply
* Re: dtc: .quad asm directive generation
From: David Gibson @ 2006-03-14 3:31 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20060313212105.GA11995@mag.az.mvista.com>
On Mon, Mar 13, 2006 at 02:21:05PM -0700, Mark A. Greer wrote:
> Hi David,
>
> I'm playing around with moving some 32-bit embedded platforms (that don't
> have OF or dev-tree-aware uboot) to the powerpc tree. Basically, I make an
> initial .dts file for that platform then dtc-compile it using:
>
> dtc -I dts -O asm -o <platform>.S -V 16 <platform>.dts
>
> Then I build the <platform>.S file with the normal bootwrapper/kernel build.
>
> The problem I'm having is that dtc generates some .quad directives that
> is causing my 32-bit assembler to choke (.quad not supported). Do we need
> a 32-bit switch for dtc or should I be giving some sort of switch to
> gcc(version 3.4.3)/gas(version 2.15.94) to make it work?
[snip]
> dtc asm output:
> ---------------
>
> /* autogenerated by dtc, do not edit */
>
> <snip>
>
> dt_reserve_map:
> _dt_reserve_map:
> .quad 0, _dt_blob_start
> .quad 0, _dt_blob_end - _dt_blob_start
> /* Memory reserve map from source file */
> .quad 0
> .quad 0
>
> <snip>
Oh, bother. I guess I never tried with a 32-bit only assembler. Um,
a number of observations are applicable here:
- The flattened tree spec defines the memory range fields to
be 64-bit quantities, always, so these things shouldn't just become
".long" for 32-bit targets.
- For the "spacer" 0 entries, we can and should just replace
the .quad with two ".long" directives, easy change.
- The autogenerated entry reserving the tree itself, however,
is trickier. It genuinely needs to be a .quad for 64-bit targets. So
I guess we'd have to have a 32/64 bit target option. Yuck.
- IIRC BenH was contemplating revising the spec so that the
range for the device tree is reserved implicitly, like the range for
the kernel image, so it wouldn't have to be listed in the blob. This
would sidestep the problem, though we would have to change dtc to omit
this entry, at least for suitable output blob versions.
- I've been thinking for a while, that the whole memory
reserve thing needs some work in dtc. The fact that the range for the
tree blob is included automatically for asm output, but not for blob
output is a wart, at least. I was thinking about instead of
automatically generating it, including a new keyword, or form for the
/memreserve/ directive that will generate this range if necessary /
possible. I never got around to implementing that, though.
And finally, as of, well right about now, until October or so, I'm
expecting to be unavailable, off travelling and things. In the
interim Jon Loeliger of Freescale has agreed to be dtc maintainer.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* buildroot uClibc busybox and associated tool versions
From: Ben @ 2006-03-14 1:48 UTC (permalink / raw)
To: linuxppc-embedded
Hi all
Im looking for some info on what versions of uClibc , busybox , gcc , binutils
and kernel headers are best to use to build up a toolchain and rootfs for a 82xx
PPC.
I am using buildroot http://buildroot.uClibc.org to generate the toolchain
associated tools and rootfs but so far have not had much luck.
The host machine i am compiling on is a dell poweredge 650 xeon server running
Fedora Core 3, it has gcc 3.4.2-6 binutils-2.15.92.0.2 glibc-2.3.3 and
linux version 2.6.9-1.667.
Im trying to compile up a rootfs for 82xx PPC with the following
gcc 4.0.2
binutils 2.16.1
Kernel headers 2.16.12
uClibc - whatever version works best, right now i have daily snapshot 20060113
busybox - whatever version works best, right now i have snapshot from 9th march
and am applying patches released from 9th march - 13th march.
Personally i think the choices of gcc , binutils and Kernel headers are fine, i
seem to be having more trouble with the uClibc ver and busybox ver.
Last Friday 10th march selecting the daily snapshot of uClibc caused the
compilation to not get past the point of generating gcc and bin utils. Using the
daily snapshot version of busybox also caused compilation to fail with it
reporting lots of .os and .osm files missing in the libbb dir until i applied
todays patches.
Ive also tried building with use daily snapshot unchecked for busybox and uClibc
but compilation fails.
Surely someone out there must know what versions of everything are the best to
use to generate a toolchain and rootfs for PPC.
Any help anyone could give would be greatly appreciated
^ permalink raw reply
* Re: pppd in eldk
From: Antonio Di Bacco @ 2006-03-13 21:33 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060313000630.5056C353A57@atlas.denx.de>
[-- Attachment #1: Type: text/plain, Size: 901 bytes --]
I compiled pppd 2.4.3 slightly modifying the Makefile (attached). Now I want
to use it to connect two segments of the same LAN. I'm working.
Bye,
Antonio.
On Monday 13 March 2006 01:06, Wolfgang Denk wrote:
> In message <200603121913.56832.antonio.dibacco@aruba.it> you wrote:
> > I didn't find the ppp package in denx eldk, I tried to cross compile the
>
> It's not included so far.
>
> > sources (from sourceforge) but I received some errors (pcap_t
> > undeclared). Before I continue I would investigate if someone was already
> > successful with ppp on ppc.
>
> We built it once for some of our customers (for ARM and ppc_8xx,
> IIRC); I can't remember of any specific problems.
>
> If cross compiling is too time-consuming you can also compile it
> natively on the target system - this may take more machine time, but
> less developer's time ;-)
>
> Best regards,
>
> Wolfgang Denk
[-- Attachment #2: Makefile --]
[-- Type: text/x-makefile, Size: 5137 bytes --]
#
# pppd makefile for Linux
# $Id: Makefile.linux,v 1.66 2004/11/13 12:02:22 paulus Exp $
#
ROOTDIR = /opt/eldk/ppc_8xx/
# Default installation locations
DESTDIR = $(ROOTDIR)usr/local
BINDIR = $(DESTDIR)/sbin
MANDIR = $(DESTDIR)/share/man/man8
INCDIR = $(DESTDIR)/include
TARGETS = pppd
PPPDSRCS = main.c magic.c fsm.c lcp.c ipcp.c upap.c chap-new.c md5.c ccp.c \
ecp.c ipxcp.c auth.c options.c sys-linux.c md4.c chap_ms.c \
demand.c utils.c tty.c eap.c chap-md5.c
HEADERS = ccp.h chap-new.h ecp.h fsm.h ipcp.h \
ipxcp.h lcp.h magic.h md5.h patchlevel.h pathnames.h pppd.h \
upap.h eap.h
MANPAGES = pppd.8
PPPDOBJS = main.o magic.o fsm.o lcp.o ipcp.o upap.o chap-new.o md5.o ccp.o \
ecp.o auth.o options.o demand.o utils.o sys-linux.o tty.o \
eap.o chap-md5.o
#
# include dependencies if present
ifeq (.depend,$(wildcard .depend))
include .depend
endif
CC = ${CROSS_COMPILE}gcc
LD = ${CROSS_COMPILE}ld
AS = ${CROSS_COMPILE}as
#
COPTS = -O2 -pipe -Wall -g
LIBS =
# Uncomment the next 2 lines to include support for Microsoft's
# MS-CHAP authentication protocol. Also, edit plugins/radius/Makefile.linux.
#CHAPMS=y
#USE_CRYPT=y
# Don't use MSLANMAN unless you really know what you're doing.
#MSLANMAN=y
# Uncomment the next line to include support for MPPE. CHAPMS (above) must
# also be enabled. Also, edit plugins/radius/Makefile.linux.
#MPPE=y
# Uncomment the next line to include support for PPP packet filtering.
# This requires that the libpcap library and headers be installed
# and that the kernel driver support PPP packet filtering.
#FILTER=y
# Uncomment the next line to enable multilink PPP (enabled by default)
# Linux distributions: Please leave multilink ENABLED in your builds
# of pppd!
#HAVE_MULTILINK=y
# Uncomment the next line to enable the TDB database (enabled by default.)
# If you enable multilink, then TDB is automatically enabled also.
# Linux distributions: Please leave TDB ENABLED in your builds.
#USE_TDB=y
#HAS_SHADOW=y
#USE_PAM=y
#HAVE_INET6=y
# Enable plugins
#PLUGIN=y
# Enable Microsoft proprietary Callback Control Protocol
#CBCP=y
# Enable EAP SRP-SHA1 authentication (requires libsrp)
#USE_SRP=y
MAXOCTETS=y
INCLUDE_DIRS= -I../include
COMPILE_FLAGS= -DHAVE_PATHS_H -DHAVE_MMAP
CFLAGS= $(COPTS) $(COMPILE_FLAGS) $(INCLUDE_DIRS)
ifdef CHAPMS
CFLAGS += -DCHAPMS=1
NEEDDES=y
PPPDOBJS += md4.o chap_ms.o
HEADERS += md4.h chap_ms.h
ifdef MSLANMAN
CFLAGS += -DMSLANMAN=1
endif
ifdef MPPE
CFLAGS += -DMPPE=1
endif
endif
# EAP SRP-SHA1
ifdef USE_SRP
CFLAGS += -DUSE_SRP -DOPENSSL -I$(ROOTDIR)usr/local/ssl/include
LIBS += -lsrp -L$(ROOTDIR)usr/local/ssl/lib -lcrypto
TARGETS += srp-entry
EXTRAINSTALL = $(INSTALL) -s -c -m 555 srp-entry $(BINDIR)/srp-entry
MANPAGES += srp-entry.8
EXTRACLEAN += srp-entry.o
NEEDDES=y
else
# OpenSSL has an integrated version of SHA-1, and its implementation
# is incompatible with this local SHA-1 implementation. We must use
# one or the other, not both.
PPPDSRCS += sha1.c
HEADERS += sha1.h
PPPDOBJS += sha1.o
endif
ifdef HAS_SHADOW
CFLAGS += -DHAS_SHADOW
#LIBS += -lshadow $(LIBS)
endif
ifneq ($(wildcard $(ROOTDIR)usr/include/crypt.h),)
CFLAGS += -DHAVE_CRYPT_H=1
endif
ifneq ($(wildcard $(ROOTDIR)usr/lib/libcrypt.*),)
LIBS += -lcrypt
endif
ifdef NEEDDES
ifndef USE_CRYPT
LIBS += -ldes $(LIBS)
else
CFLAGS += -DUSE_CRYPT=1
endif
PPPDOBJS += pppcrypt.o
HEADERS += pppcrypt.h
endif
# For "Pluggable Authentication Modules", see ftp.redhat.com:/pub/pam/.
ifdef USE_PAM
CFLAGS += -DUSE_PAM
LIBS += -lpam -ldl
endif
# Multi-linnk
ifdef HAVE_MULTILINK
# Multilink implies the use of TDB
USE_TDB=y
CFLAGS += -DHAVE_MULTILINK
PPPDSRCS += multilink.c
PPPDOBJS += multilink.o
endif
# TDB
ifdef USE_TDB
CFLAGS += -DUSE_TDB=1
PPPDSRCS += tdb.c spinlock.c
PPPDOBJS += tdb.o spinlock.o
HEADERS += tdb.h spinlock.h
endif
# Lock library binary for Linux is included in 'linux' subdirectory.
ifdef LOCKLIB
LIBS += -llock
CFLAGS += -DLOCKLIB=1
endif
ifdef PLUGIN
CFLAGS += -DPLUGIN
LDFLAGS += -Wl,-E
LIBS += -ldl
endif
ifdef FILTER
ifneq ($(wildcard $(ROOTDIR)usr/include/pcap-bpf.h),)
LIBS += -lpcap
CFLAGS += -DPPP_FILTER
endif
endif
ifdef HAVE_INET6
PPPDSRCS += ipv6cp.c eui64.c
HEADERS += ipv6cp.h eui64.h
PPPDOBJS += ipv6cp.o eui64.o
CFLAGS += -DINET6=1
endif
ifdef CBCP
PPPDSRCS += cbcp.c
PPPDOBJS += cbcp.o
CFLAGS += -DCBCP_SUPPORT
HEADERS += cbcp.h
endif
ifdef MAXOCTETS
CFLAGS += -DMAXOCTETS
endif
INSTALL= install
all: $(TARGETS)
install: pppd
mkdir -p $(BINDIR) $(MANDIR)
$(EXTRAINSTALL)
$(INSTALL) -s -c -m 555 pppd $(BINDIR)/pppd
if chgrp pppusers $(BINDIR)/pppd 2>/dev/null; then \
chmod o-rx,u+s $(BINDIR)/pppd; fi
$(INSTALL) -c -m 444 pppd.8 $(MANDIR)
pppd: $(PPPDOBJS)
$(CC) $(CFLAGS) $(LDFLAGS) -o pppd $(PPPDOBJS) $(LIBS)
srp-entry: srp-entry.c
$(CC) $(CFLAGS) $(LDFLAGS) -o $@ srp-entry.c $(LIBS)
install-devel:
mkdir -p $(INCDIR)/pppd
$(INSTALL) -c -m 644 $(HEADERS) $(INCDIR)/pppd
clean:
rm -f $(PPPDOBJS) $(EXTRACLEAN) $(TARGETS) *~ #* core
depend:
$(CPP) -M $(CFLAGS) $(PPPDSRCS) >.depend
^ permalink raw reply
* dtc: .quad asm directive generation
From: Mark A. Greer @ 2006-03-13 21:21 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
Hi David,
I'm playing around with moving some 32-bit embedded platforms (that don't
have OF or dev-tree-aware uboot) to the powerpc tree. Basically, I make an
initial .dts file for that platform then dtc-compile it using:
dtc -I dts -O asm -o <platform>.S -V 16 <platform>.dts
Then I build the <platform>.S file with the normal bootwrapper/kernel build.
The problem I'm having is that dtc generates some .quad directives that
is causing my 32-bit assembler to choke (.quad not supported). Do we need
a 32-bit switch for dtc or should I be giving some sort of switch to
gcc(version 3.4.3)/gas(version 2.15.94) to make it work?
Thanks,
Mark
---
dts:
----
/ {
linux,phandle = <100>;
model = "Sandpoint";
compatible = "MPC10x";
#address-cells = <1>;
#size-cells = <1>;
cpus {
linux,phandle = <200>;
#cpus = <1>;
#address-cells = <1>;
#size-cells = <0>;
PowerPC,7447A {
linux,phandle = <201>;
linux,boot-cpu;
device_type = "cpu";
reg = <0>;
clock-frequency = <ee6b280>; /* 250 MHz on 82xx */
timebase-frequency = <3b9aca0>; /* 250/4 MHz */
i-cache-line-size = <20>;
d-cache-line-size = <20>;
i-cache-size = <4000>; /* 16MB L1 on 8245 */
d-cache-size = <4000>; /* 16MB L1 on 8245 */
};
};
memory {
linux,phandle = <300>;
device_type = "memory";
reg = <00000000 02000000>; /* 32 MB */
};
chosen {
linux,phandle = <400>;
linux,platform = <1>;
bootargs = "";
linux,stdout-path = "/dev/ttyS0";
/* interrupt-controller = <XXXX>; */
};
};
dtc asm output:
---------------
/* autogenerated by dtc, do not edit */
<snip>
dt_reserve_map:
_dt_reserve_map:
.quad 0, _dt_blob_start
.quad 0, _dt_blob_end - _dt_blob_start
/* Memory reserve map from source file */
.quad 0
.quad 0
<snip>
^ permalink raw reply
* [PATCH][RFC] ppc32: TEMAC driver for ML403
From: Andrei Konovalov @ 2006-03-13 14:17 UTC (permalink / raw)
To: linuxppc-embedded list
Here:
http://source.mvista.com/~ank/paulus-powerpc/20060309/
is an StGIT patchset against
516450179454de9e689e0a53ed8f34b896e8651c
branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc
virtex-ppc_sys_devices-fix.patch - is the same fix posted by Grant Likely few days ago (only formatting is different),
ppc32_xilinx_edk_temac.patch - the low level code from EDK-7.1i used by the this driver
ppc32_xilinx_edk_temac_mods.patch - few modifications to EDK-7.1i code to get rid of compiling the xparameters.h
#defines into the driver. These mods should not be needed after EDK-8.1 SP2 is released.
ppc32_xilinx_temac.patch - the linux driver itself
ppc32_xilinx_ml403_temac.patch - modifications to the ML403 platform code to add TEMAC.
temac.paulus-powerpc.20060309.tgz - all the patches put together into a tarball (just in case).
temac.config - .config used.
This is not the final version yet (no MII support; SGDMA is operational, but seems to need some additional work).
And I would probably wait for EDK-8.1 SP2 (up to one month or so) where both the TEMAC IP and the EDK code
should be updated.
But it would be nice to know if there is anything to rework in the current code to get the driver
accepted into linux/kernel/git/paulus/powerpc.git or linux/kernel/git/torvalds/linux-2.6.git tree.
And probably someone could start playing with the current driver now. At least I was able to mount
the root over NFS and to run several netperf tests.
Thanks,
Andrei
^ permalink raw reply
* Re: suspend2 on PowerBook: keyboard doesn't work on resume
From: Dustin Lang @ 2006-03-13 13:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <1142232047.4228.1.camel@quad.lan>
Hi,
> > I'm trying to get suspend2 working on my PowerBook G4 of Oct 2003 vintage.
> >
> > I'm running kernel 2.6.15.6 with the 2.6.15.1 suspend2 patch (it applied
> > and built fine).
> Interesting. I was pretty sure that version wouldn't work at all :->
Do you mean that version of suspend2, or that combination of kernel and
suspend2 patch? I can try a different combination of versions if you
suspect some other configuration will work...
> There's an ADB keyboard -- this all probably suggests that the ADB
> driver from pre-resume and original kernel are stepping onto each other.
> Maybe they have no good enough power management?
Perhaps. Nigel Cunningham, the main suspend2 developer, suggested that I
post this problem to this list to see if anyone knew what was happening.
Thanks,
dustin.
^ permalink raw reply
* Re: pppd in eldk
From: Eberhard Stoll @ 2006-03-13 8:06 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200603121913.56832.antonio.dibacco@aruba.it>
Hi Antonio,
>I didn't find the ppp package in denx eldk, I tried to cross compile the
>sources (from sourceforge) but I received some errors (pcap_t undeclared).
>Before I continue I would investigate if someone was already successful with
>ppp on ppc.
>
>
We compiled pppd v. 2.4.1 with eldk 3.0 on our ppc target with nfs
mount. It was no problem. But compiling this package on our x86 linux
machine (SuSe 9.0) wasn't a problem either after setting the
environment vars CC, LD, AS to appropriate values (ppc_82xx-...).
Bye
Eberhard
^ permalink raw reply
* Re: suspend2 on PowerBook: keyboard doesn't work on resume
From: Johannes Berg @ 2006-03-13 6:40 UTC (permalink / raw)
To: Dustin Lang; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.58.0603112043460.25986@monte.ai>
Hi,
> I'm trying to get suspend2 working on my PowerBook G4 of Oct 2003 vintage.
>
> I'm running kernel 2.6.15.6 with the 2.6.15.1 suspend2 patch (it applied
> and built fine).
Interesting. I was pretty sure that version wouldn't work at all :->
> On the next startup, the kernel boots and it resumes. I see the root
> terminal again, complete with my "hibernate" command and the syslog
> messages detailing the progress of suspend2. The system does not respond
> to keystrokes, however. After a few seconds, the "Running" message is
> printed out, and after 60 seconds, the system reboots. To me this
> suggests that the system is mostly resuming correctly, but something has
> gone funny with the keyboard driver.
>
> Keyboard-related dmesg:
>
> MacIO PCI driver attached to Intrepid chipset
> input: Macintosh mouse button emulation as /class/input/input0
> adb: starting probe task...
> [snip]
> PCI: Enabling device 0002:20:0d.0 (0000 -> 0002)
> adb devices: [2]: 2 c3 [3]: 3 1 [7]: 7 1f
> ADB keyboard at 2, handler 1
> Detected ADB keyboard, type ANSI.
There's an ADB keyboard -- this all probably suggests that the ADB
driver from pre-resume and original kernel are stepping onto each other.
Maybe they have no good enough power management?
> Does anyone on the list use suspend2 on a PowerBook?
I used to, but on a later powerbook with USB keyboard, so...
johannes
^ permalink raw reply
* [Fwd: [PATCH] correct AC Power info in /proc/pmu/info]
From: Benjamin Herrenschmidt @ 2006-03-12 23:06 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev list
Report AC Power present in /proc/pmu/info if there is no battery.
Signed-off-by: Olaf Hering <olh@suse.de>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
---
drivers/macintosh/via-pmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.16-rc6-olh/drivers/macintosh/via-pmu.c
===================================================================
--- linux-2.6.16-rc6-olh.orig/drivers/macintosh/via-pmu.c
+++ linux-2.6.16-rc6-olh/drivers/macintosh/via-pmu.c
@@ -825,7 +825,7 @@ proc_get_info(char *page, char **start,
p += sprintf(p, "PMU driver version : %d\n", PMU_DRIVER_VERSION);
p += sprintf(p, "PMU firmware version : %02x\n", pmu_version);
p += sprintf(p, "AC Power : %d\n",
- ((pmu_power_flags & PMU_PWR_AC_PRESENT) != 0));
+ ((pmu_power_flags & PMU_PWR_AC_PRESENT) != 0) || pmu_battery_count == 0);
p += sprintf(p, "Battery count : %d\n", pmu_battery_count);
return p - page;
^ permalink raw reply
* pppd in eldk
From: Antonio Di Bacco @ 2006-03-12 18:13 UTC (permalink / raw)
To: linuxppc-embedded
I didn't find the ppp package in denx eldk, I tried to cross compile the
sources (from sourceforge) but I received some errors (pcap_t undeclared).
Before I continue I would investigate if someone was already successful with
ppp on ppc.
Bye,
Antonio.
^ permalink raw reply
* Therm adm103x
From: Cedric Pradalier @ 2006-03-12 11:42 UTC (permalink / raw)
To: linuxppc-dev
Hi,
Some time ago there was some talk about including the
driver for the termostat chip on ibook 2.2 (G3,~800MHz),
module therm_adm103x.
Is it still something that is going on? Is there something
missing?
As I see all the traffic for important matters on the list,
I appreciate that this is not a prioritary question, but
I'm just following up.
Thanks.
--
Cedric
^ permalink raw reply
* [PATCH] correct AC Power info in /proc/pmu/info
From: Olaf Hering @ 2006-03-12 11:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev
Report AC Power present in /proc/pmu/info if there is no battery.
Signed-off-by: Olaf Hering <olh@suse.de>
---
drivers/macintosh/via-pmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.16-rc6-olh/drivers/macintosh/via-pmu.c
===================================================================
--- linux-2.6.16-rc6-olh.orig/drivers/macintosh/via-pmu.c
+++ linux-2.6.16-rc6-olh/drivers/macintosh/via-pmu.c
@@ -825,7 +825,7 @@ proc_get_info(char *page, char **start,
p += sprintf(p, "PMU driver version : %d\n", PMU_DRIVER_VERSION);
p += sprintf(p, "PMU firmware version : %02x\n", pmu_version);
p += sprintf(p, "AC Power : %d\n",
- ((pmu_power_flags & PMU_PWR_AC_PRESENT) != 0));
+ ((pmu_power_flags & PMU_PWR_AC_PRESENT) != 0) || pmu_battery_count == 0);
p += sprintf(p, "Battery count : %d\n", pmu_battery_count);
return p - page;
^ permalink raw reply
* Re: [PATCH] powerpc: enable NAP only on cpus who support it to avoid memory corruption
From: Olaf Hering @ 2006-03-12 10:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1142121302.4057.52.camel@localhost.localdomain>
On Sun, Mar 12, Benjamin Herrenschmidt wrote:
> On Sat, 2006-03-11 at 22:58 +0100, Olaf Hering wrote:
> > commit 51d3082fe6e55aecfa17113dbe98077c749f724c enabled NAP unconditinally
> > on all powermacs. Early G3 cpus can not use it, the result is memory corruption.
>
> Ok, here is what I think is a proper fix: Just remove the code from
> setup.c since feature.c will already set powersave_nap when needed.
>
> Can you test asap please ? If it fixes the problem for you, I'll send
> the patch to Linus/Andrew with hopes that it will make it in 2.6.16
Yes, this helps.
^ permalink raw reply
* suspend2 on PowerBook: keyboard doesn't work on resume
From: Dustin Lang @ 2006-03-12 1:55 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I'm trying to get suspend2 working on my PowerBook G4 of Oct 2003 vintage.
I'm running kernel 2.6.15.6 with the 2.6.15.1 suspend2 patch (it applied
and built fine).
Before suspending, I quit X and logged in as root on the console. I
unloaded all the modules I could - leaving just agpgart and uninorth-agp.
USB is kernelized and the modules are unloaded. I started a loop that
printed "Running" every 10 seconds (and also started a job that after 60
seconds would reboot). I ran the 'hibernate' script. It completed
successfully and powered down the machine.
On the next startup, the kernel boots and it resumes. I see the root
terminal again, complete with my "hibernate" command and the syslog
messages detailing the progress of suspend2. The system does not respond
to keystrokes, however. After a few seconds, the "Running" message is
printed out, and after 60 seconds, the system reboots. To me this
suggests that the system is mostly resuming correctly, but something has
gone funny with the keyboard driver.
Keyboard-related dmesg:
MacIO PCI driver attached to Intrepid chipset
input: Macintosh mouse button emulation as /class/input/input0
adb: starting probe task...
[snip]
PCI: Enabling device 0002:20:0d.0 (0000 -> 0002)
adb devices: [2]: 2 c3 [3]: 3 1 [7]: 7 1f
ADB keyboard at 2, handler 1
Detected ADB keyboard, type ANSI.
input: ADB keyboard as /class/input/input1
input: ADB Powerbook buttons as /class/input/input2
ADB mouse at 3, handler set to 4 (trackpad)
input: ADB mouse as /class/input/input3
adb: finished probe task...
Does anyone on the list use suspend2 on a PowerBook? Any success/failure
stories? Any advice for generating more useful debugging information?
Thanks,
dustin.
^ permalink raw reply
* Re: Unmapping pages from the linear addressing without HIGHMEM support
From: Benjamin Herrenschmidt @ 2006-03-12 0:07 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <20006.1142083702@www079.gmx.net>
On Sat, 2006-03-11 at 14:28 +0100, Gerhard Pircher wrote:
> > --- Ursprüngliche Nachricht ---
> > Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > An: Gerhard Pircher <gerhard_pircher@gmx.net>
> > Kopie: linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
> > Betreff: Re: Unmapping pages from the linear addressing
> > without HIGHMEM support
> > Datum: Sat, 11 Mar 2006 10:13:30 +1100
> >
> > > That would mean I cannot reuse the code in dma-mapping.c, right?
> > > Killing the BAT mappings or limiting the memory size covered by the
> > > BATs seems to be fairly easy, but I guess I have to setup my own page
> > > table for the reserved DMA memory area and implement my own
> > > alloc_pages() function!?
> >
> > No, just limit the size of the BAT mapping and mark some of the top
> > pages of the address space reserved... That should be enough.
> >
> Okay, I will try that first. Marking some of the pages as reserved sounds
> like the code you implemented for the uninorth_agp driver with this
> "agp_special_page". I guess I still have to modify the code in dma_mapping.c
> to use the reserved address space for the consistent memory allocation
> (CONSISTENT_BASE, CONSISTENT_END)?
Probably. I'm not sure about that code, I think those
CONSISTENT_BASE/END are only virtual addresses, the code still alocates
real pages below that from anywhere in memory, you may have to change
that, or maybe just 1:1 map that reserved area non-cacheable, and change
dma-mapping.c to not allocate any physical pages but just pick the one
matching the virtual ones it just allocated...;
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: enable NAP only on cpus who support it to avoid memory corruption
From: Benjamin Herrenschmidt @ 2006-03-11 23:55 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20060311215840.GA22766@suse.de>
On Sat, 2006-03-11 at 22:58 +0100, Olaf Hering wrote:
> commit 51d3082fe6e55aecfa17113dbe98077c749f724c enabled NAP unconditinally
> on all powermacs. Early G3 cpus can not use it, the result is memory corruption.
Ok, here is what I think is a proper fix: Just remove the code from
setup.c since feature.c will already set powersave_nap when needed.
Can you test asap please ? If it fixes the problem for you, I'll send
the patch to Linus/Andrew with hopes that it will make it in 2.6.16
---
This patch fixes incorrect setting of powersave_nap to 1 on all
PowerMac's potentially causing memory corruption on some models. This
bug was introuced by me during the 32/64 bits merge.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/arch/powerpc/platforms/powermac/setup.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/powermac/setup.c 2006-02-13 14:10:43.000000000 +1100
+++ linux-work/arch/powerpc/platforms/powermac/setup.c 2006-03-12 10:47:39.000000000 +1100
@@ -621,10 +621,6 @@
/* Probe motherboard chipset */
pmac_feature_init();
- /* We can NAP */
- powersave_nap = 1;
- printk(KERN_INFO "Using native/NAP idle loop\n");
-
/* Initialize debug stuff */
udbg_scc_init(!!strstr(cmd_line, "sccdbg"));
udbg_adb_init(!!strstr(cmd_line, "btextdbg"));
Index: linux-work/arch/powerpc/platforms/powermac/feature.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/powermac/feature.c 2006-03-01 11:48:27.000000000 +1100
+++ linux-work/arch/powerpc/platforms/powermac/feature.c 2006-03-12 10:51:31.000000000 +1100
@@ -2491,9 +2491,7 @@
pmac_mb.model_id = PMAC_TYPE_COMET;
iounmap(mach_id_ptr);
}
-#endif /* CONFIG_POWER4 */
-#ifdef CONFIG_6xx
/* Set default value of powersave_nap on machines that support it.
* It appears that uninorth rev 3 has a problem with it, we don't
* enable it on those. In theory, the flush-on-lock property is
@@ -2522,10 +2520,11 @@
* NAP mode
*/
powersave_lowspeed = 1;
-#endif /* CONFIG_6xx */
-#ifdef CONFIG_POWER4
+
+#else /* CONFIG_POWER4 */
powersave_nap = 1;
-#endif
+#endif /* CONFIG_POWER4 */
+
/* Check for "mobile" machine */
if (model && (strncmp(model, "PowerBook", 9) == 0
|| strncmp(model, "iBook", 5) == 0))
^ permalink raw reply
* Re: [PATCH] powerpc: enable NAP only on cpus who support it to avoid memory corruption
From: Benjamin Herrenschmidt @ 2006-03-11 23:43 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20060311215840.GA22766@suse.de>
On Sat, 2006-03-11 at 22:58 +0100, Olaf Hering wrote:
> commit 51d3082fe6e55aecfa17113dbe98077c749f724c enabled NAP unconditinally
> on all powermacs. Early G3 cpus can not use it, the result is memory corruption.
>
> Only enable powersave_nap in one place: probe_motherboard()
> ppc32 gets nap if the cpu supports it
> ppc32 smp gets no nap
> ppc64 gets nap unconditionally
CONFIG_SMP is certainly not the way to do it though... I wonder how we
got that wrong, I'll have a look.
Ben.
> ---
> arch/powerpc/platforms/powermac/feature.c | 8 +++++++-
> arch/powerpc/platforms/powermac/setup.c | 4 ----
> arch/powerpc/platforms/powermac/smp.c | 4 ----
> 3 files changed, 7 insertions(+), 9 deletions(-)
>
> Index: linux-2.6.16-rc5-olh/arch/powerpc/platforms/powermac/feature.c
> ===================================================================
> --- linux-2.6.16-rc5-olh.orig/arch/powerpc/platforms/powermac/feature.c
> +++ linux-2.6.16-rc5-olh/arch/powerpc/platforms/powermac/feature.c
> @@ -2513,8 +2513,11 @@ found:
> /* Nap mode not supported if flush-on-lock property is present */
> if (get_property(np, "flush-on-lock", NULL))
> break;
> +
> +#ifndef CONFIG_SMP
> + /* 32 bits SMP can't NAP */
> powersave_nap = 1;
> - printk(KERN_INFO "Processor NAP mode on idle enabled.\n");
> +#endif
> break;
> }
>
> @@ -2526,6 +2529,9 @@ found:
> #ifdef CONFIG_POWER4
> powersave_nap = 1;
> #endif
> + if (powersave_nap)
> + printk(KERN_INFO "Using native/NAP idle loop\n");
> +
> /* Check for "mobile" machine */
> if (model && (strncmp(model, "PowerBook", 9) == 0
> || strncmp(model, "iBook", 5) == 0))
> Index: linux-2.6.16-rc5-olh/arch/powerpc/platforms/powermac/setup.c
> ===================================================================
> --- linux-2.6.16-rc5-olh.orig/arch/powerpc/platforms/powermac/setup.c
> +++ linux-2.6.16-rc5-olh/arch/powerpc/platforms/powermac/setup.c
> @@ -621,10 +621,6 @@ static void __init pmac_init_early(void)
> /* Probe motherboard chipset */
> pmac_feature_init();
>
> - /* We can NAP */
> - powersave_nap = 1;
> - printk(KERN_INFO "Using native/NAP idle loop\n");
> -
> /* Initialize debug stuff */
> udbg_scc_init(!!strstr(cmd_line, "sccdbg"));
> udbg_adb_init(!!strstr(cmd_line, "btextdbg"));
> Index: linux-2.6.16-rc5-olh/arch/powerpc/platforms/powermac/smp.c
> ===================================================================
> --- linux-2.6.16-rc5-olh.orig/arch/powerpc/platforms/powermac/smp.c
> +++ linux-2.6.16-rc5-olh/arch/powerpc/platforms/powermac/smp.c
> @@ -739,10 +739,6 @@ static void __init smp_core99_setup(int
> smp_hw_index[i] = i;
> }
> #endif
> -
> - /* 32 bits SMP can't NAP */
> - if (!machine_is_compatible("MacRISC4"))
> - powersave_nap = 0;
> }
>
> static int __init smp_core99_probe(void)
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: Linux v2.6.16-rc5
From: Olaf Hering @ 2006-03-11 21:59 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Linus Torvalds, Linux Kernel Mailing List
In-Reply-To: <20060306230235.GA6113@suse.de>
On Tue, Mar 07, Olaf Hering wrote:
> On Mon, Mar 06, Olaf Hering wrote:
>
> > On Mon, Mar 06, Olaf Hering wrote:
> >
> > > On Mon, Mar 06, Paul Mackeras wrote:
> > >
> > > > There are also commits from Ben H that change the way we parse
> > > > addresses from the OF device tree. If you can bisect a bit further
> > > > that would be good, although you may strike problems between the 401d
> > > > and 6237 commits I mentioned above.
> > >
> > > What I have right now is this, which got me in a non-compiling state.
> > > I will pick the udbg stuff and apply the relevant changes to -git5.
>
> I tried with CONFIG_BOOTX_TEXT disabled. same result. This is the list
> of patches I used on top of 2.6.15:
>
> patches.kernel.org/patch-2.6.15-git5
> patches.suse/get_cramfs_inode-revert.patch
> patches.suse/suse-ppc-legacy-io.patch
> patches.arch/0022-powerpc-incorrect-rmo_top-handling-in-prom_init.txt
> patches.suse/9100b205fdc70b300894954ebebbf2709c5ed525.patch
> patches.suse/3d1229d6ae92ed1994f4411b8493327ef8f4b76f.patch
> patches.suse/d1405b869850982f05c7ec0d3f137ca27588192f.patch
> patches.suse/463ce0e103f419f51b1769111e73fe8bb305d0ec.patch
>
> patches.suse/51d3082fe6e55aecfa17113dbe98077c749f724c.patch
> patches.suse/31df1678d7732b94178a6e457ed6666e4431212f.patch
> patches.suse/8dacaedf04467e32c50148751a96150e73323cdc.patch
> patches.suse/52020d2bda9fe447bb50674a2e39e4064b6a10b5.patch
51d3082fe6e55aecfa17113dbe98077c749f724c enabled powersave_nap
unconditionally. But early G3 cpus can not handle it.
I sent a patch in another thread.
^ permalink raw reply
* [PATCH] powerpc: enable NAP only on cpus who support it to avoid memory corruption
From: Olaf Hering @ 2006-03-11 21:58 UTC (permalink / raw)
To: Paul Mackeras, Benjamin Herrenschmidt, linuxppc-dev, linux-kernel
commit 51d3082fe6e55aecfa17113dbe98077c749f724c enabled NAP unconditinally
on all powermacs. Early G3 cpus can not use it, the result is memory corruption.
Only enable powersave_nap in one place: probe_motherboard()
ppc32 gets nap if the cpu supports it
ppc32 smp gets no nap
ppc64 gets nap unconditionally
---
arch/powerpc/platforms/powermac/feature.c | 8 +++++++-
arch/powerpc/platforms/powermac/setup.c | 4 ----
arch/powerpc/platforms/powermac/smp.c | 4 ----
3 files changed, 7 insertions(+), 9 deletions(-)
Index: linux-2.6.16-rc5-olh/arch/powerpc/platforms/powermac/feature.c
===================================================================
--- linux-2.6.16-rc5-olh.orig/arch/powerpc/platforms/powermac/feature.c
+++ linux-2.6.16-rc5-olh/arch/powerpc/platforms/powermac/feature.c
@@ -2513,8 +2513,11 @@ found:
/* Nap mode not supported if flush-on-lock property is present */
if (get_property(np, "flush-on-lock", NULL))
break;
+
+#ifndef CONFIG_SMP
+ /* 32 bits SMP can't NAP */
powersave_nap = 1;
- printk(KERN_INFO "Processor NAP mode on idle enabled.\n");
+#endif
break;
}
@@ -2526,6 +2529,9 @@ found:
#ifdef CONFIG_POWER4
powersave_nap = 1;
#endif
+ if (powersave_nap)
+ printk(KERN_INFO "Using native/NAP idle loop\n");
+
/* Check for "mobile" machine */
if (model && (strncmp(model, "PowerBook", 9) == 0
|| strncmp(model, "iBook", 5) == 0))
Index: linux-2.6.16-rc5-olh/arch/powerpc/platforms/powermac/setup.c
===================================================================
--- linux-2.6.16-rc5-olh.orig/arch/powerpc/platforms/powermac/setup.c
+++ linux-2.6.16-rc5-olh/arch/powerpc/platforms/powermac/setup.c
@@ -621,10 +621,6 @@ static void __init pmac_init_early(void)
/* Probe motherboard chipset */
pmac_feature_init();
- /* We can NAP */
- powersave_nap = 1;
- printk(KERN_INFO "Using native/NAP idle loop\n");
-
/* Initialize debug stuff */
udbg_scc_init(!!strstr(cmd_line, "sccdbg"));
udbg_adb_init(!!strstr(cmd_line, "btextdbg"));
Index: linux-2.6.16-rc5-olh/arch/powerpc/platforms/powermac/smp.c
===================================================================
--- linux-2.6.16-rc5-olh.orig/arch/powerpc/platforms/powermac/smp.c
+++ linux-2.6.16-rc5-olh/arch/powerpc/platforms/powermac/smp.c
@@ -739,10 +739,6 @@ static void __init smp_core99_setup(int
smp_hw_index[i] = i;
}
#endif
-
- /* 32 bits SMP can't NAP */
- if (!machine_is_compatible("MacRISC4"))
- powersave_nap = 0;
}
static int __init smp_core99_probe(void)
^ permalink raw reply
* Re: SCCx UART status on 8xx
From: Marcelo Tosatti @ 2006-03-11 22:17 UTC (permalink / raw)
To: Aristeu Sergio Rozanski Filho
Cc: fbl, Björn Östby, linuxppc-embedded
In-Reply-To: <20060220141830.GA7228@oops.ghostprotocols.net>
Aris,
Can you please prepare a detailed description of what the
patch is doing and why?
Thanks
On Mon, Feb 20, 2006 at 11:18:35AM -0300, Aristeu Sergio Rozanski Filho wrote:
> Index: stable/drivers/serial/cpm_uart/cpm_uart_cpm1.c
> ===================================================================
> --- stable.orig/drivers/serial/cpm_uart/cpm_uart_cpm1.c 2006-02-17 17:11:37.000000000 -0200
> +++ stable/drivers/serial/cpm_uart/cpm_uart_cpm1.c 2006-02-17 17:15:57.000000000 -0200
> @@ -139,24 +139,31 @@
> void scc1_lineif(struct uart_cpm_port *pinfo)
> {
> /* XXX SCC1: insert port configuration here */
> + cpmp->cp_sicr &= 0xFFFFFFC0;
> pinfo->brg = 1;
> }
>
> void scc2_lineif(struct uart_cpm_port *pinfo)
> {
> /* XXX SCC2: insert port configuration here */
> + cpmp->cp_sicr &= 0xFFFFC0FF;
> + cpmp->cp_sicr |= 0x00000900;
> pinfo->brg = 2;
> }
>
> void scc3_lineif(struct uart_cpm_port *pinfo)
> {
> /* XXX SCC3: insert port configuration here */
> + cpmp->cp_sicr &= 0xFFC0FFFF;
> + cpmp->cp_sicr |= 0x00140000;
> pinfo->brg = 3;
> }
>
> void scc4_lineif(struct uart_cpm_port *pinfo)
> {
> /* XXX SCC4: insert port configuration here */
> + cpmp->cp_sicr &= 0xC0FFFFFF;
> + cpmp->cp_sicr |= 0x1BFFFFFF;
> pinfo->brg = 4;
> }
>
> Index: stable/drivers/serial/cpm_uart/cpm_uart_core.c
> ===================================================================
> --- stable.orig/drivers/serial/cpm_uart/cpm_uart_core.c 2005-12-07 15:30:42.000000000 -0200
> +++ stable/drivers/serial/cpm_uart/cpm_uart_core.c 2005-12-08 12:39:11.000000000 -0200
> @@ -467,6 +467,7 @@
> /* free interrupt handler */
> free_irq(port->irq, port);
>
> +#if 0
> /* If the port is not the console, disable Rx and Tx. */
> if (!(pinfo->flags & FLAG_CONSOLE)) {
> /* Wait for all the BDs marked sent */
> @@ -492,6 +493,7 @@
> /* Shut them really down */
> cpm_line_cr_cmd(line, CPM_CR_STOP_TX);
> }
> +#endif
> }
>
> static void cpm_uart_set_termios(struct uart_port *port,
> @@ -896,7 +898,7 @@
> pinfo->sccp->scc_gsmrl &= ~(SCC_GSMRL_ENR | SCC_GSMRL_ENT);
> }
>
> - ret = cpm_uart_allocbuf(pinfo, 0);
> + ret = cpm_uart_allocbuf(pinfo, 1);
>
> if (ret)
> return ret;
> @@ -912,10 +914,12 @@
>
> static void cpm_uart_release_port(struct uart_port *port)
> {
> +#if 0
> struct uart_cpm_port *pinfo = (struct uart_cpm_port *)port;
>
> if (!(pinfo->flags & FLAG_CONSOLE))
> cpm_uart_freebuf(pinfo);
> +#endif
> }
>
> /*
^ permalink raw reply
* Re: Unmapping pages from the linear addressing without HIGHMEM support
From: Gerhard Pircher @ 2006-03-11 13:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <1142032411.4057.31.camel@localhost.localdomain>
> --- Ursprüngliche Nachricht ---
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> Kopie: linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
> Betreff: Re: Unmapping pages from the linear addressing
> without HIGHMEM support
> Datum: Sat, 11 Mar 2006 10:13:30 +1100
>
> > That would mean I cannot reuse the code in dma-mapping.c, right?
> > Killing the BAT mappings or limiting the memory size covered by the
> > BATs seems to be fairly easy, but I guess I have to setup my own page
> > table for the reserved DMA memory area and implement my own
> > alloc_pages() function!?
>
> No, just limit the size of the BAT mapping and mark some of the top
> pages of the address space reserved... That should be enough.
>
Okay, I will try that first. Marking some of the pages as reserved sounds
like the code you implemented for the uninorth_agp driver with this
"agp_special_page". I guess I still have to modify the code in dma_mapping.c
to use the reserved address space for the consistent memory allocation
(CONSISTENT_BASE, CONSISTENT_END)?
Thanks again!
Gerhard
--
"Feel free" mit GMX FreeMail!
Monat für Monat 10 FreeSMS inklusive! http://www.gmx.net
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox