* [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: [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
* 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
* 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
* 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
* 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
* 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
* 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: 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: 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
* [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
* [PATCH] net: NEWEMAC: Add compatible "ibm,tah" to tah matching table
From: Stefan Roese @ 2008-03-13 15:59 UTC (permalink / raw)
To: linuxppc-dev, netdev
Add "ibm,tah" to the compatible matching table of the ibm_newemac
tah driver. The type "tah" is still preserved for compatibility reasons.
New dts files should use the compatible property though.
Signed-off-by: Stefan Roese <sr@denx.de>
---
drivers/net/ibm_newemac/tah.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ibm_newemac/tah.c b/drivers/net/ibm_newemac/tah.c
index 96417ad..b023d10 100644
--- a/drivers/net/ibm_newemac/tah.c
+++ b/drivers/net/ibm_newemac/tah.c
@@ -155,6 +155,10 @@ static int __devexit tah_remove(struct of_device *ofdev)
static struct of_device_id tah_match[] =
{
{
+ .compatible = "ibm,tah",
+ },
+ /* For backward compat with old DT */
+ {
.type = "tah",
},
{},
--
1.5.4.4
^ permalink raw reply related
* Using GDB with Abatron's BDI2000 and the ppc405 in the Xilinx Virtex II Pro
From: Wood, Robert (GE EntSol, Intelligent Platforms) @ 2008-03-13 15:47 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 603 bytes --]
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: 5166 bytes --]
^ permalink raw reply
* Hi,friends, the question about the u-boot and device tree?
From: 郭劲 @ 2008-03-13 15:31 UTC (permalink / raw)
To: support.asia, linuxppc-embedded, u-boot-users
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?
^ permalink raw reply
* Re: [PATCH] ibm_newemac: emac_tx_csum typo fix.patch
From: Stefan Roese @ 2008-03-13 15:42 UTC (permalink / raw)
To: linuxppc-dev, netdev
In-Reply-To: <20080222192139.GA26126@ru.mvista.com>
On Friday 22 February 2008, Valentine Barshak wrote:
> Move the "&& skb->ip_summed == CHECKSUM_PARTIAL" part out of
> emac_has_feature parameters.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
Acked-by: Stefan Roese <sr@denx.de>
I think this is 2.6.25 material. I just stumbled over this problem too while
enabling TAH on 440GX and 460EX/GT.
Thanks.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH -mm 2/4] ptrace: compat_ptrace_request siginfo
From: Jeff Dike @ 2008-03-13 14:42 UTC (permalink / raw)
To: Roland McGrath
Cc: Thomas Gleixner, linux-kernel, linuxppc-dev, Paul Mackerras,
Anton Blanchard, Andrew Morton, Ingo Molnar
In-Reply-To: <20080313083243.E551A26F992@magilla.localdomain>
On Thu, Mar 13, 2008 at 01:32:43AM -0700, Roland McGrath wrote:
> On powerpc, this fixes a longstanding regression of 32-bit ptrace
> calls on 64-bit kernels vs native calls (64-bit calls or 32-bit
> kernels). This can be seen in a 32-bit call using PTRACE_GETSIGINFO
> to examine e.g. siginfo_t.si_addr from a signal that sets it.
> (This was broken as of 2.6.24 and, I presume, many or all prior versions.)
BTW, this also fixes a long-standing bug in x86_64 ptrace32_siginfo:
ret = sys_ptrace(request, pid, addr, (unsigned long)si);
if (ret)
return ret;
if (request == PTRACE_GETSIGINFO) {
if (copy_from_user(&ssi, si, sizeof(siginfo_t)))
return -EFAULT;
ret = copy_siginfo_to_user32(si32, &ssi);
}
si comes back with the upper bits of si_code missing, courtesy of
copy_siginfo_to_user:
err |= __put_user((short)from->si_code, &to->si_code);
causing copy_siginfo_to_user32 to not copy any fields of the union
past the first word because the upper 16 bits are used to figure out
what needs copying.
Jeff
--
Work email - jdike at linux dot intel dot com
^ permalink raw reply
* Re: Help needed to describe a custom bus in the device tree
From: Laurent Pinchart @ 2008-03-13 14:12 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20080311225427.GD7642@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 8406 bytes --]
Hi Dave,
On Tuesday 11 March 2008 23:54, David Gibson wrote:
> On Tue, Mar 11, 2008 at 03:27:26PM +0100, Laurent Pinchart wrote:
> > Hi everybody,
> >
> > the migration process from ARCH=ppc to ARCH=powerpc is easier than I
> > thought in some parts, but a few devices are still giving me
> > headaches. This should hopefully be one of my last major requests
> > for help (I'm sure most of you will be happy to see traffic on this
> > list going down when I'll be done :-))
> >
> > I'm having trouble describing a custom bus named MS bus (completely
> > unrelated to a well-known software company) in the device tree. The
> > hardware is MPC8248-based and has the following hardware topology.
> >
> > MPC8248 <-- localbus --> FPGA <-- ms bus --> Custom peripherals
> >
> > The bus interrupt controller, serial access (SPI) controller and
> > status registers are accessed through memory-mapped registers in the
> > FPGA. Parallel access to the MS bus is handled transparently by the
> > FPGA which handles address mapping.
> >
> > The FPGA is mapped on the locabus at address 0xf4000000. Bus control
> > registers are at 0xf4002000 - 0xf4003000. The parallel bus memory
> > window on the localbus is located at 0xf5000000.
> >
> > My current dts draft describes that topology as follows (unrelated
> > devices on the local bus such as flash memory are removed for
> > clarity).
> >
> > localbus@f0010100 {
> > compatible = "fsl,pq2-localbus";
> > #address-cells = <2>;
> > #size-cells = <1>;
> > reg = <f0010100 40>;
> >
> > ranges = <0 0 40000000 01000000
> > 2 0 f2000000 00100000
> > 3 0 f3000000 00100000
> > 4 0 f4000000 00100000
> > 5 0 f5000000 00100000>;
> >
> > fpga@4,0 {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > ranges = <4 0 0 00010000>;
> >
> > msbus-arbitrer@2000 {
> > compatible = "tbox,cp11-msbus-arbitrer";
> > reg = <2000 4>;
> > };
> >
> > msbus_pic: interrupt-controller@2100 {
> > compatible = "tbox,cp11-msbus-pic";
> > reg = <2100 8>;
> > interrupts = <17 2>;
> > interrupt-parent = <&cpm_pic>;
> > #interrupt-cells = <1>;
> > interrupt-controller;
> > };
> >
> > msbus-spi@2200 {
> > compatible = "tbox,cp11-msbus-spi";
> > reg = <2200 100>;
> > interrupts = <18 8>;
> > interrupt-parent = <&cpm_pic>;
> > };
> >
> > sdhc@5000 {
> > compatible = "tbox,sdhci";
> > reg = <5000 1000>;
> > interrupts = <16 8>;
> > interrupt-parent = <&cpm_pic>;
> > };
> > };
> >
> > msbus@5,0 {
> > compatible = "tbox,cp11-msbus";
> > #address-cells = <1>;
> > #size-cells = <1>;
> > #interrupt-cells = <1>;
> > reg = <5 0 0 00000400>;
> > interrupt-parent = <&msbus_pic>;
> > };
> > };
> >
> > The device tree reflects the physical topology but makes driver
> > access to the bus quite complex. An OF platform device driver
> > matching on compatible = "tbox,cp11-msbus" will not have the bus
> > FPGA registers described in its device node.
> >
> > Having a look at the various device trees included in the kernel
> > sources, it seems platforms with a PCI bus experience a similar
> > problem. To solve it the PCI bus node address and registers describe
> > the configuration registers, and the memory window to access PCI
> > devices is described by the ranges property. Applying that to my
> > custom bus would lead to the following tree.
> >
> > localbus@f0010100 {
> > compatible = "fsl,pq2-localbus";
> > #address-cells = <2>;
> > #size-cells = <1>;
> > reg = <f0010100 40>;
> >
> > ranges = <0 0 40000000 01000000
> > 2 0 f2000000 00100000
> > 3 0 f3000000 00100000
> > 4 0 f4000000 00100000
> > 4 1 f4002000 00000100
> > 5 0 f5000000 00100000>;
> >
> > fpga@4,0 {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > ranges = <4 0 0 00010000>;
> >
> > msbus_pic: interrupt-controller@2100 {
> > compatible = "tbox,cp11-msbus-pic";
> > reg = <2100 8>;
> > interrupts = <17 2>;
> > interrupt-parent = <&cpm_pic>;
> > #interrupt-cells = <1>;
> > interrupt-controller;
> > };
> >
> > msbus-spi@2200 {
> > compatible = "tbox,cp11-msbus-spi";
> > reg = <2200 100>;
> > interrupts = <18 8>;
> > interrupt-parent = <&cpm_pic>;
> > };
> >
> > sdhc@5000 {
> > compatible = "tbox,sdhci";
> > reg = <5000 1000>;
> > interrupts = <16 8>;
> > interrupt-parent = <&cpm_pic>;
> > };
> > };
> >
> > msbus@4,1 {
> > compatible = "tbox,cp11-msbus";
> > #address-cells = <1>;
> > #size-cells = <1>;
> > #interrupt-cells = <1>;
> > reg = <4 1 4>;
> > interrupt-parent = <&msbus_pic>;
> > ranges = <5 0 0 00000400>;
> > };
> > };
> >
> > Is this correct ? Is that the best way to describe my custom bus in
> > the device tree ?
>
> Your second example looks closer to right. Certainly you should use
> 'reg' only for bus control registers, and 'ranges' for windows into
> the bus address space itself.
Ok.
> The device tree describes hardware from a functional point of view, so
> I don't know that it's relevant that all the bus control functions are
> implemented in an FPGA. Each of the subnodes are more-or-less
> independent devices, so they could just have separate nodes.
>
> Or, if this seems more sensible, you could decide that they're
> sufficiently closely related to put them all as one node, with
> multiple register blocks listed in the 'reg' property. That would
> probably get messy for your PIC at the very least though.
I suppose I could implement PIC support in the bus driver itself, but having
separate nodes with separate OF devices and separate drivers seems cleaner to
me (although it can make dependencies a bit more difficult to handle).
> > How would the relationships between the bus and
> > its PIC and SPI controller be handled in the drivers ?
>
> If the msbus driver needs to work with the associated PIC and SPI
> controllers, then you should put properties in the msbus node giving
> their phandles.
The PIC can live pretty much by itself, but the SPI controller is used to
enumerate devices on the bus (and perform some other tasks at runtime). I
plan to have the SPI device and driver be self-contained, and have the bus
node reference the SPI device through its phandle. I will just have to make
sure the bus driver is initialised after the SPI driver.
> > I also don't
> > understand how interrupt mappings are supposed to be handled. PCI
> > busses have two CPM interrupt lines, one for the PCI PIC and one for
> > the PCI bus, with the PCI bus having the CPM PIC as its interrupt
> > controller. My bus PIC uses a single interrupt line. Is there some
> > documentation explaining how PICs and interrupt mappings should be
> > described ?
>
> Are interrupts from devices on the msbus routed over the msbus, or are
> they routed independently to the mspic or the cpm PIC?
There is a single active low interrupt line on the msbus. When the mspic
detects an interrupt condition, it will read the interrupt source registers
from all devices on the bus and generate a host interrupt to the cpm PIC. The
mspic driver then process the CPM interrupt in its demux handler, reads the
interrupt sources from the mspic registers and dispatch the interrupts to the
msbus device drivers.
If I understand things correctly, the mspic node should have an 'interrupts'
attribute describing the cascaded interrupt line (mspic -> cpm PIC irq), and
the msbus node should have an 'interrupts' attribute describing the interrupt
line used to report bus-related events (hotplug events for instance). Is that
right ?
To make things a bit more complex, the msbus interrupt and the bus-related
events interrupt share the same CPM irq line. Can I use the same virq number
in both nodes, or do I have to demux the interrupts in a separate driver ? If
I have to demux the interrupts in a separate PIC driver, how do I know what
virtual irq number will be assigned to each device so that I can reference
them in the device tree ?
Thanks a lot for your help.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Interrupt handling documentation
From: Laurent Pinchart @ 2008-03-13 13:56 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1205283088.7544.8.camel@concordia.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1767 bytes --]
Hi Michael,
On Wednesday 12 March 2008 01:51, Michael Ellerman wrote:
> On Tue, 2008-03-11 at 11:58 +0100, Laurent Pinchart wrote:
> > Hi everybody,
> >
> > is there any documentation describing interrupt handling for the powerpc
> > architecture ? I'm writing a driver for a cascaded interrupt controller
> > and the only source of information I found was the code.
>
> I don't think there's much documentation.
I feared so :-)
> You might want to look at arch/powerpc/platforms/cell/axon_msi.c, it's a
> reasonably simple example of how to setup an irq_host and so on - well I
> think so :D
Thanks for the pointer.
> > I'm particularly interested in information about irq hosts (allocation
> > and initialisation, especially the map and unmap callbacks) and irq
> > chaining. Different drivers seem to implement cascaded irqs differently
> > (for instance arch/powerpc/sysdev/uic.c uses setup_irq to register the
> > cascaded irq handler, while arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
> > uses set_irq_chained_handler) so I'm a bit lost here.
>
> uic.c uses set_irq_chained_handler() now, so that probably answers that
> question. I don't think it makes all that much difference if you set it
> up by hand, but set_irq_chained_handler() is the neat way to do it.
That pretty much answers my question. It's always a bit disturbing when
different drivers use different APIs to accomplish the same task, especially
when the lack of documentation doesn't clearly state which API should be used
and which API is internal/deprecated.
Thanks for your answer.
Cheers,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: PPC upstream kernel ignored DABR bug
From: Luis Machado @ 2008-03-13 13:13 UTC (permalink / raw)
To: Jens Osterkamp
Cc: linuxppc-dev, Paul Mackerras, Roland McGrath, Arnd Bergmann,
Jan Kratochvil
In-Reply-To: <200803122330.36905.jens@de.ibm.com>
On Wed, 2008-03-12 at 23:30 +0100, Jens Osterkamp wrote:
> > Just to make sure, i tested the binary against the 2.6.25-rc4 kernel. It
> > still fails. So this is really an open bug for PPC.
>
> On a Cell- or 970-based machine ?
>
> Gruß,
> Jens
On a 970-based machine.
Regards,
--
Luis Machado
Software Engineer
IBM Linux Technology Center
^ permalink raw reply
* Re: [BUG] 2.6.25-rc5-mm1 kernel panic with "Exception: 501 " on powerpc
From: Kamalesh Babulal @ 2008-03-13 13:02 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: linux-kernel, linuxppc-dev, Andrew Morton, pbadari
In-Reply-To: <20080312223300.GE613@parisc-linux.org>
Matthew Wilcox wrote:
> On Thu, Mar 13, 2008 at 09:26:09AM +1100, Michael Ellerman wrote:
>> down() looks OK, but there's still a spin_lock_irq() in __down_common(),
>> although I don't know if it makes sense for us to be in __down() at that
>> stage.
>
> The spin_lock_irq in __down_common is correct. We're going to schedule(),
> so we spin_unlock_irq() to save us passing the flags into the helper
> function. If we had interrupts disabled on entry, there's an Aieee
> for that.
>
Hi All,
Sorry for all the noise made :-(, something wrong in the test setup from my end,
the kernel was 2.6.25-rc3-mm1 not 2.6.25-rc5-mm1. This bug is not seen in the
2.6.25-rc5-mm1 kernel.
--
Thanks & Regards,
Kamalesh Babulal,
^ permalink raw reply
* Re: Driver for Freescale Display Interface Unit (A LCD controller)
From: Geert Uytterhoeven @ 2008-03-13 10:17 UTC (permalink / raw)
To: York Sun
Cc: Linux/PPC Development, Linux Frame Buffer Device Development,
Linux Kernel Development
In-Reply-To: <12053582234100-git-send-email-yorksun@freescale.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1007 bytes --]
On Wed, 12 Mar 2008, York Sun wrote:
> The following patches are for Freescale DIU. The first patch is a DIU driver.
> The second patch is the platform code to support the driver. It is a frame
> buffer driver for DIU. Descriptions can be found in the patches.
>
> It is a new feature targeting 2.6.26 kernel.
Please CC linux-fbdev-devel@lists.sourceforge.net when submitting new frame
buffer device drivers. Thx!
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: [PATCH] ppc: Export empty_zero_page
From: Christoph Hellwig @ 2008-03-13 10:12 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: linuxppc-dev
In-Reply-To: <E1JZGwo-0000vf-2v@closure.thunk.org>
On Tue, Mar 11, 2008 at 10:44:06PM -0400, Theodore Ts'o wrote:
> Stephen Rothwell discovered this issue in the linux-next tree:
>
> >Today's powerpc allmodconfig build of linux-next failed with:
> >
> >ERROR: "empty_zero_page" [fs/ext4/ext4dev.ko] undefined!
> >
> >This is because commit dde5f2130096f8469eb1aa1ad250cd2a39fee3f5 ("ext4:
> >ENOSPC error handling for writing to an uninitialized extent") uses
> >ZERO_PAGE() which on powerpc uses empty_zero_page which is not
> >EXPORT_SYMBOLed on powerpc. I have reverted that commit and a later
> >one (1ae53f35fea49a9013353078e019469551d2ad74 "ext4: zero out
> >small extents when writing to prealloc area.") which depended on it.
>
> Any chance you could get this pushed to Linus ASAP? It would be nice if
> this could get pushed before the merge window, since it could be argued
> that rationalizing whether or not empty_zero_page is exported is a bug
> fix, and anyway this is pretty much a zero-risk patch. Thanks!!
The real fix is that ext4 shouldn't be using ZERO_PAGE(). Please use
the same zeroing helpers all the other filesystems and drivers use.
^ permalink raw reply
* RE: fsldma seems to be buggy, noticed in loop mode
From: Zhang Wei @ 2008-03-13 9:23 UTC (permalink / raw)
To: Sebastian Siewior; +Cc: linuxppc-embedded
In-Reply-To: <20080313092008.GA17404@Chamillionaire.breakpoint.cc>
> -----Original Message-----
> From: Sebastian Siewior [mailto:linuxppc-embedded@ml.breakpoint.cc]=20
>=20
> * Zhang Wei | 2008-03-13 17:17:31 [+0800]:
>=20
> >Just after you reported. :)
> okey. Do you want me to add a tested by on lkml?
>=20
it's my pleasure!
Thanks!
Wei
^ permalink raw reply
* Re: fsldma seems to be buggy, noticed in loop mode
From: Sebastian Siewior @ 2008-03-13 9:20 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-embedded
In-Reply-To: <ABF87B0B6A38C0458E319AC973ED68AED32E67@zch01exm26.fsl.freescale.net>
* Zhang Wei | 2008-03-13 17:17:31 [+0800]:
>Just after you reported. :)
okey. Do you want me to add a tested by on lkml?
>
>Cheers!
>Wei.
Sebastian
^ permalink raw reply
* RE: fsldma seems to be buggy, noticed in loop mode
From: Zhang Wei @ 2008-03-13 9:17 UTC (permalink / raw)
To: Sebastian Siewior; +Cc: linuxppc-embedded
In-Reply-To: <20080313091308.GA17132@Chamillionaire.breakpoint.cc>
> -----Original Message-----
> From: Sebastian Siewior [mailto:linuxppc-embedded@ml.breakpoint.cc]=20
>=20
> * Zhang Wei | 2008-03-13 15:03:54 [+0800]:
>=20
> >Could you please apply these two patches and test again?
> >
> >http://lkml.org/lkml/2008/3/10/64
> >http://lkml.org/lkml/2008/3/13/36
> Ui, that fast. Did you find this on your own or after me=20
> reporting that
> bug?
> It solves my FIFO problem, thanks.
>=20
Just after you reported. :)
Cheers!
Wei.
^ 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