* DTC Updates
From: Jon Loeliger @ 2007-10-16 13:32 UTC (permalink / raw)
To: linuxppc-dev
Guys and Dolls,
I pushed out all of David's recent DTC and libfdt patches.
I also jammed the following patch into the mix as well.
HTH,
jdl
commit 9e32930ebcacfcf7cb7c1c2b8e776eb3957cf6cb
Author: Jon Loeliger <jdl@freescale.com>
Date: Tue Oct 16 07:35:38 2007 -0500
Restore warning message about bison expected output.
It was dropped in ad9593f229362782b953da4b805df713e8468df0.
Signed-off-by: Jon Loeliger <jdl@jdl.com>
diff --git a/Makefile b/Makefile
index 84f0efe..d7d1af5 100644
--- a/Makefile
+++ b/Makefile
@@ -207,6 +207,7 @@ clean: libfdt_clean tests_clean
%.tab.c %.tab.h %.output: %.y
@$(VECHO) BISON $@
+ @$(VECHO) ---- Expect 2 s/r and 2 r/r. ----
$(BISON) -d $<
FORCE:
^ permalink raw reply related
* Re: Merge dtc
From: Kumar Gala @ 2007-10-16 13:41 UTC (permalink / raw)
To: Grant Likely; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <fa686aa40710160617o57564cb4r260a40cd66407852@mail.gmail.com>
On Oct 16, 2007, at 8:17 AM, Grant Likely wrote:
> On 10/15/07, David Gibson <david@gibson.dropbear.id.au> wrote:
>> This very large patch incorporates a copy of dtc into the kernel
>> source, in arch/powerpc/boot/dtc-src. This means that dtc is no
>> longer an external dependency to build kernels with configurations
>> which need a dtb file.
>
> Powerpc is probably not going to be the only user of dtc. Microblaze
> will be using it too. Can it be put somewhere more common?
mkimage should also be put somewhere common since other archs use it.
- k
^ permalink raw reply
* Re: Antwort: Re: ATA flash disk ok, missing ip config
From: Mohamed Hamed @ 2007-10-16 12:44 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <0FOJ00CF99QJAJ@pmdf-it.hasler.ascom.ch>
Dear Sir,
i'm trying to install qemu in a debian linux system , ubuntu , and when
i finished from installation and trying to run the qemu more error be
found as follow :
(qemu) Uncompressing
Linux.......................................................................... done, booting the kernel.
Linux version 2.6.17-rc3 (paul@wren) (gcc version 4.1.0 (CodeSourcery
ARM)) #53 Thu May 4 15:05:18 BST 2006
CPU: ARM926EJ-Sid(wb) [41069265] revision 5 (ARMv5TEJ)
Machine: ARM-IntegratorCP
Memory policy: ECC disabled, Data cache writeback
CPU0: D VIVT write-through cache
CPU0: I cache: 4096 bytes, associativity 4, 32 byte lines, 32 sets
CPU0: D cache: 65536 bytes, associativity 4, 32 byte lines, 512 sets
Built 1 zonelists
Kernel command line: console=ttyAMA0 root= /dev/nfs
nfsroot=10.1.6.1:/nfs/share/arm,rsize=8192,wsize=8192,hard,intr,tcp,nolock ip=10.1.6.50::10.1.6.1:255.255.255.0:arm.home:eth0
PID hash table entries: 2048 (order: 11, 8192 bytes)
Console: colour dummy device 80x30
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 256MB = 256MB total
Memory: 257280KB available (1928K code, 388K data, 104K init)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
NetWinder Floating Point Emulator V0.97 (double precision)
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
CLCD: Integrator/CP hardware, VGA display
Clock CLCDCLK: setting VCO reg params: S=1 R=39 V=35
Console: switching to colour frame buffer device 80x30
Serial: AMBA PL011 UART driver
mb:16: ttyAMA0 at MMIO 0x16000000 (irq = 1) is a AMBA/PL011
mb:17: ttyAMA1 at MMIO 0x17000000 (irq = 2) is a AMBA/PL011
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
loop: loaded (max 8 devices)
nbd: registered device at major 43
smc91x.c: v1.1, sep 22 2004 by Nicolas Pitre <nico@cam.org>
eth0: SMC91C11xFD (rev 1) at d0816000 IRQ 27 [nowait]
eth0: Ethernet addr: 52:54:00:12:34:56
mice: PS/2 mouse device common for all mice
Green LED off
input: AT Raw Set 2 keyboard as /class/input/input0
input: ImExPS/2 Generic Explorer Mouse as /class/input/input1
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 8192 bind 4096)
TCP reno registered
IPv4 over IPv4 tunneling driver
GRE over IPv4 tunneling driver
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <davem@redhat.com>
VFP support v0.3: implementor 41 architecture 1 part 10 variant 9 rev 0
eth0: link up
IP-Config: Complete:
device=eth0, addr=10.1.6.50, mask=255.255.255.0, gw=10.1.6.1,
host=arm, domain=, nis-domain=home,
bootserver=255.255.255.255, rootserver=10.1.6.1, rootpath=
Looking up port of RPC 100003/2 on 10.1.6.1
Root-NFS: Unable to get nfsd port number from server, using default
Looking up port of RPC 100005/1 on 10.1.6.1
Root-NFS: Unable to get mountd port number from server, using default
Root-NFS: Server returned error -5 while mounting /nfs/share/arm
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "<NULL>" or unknown-block(2,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(2,0)
and i don't know what is the reason and i don't know what the line root
=boot option
this is the script which i run
#!/bin/sh
console="ttyAMA0" # serial console
nfsserver="10.1.6.1" # address of NFS server
nfsdir="/nfs/share/arm" # exported share where debian/arm is installed
address="10.1.6.50" # address for guest server
gateway="10.1.6.1" # default gateway
netmask="255.255.255.0" # subnet mask
hostname="arm.home" # hostname for guest server
device="eth0" # interface that guest server will use
mem=256 # memory for guest server in Mb
tap="/var/run/vde/tap0.ctl" # vde tap socket
kernel="/usr/local/etc/images/zimage.arm" # arm kernel
nfsopts="rsize=8192,wsize=8192,hard,intr,tcp,nolock" # nfs options
consoleopt="console=$console"
nfsrootopt="nfsroot=$nfsserver:$nfsdir,$nfsopts"
ipopt="ip=$address::$gateway:$netmask:$hostname:$device"
init=""
if [ "x$1" == "xsingle" ]
then
init="init=/bin/bash"
fi
vdeq qemu-system-arm -sock $tap -m $mem \
-kernel $kernel -nographic \
-append "$consoleopt root= /dev/nfs $nfsrootopt $ipopt $init"
and i don't know this line root = /dev/nfs , where this directory is
empty
thanks for helping me
i hope to reply me at this mail mhamed@future-group.com
or at eng_m_elsaidy@yahoo.com
Hamed
^ permalink raw reply
* Please pull from 'fixes-2.6.24'
From: Kumar Gala @ 2007-10-16 14:10 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
(Note, this tree is based on a recent linus tree)
Please pull from 'fixes-2.6.24' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git fixes-2.6.24
to receive the following updates:
arch/powerpc/math-emu/math.c | 13 +++++++++----
arch/powerpc/sysdev/fsl_pci.c | 2 +-
2 files changed, 10 insertions(+), 5 deletions(-)
Kumar Gala (1):
[POWERPC] Fix handling of stfiwx math emulation
Tony Li (1):
[POWERPC] Add missing semicolon for fsl_pci.c
commit 01db9953a70e8ad33fbcf91d629f8a8ee59b3484
Author: Tony Li <tony.li@freescale.com>
Date: Tue Oct 16 15:15:23 2007 +0800
[POWERPC] Add missing semicolon for fsl_pci.c
Signed-off-by: Tony Li <tony.li@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit ba02946a903015840ef672ccc9dc8620a7e83de6
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Thu Oct 11 17:07:34 2007 -0500
[POWERPC] Fix handling of stfiwx math emulation
Its legal for the stfiwx instruction to have RA = 0 as part of its
effective address calculation. This is illegal for all other XE
form instructions.
Add code to compute the proper effective address for stfiwx if
RA = 0 rather than treating it as illegal.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
diff --git a/arch/powerpc/math-emu/math.c b/arch/powerpc/math-emu/math.c
index 69058b2..381306b 100644
--- a/arch/powerpc/math-emu/math.c
+++ b/arch/powerpc/math-emu/math.c
@@ -407,11 +407,16 @@ do_mathemu(struct pt_regs *regs)
case XE:
idx = (insn >> 16) & 0x1f;
- if (!idx)
- goto illegal;
-
op0 = (void *)¤t->thread.fpr[(insn >> 21) & 0x1f];
- op1 = (void *)(regs->gpr[idx] + regs->gpr[(insn >> 11) & 0x1f]);
+ if (!idx) {
+ if (((insn >> 1) & 0x3ff) == STFIWX)
+ op1 = (void *)(regs->gpr[(insn >> 11) & 0x1f]);
+ else
+ goto illegal;
+ } else {
+ op1 = (void *)(regs->gpr[idx] + regs->gpr[(insn >> 11) & 0x1f]);
+ }
+
break;
case XEU:
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index af090c9..33df4c3 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -255,7 +255,7 @@ DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8533E, quirk_fsl_pcie_transpare
DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8533, quirk_fsl_pcie_transparent);
DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8544E, quirk_fsl_pcie_transparent);
DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8544, quirk_fsl_pcie_transparent);
-DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8572E, quirk_fsl_pcie_transparent)
+DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8572E, quirk_fsl_pcie_transparent);
DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8572, quirk_fsl_pcie_transparent);
DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8641, quirk_fsl_pcie_transparent);
DECLARE_PCI_FIXUP_EARLY(0x1957, PCI_DEVICE_ID_MPC8641D, quirk_fsl_pcie_transparent);
^ permalink raw reply related
* Serial init / BRG
From: Alan Bennett @ 2007-10-16 14:19 UTC (permalink / raw)
To: Scott Wood, linuxppc-dev
For some reason I'm unable to track down the right sequence to
initialize my serial ports. (note: my console is working, but
attempts to initialize SCC1 and SCC4 fail). My console has the luxury
of having uboot initialize it and its brg, but SCC1 / SCC4 aren't so
lucky.
A few questions: To use 3 brgs, should I have 1 brg entry and X reg
values or three brg entries in my device tree? what are the third and
fourth reg values of the brg item in the device tree. I'll need 3
separate baud rates on the serial lines. Should I just add code to
initialize the brg's in u-boot or figure out how to get the kernel to
do it?
boot sequence
===========
CPM UART serial mem=e0011a80 pram=e0000000
ttyCPM0 at MMIO 0xe0011a80 (irq = 16) is a CPM UART
CPM UART serial mem=e0011a00 pram=e0008000
CPM uart[1]:init_scc - sup = e0008000
ttyCPM1 at MMIO 0xe0011a00 (irq = 40) is a CPM UART
CPM UART serial mem=e0011a60 pram=e0008300
CPM uart[2]:init_scc - sup = e0008300
ttyCPM2 at MMIO 0xe0011a60 (irq = 43) is a CPM UART
BRG Values after above
=================
brgc1: 0x00000000
brgc2: 0x00000000
brgc3: 0x00000000
brgc4: 0x00000000
brgc5: 0x00000000
brgc6: 0x00000000
brgc7: 0x0001004e
brgc8: 0x00000000
Device Tree:
brg@119f0 {
compatible = "fsl,mpc8272-brg",
"fsl,cpm2-brg",
"fsl,cpm-brg";
reg = <119f0 10 115f0 10>;
};
/* Monitor port/SMC1 */
serial@11a80 {
device_type = "serial";
compatible = "fsl,mpc8248-smc-uart",
"fsl,cpm2-smc-uart";
reg = <11a80 20 0 40>;
interrupts = <4 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <7>;
fsl,cpm-command = <1d000000>;
};
/* "Serial" port/SCC1 */
serial@11a00 {
device_type = "serial";
compatible = "fsl,mpc8248-scc-uart",
"fsl,cpm2-scc-uart";
reg = <11a00 20 8000 100>;
interrupts = <28 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <1>;
fsl,cpm-command = <00800000>;
};
/* "Serial" port/SCC4 */
serial@11a60 {
device_type = "serial";
compatible = "fsl,mpc8248-scc-uart",
"fsl,cpm2-scc-uart";
reg = <11a60 20 8300 100>;
interrupts = <2B 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <4>;
fsl,cpm-command = <0CE00000>;
};
^ permalink raw reply
* Re: [PATCH 4/5] ibmebus: Move to of_device and of_platform_driver, match eHCA and eHEA drivers
From: Joachim Fenkes @ 2007-10-16 21:20 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Q Klein, Jan-Bernd Themann, netdev, Paul Mackerras, LKML,
LinuxPPC-Dev, Christoph Raisch, Marcus Eder, Paul Mackerras,
Stefan Roscher
In-Reply-To: <OF48E0997F.B61F7220-ONC125736F.002D7F06-C125736F.002DD39C@de.ibm.com>
On Tuesday 09 October 2007 10:21, Jan-Bernd Themann wrote:
> Roland Dreier <rdreier@cisco.com> wrote on 03.10.2007 20:05:44:
> > > > Replace struct ibmebus_dev and struct ibmebus_driver with struct=20
of_device
> > > > and struct of_platform_driver, respectively. Match the external=20
ibmebus
> > > > interface and drivers using it.
> > > >
> > > > Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
> > >
> > > This is somewhat difficult as this patch touches files that are the
> > > responsibility of three different maintainers. =A0Is it possible to
> > > split the patch into three, one for each maintainer (possibly by
> > > keeping both old and new interfaces around for a little while)?
> > >=20
> > > If not, then you need to get an Acked-by and an agreement that this
> > > change can go via the powerpc.git tree from Roland Dreier and Jeff
> > > Garzik.
> >
> > I don't see anything objectionable in the infiniband parts of the
> > patch -- I don't have any way to test the changes but it all looks
> > like a straightforward conversion to a new platform API. So:
> >
> > Acked-by: Roland Dreier <rolandd@cisco.com>
> >
> > - R.
>
> Looks good from eHEA driver perspective.
>
> Acked-by: Jan-Bernd Themann <themann@de.ibm.com>
Jeff, do you have any objections against this patch going into the kernel
via Paul's powerpc.git tree? It touches only a few lines of ehea which are
specific to the bus interface changes.
You can see the full patch here:
http://patchwork.ozlabs.org/linuxppc/patch?id=3D13750
If you have no objections, please ack the patch so Paul can include it.
Thanks and regards,
Joachim
^ permalink raw reply
* Re: [PATCH v2 4/7] bestcomm: core bestcomm support for Freescale MPC5200
From: tnt @ 2007-10-16 13:21 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, paulus, domen.puncer
In-Reply-To: <fa686aa40710150704j15f3a511rf5924573282c966b@mail.gmail.com>
> On 10/15/07, Matt Sealey <matt@genesi-usa.com> wrote:
>>
>> My nits:
>>
>> Grant Likely wrote:
>> > From: Sylvain Munaut <tnt@246tNt.com>
>> > +static int __devinit
>> > +bcom_engine_init(void)
>>
>> Why "bcom" and not "bestcomm"?
>
> I can type 'bcom' twice as fast. :-) bcom is a suitable shortening;
> I'm not concerned about it.
I prefer bcom as well. Much shorter and there is no ambiguity.
If you use theses, you are writing a 5200 driver. In that context you
should be able to figure out what 'bcom' stands for ... (and if not, maybe
you shouldn't be using them ;)
>> > + /* Disable COMM Bus Prefetch, apparently it's not reliable yet
>> */
>> > + /* FIXME: This should be done on 5200 and not 5200B ... */
>> > + out_be16(&bcom_eng->regs->PtdCntrl,
>> in_be16(&bcom_eng->regs->PtdCntrl) | 1);
>>
>> This really, really shouldn't even be here, could it be moved to a
>> platform
>> init, or switched on a PVR/SVR here?
>
> I think I'd like to leave it here for getting this series merged; it
> may not be good to have it here; but it's not dangerous either. I'm
> trying to keep churn on this series down to a minimum.
>
> Please submit a patch to make this change once it's merged.
Mmmm.
I think it _does_ belong here. COMM bus prefetch _is_ a bestcomm engine
option.
But indeed as the comment says, it maybe should be enabled on 5200B.
Not a big concern for me at the moment tough.
Sylvain
^ permalink raw reply
* cross compilation issue
From: Venkatesh Ananthakrishnan, TLS-Chennai @ 2007-10-16 14:24 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]
Hai
I am newbi to linux.
I wrote the application usb libusb which works fine with x86 pc.
I want to compile the application for ppc. I have cross compiled libusb.
I have tool chain also.
If I give ppc_6xx-gcc filename.c
It gives the error message as usb.h No such a file or directory.
How to give include path and library path during compilation?
Please do the needful
Regards,
Venkatesh
DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the sender immediately. Before opening any mail and
attachments please check them for viruses and defect.
-----------------------------------------------------------------------------------------------------------------------
[-- Attachment #2: Type: text/html, Size: 4005 bytes --]
^ permalink raw reply
* ioctl32: Unknown cmd
From: Geert Uytterhoeven @ 2007-10-16 14:45 UTC (permalink / raw)
To: Arnd Bergmann, Jens Axboe; +Cc: Linux/PPC Development, Linux Kernel Development
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1182 bytes --]
Hi Arnd, Jens,
The recent (post 2.6.23) changes to compat_ioctl made the reporting of
unsupported ioctls more verbose. E.g. on the PS3 I get:
| ioctl32(cdrom_id:608): Unknown cmd fd(3) cmd(00005331){t:'S';sz:0} arg(00000000) on /dev/.tmp-11-0
| ioctl32(hdparm:1427): Unknown cmd fd(3) cmd(0000031f){t:03;sz:0} arg(00000000) on /dev/ps3da
| ioctl32(hdparm:1427): Unknown cmd fd(3) cmd(0000031f){t:03;sz:0} arg(00000000) on /dev/ps3da
The first one is triggered by the detection of the CD/DVD/BD-ROM driver,
The others are triggered by me running hdparm.
Was this intentional?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: cross compilation issue
From: ravi.rao @ 2007-10-16 14:51 UTC (permalink / raw)
To: avenkatesh
Cc: linuxppc-embedded-bounces+ravi.rao=rflelect.com,
linuxppc-embedded
In-Reply-To: <66E8AEE9980BB44CA5FCAD39EBA56AC6029A29DD@CHN-HCLT-EVS02.HCLT.CORP.HCL.IN>
[-- Attachment #1: Type: text/plain, Size: 2603 bytes --]
Hi,
Easiest way is to edit the x86 Makefile so that gcc and ld points to Ur
tool chain's ppc_6xx-gcc & ppc_6xx-ld..
Thanks,
Ravishankar Govindarao
RFL Electronics Inc.
E-mail : Ravi.Rao@rflelect.com
Voice: 973.334.3100 Ext. 233
Fax: 973.334.3863
CONFIDENTIALITY NOTE
This e-mail, including any attachments, may contain confidential and/or
legally privileged information. The Information is intended only for the
use of the individual or entity named on this e-mail . If you are not the
intended recipient, you are hereby notified that any disclosure, copying,
distribution, or the taking of any action in reliance on the contents of
this transmitted Information is strictly prohibited. Further, if you are
not the intended recipient, please notify us by return e-mail and delete
the Information promptly.
"Venkatesh Ananthakrishnan, TLS-Chennai" <avenkatesh@hcl.in>
Sent by: linuxppc-embedded-bounces+ravi.rao=rflelect.com@ozlabs.org
10/16/2007 10:24 AM
To
<linuxppc-embedded@ozlabs.org>
cc
Subject
cross compilation issue
Hai
I am newbi to linux.
I wrote the application usb libusb which works fine with x86 pc.
I want to compile the application for ppc. I have cross compiled libusb. I
have tool chain also.
If I give ppc_6xx-gcc filename.c
It gives the error message as usb.h No such a file or directory.
How to give include path and library path during compilation?
Please do the needful
Regards,
Venkatesh
DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and
intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its
affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect
the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure,
modification, distribution and / or publication of
this message without the prior written consent of the author of this
e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the sender
immediately. Before opening any mail and
attachments please check them for viruses and defect.
-----------------------------------------------------------------------------------------------------------------------
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: Type: text/html, Size: 4726 bytes --]
^ permalink raw reply
* Re: [PATCH 4/5] ibmebus: Move to of_device and of_platform_driver, match eHCA and eHEA drivers
From: Jeff Garzik @ 2007-10-16 15:00 UTC (permalink / raw)
To: Joachim Fenkes
Cc: Thomas Q Klein, Jan-Bernd Themann, netdev, Paul Mackerras, LKML,
LinuxPPC-Dev, Christoph Raisch, Marcus Eder, Paul Mackerras,
Stefan Roscher
In-Reply-To: <200710162320.00630.fenkes@de.ibm.com>
Joachim Fenkes wrote:
> On Tuesday 09 October 2007 10:21, Jan-Bernd Themann wrote:
>> Roland Dreier <rdreier@cisco.com> wrote on 03.10.2007 20:05:44:
>>> > > Replace struct ibmebus_dev and struct ibmebus_driver with struct
> of_device
>>> > > and struct of_platform_driver, respectively. Match the external
> ibmebus
>>> > > interface and drivers using it.
>>> > >
>>> > > Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
>>> >
>>> > This is somewhat difficult as this patch touches files that are the
>>> > responsibility of three different maintainers. �Is it possible to
>>> > split the patch into three, one for each maintainer (possibly by
>>> > keeping both old and new interfaces around for a little while)?
>>> >
>>> > If not, then you need to get an Acked-by and an agreement that this
>>> > change can go via the powerpc.git tree from Roland Dreier and Jeff
>>> > Garzik.
>>>
>>> I don't see anything objectionable in the infiniband parts of the
>>> patch -- I don't have any way to test the changes but it all looks
>>> like a straightforward conversion to a new platform API. So:
>>>
>>> Acked-by: Roland Dreier <rolandd@cisco.com>
>>>
>>> - R.
>> Looks good from eHEA driver perspective.
>>
>> Acked-by: Jan-Bernd Themann <themann@de.ibm.com>
>
> Jeff, do you have any objections against this patch going into the kernel
> via Paul's powerpc.git tree? It touches only a few lines of ehea which are
> specific to the bus interface changes.
>
> You can see the full patch here:
> http://patchwork.ozlabs.org/linuxppc/patch?id=13750
>
> If you have no objections, please ack the patch so Paul can include it.
Fine with me...
Jeff
^ permalink raw reply
* [PATCH 0/5] IB/ehca: SRQ and MR/MW fixes
From: Joachim Fenkes @ 2007-10-16 15:22 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, Roland Dreier, OF-EWG
Cc: Stefan Roscher, Christoph Raisch
Here are some more fixes for the eHCA driver, fixing some problems we found
during internal system test.
[1/5] fixes the QP pointer determination for SRQ base QPs
[2/5] fixes a masking error in {,re}reg_phys_mr()
[3/5] fixes a bug in alloc_fmr() and simplifies some code
[4/5] refactors hca_cap_mr_pgsize and fixes a problem with ib_srp
[5/5] enables large page MRs by default
I built the patches on top of Roland's for-2.6.24 git branch. Please review
and queue them for 2.6.24-rc1 if you're okay with them. Thanks!
Cheers,
Joachim
=2D-=20
Joachim Fenkes =A0-- =A0eHCA Linux Driver Developer and Hardware Tamer
IBM Deutschland Entwicklung GmbH =A0-- =A0Dept. 3627 (I/O Firmware Dev. 2)
Schoenaicher Strasse 220 =A0-- =A071032 Boeblingen =A0-- =A0Germany
eMail: fenkes@de.ibm.com
^ permalink raw reply
* [PATCH 1/5] IB/ehca: Supply QP token for SRQ base QPs
From: Joachim Fenkes @ 2007-10-16 15:24 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, OF-EWG; +Cc: Stefan Roscher, Christoph Raisch
In-Reply-To: <200710161722.29144.fenkes@de.ibm.com>
Because hardware reports the SRQ token in RWQEs of SRQ base QPs, supply the
base QP token as SRQ token, so we can properly find the SRQ base QP.
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
drivers/infiniband/hw/ehca/ehca_qp.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_qp.c b/drivers/infiniband/hw/ehca/ehca_qp.c
index e2bd62b..de18264 100644
--- a/drivers/infiniband/hw/ehca/ehca_qp.c
+++ b/drivers/infiniband/hw/ehca/ehca_qp.c
@@ -451,7 +451,6 @@ static struct ehca_qp *internal_create_qp(
has_srq = 1;
parms.ext_type = EQPT_SRQBASE;
parms.srq_qpn = my_srq->real_qp_num;
- parms.srq_token = my_srq->token;
}
if (is_llqp && has_srq) {
@@ -583,6 +582,9 @@ static struct ehca_qp *internal_create_qp(
goto create_qp_exit1;
}
+ if (has_srq)
+ parms.srq_token = my_qp->token;
+
parms.servicetype = ibqptype2servicetype(qp_type);
if (parms.servicetype < 0) {
ret = -EINVAL;
--
1.5.2
^ permalink raw reply related
* [PATCH 2/5] IB/ehca: Fix masking error in {,re}reg_phys_mr()
From: Joachim Fenkes @ 2007-10-16 15:25 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, OF-EWG; +Cc: Stefan Roscher, Christoph Raisch
In-Reply-To: <200710161722.29144.fenkes@de.ibm.com>
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
drivers/infiniband/hw/ehca/ehca_mrmw.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_mrmw.c b/drivers/infiniband/hw/ehca/ehca_mrmw.c
index da88738..16c9efd 100644
--- a/drivers/infiniband/hw/ehca/ehca_mrmw.c
+++ b/drivers/infiniband/hw/ehca/ehca_mrmw.c
@@ -259,7 +259,7 @@ struct ib_mr *ehca_reg_phys_mr(struct ib_pd *pd,
pginfo.u.phy.num_phys_buf = num_phys_buf;
pginfo.u.phy.phys_buf_array = phys_buf_array;
pginfo.next_hwpage =
- ((u64)iova_start & ~(hw_pgsize - 1)) / hw_pgsize;
+ ((u64)iova_start & ~PAGE_MASK) / hw_pgsize;
ret = ehca_reg_mr(shca, e_mr, iova_start, size, mr_access_flags,
e_pd, &pginfo, &e_mr->ib.ib_mr.lkey,
@@ -547,7 +547,7 @@ int ehca_rereg_phys_mr(struct ib_mr *mr,
pginfo.u.phy.num_phys_buf = num_phys_buf;
pginfo.u.phy.phys_buf_array = phys_buf_array;
pginfo.next_hwpage =
- ((u64)iova_start & ~(hw_pgsize - 1)) / hw_pgsize;
+ ((u64)iova_start & ~PAGE_MASK) / hw_pgsize;
}
if (mr_rereg_mask & IB_MR_REREG_ACCESS)
new_acl = mr_access_flags;
--
1.5.2
^ permalink raw reply related
* [PATCH 3/5] IB/ehca: Fix ehca_encode_hwpage_size() and alloc_fmr()
From: Joachim Fenkes @ 2007-10-16 15:26 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, OF-EWG; +Cc: Stefan Roscher, Christoph Raisch
In-Reply-To: <200710161722.29144.fenkes@de.ibm.com>
Simplify ehca_encode_hwpage_size(), fixing an infinite loop for pgsize == 0
in the process. Fix the bug in alloc_fmr() that triggered the loop.
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
drivers/infiniband/hw/ehca/ehca_mrmw.c | 15 ++++-----------
1 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_mrmw.c b/drivers/infiniband/hw/ehca/ehca_mrmw.c
index 16c9efd..b9a788c 100644
--- a/drivers/infiniband/hw/ehca/ehca_mrmw.c
+++ b/drivers/infiniband/hw/ehca/ehca_mrmw.c
@@ -72,17 +72,9 @@ enum ehca_mr_pgsize {
static u32 ehca_encode_hwpage_size(u32 pgsize)
{
- u32 idx = 0;
- pgsize >>= 12;
- /*
- * map mr page size into hw code:
- * 0, 1, 2, 3 for 4K, 64K, 1M, 64M
- */
- while (!(pgsize & 1)) {
- idx++;
- pgsize >>= 4;
- }
- return idx;
+ int log = ilog2(pgsize);
+ WARN_ON(log < 12 || log > 24 || log & 3);
+ return (log - 12) / 4;
}
static u64 ehca_get_max_hwpage_size(struct ehca_shca *shca)
@@ -826,6 +818,7 @@ struct ib_fmr *ehca_alloc_fmr(struct ib_pd *pd,
/* register MR on HCA */
memset(&pginfo, 0, sizeof(pginfo));
+ pginfo.hwpage_size = hw_pgsize;
/*
* pginfo.num_hwpages==0, ie register_rpages() will not be called
* but deferred to map_phys_fmr()
--
1.5.2
^ permalink raw reply related
* Re: [PATCH 4/5] ibmebus: Move to of_device and of_platform_driver, match eHCA and eHEA drivers
From: Stephen Rothwell @ 2007-10-16 15:27 UTC (permalink / raw)
To: Joachim Fenkes
Cc: Thomas Q Klein, Jeff Garzik, Mackerras, netdev, Jan-Bernd Themann,
LKML, LinuxPPC-Dev, Christoph Raisch, Paul Mackerras, Marcus Eder,
Paul, Stefan Roscher
In-Reply-To: <200710162320.00630.fenkes@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 577 bytes --]
On Tue, 16 Oct 2007 23:20:00 +0200 Joachim Fenkes <fenkes@de.ibm.com> wrote:
>
One small change - I intend to remove the name and owner fields from
struct of_platform_driver, so you should not bother initialising the name
field and just initialise the name field of the embedded struct
device_driver instead. This, of course, means that you don't need
drv->driver.name = drv->name;
in ibmebus_register_driver.
Sorry for not picking this up earlier.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: Linux booting problem on Xilinx ppc
From: Sergey Oleynichenko @ 2007-10-16 15:08 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <13219154.post@talk.nabble.com>
I noticed this problem happens when on-chip memories are enabled in a design
(it is 4th page in base system builder). Try to leave them "none" for both
instruction and data.
Sergey
-----Original Message-----
From: linuxppc-embedded-bounces+soleynichenko=zenith.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+soleynichenko=zenith.com@ozlabs.org] On
Behalf Of aauer1
Sent: Monday, October 15, 2007 1:47 PM
To: linuxppc-embedded@ozlabs.org
Subject: Re: Linux booting problem on Xilinx ppc
Hello
I'm also working with ML403 board from Xilinx and have the same problem as
you. The boot process stops after decompressing with the message "Now
booting the kernel". We also used gcc-4.1.0 for the cross compilation. So, I
would be glad to know, which gcc version have you used to get a working
kernel!
Thanks,
Andreas
Junqiang Hu wrote:
>
>
> Hi Grant,
>
> Thank you so much for the reply! Fortunately I got it work now -- it's
> the crosstool compiler problem. Originally I was using gcc-4.1.0, yet
> when compiling kernel 2.6.22, I noticed that it says gcc-4.1.0 will
> miscompile the kernel, so I changed to another version, and now I can let
> it go!
>
> Right now still not fully booted because of the SystemACE problem, or
> maybe the partition is not correct. I'm still working on it, hopefully to
> get it solved soon :-)
>
> Thanks,
> -J.
>
>
> Grant Likely-2 wrote:
>>
>> On 9/15/07, Junqiang Hu <jqhu936@yahoo.com> wrote:
>>>
>>>
>>> Dear friends,
>>>
>>> I'm trying to run Linux in AvNet (Memec) Xilinx-XC2VP50-EVKT-FF1152
>>> board. The Linux version I'm using is 2.4; the cross-compiler is
>>> gcc-4.1.0, glibc 2.3.6. When booting the kernel, it shows:
>>> loaded at: 00400000 004B51E4
>>> board data at: 00000000 00000018
>>> relocated to: 0040526C 00405284
>>> zimage at: 00405B2B 004B177C
>>> avail ram: 004B6000 60000000
>>
>> I strongly recommend moving to a 2.6 kernel. Recent mainline has
>> support for the Xilinx ppc built in.
>>>
>>> Linux/PPC load: console=ttyS0,9600 root=/dev/xsysace/disc0/part3
>>> rw
>>> Uncompressing Linux...done.
>>> Now booting the kernel
>>>
>>> Then it hangs. First it seems to me that the "avail ram" is not correct,
>>> since I configured only 32MB SDRAM. Moreover, if it's first powered on,
>>> the
>>> end address of "avail ram" would be FFD9FBED. Then I tried to
>>> investigate
>>> the problem using xmd. When launched, it says:
>>
>> (If you're using u-boot) You might have a mismatch between the board
>> info structure used by u-boot and the one used by Linux.
>>
>> Also, you should use your debugger to inspect the __log_buf memory of
>> the kernel. A common problem is the kernel starts booting, but the
>> console is setup incorrectly and so you see nothing. But, you can
>> read the console output directly from memory if you look at the
>> __log_buf region (find the address in the System.map file; you might
>> need to subtract 0xC0000000 from the address to view the memory)
>>
>> Cheers,
>> g.
>>
>> --
>> Grant Likely, B.Sc., P.Eng.
>> Secret Lab Technologies Ltd.
>> grant.likely@secretlab.ca
>> (403) 399-0195
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/Linux-booting-problem-on-Xilinx-ppc-tf4449060.html#a13
219154
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [PATCH 4/5] IB/ehca: Change meaning of hca_cap_mr_pgsize
From: Joachim Fenkes @ 2007-10-16 15:31 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, OF-EWG; +Cc: Stefan Roscher, Christoph Raisch
In-Reply-To: <200710161722.29144.fenkes@de.ibm.com>
ehca_shca.hca_cap_mr_pgsize now contains all supported page sizes ORed
together. This makes some checks easier to code and understand, plus we can
return this value verbatim in query_hca(), fixing a problem with SRP
(reported by Anton Blanchard -- thanks!).
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
drivers/infiniband/hw/ehca/ehca_classes.h | 1 -
drivers/infiniband/hw/ehca/ehca_hca.c | 1 +
drivers/infiniband/hw/ehca/ehca_main.c | 18 ++++++++++++-
drivers/infiniband/hw/ehca/ehca_mrmw.c | 38 ++++++++++++++--------------
4 files changed, 36 insertions(+), 22 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_classes.h b/drivers/infiniband/hw/ehca/ehca_classes.h
index 0f7a55d..365bc5d 100644
--- a/drivers/infiniband/hw/ehca/ehca_classes.h
+++ b/drivers/infiniband/hw/ehca/ehca_classes.h
@@ -323,7 +323,6 @@ extern int ehca_static_rate;
extern int ehca_port_act_time;
extern int ehca_use_hp_mr;
extern int ehca_scaling_code;
-extern int ehca_mr_largepage;
struct ipzu_queue_resp {
u32 qe_size; /* queue entry size */
diff --git a/drivers/infiniband/hw/ehca/ehca_hca.c b/drivers/infiniband/hw/ehca/ehca_hca.c
index 4aa3ffa..15806d1 100644
--- a/drivers/infiniband/hw/ehca/ehca_hca.c
+++ b/drivers/infiniband/hw/ehca/ehca_hca.c
@@ -77,6 +77,7 @@ int ehca_query_device(struct ib_device *ibdev, struct ib_device_attr *props)
}
memset(props, 0, sizeof(struct ib_device_attr));
+ props->page_size_cap = shca->hca_cap_mr_pgsize;
props->fw_ver = rblock->hw_ver;
props->max_mr_size = rblock->max_mr_size;
props->vendor_id = rblock->vendor_id >> 8;
diff --git a/drivers/infiniband/hw/ehca/ehca_main.c b/drivers/infiniband/hw/ehca/ehca_main.c
index 403467f..d477dc3 100644
--- a/drivers/infiniband/hw/ehca/ehca_main.c
+++ b/drivers/infiniband/hw/ehca/ehca_main.c
@@ -260,13 +260,20 @@ static struct cap_descr {
{ HCA_CAP_MINI_QP, "HCA_CAP_MINI_QP" },
};
-int ehca_sense_attributes(struct ehca_shca *shca)
+static int ehca_sense_attributes(struct ehca_shca *shca)
{
int i, ret = 0;
u64 h_ret;
struct hipz_query_hca *rblock;
struct hipz_query_port *port;
+ static const u32 pgsize_map[] = {
+ HCA_CAP_MR_PGSIZE_4K, 0x1000,
+ HCA_CAP_MR_PGSIZE_64K, 0x10000,
+ HCA_CAP_MR_PGSIZE_1M, 0x100000,
+ HCA_CAP_MR_PGSIZE_16M, 0x1000000,
+ };
+
rblock = ehca_alloc_fw_ctrlblock(GFP_KERNEL);
if (!rblock) {
ehca_gen_err("Cannot allocate rblock memory.");
@@ -329,8 +336,15 @@ int ehca_sense_attributes(struct ehca_shca *shca)
if (EHCA_BMASK_GET(hca_cap_descr[i].mask, shca->hca_cap))
ehca_gen_dbg(" %s", hca_cap_descr[i].descr);
- shca->hca_cap_mr_pgsize = rblock->memory_page_size_supported;
+ /* translate supported MR page sizes; always support 4K */
+ shca->hca_cap_mr_pgsize = EHCA_PAGESIZE;
+ if (ehca_mr_largepage) { /* support extra sizes only if enabled */
+ for (i = 0; i < ARRAY_SIZE(pgsize_map); i += 2)
+ if (rblock->memory_page_size_supported & pgsize_map[i])
+ shca->hca_cap_mr_pgsize |= pgsize_map[i + 1];
+ }
+ /* query max MTU from first port -- it's the same for all ports */
port = (struct hipz_query_port *)rblock;
h_ret = hipz_h_query_port(shca->ipz_hca_handle, 1, port);
if (h_ret != H_SUCCESS) {
diff --git a/drivers/infiniband/hw/ehca/ehca_mrmw.c b/drivers/infiniband/hw/ehca/ehca_mrmw.c
index b9a788c..bb97915 100644
--- a/drivers/infiniband/hw/ehca/ehca_mrmw.c
+++ b/drivers/infiniband/hw/ehca/ehca_mrmw.c
@@ -79,9 +79,7 @@ static u32 ehca_encode_hwpage_size(u32 pgsize)
static u64 ehca_get_max_hwpage_size(struct ehca_shca *shca)
{
- if (shca->hca_cap_mr_pgsize & HCA_CAP_MR_PGSIZE_16M)
- return EHCA_MR_PGSIZE16M;
- return EHCA_MR_PGSIZE4K;
+ return 1UL << ilog2(shca->hca_cap_mr_pgsize);
}
static struct ehca_mr *ehca_mr_new(void)
@@ -288,7 +286,7 @@ struct ib_mr *ehca_reg_user_mr(struct ib_pd *pd, u64 start, u64 length,
container_of(pd->device, struct ehca_shca, ib_device);
struct ehca_pd *e_pd = container_of(pd, struct ehca_pd, ib_pd);
struct ehca_mr_pginfo pginfo;
- int ret;
+ int ret, page_shift;
u32 num_kpages;
u32 num_hwpages;
u64 hwpage_size;
@@ -343,19 +341,20 @@ struct ib_mr *ehca_reg_user_mr(struct ib_pd *pd, u64 start, u64 length,
/* determine number of MR pages */
num_kpages = NUM_CHUNKS((virt % PAGE_SIZE) + length, PAGE_SIZE);
/* select proper hw_pgsize */
- if (ehca_mr_largepage &&
- (shca->hca_cap_mr_pgsize & HCA_CAP_MR_PGSIZE_16M)) {
- int page_shift = PAGE_SHIFT;
- if (e_mr->umem->hugetlb) {
- /* determine page_shift, clamp between 4K and 16M */
- page_shift = (fls64(length - 1) + 3) & ~3;
- page_shift = min(max(page_shift, EHCA_MR_PGSHIFT4K),
- EHCA_MR_PGSHIFT16M);
- }
- hwpage_size = 1UL << page_shift;
- } else
- hwpage_size = EHCA_MR_PGSIZE4K; /* ehca1 only supports 4k */
- ehca_dbg(pd->device, "hwpage_size=%lx", hwpage_size);
+ page_shift = PAGE_SHIFT;
+ if (e_mr->umem->hugetlb) {
+ /* determine page_shift, clamp between 4K and 16M */
+ page_shift = (fls64(length - 1) + 3) & ~3;
+ page_shift = min(max(page_shift, EHCA_MR_PGSHIFT4K),
+ EHCA_MR_PGSHIFT16M);
+ }
+ hwpage_size = 1UL << page_shift;
+
+ /* now that we have the desired page size, shift until it's
+ * supported, too. 4K is always supported, so this terminates.
+ */
+ while (!(hwpage_size & shca->hca_cap_mr_pgsize))
+ hwpage_size >>= 4;
reg_user_mr_fallback:
num_hwpages = NUM_CHUNKS((virt % hwpage_size) + length, hwpage_size);
@@ -801,8 +800,9 @@ struct ib_fmr *ehca_alloc_fmr(struct ib_pd *pd,
ib_fmr = ERR_PTR(-EINVAL);
goto alloc_fmr_exit0;
}
- hw_pgsize = ehca_get_max_hwpage_size(shca);
- if ((1 << fmr_attr->page_shift) != hw_pgsize) {
+
+ hw_pgsize = 1 << fmr_attr->page_shift;
+ if (!(hw_pgsize & shca->hca_cap_mr_pgsize)) {
ehca_err(pd->device, "unsupported fmr_attr->page_shift=%x",
fmr_attr->page_shift);
ib_fmr = ERR_PTR(-EINVAL);
--
1.5.2
^ permalink raw reply related
* [PATCH 5/5] IB/ehca: Enable large page MRs by default
From: Joachim Fenkes @ 2007-10-16 15:31 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, OF-EWG; +Cc: Stefan Roscher, Christoph Raisch
In-Reply-To: <200710161722.29144.fenkes@de.ibm.com>
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
drivers/infiniband/hw/ehca/ehca_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_main.c b/drivers/infiniband/hw/ehca/ehca_main.c
index d477dc3..2f51c13 100644
--- a/drivers/infiniband/hw/ehca/ehca_main.c
+++ b/drivers/infiniband/hw/ehca/ehca_main.c
@@ -65,7 +65,7 @@ int ehca_port_act_time = 30;
int ehca_poll_all_eqs = 1;
int ehca_static_rate = -1;
int ehca_scaling_code = 0;
-int ehca_mr_largepage = 0;
+int ehca_mr_largepage = 1;
module_param_named(open_aqp1, ehca_open_aqp1, int, S_IRUGO);
module_param_named(debug_level, ehca_debug_level, int, S_IRUGO);
--
1.5.2
^ permalink raw reply related
* Re: mpc 860 boot linux2.6.23 problem
From: Scott Wood @ 2007-10-16 16:18 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <20071015233839.959F4247BB@gemini.denx.de>
Wolfgang Denk wrote:
> In message <4713A08C.3060204@freescale.com> you wrote:
>> keng_629 wrote:
>>>
>>> i am proting linux2.63.23 to mpc860t board with uboot1.1.4 as bootloader.
>>> my bootargs is root=/dev/ram rw init=/linuxrc.
>>> i use debugger to see the regedits, find pc is run in the cpu_idle().
>>> what is wrong with my kernel, plese give me some advice.thank you .
>> Posting the same thing over and over again isn't going to change the
>> response. Try head-of-Linus's-git, make sure you're using arch/powerpc,
>> and post the device tree you're using. Without more information, we
>> can't help you.
>
> Just to point out the obvious: U-Boot 1.1.4 is *way* too old to
> support any device-tree based kernel, so the fist step is to update
> U-Boot to a somewhat recent version (i. e. 1.3.0-rcX).
Upgrading to the latest u-boot certainly shouldn't hurt, but I don't
think there's any device tree support for 8xx yet, so for now he should
boot with cuImage.
-Scott
^ permalink raw reply
* Re: Serial init / BRG
From: Scott Wood @ 2007-10-16 16:31 UTC (permalink / raw)
To: Alan Bennett; +Cc: linuxppc-dev
In-Reply-To: <bfa0697f0710160719r44099b19jbda55af2ef88e9f8@mail.gmail.com>
Alan Bennett wrote:
> A few questions: To use 3 brgs, should I have 1 brg entry and X reg
> values or three brg entries in my device tree?
The current brg entry describes all 8 BRGs... don't touch it. :-)
> what are the third and fourth reg values of the brg item in the
> device tree. I'll need 3 separate baud rates on the serial lines.
> Should I just add code to initialize the brg's in u-boot or figure
> out how to get the kernel to do it?
No, the kernel should do it. Are you associating the BRG with the SCC
in the CMXSCR register, and setting up the pins required by SCC1 and
SCC4, in either u-boot or your platform code?
> boot sequence
> ===========
> CPM UART serial mem=e0011a80 pram=e0000000
> ttyCPM0 at MMIO 0xe0011a80 (irq = 16) is a CPM UART
>
> CPM UART serial mem=e0011a00 pram=e0008000
> CPM uart[1]:init_scc - sup = e0008000
> ttyCPM1 at MMIO 0xe0011a00 (irq = 40) is a CPM UART
>
> CPM UART serial mem=e0011a60 pram=e0008300
> CPM uart[2]:init_scc - sup = e0008300
> ttyCPM2 at MMIO 0xe0011a60 (irq = 43) is a CPM UART
>
> BRG Values after above
> =================
> brgc1: 0x00000000
> brgc2: 0x00000000
> brgc3: 0x00000000
> brgc4: 0x00000000
> brgc5: 0x00000000
> brgc6: 0x00000000
> brgc7: 0x0001004e
> brgc8: 0x00000000
This is expected if you haven't opened the other serial ports yet... it
doesn't initialize the brg until then.
-Scott
^ permalink raw reply
* RE: cross compilation issue
From: Leisner, Martin @ 2007-10-16 16:36 UTC (permalink / raw)
To: ravi.rao, avenkatesh
Cc: linuxppc-embedded-bounces+ravi.rao=rflelect.com,
linuxppc-embedded
In-Reply-To: <OF1782007A.A1A7A36C-ON85257376.005181BD-85257376.00519317@rflelect.com>
I sometimes found this painful...
I have a simple script in a configured directory "make-line" which looks =
like
bash2 :2 mleisner@linuxcom-01 11:53:58; cat make-line
#! /bin/bash
exec make ARCH=3Dpowerpc =
CROSS_COMPILE=3D/opt/denx/eldk4.1/usr/bin/ppc_74xx- =
INSTALL_MOD_PATH=3D${PWD}/root $*
I know hardhat linux had a strategy to make . files hiding the names of =
ARCH/CROSS_COMPILE -- so typing make
would work once configured...
IMHO it should be hardcoded in the Makefile after configuration -- it =
causes a lot of grief if you FORGET
to specify one of these and just type "make".
One of the things I want to do is look at how the linux make system =
works now (I recall at times I edit the Makefile
to hardcode these things).
marty
________________________________________
From: linuxppc-embedded-bounces+martin.leisner=3Dxerox.com@ozlabs.org =
[mailto:linuxppc-embedded-bounces+martin.leisner=3Dxerox.com@ozlabs.org] =
On Behalf Of ravi.rao@rflelect.com
Sent: Tuesday, October 16, 2007 10:52 AM
To: avenkatesh@hcl.in
Cc: linuxppc-embedded-bounces+ravi.rao=3Drflelect.com@ozlabs.org; =
linuxppc-embedded@ozlabs.org
Subject: Re: cross compilation issue
Hi,=20
=A0Easiest way is to edit the x86 Makefile so that gcc and ld points to =
Ur tool chain's ppc_6xx-gcc & ppc_6xx-ld..=20
Thanks,
Ravishankar Govindarao
RFL Electronics Inc.
E-mail : Ravi.Rao@rflelect.com=20
Voice: 973.334.3100 Ext. 233
Fax: 973.334.3863=20
=A0=20
CONFIDENTIALITY NOTE
This e-mail, including any attachments, may contain confidential and/or =
legally privileged information.=A0 The Information is intended only for =
the use of the individual or entity named on this e-mail .=A0 If you are =
not the intended recipient, you are hereby notified that any disclosure, =
copying, distribution, or the taking of any action in reliance on the =
contents of this transmitted Information is strictly prohibited.=A0 =
Further, if you are not the intended recipient, please notify us by =
return e-mail and delete the Information promptly.=20
=A0=20
=A0=20
=A0=20
"Venkatesh Ananthakrishnan, TLS-Chennai" <avenkatesh@hcl.in>=20
Sent by: linuxppc-embedded-bounces+ravi.rao=3Drflelect.com@ozlabs.org=20
10/16/2007 10:24 AM=20
To
<linuxppc-embedded@ozlabs.org>=20
cc
Subject
cross compilation issue
Hai=20
I am newbi to linux.=20
I wrote the application usb libusb which works fine with x86 pc.=20
I want to compile the application for ppc. I have cross compiled libusb. =
I have tool chain also.=20
If I give ppc_6xx-gcc filename.c=20
It gives the error message as usb.h No such a file or directory.=20
How to give include path and library path during compilation?=20
Please do the needful=20
=A0=20
Regards,=20
Venkatesh=20
=A0=20
DISCLAIMER:
-------------------------------------------------------------------------=
----------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and =
intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its =
affiliates. Any views or opinions presented in=20
this email are solely those of the author and may not necessarily =
reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, =
modification, distribution and / or publication of=20
this message without the prior written consent of the author of this =
e-mail is strictly prohibited. If you have=20
received this email in error please delete it and notify the sender =
immediately. Before opening any mail and=20
attachments please check them for viruses and defect.
-------------------------------------------------------------------------=
----------------------------------------------
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded=20
^ permalink raw reply
* Re: ioctl32: Unknown cmd
From: Jens Axboe @ 2007-10-16 16:58 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux/PPC Development, Linux Kernel Development, Arnd Bergmann
In-Reply-To: <Pine.LNX.4.62.0710161642200.20196@pademelon.sonytel.be>
On Tue, Oct 16 2007, Geert Uytterhoeven wrote:
> Hi Arnd, Jens,
>
> The recent (post 2.6.23) changes to compat_ioctl made the reporting of
> unsupported ioctls more verbose. E.g. on the PS3 I get:
>
> | ioctl32(cdrom_id:608): Unknown cmd fd(3) cmd(00005331){t:'S';sz:0} arg(00000000) on /dev/.tmp-11-0
> | ioctl32(hdparm:1427): Unknown cmd fd(3) cmd(0000031f){t:03;sz:0} arg(00000000) on /dev/ps3da
> | ioctl32(hdparm:1427): Unknown cmd fd(3) cmd(0000031f){t:03;sz:0} arg(00000000) on /dev/ps3da
>
> The first one is triggered by the detection of the CD/DVD/BD-ROM driver,
> The others are triggered by me running hdparm.
>
> Was this intentional?
Nope, not intential to me at least. I'll check up on it.
--
Jens Axboe
^ permalink raw reply
* RE: Refactor booting-without-of.txt
From: Stephen Neuendorffer @ 2007-10-16 17:13 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev, microblaze-uclinux
In-Reply-To: <fa686aa40710150908o55d1f5d2t264cbb8ed800a12f@mail.gmail.com>
On a similar note, is there interest in actually factoring the device
tree code out from the different architectures into a common codebase?
Steve=20
> -----Original Message-----
> From:=20
> linuxppc-dev-bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.or
> g=20
> [mailto:linuxppc-dev-bounces+stephen.neuendorffer=3Dxilinx.com@o
zlabs.org] On Behalf Of Grant Likely
> Sent: Monday, October 15, 2007 9:09 AM
> To: linuxppc-dev; microblaze-uclinux@itee.uq.edu.au
> Subject: Refactor booting-without-of.txt
>=20
> Adding the Linux expected device tree bindings to
> booting-without-of.txt seems to be getting a little unwieldy. Plus
> with more than one arch using the device tree (powerpc, sparc &
> microblaze) the device tree bindings aren't necessarily powerpc only
> (the Xilinx devices certainly fall in this category).
>=20
> Anyone have comments about splitting the expected device tree bindings
> out of booting-without-of.txt into a separate directory?
>=20
> Perhaps something like this; each file contains common bindings for
> the type of device and device specific properties:
>=20
> Documentation/of/
> Documentation/of/README - Description of the purpose and layout of
> this directory
> Documentation/of/net.txt - network device bindings (eth,=20
> MDIO, phy, etc)
> Documentation/of/serial.txt - serial device bindings
> Documentation/of/misc.txt - anything that doesn't fit=20
> anywhere else yet.
> Documentation/of/soc/* - System on chip stuff that doesn't fit will
> into established device types; possibly a separate file for each chip.
> Documentation/of/usb.txt - usb blah blah blah
> Documentation/of/whatever - you get the picture.
>=20
> Thoughts?
> g.
>=20
> --=20
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>=20
>=20
^ permalink raw reply
* Re: Refactor booting-without-of.txt
From: Grant Likely @ 2007-10-16 17:17 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, microblaze-uclinux
In-Reply-To: <20071016171417.64605230209@mail24-fra.bigfish.com>
On 10/16/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
> On a similar note, is there interest in actually factoring the device
> tree code out from the different architectures into a common codebase?
It's already happened somewhat. (Look in drivers/of and include/linux/of*.h)
However, I don't think any of the stuff specific to flattened device
trees is being factored out of arch/powerpc yet.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ 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