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 wrot
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.
Sign
On Wed, 15 Apr 2009 00:48:08 +0200, Andreas Schwab wrote:
> Jean Delvare 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.
> >
> > Than
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
Date: Tue, 14 Apr 2009 15:45:07 +0200
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 00:00:
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, only
From: Markus Brunner
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 will call
> dev_kfree_skb_any(NUL
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 s
On Tue, 14 Apr 2009 23:59:59 +0200, Johannes Berg wrote:
> Hi Jean,
>
> > Thanks for the quick test and sorry that it didn't work. I'll take a
> > look at the trace below and try to figure out what went wrong.
>
> No worries, seems some error path is going wrong but I can't see what it
> is right
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
Cc: Johannes Berg
Cc: Benjamin Herrenschmidt
Tested-by: Andreas Schwab
---
Johannes, this is a reworked patch which assumes that the onyx codec
probi
On Wed, Apr 15, 2009 at 1:23 PM, Zhivko Yordanov wrote:
> 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 alrea
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
> Cc: Johannes Berg
> Cc: Benjamin Herrenschmidt
> Tested-by: Andreas Schwab
> ---
> J
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 -- t
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.
> > > (...)
>
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,
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
> > Cc: Johannes Berg
On Tue, Apr 14, 2009 at 2:08 PM, John Linn 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" though it can
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:
http://ozlabs.org/pipermail/devicetree-discuss/20
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
---
arch/powerpc/boot/dts/mpc832x_mds.dts |1 -
arch/powerpc/boot/dts/mpc832
On Wed, Apr 15, 2009 at 9:40 AM, Kumar Gala 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
Acked-by: Grant Likely
> --
From: Ted Peters
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
The p2020 DS reference boa
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?
- k
___
Linuxppc-dev mailing list
Linuxpp
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 slow
On Wed, Apr 15, 2009 at 10:49 AM, Kumar Gala 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 (!machine_is(mpc86xx_hpcn) && !mach
On Wed, Apr 15, 2009 at 9:58 AM, Stephen Neuendorffer
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 core is
> > - 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 initi
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 f
On Apr 15, 2009, at 10:59 AM, Timur Tabi wrote:
On Wed, Apr 15, 2009 at 10:49 AM, Kumar Gala > 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;
> -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
>
> 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
> * an
On Wed, Apr 15, 2009 at 10:44 AM, Stephen Neuendorffer
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;
>> linux-fbdev-de...@lists.
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 t
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
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",
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
[mailto:linuxppc-dev-bounces+tmarri=amcc.
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
---
arch/powerpc/platforms/fsl_uli1575.c | 22 --
1 fil
On Mar 31, 2009, at 3:27 AM, Grant Likely wrote:
From: Grant Likely
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 device tree descriptions o
On Mon, 13 Apr 2009 14:05:13 +0800
Harry Ciao 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 add a fixup routine f
On Mon, 13 Apr 2009 14:05:14 +0800
Harry Ciao 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:
---
a/drivers/edac/cpc925_edac.c~edac-add-cpc925-memo
On Mon, 13 Apr 2009 14:05:15 +0800
Harry Ciao 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 structures should be taken care
On Mar 31, 2009, at 3:27 AM, Grant Likely wrote:
From: Grant Likely
This patch simplifies the driver by making use of more common code.
Signed-off-by: Grant Likely
---
drivers/net/gianfar.c | 103 +
+---
drivers/net/gianfar.h |3 +
2 files c
Other than the previous comments, all appropriate patches can be marked:
Acked-by: Andy Fleming
___
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,
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 o
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
---
arch/powerpc/kernel/prom_init.c | 40 ++
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
