Hello all：
We use the AMCC PowerPC 405ex through emac1 way RGMII with realtek RTL8211 Giga
phy linked to, At present the PHY Address is: 00110
add delay 2ns for RGMII
CONFIG[8:5]:AUTO_Negotiation
=NWay,advertise ，all capabilities,prefer Slave
mode;1=RGMII mode
Clk on the hardware no
Sachin P. Sant wrote:
sure if this is a new problem or a recurring one. Will try booting
some older kernels on this box and will report the results.
I tried few older kernels till 2.6.28 and all of them had the
same problem.
I also tried using SLUB instead of SLAB. That also failed to
boot
On Mon, 9 Mar 2009, Geoff Levand wrote:
On 03/09/2009 06:26 AM, Geert Uytterhoeven wrote:
Create a real RTC driver for PS3, and unhook the deprecated
ppc_md.[gs]et_rtc_time.
8 files changed, 132 insertions(+), 18 deletions(-)
Sorry, I hadn't been following the discussion closely, but
On Tue, 10 Mar 2009 10:21:14 +0100 (CET)
Geert Uytterhoeven geert.uytterhoe...@sonycom.com wrote:
Alessandro prefers not to have generic RTC drivers on top of some other
abstraction, but wants platform/chip-specific drivers under drivers/rtc/
instead. The goal is to convert all RTC drivers
On Tue, Mar 10, 2009 at 11:36:15AM +1100, Benjamin Herrenschmidt wrote:
On Mon, 2009-03-09 at 20:05 -0400, Josh Boyer wrote:
[cfffb830] [c05fe504] .mutex_lock_nested+0x78/0x4b0
(unreliable)
[cfffb950] [c039d520] .echo_char_raw+0x40/0x98
[cfffb9f0]
On Tue, Mar 10, 2009 at 11:36:41AM +0530, Sachin P. Sant wrote:
Sachin P. Sant wrote:
sure if this is a new problem or a recurring one. Will try booting
some older kernels on this box and will report the results.
I tried few older kernels till 2.6.28 and all of them had the
same problem.
While booting Next 20090310 on a powerpc box (Power6 9117-MMA)
i observed the following badness :
[0.339662] [ cut here ]
[0.339666] Badness at mm/allocpercpu.c:123
[0.339670] NIP: c01129dc LR: c01129b8 CTR:
[0.339676] REGS
Hello all：
We use the AMCC PowerPC 405ex through emac1 way RGMII with realtek RTL8211
Giga phy linked to, At present the PHY Address is: 00110
add delay 2ns for RGMII
CONFIG[8:5]:AUTO_Negotiation
=NWay,advertise ，all capabilities,prefer Slave
mode;1=RGMII mode
Clk on the
Mel Gorman wrote:
Well, the machine must have started with some kernel. What mainline
version does that correspond to and can you bisect it?
The last booted kernel was a 2.6.25 based kernel. I am trying to find out
the last good kernel.org kernel. I should have that information by tomorrow.
From: Ted Peters ted.pet...@freescale.com
The PCI irqs for the protected sources where not correct for PCI PHBs
Signed-off-by: Ted Peters ted.pet...@freescale.com
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts |2 +-
On Mar 10, 2009, at 9:38 AM, Kumar Gala wrote:
From: Ted Peters ted.pet...@freescale.com
The PCI irqs for the protected sources where not correct for PCI PHBs
Signed-off-by: Ted Peters ted.pet...@freescale.com
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
Hi all,
This series reworks some of the phylib code to allow PHY descriptions and
connections to be extracted from the OF device tree. MDIO bus drivers gain
a common helper function for parsing the PHY data and registering new
phy_devices to match. Ethernet controller drivers gain the ability
From: Grant Likely grant.lik...@secretlab.ca
bus_register_notifier_alldev() is a variation on bus_register_notifier()
which also triggers the notifier callback for devices already on the bus
and already bound to drivers.
This function is useful for the case where a driver needs to get a
From: Grant Likely grant.lik...@secretlab.ca
This patch makes changes in preparation for supporting open firmware
device tree descriptions of MDIO busses. Changes include:
- Cleanup handling of phy_map[] entries; they are already NULLed when
registering and so don't need to be re-cleared, and
From: Grant Likely grant.lik...@secretlab.ca
Add support for parsing the device tree for PHY devices on an MDIO bus
CC: Andy Fleming aflem...@freescale.com
CC: linuxppc-dev@ozlabs.org
CC: devtree-disc...@ozlabs.org
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
drivers/of/Kconfig
From: Grant Likely grant.lik...@secretlab.ca
The patch reworks the MPC5200 Fast Ethernet Controller (FEC) driver to
use the of_mdio infrastructure for registering PHY devices from data out
openfirmware device tree, and eliminates the assumption that the PHY
for the FEC is always attached to the
Signed-off-by: Wolfram Sang w.s...@pengutronix.de
---
Changes since V1:
* removed defconfig
* reworked localbus node
arch/powerpc/boot/dts/pcm032.dts | 392 ++
arch/powerpc/platforms/52xx/Kconfig |1 +
arch/powerpc/platforms/52xx/mpc5200_simple.c
On 03/09/2009 06:26 AM, Geert Uytterhoeven wrote:
Create a real RTC driver for PS3, and unhook the deprecated
ppc_md.[gs]et_rtc_time.
Signed-off-by: Geert Uytterhoeven geert.uytterhoe...@sonycom.com
Cc: Geoff Levand geoffrey.lev...@am.sony.com
---
arch/powerpc/include/asm/ps3.h|
Hi Henk,
Acked-by: Grant Likely grant.lik...@secretlab.ca
Can you please repost with a blurb for the commit description and your
signed-off-by line? The blub below makes sense in the context of this
mailing list thread, but it won't be very useful for someone looking
at the commit message in
From: Grant Likely grant.lik...@secretlab.ca
Date: Tue, 10 Mar 2009 11:13:02 -0600
Hi Henk,
Acked-by: Grant Likely grant.lik...@secretlab.ca
...
Jeff, after Henk provides his s-o-b line, do you want to pick it up,
or should I merge it through my mpc52xx powerpc tree (via benh).
Send it to
On Tue, Mar 10, 2009 at 11:19 AM, David Miller da...@davemloft.net wrote:
Send it to netdev, CC:'d to me, Jeff hasn't been handling networking
driver changes for a while now.
Ah, okay. I didn't know. I looked in MAINTAINERS today, and Jeff is
listed there for NETWORK DEVICE DRIVERS.
g.
--
Hi,
not critical problem here.
IBM EMAC driver performs device reset (drivers/net/ibm_newemac/core.c:
emac_probe() - emac_init_phy() - emac_reset()) before registering
appropriate net_device (emac_probe() - register_netdev()), so
net_device name contains raw format string during EMAC reset
setup_irq(0, NULL) is broken as setup_irq() dereferences action
unconditionally.
Signed-off-by: Thomas Gleixner t...@linutronix.de
CC: Kumar Gala ga...@kernel.crashing.org
CC: Linux PPC Development linuxppc-dev@ozlabs.org
---
arch/powerpc/platforms/85xx/ksi8560.c |2 --
1 file changed, 2
On Mar 10, 2009, at 1:43 PM, Thomas Gleixner wrote:
setup_irq(0, NULL) is broken as setup_irq() dereferences action
unconditionally.
Signed-off-by: Thomas Gleixner t...@linutronix.de
CC: Kumar Gala ga...@kernel.crashing.org
CC: Linux PPC Development linuxppc-dev@ozlabs.org
---
On Mar 9, 2009, at 10:09 PM, Liu Yu wrote:
There is no dependece between efp and math-emu.
But when disalbe math-emu, the efp code cannot be built.
This patch fixes it.
Signed-off-by: Liu Yu yu@freescale.com
---
It would be nice to see this patch go along with 2.6.29
not critical enough
Please pull from 'next' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git next
to receive the following updates:
(The i2c patch was ack'd by Ben Dooks cpm_uart has historically gone via
powerpc tree as a PPC specific driver).
On Tue, Mar 10, 2009 at 09:22:24AM -0600, Grant Likely wrote:
From: Grant Likely grant.lik...@secretlab.ca
[...]
+static int mpc52xx_fec_notifier_phy_add(struct notifier_block *nb,
+ unsigned long event, void *_dev)
+{
[...]
+ rc =
On Tue, Mar 10, 2009 at 1:16 PM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
On Tue, Mar 10, 2009 at 09:22:24AM -0600, Grant Likely wrote:
From: Grant Likely grant.lik...@secretlab.ca
[...]
+static int mpc52xx_fec_notifier_phy_add(struct notifier_block *nb,
+
On Tue, Mar 10, 2009 at 01:48:26PM -0600, Grant Likely wrote:
[...]
eliminates the assumption that the PHY for the FEC is always
attached to the FEC's own MDIO bus. With this patch, the FEC can
use a PHY attached to any MDIO bus if it is described in the device
tree.
AFAIK, Gianfar and
I was just going to submit a patch for that too.
Indeed, the denali_fixup_memsize() miscalculated a couple of address
field widths. We were lucky to eventually get the right result,
because the effect of the first error was killed by the other one.
According to the AMCC 440EPX/GRX user manual,
the
Valentine Barshak wrote:
According to the AMCC 440EPX/GRX user manual,
the Chip Select width is always fixed at 1 bit no matter
what is actually read from register DDR_10.
Well, from my point of view original kernel code is correct in this part.
Adding one bit into memory address means
Timur Tabi wrote:
The macro spin_event_timeout() takes a condition and timeout value
(in microseconds) as parameters. It spins until either the condition is true
or the timeout expires. It returns zero if the timeout expires first, non-zero
otherwise.
This primary purpose of this macro is to
On Tue, Mar 10, 2009 at 05:33:08PM -0500, Scott Wood wrote:
Timur Tabi wrote:
The macro spin_event_timeout() takes a condition and timeout value
(in microseconds) as parameters. It spins until either the condition is true
or the timeout expires. It returns zero if the timeout expires first,
For those of you who are running into this error:
24520:01 not found
eth0: Could not attach to PHY
IP-Config: Failed to open eth0
IP-Config: Device `eth0' not found.
There is a bug in recent kernels. I found it in 2.6.28.7:
Josh Boyer wrote:
On Tue, Mar 10, 2009 at 05:33:08PM -0500, Scott Wood wrote:
Timur Tabi wrote:
The macro spin_event_timeout() takes a condition and timeout value
(in microseconds) as parameters. It spins until either the condition is true
or the timeout expires. It returns zero if the
(I did not get to complete the message!)
For those of you who are running into this error:
24520:01 not found
eth0: Could not attach to PHY
IP-Config: Failed to open eth0
IP-Config: Device `eth0' not found.
There is a bug in recent kernels. I found it in 2.6.28.7:
Hi,
I am using 2.6.24-rc3 ( secretlabs git) in an ML403 where I want to
use the USB c67x00 based host with Peter Kosgaard driver. I am using it
together with the sysace device for CF access ( in the ML403 those two
share lines, but I managed to insert some logic to multiplex both
devices). I
Unfortunately, the 2.6.24-rc3 stuff in my git tree is really old.
I've been getting all of my recent work into mainline. The CF driver
is in much better shape there. The c67x00 driver is merged into
mainline, but I haven't tested it at all in the last year so I don't
know how well it will work.
On Tue, Mar 10, 2009 at 4:55 PM, Johns Daniel johns.dan...@gmail.com wrote:
For those of you who are running into this error:
24520:01 not found
eth0: Could not attach to PHY
IP-Config: Failed to open eth0
IP-Config: Device `eth0' not found.
There is a bug in
Hi Linus !
Here are some late fixes for 2.6.29. I've included a radeonfb/aty128fb commit
as it only affects a powerpc specific code path and solves a reported
regression.
There's also an hvc_console commit that only affects powerpc pseries backends,
and also solves a regression. The rest are
On Tue, 2009-03-10 at 17:11 -0500, Timur Tabi wrote:
The macro spin_event_timeout() takes a condition and timeout value
(in microseconds) as parameters. It spins until either the condition is true
or the timeout expires. It returns zero if the timeout expires first,
non-zero
otherwise.
On Tue, 2009-03-10 at 18:37 -0400, Josh Boyer wrote:
On Tue, Mar 10, 2009 at 05:33:08PM -0500, Scott Wood wrote:
Timur Tabi wrote:
The macro spin_event_timeout() takes a condition and timeout value
(in microseconds) as parameters. It spins until either the condition is
true
or the
On Wed, 2009-03-11 at 01:39 +0200, Felix Radensky wrote:
Benjamin Herrenschmidt wrote:
On Wed, 2009-03-11 at 00:14 +0200, Felix Radensky wrote:
Yes, seems logical. U-boot has code to enable and disable loopback clock
for 440SPE, 440EPX,440GRX,405EX, 460EX and 460GT.
I can test
On Tue, 2009-03-10 at 19:22 -0500, Timur Tabi wrote:
Alan did have one valid point though. Determining how long to loop
for is architecture-specific. Using jiffies is bad, because even one
jiffy is too long. Adding a udelay() inside the loop means that it
only checks he condition every
On Tue, Mar 10, 2009 at 6:59 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
And ? We can disagree with Alan...
If you guys want to argue with Alan on lkml, please go ahead. I could
use the support.
Alan did have one valid point though. Determining how long to loop
for is
On Tue, Mar 10, 2009 at 05:58:58PM -0500, Scott Wood wrote:
Josh Boyer wrote:
On Tue, Mar 10, 2009 at 05:33:08PM -0500, Scott Wood wrote:
Timur Tabi wrote:
The macro spin_event_timeout() takes a condition and timeout value
(in microseconds) as parameters. It spins until either the condition
On Wed, Mar 11, 2009 at 10:59:11AM +1100, Benjamin Herrenschmidt wrote:
On Tue, 2009-03-10 at 18:37 -0400, Josh Boyer wrote:
On Tue, Mar 10, 2009 at 05:33:08PM -0500, Scott Wood wrote:
Timur Tabi wrote:
The macro spin_event_timeout() takes a condition and timeout value
(in microseconds) as
Impact: cleanup
Convert the last remaining users.
Signed-off-by: Thomas Gleixner t...@linutronix.de
CC: Benjamin Herrenschmidt b...@kernel.crashing.org
CC: linuxppc-dev@ozlabs.org
---
arch/powerpc/kernel/irq.c|4 ++--
arch/powerpc/platforms/iseries/irq.c |2 +-
2 files
Impact: cleanup
Convert the last remaining users to struct irq_chip.
Signed-off-by: Thomas Gleixner t...@linutronix.de
CC: Benjamin Herrenschmidt b...@kernel.crashing.org
CC: linuxppc-dev@ozlabs.org
---
arch/powerpc/include/asm/hw_irq.h |2 +-
arch/powerpc/platforms/powermac/pic.h |
Mikhail Zolotaryov wrote:
Valentine Barshak wrote:
According to the AMCC 440EPX/GRX user manual,
the Chip Select width is always fixed at 1 bit no matter
what is actually read from register DDR_10.
Well, from my point of view original kernel code is correct in this part.
Adding one bit into
On Wed, 2009-03-11 at 00:45 +, Thomas Gleixner wrote:
plain text document attachment
(powerpc-convert-obsolete-irq-desc-t-typedef.patch)
Impact: cleanup
Convert the last remaining users.
Ack. This would be more easily carried in my -next tree if that's ok
with you.
Signed-off-by:
On Wed, 2009-03-11 at 00:46 +, Thomas Gleixner wrote:
plain text document attachment
(powerpc-convert-obsolete-hw-interrupt-type.patch)
Impact: cleanup
Convert the last remaining users to struct irq_chip.
Ack too, same comment, happy to have that one in powerpc.
Ben.
Signed-off-by:
Yes, you could phrase it that way. According to the PPC440EPx manual,
the total memory size is calculated based on the following formula:
memsize = cs * (1 (col+row)) * bank * dpath;
So, if both chipselects are used, we add an extra bit to the memory
address to distinguish between these
While we did add support for _PAGE_SPECIAL on some 32-bit platforms,
we never actually built get_user_pages_fast() on them. This fixes
it which requires a little bit of ifdef'ing around.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/mm/Makefile |4 ++--
This series of patches does some ground work to make 32 and 64-bit
page table and PTE access slightly more common and to facilitate
the addition of a new MMU type (Book3-E version 2.06 and later)
for which I'd like to be able to use the same definitions for both
32 and 64-bit implementations.
CONFIG_PPC_MULTIPLATFORM is a remain of the pre-powerpc days and isn't
really meaningful anymore. It was basically equivalent to PPC64 || 6xx.
This removes it along with the following changes:
- 32-bit platforms that relied on PPC32 PPC_MULTIPLATFORM now rely
on 6xx which is what they want
This updates the 32-bit headers to use the same definitions for the RPN
shift inside the PTE as 64-bit, and thus updates _PAGE_CHG_MASK to
become identical.
This does introduce a runtime visible difference, which is that now,
_PAGE_HASHPTE will be part of _PAGE_CHG_MASK and thus preserved.
This patch tweaks the way some PTE bit combinations are defined, in such a
way that the 32 and 64-bit variant become almost identical and that will
make it easier to bring in a new common pte-* file for the new variant
of the Book3-E support.
The combination of bits defining access to kernel
Now that they are almost identical, we can merge some of the definitions
related to the PTE format into common files.
This creates a new pte-common.h which is included by both 32 and 64-bit
right after the CPU specific pte-*.h file, and which defines some
bits to default values if they haven't
This file is only useful on 64-bit, so we name it accordingly.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/mm/Makefile |2
arch/powerpc/mm/mmap.c| 109 --
arch/powerpc/mm/mmap_64.c | 109
We need to use %zu instead of %d when printing a sizeof()
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/mm/mmu_context_nohash.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-work.orig/arch/powerpc/mm/mmu_context_nohash.c2009-03-11
ppc32 has it already, add it to ppc64 as a preliminary for adding
support for Book3E 64-bit support
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include/asm/pgtable-ppc64.h | 12 +++-
arch/powerpc/include/asm/pte-hash64.h|2 ++
2 files
This moves some MMU related init code out of setup_64.c into hash_utils_64.c
and calls it early_init_mmu() and early_init_mmu_secondary(). This will
make it easier to plug in a new MMU type.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include/asm/mmu-hash64.h
On Fri, 2009-03-06 at 23:45 +0100, Joachim Foerster wrote:
Hi,
On Fri, 2009-03-06 at 16:51 +0100, A. Nolson wrote:
just a little question. I am using 2.6.24-rc3 (secretlab) and I would
like to use c67x00 driver from Peter Kosgaard for USB-Host in my Xilinx
ML403 board. Is there support
On Mon, 2009-03-09 at 16:36 +, David Howells wrote:
In ehea_probe_adapter() the initial memory allocation and initialisation does
not need to be done with the ehea_fw_handles.lock semaphore held. Doing so
extends the amount of time the lock is held unnecessarily.
Can you resend with
On Mon, 2009-03-09 at 13:59 +, David Woodhouse wrote:
On Mon, 2009-03-09 at 14:26 +0100, Geert Uytterhoeven wrote:
PowerPC has been a long time user of the generic RTC abstraction, so hook up
rtc-generic:
- Create the rtc-generic platform device if ppc_md.get_rtc_time is set,
-
Sachin P. Sant wrote:
While booting Next 20090310 on a powerpc box (Power6 9117-MMA)
i observed the following badness :
[0.339662] [ cut here ]
[0.339666] Badness at mm/allocpercpu.c:123
[0.339670] NIP: c01129dc LR: c01129b8 CTR
Alan did have one valid point though. Determining how long to loop
for is architecture-specific. Using jiffies is bad, because even one
jiffy is too long. Adding a udelay() inside the loop means that it
only checks he condition every microsecond. So the real solution is
to use keep
On Mon, 2009-03-09 at 09:23 -0600, Grant Likely wrote:
From: Grant Likely grant.lik...@secretlab.ca
fixed-head.o must be linked into the bootwrapper for raw-binary images to
work. This patch adds it into the bootwrapper.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
Reported-by:
On Thu, 2009-03-05 at 13:53 -0600, Nathan Fontenot wrote:
The return code from invoking the notifier chain when updating the
ibm,dynamic-memory property is not handled properly. In failure
cases (rc == NOTIFY_BAD) we should be restoring the original value
of the property. In success (rc ==
Impact: remove spurious WARN on legacy SMP percpu allocator
Commit f2a8205c4ef1af917d175c36a4097ae5587791c8 incorrectly added too
tight WARN_ON_ONCE() on alignments for UP and legacy SMP percpu
allocator. Commit e317603694bfd17b28a40de9d65e1a4ec12f816e fixed it
for UP but legacy SMP allocator
Impact: remove spurious WARN on legacy SMP percpu allocator
Commit f2a8205c4ef1af917d175c36a4097ae5587791c8 incorrectly added too
tight WARN_ON_ONCE() on alignments for UP and legacy SMP percpu
allocator. Commit e317603694bfd17b28a40de9d65e1a4ec12f816e fixed it
for UP but legacy SMP allocator
72 matches
Mail list logo
