* Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
From: Olof Johansson @ 2007-11-27 15:23 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.62.0711271555520.5847@pademelon.sonytel.be>
On Tue, Nov 27, 2007 at 03:56:53PM +0100, Geert Uytterhoeven wrote:
> On Wed, 21 Nov 2007, Geert Uytterhoeven wrote:
> > On Tue, 20 Nov 2007, Kumar Gala wrote:
> > > On Nov 20, 2007, at 11:54 AM, Scott Wood wrote:
> > > > On Mon, Nov 19, 2007 at 09:36:57PM -0600, Kumar Gala wrote:
> > > >> isel (Integer Select) is a new user space instruction in the
> > > >> PowerISA 2.04 spec. Not all processors implement it so lets emulate
> > > >> to ensure code built with isel will run everywhere.
> > > >
> > > > Given that the instruction is meant to be a performance enhancement,
> > > > we should probably warn the first few times it's emulated, so the user
> > > > knows they should change their toolchain setup if possible.
> > >
> > > The same is true of mcrxr, popcntb, and possibly string ld/st.
> > >
> > > Feel free to submit a patch that warns about their usage.
> >
> > Something like this?
>
> New version below.
>
> Do we want it in sysfs? Or should we use debugfs instead?
I like this, and I'd say it's useful to have in sysfs. Few production
systems enable debugfs, and this is something that could be useful to
have access to there.
> Subject: powerpc: Keep track of emulated instructions
>
> From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
>
> powerpc: Keep track of emulated instructions
>
> Counters for the various classes of emulated instructions are available under
> /sys/devices/system/cpu/cpu*/emulated/.
> Optionally, rate-limited warnings can be printed to the console when
> instructions are emulated.
>
> Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
> ---
> arch/powerpc/Kconfig.debug | 10 ++++++
> arch/powerpc/kernel/align.c | 17 ++++++++--
> arch/powerpc/kernel/sysfs.c | 64 ++++++++++++++++++++++++++++++++++++++++-
> arch/powerpc/kernel/traps.c | 17 +++++++++-
> include/asm-powerpc/emulator.h | 60 ++++++++++++++++++++++++++++++++++++++
This name stood out as being a bit too generic, emulator could mean
system support for running under some sort of emulator as well. How
about emulated_ops.h?
> +config DEBUG_WARN_EMULATED
> + bool "Warn if emulated instructions are used"
> + depends on DEBUG_KERNEL && SYSFS
> + help
> + This option will cause messages to be printed if an instruction is
> + emulated.
> + Counters for emulated instruction usages are always available under
> + /sys/devices/system/cpu/cpu*/emulated/, irrespective of the state
> + of this option.
How about making it a sysctl instead, so it can be flipped at runtime
(but default off)?
-Olof
^ permalink raw reply
* Re: [PATCH] [POWERPC] Emulate isel (Integer Select) instruction
From: Geert Uytterhoeven @ 2007-11-27 14:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.62.0711211407260.12720@pademelon.sonytel.be>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 10848 bytes --]
On Wed, 21 Nov 2007, Geert Uytterhoeven wrote:
> On Tue, 20 Nov 2007, Kumar Gala wrote:
> > On Nov 20, 2007, at 11:54 AM, Scott Wood wrote:
> > > On Mon, Nov 19, 2007 at 09:36:57PM -0600, Kumar Gala wrote:
> > >> isel (Integer Select) is a new user space instruction in the
> > >> PowerISA 2.04 spec. Not all processors implement it so lets emulate
> > >> to ensure code built with isel will run everywhere.
> > >
> > > Given that the instruction is meant to be a performance enhancement,
> > > we should probably warn the first few times it's emulated, so the user
> > > knows they should change their toolchain setup if possible.
> >
> > The same is true of mcrxr, popcntb, and possibly string ld/st.
> >
> > Feel free to submit a patch that warns about their usage.
>
> Something like this?
New version below.
Do we want it in sysfs? Or should we use debugfs instead?
Subject: powerpc: Keep track of emulated instructions
From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
powerpc: Keep track of emulated instructions
Counters for the various classes of emulated instructions are available under
/sys/devices/system/cpu/cpu*/emulated/.
Optionally, rate-limited warnings can be printed to the console when
instructions are emulated.
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
arch/powerpc/Kconfig.debug | 10 ++++++
arch/powerpc/kernel/align.c | 17 ++++++++--
arch/powerpc/kernel/sysfs.c | 64 ++++++++++++++++++++++++++++++++++++++++-
arch/powerpc/kernel/traps.c | 17 +++++++++-
include/asm-powerpc/emulator.h | 60 ++++++++++++++++++++++++++++++++++++++
5 files changed, 161 insertions(+), 7 deletions(-)
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -284,4 +284,14 @@ config PPC_EARLY_DEBUG_CPM_ADDR
platform probing is done, all platforms selected must
share the same address.
+config DEBUG_WARN_EMULATED
+ bool "Warn if emulated instructions are used"
+ depends on DEBUG_KERNEL && SYSFS
+ help
+ This option will cause messages to be printed if an instruction is
+ emulated.
+ Counters for emulated instruction usages are always available under
+ /sys/devices/system/cpu/cpu*/emulated/, irrespective of the state
+ of this option.
+
endmenu
--- a/arch/powerpc/kernel/align.c
+++ b/arch/powerpc/kernel/align.c
@@ -24,6 +24,7 @@
#include <asm/system.h>
#include <asm/cache.h>
#include <asm/cputable.h>
+#include <asm/emulator.h>
struct aligninfo {
unsigned char len;
@@ -696,8 +697,10 @@ int fix_alignment(struct pt_regs *regs)
areg = dsisr & 0x1f; /* register to update */
#ifdef CONFIG_SPE
- if ((instr >> 26) == 0x4)
+ if ((instr >> 26) == 0x4) {
+ WARN_EMULATE(spe);
return emulate_spe(regs, reg, instr);
+ }
#endif
instr = (dsisr >> 10) & 0x7f;
@@ -731,17 +734,21 @@ int fix_alignment(struct pt_regs *regs)
/* A size of 0 indicates an instruction we don't support, with
* the exception of DCBZ which is handled as a special case here
*/
- if (instr == DCBZ)
+ if (instr == DCBZ) {
+ WARN_EMULATE(dcbz);
return emulate_dcbz(regs, addr);
+ }
if (unlikely(nb == 0))
return 0;
/* Load/Store Multiple instructions are handled in their own
* function
*/
- if (flags & M)
+ if (flags & M) {
+ WARN_EMULATE(multiple);
return emulate_multiple(regs, addr, reg, nb,
flags, instr, swiz);
+ }
/* Verify the address of the operand */
if (unlikely(user_mode(regs) &&
@@ -758,8 +765,10 @@ int fix_alignment(struct pt_regs *regs)
}
/* Special case for 16-byte FP loads and stores */
- if (nb == 16)
+ if (nb == 16) {
+ WARN_EMULATE(fp_pair);
return emulate_fp_pair(regs, addr, reg, flags);
+ }
/* If we are loading, get the data from user space, else
* get it from register values
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -19,6 +19,7 @@
#include <asm/lppaca.h>
#include <asm/machdep.h>
#include <asm/smp.h>
+#include <asm/emulator.h>
static DEFINE_PER_CPU(struct cpu, cpu_devices);
@@ -291,12 +292,68 @@ static struct sysdev_attribute pa6t_attr
};
+#define SYSFS_EMULATED_SETUP(type) \
+DEFINE_PER_CPU(atomic_long_t, emulated_ ## type); \
+static ssize_t show_emulated_ ## type (struct sys_device *dev, \
+ char *buf) \
+{ \
+ struct cpu *cpu = container_of(dev, struct cpu, sysdev); \
+ \
+ return sprintf(buf, "%lu\n", \
+ atomic_long_read(&per_cpu(emulated_ ## type, \
+ cpu->sysdev.id))); \
+} \
+ \
+static struct sysdev_attribute emulated_ ## type ## _attr = { \
+ .attr = { .name = #type, .mode = 0400 }, \
+ .show = show_emulated_ ## type, \
+};
+
+SYSFS_EMULATED_SETUP(dcba);
+SYSFS_EMULATED_SETUP(dcbz);
+SYSFS_EMULATED_SETUP(fp_pair);
+SYSFS_EMULATED_SETUP(mcrxr);
+SYSFS_EMULATED_SETUP(mfpvr);
+SYSFS_EMULATED_SETUP(multiple);
+SYSFS_EMULATED_SETUP(popcntb);
+SYSFS_EMULATED_SETUP(spe);
+SYSFS_EMULATED_SETUP(string);
+#ifdef CONFIG_MATH_EMULATION
+SYSFS_EMULATED_SETUP(math);
+#elif defined(CONFIG_8XX_MINIMAL_FPEMU)
+SYSFS_EMULATED_SETUP(8xx);
+#endif
+
+static struct attribute *emulated_attrs[] = {
+ &emulated_dcba_attr.attr,
+ &emulated_dcbz_attr.attr,
+ &emulated_fp_pair_attr.attr,
+ &emulated_mcrxr_attr.attr,
+ &emulated_mfpvr_attr.attr,
+ &emulated_multiple_attr.attr,
+ &emulated_popcntb_attr.attr,
+ &emulated_spe_attr.attr,
+ &emulated_string_attr.attr,
+#ifdef CONFIG_MATH_EMULATION
+ &emulated_math_attr.attr,
+#elif defined(CONFIG_8XX_MINIMAL_FPEMU)
+ &emulated_8xx_attr.attr,
+#endif
+ NULL
+};
+
+static struct attribute_group emulated_attr_group = {
+ .attrs = emulated_attrs,
+ .name = "emulated"
+};
+
+
static void register_cpu_online(unsigned int cpu)
{
struct cpu *c = &per_cpu(cpu_devices, cpu);
struct sys_device *s = &c->sysdev;
struct sysdev_attribute *attrs, *pmc_attrs;
- int i, nattrs;
+ int i, nattrs, res;
if (!firmware_has_feature(FW_FEATURE_ISERIES) &&
cpu_has_feature(CPU_FTR_SMT))
@@ -339,6 +396,11 @@ static void register_cpu_online(unsigned
if (cpu_has_feature(CPU_FTR_DSCR))
sysdev_create_file(s, &attr_dscr);
+
+ res = sysfs_create_group(&s->kobj, &emulated_attr_group);
+ if (res)
+ pr_warning("Cannot create emulated sysfs group for cpu %u\n",
+ cpu);
}
#ifdef CONFIG_HOTPLUG_CPU
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -53,6 +53,7 @@
#include <asm/processor.h>
#endif
#include <asm/kexec.h>
+#include <asm/emulator.h>
#ifdef CONFIG_DEBUGGER
int (*__debugger)(struct pt_regs *regs);
@@ -721,31 +722,38 @@ static int emulate_instruction(struct pt
/* Emulate the mfspr rD, PVR. */
if ((instword & INST_MFSPR_PVR_MASK) == INST_MFSPR_PVR) {
+ WARN_EMULATE(mfpvr);
rd = (instword >> 21) & 0x1f;
regs->gpr[rd] = mfspr(SPRN_PVR);
return 0;
}
/* Emulating the dcba insn is just a no-op. */
- if ((instword & INST_DCBA_MASK) == INST_DCBA)
+ if ((instword & INST_DCBA_MASK) == INST_DCBA) {
+ WARN_EMULATE(dcba);
return 0;
+ }
/* Emulate the mcrxr insn. */
if ((instword & INST_MCRXR_MASK) == INST_MCRXR) {
int shift = (instword >> 21) & 0x1c;
unsigned long msk = 0xf0000000UL >> shift;
+ WARN_EMULATE(mcrxr);
regs->ccr = (regs->ccr & ~msk) | ((regs->xer >> shift) & msk);
regs->xer &= ~0xf0000000UL;
return 0;
}
/* Emulate load/store string insn. */
- if ((instword & INST_STRING_GEN_MASK) == INST_STRING)
+ if ((instword & INST_STRING_GEN_MASK) == INST_STRING) {
+ WARN_EMULATE(string);
return emulate_string_inst(regs, instword);
+ }
/* Emulate the popcntb (Population Count Bytes) instruction. */
if ((instword & INST_POPCNTB_MASK) == INST_POPCNTB) {
+ WARN_EMULATE(popcntb);
return emulate_popcntb_inst(regs, instword);
}
@@ -929,6 +937,8 @@ void SoftwareEmulation(struct pt_regs *r
#ifdef CONFIG_MATH_EMULATION
errcode = do_mathemu(regs);
+ if (errcode >= 0)
+ WARN_EMULATE(math);
switch (errcode) {
case 0:
@@ -950,6 +960,9 @@ void SoftwareEmulation(struct pt_regs *r
#elif defined(CONFIG_8XX_MINIMAL_FPEMU)
errcode = Soft_emulate_8xx(regs);
+ if (errcode >= 0)
+ WARN_EMULATE(8xx);
+
switch (errcode) {
case 0:
emulate_single_step(regs);
--- /dev/null
+++ b/include/asm-powerpc/emulator.h
@@ -0,0 +1,60 @@
+/*
+ * Copyright 2007 Sony Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef _ASM_POWERPC_EMULATOR_H
+#define _ASM_POWERPC_EMULATOR_H
+
+#include <linux/kernel.h>
+#include <linux/percpu.h>
+
+#include <asm/atomic.h>
+
+DECLARE_PER_CPU(atomic_long_t, emulated_dcba);
+DECLARE_PER_CPU(atomic_long_t, emulated_dcbz);
+DECLARE_PER_CPU(atomic_long_t, emulated_fp_pair);
+DECLARE_PER_CPU(atomic_long_t, emulated_mcrxr);
+DECLARE_PER_CPU(atomic_long_t, emulated_mfpvr);
+DECLARE_PER_CPU(atomic_long_t, emulated_multiple);
+DECLARE_PER_CPU(atomic_long_t, emulated_popcntb);
+DECLARE_PER_CPU(atomic_long_t, emulated_spe);
+DECLARE_PER_CPU(atomic_long_t, emulated_string);
+#ifdef CONFIG_MATH_EMULATION
+DECLARE_PER_CPU(atomic_long_t, emulated_math);
+#elif defined(CONFIG_8XX_MINIMAL_FPEMU)
+DECLARE_PER_CPU(atomic_long_t, emulated_8xx);
+#endif
+
+#ifdef CONFIG_DEBUG_WARN_EMULATED
+static inline void do_warn_emulate(const char *type)
+{
+ if (printk_ratelimit())
+ pr_warning("%s used emulated %s instruction\n", current->comm,
+ type);
+}
+#else
+static inline void do_warn_emulate(const char *type) {}
+#endif
+
+#define WARN_EMULATE(type) \
+ do { \
+ atomic_long_inc(&per_cpu(emulated_ ## type, \
+ raw_smp_processor_id())); \
+ do_warn_emulate(#type); \
+ } while (0)
+
+
+#endif /* _ASM_POWERPC_EMULATOR_H */
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: 85xx software reset problems from paulus.git
From: Dale Farnsworth @ 2007-11-27 14:54 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20071127135051.32227.qmail@farnsworth.org>
I wrote:
> Kumar Gala wrote:
> > >> Yes. The symptoms in 2.6.24RC2 are that during a kernel panic or when
> > >> calling 'reboot' in the shell, it just hangs. Using the same dts and
> > >> resets in 2.6.23.1 reboots fine. I don't have a cds reference, but
> > >> someone who does should be able to confirm whether the issue exists
> > >> or
> > >> not by just attempting to reboot via bash.
> >
> > Can someone do a git-bisect and find the patch that breaks things?
>
> I'll see if I can reproduce it on my 8548cds. If so, I'll then git-bisect.
I tried this with the current powerpc.git tree on my mpc8548cds, and
the reboot command works for me. The system rebooted just fine.
-Dale
^ permalink raw reply
* RE: [PATCH v2] [POWERPC] Optimize counting distinct entries in the relocation sections
From: Medve Emilian @ 2007-11-27 14:54 UTC (permalink / raw)
To: paulus, rusty, ntl, sfr, behlendorf1, galak, linuxppc-dev,
linuxppc-embedded
In-Reply-To: <1194971044-28840-1-git-send-email-Emilian.Medve@Freescale.com>
Hi Paul,
I'm just wondering what are your latest thoughts about this patch
(http://patchwork.ozlabs.org/linuxppc/patch?id=3D14707).
Cheers,
Emil.
> -----Original Message-----
> From: Medve Emilian=20
> Sent: Tuesday, November 13, 2007 10:24 AM
> To: paulus@samba.org; rusty@rustcorp.com.au; ntl@pobox.com;=20
> sfr@canb.auug.org.au; behlendorf1@llnl.gov;=20
> galak@kernel.crashing.org; linuxppc-dev@ozlabs.org;=20
> linuxppc-embedded@ozlabs.org
> Cc: Medve Emilian
> Subject: [PATCH v2] [POWERPC] Optimize counting distinct=20
> entries in the relocation sections
>=20
> When a module has relocation sections with tens of thousands=20
> worth of entries,
> counting the distinct/unique entries only (i.e. no=20
> duplicates) at load time can
> take tens of seconds and up to minutes. The sore point is the=20
> count_relocs()
> function which is called as part of the architecture specific=20
> module loading
> processing path:
>=20
> -> load_module() generic
> -> module_frob_arch_sections() arch specific
> -> get_plt_size() 32-bit
> -> get_stubs_size() 64-bit
> -> count_relocs()
>=20
> (Not sure why the relocation tables could contain lots of=20
> duplicates and why
> they are not trimmed at compile time by the linker. In some=20
> test cases, out of
> 35K relocation entries only 1.5K were distinct/unique)
>=20
> The previous counting algorithm was having O(n^2) complexity.=20
> Basically two
> solutions were proposed on the e-mail list: a hash based=20
> approach and a sort
> based approach
>=20
> The hash based approach is the fastest (O(n)) but the has it=20
> needs additional
> memory and for certain corner cases it could take lots of=20
> memory due to the
> degeneration of the hash. One such proposal was submitted here:
>=20
> http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037641.html
>=20
> In this proposal, the symbol + addendum are hashed to=20
> generate a key and a
> pointer to the relocation entry will be stored in it. The=20
> hash is implemented as
> a linked list of memory pages with PAGE_SIZE /=20
> sizeof(Elfxx_Rela *) entries. In
> case of collisions in all the existing pages, a new page is=20
> added to the list to
> accommodate the new distinct relocation entry
>=20
> For 32-bit PowerPCs with 4K pages, a page can accommodate 1K=20
> worth of pointers
> to relocation entries. In the 35K entries scenario, as=20
> much/little of six (6)
> pages could be allocated using 24K of extra memory during the=20
> module load
>=20
> The sort based approach is slower (O(n * log n + n)) but if=20
> the sorting is done
> "in place" it doesn't need additional memory. A proposal was=20
> submitted here:
>=20
> http://ozlabs.org/pipermail/linuxppc-dev/2007-November/045854.html
> =
(http://patchwork.ozlabs.org/linuxppc/patch?filter=3Ddefault&id=3D14573)
>=20
> In this proposal an array of pointers to the relocation=20
> entries is built and
> then is sorted using the kernel sort() utility function. This=20
> is basically a heap
> sort algorithm with a stable O(n * log n) complexity. With=20
> this counting the
> distinct/unique entries is just linear (O(n)) complexity. The=20
> problem is the
> extra memory needed in this proposal, which in the 35K=20
> relocation entries test
> case it can be as much as 140K (for 32-bit PowerPCs; double=20
> for 64-bit). This is
> much more then the memory needed by the hash based approach described
> above/earlier but it doesn't hide potential degenerative corner cases
>=20
> The current patch is a happy compromise between the two=20
> proposals above:
> O(n + n * log n) performance with no additional memory=20
> requirements due to
> sorting in place the relocation table itself
>=20
> Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
> ---
>=20
> This patch only tries to address counting the distinct=20
> R_PPC_REL24 entries for
> the purpose of sizing the PLT. This operation was/can be=20
> detected by the proper
> kernel logic as a soft lockup for large relocation tables
>=20
> A related optimization (that could cause rewriting the this=20
> patch) is to
> optimize the PLT search from do_plt_call() but that doesn't=20
> seem to be a
> problem right now
>=20
> The errors below are false positives due to the fact that=20
> Elfxx_Rela are
> falsely assumed to be variables/operands instead of types:
>=20
> linux-2.6> scripts/checkpatch.pl=20
> 0001-POWERPC-Optimize-counting-distinct-entries-in-the.patch=20
> ERROR: need consistent spacing around '*' (ctx:WxV)
> #116: FILE: arch/powerpc/kernel/module_32.c:78:
> + const Elf32_Rela *x, *y;
> ^
>=20
> ERROR: need consistent spacing around '*' (ctx:WxV)
> #228: FILE: arch/powerpc/kernel/module_64.c:122:
> + const Elf64_Rela *x, *y;
> ^
>=20
> total: 2 errors, 0 warnings, 218 lines checked
> Your patch has style problems, please review. If any of these errors
> are false positives report them to the maintainer, see
> CHECKPATCH in MAINTAINERS.
>=20
> arch/powerpc/kernel/module_32.c | 77=20
> ++++++++++++++++++++++++++++++-------
> arch/powerpc/kernel/module_64.c | 81=20
> ++++++++++++++++++++++++++++++--------
> 2 files changed, 127 insertions(+), 31 deletions(-)
>=20
> diff --git a/arch/powerpc/kernel/module_32.c=20
> b/arch/powerpc/kernel/module_32.c
> index 07a89a3..eab3138 100644
> --- a/arch/powerpc/kernel/module_32.c
> +++ b/arch/powerpc/kernel/module_32.c
> @@ -24,6 +24,7 @@
> #include <linux/kernel.h>
> #include <linux/cache.h>
> #include <linux/bug.h>
> +#include <linux/sort.h>
> =20
> #include "setup.h"
> =20
> @@ -54,22 +55,60 @@ void module_free(struct module *mod, void=20
> *module_region)
> addend) */
> static unsigned int count_relocs(const Elf32_Rela *rela,=20
> unsigned int num)
> {
> - unsigned int i, j, ret =3D 0;
> -
> - /* Sure, this is order(n^2), but it's usually short, and not
> - time critical */
> - for (i =3D 0; i < num; i++) {
> - for (j =3D 0; j < i; j++) {
> - /* If this addend appeared before, it's
> - already been counted */
> - if (ELF32_R_SYM(rela[i].r_info)
> - =3D=3D ELF32_R_SYM(rela[j].r_info)
> - && rela[i].r_addend =3D=3D rela[j].r_addend)
> - break;
> + unsigned int i, r_info, r_addend, _count_relocs;
> +
> + _count_relocs =3D 0;
> + r_info =3D 0;
> + r_addend =3D 0;
> + for (i =3D 0; i < num; i++)
> + /* Only count 24-bit relocs, others don't need stubs */
> + if (ELF32_R_TYPE(rela[i].r_info) =3D=3D R_PPC_REL24 &&
> + (r_info !=3D ELF32_R_SYM(rela[i].r_info) ||
> + r_addend !=3D rela[i].r_addend)) {
> + _count_relocs++;
> + r_info =3D ELF32_R_SYM(rela[i].r_info);
> + r_addend =3D rela[i].r_addend;
> }
> - if (j =3D=3D i) ret++;
> +
> + return _count_relocs;
> +}
> +
> +static int relacmp(const void *_x, const void *_y)
> +{
> + const Elf32_Rela *x, *y;
> +
> + y =3D (Elf32_Rela *)_x;
> + x =3D (Elf32_Rela *)_y;
> +
> + /* Compare the entire r_info (as opposed to=20
> ELF32_R_SYM(r_info) only) to
> + * make the comparison cheaper/faster. It won't affect=20
> the sorting or
> + * the counting algorithms' performance
> + */
> + if (x->r_info < y->r_info)
> + return -1;
> + else if (x->r_info > y->r_info)
> + return 1;
> + else if (x->r_addend < y->r_addend)
> + return -1;
> + else if (x->r_addend > y->r_addend)
> + return 1;
> + else
> + return 0;
> +}
> +
> +static void relaswap(void *_x, void *_y, int size)
> +{
> + uint32_t *x, *y, tmp;
> + int i;
> +
> + y =3D (uint32_t *)_x;
> + x =3D (uint32_t *)_y;
> +
> + for (i =3D 0; i < sizeof(Elf32_Rela) / sizeof(uint32_t); i++) {
> + tmp =3D x[i];
> + x[i] =3D y[i];
> + y[i] =3D tmp;
> }
> - return ret;
> }
> =20
> /* Get the potential trampolines size required of the init and
> @@ -100,6 +139,16 @@ static unsigned long get_plt_size(const=20
> Elf32_Ehdr *hdr,
> DEBUGP("Ptr: %p. Number: %u\n",
> (void *)hdr + sechdrs[i].sh_offset,
> sechdrs[i].sh_size / sizeof(Elf32_Rela));
> +
> + /* Sort the relocation information=20
> based on a symbol and
> + * addend key. This is a stable O(n*log=20
> n) complexity
> + * alogrithm but it will reduce the=20
> complexity of
> + * count_relocs() to linear complexity O(n)
> + */
> + sort((void *)hdr + sechdrs[i].sh_offset,
> + sechdrs[i].sh_size / sizeof(Elf32_Rela),
> + sizeof(Elf32_Rela), relacmp, relaswap);
> +
> ret +=3D count_relocs((void *)hdr
> + sechdrs[i].sh_offset,
> sechdrs[i].sh_size
> diff --git a/arch/powerpc/kernel/module_64.c=20
> b/arch/powerpc/kernel/module_64.c
> index 75c7c4f..3a82b02 100644
> --- a/arch/powerpc/kernel/module_64.c
> +++ b/arch/powerpc/kernel/module_64.c
> @@ -24,6 +24,7 @@
> #include <asm/module.h>
> #include <asm/uaccess.h>
> #include <asm/firmware.h>
> +#include <linux/sort.h>
> =20
> #include "setup.h"
> =20
> @@ -81,25 +82,23 @@ static struct ppc64_stub_entry ppc64_stub =3D
> different addend) */
> static unsigned int count_relocs(const Elf64_Rela *rela,=20
> unsigned int num)
> {
> - unsigned int i, j, ret =3D 0;
> + unsigned int i, r_info, r_addend, _count_relocs;
> =20
> /* FIXME: Only count external ones --RR */
> - /* Sure, this is order(n^2), but it's usually short, and not
> - time critical */
> - for (i =3D 0; i < num; i++) {
> + _count_relocs =3D 0;
> + r_info =3D 0;
> + r_addend =3D 0;
> + for (i =3D 0; i < num; i++)
> /* Only count 24-bit relocs, others don't need stubs */
> - if (ELF64_R_TYPE(rela[i].r_info) !=3D R_PPC_REL24)
> - continue;
> - for (j =3D 0; j < i; j++) {
> - /* If this addend appeared before, it's
> - already been counted */
> - if (rela[i].r_info =3D=3D rela[j].r_info
> - && rela[i].r_addend =3D=3D rela[j].r_addend)
> - break;
> + if (ELF64_R_TYPE(rela[i].r_info) =3D=3D R_PPC_REL24 &&
> + (r_info !=3D ELF64_R_SYM(rela[i].r_info) ||
> + r_addend !=3D rela[i].r_addend)) {
> + _count_relocs++;
> + r_info =3D ELF64_R_SYM(rela[i].r_info);
> + r_addend =3D rela[i].r_addend;
> }
> - if (j =3D=3D i) ret++;
> - }
> - return ret;
> +
> + return _count_relocs;
> }
> =20
> void *module_alloc(unsigned long size)
> @@ -118,6 +117,44 @@ void module_free(struct module *mod,=20
> void *module_region)
> table entries. */
> }
> =20
> +static int relacmp(const void *_x, const void *_y)
> +{
> + const Elf64_Rela *x, *y;
> +
> + y =3D (Elf64_Rela *)_x;
> + x =3D (Elf64_Rela *)_y;
> +
> + /* Compare the entire r_info (as opposed to=20
> ELF64_R_SYM(r_info) only) to
> + * make the comparison cheaper/faster. It won't affect=20
> the sorting or
> + * the counting algorithms' performance
> + */
> + if (x->r_info < y->r_info)
> + return -1;
> + else if (x->r_info > y->r_info)
> + return 1;
> + else if (x->r_addend < y->r_addend)
> + return -1;
> + else if (x->r_addend > y->r_addend)
> + return 1;
> + else
> + return 0;
> +}
> +
> +static void relaswap(void *_x, void *_y, int size)
> +{
> + uint64_t *x, *y, tmp;
> + int i;
> +
> + y =3D (uint64_t *)_x;
> + x =3D (uint64_t *)_y;
> +
> + for (i =3D 0; i < sizeof(Elf64_Rela) / sizeof(uint64_t); i++) {
> + tmp =3D x[i];
> + x[i] =3D y[i];
> + y[i] =3D tmp;
> + }
> +}
> +
> /* Get size of potential trampolines required. */
> static unsigned long get_stubs_size(const Elf64_Ehdr *hdr,
> const Elf64_Shdr *sechdrs)
> @@ -133,6 +170,16 @@ static unsigned long=20
> get_stubs_size(const Elf64_Ehdr *hdr,
> DEBUGP("Ptr: %p. Number: %lu\n",
> (void *)sechdrs[i].sh_addr,
> sechdrs[i].sh_size / sizeof(Elf64_Rela));
> +
> + /* Sort the relocation information=20
> based on a symbol and
> + * addend key. This is a stable O(n*log=20
> n) complexity
> + * alogrithm but it will reduce the=20
> complexity of
> + * count_relocs() to linear complexity O(n)
> + */
> + sort((void *)sechdrs[i].sh_addr,
> + sechdrs[i].sh_size / sizeof(Elf64_Rela),
> + sizeof(Elf64_Rela), relacmp, relaswap);
> +
> relocs +=3D count_relocs((void=20
> *)sechdrs[i].sh_addr,
> sechdrs[i].sh_size
> / sizeof(Elf64_Rela));
> @@ -343,7 +390,7 @@ int apply_relocate_add(Elf64_Shdr *sechdrs,
> /* Simply set it */
> *(u32 *)location =3D value;
> break;
> - =09
> +
> case R_PPC64_ADDR64:
> /* Simply set it */
> *(unsigned long *)location =3D value;
> @@ -399,7 +446,7 @@ int apply_relocate_add(Elf64_Shdr *sechdrs,
> }
> =20
> /* Only replace bits 2 through 26 */
> - *(uint32_t *)location=20
> + *(uint32_t *)location
> =3D (*(uint32_t *)location & ~0x03fffffc)
> | (value & 0x03fffffc);
> break;
> --=20
> 1.5.3.GIT
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] fsl_soc: add support for gianfar for fixed-link property
From: Joakim Tjernlund @ 2007-11-27 14:01 UTC (permalink / raw)
To: avorontsov; +Cc: netdev, linux-kernel, Jeff Garzik, linuxppc-dev
In-Reply-To: <20071127135952.GA1483@localhost.localdomain>
On Tue, 2007-11-27 at 16:59 +0300, Anton Vorontsov wrote:
> On Tue, Nov 27, 2007 at 02:17:11PM +0100, Joakim Tjernlund wrote:
> >
> > On Tue, 2007-11-27 at 14:39 +0300, Anton Vorontsov wrote:
> > > On Mon, Nov 26, 2007 at 04:04:08PM +0100, Joakim Tjernlund wrote:
> > > > On Mon, 2007-11-26 at 17:29 +0300, Vitaly Bordug wrote:
> > > > > fixed-link says: register new "Fixed/emulated PHY", i.e. PHY that
> > > > > not connected to the real MDIO bus.
> > > > >
> > > > > Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
> > > > > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> > > > >
> > > > > ---
> > > > >
> > > > > Documentation/powerpc/booting-without-of.txt | 3 +
> > > > > arch/powerpc/sysdev/fsl_soc.c | 56 ++++++++++++++++++--------
> > > > > 2 files changed, 42 insertions(+), 17 deletions(-)
> > > > >
> > > > >
> > > > > diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> > > > > index e9a3cb1..cf25070 100644
> > > > > --- a/Documentation/powerpc/booting-without-of.txt
> > > > > +++ b/Documentation/powerpc/booting-without-of.txt
> > > > > @@ -1254,6 +1254,9 @@ platforms are moved over to use the flattened-device-tree model.
> > > > > services interrupts for this device.
> > > > > - phy-handle : The phandle for the PHY connected to this ethernet
> > > > > controller.
> > > > > + - fixed-link : <a b c> where a is emulated phy id - choose any,
> > > > > + but unique to the all specified fixed-links, b is duplex - 0 half,
> > > > > + 1 full, c is link speed - d#10/d#100/d#1000.
> > > >
> > > > Good work!
> > > > May I suggest adding a "d" to <a b c> where d is flow control - 0 no, 1 yes
> > >
> > > Well, I see no reference of the "flow" neither in the include/linux/mii.h
> > > nor in the drivers/net/phy/*. :-/ Thus today there is no such register
> > > bit we can emulate?..
> >
> > Well, as good as I can recall, flow control(pause) is something that the
> > PHY negotiates, just like FDX/HDX and should be dealt with in the
> > adjust_link callback but not many do currently.
> >
> > If you seach for pause in phy_device.c you will find it.
>
> Ah, pause. Sure, we can emulate that.
Good, looking into phy_device there seems to be 2 pauses:
ADVERTISED_Pause and ADVERTISE_PAUSE_ASYM which
maps to phydev->pause and phydev->asym_pause
so "d" should reflect that or a "e" should be added
for the asym pause.
Jocke
Jocke
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] fsl_soc: add support for gianfar for fixed-link property
From: Anton Vorontsov @ 2007-11-27 13:59 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: netdev, linux-kernel, Jeff Garzik, linuxppc-dev
In-Reply-To: <1196169432.9816.16.camel@gentoo-jocke.transmode.se>
On Tue, Nov 27, 2007 at 02:17:11PM +0100, Joakim Tjernlund wrote:
>
> On Tue, 2007-11-27 at 14:39 +0300, Anton Vorontsov wrote:
> > On Mon, Nov 26, 2007 at 04:04:08PM +0100, Joakim Tjernlund wrote:
> > > On Mon, 2007-11-26 at 17:29 +0300, Vitaly Bordug wrote:
> > > > fixed-link says: register new "Fixed/emulated PHY", i.e. PHY that
> > > > not connected to the real MDIO bus.
> > > >
> > > > Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
> > > > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> > > >
> > > > ---
> > > >
> > > > Documentation/powerpc/booting-without-of.txt | 3 +
> > > > arch/powerpc/sysdev/fsl_soc.c | 56 ++++++++++++++++++--------
> > > > 2 files changed, 42 insertions(+), 17 deletions(-)
> > > >
> > > >
> > > > diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> > > > index e9a3cb1..cf25070 100644
> > > > --- a/Documentation/powerpc/booting-without-of.txt
> > > > +++ b/Documentation/powerpc/booting-without-of.txt
> > > > @@ -1254,6 +1254,9 @@ platforms are moved over to use the flattened-device-tree model.
> > > > services interrupts for this device.
> > > > - phy-handle : The phandle for the PHY connected to this ethernet
> > > > controller.
> > > > + - fixed-link : <a b c> where a is emulated phy id - choose any,
> > > > + but unique to the all specified fixed-links, b is duplex - 0 half,
> > > > + 1 full, c is link speed - d#10/d#100/d#1000.
> > >
> > > Good work!
> > > May I suggest adding a "d" to <a b c> where d is flow control - 0 no, 1 yes
> >
> > Well, I see no reference of the "flow" neither in the include/linux/mii.h
> > nor in the drivers/net/phy/*. :-/ Thus today there is no such register
> > bit we can emulate?..
>
> Well, as good as I can recall, flow control(pause) is something that the
> PHY negotiates, just like FDX/HDX and should be dealt with in the
> adjust_link callback but not many do currently.
>
> If you seach for pause in phy_device.c you will find it.
Ah, pause. Sure, we can emulate that.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: 85xx software reset problems from paulus.git
From: Dale Farnsworth @ 2007-11-27 13:50 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <2F57AC6E-EE1B-4B8D-8AB5-AAF5B2DC4C06@kernel.crashing.org>
Kumar Gala wrote:
> >> Yes. The symptoms in 2.6.24RC2 are that during a kernel panic or when
> >> calling 'reboot' in the shell, it just hangs. Using the same dts and
> >> resets in 2.6.23.1 reboots fine. I don't have a cds reference, but
> >> someone who does should be able to confirm whether the issue exists
> >> or
> >> not by just attempting to reboot via bash.
>
> Can someone do a git-bisect and find the patch that breaks things?
I'll see if I can reproduce it on my 8548cds. If so, I'll then git-bisect.
-Dale
^ permalink raw reply
* Re: time accounting problem (powerpc only?)
From: Johannes Berg @ 2007-11-27 13:42 UTC (permalink / raw)
To: Tony Breeds; +Cc: linuxppc-dev list, Linux Kernel list
In-Reply-To: <20071127050031.GC24243@bakeyournoodle.com>
[-- Attachment #1: Type: text/plain, Size: 547 bytes --]
On Tue, 2007-11-27 at 16:00 +1100, Tony Breeds wrote:
> On Mon, Nov 26, 2007 at 05:23:13PM +0100, Johannes Berg wrote:
> > Contrary to what I claimed later in the thread, my 64-bit powerpc box
> > (quad-core G5) doesn't suffer from this problem.
> >
> > Does anybody have any idea? I don't even know how to debug it further.
>
> I'll see if I can grab an appropriate machine tomorrow and have a look at
> it. I think it's just an accounting bug, which is probably my fault :)
Thanks. Let me know if you need any info.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] fsl_soc: add support for gianfar for fixed-link property
From: Joakim Tjernlund @ 2007-11-27 13:17 UTC (permalink / raw)
To: avorontsov; +Cc: netdev, linux-kernel, Jeff Garzik, linuxppc-dev
In-Reply-To: <20071127113935.GA26867@localhost.localdomain>
On Tue, 2007-11-27 at 14:39 +0300, Anton Vorontsov wrote:
> On Mon, Nov 26, 2007 at 04:04:08PM +0100, Joakim Tjernlund wrote:
> > On Mon, 2007-11-26 at 17:29 +0300, Vitaly Bordug wrote:
> > > fixed-link says: register new "Fixed/emulated PHY", i.e. PHY that
> > > not connected to the real MDIO bus.
> > >
> > > Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
> > > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> > >
> > > ---
> > >
> > > Documentation/powerpc/booting-without-of.txt | 3 +
> > > arch/powerpc/sysdev/fsl_soc.c | 56 ++++++++++++++++++--------
> > > 2 files changed, 42 insertions(+), 17 deletions(-)
> > >
> > >
> > > diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> > > index e9a3cb1..cf25070 100644
> > > --- a/Documentation/powerpc/booting-without-of.txt
> > > +++ b/Documentation/powerpc/booting-without-of.txt
> > > @@ -1254,6 +1254,9 @@ platforms are moved over to use the flattened-device-tree model.
> > > services interrupts for this device.
> > > - phy-handle : The phandle for the PHY connected to this ethernet
> > > controller.
> > > + - fixed-link : <a b c> where a is emulated phy id - choose any,
> > > + but unique to the all specified fixed-links, b is duplex - 0 half,
> > > + 1 full, c is link speed - d#10/d#100/d#1000.
> >
> > Good work!
> > May I suggest adding a "d" to <a b c> where d is flow control - 0 no, 1 yes
>
> Well, I see no reference of the "flow" neither in the include/linux/mii.h
> nor in the drivers/net/phy/*. :-/ Thus today there is no such register
> bit we can emulate?..
Well, as good as I can recall, flow control(pause) is something that the
PHY negotiates, just like FDX/HDX and should be dealt with in the
adjust_link callback but not many do currently.
If you seach for pause in phy_device.c you will find it.
>
> > flow control or not just popped up here today so I got a use for it.
>
> ..and I looked into few drivers (gianfar, ucc), and they seem to use
> hard-coded flow control values, thus they don't speak to the PHYs
> about that.
Yes, but they should.
>
> Can you give any reference to the driver that needs that parameter?
> Does it use PHY subsystem to obtain flow-control on/off information?
>
> Thanks,
>
^ permalink raw reply
* Re: time accounting problem (powerpc only?)
From: Johannes Berg @ 2007-11-27 13:06 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, Linux Kernel list
In-Reply-To: <18251.59930.30260.145217@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 727 bytes --]
On Tue, 2007-11-27 at 20:57 +1100, Paul Mackerras wrote:
> Johannes Berg writes:
>
> > Contrary to what I claimed later in the thread, my 64-bit powerpc box
> > (quad-core G5) doesn't suffer from this problem.
> >
> > Does anybody have any idea? I don't even know how to debug it further.
>
> I see it on my G4 powerbook. However, a compute-bound task runs just
> as fast (i.e. completes in the same elapsed time) as on older kernels,
> so it does look like it is just an accounting problem. If the CPU was
> really spending more than half its time servicing hardware interrupts,
> the task should take more than twice as long to complete.
Exactly. So where do I look for the accounting bug?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: time accounting problem (powerpc only?)
From: Johannes Berg @ 2007-11-26 23:55 UTC (permalink / raw)
To: Linux Kernel list; +Cc: linuxppc-dev list
In-Reply-To: <1195814816.4149.94.camel@johannes.berg>
[-- Attachment #1: Type: text/plain, Size: 200 bytes --]
> On my powerbook, with NO_HZ and HIGH_RES_TIMERS, I observed recently
> that powernowd would not ever switch between CPU speeds.
Also happens without NO_HZ (with HIGH_RES_TIMERS).
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: 2.6.24-rc3: High CPU load -- hardware interrupts
From: Jörg Sommer @ 2007-11-27 11:13 UTC (permalink / raw)
To: Elimar Riesebieter; +Cc: linuxppc-dev
In-Reply-To: <20071126223831.GA11112@frodo.home.lxtec.de>
[-- Attachment #1: Type: text/plain, Size: 403 bytes --]
Hi Elimar,
Elimar Riesebieter schrieb am Mon 26. Nov, 23:38 (+0100):
> I can confirm this situation. But it seems, that no one takes care
> of it ....
Have a look at the thread “time accounting problem (powerpc only?)”
started by Johannes Berg on 23 Nov 2007.
Bye, Jörg.
--
Du kannst einem Schwein einen goldenen Ring durch die Nase ziehen,
deswegen bleibt es trozdem ein Schwein!
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] [POWERPC] fsl_soc: add support for gianfar for fixed-link property
From: Anton Vorontsov @ 2007-11-27 11:39 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: netdev, linux-kernel, Jeff Garzik, linuxppc-dev
In-Reply-To: <1196089448.12625.62.camel@gentoo-jocke.transmode.se>
On Mon, Nov 26, 2007 at 04:04:08PM +0100, Joakim Tjernlund wrote:
> On Mon, 2007-11-26 at 17:29 +0300, Vitaly Bordug wrote:
> > fixed-link says: register new "Fixed/emulated PHY", i.e. PHY that
> > not connected to the real MDIO bus.
> >
> > Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
> > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> >
> > ---
> >
> > Documentation/powerpc/booting-without-of.txt | 3 +
> > arch/powerpc/sysdev/fsl_soc.c | 56 ++++++++++++++++++--------
> > 2 files changed, 42 insertions(+), 17 deletions(-)
> >
> >
> > diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> > index e9a3cb1..cf25070 100644
> > --- a/Documentation/powerpc/booting-without-of.txt
> > +++ b/Documentation/powerpc/booting-without-of.txt
> > @@ -1254,6 +1254,9 @@ platforms are moved over to use the flattened-device-tree model.
> > services interrupts for this device.
> > - phy-handle : The phandle for the PHY connected to this ethernet
> > controller.
> > + - fixed-link : <a b c> where a is emulated phy id - choose any,
> > + but unique to the all specified fixed-links, b is duplex - 0 half,
> > + 1 full, c is link speed - d#10/d#100/d#1000.
>
> Good work!
> May I suggest adding a "d" to <a b c> where d is flow control - 0 no, 1 yes
Well, I see no reference of the "flow" neither in the include/linux/mii.h
nor in the drivers/net/phy/*. :-/ Thus today there is no such register
bit we can emulate?..
> flow control or not just popped up here today so I got a use for it.
..and I looked into few drivers (gianfar, ucc), and they seem to use
hard-coded flow control values, thus they don't speak to the PHYs
about that.
Can you give any reference to the driver that needs that parameter?
Does it use PHY subsystem to obtain flow-control on/off information?
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [2.6 patch] the scheduled I2C RTC driver removal
From: Jean Delvare @ 2007-11-27 10:19 UTC (permalink / raw)
To: linuxppc-dev, Kumar Gala, Paul Mackerras
Cc: Adrian Bunk, linux-kernel, rtc-linux, i2c
In-Reply-To: <20071102231243.61c39d23@hyperion.delvare>
On Fri, 2 Nov 2007 23:12:43 +0100, Jean Delvare wrote:
> Hi Adrian,
>
> On Thu, 1 Nov 2007 00:03:58 +0100, Adrian Bunk wrote:
> > This patch contains the scheduled removal of legacy I2C RTC drivers with
> > replacement drivers.
> > (...)
> > Documentation/feature-removal-schedule.txt | 7
> > arch/powerpc/platforms/83xx/mpc832x_mds.c | 24 -
> > arch/powerpc/platforms/83xx/mpc834x_mds.c | 24 -
> > arch/powerpc/platforms/83xx/mpc836x_mds.c | 24 -
> > arch/ppc/platforms/83xx/mpc834x_sys.c | 20 -
> > arch/ppc/platforms/85xx/tqm85xx.c | 21 -
> > arch/ppc/platforms/katana.c | 21 -
> > drivers/i2c/chips/Kconfig | 38 -
> > drivers/i2c/chips/Makefile | 3
> > drivers/i2c/chips/ds1337.c | 410 --------------------
> > drivers/i2c/chips/ds1374.c | 267 -------------
> > drivers/i2c/chips/m41t00.c | 413 ---------------------
> > include/linux/m41t00.h | 50 --
> > 13 files changed, 1322 deletions(-)
>
> Obviously we're not yet ready to remove the drivers, as some platforms
> still use them! The remaining platforms need to be updated to use the
> new RTC drivers first. The mapping is as follows:
>
> chip | old driver | new driver |
> -----------+------------+--------------+
> DS1337 | ds1337 | rtc-ds1307 |
> DS1339 | ds1337 | rtc-ds1307 |
> DS1374 | ds1374 | rtc-ds1374 |
> M41T00 | m41t00 | rtc-ds1307 |
> M41T81 | m41t00 | rtc-m41t80 |
> M41ST85 | m41t00 | rtc-m41t80 |
>
> So, PPC people, please update your platform code to make use of the new
> drivers now, and let me know when you're done. As soon as all platforms
> are converted, I'll apply Adrian's patch.
As of 2.6.24-rc3-git2, I see that the references to the obsolete
drivers have been removed from arch/powerpc/*. Great, I'll update
Adrian's patch. This leaves only 3 platforms under arch/ppc (83xx, 85xx
and katana) that still need updating. Kumar, Paul, what's the status?
Thanks,
--
Jean Delvare
^ permalink raw reply
* MPC5200 I2C and 2.6 kernel
From: Oliver Rutsch @ 2007-11-27 10:07 UTC (permalink / raw)
To: Linuxppc-dev
Hi,
I'm using a TQM5200S (MPC5200B CPU) module on the STK52xx starter kit.
For some reasons I have to use the 2.6 kernel (the latest 2.6.23.1 from
the DENX git archive) with ARCH=powerpc and most of my external hardware
is running fine with this.
On the starter kit there is an external I2C RTC (M41T00) and I like to
use it now. In the 2.4 kernel there were some options regarding MPC5200
I2C, but I could not find them in the 2.6 kernel.
There were options for MPCxxx I2C Algorithm or MPC5xxx TQM5200 I2C
Adapter, for example.
Regardless what I'm doing in the 2.6 kernel configuration I can't get
this RTC running (I activated RTC support and the driver for the M41T00
in the configuration).
hwclock --debug tells me:
hwclock: Open of /dev/rtc failed, errno=19: No such device.
No usable clock interface found.
So the questions is: Is the I2C support for the MPC5200 in the 2.6.23
kernel in an usable state? Or do I need some special patches from TQ for
this board to get it running?
Thanks in advance and bye,
--
Dipl. Ing. Oliver Rutsch
EMail: orutsch@sympatec.com
^ permalink raw reply
* Re: How to map addresses beyond 4GB
From: Dell Query @ 2007-11-27 9:57 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <A54CDFF0-EF7A-445B-8A1E-E211E5D267D9@embeddedalley.com>
[-- Attachment #1: Type: text/plain, Size: 354 bytes --]
Thanks
Dan Malek <dan@embeddedalley.com> wrote:
On Nov 22, 2007, at 2:42 AM, Dell Query wrote:
> May I know how to map this one?
Just call ioremap() as usual. It will understand the > 4G
physical address and return a useful virtual address
to you.
-- Dan
---------------------------------
Never miss a thing. Make Yahoo your homepage.
[-- Attachment #2: Type: text/html, Size: 610 bytes --]
^ permalink raw reply
* Re: time accounting problem (powerpc only?)
From: Paul Mackerras @ 2007-11-27 9:57 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, Linux Kernel list
In-Reply-To: <1196094193.4149.287.camel@johannes.berg>
Johannes Berg writes:
> Contrary to what I claimed later in the thread, my 64-bit powerpc box
> (quad-core G5) doesn't suffer from this problem.
>
> Does anybody have any idea? I don't even know how to debug it further.
I see it on my G4 powerbook. However, a compute-bound task runs just
as fast (i.e. completes in the same elapsed time) as on older kernels,
so it does look like it is just an accounting problem. If the CPU was
really spending more than half its time servicing hardware interrupts,
the task should take more than twice as long to complete.
Paul.
^ permalink raw reply
* Re: [patch 2/9] ps3: Use symbolic names for video modes
From: Geert Uytterhoeven @ 2007-11-27 8:17 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Linux/PPC Development, Linux Frame Buffer Device Development
In-Reply-To: <20071127110538.32f8dfef.sfr@canb.auug.org.au>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2562 bytes --]
On Tue, 27 Nov 2007, Stephen Rothwell wrote:
> On Mon, 26 Nov 2007 18:24:57 +0100 Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> > @@ -594,20 +594,21 @@ static const struct {
> > unsigned mask : 19;
> > unsigned id : 4;
> > } ps3av_preferred_modes[] = {
> > - { .mask = PS3AV_RESBIT_WUXGA << SHIFT_VESA, .id = 13 },
> > - { .mask = PS3AV_RESBIT_1920x1080P << SHIFT_60, .id = 5 },
> > - { .mask = PS3AV_RESBIT_1920x1080P << SHIFT_50, .id = 10 },
> > - { .mask = PS3AV_RESBIT_1920x1080I << SHIFT_60, .id = 4 },
> > - { .mask = PS3AV_RESBIT_1920x1080I << SHIFT_50, .id = 9 },
> > - { .mask = PS3AV_RESBIT_SXGA << SHIFT_VESA, .id = 12 },
> > - { .mask = PS3AV_RESBIT_WXGA << SHIFT_VESA, .id = 11 },
> > - { .mask = PS3AV_RESBIT_1280x720P << SHIFT_60, .id = 3 },
> > - { .mask = PS3AV_RESBIT_1280x720P << SHIFT_50, .id = 8 },
> > - { .mask = PS3AV_RESBIT_720x480P << SHIFT_60, .id = 2 },
> > - { .mask = PS3AV_RESBIT_720x576P << SHIFT_50, .id = 7 },
> > + { PS3AV_RESBIT_WUXGA << SHIFT_VESA, PS3AV_MODE_WUXGA },
> > + { PS3AV_RESBIT_1920x1080P << SHIFT_60, PS3AV_MODE_1080P60 },
> > + { PS3AV_RESBIT_1920x1080P << SHIFT_50, PS3AV_MODE_1080P50 },
> > + { PS3AV_RESBIT_1920x1080I << SHIFT_60, PS3AV_MODE_1080I60 },
> > + { PS3AV_RESBIT_1920x1080I << SHIFT_50, PS3AV_MODE_1080I50 },
> > + { PS3AV_RESBIT_SXGA << SHIFT_VESA, PS3AV_MODE_SXGA },
> > + { PS3AV_RESBIT_WXGA << SHIFT_VESA, PS3AV_MODE_WXGA },
> > + { PS3AV_RESBIT_1280x720P << SHIFT_60, PS3AV_MODE_720P60 },
> > + { PS3AV_RESBIT_1280x720P << SHIFT_50, PS3AV_MODE_720P50 },
> > + { PS3AV_RESBIT_720x480P << SHIFT_60, PS3AV_MODE_480P },
> > + { PS3AV_RESBIT_720x576P << SHIFT_50, PS3AV_MODE_576P },
>
> Why did you remove the C99 style initialisers?
Because else things no longer fit on one line.
I prefered a clean structural overview over the protection against the
(almost nonexisting) risk of initializing the wrong member.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Move CPM command handling into the cpm drivers
From: Vitaly Bordug @ 2007-11-27 8:08 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <474B3D7F.8060503@freescale.com>
On Mon, 26 Nov 2007 15:41:19 -0600
Scott Wood wrote:
> Vitaly Bordug wrote:
> > perhaps I was not clear enough. That was a rough idea how to handle
> > the whole thing, not just cpm_cr_cmd. This cpm command is a corner
> > case, but there can be other actions that may confuse CPM being
> > triggered simultaneously or overlapping.
>
> What kind of actions did you have in mind? Microcode patching?
>
microcode is another case to handle gracefully. There are also
"soft" cases like cpmux mess-up, incompatible SoC devices (which we are handling by
logical exclude now but which do have natural reasons of "not leaving together" like
shared dedicated GPIO or smth else) etc.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: Booting latest linux kernel(2.6.20) on MPC8548ECDS
From: Kumar Gala @ 2007-11-27 7:40 UTC (permalink / raw)
To: rajendra prasad; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <760ff48e0711262154u39c30dbduacdf310b820a7c81@mail.gmail.com>
On Nov 26, 2007, at 11:54 PM, rajendra prasad wrote:
> Hi,
>
> I am using MPC8548ECDS board from CDS for my telecom application. I am
> able to build 2.6.10 linux kernel and boot 2.6.10 kernel on
> MPC8548ECDS board.When I take same configuration file and built
> successfully but not able to boot on MPC8548E CDS board.I am using
> u-boot-1.1.6 as boot loader.I came to know taht latest kernel is
> booted with new procedure.Pls tell me the procedure how to boot
> procedure.
Ask this question on the linuxppc-dev list. You're more likely to get
an answer.
Its unclear, but you are trying to use the latest kernel on a MPC8548E
CDS?
- k
^ permalink raw reply
* Re: 85xx software reset problems from paulus.git
From: Kumar Gala @ 2007-11-27 7:38 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-embedded
In-Reply-To: <474B2A7F.5090607@anagramm.de>
>> Yes. The symptoms in 2.6.24RC2 are that during a kernel panic or when
>> calling 'reboot' in the shell, it just hangs. Using the same dts and
>> resets in 2.6.23.1 reboots fine. I don't have a cds reference, but
>> someone who does should be able to confirm whether the issue exists
>> or
>> not by just attempting to reboot via bash.
Can someone do a git-bisect and find the patch that breaks things?
>> ACK. Exactly the same over here (mpc8540ads compatible).
> I added the global-utilities today as well, but reboot fails.
if you are on a 8540 GUTS doesn't support hreset_req (8548 or newer).
> Why is the guts stuff missing i.e. in most of the shipped
> mpc85xx*.dts? Does it depend on some hardware connections
> external to the CPU?
Only the 8548 or newer CPUs have the GUTS HRESET_REQ ability that we
use to reset. (8540, 8560, 8541, 8555 do not).
- k
^ permalink raw reply
* Re: time accounting problem (powerpc only?)
From: Tony Breeds @ 2007-11-27 5:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, Linux Kernel list
In-Reply-To: <1196094193.4149.287.camel@johannes.berg>
On Mon, Nov 26, 2007 at 05:23:13PM +0100, Johannes Berg wrote:
> Contrary to what I claimed later in the thread, my 64-bit powerpc box
> (quad-core G5) doesn't suffer from this problem.
>
> Does anybody have any idea? I don't even know how to debug it further.
I'll see if I can grab an appropriate machine tomorrow and have a look at
it. I think it's just an accounting bug, which is probably my fault :)
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: The question about the high memory support on MPC8360?
From: vijay baskar @ 2007-11-27 4:27 UTC (permalink / raw)
To: Scott Wood; +Cc: 郭劲, linuxppc-embedded
In-Reply-To: <20071126165751.GA4415@loki.buserror.net>
[-- Attachment #1: Type: text/html, Size: 4592 bytes --]
^ permalink raw reply
* Re: dtc: Add valgrind support to testsuite
From: David Gibson @ 2007-11-27 4:17 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1IwmA3-0002eh-OO@jdl.com>
On Mon, Nov 26, 2007 at 04:10:39PM -0600, Jon Loeliger wrote:
> So, like, the other day David Gibson mumbled:
> > This patch adds some options to the run_tests.sh script allowing it to
> > run all the testcases under valgrind to check for pointer corruption
> > bugs and memory leaks. Invoking "make checkm" will run the testsuite
> > with valgrind.
> >
> > It include a mechanism for specifying valgrind errors to be suppressed
> > on a per-testcase basis, and adds a couple of such suppression files
> > for the mangle-layout and open_pack testcases which dump for use by
> > other testcases a buffer which may contain uninitialized sections. We
> > use suppressions rather than initializing the buffer so that valgrind
> > will catch any internal access s to the uninitialized data, which
> > would be a bug.
> >
> > The patch also fixes one genuine bug caught by valgrind -
> > _packblocks() in fdt_rw.c was using memcpy() where it should have been
> > using memmove().
> >
> > At present the valgrinding won't do anything useful for testcases
> > invoked via a shell script - which includes all the dtc testcases. I
> > plan to fix that later.
> >
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>
> Applied.
>
> Thanks,
> jdl
>
> PS -- Clearly, I'm going to have to break down and install valgrind now. :-)
Absolutely. Actually valgrind didn't show up much interesting on
libfdt. Some preliminary investigations suggest it may find some
problems in dtc, once I get the shell scripts to pass the valgrind
option through properly.
Be aware that running the testsuite under valgrind will take a long
time. It goes from something like 1s without valgrind to 10 minutes
on one of my machines.
--
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: dtc: Flexible tree checking infrastructure (v2)
From: David Gibson @ 2007-11-27 3:58 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1IwmCq-0002g9-Nk@jdl.com>
On Mon, Nov 26, 2007 at 04:13:32PM -0600, Jon Loeliger wrote:
> So, like, the other day David Gibson mumbled:
> > dtc: Flexible tree checking infrastructure
> >
> > Here, at last, is a substantial start on revising dtc's infrastructure
> > for checking the tree; this is the rework I've been saying was
> > necessary practically since dtc was first release.
> >
> > In the new model, we have a table of "check" structures, each with a
> > name, references to checking functions, and status variables. Each
> > check can (in principle) be individually switched off or on (as either
> > a warning or error). Checks have a list of prerequisites, so if
> > checks need to rely on results from earlier checks to make sense (or
> > even to avoid crashing) they just need to list the relevant other
> > checks there.
> >
> > For now, only the "structural" checks and the fixups for phandle
> > references are converted to the new mechanism. The rather more
> > involved semantic checks (which is where this new mechanism will
> > really be useful) will have to be converted in future patches.
> >
> > At present, there's no user interface for turning on/off the checks -
> > the -f option now forces output even if "error" level checks fail.
> > Again, future patches will be needed to add the fine-grained control,
> > but that should be quite straightforward with the infrastructure
> > implemented here.
> >
> > Also adds a testcase for the handling of bad references, which catches
> > a bug encountered while developing this patch.
> >
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>
> While I've Applied this one, it has introduced this:
>
> CC dtc.o
> dtc.c: In function 'main':
> dtc.c:199: warning: 'structure_ok' is used uninitialized in this function
>
> Followup easy patch?
Crap. For some reason my compiler isn't giving that warning, so I
missed that little bug :(.
I'm away at the moment, I'll see what I can do.
--
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
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