* Re: [PATCH] powerpc: mpc832x mds: Fix board PHY reset code
From: Kumar Gala @ 2007-11-20 5:52 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev, Li Yang, peter.vanackeren
In-Reply-To: <20071119190443.7c04ae6b.kim.phillips@freescale.com>
On Mon, 19 Nov 2007, Kim Phillips wrote:
> currently the board-level PHY reset code for the mpc832x MDS messes with
> reset configuration words source settings which is plain wrong (it
> looks like this board code was cut-n-pasted from the mpc8360 mds code,
> which has the PHY reset bits in a different BCSR); this patch points
> the PHY reset code to the proper mpc832x mds PHY reset bits in the BCSR.
>
> Signed-off-by: Peter Van Ackeren <peter.vanackeren@freescale.com>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> ---
> arch/powerpc/platforms/83xx/mpc832x_mds.c | 7 ++++---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>
applied.
- k
^ permalink raw reply
* Re: [PATCH] powerpc: fix 2nd UCC entry in mpc832x_mds.dts
From: Kumar Gala @ 2007-11-20 5:52 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <20071113172631.7b42e1e1.kim.phillips@freescale.com>
On Tue, 13 Nov 2007, Kim Phillips wrote:
> correct the reg property, remove duplicate io port entry, whitespace fixes.
>
> Thanks to Peter Van Ackeren for pointing this out.
>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> ---
> arch/powerpc/boot/dts/mpc832x_mds.dts | 9 ++++-----
> 1 files changed, 4 insertions(+), 5 deletions(-)
>
applied
- k
^ permalink raw reply
* Re: [PATCH 5/5] powerpc: handle mpc8360 rev. 2.1 RGMII timing erratum
From: Kumar Gala @ 2007-11-20 5:53 UTC (permalink / raw)
To: Kim Phillips; +Cc: netdev, Li Yang, jgarzik, paulus, linuxppc-dev
In-Reply-To: <20071105121551.a28b5446.kim.phillips@freescale.com>
On Mon, 5 Nov 2007, Kim Phillips wrote:
> if on a rev. 2.1, adjust UCC clock and data timing characteristics
> as specified in the rev.2.1 erratum #2.
>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> ---
> arch/powerpc/platforms/83xx/mpc836x_mds.c | 31 ++++++++++++++++++++++++++--
> 1 files changed, 28 insertions(+), 3 deletions(-)
>
applied.
- k
^ permalink raw reply
* Re: [PATCH 1/5] powerpc: document rgmii-rxid and rgmii-txid phy-connection-types
From: Kumar Gala @ 2007-11-20 5:53 UTC (permalink / raw)
To: Kim Phillips; +Cc: netdev, Li Yang, jgarzik, paulus, linuxppc-dev
In-Reply-To: <20071105121535.c423d095.kim.phillips@freescale.com>
On Mon, 5 Nov 2007, Kim Phillips wrote:
> A h/w bug requires we program the PHY in RGMII mode for internal delay
> on the receive or transmit side only; document the new property values.
>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> ---
> Documentation/powerpc/booting-without-of.txt | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
applied.
- k
^ permalink raw reply
* Please pull from 'for-2.6.24' branch
From: Kumar Gala @ 2007-11-20 5:56 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Please pull from 'for-2.6.24' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.24
to receive the following updates:
Documentation/powerpc/booting-without-of.txt | 5 -
arch/powerpc/boot/dts/mpc832x_mds.dts | 9 -
arch/powerpc/boot/dts/mpc8544ds.dts | 20 ++--
arch/powerpc/boot/dts/mpc8572ds.dts | 108 ++++++++++++++++++++---
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 126 ++++++++++++++++++++++-----
arch/powerpc/platforms/83xx/mpc832x_mds.c | 7 -
arch/powerpc/platforms/83xx/mpc836x_mds.c | 31 ++++++
arch/powerpc/platforms/83xx/usb.c | 8 -
8 files changed, 254 insertions(+), 60 deletions(-)
Cyrill Gorcunov (1):
[POWERPC] Fix potential NULL dereference
Kim Phillips (4):
[POWERPC] 83xx: mpc832x mds: Fix board PHY reset code
[POWERPC] 83xx: Fix 2nd UCC entry in mpc832x_mds.dts
[POWERPC] Document rgmii-rxid and rgmii-txid phy-connection-types
[POWERPC] 83xx: Handle mpc8360 rev. 2.1 RGMII timing erratum
Kumar Gala (1):
[POWERPC] Fix device tree interrupt map for Freescale ULI1575 boards
^ permalink raw reply
* Re: [patch] xmon bitlock fix
From: Nick Piggin @ 2007-11-20 6:03 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18242.28770.6643.679177@cargo.ozlabs.ibm.com>
On Tue, Nov 20, 2007 at 04:28:02PM +1100, Paul Mackerras wrote:
> Nick Piggin writes:
>
> > xmon uses a bit lock spinlock but doesn't close the critical section
> > when releasing it. It doesn't seem like a big deal because it will
> > eventually break out of the lock anyway, but presumably that's only
> > in exceptional cases where some error is tolerated, while the lack of a memory
> > barrier could allow incorrect results during normal functioning operation
> > as well.
> >
> > Convert it to use a regular spinlock instead.
>
> I'd rather not. The idea is that xmon is as independent as possible
> of the rest of the kernel, so that it will work even when lots of
> kernel data structures are corrupted. If spinlocks were simple spin
> loops then maybe, but they're not these days.
Fair enough, I guess you still want lockdep kernels to work.
> As for the memory barrier comment, I don't think it is a reason, since
> test_and_set_bit acts as a barrier, and in any case the worst thing
test_and_set_bit is a barrier (although heavier than required to acquire
a lock). But clear_bit isn't strong enough... you do have eieio() in
there, making it probably less problem, but that won't get executed if
nb is 0, and it is still doing the xmon_init_scc() outside the loop. I
just prefer to make it a simple lock that doesn't rely on barriers or
the specific structure of the critical section.
> that could happen is that the characters from different cpu's outputs
> get interleaved (that's one reason why the loop has a timeout, the
> other is for robustness).
>
> In any case this is in arch/ppc which is dying code. I don't think
> there are any SMP platforms supported in arch/ppc any more except for
> some (fairly rare) PReP platforms, and I hope to get PReP moved over
> soon.
I was just grepping the tree, and trying to reduce code which might
be fragile, broken, or a poor example.
> Finally, why do you say that it doesn't close the critical section?
> Possibly the "locked" variable is badly named (it's zero when we get
> the lock) but AFAICS the code is actually correct.
Well the unlock itself doesn't close it properly because clear_bit
doesn't order previous loads or stores.
How about this?
---
xmon uses a bit lock spinlock but doesn't close the critical section
when releasing it. It doesn't seem like a big deal because it will
eventually break out of the lock anyway, but presumably that's only
in exceptional cases where some error is tolerated, while the lack of a memory
barrier could allow incorrect results during normal functioning operation
as well.
Signed-off-by: Nick Piggin <npiggin@suse.de>
---
Index: linux-2.6/arch/ppc/xmon/start.c
===================================================================
--- linux-2.6.orig/arch/ppc/xmon/start.c
+++ linux-2.6/arch/ppc/xmon/start.c
@@ -98,7 +98,7 @@ xmon_write(void *handle, void *ptr, int
int lock_wait = 1000000;
int locked;
- while ((locked = test_and_set_bit(0, &xmon_write_lock)) != 0)
+ while ((locked = test_and_set_bit_lock(0, &xmon_write_lock)) != 0)
if (--lock_wait == 0)
break;
#endif
@@ -124,7 +124,7 @@ xmon_write(void *handle, void *ptr, int
#ifdef CONFIG_SMP
if (!locked)
- clear_bit(0, &xmon_write_lock);
+ clear_bit_unlock(0, &xmon_write_lock);
#endif
return nb;
}
^ permalink raw reply
* Re: [patch] powerpc: hash lock use lock bitops
From: Benjamin Herrenschmidt @ 2007-11-20 6:08 UTC (permalink / raw)
To: Nick Piggin; +Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard
In-Reply-To: <20071120050950.GB18332@wotan.suse.de>
On Tue, 2007-11-20 at 06:09 +0100, Nick Piggin wrote:
> This isn't a bugfix, but may help performance slightly...
>
> --
> powerpc 64-bit hash pte lock bit is an actual lock, so it can take advantage
> of lock bitops for slightly more optimal memory barriers (can avoid an lwsync
> in the trylock).
>
> Signed-off-by: Nick Piggin <npiggin@suse.de>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
Looks nice, I'll try it out on a G5 and let you know.
Cheers,
Ben.
^ permalink raw reply
* [PATCH] [PPC] Remove xmon from ml300 and ml403 defconfig
From: Grant Likely @ 2007-11-20 6:08 UTC (permalink / raw)
To: "jwboyer, linuxppc-dev
From: Grant Likely <grant.likely@secretlab.ca>
xmon is broken under arch/ppc so remove it from the defconfig.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Josh; I'm not going to even bother doing a full defconfig update for these
boards right now; it's probably not worth it. This change just eliminates
the xmon build issue. Plus doing it this way is trivial to review. :-)
In fact; looking at the code, I don't think xmon builds for *any* arch/ppc
platforms at the moment. :-/ Probably not even worth worrying about.
As we discussed, this should go in for .24
Cheers,
g.
arch/ppc/configs/ml300_defconfig | 2 +-
arch/ppc/configs/ml403_defconfig | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/ppc/configs/ml300_defconfig b/arch/ppc/configs/ml300_defconfig
index 69bad91..d66cacd 100644
--- a/arch/ppc/configs/ml300_defconfig
+++ b/arch/ppc/configs/ml300_defconfig
@@ -719,7 +719,7 @@ CONFIG_DEBUG_INFO=y
CONFIG_FORCED_INLINING=y
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_KGDB is not set
-CONFIG_XMON=y
+# CONFIG_XMON is not set
# CONFIG_BDI_SWITCH is not set
# CONFIG_SERIAL_TEXT_DEBUG is not set
diff --git a/arch/ppc/configs/ml403_defconfig b/arch/ppc/configs/ml403_defconfig
index a78896e..71bcfa7 100644
--- a/arch/ppc/configs/ml403_defconfig
+++ b/arch/ppc/configs/ml403_defconfig
@@ -720,7 +720,7 @@ CONFIG_DEBUG_INFO=y
CONFIG_FORCED_INLINING=y
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_KGDB is not set
-CONFIG_XMON=y
+# CONFIG_XMON is not set
# CONFIG_BDI_SWITCH is not set
# CONFIG_SERIAL_TEXT_DEBUG is not set
^ permalink raw reply related
* Re: [patch] powerpc: hash lock use lock bitops
From: Nick Piggin @ 2007-11-20 6:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard
In-Reply-To: <1195538904.6970.37.camel@pasglop>
On Tue, Nov 20, 2007 at 05:08:24PM +1100, Benjamin Herrenschmidt wrote:
>
> On Tue, 2007-11-20 at 06:09 +0100, Nick Piggin wrote:
> > This isn't a bugfix, but may help performance slightly...
> >
> > --
> > powerpc 64-bit hash pte lock bit is an actual lock, so it can take advantage
> > of lock bitops for slightly more optimal memory barriers (can avoid an lwsync
> > in the trylock).
> >
> > Signed-off-by: Nick Piggin <npiggin@suse.de>
> > Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > ---
>
> Looks nice, I'll try it out on a G5 and let you know.
Cool, thanks (I don't have mine handy ATM...).
BTW, here is another thing which you might want to think about. Again
untested for temporary lack of hardware.
--
The radix-tree is now RCU safe, so powerpc can avoid the games it was playing
in order to have a lockless readside. Saves an irq disable/enable, a couple of
__get_cpu_var()s, a cacheline, and a memory barrier, in the fastpath. Should
save a cycle or two...
---
Index: linux-2.6/arch/powerpc/kernel/irq.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/irq.c
+++ linux-2.6/arch/powerpc/kernel/irq.c
@@ -406,8 +406,6 @@ void do_softirq(void)
static LIST_HEAD(irq_hosts);
static DEFINE_SPINLOCK(irq_big_lock);
-static DEFINE_PER_CPU(unsigned int, irq_radix_reader);
-static unsigned int irq_radix_writer;
struct irq_map_entry irq_map[NR_IRQS];
static unsigned int irq_virq_count = NR_IRQS;
static struct irq_host *irq_default_host;
@@ -550,57 +548,6 @@ void irq_set_virq_count(unsigned int cou
irq_virq_count = count;
}
-/* radix tree not lockless safe ! we use a brlock-type mecanism
- * for now, until we can use a lockless radix tree
- */
-static void irq_radix_wrlock(unsigned long *flags)
-{
- unsigned int cpu, ok;
-
- spin_lock_irqsave(&irq_big_lock, *flags);
- irq_radix_writer = 1;
- smp_mb();
- do {
- barrier();
- ok = 1;
- for_each_possible_cpu(cpu) {
- if (per_cpu(irq_radix_reader, cpu)) {
- ok = 0;
- break;
- }
- }
- if (!ok)
- cpu_relax();
- } while(!ok);
-}
-
-static void irq_radix_wrunlock(unsigned long flags)
-{
- smp_wmb();
- irq_radix_writer = 0;
- spin_unlock_irqrestore(&irq_big_lock, flags);
-}
-
-static void irq_radix_rdlock(unsigned long *flags)
-{
- local_irq_save(*flags);
- __get_cpu_var(irq_radix_reader) = 1;
- smp_mb();
- if (likely(irq_radix_writer == 0))
- return;
- __get_cpu_var(irq_radix_reader) = 0;
- smp_wmb();
- spin_lock(&irq_big_lock);
- __get_cpu_var(irq_radix_reader) = 1;
- spin_unlock(&irq_big_lock);
-}
-
-static void irq_radix_rdunlock(unsigned long flags)
-{
- __get_cpu_var(irq_radix_reader) = 0;
- local_irq_restore(flags);
-}
-
static int irq_setup_virq(struct irq_host *host, unsigned int virq,
irq_hw_number_t hwirq)
{
@@ -791,9 +738,9 @@ void irq_dispose_mapping(unsigned int vi
/* Check if radix tree allocated yet */
if (host->revmap_data.tree.gfp_mask == 0)
break;
- irq_radix_wrlock(&flags);
+ spin_lock_irqsave(&irq_big_lock, flags);
radix_tree_delete(&host->revmap_data.tree, hwirq);
- irq_radix_wrunlock(flags);
+ spin_unlock_irqrestore(&irq_big_lock, flags);
break;
}
@@ -861,9 +808,9 @@ unsigned int irq_radix_revmap(struct irq
return irq_find_mapping(host, hwirq);
/* Now try to resolve */
- irq_radix_rdlock(&flags);
+ rcu_read_lock();
ptr = radix_tree_lookup(tree, hwirq);
- irq_radix_rdunlock(flags);
+ rcu_read_unlock();
/* Found it, return */
if (ptr) {
@@ -874,9 +821,9 @@ unsigned int irq_radix_revmap(struct irq
/* If not there, try to insert it */
virq = irq_find_mapping(host, hwirq);
if (virq != NO_IRQ) {
- irq_radix_wrlock(&flags);
+ spin_lock_irqsave(&irq_big_lock, flags);
radix_tree_insert(tree, hwirq, &irq_map[virq]);
- irq_radix_wrunlock(flags);
+ spin_unlock_irqrestore(&irq_big_lock, flags);
}
return virq;
}
@@ -989,12 +936,12 @@ static int irq_late_init(void)
struct irq_host *h;
unsigned long flags;
- irq_radix_wrlock(&flags);
+ spin_lock_irqsave(&irq_big_lock, flags);
list_for_each_entry(h, &irq_hosts, link) {
if (h->revmap_type == IRQ_HOST_MAP_TREE)
INIT_RADIX_TREE(&h->revmap_data.tree, GFP_ATOMIC);
}
- irq_radix_wrunlock(flags);
+ spin_unlock_irqrestore(&irq_big_lock, flags);
return 0;
}
^ permalink raw reply
* Re: [patch] powerpc: hash lock use lock bitops
From: Benjamin Herrenschmidt @ 2007-11-20 7:10 UTC (permalink / raw)
To: Nick Piggin; +Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard
In-Reply-To: <20071120062618.GB31514@wotan.suse.de>
On Tue, 2007-11-20 at 07:26 +0100, Nick Piggin wrote:
>
> BTW, here is another thing which you might want to think about. Again
> untested for temporary lack of hardware.
>
> --
>
> The radix-tree is now RCU safe, so powerpc can avoid the games it was playing
> in order to have a lockless readside. Saves an irq disable/enable, a couple of
> __get_cpu_var()s, a cacheline, and a memory barrier, in the fastpath. Should
> save a cycle or two...
Yup, I know. I need to work on that for -rt anyway due to other issues...
Thanks !
Ben.
^ permalink raw reply
* [PATCH] powerpc: Fix 8xx build breakage due to _tlbie changes
From: Vitaly Bordug @ 2007-11-20 7:32 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
My changes to _tlbie to fix 4xx unfortunately broke 8xx build in a
couple of places. This fixes it.
Spotted by Olof Johansson
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
---
arch/powerpc/mm/mem.c | 2 +-
arch/powerpc/mm/mmu_decl.h | 2 +-
arch/ppc/mm/init.c | 2 +-
arch/ppc/mm/mmu_decl.h | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 81eb96e..5402fb6 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -464,7 +464,7 @@ void update_mmu_cache(struct vm_area_struct *vma, unsigned long address,
* we invalidate the TLB here, thus avoiding dcbst
* misbehaviour.
*/
- _tlbie(address);
+ _tlbie(address, 0 /* 8xx doesn't care about PID */);
#endif
if (!PageReserved(page)
&& !test_bit(PG_arch_1, &page->flags)) {
diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
index eb3a732..ebfd13d 100644
--- a/arch/powerpc/mm/mmu_decl.h
+++ b/arch/powerpc/mm/mmu_decl.h
@@ -56,7 +56,7 @@ extern unsigned long total_lowmem;
* architectures. -- Dan
*/
#if defined(CONFIG_8xx)
-#define flush_HPTE(X, va, pg) _tlbie(va)
+#define flush_HPTE(X, va, pg) _tlbie(va, 0 /* 8xx doesn't care about PID */)
#define MMU_init_hw() do { } while(0)
#define mmu_mapin_ram() (0UL)
diff --git a/arch/ppc/mm/init.c b/arch/ppc/mm/init.c
index 390dd19..dd898d3 100644
--- a/arch/ppc/mm/init.c
+++ b/arch/ppc/mm/init.c
@@ -561,7 +561,7 @@ void update_mmu_cache(struct vm_area_struct *vma, unsigned long address,
* That means the zeroed TLB has to be invalidated
* whenever a page miss occurs.
*/
- _tlbie(address);
+ _tlbie(address, 0 /* 8xx doesn't care about PID */);
#endif
if (!PageReserved(page)
&& !test_bit(PG_arch_1, &page->flags)) {
diff --git a/arch/ppc/mm/mmu_decl.h b/arch/ppc/mm/mmu_decl.h
index f1d4f21..b298b60 100644
--- a/arch/ppc/mm/mmu_decl.h
+++ b/arch/ppc/mm/mmu_decl.h
@@ -49,7 +49,7 @@ extern unsigned int num_tlbcam_entries;
* architectures. -- Dan
*/
#if defined(CONFIG_8xx)
-#define flush_HPTE(X, va, pg) _tlbie(va)
+#define flush_HPTE(X, va, pg) _tlbie(va, 0 /* 8xx doesn't care about PID */)
#define MMU_init_hw() do { } while(0)
#define mmu_mapin_ram() (0UL)
^ permalink raw reply related
* Re: Virtex TEMAC ping -s 10000 host, is it working?
From: Lorenz Kolb @ 2007-11-20 7:45 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <13830023.post@talk.nabble.com>
alex_snippet wrote:
>
>
> It's interesting to see some info from your design files, PLB_TEMAC &
> HardTEMAC description from mhs,
> and kernel .config network section.
>
.mhs
> <snip>
> BEGIN hard_temac
> PARAMETER INSTANCE = hard_temac_0
> PARAMETER HW_VER = 3.00.a
> BUS_INTERFACE V4EMACDST0 = plb_temac_0_V4EMACSRC
> PORT MII_TX_CLK_0 = fpga_0_Hard_Temac_0_MII_TX_CLK_0
> PORT GMII_TXD_0 = fpga_0_Hard_Temac_0_GMII_TXD_0
> PORT GMII_TX_EN_0 = fpga_0_Hard_Temac_0_GMII_TX_EN_0
> PORT GMII_TX_ER_0 = fpga_0_Hard_Temac_0_GMII_TX_ER_0
> PORT GMII_TX_CLK_0 = fpga_0_Hard_Temac_0_GMII_TX_CLK_0
> PORT GMII_RXD_0 = fpga_0_Hard_Temac_0_GMII_RXD_0
> PORT GMII_RX_DV_0 = fpga_0_Hard_Temac_0_GMII_RX_DV_0
> PORT GMII_RX_ER_0 = fpga_0_Hard_Temac_0_GMII_RX_ER_0
> PORT GMII_RX_CLK_0 = fpga_0_Hard_Temac_0_GMII_RX_CLK_0
> PORT MDC_0 = fpga_0_Hard_Temac_0_MDC_0
> PORT MDIO_0 = fpga_0_Hard_Temac_0_MDIO_0
> PORT RESET = Emac_Reset_s
> PORT GTX_CLK_0 = temac_0_clk_s
> PORT REFCLK = sys_clk
> END
>
> BEGIN plb_temac
> PARAMETER INSTANCE = plb_temac_0
> PARAMETER HW_VER = 3.00.a
> PARAMETER C_MAC_FIFO_DEPTH = 64
> PARAMETER C_RX_DRE_TYPE = 0
> PARAMETER C_TX_DRE_TYPE = 0
> PARAMETER C_DMA_TYPE = 1
> PARAMETER C_PLB_CLK_PERIOD_PS = 10000
> PARAMETER C_BASEADDR = 0x40000000
> PARAMETER C_HIGHADDR = 0x4000FFFF
> BUS_INTERFACE V4EMACSRC = plb_temac_0_V4EMACSRC
> BUS_INTERFACE MSPLB = plb_v34_0
> PORT Emac_Reset = Emac_Reset_s
> PORT PhyResetN = fpga_0_TriMode_MAC_GMII_PhyResetN
> PORT IP2INTC_Irpt = plb_temac_0_IP2INTC_Irpt
> END
> <snap>
>
.config
> <snip>
> #
> # Networking
> #
> CONFIG_NET=y
>
> #
> # Networking options
> #
> CONFIG_PACKET=y
> CONFIG_PACKET_MMAP=y
> CONFIG_UNIX=y
> CONFIG_INET=y
> CONFIG_IP_FIB_HASH=y
> CONFIG_TCP_CONG_CUBIC=y
> CONFIG_DEFAULT_TCP_CONG="cubic"
> <snap>
>
We use the Temac driver from Grant's tree.
Nevertheless we changed the auto-negotiation code, as we had problem with
the default code when using the same code in U-Boot.
I have attached our auto-negotiation patch (nevertheless the old
auto-negotiation worked fine with the linux kernel, the main reason we
patched that is to hold the code base to maintain minimal).
http://www.nabble.com/file/p13852281/0018-TEMAC-changed-renegotiation-function-to-ESIC-U-Boo.patch
0018-TEMAC-changed-renegotiation-function-to-ESIC-U-Boo.patch
alex_snippet wrote:
>
> The biggest problem that i actually do not understand what kind of problem
> is it, hardware or software or configuration.
>
Regards,
--
Lorenz Kolb
Embedded specialist
ESIC Solutions
San Jose, CA
Neu-Ulm, Germany
--
View this message in context: http://www.nabble.com/Virtex-TEMAC-ping--s-10000-host%2C-is-it-working--tf4812989.html#a13852281
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2007-11-20 8:38 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get another batch of fixes for powerpc, as listed below.
Thanks,
Paul.
Documentation/powerpc/booting-without-of.txt | 5 +
arch/powerpc/boot/dts/mpc832x_mds.dts | 9 +-
arch/powerpc/boot/dts/mpc8544ds.dts | 20 ++--
arch/powerpc/boot/dts/mpc8572ds.dts | 108 ++++++++++++++++++---
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 126 ++++++++++++++++++++----
arch/powerpc/kernel/asm-offsets.c | 4 +
arch/powerpc/kernel/rtas.c | 111 ++++++++++++---------
arch/powerpc/kernel/time.c | 5 +
arch/powerpc/kernel/vdso.c | 11 ++
arch/powerpc/kernel/vdso32/cacheflush.S | 41 ++++++--
arch/powerpc/kernel/vdso64/cacheflush.S | 41 ++++++--
arch/powerpc/mm/mem.c | 2
arch/powerpc/mm/mmu_decl.h | 2
arch/powerpc/mm/stab.c | 1
arch/powerpc/platforms/40x/walnut.c | 3 -
arch/powerpc/platforms/44x/bamboo.c | 3 -
arch/powerpc/platforms/44x/ebony.c | 3 -
arch/powerpc/platforms/44x/sequoia.c | 3 -
arch/powerpc/platforms/83xx/mpc832x_mds.c | 7 +
arch/powerpc/platforms/83xx/mpc836x_mds.c | 31 +++++-
arch/powerpc/platforms/83xx/usb.c | 8 +-
arch/powerpc/platforms/cell/spufs/inode.c | 1
arch/powerpc/platforms/embedded6xx/prpmc2800.c | 1
arch/powerpc/platforms/pasemi/setup.c | 2
arch/powerpc/platforms/pseries/Kconfig | 2
arch/powerpc/platforms/pseries/setup.c | 3 -
arch/powerpc/sysdev/uic.c | 18 +++
arch/ppc/kernel/setup.c | 7 +
arch/ppc/mm/init.c | 2
arch/ppc/mm/mmu_decl.h | 2
arch/ppc/platforms/4xx/yucca.c | 1
arch/ppc/syslib/virtex_devices.c | 31 ++++++
include/asm-powerpc/page_32.h | 4 +
include/asm-powerpc/pci-bridge.h | 5 +
include/asm-powerpc/rtas.h | 3 -
include/asm-powerpc/vdso_datapage.h | 8 ++
36 files changed, 486 insertions(+), 148 deletions(-)
Benjamin Herrenschmidt (3):
[POWERPC] Fix declaration of pcibios_free_controller
[POWERPC] Fix kmalloc alignment on non-coherent DMA platforms
[POWERPC] Fix 8xx build breakage due to _tlbie changes
Cyrill Gorcunov (1):
[POWERPC] Fix potential NULL dereference
Jeremy Kerr (1):
[POWERPC] spufs: Fix context destroy vs /spu readdir race
Joachim Foerster (1):
[POWERPC] Xilinx: Register AC97 Controller Reference with the platform bus
Jon Loeliger (1):
[POWERPC] 4xx: Replace #includes of asm/of_platform.h with linux/of_platform.h.
Josh Boyer (1):
[POWERPC] 4xx: Use virtual PVR value to init FPU on arch/ppc 440EP
Kamalesh Babulal (1):
[POWERPC] Fix build failure on legacy iSeries
Kim Phillips (4):
[POWERPC] 83xx: mpc832x mds: Fix board PHY reset code
[POWERPC] 83xx: Fix 2nd UCC entry in mpc832x_mds.dts
[POWERPC] Document rgmii-rxid and rgmii-txid phy-connection-types
[POWERPC] 83xx: Handle mpc8360 rev. 2.1 RGMII timing erratum
Kumar Gala (1):
[POWERPC] Fix device tree interrupt map for Freescale ULI1575 boards
Linas Vepstas (1):
[POWERPC] Fix RTAS os-term usage on kernel panic
Mark A. Greer (1):
[POWERPC] prpmc2800: Enable L2 cache
Michael Neuling (1):
[POWERPC] Fix possible division by zero in scaled time accounting
Nathan Lynch (1):
[POWERPC] Fix multiple bugs in rtas_ibm_suspend_me code
Olof Johansson (2):
[POWERPC] pasemi: Don't reset mpic at boot
[POWERPC] vdso: Fixes for cache block sizes
Roel Kluin (1):
[POWERPC] 4xx: balance ioremap/ioumap calls for Yucca
Stephen Rothwell (1):
[POWERPC] pSeries: make pseries_defconfig minus PCI build again
Valentine Barshak (1):
[POWERPC] 4xx: UIC add mask_ack callback
^ permalink raw reply
* [PATCH] ppc: 4xx: Fix TLB 0 problem with CONFIG_SERIAL_TEXT_DEBUG
From: Stefan Roese @ 2007-11-20 10:19 UTC (permalink / raw)
To: linuxppc-dev
Right now TLB entry 0 ist used as UART0 mapping for the early debug
output (via CONFIG_SERIAL_TEXT_DEBUG). This causes problems when many
TLB's get used upon Linux bootup (e.g. while PCIe scanning behind
bridges and/or switches on 440SPe platforms). This will overwrite the
TLB 0 entry and further debug output's may crash/hang the system.
This patch moves the early debug UART0 TLB entry from 0 to 62 as done
in arch/powerpc. This way it is in the "pinned" area and will not get
overwritten. Also the arch/ppc/mm/44x_mmu.c code is now synced with the
newer code from arch/powerpc.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/ppc/kernel/head_44x.S | 2 +-
arch/ppc/mm/44x_mmu.c | 51 +++++++++++++------------------------------
include/asm-ppc/mmu.h | 6 +++++
3 files changed, 23 insertions(+), 36 deletions(-)
diff --git a/arch/ppc/kernel/head_44x.S b/arch/ppc/kernel/head_44x.S
index 75bbc93..ebb5a40 100644
--- a/arch/ppc/kernel/head_44x.S
+++ b/arch/ppc/kernel/head_44x.S
@@ -195,7 +195,7 @@ skpinv: addi r4,r4,1 /* Increment */
li r5,0
ori r5,r5,(PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_I | PPC44x_TLB_G)
- li r0,0 /* TLB slot 0 */
+ li r0,62 /* TLB slot 62 */
tlbwe r3,r0,PPC44x_TLB_PAGEID /* Load the pageid fields */
tlbwe r4,r0,PPC44x_TLB_XLAT /* Load the translation fields */
diff --git a/arch/ppc/mm/44x_mmu.c b/arch/ppc/mm/44x_mmu.c
index 6536a25..fbb577a 100644
--- a/arch/ppc/mm/44x_mmu.c
+++ b/arch/ppc/mm/44x_mmu.c
@@ -60,38 +60,28 @@ extern char etext[], _stext[];
* Just needed it declared someplace.
*/
unsigned int tlb_44x_index = 0;
-unsigned int tlb_44x_hwater = 62;
+unsigned int tlb_44x_hwater = PPC4XX_TLB_SIZE - 1 - PPC44x_EARLY_TLBS;
int icache_44x_need_flush;
/*
* "Pins" a 256MB TLB entry in AS0 for kernel lowmem
*/
-static void __init
-ppc44x_pin_tlb(int slot, unsigned int virt, unsigned int phys)
+static void __init ppc44x_pin_tlb(unsigned int virt, unsigned int phys)
{
- unsigned long attrib = 0;
-
- __asm__ __volatile__("\
- clrrwi %2,%2,10\n\
- ori %2,%2,%4\n\
- clrrwi %1,%1,10\n\
- li %0,0\n\
- ori %0,%0,%5\n\
- tlbwe %2,%3,%6\n\
- tlbwe %1,%3,%7\n\
- tlbwe %0,%3,%8"
+ __asm__ __volatile__(
+ "tlbwe %2,%3,%4\n"
+ "tlbwe %1,%3,%5\n"
+ "tlbwe %0,%3,%6\n"
:
- : "r" (attrib), "r" (phys), "r" (virt), "r" (slot),
- "i" (PPC44x_TLB_VALID | PPC44x_TLB_256M),
- "i" (PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | PPC44x_TLB_G),
+ : "r" (PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | PPC44x_TLB_G),
+ "r" (phys),
+ "r" (virt | PPC44x_TLB_VALID | PPC44x_TLB_256M),
+ "r" (tlb_44x_hwater--), /* slot for this TLB entry */
"i" (PPC44x_TLB_PAGEID),
"i" (PPC44x_TLB_XLAT),
"i" (PPC44x_TLB_ATTRIB));
}
-/*
- * MMU_init_hw does the chip-specific initialization of the MMU hardware.
- */
void __init MMU_init_hw(void)
{
flush_instruction_cache();
@@ -99,22 +89,13 @@ void __init MMU_init_hw(void)
unsigned long __init mmu_mapin_ram(void)
{
- unsigned int pinned_tlbs = 1;
- int i;
-
- /* Determine number of entries necessary to cover lowmem */
- pinned_tlbs = (unsigned int)
- (_ALIGN(total_lowmem, PPC_PIN_SIZE) >> PPC44x_PIN_SHIFT);
-
- /* Write upper watermark to save location */
- tlb_44x_hwater = PPC44x_LOW_SLOT - pinned_tlbs;
+ unsigned long addr;
- /* If necessary, set additional pinned TLBs */
- if (pinned_tlbs > 1)
- for (i = (PPC44x_LOW_SLOT-(pinned_tlbs-1)); i < PPC44x_LOW_SLOT; i++) {
- unsigned int phys_addr = (PPC44x_LOW_SLOT-i) * PPC_PIN_SIZE;
- ppc44x_pin_tlb(i, phys_addr+PAGE_OFFSET, phys_addr);
- }
+ /* Pin in enough TLBs to cover any lowmem not covered by the
+ * initial 256M mapping established in head_44x.S */
+ for (addr = PPC_PIN_SIZE; addr < total_lowmem;
+ addr += PPC_PIN_SIZE)
+ ppc44x_pin_tlb(addr + PAGE_OFFSET, addr);
return total_lowmem;
}
diff --git a/include/asm-ppc/mmu.h b/include/asm-ppc/mmu.h
index 14584e5..d46b57b 100644
--- a/include/asm-ppc/mmu.h
+++ b/include/asm-ppc/mmu.h
@@ -383,6 +383,12 @@ typedef struct _P601_BAT {
#define BOOKE_PAGESZ_256GB 14
#define BOOKE_PAGESZ_1TB 15
+#ifndef CONFIG_SERIAL_TEXT_DEBUG
+#define PPC44x_EARLY_TLBS 1
+#else
+#define PPC44x_EARLY_TLBS 2
+#endif
+
/*
* Freescale Book-E MMU support
*/
--
1.5.3.5.788.gea559
^ permalink raw reply related
* Re: Oops: of_platform_serial_probe
From: Clemens Koller @ 2007-11-20 10:52 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-embedded
In-Reply-To: <200711191756.55165.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 3872 bytes --]
Hi, Arnd!
Arnd Bergmann schrieb:
> On Monday 19 November 2007, Clemens Koller wrote:
>> Unable to handle kernel paging request for data at address 0x00000000
>> Faulting instruction address: 0xc018f03c
>> Oops: Kernel access of bad area, sig: 11 [#1]
>> MPC85xx ADS
>> Modules linked in:
>> NIP: c018f03c LR: c018f00c CTR: c00127b4
>> REGS: c0821cf0 TRAP: 0300 Not tainted (2.6.24-rc2-ge6a5c27f)
>> MSR: 00029000 <EE,ME> CR: 42022088 XER: 20000000
>> DEAR: 00000000, ESR: 00000000
>> TASK = c081e000[1] 'swapper' THREAD: c0820000
>> GPR00: b1000000 c0821da0 c081e000 c0833e10 00000004 c0821d80 c03d3064 c05eea80
>> GPR08: 00000200 00000002 0000002a 13ab6680 82022042 00000000 c03318a4 c033188c
>> GPR16: c0331908 c03318f0 c03a0e30 c0331930 c033191c 007fff00 0ffeccbc c03a0000
>> GPR24: c0821dc4 00000000 00000003 c0934cf8 cffffba8 00000000 c0833e00 c07fdc6c
>> NIP [c018f03c] of_platform_serial_probe+0x118/0x1e4
>> LR [c018f00c] of_platform_serial_probe+0xe8/0x1e4
>> Call Trace:
>
> Ok, that is a NULL pointer access, probably somewhere in the
> of_platform_serial_setup that can be inlined. Please post the
> device tree entries for your serial ports so we can see what
> goes wrong there.
The device tree is the default one which comes with the kernel:
paulus.git/arch/powerpc/boot/dts/mpc8540ads.dts
which contains:
serial@4500 {
device_type = "serial";
compatible = "ns16550";
reg = <4500 100>; // reg base, size
clock-frequency = <0>; // should we fill in in uboot?
interrupts = <2a 2>;
interrupt-parent = <&mpic>;
};
serial@4600 {
device_type = "serial";
compatible = "ns16550";
reg = <4600 100>; // reg base, size
clock-frequency = <0>; // should we fill in in uboot?
interrupts = <2a 2>;
interrupt-parent = <&mpic>;
};
> One potential problem that I can see is a missing 'current-speed'
> property in your tree, which would cause this behavior.
That's correct. Should be fixed in all .dts' ?
> It looks
> like many device trees set this, but it is not required by all
> bindings.
How should someone know, when it's really needed and when not?
> If that's the case, the patch below should fix your
> problem, but you probably want to set the current-speed anyway,
> according to your boot loader settings.
I think there was no need to set it again, because of: console=ttyS0,115200
But I'll verify...
> --- a/drivers/serial/of_serial.c
> +++ b/drivers/serial/of_serial.c
> @@ -56,7 +56,8 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
> port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
> | UPF_FIXED_PORT;
> port->dev = &ofdev->dev;
> - port->custom_divisor = *clk / (16 * (*spd));
> + if (spd)
> + port->custom_divisor = *clk / (16 * (*spd));
>
> return 0;
> }
>
Ack! However, I changed it similar to the available code.
No idea what's better here. At least it should tell the user:
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 42) is a 16550A
console [ttyS0] enabled
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 42) is a 16550A
of_serial e0004500.serial: no current-speed property set
of_serial e0004600.serial: no current-speed property set
Patch attached.
Regards,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
[-- Attachment #2: of_serial-check-current-speed.patch --]
[-- Type: text/plain, Size: 741 bytes --]
Warn user when current-speed property isn't set and exit.
Signed-off-by: Clemens Koller <clemens.koller@anagramm.de>
CC: Arnd Bergmann <arnd@arndb.de>
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index a64d858..e035cb2 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -36,6 +36,10 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
memset(port, 0, sizeof *port);
spd = of_get_property(np, "current-speed", NULL);
clk = of_get_property(np, "clock-frequency", NULL);
+ if (!spd) {
+ dev_warn(&ofdev->dev, "no current-speed property set\n");
+ return -ENODEV;
+ }
if (!clk) {
dev_warn(&ofdev->dev, "no clock-frequency property set\n");
return -ENODEV;
^ permalink raw reply related
* Re: 2.6 kernel hangs after loading device tree
From: Clemens Koller @ 2007-11-20 11:08 UTC (permalink / raw)
To: abhi_linux; +Cc: linuxppc-embedded
In-Reply-To: <13848328.post@talk.nabble.com>
> charanya venkatraman wrote:
>> Hi all
>> Sorry about the previous mail.Got sent by mistake.
>>
>> Iam using the 2.6.22.5 kernel on MPC 8560 and MPC8540 on my custom
>> board.Mykernel hangs after loading the device tree in both the
>> processors. There is
>> no output on the serial port after loading the device tree.
>> I have tried the following console arguments:
>> MPC8540: bootargs root=/dev/ram rw console=ttyS0,115200
>> MPC8560:bootargs root=/dev/ram rw console=ttyCPM0,115200
>>
>> Any help on this issue??
Maybe your problem is related to... See the thread at:
http://ozlabs.org/pipermail/linuxppc-embedded/2007-November/028968.html
(I use Paulus' git tree.)
Regards,
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* RE: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2 (RGMII Timing)
From: Li Yang @ 2007-11-20 11:08 UTC (permalink / raw)
To: jgarzik, Phillips Kim, Kumar Gala, netdev, linuxppc-dev; +Cc: paulus
In-Reply-To: <20071105121530.5c38fbb7.kim.phillips@freescale.com>
> -----Original Message-----
> From: Phillips Kim=20
> Sent: Tuesday, November 06, 2007 2:16 AM
> To: Li Yang-r58472; Kumar Gala; netdev@vger.kernel.org;=20
> linuxppc-dev@ozlabs.org
> Cc: jgarzik@pobox.com; paulus@samba.org
> Subject: [PATCH 0/5] fixups for mpc8360 rev. 2.1 erratum #2=20
> (RGMII Timing)
>=20
> Hello all,
>=20
> the following patches fix RGMII timing for rev. 2.1 of the=20
> mpc8360, according to erratum #2 (erratum text included=20
> below). Basically the most intrusive part is the addition of=20
> two new RGMII Internal Delay modes; one for TX delay only,=20
> and the other for RX delay only (i.e, not both at the same time).
>=20
> Please review, and since this affects both netdev and powerpc=20
> trees, one maintainer should ack them for the other to push=20
> upstream (i.e, Kumar acks them, and Leo picks them up to go=20
> through netdev or the other way around; either way is fine=20
> with me). I'm hoping they're trivial enough to go in 2.6.24.
>=20
> Depending on how the review goes, a follow-on patch to u-boot=20
> will be sent out that fixes up the phy-connection-type in the=20
> device tree (from "rgmii-id" to "rgmii-rxid" iff on mpc8360rev2.1).
>=20
2-4
Acked-by: Li Yang <leoli@freescale.com>
^ permalink raw reply
* dtc: Don't use env(1) in testsuite
From: David Gibson @ 2007-11-20 11:14 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
The run_tests.sh script currently invokes the testcase binaries via
env(1). This behaviour is inherited from the libhugetlbfs testsuite
which uses this approach to easily set various configuration
environment variables in testcases.
We don't use that for dtc, and are unlikely to ever want to.
Therefore this patch removes that technique, which substantially
speeds up the testsuite.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/tests/run_tests.sh
===================================================================
--- dtc.orig/tests/run_tests.sh 2007-11-20 22:06:12.000000000 +1100
+++ dtc/tests/run_tests.sh 2007-11-20 22:06:22.000000000 +1100
@@ -2,8 +2,6 @@
export QUIET_TEST=1
-ENV=/usr/bin/env
-
tot_tests=0
tot_pass=0
tot_fail=0
@@ -13,7 +11,7 @@
run_test () {
tot_tests=$[tot_tests + 1]
echo -n "$@: "
- if PATH=".:$PATH" $ENV "$@"; then
+ if "./$@"; then
tot_pass=$[tot_pass + 1]
else
ret="$?"
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* RE: [PATCH] powerpc: mpc832x mds: Fix board PHY reset code
From: Li Yang @ 2007-11-20 11:30 UTC (permalink / raw)
To: Phillips Kim, Kumar Gala, linuxppc-dev; +Cc: Van Ackeren Peter
In-Reply-To: <20071119190443.7c04ae6b.kim.phillips@freescale.com>
> -----Original Message-----
> From: Phillips Kim=20
> Sent: Tuesday, November 20, 2007 9:05 AM
> To: Kumar Gala; linuxppc-dev@ozlabs.org
> Cc: Van Ackeren Peter; Li Yang
> Subject: [PATCH] powerpc: mpc832x mds: Fix board PHY reset code
>=20
> currently the board-level PHY reset code for the mpc832x MDS=20
> messes with reset configuration words source settings which=20
> is plain wrong (it looks like this board code was=20
> cut-n-pasted from the mpc8360 mds code, which has the PHY=20
> reset bits in a different BCSR); this patch points the PHY=20
> reset code to the proper mpc832x mds PHY reset bits in the BCSR.
>=20
> Signed-off-by: Peter Van Ackeren <peter.vanackeren@freescale.com>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Acked-by: Li Yang <leoli@freescale.com>
> ---
> arch/powerpc/platforms/83xx/mpc832x_mds.c | 7 ++++---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>=20
> diff --git a/arch/powerpc/platforms/83xx/mpc832x_mds.c=20
> b/arch/powerpc/platforms/83xx/mpc832x_mds.c
> index 972fa85..9e3bfcc 100644
> --- a/arch/powerpc/platforms/83xx/mpc832x_mds.c
> +++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c
> @@ -90,10 +90,11 @@ static void __init mpc832x_sys_setup_arch(void)
> =20
> if ((np =3D of_find_compatible_node(NULL, "network", "ucc_geth"))
> !=3D NULL){
> - /* Reset the Ethernet PHY */
> - bcsr_regs[9] &=3D ~0x20;
> + /* Reset the Ethernet PHYs */
> +#define BCSR8_FETH_RST 0x50
> + bcsr_regs[8] &=3D ~BCSR8_FETH_RST;
> udelay(1000);
> - bcsr_regs[9] |=3D 0x20;
> + bcsr_regs[8] |=3D BCSR8_FETH_RST;
> iounmap(bcsr_regs);
> of_node_put(np);
> }
> --
> 1.5.2.2
>=20
>=20
^ permalink raw reply
* Re: Oops: of_platform_serial_probe
From: Arnd Bergmann @ 2007-11-20 12:05 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4742BC57.7020305@anagramm.de>
On Tuesday 20 November 2007, Clemens Koller wrote:
> The device tree is the default one which comes with the kernel:
> paulus.git/arch/powerpc/boot/dts/mpc8540ads.dts
> which contains:
>=20
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0serial@4500 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0device_type =3D "seria=
l";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "ns1655=
0";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <4500 100>; =
=A0 =A0 =A0 // reg base, size
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0clock-frequency =3D <0=
>; =A0// should we fill in in uboot?
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupts =3D <2a 2>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupt-parent =3D <=
&mpic>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
>=20
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0serial@4600 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0device_type =3D "seria=
l";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "ns1655=
0";
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <4600 100>; =
=A0 =A0 =A0 // reg base, size
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0clock-frequency =3D <0=
>; =A0// should we fill in in uboot?
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupts =3D <2a 2>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupt-parent =3D <=
&mpic>;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0};
>=20
> =A0> One potential problem that I can see is a missing 'current-speed'
> =A0> property in your tree, which would cause this behavior.
>=20
> That's correct. Should be fixed in all .dts' ?
=20
It depends a lot on how the systems are used. current-speed only makes
sense if there is a boot loader that also does some serial I/O at a
speed it sets up itself.
> =A0> It looks
> =A0> like many device trees set this, but it is not required by all
> =A0> bindings.
>=20
> How should someone know, when it's really needed and when not?
The point of current-speed is that the kernel can tell what bitrate
was used by the boot loader and set up the same speed so that your
terminal emulation does not get garbled output when changing from
boot loader messages to kernel messages.
> =A0> If that's the case, the patch below should fix your
> =A0> problem, but you probably want to set the current-speed anyway,
> =A0> according to your boot loader settings.
>=20
> I think there was no need to set it again, because of: console=3DttyS0,11=
5200
> But I'll verify...
When current-speed is set, you don't need to override the speed at the
command line.
> @@ -36,6 +36,10 @@ static int __devinit of_platform_serial_setup(struct o=
f_device *ofdev,
> =A0=A0=A0=A0=A0=A0=A0=A0memset(port, 0, sizeof *port);
> =A0=A0=A0=A0=A0=A0=A0=A0spd =3D of_get_property(np, "current-speed", NULL=
);
> =A0=A0=A0=A0=A0=A0=A0=A0clk =3D of_get_property(np, "clock-frequency", NU=
LL);
> +=A0=A0=A0=A0=A0=A0=A0if (!spd) {
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0dev_warn(&ofdev->dev, "no c=
urrent-speed property set\n");
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0return -ENODEV;
> +=A0=A0=A0=A0=A0=A0=A0}
> =A0=A0=A0=A0=A0=A0=A0=A0if (!clk) {
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0dev_warn(&ofdev->dev, "no=
clock-frequency property set\n");
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0return -ENODEV;
This looks wrong. Since the current-speed property is not mandated by open =
firmware,
we should not error out here, but simply use the setting from the command l=
ine
or whatever other defaults can be used. Not setting port->custom_divisor at=
all
should do the job.
Arnd <><
^ permalink raw reply
* Re: Problem with uboot on lite5200
From: Clemens Koller @ 2007-11-20 12:18 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Leo Hendrawan, linuxppc-embedded
In-Reply-To: <20071119211347.575522479C@gemini.denx.de>
Hello, Wolfgang!
Wolfgang Denk schrieb:
> In message <47403C73.9040506@anagramm.de> you wrote:
>> How should people get a glue what's current, when in the section
>> "Latest News" at http://sourceforge.net/projects/u-boot/ the people
>> still find a more or less official looking "u-boot-1.1.5" release.
>
> Maybe by reading the very first two lines on the SF page:
>
> ...
> NOTE: current source code is available from DENX git
> repository and FTP server; see http://www.denx.de/en/Software/GIT
I tried to convince you to point them to the releases... and _not_
to any repository.
> The problem is that you cannot really "shut down" a SourceForge
> project (please correct me if I'm wrong).
I don't like SourceForge for some reasons... now, if that's true,
I got one more. But anyway, there should be a way to update the
"Latest News"... in a way it points to current stuff.
>>> Current U-Boot is 1.3.0-rc4. Please wake up.
>> Well... maybe it's better to remove all references to the old
>> releases at sourceforge and point them to ftp://ftp.denx.de/pub/u-boot/
>
> Can you please teach me how to do that?
I would expect that one of the project admins (i.e. you) is able
to update the site information.
You could update the SF project as you did since u-boot-0.2.0.
If you don't want to continue with SF, propably an update to
a "last SF version" with nothing more than an README should
suffice.
Well, I know you expect people to read...
I'm just wondering why so many people use ancient versions. (-:
> And 1.3.0 will be out in less than 2 hours from now :-)
Well... that's great... thank you all!
Regards,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* NULL dereference in clockevents_program_event
From: Johannes Berg @ 2007-11-19 20:06 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linuxppc-dev list, Ingo Molnar, Paul Mackerras, Linux Kernel list
[-- Attachment #1: Type: text/plain, Size: 750 bytes --]
Hi,
During a hibernate cycle on my G5, while machine was powering down after
saving the image, I just had a NULL dereference in
clockevents_program_event when accessing dev->mode, dev was NULL.
Unfortunately the machine rebooted before I was able to write down more
than the fact that it was called from tick_program_event(); the problem
doesn't seem to be easily reproducible.
From what I can see when doing the same thing, the shutdown attempts to
offline all CPUs. Because the snapshot was actually saved to disk and
the machine was shutting down I guess that the it happened at that time,
but I have no idea what else to do to debug this.
I have
| CONFIG_HIGH_RES_TIMERS=y
| CONFIG_NO_HZ=y
in this config.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: Oops: of_platform_serial_probe
From: Clemens Koller @ 2007-11-20 12:49 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-embedded
In-Reply-To: <200711201305.47753.arnd@arndb.de>
>> @@ -36,6 +36,10 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
>> memset(port, 0, sizeof *port);
>> spd = of_get_property(np, "current-speed", NULL);
>> clk = of_get_property(np, "clock-frequency", NULL);
>> + if (!spd) {
>> + dev_warn(&ofdev->dev, "no current-speed property set\n");
>> + return -ENODEV;
>> + }
>> if (!clk) {
>> dev_warn(&ofdev->dev, "no clock-frequency property set\n");
>> return -ENODEV;
>
> This looks wrong. Since the current-speed property is not mandated by open firmware,
> we should not error out here, but simply use the setting from the command line
> or whatever other defaults can be used. Not setting port->custom_divisor at all
> should do the job.
Understood... but then, my console just stops / gets reinitialized to some unknown
baudrate when I get to of_serial.c. :-(
Regards,
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* Re: libfdt: Abolish fdt_offset_ptr_typed()
From: Jon Loeliger @ 2007-11-20 15:06 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071119062622.GL20794@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> The fdt_offset_ptr_typed() macro seemed like a good idea at the time.
> However, it's not actually used all that often, it can silently throw
> away const qualifications and it uses a gcc extension (typeof) which
> I'd prefer to avoid for portability.
>
> Therefore, this patch gets rid of it (and the fdt_offset_ptr_typed_w()
> variant which was never used at all). It also makes a few variables
> const in testcases, which always should have been const, but weren't
> caught before because of the aforementioned silent discards.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
jdl
^ permalink raw reply
* Re: libfdt: Abolish _typed() variants, add _cell() variants
From: Jon Loeliger @ 2007-11-20 15:06 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071120023546.GA4356@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> In a number of places through libfdt and its tests, we have *_typed()
> macro variants on functions which use gcc's typeof and statement
> expression extensions to allow passing literals where the underlying
> function takes a buffer and size.
>
> These seemed like a good idea at the time, but in fact they have some
> problems. They use typeof and statement expressions, extensions I'd
> prefer to avoid for portability. Plus, they have potential gotchas -
> although they'll deal with the size of the thing passed, they won't
> deal with other representation issues (like endianness) and results
> could be very strange if the type of the expression passed isn't what
> you think it is.
>
> In fact, the only users of these _typed() macros were when the value
> passed is a single cell (32-bit integer). Therefore, this patch
> removes all these _typed() macros and replaces them with explicit
> _cell() variants which handle a single 32-bit integer, and which also
> perform endian convesions as appropriate.
>
> With this in place, it now becomes easy to use standardized big-endian
> representation for integer valued properties in the testcases,
> regardless of the platform we're running on. We therefore do that,
> which has the additional advantage that all the example trees created
> during a test run are now byte-for-byte identical regardless of
> platform.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
jdl
^ 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