On Apr 14, 2009, at 10:31 PM, Paul Mackerras wrote:
Kumar Gala writes:
Please pull from 'merge' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git merge
Thanks, pulled. I'll collect up a few more patches for .30 and send
Linus a pull request shortly.
By the
Ben,
I was looking at what I need to get some additional bits of PCI code
building w/your ppc64 booke patches. One thing it looks like we need
is the early config cycle code. The question I have is do we think we
still need the null_ops support? Also do we think we every get called
Mike Mason writes:
diff --git a/arch/powerpc/platforms/pseries/eeh_driver.c
b/arch/powerpc/platforms/pseries/eeh_driver.c
index 380420f..9a2a6e3 100644
--- a/arch/powerpc/platforms/pseries/eeh_driver.c
+++ b/arch/powerpc/platforms/pseries/eeh_driver.c
@@ -182,6 +182,8 @@ static void
Hi Paul,
On Wed, 15 Apr 2009 14:57:30 +1000, Paul Mackerras wrote:
Jean Delvare writes:
The legacy i2c binding model is going away soon,
But not before 2.6.30, right?
Ideally, yes, before 2.6.30. This is what
Documentation/feature-removal-schedule.txt says:
---
I'd like to understand the implications of this bug.
Obviously applications using the futex system can be affected, but
does anybody know whether GNU software packages suffer from this problem.
I mean glibc (nptl) uses futexes, so does gdb and gcc. will this bug hurt
them ?
Paul Mackerras
After a transmit timed out, the reset task will be called, which will free the
allocated resources(stop_gfar). If gfar_poll will be called before the
resources get allocated again gfar_clean_tx_ring will call
dev_kfree_skb_any(NULL).
This Patch calls netif_stop_queue before calling stop_gfar.
On Wed, 15 Apr 2009 00:48:08 +0200, Andreas Schwab wrote:
Jean Delvare kh...@linux-fr.org writes:
Hi Johannes,
On Tue, 14 Apr 2009 19:41:55 +0200, Johannes Berg wrote:
Alright, with the patch Andreas pointed out it loads, but segfaults, as
below. Works fine without your patch.
Hi,
This is an updated version of the patch which takes into account a few changes
suggested by Grant which I forgot to add.
Regards,
Roderick Colenbrander
From 2b34a315b18834448c0a8218d4da85ffaf76039e Mon Sep 17 00:00:00 2001
From: Roderick Colenbrander thunderbir...@gmail.com
Date: Tue, 14
Hi,
This is an updated version of my patch from yesterday it contains some fixes. I
had some c++ style comments
left in my previous version of this patch and there was a small error in the
dts file.
Regards,
Roderick Colenbrander
From 018041061bc233c09340eff20fcd4e8bc75da1d3 Mon Sep 17
Linus,
Please pull from the 'merge' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get a collection of bug fixes, a documentation update and a
defconfig update for powerpc.
The commit from Hugh Dickins is not strictly a bugfix, but it is
small, obvious,
From: Markus Brunner super.firetwis...@googlemail.com
Date: Wed, 15 Apr 2009 09:51:23 +0200
After a transmit timed out, the reset task will be called, which will free the
allocated resources(stop_gfar). If gfar_poll will be called before the
resources get allocated again gfar_clean_tx_ring
Hello,
I'm on designing of a new embedded board, based on mpc6841d and South Bridge
ULi M1575. As а reference design, I use Freescale HPCN board. However after
consult with chip's distributor, it became clear that the M1575 is already
discounted. Now I'm in looking of an another solution. Can
The legacy i2c binding model is going away soon, so convert the AOA
codec drivers to the new model or they'll break.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Johannes Berg johan...@sipsolutions.net
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Tested-by: Andreas Schwab
Hi,
Because the device-tree is broken -- there are two nodes for the same
device, and only one of them can be used. Then the fabric rejects the
first instantiation from the broken node. Here's how it looks normally:
...
[ 10.398296] snd-aoa-codec-onyx: found pcm3052
[
I have just started to add PCI support to our custom MPC832x board
and I have a hard time figuring out how to describe this in the
dts. Looking at mpc832x_mds.dts I see:
pci0: p...@e0008500 {
cell-index = 1;
interrupt-map-mask = 0xf800 0x0 0x0 0x7;
On Wed, 2009-04-15 at 14:22 +0200, Jean Delvare wrote:
The legacy i2c binding model is going away soon, so convert the AOA
codec drivers to the new model or they'll break.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Johannes Berg johan...@sipsolutions.net
Cc: Benjamin Herrenschmidt
On Wed, 15 Apr 2009 14:52:14 +0200, Johannes Berg wrote:
OK, I understand better what is going on now. I do not understand the
crash at the end though, but I suspect it isn't a bug in my code but
simply a faulty error path which had never been taken before.
That would be weird -- the
On Wed, Apr 15, 2009 at 02:54:57PM +0200, Joakim Tjernlund wrote:
dts fragment correct for my setup? If not, is there a better example I can
look at?
Maybe this message/thread can help you:
http://ozlabs.org/pipermail/devicetree-discuss/2009-March/000597.html
--
Pengutronix e.K.
On Wed, 2009-04-15 at 15:06 +0200, Jean Delvare wrote:
That would be weird -- the error path _has_ to be taken always in onyx.
Unless you're talking about something in the i2c core or whatever?
Yes, i2c core or even driver core. I'll see if I can reproduce it.
Alright.
(...)
Well,
On Wed, 15 Apr 2009 15:18:10 +0200, Johannes Berg wrote:
On Wed, 2009-04-15 at 15:06 +0200, Jean Delvare wrote:
Yes, i2c core or even driver core. I'll see if I can reproduce it.
Alright.
Hmm, couldn't reproduce it. Maybe it is fixed in rc2. I don't have too
much time to spend on this, so
On Wed, 15 Apr 2009 15:00:44 +0200, Johannes Berg wrote:
On Wed, 2009-04-15 at 14:22 +0200, Jean Delvare wrote:
The legacy i2c binding model is going away soon, so convert the AOA
codec drivers to the new model or they'll break.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc:
On Tue, Apr 14, 2009 at 2:08 PM, John Linn john.l...@xilinx.com wrote:
Added support for the new xps tft controller. The new core
has PLB interface support in addition to existing DCR interface.
Good looking patch. A few more comments below.
g.
/*
* Xilinx calls it PLB TFT LCD Controller
On Apr 15, 2009, at 8:08 AM, Wolfram Sang wrote:
On Wed, Apr 15, 2009 at 02:54:57PM +0200, Joakim Tjernlund wrote:
dts fragment correct for my setup? If not, is there a better
example I can
look at?
Maybe this message/thread can help you:
The cell-index property isn't used on PCI nodes and is ill defined.
Remove it for now and if someone comes up with a good reason and
consistent definition for it we can add it back
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/mpc832x_mds.dts |1 -
On Wed, Apr 15, 2009 at 9:40 AM, Kumar Gala ga...@kernel.crashing.org wrote:
The cell-index property isn't used on PCI nodes and is ill defined.
Remove it for now and if someone comes up with a good reason and
consistent definition for it we can add it back
Signed-off-by: Kumar Gala
From: Ted Peters ted.pet...@freescale.com
The P2020 is a dual e500v2 core based SOC with:
* 3 PCIe controllers
* 2 General purpose DMA controllers
* 2 sRIO controllers
* 3 eTSECS
* USB 2.0
* SDHC
* SPI, I2C, DUART
* enhanced localbus
* and optional Security (P2020E) security w/XOR acceleration
Adds support for the unused page hint which can be used in shared
memory partitions to flag pages not in use, which will then be stolen
before active pages by the hypervisor when memory needs to be moved to
LPARs in need of additional memory. Failure to mark pages as 'unused'
makes the LPAR
On Wed, Apr 15, 2009 at 10:49 AM, Kumar Gala ga...@kernel.crashing.org wrote:
--- a/arch/powerpc/platforms/fsl_uli1575.c
+++ b/arch/powerpc/platforms/fsl_uli1575.c
@@ -57,7 +57,7 @@ static void __devinit early_uli5249(struct pci_dev *dev)
unsigned char temp;
if
On Wed, Apr 15, 2009 at 9:58 AM, Stephen Neuendorffer
stephen.neuendorf...@xilinx.com wrote:
- rc = of_address_to_resource(op-node, 0, res);
- if (rc) {
- dev_err(op-dev, invalid address\n);
- return rc;
+ /*
+ * To check whether the
- rc = of_address_to_resource(op-node, 0, res);
- if (rc) {
- dev_err(op-dev, invalid address\n);
- return rc;
+ /*
+ * To check whether the core is connected directly to DCR or PLB
+ * interface and initialize the
On Wed, Apr 15, 2009 at 10:54:40AM -0500, Kumar Gala wrote:
Vitaly, Anton
You guys have used this code.. I was wondering how we decide to used the
fixed phy vs another phy. Is this a runtime decision based on something
in the device tree or purely at compile time?
It's specified via
On Apr 15, 2009, at 10:59 AM, Timur Tabi wrote:
On Wed, Apr 15, 2009 at 10:49 AM, Kumar Gala ga...@kernel.crashing.org
wrote:
--- a/arch/powerpc/platforms/fsl_uli1575.c
+++ b/arch/powerpc/platforms/fsl_uli1575.c
@@ -57,7 +57,7 @@ static void __devinit early_uli5249(struct
pci_dev *dev)
-Original Message-
From: Grant Likely [mailto:grant.lik...@secretlab.ca]
Sent: Wednesday, April 15, 2009 9:03 AM
To: Stephen Neuendorffer
Cc: John Linn; jwbo...@linux.vnet.ibm.com;
linux-fbdev-de...@lists.sourceforge.net; linuxppc-
d...@ozlabs.org; akonova...@ru.mvista.com;
On Wed, Apr 15, 2009 at 10:49:24AM -0500, Kumar Gala wrote:
From: Ted Peters ted.pet...@freescale.com
The P2020 is a dual e500v2 core based SOC with:
* 3 PCIe controllers
* 2 General purpose DMA controllers
* 2 sRIO controllers
* 3 eTSECS
* USB 2.0
* SDHC
* SPI, I2C, DUART
* enhanced
On Wed, Apr 15, 2009 at 10:44 AM, Stephen Neuendorffer
stephen.neuendorf...@xilinx.com wrote:
-Original Message-
From: Grant Likely [mailto:grant.lik...@secretlab.ca]
Sent: Wednesday, April 15, 2009 9:03 AM
To: Stephen Neuendorffer
Cc: John Linn; jwbo...@linux.vnet.ibm.com;
On Apr 15, 2009, at 11:17 AM, Anton Vorontsov wrote:
On Wed, Apr 15, 2009 at 10:54:40AM -0500, Kumar Gala wrote:
Vitaly, Anton
You guys have used this code.. I was wondering how we decide to
used the
fixed phy vs another phy. Is this a runtime decision based on
something
in the device
On Apr 15, 2009, at 11:50 AM, Anton Vorontsov wrote:
Sorry for bringing this up again... But can we decide on soc's
compatible scheme and finally remove the device_type = soc
for new boards? fsl,p2020-soc, fsl,soc, simple-bus maybe?
Thanks,
We can, but I don't want to couple the two
On Wed, Apr 15, 2009 at 12:20:14PM -0500, Kumar Gala wrote:
On Apr 15, 2009, at 11:17 AM, Anton Vorontsov wrote:
On Wed, Apr 15, 2009 at 10:54:40AM -0500, Kumar Gala wrote:
Vitaly, Anton
You guys have used this code.. I was wondering how we decide to used
the
fixed phy vs another phy.
On Wed, Apr 15, 2009 at 12:22:48PM -0500, Kumar Gala wrote:
On Apr 15, 2009, at 11:50 AM, Anton Vorontsov wrote:
Sorry for bringing this up again... But can we decide on soc's
compatible scheme and finally remove the device_type = soc
for new boards? fsl,p2020-soc, fsl,soc, simple-bus
Some debuggers like BDI(Abatron) they setup the debug registers. If you
have different debugger which doesn't support configuring debug
registers I suggest you to program then in the head_44x.S file.
From: linuxppc-dev-bounces+tmarri=amcc@ozlabs.org
Refactor the check to determine if the quirk is applicable to the boards
into one inline function so we only have to change one place to add more
boards that the quirks might be applicable to.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/platforms/fsl_uli1575.c | 22
On Mar 31, 2009, at 3:27 AM, Grant Likely wrote:
From: Grant Likely grant.lik...@secretlab.ca
Add phy_connect_direct() and phy_attach_direct() functions so that
drivers can use a pointer to the phy_device instead of trying to
determine
the phy's bus_id string.
This patch is useful for OF
On Mon, 13 Apr 2009 14:05:13 +0800
Harry Ciao qingtao@windriver.com wrote:
Hi Doug and Michael,
This is the latest v2 patches, the 1/3 of CPC925 MC EDAC driver remains
the same as before, the 2/3 has been pushed to Andrew already, and the
3/3 has integrated Michael's suggestions to
On Mon, 13 Apr 2009 14:05:14 +0800
Harry Ciao qingtao@windriver.com wrote:
Introduce IBM CPC925 EDAC driver, which makes use of ECC, CPU and
HyperTransport Link error detections and corrections on the IBM
CPC925 Bridge and Memory Controller.
A wee cleanup:
---
On Mon, 13 Apr 2009 14:05:15 +0800
Harry Ciao qingtao@windriver.com wrote:
Add edac_device_alloc_index(), because for MAPLE platform there may
exist several EDAC driver modules that could make use of
edac_device_ctl_info structure at the same time. The index allocation
for these
On Mar 31, 2009, at 3:27 AM, Grant Likely wrote:
From: Grant Likely grant.lik...@secretlab.ca
This patch simplifies the driver by making use of more common code.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
drivers/net/gianfar.c | 103 +
Other than the previous comments, all appropriate patches can be marked:
Acked-by: Andy Fleming aflem...@freescale.com
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Apr 15, 2009, at 5:27 PM, a...@linux-foundation.org wrote:
The patch titled
edac: cpc925 MC platform device setup
has been added to the -mm tree. Its filename is
edac-cpc925-mc-platform-device-setup.patch
Before you just go and hit reply, please:
a) Consider who else should be
Kumar Gala wrote:
On Apr 15, 2009, at 5:27 PM, a...@linux-foundation.org wrote:
The patch titled
edac: cpc925 MC platform device setup
has been added to the -mm tree. Its filename is
edac-cpc925-mc-platform-device-setup.patch
Before you just go and hit reply, please:
a) Consider
On Thu, 2009-04-16 at 09:57 +0800, Harry Ciao wrote:
Kumar Gala wrote:
On Apr 15, 2009, at 5:27 PM, a...@linux-foundation.org wrote:
arch/powerpc/kernel/prom_init.c | 33 +
arch/powerpc/platforms/maple/setup.c | 59 +
2 files changed, 92
Michael Ellerman wrote:
On Thu, 2009-04-16 at 09:57 +0800, Harry Ciao wrote:
Kumar Gala wrote:
On Apr 15, 2009, at 5:27 PM, a...@linux-foundation.org wrote:
arch/powerpc/kernel/prom_init.c | 33 +
arch/powerpc/platforms/maple/setup.c | 59
Sachin Sant wrote:
Sachin Sant wrote:
Benjamin Herrenschmidt wrote:
On Tue, 2009-03-31 at 14:57 +0530, Sachin Sant wrote:
While executing CPU HotPlug[1] tests i observed that during
every cpu offline process an exception is thrown.
Looks like a BUG_ON() to me... can you look at what
Fixup the number of cells for the values of CPC925 Memory Controller,
and setup related platform device during system booting up, against
which CPC925 Memory Controller EDAC driver would be matched.
Signed-off-by: Harry Ciao qingtao@windriver.com
---
arch/powerpc/kernel/prom_init.c |
Hi Andrew and Michael,
This is the modified 3/3 patch that corrects CPC925 memory controller DTB node
on Maple and setup related platform device for CPC925 EDAC driver. Michael's
suggestion of being more discernible for the Maple platform only has been
adopted.
v2 1/3 2/3 patches have been
54 matches
Mail list logo
