* [PATCH] [POWERPC] Add TAH support to taishan dts
From: Stefan Roese @ 2008-03-13 16:00 UTC (permalink / raw)
To: linuxppc-dev
This patch adds TAH (TCP/IP Acceleration Hardware) support to the
taishan 440GX dts. It depends on the NEWEMAC/tah patch that adds the
compatible "ibm,tah" property to the matching table.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/boot/dts/taishan.dts | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/taishan.dts b/arch/powerpc/boot/dts/taishan.dts
index 8278068..b5aad74 100644
--- a/arch/powerpc/boot/dts/taishan.dts
+++ b/arch/powerpc/boot/dts/taishan.dts
@@ -232,6 +232,15 @@
reg = <40000790 8>;
};
+ TAH0: emac-tah@40000b50 {
+ compatible = "ibm,tah-440gx", "ibm,tah";
+ reg = <40000b50 30>;
+ };
+
+ TAH1: emac-tah@40000d50 {
+ compatible = "ibm,tah-440gx", "ibm,tah";
+ reg = <40000d50 30>;
+ };
EMAC0: ethernet@40000800 {
unused = <1>;
@@ -297,6 +306,8 @@
rgmii-channel = <0>;
zmii-device = <&ZMII0>;
zmii-channel = <2>;
+ tah-device = <&TAH0>;
+ tah-channel = <0>;
};
EMAC3: ethernet@40000e00 {
@@ -320,6 +331,8 @@
rgmii-channel = <1>;
zmii-device = <&ZMII0>;
zmii-channel = <3>;
+ tah-device = <&TAH1>;
+ tah-channel = <0>;
};
--
1.5.4.4
^ permalink raw reply related
* Re: slow Kilauea TCP throughput?
From: Stefan Roese @ 2008-03-13 16:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Donasch, Ingo @ SDS
In-Reply-To: <9E33F44949583B4597BDA2D06042567003734A0F@FLS-EXCHANGE.corp.sds.l-3com.com>
On Wednesday 12 March 2008, Donasch, Ingo @ SDS wrote:
> I have a project where I would like to use the AMC405EX under Linux for
> high speed data acquisition. I have the Kilauea board in the lab but
> measured only 150Mbit/s TCP throughput (outbound) with iperf. I need
> twice of that and actually expecting 3x higher bandwidth from that
> architecture.
I'm not sure if 3 times the performace will be possible. Why did you expect
such a performance btw?
> what is it that I'm missing?
> can anybody confirm my results or tell me what am I doing wrong?
I just ran some iperf tests and they show similar results. I'll currently
comparing them to other 4xx platforms. Perhaps this gives some infos on what
is happening here and where the bottleneck lies.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* RE: Using GDB with Abatron's BDI2000 and the ppc405 in the Xilinx VirtexII Pro
From: Sugathan, Rupesh @ 2008-03-13 16:51 UTC (permalink / raw)
To: Wood, Robert (GE EntSol, Intelligent Platforms),
linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 555 bytes --]
We need a simple description of how to get GDB running with the BDI2000.
We have the '2000 communicating and can access the registers and like
through the telnet link but don't know how to configure the unit or GDB
to work together.
See if these helps
http://www.unimax.co.kr/unimax_2003_11/products/datasheets/ManGDBPPC-200
0C5.pdf
http://microcross.com/Debugging_Linux_Kernel.pdf
<http://microcross.com/Debugging_Linux_Kernel.pdf>
http://ultsol.com/pdfs/ <http://ultsol.com/pdfs/>
Thanks
--
Rupesh Sugathan
[-- Attachment #2: Type: text/html, Size: 4116 bytes --]
^ permalink raw reply
* RE: Using GDB with Abatron's BDI2000 and the ppc405 in the Xilinx VirtexII Pro
From: John Linn @ 2008-03-13 17:11 UTC (permalink / raw)
To: Wood, Robert (GE EntSol, Intelligent Platforms),
linuxppc-embedded
In-Reply-To: <0F3B2CB6574F1A488E62523706BF8A7703F295E7@LOUMLVEM03.e2k.ad.ge.com>
[-- Attachment #1: Type: text/plain, Size: 1344 bytes --]
Hi Robert,
Here's a link to an app note on it. I'm using it on the 405 right now as
we speak. I used the app note to get it working.
If you have problems, let me know.
http://www.xilinx.com/support/documentation/application_notes/xapp981.pd
f
Thanks,
John Linn
Xilinx Open Source Linux Engineer
________________________________
From: linuxppc-embedded-bounces+john.linn=xilinx.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+john.linn=xilinx.com@ozlabs.org] On
Behalf Of Wood, Robert (GE EntSol,Intelligent Platforms)
Sent: Thursday, March 13, 2008 9:48 AM
To: linuxppc-embedded@ozlabs.org
Subject: Using GDB with Abatron's BDI2000 and the ppc405 in the Xilinx
VirtexII Pro
Hi, sorry for what is probably previously covered subject., I am
searching the archives.
We need a simple description of how to get GDB running with the BDI2000.
We have the '2000 communicating and can access the registers and like
through the telnet link but don't know how to configure the unit or GDB
to work together.
Robert Wood
Senior Engineer
GE Fanuc Intelligent Platforms
T +613 749 9241 x270
F +613 749 9461
E robert.wood@gefanuc.com
www.ge.com
5430 Canotek Road
Ottawa, Ontario
Canada K1J 9G2
General Electric Company
[-- Attachment #2: Type: text/html, Size: 14258 bytes --]
^ permalink raw reply
* RE: [PATCH] Ported Xilinx GPIO driver to OpenFirmware.
From: Stephen Neuendorffer @ 2008-03-13 17:18 UTC (permalink / raw)
To: Magnus Hjorth, git; +Cc: linuxppc-embedded
In-Reply-To: <001601c884e4$ef90bff0$ceb23fd0$@se>
Thanks Magnus...
Re: SPI I've been pondering some ideas along this line, but I haven't
done anything concrete. There are other cases where it makes sense to
have some information about the board-level design of the system (e.g.
ethernet PHYs.).
Steve
> -----Original Message-----
> From: Magnus Hjorth [mailto:mh@omnisys.se]
> Sent: Thursday, March 13, 2008 1:34 AM
> To: Stephen Neuendorffer; git
> Cc: linuxppc-embedded@ozlabs.org; 'Grant Likely'
> Subject: RE: [PATCH] Ported Xilinx GPIO driver to OpenFirmware.
>=20
> Hi,
>=20
> Thanks for the feedback. I'll have a look into refining the patch in a
few weeks when I get some
> more time.
>=20
> I have also been tinkering a little with the SPI driver, and that got
me thinking. Wouldn't it be
> great if SPI controllers and devices could be specified in the OF
device tree and registered on boot
> time? Even better if SPI worked as a true bus in EDK, with placeholder
IP-cores for each slave
> device, so such device entries could be autogenerated.
>=20
> Cheers,
> Magnus
>=20
> > -----Original Message-----
> > From: Stephen Neuendorffer [mailto:stephen.neuendorffer@xilinx.com]
> > Sent: den 11 mars 2008 18:36
> > To: Magnus Hjorth; git
> > Cc: linuxppc-embedded@ozlabs.org; Grant Likely
> > Subject: RE: [PATCH] Ported Xilinx GPIO driver to OpenFirmware.
> >
> >
> > Thanks Magnus!
> >
> > Generally speaking this looks reasonable. Some comments:
> >
> > > struct xgpio_instance {
> > > struct list_head link;
> > > unsigned long base_phys; /* GPIO base address - physical
> > */
> > > unsigned long remap_size;
> > > - u32 device_id;
> > > + u32 device_id; /* Dev ID for platform devices, 0 for OF
> > devices */
> > > + void *of_id; /* of_dev pointer for OF devices, NULL
> > for plat devices */
> >
> > Why have separate ids? I don't think the of_dev needs to be kept
around
> > here. This driver seems seems awkwardly written to have a local
list of
> > all the devices, rather than simply attaching the xgpio_instance as
the
> > private data of the file.
> >
> > For instance, in drivers/char/xilinx_hwicap.c:
> >
> > static ssize_t
> > hwicap_read(struct file *file, char __user *buf, size_t count,
loff_t
> > *ppos)
> > {
> > struct hwicap_drvdata *drvdata =3D file->private_data;
> >
> > and the drvdata is set in open:
> >
> > static int hwicap_open(struct inode *inode, struct file *file)
> > {
> > struct hwicap_drvdata *drvdata;
> > int status;
> >
> > drvdata =3D container_of(inode->i_cdev, struct hwicap_drvdata,
> > cdev);
> > ...
> > file->private_data =3D drvdata;
> >
> > Which would work if xgpio_instance directly contains the struct
> > miscdevice.
> > I think this is a much cleaner pattern (although it took me a while
to
> > figure out the magic that makes it work... )
> >
> > > +static struct of_device_id xgpio_of_match[] =3D {
> > > + {.compatible =3D "xlnx,xps-gpio-1.00.a"},
> >
> > This should also probably contain the corresponding strings for the
> > following as well:
> > opb_gpio_v1_00_a
> > opb_gpio_v2_00_a
> > opb_gpio_v3_01_a
> > opb_gpio_v3_01_b
> > plb_gpio_v1_00_b
> >
> > This would seem to be a relatively easy driver to clean up (by
pulling
> > it all into one file and converting the other code to the kernel
style)
> > and submit to mainline, if you're interested?
> >
> > Steve
^ permalink raw reply
* console kernel parameter problem
From: Fabio Ubaldi @ 2008-03-13 16:53 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I'm working with a board with a MPC8548 processor. I built the uboot,
the DTS file (myboard.dtb) and a kernel 2.6.21 .
When I try to boot the kernel via NFS I have some exception mode when
parsing the kernel parameters. Specifically I obtained an error during
the parsing of "console" parameter.
My host computer is connected to the board via console using a standard
8250 port.
I append the log in this post.
Has anyone any suggestion?
Thanks in advance for the reply.
root=/dev/nfs rw nfsroot=192.168.0.90:/home/ftpuser/workspace/rootfs
ip=192.168.0.11:192.168.0.90:192.168.0.90:255.255.255.0:MYBOARD:eth2:off
console=ttyS1,115200
=>
=>
=> run nfsboot
Enet starting in 1000BT/FD
Speed: 1000, full duplex
Using eTSEC2 device
TFTP from server 192.168.0.90; our IP address is 192.168.0.11
Filename 'uImage'.
Load address: 0x1000000
Loading: *\b
Enet starting in 1000BT/FD
Speed: 1000, full duplex
Using eTSEC2 device
TFTP from server 192.168.0.90; our IP address is 192.168.0.11
Filename 'myboard.dtb'.
Load address: 0x3000000
Loading: *\b
## Booting image at 01000000 ...
Image Name: Linux-2.6.21.7
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1509390 Bytes = 1.4 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Booting using the fdt at 0x3000000
Loading Device Tree to 007fc000, end 007fd313 ... OK
Parsing ARGS: root=/dev/nfs rw
nfsroot=192.168.0.90:/home/ftpuser/workspace/rootfs
ip=192.168.0.11:192.168.0.90:192.168.0.90:255.255.255.0:MYBOARD:eth2:off
console=ttyS1,115200
early options: Parameter `root'
Unknown argument: calling c02dc5f0
return parse_one 0 early options: Parameter `root'
early options: Parameter `rw'
Unknown argument: calling c02dc5f0
return parse_one 0 early options: Parameter `rw'
early options: Parameter `nfsroot'
Unknown argument: calling c02dc5f0
return parse_one 0 early options: Parameter `nfsroot'
early options: Parameter `ip'
Unknown argument: calling c02dc5f0
return parse_one 0 early options: Parameter `ip'
early options: Parameter `console'
Unknown argument: calling c02dc5f0
return parse_one 0 early options: Parameter `console'
Using MYBOARD machine description
Memory CAM mapping: CAM0=256Mb, CAM1=256Mb, CAM2=256Mb residual: 256Mb
Linux version 2.6.21.7 (gcc version 4.1.2 ) #2 PREEMPT Thu Mar 13
16:30:01 GMT 2008
setup_arch: bootmem
setup_arch()
arch: exit
Zone PFN ranges:
DMA 0 -> 196608
Normal 196608 -> 196608
HighMem 196608 -> 262144
early_node_map[1] active PFN ranges
0: 0 -> 262144
Built 1 zonelists. Total pages: 260096
Kernel command line: root=/dev/nfs rw
nfsroot=192.168.0.90:/home/ftpuser/workspace/rootfs
ip=192.168.0.11:192.168.0.90:192.168.0.90:255.255.255.0:MYBOARD:eth2:off
console=ttyS1,115200
Parsing ARGS: root=/dev/nfs rw
nfsroot=192.168.0.90:/home/ftpuser/workspace/rootfs
ip=192.168.0.11:192.168.0.90:192.168.0.90:255.255.255.0:MYBOARD:eth2:off
console=ttyS1,115200
Booting kernel: Parameter `root'
Unknown argument: calling c02dc318
return parse_one 0 Booting kernel: Parameter `root=/dev/nfs'
Booting kernel: Parameter `rw'
Unknown argument: calling c02dc318
return parse_one 0 Booting kernel: Parameter `rw'
Booting kernel: Parameter `nfsroot'
Unknown argument: calling c02dc318
return parse_one 0 Booting kernel: Parameter
`nfsroot=192.168.0.90:/home/ftpuser/workspace/rootfs'
Booting kernel: Parameter `ip'
Unknown argument: calling c02dc318
return parse_one 0 Booting kernel: Parameter
`ip=192.168.0.11:192.168.0.90:192.168.0.90:255.255.255.0:MYBOARD:eth2:off'
Booting kernel: Parameter `console'
Unknown argument: calling c02dc318
Oops: Exception in kernel mode, sig: 4 [#1]
PREEMPT
Modules linked in:
NIP: C02E7B30 LR: C02E7C28 CTR: 00000000
REGS: c031be80 TRAP: 0700 Not tainted (2.6.21.7)
MSR: 00021000 <ME> CR: 24084022 XER: 00000000
TASK = c02fe5b8[0] 'swapper' THREAD: c031a000
GPR00: 00000000 C031BF30 C02FE5B8 C0332184 C031BF58 C035595A C031BF5E
C0300000
GPR08: 0000000A C0332184 00000001 C0332184 00000000 60000000 3FFFC400
03000000
GPR16: 00000001 00000000 007FFF00 00000000 00000000 007FFEB0 00000000
C02D6000
GPR24: 00000044 00021000 00000000 C035595A 00000001 C031BF58 C0332184
00000000
NIP [C02E7B30] add_preferred_console+0xac/0xd8
LR [C02E7C28] console_setup+0xcc/0xe4
Call Trace:
[C031BF30] [C03017C0] 0xc03017c0 (unreliable)
[C031BF50] [C02E7C28] console_setup+0xcc/0xe4
[C031BF70] [C02DC400] unknown_bootoption+0xe8/0x260
[C031BF90] [C003DDC8] parse_args+0x1f8/0x310
[C031BFC0] [C02DC7F4] start_kernel+0x16c/0x2b4
[C031BFF0] [C0000388] skpinv+0x2b8/0x2f4
Instruction dump:
48000048 3d20c030 38600000 93e9ff98 48000038 3d20c030 93e9ff98 3d20c033
39292184 57eb2036 7d6b4a14 38000000 <7d3d44aa> 7d2b45aa 38600000 938b0008
Kernel panic - not syncing: Attempted to kill the idle task!
Rebooting in 180 seconds..
^ permalink raw reply
* Linux/PPC leads needed
From: Sadakathullah Mohamed Ali (mohamali) @ 2008-03-13 17:57 UTC (permalink / raw)
To: linuxppc-dev
Hi LinuxPPC Guru's
I am sending these leads your way on behalf of Cisco's Embedded system
software manager.
Please send responses to mohamali@cisco.com
Cisco has 3 positions which are very similar 2 Technical lead positions
and 1 Sr. Software Engineer position(Linux, Power PC, Bring up and
Drivers, Diag software (U-boot) )=20
=20
Req 1: Technical Lead (New product) - (Driver, board bring up, Linux,
PowerPC)
------------------------------------------------------------------------
------
Location: San Jose, CA
Cisco is looking to hire a tech lead - Software engineer. This is a
highly skilled, high power team with a goal to make significant
contribution to the way Cisco designs and develops system software in
the datacenter.
Sr. System Software Engineer with the following experience/skills:=20
*8+ years C programming, embedded OS and device drivers *Solid grounding
in Linux/Unix internals *Hardware board bringup, ability to read
schematic drawings *PowerPC assembly, a plus *Familiarity with
Clearcase, cvs or other SCM systems *Ability to document and communicate
original designs *At least a BSCS or BSEE *Good communication skills
*Strong team player
Desirable Skills:
*Knowledge and understanding of networks and networking software *TCL ,
PERL, Python or other scripting language *Knowledge of Cisco's Data
Center OS is a Plus.
Req 2: Tech lead - Diag software development - Cisco's new digital video
product
------------------------------------------------------------------------
--------
The successful applicant must have a proven track record of bringing
products to market, and should possess the following particular skills
and experience:=20
* 7-10 years of experience working as a software engineer with a hi-tech
company * Experience with the bring-up of complex PC boards with
advanced CPU, DSP, and Ethernet chipsets.=20
* Experience with embedded processors (Intel, Freescale) * Linux
experience * UBoot experience * ATCA experience highly desirable *
Experience in managing and working with external developer resources.=20
* Demonstrated ability to successfully influence win-win
cross-functional dynamics.=20
* Applies high degree of ingenuity using broad parameters for foundation
of decisions.=20
* Makes product level decisions independently.=20
* Technical, Industry, Business and Cross-Functional Knowledge.=20
* Have outstanding communication, presentation and written skills as
well as an ability to deal effectively with both technologists and
business representatives and to sell and promote ideas across the
organization.=20
Education
* Requires BSEE, BSCS or equivalent training with 7-10+ yrs related exp.
Masters degree desired.
=09
Thanks and Regards
Mohamed Ali
mohamali@cisco.com
Mobile :510-402-7625
225 E Tasman Dr San Jose, CA United States
www.cisco.com=20
^ permalink raw reply
* Linux/PPC leads needed
From: Sadakathullah Mohamed Ali (mohamali) @ 2008-03-13 17:47 UTC (permalink / raw)
To: linuxppc-embedded
Hi LinuxPPC Guru's
I am sending these leads your way on behalf of Cisco's Embedded system
software manager.
Please send responses to mohamali@cisco.com
Cisco has 3 positions which are very similar 2 Technical lead positions
and 1 Sr. Software Engineer position(Linux, Power PC, Bring up and
Drivers, Diag software (U-boot) )=20
=20
Req 1: Technical Lead (New product) - (Driver, board bring up, Linux,
PowerPC)
------------------------------------------------------------------------
------
Location: San Jose, CA
Cisco is looking to hire a tech lead - Software engineer. This is a
highly skilled, high power team with a goal to make significant
contribution to the way Cisco designs and develops system software in
the datacenter.
Sr. System Software Engineer with the following experience/skills:=20
*8+ years C programming, embedded OS and device drivers
*Solid grounding in Linux/Unix internals
*Hardware board bringup, ability to read schematic drawings
*PowerPC assembly, a plus
*Familiarity with Clearcase, cvs or other SCM systems
*Ability to document and communicate original designs
*At least a BSCS or BSEE
*Good communication skills
*Strong team player
Desirable Skills:
*Knowledge and understanding of networks and networking software
*TCL , PERL, Python or other scripting language
*Knowledge of Cisco's Data Center OS is a Plus.
Req 2: Tech lead - Diag software development - Cisco's new digital video
product
------------------------------------------------------------------------
--------
The successful applicant must have a proven track record of bringing
products to market, and should possess the following particular skills
and experience:=20
* 7-10 years of experience working as a software engineer with a hi-tech
company=20
* Experience with the bring-up of complex PC boards with advanced CPU,
DSP, and Ethernet chipsets.=20
* Experience with embedded processors (Intel, Freescale)=20
* Linux experience=20
* UBoot experience=20
* ATCA experience highly desirable=20
* Experience in managing and working with external developer resources.=20
* Demonstrated ability to successfully influence win-win
cross-functional dynamics.=20
* Applies high degree of ingenuity using broad parameters for foundation
of decisions.=20
* Makes product level decisions independently.=20
* Technical, Industry, Business and Cross-Functional Knowledge.=20
* Have outstanding communication, presentation and written skills as
well as an ability to deal effectively with both technologists and
business representatives and to sell and promote ideas across the
organization.=20
Education=20
* Requires BSEE, BSCS or equivalent training with 7-10+ yrs related exp.
Masters degree desired.
=09
Thanks and Regards
Mohamed Ali
mohamali@cisco.com
Mobile :510-402-7625
225 E Tasman Dr San Jose, CA United States
www.cisco.com=20
^ permalink raw reply
* RE: Using GDB with Abatron's BDI2000 and the ppc405 in the Xilinx VirtexII Pro
From: Wood, Robert (GE EntSol, Intelligent Platforms) @ 2008-03-13 16:55 UTC (permalink / raw)
To: Sugathan, Rupesh, linuxppc-embedded
In-Reply-To: <EE63F03D9E04774997AEBCD21FC77F251BB1CC@ccomm-ex1.ccomm.com>
[-- Attachment #1: Type: text/plain, Size: 1213 bytes --]
Thanks for the help. The archives were tedious to search but very
enlightening.
Robert Wood
Senior Engineer
GE Fanuc Intelligent Platforms
T +613 749 9241 x270
F +613 749 9461
E robert.wood@gefanuc.com
www.ge.com
5430 Canotek Road
Ottawa, Ontario
Canada K1J 9G2
General Electric Company
________________________________
From: Sugathan, Rupesh [mailto:rs@carriercomm.com]
Sent: Thursday, March 13, 2008 12:52 PM
To: Wood, Robert (GE EntSol, Intelligent Platforms);
linuxppc-embedded@ozlabs.org
Subject: RE: Using GDB with Abatron's BDI2000 and the ppc405 in the
Xilinx VirtexII Pro
We need a simple description of how to get GDB running with the BDI2000.
We have the '2000 communicating and can access the registers and like
through the telnet link but don't know how to configure the unit or GDB
to work together.
See if these helps
http://www.unimax.co.kr/unimax_2003_11/products/datasheets/ManGDBPPC-200
0C5.pdf
http://microcross.com/Debugging_Linux_Kernel.pdf
<http://microcross.com/Debugging_Linux_Kernel.pdf>
http://ultsol.com/pdfs/ <http://ultsol.com/pdfs/>
Thanks
--
Rupesh Sugathan
[-- Attachment #2: Type: text/html, Size: 9561 bytes --]
^ permalink raw reply
* Re: [U-Boot-Users] Hi, friends, the question about the u-boot and device tree?
From: Grant Likely @ 2008-03-13 19:21 UTC (permalink / raw)
To: 郭劲; +Cc: u-boot-users, support.asia, linuxppc-embedded
In-Reply-To: <405422271.18508@tsinghua.org.cn>
T24gVGh1LCBNYXIgMTMsIDIwMDggYXQgOTozMSBBTSwgufm+oiA8Z3VvamluMDJAdHNpbmdodWEu
b3JnLmNuPiB3cm90ZToKPiBIaSxmcmllbmRzLAo+Cj4gIEkgbWFrZSBhbGwgdGhlIGZyZXF1ZW5j
eSh0aW1lYmFzZS1mcmVxdWVuY3k7YnVzLWZyZXF1ZW5jeTtjbG9jay1mcmVxdWVuY3kpIHZhbHVl
Cj4gIG9uIGRldmljZSB0cmVlIGZpbGUgZXF1YWwgdG8gemVybywgSSB0aGluayB0aG9zZSBmcmVx
dWVuY3kgd2lsbCBmaWxsZWQgYnkgdS1ib290Cj4gIGR1cmluZyBib290bSwgYnV0IGluIGZhY3Qs
IHRoZSB1LWJvb3QgZGlkIG5vdCBmaWxsIGFueSBmcmVxdWVuY3kuIGFmdGVyIGJvb3RtLAo+ICBj
cmFzaGVkLiBXaHk/Cj4KPiAgV2h5IHNvIG1hbnkgZG9jdW1lbnQgcG9pbnQgb3V0IHRoYXQgdGhl
IHplcm8gdmFsdWUgd2lsbCBiZSBmaWxsZWQgYnkgdS1ib290PwoKSW4gbW9zdCBjYXNlcyBpdCB3
aWxsIGFzc3VtaW5nIHRoYXQgeW91ciB1LWJvb3QgYm9hcmQgcG9ydCBpcwpjb25maWd1cmVkIHRv
IGZpbGwgaW4gdGhvc2UgdmFsdWVzLiAgWW91IG5lZWQgdG8gbWFrZSBzdXJlIHRoYXQgdGhlCmZ0
X2JvYXJkX3NldHVwIGZ1bmN0aW9uIGlzIGdldHRpbmcgY2FsbGVkIGJ5IGJvb3RtIGFuZCB0aGF0
IGl0IGZpbGxzCmluIHRob3NlIHByb3BlcnRpZXMuCgpnLgoKLS0gCkdyYW50IExpa2VseSwgQi5T
Yy4sIFAuRW5nLgpTZWNyZXQgTGFiIFRlY2hub2xvZ2llcyBMdGQuCg==
^ permalink raw reply
* [PATCH] convert pci and eeh code to of_device_is_available
From: Nathan Lynch @ 2008-03-13 19:52 UTC (permalink / raw)
To: linuxppc-dev
A couple of places are duplicating the function of
of_device_is_available; convert them to use it.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
This depends on Josh Boyer's patch "[OF] Add of_device_is_available
function":
http://patchwork.ozlabs.org/linuxppc/patch?id=17100
arch/powerpc/kernel/rtas_pci.c | 19 ++-----------------
arch/powerpc/platforms/pseries/eeh.c | 5 ++---
2 files changed, 4 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/kernel/rtas_pci.c b/arch/powerpc/kernel/rtas_pci.c
index 433a0a0..39a752b 100644
--- a/arch/powerpc/kernel/rtas_pci.c
+++ b/arch/powerpc/kernel/rtas_pci.c
@@ -56,21 +56,6 @@ static inline int config_access_valid(struct pci_dn *dn, int where)
return 0;
}
-static int of_device_available(struct device_node * dn)
-{
- const char *status;
-
- status = of_get_property(dn, "status", NULL);
-
- if (!status)
- return 1;
-
- if (!strcmp(status, "okay"))
- return 1;
-
- return 0;
-}
-
int rtas_read_config(struct pci_dn *pdn, int where, int size, u32 *val)
{
int returnval = -1;
@@ -117,7 +102,7 @@ static int rtas_pci_read_config(struct pci_bus *bus,
for (dn = busdn->child; dn; dn = dn->sibling) {
struct pci_dn *pdn = PCI_DN(dn);
if (pdn && pdn->devfn == devfn
- && of_device_available(dn))
+ && of_device_is_available(dn))
return rtas_read_config(pdn, where, size, val);
}
@@ -164,7 +149,7 @@ static int rtas_pci_write_config(struct pci_bus *bus,
for (dn = busdn->child; dn; dn = dn->sibling) {
struct pci_dn *pdn = PCI_DN(dn);
if (pdn && pdn->devfn == devfn
- && of_device_available(dn))
+ && of_device_is_available(dn))
return rtas_write_config(pdn, where, size, val);
}
return PCIBIOS_DEVICE_NOT_FOUND;
diff --git a/arch/powerpc/platforms/pseries/eeh.c b/arch/powerpc/platforms/pseries/eeh.c
index 9eb539e..550b2f7 100644
--- a/arch/powerpc/platforms/pseries/eeh.c
+++ b/arch/powerpc/platforms/pseries/eeh.c
@@ -945,7 +945,6 @@ static void *early_enable_eeh(struct device_node *dn, void *data)
unsigned int rets[3];
struct eeh_early_enable_info *info = data;
int ret;
- const char *status = of_get_property(dn, "status", NULL);
const u32 *class_code = of_get_property(dn, "class-code", NULL);
const u32 *vendor_id = of_get_property(dn, "vendor-id", NULL);
const u32 *device_id = of_get_property(dn, "device-id", NULL);
@@ -959,8 +958,8 @@ static void *early_enable_eeh(struct device_node *dn, void *data)
pdn->eeh_freeze_count = 0;
pdn->eeh_false_positives = 0;
- if (status && strncmp(status, "ok", 2) != 0)
- return NULL; /* ignore devices with bad status */
+ if (!of_device_is_available(dn))
+ return NULL;
/* Ignore bad nodes. */
if (!class_code || !vendor_id || !device_id)
--
1.5.4.rc5
^ permalink raw reply related
* Re: [PATCH] pasemi_dma: Driver for PA Semi PWRficient on-chip DMAengine
From: Olof Johansson @ 2008-03-13 19:54 UTC (permalink / raw)
To: Dan Williams
Cc: linuxppc-dev, pasemi-linux, Nelson, Shannon, linux-kernel,
hskinnemoen
In-Reply-To: <1205255051.26723.19.camel@dwillia2-linux.ch.intel.com>
On Tue, Mar 11, 2008 at 10:04:11AM -0700, Dan Williams wrote:
> I notice that the driver does not handle callbacks in its descriptor
> cleanup path. This could be ok if your intent is only to support the
> net_dma style polled operations, but this will not work for the
> raid-offload async_tx case. I think the solution is for async_tx to
> ignore channels without the DMA_INTERRUPT capability.
Good point, and correct - I have mostly been testing this with the
NET_DMA offload. async_tx doesn't make use of just memcpy, does it?
Also, how is DMA_INTERRUPT supposed to work? I see there's a separate
"prep_dma_interrupt" function, but that doesn't make sense to me. Don't
you want the interrupt associated with a specific transaction instead
of added as a separate (empty) transaction?
Once I add the descriptor to the ring, I can't change it to set the
interrupt request bit on it. I suppose I could just add a dummy descriptor
to the ring, but that doesn't seem quite right either.
> > +static void pasemi_dma_clean(struct pasemi_dma_chan *chan)
> > +{
> > + int old, new, i;
> > + unsigned long flags;
> > + struct pasemi_dma_desc *desc;
> > + spin_lock_irqsave(&chan->desc_lock, flags);
>
> Is spin_lock_bh() insufficient here?
>
> ...that's all that jumps out at the moment.
Can't do that if it's called both from the polling as well as the IRQ
context, it'd need to hold off irqs. I.e. once I add the DMA_INTERRUPT
support it will be needed.
-Olof
^ permalink raw reply
* Re: [PATCH -mm 1/4] powerpc copy_siginfo_from_user32
From: Andrew Morton @ 2008-03-13 21:35 UTC (permalink / raw)
To: Roland McGrath; +Cc: linux-kernel, linuxppc-dev, paulus, anton, mingo, tglx
In-Reply-To: <20080313083107.8BDE926F992@magilla.localdomain>
Problems.
> Subject: [PATCH -mm 1/4] powerpc copy_siginfo_from_user32
This is advertised as a -mm patch but afacit it isn't against -mm. And it
doesn't seem to be against mainline either? At least, the fourth patch
fails to apply.
When trying to apply the fourth patch to -mm I hit a reject due to the new
BTS support in git-x86. I stopped there because the patch might be invalid
because of this.
On Thu, 13 Mar 2008 01:31:07 -0700 (PDT)
Roland McGrath <roland@redhat.com> wrote:
>
> Define the copy_siginfo_from_user32 entry point for powerpc, so
> that generic CONFIG_COMPAT code can call it. We already had the
> code rolled into compat_sys_rt_sigqueueinfo, this just moves it
> out into the canonical function that other arch's define.
>
Even though this appears to be a signal-related patch it is actually
ptrace-related, yes?
This patch is a prerequisite for "ptrace: compat_ptrace_request siginfo",
but this patch is independent from that patch (and from all others) and
hence this patch can be merged on its own into powerpc tree if we wish to go that
way, yes? (Although probably it would be better not to do it that way, for
sanity's sake).
Anwyay, please help me out with the dependencies here, and take a look at
the x86 BTS stuff?
Thanks.
^ permalink raw reply
* Re: [PATCH] Linux >=2.6.24 support for FEC on MPC5200 (not B!)
From: Grant Likely @ 2008-03-13 21:50 UTC (permalink / raw)
To: René Bürgel; +Cc: linuxppc-dev
In-Reply-To: <47D827A5.8040701@unicontrol.de>
On Wed, Mar 12, 2008 at 12:57 PM, Ren=E9 B=FCrgel <r.buergel@unicontrol.de>=
wrote:
> Here is a patch for the lite5200 to get the FEC working again for kernel
> >=3D2.6.24. It was created against Linux 2.6.24.
>
> The FEC driver is also compatible with the MPC5200, not only with the
> MPC5200B, so an according entry was added to the drivers matching list.
> Furthermore the settings for the PHY were entered in the dts file for
> the Lite5200. Note, that this is not exactly the same as in the
> Lite5200B, because the PHY is located at f0003000:01 for the 5200, and
> at :00 for the 5200B. I could test the patch on a Lite5200 and a
> Lite5200B, both booted a kernel via tftp and mounted the root via nfs
> successfully.
> I hope, you can include the patch into the official tree.
Looks good. I'll pick this one up.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Linux UIO driver cache problem in PowerPC (fix)
From: Grant Likely @ 2008-03-13 21:53 UTC (permalink / raw)
To: Hans-Jürgen Koch, Josh Boyer, linuxppc-embedded
Cc: Jean-Samuel Chenard, LKML, Greg KH
In-Reply-To: <20080313081932.4edee290@dilbert.local>
On Thu, Mar 13, 2008 at 1:19 AM, Hans-J=FCrgen Koch <hjk@linutronix.de> wro=
te:
> Am Wed, 12 Mar 2008 15:22:59 -0400
> schrieb "Jean-Samuel Chenard" <jsamch@gmail.com>:
>
> > Hi,
>
> Hi Jean-Samuel,
> thanks for your report. Please CC LKML if you find bugs like this. I
> also added Grant Likely (PPC Xilinx Virtex maintainer), as it seems to
> be a platform specific problem.
Hmmm. I'm not a memory handling expert so I don't know what's going
on here. Josh, does this look like anything that would be ppc405
related?
g.
>
> >
> > Experimenting with your userspace I/O driver on a Xilinx FPGA (PowerPC
> > 405), I was having problems when reading hardware device registers
> > mapped on my platform using the user-space mmap() call.
> >
> > After some investigation (looking at the driver/char/mspec.c file), I
> > found that preventing caching of the page in uio_mmap_physical fixed
> > my issues with userspace mmap() reading messed-up values.
>
> Hm, we already mark the page with VM_IO. That's sufficient on x86 and
> arm. I'm not sure whether this is a bug in PPC memory handling. Why do
> they cache VM_IO pages?
>
> >
> > This patch is against your initial commit of the UIO driver in the
> > mainline kernel tree.
> >
> > =3D=3D=3D=3D
> > diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
> > index 865f32b..36e1123 100644
> > --- a/drivers/uio/uio.c
> > +++ b/drivers/uio/uio.c
> > @@ -22,6 +22,7 @@
> > #include <linux/string.h>
> > #include <linux/kobject.h>
> > #include <linux/uio_driver.h>
> > +#include <asm/pgtable.h>
> >
> > #define UIO_MAX_DEVICES 255
> >
> > @@ -447,6 +448,8 @@ static int uio_mmap_physical(struct
> > vm_area_struct *vma)
> >
> > vma->vm_flags |=3D VM_IO | VM_RESERVED;
> >
> > + vma->vm_page_prot =3D pgprot_noncached(vma->vm_page_prot);
> > +
> > return remap_pfn_range(vma,
> > vma->vm_start,
> > idev->info->mem[mi].addr >> PAGE_SHIFT,
> > =3D=3D=3D=3D
> >
> > I am a bit unsure if this will break something in any of your uses of
> > the UIO driver (on other platforms than ppc), but it really fixes
> > things for me.
>
> It should be OK, but unneccesary on other platforms. I have no
> objections, but I fear in 6 months we'll see a patch removing that
> line again because it's not needed...
>
> > Let me know if you need more details on what was
> > happening on my platform before I added this statement.
>
> I'd like to hear the opinion of people really involved in PPC memory
> handling.
>
> >
> > Thanks for the great driver for user-space I/O, it will save me lots
> > of time in my research.
> >
> > Regards,
> >
> > Jean-Samuel
>
> Thanks,
> Hans
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: PPC upstream kernel ignored DABR bug
From: Segher Boessenkool @ 2008-03-13 22:20 UTC (permalink / raw)
To: Roland McGrath
Cc: linuxppc-dev, Jan Kratochvil, Paul Mackerras, Arnd Bergmann
In-Reply-To: <20080313014745.DE97826F992@magilla.localdomain>
> AFAICT the DABRX register just has two global bits that enable paying
> attention to the DABR register.
It has four bits:
01 match in user mode
02 match in supervisor mode
04 match in hypervisor mode
08 ignore translation field in DABR
If the kernel can write to DABRX, it is running in hypervisor mode, so
it should set 07 instead of 03 (as it currently does) if it wants to
match in kernel mode; or 01, if it doesn't.
OTOH, the Apple version of the 970 is special (it has no separate
hypervisor mode); still, 07 should always work.
> It only needs to be set once at boot time
> (as the cell code does). I don't see how missing that initialization
> could
> ever have explained the behavior we see where DABR matches are
> intermittent.
> If those DABRX bits weren't set then no DABR match would have happened.
> (Apparently they are set before boot on an Apple G5.)
I don't see the Apple boot code initialising DABRX; maybe the bootup
state
for DABRX is 07, dunno. Either way, it would be good if the kernel set
it
properly, esp. if it wants to enable or disable matches in the kernel
itself.
> What we actually see is that DABR matches seem to be reliable when
> things
> are slow, and get intermittent when there are enough threads with DABR
> set.
> I happened across:
>
> http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/
> 79B6E24422AA101287256E93006C957E/$file/
> PowerPC_970FX_errata_DD3.X_V1.7.pdf
>
> which is "IBM PowerPC 970FX RISC Microprocessor Errata List for DD3.X"
> and contains "Erratum #8: DABRX register might not always be updated
> correctly":
> The only machine I have at home for testing powerpc is an Apple G5,
> supplied to me by IBM. It says:
> cpu : PPC970FX, altivec supported
> revision : 3.0 (pvr 003c 0300)
> so I am guessing this document applies to the chips I have.
Indeed.
> Since I can't
> test on other chips myself, it is plausible from what I've seen that
> there
> is no mysterious kernel problem and only this hardware problem. The
> description of the hardware problem would not make me think that it
> would
> behave this way, but it is not very detailed or precise, or at least
> does
> not seem so to a reader not expert on powerpc.
Since the 970 kernel never sets DABRX currently, #8 cannot explain
_intermittent_ problems: either it always works, or never does.
You could be happening upon #5, if the non-triggering data breakpoints
are with vector loads/stores in strange code.
> I don't know what I can do next to tell whether this processor erratum
> is in
> fact what's happening in the test case. If it is, I don't know if
> there
> might be some arcane way to work around it despite "None" cited above.
It would help if you could give us the disassembly of some code where
the
breakpoint did not trigger; say, that insn and the previous 20 or so
insns.
Segher
^ permalink raw reply
* Re: [PATCH] pasemi_dma: Driver for PA Semi PWRficient on-chip DMAengine
From: Dan Williams @ 2008-03-13 22:29 UTC (permalink / raw)
To: Olof Johansson
Cc: linuxppc-dev, pasemi-linux, Nelson, Shannon, linux-kernel,
hskinnemoen
In-Reply-To: <20080313195431.GA1449@lixom.net>
On Thu, Mar 13, 2008 at 12:54 PM, Olof Johansson <olof@lixom.net> wrote:
> On Tue, Mar 11, 2008 at 10:04:11AM -0700, Dan Williams wrote:
>
> > I notice that the driver does not handle callbacks in its descriptor
> > cleanup path. This could be ok if your intent is only to support the
> > net_dma style polled operations, but this will not work for the
> > raid-offload async_tx case. I think the solution is for async_tx to
> > ignore channels without the DMA_INTERRUPT capability.
>
> Good point, and correct - I have mostly been testing this with the
> NET_DMA offload. async_tx doesn't make use of just memcpy, does it?
>
Right, it makes use of any capability it can get its hands on,
otherwise fall back to software.
> Also, how is DMA_INTERRUPT supposed to work? I see there's a separate
> "prep_dma_interrupt" function, but that doesn't make sense to me. Don't
> you want the interrupt associated with a specific transaction instead
> of added as a separate (empty) transaction?
>
Yes, and that is what happens in most cases. The additional
prep_dma_interrupt method is for two special cases:
1/ Locations where code is submitting an indeterminate number of
operations and wants an interrupt (callback) at the completion of the
chain. Someting like:
list_for_each_entry()
async_memcpy()
async_trigger_callback()
2/ For supporting channel switching on, for instance, a memcpy->xor
chain where chan1 supports memcpy and chan2 supports xor. When
async_tx sees this it injects an interrupt for chan1. The xor
operation gets kicked off by the bottom half of the chan1 interrupt
handler. However, if chan1 can do both operations no interrupt is
needed.
> Once I add the descriptor to the ring, I can't change it to set the
> interrupt request bit on it. I suppose I could just add a dummy descriptor
> to the ring, but that doesn't seem quite right either.
>
Dummy descriptors that do nothing but cause an interrupt is the intent.
>
> > > +static void pasemi_dma_clean(struct pasemi_dma_chan *chan)
> > > +{
> > > + int old, new, i;
> > > + unsigned long flags;
> > > + struct pasemi_dma_desc *desc;
> > > + spin_lock_irqsave(&chan->desc_lock, flags);
> >
> > Is spin_lock_bh() insufficient here?
> >
> > ...that's all that jumps out at the moment.
>
> Can't do that if it's called both from the polling as well as the IRQ
> context, it'd need to hold off irqs. I.e. once I add the DMA_INTERRUPT
> support it will be needed.
>
...do it in a tasklet.
>
> -Olof
>
Regards,
Dan
^ permalink raw reply
* [PATCH] [RFC] [POWERPC] Xilinx: OF Serial: add support for 8250 console
From: y @ 2008-03-13 22:29 UTC (permalink / raw)
To: linuxppc-dev; +Cc: John Linn
From: John Linn <john.linn@xilinx.com>
This change to the OF serial driver causes it to setup a console
which then gets the OF data and sets up the 8250 console. Prior to
this the uart was not setup in time for the 8250 console initialization
to work correct.
It appears that the kernel console uart depends on the bootstrap loader
to setup the uart (baud,etc.) prior to the kernel running. Without the
bootstrap loader uart working correctly, the kernel console uart doesn't
work either, is that expected?
Signed-off-by: <john.linn@xilinx.com>
---
drivers/serial/8250.c | 10 +++-
drivers/serial/of_serial.c | 115 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 123 insertions(+), 2 deletions(-)
diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c
index f94109c..d8e211e 100644
--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -2547,7 +2547,7 @@ static int serial8250_console_early_setup(void)
}
static struct uart_driver serial8250_reg;
-static struct console serial8250_console = {
+struct console serial8250_console = {
.name = "ttyS",
.write = serial8250_console_write,
.device = uart_console_device,
@@ -2558,13 +2558,19 @@ static struct console serial8250_console = {
.data = &serial8250_reg,
};
-static int __init serial8250_console_init(void)
+int __init serial8250_console_init(void)
{
serial8250_isa_init_ports();
register_console(&serial8250_console);
return 0;
}
+
+/* when OF is being used with the 8250 console, the OF hooks in the
+ 8250 console
+*/
+#if defined(CONFIG_SERIAL_8250_CONSOLE) && !defined(CONFIG_SERIAL_OF_PLATFORM)
console_initcall(serial8250_console_init);
+#endif
int serial8250_find_port(struct uart_port *p)
{
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index a64d858..c80198b 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -13,9 +13,11 @@
#include <linux/module.h>
#include <linux/serial_core.h>
#include <linux/serial_8250.h>
+#include <linux/console.h>
#include <asm/of_platform.h>
#include <asm/prom.h>
+#include <asm/io.h>
struct of_serial_info {
int type;
@@ -158,6 +160,119 @@ static void __exit of_platform_serial_exit(void)
};
module_exit(of_platform_serial_exit);
+#if defined(CONFIG_SERIAL_8250_CONSOLE) && defined(CONFIG_SERIAL_OF_PLATFORM)
+
+/* when an 8250 console is being used and OF, the OF needs to
+ setup the uart before the 8250 console initializes
+*/
+extern struct console serial8250_console;
+extern int serial8250_console_init(void);
+extern int __init early_serial_console_setup(struct uart_port *port);
+static struct uart_port of_uart_port;
+
+static struct of_device_id __devinit uart_of_match[] = {
+ { .type = "serial", .compatible = "ns16550", },
+ {},
+};
+
+/*
+ * Setup the console based on OF properties
+ */
+static int __init console_of_setup(struct device_node *np,
+ struct uart_port *port)
+{
+ struct resource resource;
+ const unsigned int *clk, *spd, *regshift;
+ int ret;
+
+ memset(port, 0, sizeof *port);
+ spd = of_get_property(np, "current-speed", NULL);
+ regshift = of_get_property(np, "reg-shift", NULL);
+ clk = of_get_property(np, "clock-frequency", NULL);
+ if (!clk) {
+ return -ENODEV;
+ }
+
+ ret = of_address_to_resource(np, 0, &resource);
+ if (ret) {
+ return ret;
+ }
+
+ spin_lock_init(&port->lock);
+ port->irq = irq_of_parse_and_map(np, 0);
+ port->iotype = UPIO_MEM;
+ port->type = PORT_16550;
+ port->uartclk = *clk;
+ port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
+ | UPF_FIXED_PORT;
+ if (spd) {
+ port->custom_divisor = *clk / (16 * (*spd));
+ }
+
+ if (regshift) {
+ port->regshift = *regshift;
+ port->mapbase = resource.start + ((1 << *regshift) - 1);
+ } else {
+ port->mapbase = resource.start;
+ }
+ return 0;
+}
+
+static struct device_node __init *console_of_find_device(int id)
+{
+ struct device_node *np;
+ const struct of_device_id *matches = uart_of_match;
+
+ while (matches->compatible[0]) {
+ for_each_compatible_node(np, NULL, matches->compatible) {
+ if (!of_match_node(matches, np))
+ continue;
+
+ of_node_put(np);
+ return np;
+ }
+ matches++;
+ }
+ return 0;
+}
+
+static int __init console_setup(struct console *co)
+{
+ struct device_node *np;
+
+ /* Find a matching uart port in the device tree */
+ np = console_of_find_device(co->index);
+ if (!np)
+ return -ENODEV;
+
+ if (console_of_setup(np, &of_uart_port))
+ return -ENODEV;
+
+ /* registers mapped yet? */
+ if (!of_uart_port.membase) {
+ of_uart_port.membase = ioremap(of_uart_port.mapbase, 256);
+ if (of_uart_port.membase)
+ return -ENODEV;
+ }
+ return 0;
+}
+
+/* This function sets up the 8250 console by getting the OF data at
+ console init time and then setting up the 8250 uart and console.
+ This solves the problem of the OF uart not being setup in time
+ for the 8250 console to use it.
+*/
+static int __init of_console_init(void)
+{
+ console_setup(&serial8250_console);
+ early_serial_setup(&of_uart_port);
+ serial8250_console_init();
+ return 0;
+}
+
+console_initcall(of_console_init);
+#endif
+
MODULE_AUTHOR("Arnd Bergmann <arnd@arndb.de>");
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Serial Port driver for Open Firmware platform devices");
--
1.5.2.1
^ permalink raw reply related
* Re: PPC upstream kernel ignored DABR bug
From: Roland McGrath @ 2008-03-13 22:42 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linuxppc-dev, Jan Kratochvil, Paul Mackerras, Arnd Bergmann
In-Reply-To: <2f8f82fe943fcd5103ec4cc39cc1bb26@kernel.crashing.org>
> Since the 970 kernel never sets DABRX currently, #8 cannot explain
> _intermittent_ problems: either it always works, or never does.
That's kind of what I thought, but I couldn't make enough sense of
the #8 text to be very sure.
> You could be happening upon #5, if the non-triggering data breakpoints
> are with vector loads/stores in strange code.
They are not.
> It would help if you could give us the disassembly of some code where the
> breakpoint did not trigger; say, that insn and the previous 20 or so insns.
The pointer to the test case was given here before.
http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/tests/ptrace-tests/tests/ppc-dabr-race.c?cvsroot=systemtap
-m32 Dump of assembler code for function child_thread:
0x10000950 <child_thread+0>: stwu r1,-32(r1)
0x10000954 <child_thread+4>: li r3,207
0x10000958 <child_thread+8>: mflr r0
0x1000095c <child_thread+12>: stw r29,20(r1)
0x10000960 <child_thread+16>: stw r0,36(r1)
0x10000964 <child_thread+20>: crclr 4*cr1+eq
0x10000968 <child_thread+24>: bl 0x10001680 <syscall>
0x1000096c <child_thread+28>: lis r11,4097
0x10000970 <child_thread+32>: mr r29,r3
0x10000974 <child_thread+36>: li r3,1
0x10000978 <child_thread+40>: lwz r9,7800(r11)
0x1000097c <child_thread+44>: addi r9,r9,1
0x10000980 <child_thread+48>: stw r9,7800(r11)
0x10000984 <child_thread+52>: bl 0x10001750 <sleep>
0x10000988 <child_thread+56>: lis r9,4097
---> 0x1000098c <child_thread+60>: stw r29,7792(r9)
0x10000990 <child_thread+64>: bl 0x10001760 <pause>
0x10000994 <child_thread+68>: bl 0x10001760 <pause>
0x10000998 <child_thread+72>: b 0x10000990 <child_thread+64>
End of assembler dump.
-m64 Dump of assembler code for function child_thread:
0x0000000010000d10 <child_thread+0>: mflr r0
0x0000000010000d14 <child_thread+4>: std r29,-24(r1)
0x0000000010000d18 <child_thread+8>: li r3,207
0x0000000010000d1c <child_thread+12>: std r0,16(r1)
0x0000000010000d20 <child_thread+16>: stdu r1,-144(r1)
0x0000000010000d24 <child_thread+20>: bl 0x10000b68
0x0000000010000d28 <child_thread+24>: ld r2,40(r1)
0x0000000010000d2c <child_thread+28>: ld r11,-32696(r2)
0x0000000010000d30 <child_thread+32>: mr r29,r3
0x0000000010000d34 <child_thread+36>: li r3,1
0x0000000010000d38 <child_thread+40>: extsw r29,r29
0x0000000010000d3c <child_thread+44>: lwz r9,0(r11)
0x0000000010000d40 <child_thread+48>: addi r9,r9,1
0x0000000010000d44 <child_thread+52>: clrldi r9,r9,32
0x0000000010000d48 <child_thread+56>: stw r9,0(r11)
0x0000000010000d4c <child_thread+60>: bl 0x10000a88
0x0000000010000d50 <child_thread+64>: ld r2,40(r1)
0x0000000010000d54 <child_thread+68>: ld r9,-32688(r2)
---> 0x0000000010000d58 <child_thread+72>: std r29,0(r9)
0x0000000010000d5c <child_thread+76>: nop
0x0000000010000d60 <child_thread+80>: bl 0x100009a8
0x0000000010000d64 <child_thread+84>: ld r2,40(r1)
0x0000000010000d68 <child_thread+88>: b 0x10000d60 <child_thread+80>
0x0000000010000d6c <child_thread+92>: .long 0x0
0x0000000010000d70 <child_thread+96>: .long 0x1
0x0000000010000d74 <child_thread+100>: lwz r0,0(r3)
End of assembler dump.
Thanks,
Roland
^ permalink raw reply
* Re: [PATCH] pasemi_dma: Driver for PA Semi PWRficient on-chip DMAengine
From: Olof Johansson @ 2008-03-13 23:14 UTC (permalink / raw)
To: Dan Williams
Cc: linuxppc-dev, pasemi-linux, Nelson, Shannon, linux-kernel,
hskinnemoen
In-Reply-To: <e9c3a7c20803131529j22db434aqdab0ef6f18891d67@mail.gmail.com>
On Thu, Mar 13, 2008 at 03:29:29PM -0700, Dan Williams wrote:
> On Thu, Mar 13, 2008 at 12:54 PM, Olof Johansson <olof@lixom.net> wrote:
> > On Tue, Mar 11, 2008 at 10:04:11AM -0700, Dan Williams wrote:
> >
> > > I notice that the driver does not handle callbacks in its descriptor
> > > cleanup path. This could be ok if your intent is only to support the
> > > net_dma style polled operations, but this will not work for the
> > > raid-offload async_tx case. I think the solution is for async_tx to
> > > ignore channels without the DMA_INTERRUPT capability.
> >
> > Good point, and correct - I have mostly been testing this with the
> > NET_DMA offload. async_tx doesn't make use of just memcpy, does it?
> >
>
> Right, it makes use of any capability it can get its hands on,
> otherwise fall back to software.
Badly worded question, but it got answered anyway. What I really meant
to as was "does async_tx use memcpy", I thought it only used xor. Good
to know.
> > Also, how is DMA_INTERRUPT supposed to work? I see there's a separate
> > "prep_dma_interrupt" function, but that doesn't make sense to me. Don't
> > you want the interrupt associated with a specific transaction instead
> > of added as a separate (empty) transaction?
> >
>
> Yes, and that is what happens in most cases. The additional
> prep_dma_interrupt method is for two special cases:
> 1/ Locations where code is submitting an indeterminate number of
> operations and wants an interrupt (callback) at the completion of the
> chain. Someting like:
> list_for_each_entry()
> async_memcpy()
> async_trigger_callback()
Ok, one could argue that it'd make more sense to have a way to issue a
memcpy (or other op) with a callback. Anyway, both methods work.
> 2/ For supporting channel switching on, for instance, a memcpy->xor
> chain where chan1 supports memcpy and chan2 supports xor. When
> async_tx sees this it injects an interrupt for chan1. The xor
> operation gets kicked off by the bottom half of the chan1 interrupt
> handler. However, if chan1 can do both operations no interrupt is
> needed.
>
> > Once I add the descriptor to the ring, I can't change it to set the
> > interrupt request bit on it. I suppose I could just add a dummy descriptor
> > to the ring, but that doesn't seem quite right either.
> >
>
> Dummy descriptors that do nothing but cause an interrupt is the intent.
Well, it'd be slightly more efficient to do add the interrupt attribute
to the last issued descriptor when it's known in advance. If the
underlying driver doesn't support it, adding a separate descriptor would
be a good fallback.
Anyway, this isn't likely to be a performance bottleneck. If it turns
out to be, I'll refactor it and submit patches.
> > > > +static void pasemi_dma_clean(struct pasemi_dma_chan *chan)
> > > > +{
> > > > + int old, new, i;
> > > > + unsigned long flags;
> > > > + struct pasemi_dma_desc *desc;
> > > > + spin_lock_irqsave(&chan->desc_lock, flags);
> > >
> > > Is spin_lock_bh() insufficient here?
> > >
> > > ...that's all that jumps out at the moment.
> >
> > Can't do that if it's called both from the polling as well as the IRQ
> > context, it'd need to hold off irqs. I.e. once I add the DMA_INTERRUPT
> > support it will be needed.
> >
>
> ...do it in a tasklet.
Why? That just adds overhead and latency.
-Olof
^ permalink raw reply
* Re: [PATCH -mm 1/4] powerpc copy_siginfo_from_user32
From: Roland McGrath @ 2008-03-13 23:36 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linuxppc-dev, paulus, anton, mingo, tglx
In-Reply-To: <20080313143510.9cfb7ab4.akpm@linux-foundation.org>
> This is advertised as a -mm patch but afacit it isn't against -mm. And it
> doesn't seem to be against mainline either? At least, the fourth patch
> fails to apply.
Oops, sorry for the bad labeling. The baseline I used was actually x86/mm.
(This was originally going to be just some x86_64 cleanups destined for
post-2.6.25, before I noticed that powerpc had issues.)
> When trying to apply the fourth patch to -mm I hit a reject due to the new
> BTS support in git-x86. I stopped there because the patch might be invalid
> because of this.
The only differences for that stuff should be to pass any new BTS requests
through to arch_ptrace as is done for e.g. PTRACE_GET_THREAD_AREA. I'll
admit I tried not to think about that since it's disabled now and still in
so much flux.
> Even though this appears to be a signal-related patch it is actually
> ptrace-related, yes?
It is a prerequisite for ptrace cleanups/fixes, yes. The change does not
affect any signals code behavior. It may also be useful for other generic
signals compat code later (though I haven't looked into that yet). I'd
call it "compat-related" really.
> This patch is a prerequisite for "ptrace: compat_ptrace_request siginfo",
> but this patch is independent from that patch (and from all others) and
> hence this patch can be merged on its own into powerpc tree if we wish to
> go that way, yes?
Yes.
> Anwyay, please help me out with the dependencies here, and take a look at
> the x86 BTS stuff?
2/4 depends on 1/4 for powerpc64 to keep building.
3/4 depends on 2/4 for x86_64 kernel's 32-bit ptrace calls to keep working.
4/4 depends on 3/4 for same.
I've become fairly confused about the various trees and the state of the
ill-fated BTS code. It's hard to figure out when it's coming and going
from where lately. But resolving the actual code bits in any conflicts
with that will be trivial.
Thanks,
Roland
^ permalink raw reply
* Re: [PATCH] pasemi_dma: Driver for PA Semi PWRficient on-chip DMAengine
From: Dan Williams @ 2008-03-14 0:06 UTC (permalink / raw)
To: Olof Johansson
Cc: linuxppc-dev, pasemi-linux, Nelson, Shannon, linux-kernel,
hskinnemoen
In-Reply-To: <20080313231442.GA4639@lixom.net>
On Thu, Mar 13, 2008 at 4:14 PM, Olof Johansson <olof@lixom.net> wrote:
> > Dummy descriptors that do nothing but cause an interrupt is the intent.
>
> Well, it'd be slightly more efficient to do add the interrupt attribute
> to the last issued descriptor when it's known in advance. If the
> underlying driver doesn't support it, adding a separate descriptor would
> be a good fallback.
>
When it is known in advance the interrupt attribute *is* set,
otherwise the descriptor may already be in flight.
> Anyway, this isn't likely to be a performance bottleneck. If it turns
> out to be, I'll refactor it and submit patches.
>
Would not hurt to have another pair of eyes on this part of the code.
A rewrite of the channel switch mechanism is currently pending in
async_tx.git#upstream.
[..]
> > > Can't do that if it's called both from the polling as well as the IRQ
> > > context, it'd need to hold off irqs. I.e. once I add the DMA_INTERRUPT
> > > support it will be needed.
> > >
> >
> > ...do it in a tasklet.
>
> Why? That just adds overhead and latency.
>
The original ioat_dma code used nothing heavier than spin_lock_bh.
Async_tx now assumes that local_bh_disable prevents races with any
channel's cleanup routine. Clients can place the same kind of code in
an async_tx callback as they would in a timer callback. The
assumption is that code using async_tx can afford its extra overhead,
which is true for raid. This is also why you don't see async_memcpy
calls in net_dma.
--
Dan
^ permalink raw reply
* Re: [U-Boot-Users] Hi, friends, the question about the u-boot and device tree?
From: 郭劲 @ 2008-03-14 1:40 UTC (permalink / raw)
To: Grant Likely; +Cc: u-boot-users, support.asia, linuxppc-embedded
Hi,friends,
I¡¡made follow define on my MPC8360EMDS.h file. Is it enough? The uboot still did
not fill the zero frequency on dtb. I think the ft_cpu_setup and ft_board_setup
function have been run.
/* pass open firmware flat tree */
#define CONFIG_OF_FLAT_TREE 1
#define CONFIG_OF_BOARD_SETUP 1
/* maximum size of the flat tree (8K) */
#define OF_FLAT_TREE_MAX_SIZE 8192
>From: "Grant Likely" <grant.likely@secretlab.ca>
>Reply-To:
>To: "¹ù¾¢" <guojin02@tsinghua.org.cn>
>Subject: Re: [U-Boot-Users] Hi, friends, the question about the u-boot and device
tree?
>Date:Thu, 13 Mar 2008 13:21:35 -0600
>
>On Thu, Mar 13, 2008 at 9:31 AM, ¹ù¾¢ <guojin02@tsinghua.org.cn> wrote:
>> Hi,friends,
>>
>> I make all the frequency(timebase-frequency;bus-frequency;clock-frequency)
value
>> on device tree file equal to zero, I think those frequency will filled by
u-boot
>> during bootm, but in fact, the u-boot did not fill any frequency. after
bootm,
>> crashed. Why?
>>
>> Why so many document point out that the zero value will be filled by u-boot?
>
>In most cases it will assuming that your u-boot board port is
>configured to fill in those values. You need to make sure that the
>ft_board_setup function is getting called by bootm and that it fills
>in those properties.
>
>g.
>
>--
>Grant Likely, B.Sc., P.Eng.
>Secret Lab Technologies Ltd.
>
^ permalink raw reply
* Re: PPC upstream kernel ignored DABR bug
From: Segher Boessenkool @ 2008-03-14 2:11 UTC (permalink / raw)
To: Roland McGrath
Cc: linuxppc-dev, Jan Kratochvil, Paul Mackerras, Arnd Bergmann
In-Reply-To: <20080313224234.0A4FB26F993@magilla.localdomain>
> The pointer to the test case was given here before.
Oh, I missed that. Anyway, I wanted to see the asm, and who knows,
with different compiler versions and all that.
> 0x10000984 <child_thread+52>: bl 0x10001750 <sleep>
> 0x10000988 <child_thread+56>: lis r9,4097
> ---> 0x1000098c <child_thread+60>: stw r29,7792(r9)
> 0x0000000010000d4c <child_thread+60>: bl 0x10000a88
> 0x0000000010000d50 <child_thread+64>: ld r2,40(r1)
> 0x0000000010000d54 <child_thread+68>: ld r9,-32688(r2)
> ---> 0x0000000010000d58 <child_thread+72>: std r29,0(r9)
In both these cases, the storage access goes to LSU0, so you're
not hitting the errata.
I noticed set_dabr() doesn't do proper synchronisation insns, could
you try this patch? I doubt it helps, but it changes the code to do
"the right thing".
diff --git a/arch/powerpc/kernel/process.c
b/arch/powerpc/kernel/process.c
index 4846bf5..ee925f5 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -250,7 +250,9 @@ int set_dabr(unsigned long dabr)
/* XXX should we have a CPU_FTR_HAS_DABR ? */
#if defined(CONFIG_PPC64) || defined(CONFIG_6xx)
+ asm("sync");
mtspr(SPRN_DABR, dabr);
+ asm("isync");
#endif
return 0;
}
(badly copy/pasted, please apply by hand. Will send a real patch later
;-) )
If this doesn't help, and the failures stay intermittent, I don't think
there
is a close-to-the-hardware problem here.
Segher
^ permalink raw reply related
* MPC8241 GPIO
From: Vincent Teoh @ 2008-03-14 3:23 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 496 bytes --]
Hi Folks,
I am using an MPC8241 and how can I access the GPIOs? I read the datasheet, the processor doesn't really have any physical GPIOs. I would like to use and configure, if possible, one of the GPIOs to drive one of the LEDs.
Thank you.
-vincent
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
[-- Attachment #2: Type: text/html, Size: 751 bytes --]
^ 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