* Re: [openib-general] [PATCH 2.6.19 2/4] ehca: hcp_phyp.c: correct page mapping in 64k page mode
From: Paul Mackerras @ 2006-11-10 8:46 UTC (permalink / raw)
To: Christoph Raisch
Cc: openib-general-bounces, linuxppc-dev, Roland Dreier, linux-kernel,
openib-general
In-Reply-To: <OF75FFAC00.E43450CA-ONC1257222.002A402A-C1257222.002AB9BD@de.ibm.com>
Christoph Raisch writes:
> The patch is needed. We've seen it on the real system. We did fix it on the
> real system.
I disagree that the ioremap change is needed.
> ...and it conforms to theory... although theory is a bit confusing here.
>
> let me try to summarize:
> ioremap checks for 64k boundary (actually page boundary)
Actually, ioremap itself already does the calculations that your patch
adds - that is, it generates the offset within the page and the
physical address of the start of the page, does the mapping using the
latter, then adds on the offset to the virtual address of the page and
returns that.
Paul.
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 2/2] Add support for dumping spu info from xmon
From: Geoff Levand @ 2006-11-10 9:11 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, Arnd Bergmann, cbe-oss-dev
In-Reply-To: <1161154573.7906.11.camel@localhost.localdomain>
Michael Ellerman wrote:
> On Thu, 2006-10-12 at 10:42 -0700, Geoff Levand wrote:
>> Michael Ellerman wrote:
>> > This patch adds a command to xmon for dumping information about
>> > spu structs. The command is 'sf' for "spu fields" perhaps, and
>> > takes the spu number as an argument. This is the same value as the
>> > spu->number field, or the "phys-id" value of a context when it is
>> > bound to a physical spu.
>>
>> > +static void dump_spu_fields(struct spu *spu)
>> > +{
>> ...
>> > + DUMP_FIELD(spu, "0x%x", problem->spu_npc_RW);
>> > + DUMP_FIELD(spu, "0x%p", priv1);
>> > +
>> > + if (spu->priv1)
>> > + DUMP_FIELD(spu, "0x%lx", priv1->mfc_sr1_RW);
>> > +
>> > + DUMP_FIELD(spu, "0x%p", priv2);
>>
>> Just to let you know, I've been doing some work to abstract the platform
>> specific parts out of the spu support to better support running on a
>> hypervisor. It shouldn't make much difference, but maybe I'll try to set
>> something up like this for you:
>>
>> DUMP_FIELD(spu, "0x%x", problem->spu_npc_RW);
>> DUMP_FIELD(spu, "0x%p", priv2);
>> spu_dump_platform_fields(spu);
>
> We already have the spu_priv1_ops abstracted out, is that not enough? I
> decided to check explicitly for the priv1 pointer because calling the
> hypervisor from a panicked kernel is risky at best. Although I haven't
> seen how you guys implement hypervisor calls, so perhaps it's not so
> bad.
Michael,
I tried to set this up as above, but unfortunately, your DUMP_FIELD is
setup in such a way that it is not easy to change to use from outside
xmon.c, so I left spu_dump_platform_fields() (I put it in spu_priv1_mmio.c)
empty. We'll need to work on something usable here, or make some other way
to abstract those platform specific spu variables.
I'll re-post my abstract spu management routines patch again soon with
this xmon support added.
-Geoff
^ permalink raw reply
* Re: [PATCH 4/5] ppc64: make soft_enabled irqs preempt safe
From: Paul Mackerras @ 2006-11-10 9:18 UTC (permalink / raw)
To: Hugh Dickins; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0610311841570.26470@blonde.wat.veritas.com>
Hugh Dickins writes:
> local_irq_restore be careful to access hard_enabled and lppaca before
> setting soft_enabled, which may well permit preemption. Use local_paca
The reason for testing hard_enabled *after* setting soft_enabled is to
avoid a race. If we load hard_enabled first, as your patch does, then
an interrupt could come in between that load and the store that sets
soft_enabled, and we would miss that and not hard-enable as we should.
I'm not sure what the solution is. I suppose we could disable
preemption, although I'd rather something lighter-weight if possible.
Paul.
^ permalink raw reply
* [PATCH] Distinguish POWER6 partition modes and tell userspace
From: Paul Mackerras @ 2006-11-10 9:38 UTC (permalink / raw)
To: linuxppc-dev
This adds code to look at the properties firmware puts in the device
tree to determine what compatibility mode the partition is in on
POWER6 machines, and set the ELF aux vector AT_HWCAP and AT_PLATFORM
entries appropriately.
Specifically, we look at the cpu-version property in the cpu node(s).
If that contains a "logical" PVR value (of the form 0x0f00000x), we
call identify_cpu again with this PVR value. A value of 0x0f000000
indicates the partition is in POWER5+ compatibility mode, and a value
of 0x0f000001 indicates "POWER6 architected" mode, with various
extensions disabled. We also look for various other properties:
ibm,dfp, ibm,purr and ibm,spurr.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index bfd499e..20025ed 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -276,10 +276,45 @@ static struct cpu_spec cpu_specs[] = {
.oprofile_mmcra_sipr = MMCRA_SIPR,
.platform = "power5+",
},
+ { /* POWER6 in P5+ mode; 2.04-compliant processor */
+ .pvr_mask = 0xffffffff,
+ .pvr_value = 0x0f000000,
+ .cpu_name = "POWER5+",
+ .cpu_features = CPU_FTRS_POWER5,
+ .cpu_user_features = COMMON_USER_POWER5_PLUS,
+ .icache_bsize = 128,
+ .dcache_bsize = 128,
+ .num_pmcs = 6,
+ .oprofile_cpu_type = "ppc64/power6",
+ .oprofile_type = PPC_OPROFILE_POWER4,
+ .oprofile_mmcra_sihv = POWER6_MMCRA_SIHV,
+ .oprofile_mmcra_sipr = POWER6_MMCRA_SIPR,
+ .oprofile_mmcra_clear = POWER6_MMCRA_THRM |
+ POWER6_MMCRA_OTHER,
+ .platform = "power5+",
+ },
{ /* Power6 */
.pvr_mask = 0xffff0000,
.pvr_value = 0x003e0000,
- .cpu_name = "POWER6",
+ .cpu_name = "POWER6 (raw)",
+ .cpu_features = CPU_FTRS_POWER6,
+ .cpu_user_features = COMMON_USER_POWER6 |
+ PPC_FEATURE_POWER6_EXT,
+ .icache_bsize = 128,
+ .dcache_bsize = 128,
+ .num_pmcs = 6,
+ .oprofile_cpu_type = "ppc64/power6",
+ .oprofile_type = PPC_OPROFILE_POWER4,
+ .oprofile_mmcra_sihv = POWER6_MMCRA_SIHV,
+ .oprofile_mmcra_sipr = POWER6_MMCRA_SIPR,
+ .oprofile_mmcra_clear = POWER6_MMCRA_THRM |
+ POWER6_MMCRA_OTHER,
+ .platform = "power6x",
+ },
+ { /* 2.05-compliant processor, i.e. Power6 "architected" mode */
+ .pvr_mask = 0xffffffff,
+ .pvr_value = 0x0f000001,
+ .cpu_name = "POWER6 (architected)",
.cpu_features = CPU_FTRS_POWER6,
.cpu_user_features = COMMON_USER_POWER6,
.icache_bsize = 128,
@@ -1169,19 +1204,15 @@ static struct cpu_spec cpu_specs[] = {
#endif /* CONFIG_PPC32 */
};
-struct cpu_spec *identify_cpu(unsigned long offset)
+struct cpu_spec *identify_cpu(unsigned long offset, unsigned int pvr)
{
struct cpu_spec *s = cpu_specs;
struct cpu_spec **cur = &cur_cpu_spec;
- unsigned int pvr = mfspr(SPRN_PVR);
int i;
s = PTRRELOC(s);
cur = PTRRELOC(cur);
- if (*cur != NULL)
- return PTRRELOC(*cur);
-
for (i = 0; i < ARRAY_SIZE(cpu_specs); i++,s++)
if ((pvr & s->pvr_mask) == s->pvr_value) {
*cur = cpu_specs + i;
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index bdb412d..75e06e3 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -538,35 +538,31 @@ static struct ibm_pa_feature {
{CPU_FTR_REAL_LE, PPC_FEATURE_TRUE_LE, 5, 0, 0},
};
-static void __init check_cpu_pa_features(unsigned long node)
+static void __init scan_features(unsigned long node, unsigned char *ftrs,
+ unsigned long tablelen,
+ struct ibm_pa_feature *fp,
+ unsigned long ft_size)
{
- unsigned char *pa_ftrs;
- unsigned long len, tablelen, i, bit;
-
- pa_ftrs = of_get_flat_dt_prop(node, "ibm,pa-features", &tablelen);
- if (pa_ftrs == NULL)
- return;
+ unsigned long i, len, bit;
/* find descriptor with type == 0 */
for (;;) {
if (tablelen < 3)
return;
- len = 2 + pa_ftrs[0];
+ len = 2 + ftrs[0];
if (tablelen < len)
return; /* descriptor 0 not found */
- if (pa_ftrs[1] == 0)
+ if (ftrs[1] == 0)
break;
tablelen -= len;
- pa_ftrs += len;
+ ftrs += len;
}
/* loop over bits we know about */
- for (i = 0; i < ARRAY_SIZE(ibm_pa_features); ++i) {
- struct ibm_pa_feature *fp = &ibm_pa_features[i];
-
- if (fp->pabyte >= pa_ftrs[0])
+ for (i = 0; i < ft_size; ++i, ++fp) {
+ if (fp->pabyte >= ftrs[0])
continue;
- bit = (pa_ftrs[2 + fp->pabyte] >> (7 - fp->pabit)) & 1;
+ bit = (ftrs[2 + fp->pabyte] >> (7 - fp->pabit)) & 1;
if (bit ^ fp->invert) {
cur_cpu_spec->cpu_features |= fp->cpu_features;
cur_cpu_spec->cpu_user_features |= fp->cpu_user_ftrs;
@@ -577,16 +573,59 @@ static void __init check_cpu_pa_features
}
}
+static void __init check_cpu_pa_features(unsigned long node)
+{
+ unsigned char *pa_ftrs;
+ unsigned long tablelen;
+
+ pa_ftrs = of_get_flat_dt_prop(node, "ibm,pa-features", &tablelen);
+ if (pa_ftrs == NULL)
+ return;
+
+ scan_features(node, pa_ftrs, tablelen,
+ ibm_pa_features, ARRAY_SIZE(ibm_pa_features));
+}
+
+static struct feature_property {
+ const char *name;
+ u32 min_value;
+ unsigned long cpu_feature;
+ unsigned long cpu_user_ftr;
+} feature_properties[] __initdata = {
+#ifdef CONFIG_ALTIVEC
+ {"altivec", 0, CPU_FTR_ALTIVEC, PPC_FEATURE_HAS_ALTIVEC},
+ {"ibm,vmx", 1, CPU_FTR_ALTIVEC, PPC_FEATURE_HAS_ALTIVEC},
+#endif /* CONFIG_ALTIVEC */
+#ifdef CONFIG_PPC64
+ {"ibm,dfp", 1, 0, PPC_FEATURE_HAS_DFP},
+ {"ibm,purr", 1, CPU_FTR_PURR, 0},
+ {"ibm,spurr", 1, CPU_FTR_SPURR, 0},
+#endif /* CONFIG_PPC64 */
+};
+
+static void __init check_cpu_feature_properties(unsigned long node)
+{
+ unsigned long i;
+ struct feature_property *fp = feature_properties;
+ const u32 *prop;
+
+ for (i = 0; i < ARRAY_SIZE(feature_properties); ++i, ++fp) {
+ prop = of_get_flat_dt_prop(node, fp->name, NULL);
+ if (prop && *prop >= fp->min_value) {
+ cur_cpu_spec->cpu_features |= fp->cpu_feature;
+ cur_cpu_spec->cpu_user_features |= fp->cpu_user_ftr;
+ }
+ }
+}
+
static int __init early_init_dt_scan_cpus(unsigned long node,
const char *uname, int depth,
void *data)
{
static int logical_cpuid = 0;
char *type = of_get_flat_dt_prop(node, "device_type", NULL);
-#ifdef CONFIG_ALTIVEC
- u32 *prop;
-#endif
- u32 *intserv;
+ const u32 *prop;
+ const u32 *intserv;
int i, nthreads;
unsigned long len;
int found = 0;
@@ -643,24 +682,27 @@ static int __init early_init_dt_scan_cpu
intserv[i]);
boot_cpuid = logical_cpuid;
set_hard_smp_processor_id(boot_cpuid, intserv[i]);
- }
-#ifdef CONFIG_ALTIVEC
- /* Check if we have a VMX and eventually update CPU features */
- prop = (u32 *)of_get_flat_dt_prop(node, "ibm,vmx", NULL);
- if (prop && (*prop) > 0) {
- cur_cpu_spec->cpu_features |= CPU_FTR_ALTIVEC;
- cur_cpu_spec->cpu_user_features |= PPC_FEATURE_HAS_ALTIVEC;
- }
-
- /* Same goes for Apple's "altivec" property */
- prop = (u32 *)of_get_flat_dt_prop(node, "altivec", NULL);
- if (prop) {
- cur_cpu_spec->cpu_features |= CPU_FTR_ALTIVEC;
- cur_cpu_spec->cpu_user_features |= PPC_FEATURE_HAS_ALTIVEC;
+ /*
+ * PAPR defines "logical" PVR values for cpus that
+ * meet various levels of the architecture:
+ * 0x0f000000 Architecture version 2.04
+ * 0x0f000001 Architecture version 2.05
+ * If the cpu-version property in the cpu node contains
+ * such a value, we call identify_cpu again with the
+ * logical PVR value in order to use the cpu feature
+ * bits appropriate for the architecture level.
+ *
+ * A POWER6 partition in "POWER6 architected" mode
+ * uses the 0x0f000001 PVR value; in POWER5+ mode
+ * it uses 0x0f000000.
+ */
+ prop = of_get_flat_dt_prop(node, "cpu-version", NULL);
+ if (prop && (*prop & 0xff000000) == 0x0f000000)
+ identify_cpu(0, *prop);
}
-#endif /* CONFIG_ALTIVEC */
+ check_cpu_feature_properties(node);
check_cpu_pa_features(node);
#ifdef CONFIG_PPC_PSERIES
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index b917616..447d794 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -627,6 +627,7 @@ static void __init early_cmdline_parse(v
/* Option vector 3: processor options supported */
#define OV3_FP 0x80 /* floating point */
#define OV3_VMX 0x40 /* VMX/Altivec */
+#define OV3_DFP 0x20 /* decimal FP */
/* Option vector 5: PAPR/OF options supported */
#define OV5_LPAR 0x80 /* logical partitioning supported */
@@ -668,7 +669,7 @@ static unsigned char ibm_architecture_ve
/* option vector 3: processor options supported */
3 - 2, /* length */
0, /* don't ignore, don't halt */
- OV3_FP | OV3_VMX,
+ OV3_FP | OV3_VMX | OV3_DFP,
/* option vector 4: IBM PAPR implementation */
2 - 2, /* length */
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index a4c2964..f594079 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -101,7 +101,7 @@ unsigned long __init early_init(unsigned
* Identify the CPU type and fix up code sections
* that depend on which cpu we have.
*/
- spec = identify_cpu(offset);
+ spec = identify_cpu(offset, mfspr(SPRN_PVR));
do_feature_fixups(spec->cpu_features,
PTRRELOC(&__start___ftr_fixup),
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 1627896..cc86287 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -171,7 +171,7 @@ void __init setup_paca(int cpu)
void __init early_setup(unsigned long dt_ptr)
{
/* Identify CPU type */
- identify_cpu(0);
+ identify_cpu(0, mfspr(SPRN_PVR));
/* Assume we're on cpu 0 for now. Don't write to the paca yet! */
setup_paca(0);
diff --git a/arch/ppc/kernel/setup.c b/arch/ppc/kernel/setup.c
index 27faeca..3c506af 100644
--- a/arch/ppc/kernel/setup.c
+++ b/arch/ppc/kernel/setup.c
@@ -313,7 +313,7 @@ early_init(int r3, int r4, int r5)
* Identify the CPU type and fix up code sections
* that depend on which cpu we have.
*/
- spec = identify_cpu(offset);
+ spec = identify_cpu(offset, mfspr(SPRN_PVR));
do_feature_fixups(spec->cpu_features,
PTRRELOC(&__start___ftr_fixup),
PTRRELOC(&__stop___ftr_fixup));
diff --git a/include/asm-powerpc/cputable.h b/include/asm-powerpc/cputable.h
index a9a4014..af157fd 100644
--- a/include/asm-powerpc/cputable.h
+++ b/include/asm-powerpc/cputable.h
@@ -24,6 +24,8 @@
#define PPC_FEATURE_ICACHE_SNOOP 0x00002000
#define PPC_FEATURE_ARCH_2_05 0x00001000
#define PPC_FEATURE_PA6T 0x00000800
+#define PPC_FEATURE_HAS_DFP 0x00000400
+#define PPC_FEATURE_POWER6_EXT 0x00000200
#define PPC_FEATURE_TRUE_LE 0x00000002
#define PPC_FEATURE_PPC_LE 0x00000001
@@ -91,7 +93,7 @@ extern struct cpu_spec *cur_cpu_spec;
extern unsigned int __start___ftr_fixup, __stop___ftr_fixup;
-extern struct cpu_spec *identify_cpu(unsigned long offset);
+extern struct cpu_spec *identify_cpu(unsigned long offset, unsigned int pvr);
extern void do_feature_fixups(unsigned long value, void *fixup_start,
void *fixup_end);
@@ -148,6 +150,7 @@ extern void do_feature_fixups(unsigned l
#define CPU_FTR_PAUSE_ZERO LONG_ASM_CONST(0x0000200000000000)
#define CPU_FTR_PURR LONG_ASM_CONST(0x0000400000000000)
#define CPU_FTR_CELL_TB_BUG LONG_ASM_CONST(0x0000800000000000)
+#define CPU_FTR_SPURR LONG_ASM_CONST(0x0001000000000000)
#ifndef __ASSEMBLY__
@@ -332,7 +335,13 @@ extern void do_feature_fixups(unsigned l
CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_MMCRA | CPU_FTR_SMT | \
CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \
- CPU_FTR_PURR | CPU_FTR_CI_LARGE_PAGE | CPU_FTR_REAL_LE)
+ CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE)
+#define CPU_FTRS_POWER6X (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
+ CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
+ CPU_FTR_MMCRA | CPU_FTR_SMT | \
+ CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \
+ CPU_FTR_PURR | CPU_FTR_CI_LARGE_PAGE | \
+ CPU_FTR_SPURR | CPU_FTR_REAL_LE)
#define CPU_FTRS_CELL (CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB | \
CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
diff --git a/arch/powerpc/platforms/iseries/setup.c b/arch/powerpc/platforms/iseries/setup.c
index 6f73469..b8cffcd 100644
--- a/arch/powerpc/platforms/iseries/setup.c
+++ b/arch/powerpc/platforms/iseries/setup.c
@@ -697,7 +697,7 @@ void * __init iSeries_early_setup(void)
/* Identify CPU type. This is done again by the common code later
* on but calling this function multiple times is fine.
*/
- identify_cpu(0);
+ identify_cpu(0, mfspn(SPRN_PVR));
powerpc_firmware_features |= FW_FEATURE_ISERIES;
powerpc_firmware_features |= FW_FEATURE_LPAR;
^ permalink raw reply related
* Re: 2.6.19-rc5-mm1 -- ppc64 ohci-hdc.c compile failure
From: Paul Mackerras @ 2006-11-10 9:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Andrew Morton, Steve Fox, linux-kernel, linuxppc-dev
In-Reply-To: <1163112227.4982.44.camel@localhost.localdomain>
Benjamin Herrenschmidt writes:
> > Seems that the patch below has introduced USB_OHCI_HCD_PPC_OF enabled by
> > default. When it and CONFIG_USB_OHCI_HCD_PPC_SOC are enabled which
> > occured by default on my config then we end up with two module_init()
> > calls, which is illegal.
> >
> > powerpc-add-of_platform-support-for-ohci-bigendian-hc
> >
> > I am guessing that we are only meant to be able to have one of these
> > defined at a time? I changed the default to n for this and I could at
> > least compile the kernel, but I am sure thats not the right fix.
>
> Paul, which patch did you merge ? I rejected the initial one that was
> doing 2 drivers/probe routines and Nicolas did a new one.. You may have
> taken the wrong one.
I didn't merge either of them.
Paul.
^ permalink raw reply
* Re: 2.6.19-rc5-mm1 -- ppc64 ohci-hdc.c compile failure
From: Benjamin Herrenschmidt @ 2006-11-10 9:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Andrew Morton, Steve Fox, linux-kernel, linuxppc-dev
In-Reply-To: <17748.19234.278295.476881@cargo.ozlabs.ibm.com>
On Fri, 2006-11-10 at 20:49 +1100, Paul Mackerras wrote:
> Benjamin Herrenschmidt writes:
>
> > > Seems that the patch below has introduced USB_OHCI_HCD_PPC_OF enabled by
> > > default. When it and CONFIG_USB_OHCI_HCD_PPC_SOC are enabled which
> > > occured by default on my config then we end up with two module_init()
> > > calls, which is illegal.
> > >
> > > powerpc-add-of_platform-support-for-ohci-bigendian-hc
> > >
> > > I am guessing that we are only meant to be able to have one of these
> > > defined at a time? I changed the default to n for this and I could at
> > > least compile the kernel, but I am sure thats not the right fix.
> >
> > Paul, which patch did you merge ? I rejected the initial one that was
> > doing 2 drivers/probe routines and Nicolas did a new one.. You may have
> > taken the wrong one.
>
> I didn't merge either of them.
Ah, must be Andrew then. Andrew, can you drop this (along with the other
Efika/MPC5200) patches from -mm ? They'll get in via the powerpc merge
and I'll make sure Paulus gets the right versions.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] CPM_UART: Fix non-console initialisation (v2)
From: Paul Mackerras @ 2006-11-10 10:29 UTC (permalink / raw)
To: Kalle Pokki; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.64.0611011457490.3387@host32.eke.fi>
Kalle Pokki writes:
> This is a cleaned-up version of a patch sent on Oct 19th. The patch is
> fairly straightforward and does not affect other than the compat mode. As
> not having this patch renders the cpm_uart driver unusable with a frame
> buffer console, I think this should be included in 2.6.19.
The last hunk, i.e. the change to drivers/serial/cpm_uart/cpm_uart_cpm2.c,
doesn't apply because cpm_uart_init_portdesc now looks different to the
context in your patch, so I dropped that hunk (it looked to be pretty
much independent of the other changes).
Also, the whitespace is damaged throughout this and your other
patches. I fixed it up this time, but please fix your mailer not to
munge the whitespace. Specifically, where a line begins with a space
character, your mailer removes it if there is nothing else on the
line, or turns it into two spaces otherwise. :P
Paul.
^ permalink raw reply
* ipr SATA support is causing problems
From: Paul Mackerras @ 2006-11-10 11:37 UTC (permalink / raw)
To: Brian King; +Cc: akpm, linuxppc-dev, torvalds, James Bottomley
Brian,
Today I compiled up a kernel from Linus' git tree and tried it on a
POWER6 partition. First I found that my config no longer had the ipr
driver, because I didn't have CONFIG_ATA and ipr now depends on
CONFIG_ATA. So I enabled CONFIG_ATA without enabling any of the ATA
chip drivers, which seems a little weird, and re-enabled ipr.
However, the kernel crashed on boot with a null pointer dereference in
the ata code called from the ipr driver (see stack trace below).
Other people have also reported such a crash. I then reverted commit
35a39691e4, and the resulting kernel booted without crashing.
It looks like there is still some bug in the SATA support in ipr.c,
perhaps something not getting initialized that needs to be
initialized. We may have to get Linus to revert that commit if the
bug can't be found and fixed, because otherwise 2.6.19 will be
unusable on pseries partitions with ipr SCSI adaptors.
Paul.
Unable to handle kernel paging request for data at address 0x00000010
Faulting instruction address: 0xc000000000063ca0
cpu 0x2: Vector: 300 (Data Access) at [c000000002f2ecc0]
pc: c000000000063ca0: .flush_workqueue+0x28/0xdc
lr: c000000000366848: .ata_port_flush_task+0x5c/0x124
sp: c000000002f2ef40
msr: 8000000000009032
dar: 10
dsisr: 40000000
current = 0xc000000002f29800
paca = 0xc0000000005aa800
pid = 1, comm = swapper
enter ? for help
[c000000002f2efd0] c000000000366848 .ata_port_flush_task+0x5c/0x124
[c000000002f2f060] c00000000036afe4 .ata_exec_internal+0x260/0x418
[c000000002f2f170] c00000000036b2b0 .ata_dev_read_id+0x114/0x36c
[c000000002f2f250] c00000000036bfa0 .ata_bus_probe+0x180/0x34c
[c000000002f2f310] c00000000036f4d8 .ata_sas_port_init+0x50/0x70
[c000000002f2f3a0] c00000000034fca8 .ipr_slave_alloc+0x17c/0x200
[c000000002f2f430] c00000000032dc88 .scsi_alloc_sdev+0x1d0/0x248
[c000000002f2f4f0] c00000000032dee0 .scsi_probe_and_add_lun+0x118/0x918
[c000000002f2f5f0] c00000000032ee6c .__scsi_scan_target+0xf0/0x608
[c000000002f2f700] c00000000032f3d8 .scsi_scan_channel+0x54/0xd0
[c000000002f2f7a0] c00000000032f50c .scsi_scan_host_selected+0xb8/0x130
[c000000002f2f850] c00000000034f2f4 .ipr_probe+0xe98/0xf80
[c000000002f2f960] c000000000227298 .pci_device_probe+0x144/0x1e4
[c000000002f2fa20] c0000000002a35b8 .really_probe+0x80/0x19c
[c000000002f2fac0] c0000000002a397c .__driver_attach+0xa0/0x124
[c000000002f2fb50] c0000000002a2708 .bus_for_each_dev+0x7c/0xd4
[c000000002f2fc10] c0000000002a3430 .driver_attach+0x28/0x40
[c000000002f2fc90] c0000000002a2bdc .bus_add_driver+0x80/0x1ec
[c000000002f2fd30] c0000000002a3d60 .driver_register+0xa8/0xc4
[c000000002f2fdb0] c0000000002275f4 .__pci_register_driver+0x9c/0xe4
[c000000002f2fe40] c00000000056e03c .ipr_init+0x34/0x4c
[c000000002f2fec0] c0000000000093ac .init+0x1e0/0x3c0
[c000000002f2ff90] c000000000023f04 .kernel_thread+0x4c/0x68
2:mon> r
R00 = c000000000366848 R16 = 4000000002100000
R01 = c000000002f2ef40 R17 = c0000000004a7cf0
R02 = c0000000007ba890 R18 = c00000000283022c
R03 = 0000000000000000 R19 = 00000000000000a1
R04 = 8000000000009032 R20 = 0000000000000200
R05 = 0000000000000160 R21 = 00000000fafbfcfd
R06 = 0000000024002042 R22 = 0000000000000000
R07 = 0000000000000000 R23 = 0000000000000000
R08 = 0000000000000000 R24 = 0000000000000002
R09 = 0000000000000010 R25 = c000000002f2f1e0
R10 = c000000002f2f0e8 R26 = 8000000000009032
R11 = c000000002f2f0e8 R27 = c000000002830200
R12 = 8000000001310000 R28 = c000000000867fb8
R13 = c0000000005aa800 R29 = 0000000000000000
R14 = 0000000000000000 R30 = c0000000005e2d58
R15 = c0000000004a9268 R31 = c000000002830000
pc = c000000000063ca0 .flush_workqueue+0x28/0xdc
lr = c000000000366848 .ata_port_flush_task+0x5c/0x124
msr = 8000000000009032 cr = 24002042
ctr = 0000000000000000 xer = 000000002000000c trap = 300
dar = 0000000000000010 dsisr = 40000000
^ permalink raw reply
* Re: [PATCH] CPM_UART: Fix non-console initialisation (v2)
From: Kalle Pokki @ 2006-11-10 11:45 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-embedded
In-Reply-To: <17748.21645.621069.105453@cargo.ozlabs.ibm.com>
On 11/10/06, Paul Mackerras <paulus@samba.org> wrote:
>
> The last hunk, i.e. the change to drivers/serial/cpm_uart/cpm_uart_cpm2.c,
> doesn't apply because cpm_uart_init_portdesc now looks different to the
> context in your patch, so I dropped that hunk (it looked to be pretty
> much independent of the other changes).
OK, better drop all the hunks except the one that concerns
drivers/serial/cpm_uart/cpm_uart_core.c then, since I added the same
'__init' lines in cpm_uart.h, cpm_uart_cpm1.c, and cpm_uart_cpm2.c.
> Also, the whitespace is damaged throughout this and your other
> patches. I fixed it up this time, but please fix your mailer not to
> munge the whitespace. Specifically, where a line begins with a space
> character, your mailer removes it if there is nothing else on the
> line, or turns it into two spaces otherwise. :P
I'll fix this. It seems I was sending the patches with pine making them flowed.
^ permalink raw reply
* Re: ipr SATA support is causing problems
From: Josh Boyer @ 2006-11-10 11:48 UTC (permalink / raw)
To: Paul Mackerras; +Cc: akpm, linuxppc-dev, torvalds, James Bottomley
In-Reply-To: <17748.25705.543922.486456@cargo.ozlabs.ibm.com>
On Fri, 2006-11-10 at 22:37 +1100, Paul Mackerras wrote:
> Brian,
>
> Today I compiled up a kernel from Linus' git tree and tried it on a
> POWER6 partition. First I found that my config no longer had the ipr
> driver, because I didn't have CONFIG_ATA and ipr now depends on
> CONFIG_ATA. So I enabled CONFIG_ATA without enabling any of the ATA
> chip drivers, which seems a little weird, and re-enabled ipr.
>
> However, the kernel crashed on boot with a null pointer dereference in
> the ata code called from the ipr driver (see stack trace below).
> Other people have also reported such a crash. I then reverted commit
> 35a39691e4, and the resulting kernel booted without crashing.
John Rose reported this a few days ago. Brian responded with this:
http://marc.theaimsgroup.com/?l=linux-ide&m=116169938407596&w=2
josh
^ permalink raw reply
* Re: ipr SATA support is causing problems
From: Paul Mackerras @ 2006-11-10 12:07 UTC (permalink / raw)
To: Josh Boyer; +Cc: akpm, James Bottomley, linuxppc-dev, torvalds, Jeff Garzik
In-Reply-To: <1163159326.19697.23.camel@crusty.rchland.ibm.com>
Josh Boyer writes:
> John Rose reported this a few days ago. Brian responded with this:
>
> http://marc.theaimsgroup.com/?l=linux-ide&m=116169938407596&w=2
Didn't John say he still saw the crash with that change?
Anyway, my point would be that either that patch (assuming it fixes
the problem) needs to go in 2.6.19, or 35a39691e4 needs to be
reverted.
Jeff, any comments on Brian's patch?
Paul.
^ permalink raw reply
* Compile Error using SMC1 on a MPC8272 for 2.6.19-rc4
From: Heiko Schocher @ 2006-11-10 11:53 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I tried to compile the Linux Kernel 2.6.19-rc5 with a MPC8272 CPU and a
console on SMC1, and get the following Compile Error:
CC drivers/serial/cpm_uart/cpm_uart_cpm2.o
drivers/serial/cpm_uart/cpm_uart_cpm2.c: In function
'cpm_uart_init_portdesc':
drivers/serial/cpm_uart/cpm_uart_cpm2.c:364: warning: assignment makes
integer from pointer without a cast
drivers/serial/cpm_uart/cpm_uart_cpm2.c:368: error: invalid type
argument of 'unary *'
make[3]: *** [drivers/serial/cpm_uart/cpm_uart_cpm2.o] Error 1
make[2]: *** [drivers/serial/cpm_uart] Error 2
make[1]: *** [drivers/serial] Error 2
make: *** [drivers] Error 2
The following Code solves the problem:
diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
index 0599030..bb0a6c1 100644
--- a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
+++ b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
@@ -349,7 +349,7 @@ void cpm_uart_freebuf(struct uart_cpm_po
int cpm_uart_init_portdesc(void)
{
#if defined(CONFIG_SERIAL_CPM_SMC1) || defined(CONFIG_SERIAL_CPM_SMC2)
- u32 addr;
+ u32 *addr;
#endif
pr_debug("CPM uart[-]:init portdesc\n");
thanks
Heiko
^ permalink raw reply related
* Re: [PATCH] CPM_UART: Fix non-console initialisation (v2)
From: Kalle Pokki @ 2006-11-10 12:02 UTC (permalink / raw)
To: Kalle Pokki; +Cc: Paul Mackerras, linuxppc-embedded
In-Reply-To: <a425f86c0611100345h40b104cchdb766e35f1767656@mail.gmail.com>
On Fri, 10 Nov 2006, Kalle Pokki wrote:
> OK, better drop all the hunks except the one that concerns
> drivers/serial/cpm_uart/cpm_uart_core.c then, since I added the same
> '__init' lines in cpm_uart.h, cpm_uart_cpm1.c, and cpm_uart_cpm2.c.
Hmm, it seems you already pushed the changes. This should apply to the
current 'merge' branch.
drivers/serial/cpm_uart/cpm_uart_cpm2.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm2.c b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
index b691d3e..787a8f1 100644
--- a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
+++ b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
@@ -282,7 +282,7 @@ void cpm_uart_freebuf(struct uart_cpm_po
}
/* Setup any dynamic params in the uart desc */
-int cpm_uart_init_portdesc(void)
+int __init cpm_uart_init_portdesc(void)
{
#if defined(CONFIG_SERIAL_CPM_SMC1) || defined(CONFIG_SERIAL_CPM_SMC2)
u32 addr;
--
1.4.1.1
^ permalink raw reply related
* Re: ipr SATA support is causing problems
From: Josh Boyer @ 2006-11-10 13:14 UTC (permalink / raw)
To: Paul Mackerras; +Cc: akpm, James Bottomley, linuxppc-dev, torvalds, Jeff Garzik
In-Reply-To: <17748.27504.715056.565983@cargo.ozlabs.ibm.com>
On Fri, 2006-11-10 at 23:07 +1100, Paul Mackerras wrote:
> Josh Boyer writes:
>
> > John Rose reported this a few days ago. Brian responded with this:
> >
> > http://marc.theaimsgroup.com/?l=linux-ide&m=116169938407596&w=2
>
> Didn't John say he still saw the crash with that change?
He did on my suggestion, which technically wasn't correct. I haven't
seen anything from him after Brian replied with a real patch.
I know I helped debug a crash that looked very much like that on a P5
box with a 2.6.19-rcX kernel and Brian's patch fixed it.
josh
^ permalink raw reply
* Re: [PATCH] PowerPC: clockevents and HRT support
From: Sergei Shtylyov @ 2006-11-10 14:08 UTC (permalink / raw)
To: Paul Mackerras; +Cc: tglx, greg.weeks, linuxppc-dev
In-Reply-To: <17748.14621.231956.561842@cargo.ozlabs.ibm.com>
Hello.
Paul Mackerras wrote:
> Sergei Shtylyov writes:
>> And I left people a choice: they can either have fancy accounting or HRT,
>>just not both at once. What's wrong with that?
> _I_ want both at once. :)
I think the usual rule is: "you want it, you do it". ;-)
Seriously, we have neither time, not hardware, nor docs for the h/w this
accounting option applies to. And coercing the generic clcokevents/hrtimers
code into calling the arch hooks is serious design decision which I felt is
better to be left to Thomas as a maintainer...
> Paul.
WBR, Sergei
^ permalink raw reply
* Re: Low memory not pageable on Freescale BookE
From: Kumar Gala @ 2006-11-10 14:17 UTC (permalink / raw)
To: M Ptich; +Cc: linuxppc-dev
In-Reply-To: <BAY102-F187E9196477E724317B9C6A9F70@phx.gbl>
On Nov 10, 2006, at 2:14 AM, M Ptich wrote:
> For our application, we need low memory to be mapped with pages,
> but it
> turned out that Freescale BookE maps it with TLB1. Was there any
> particular
> reason why ? I am thinking of changing it, but wondering if there was
> something fundamental behind it.
Why do you need low kernel memory to be pageable?
- kumar
^ permalink raw reply
* Re: ipr SATA support is causing problems
From: Brian King @ 2006-11-10 15:07 UTC (permalink / raw)
To: Josh Boyer
Cc: akpm, James Bottomley, John H Rose, linuxppc-dev, torvalds,
Paul Mackerras, Jeff Garzik
In-Reply-To: <1163164499.4168.3.camel@zod.rchland.ibm.com>
Josh Boyer wrote:
> On Fri, 2006-11-10 at 23:07 +1100, Paul Mackerras wrote:
>> Josh Boyer writes:
>>
>>> John Rose reported this a few days ago. Brian responded with this:
>>>
>>> http://marc.theaimsgroup.com/?l=linux-ide&m=116169938407596&w=2
>> Didn't John say he still saw the crash with that change?
>
> He did on my suggestion, which technically wasn't correct. I haven't
> seen anything from him after Brian replied with a real patch.
>
> I know I helped debug a crash that looked very much like that on a P5
> box with a 2.6.19-rcX kernel and Brian's patch fixed it.
Paul,
The backtrace you posted is identical to the problem fixed by the patch
that Josh pointed you to. The patch has been submitted to Jeff. I asked
Jeff two days ago if this could be pulled in for 2.6.19. I verified the
bug and the fix on my machine. As far as I know, John still has not tried
the actual patch pointed to above. Just to clarify, without this patch,
any monolithic kernel will not work on pseries, but modular kernels will
still work. If someone can reproduce any problem with the libata patch
above applied, please let me know.
Brian
--
Brian King
eServer Storage I/O
IBM Linux Technology Center
^ permalink raw reply
* Re: ipr SATA support is causing problems
From: Brian King @ 2006-11-10 15:23 UTC (permalink / raw)
To: Paul Mackerras; +Cc: akpm, linuxppc-dev, torvalds, James Bottomley
In-Reply-To: <17748.25705.543922.486456@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Brian,
>
> Today I compiled up a kernel from Linus' git tree and tried it on a
> POWER6 partition. First I found that my config no longer had the ipr
> driver, because I didn't have CONFIG_ATA and ipr now depends on
> CONFIG_ATA. So I enabled CONFIG_ATA without enabling any of the ATA
> chip drivers, which seems a little weird, and re-enabled ipr.
I'm not sure what the best way to fix this one is... The ideal way is to
change ipr to select CONFIG_ATA, but kconfig currently doesn't handle
that and complains about recursive dependencies since IPR depends on
CONFIG_SCSI and CONFIG_ATA selects CONFIG_SCSI. I'm guessing the
libsas SATA usage has similar problems. Right now we both use a depends
CONFIG_ATA statement. Ideally, kconfig should be fixed to handle this.
Brian
--
Brian King
eServer Storage I/O
IBM Linux Technology Center
^ permalink raw reply
* Modules Problem on ML403
From: alayrac christophe @ 2006-11-10 16:50 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
We succeed to port linux2-4.26 on ML403 board with Montavista RFS on CF
or NFS.
Problems arise when we try to use modules.
We have include gpio modules in the kernel and build follow
make ARCH=ppc CROSS_COMPILE=powerpc-405-linux-gnu- dep uImage
make ARCH=ppc CROSS_COMPILE=powerpc-405-linux-gnu- modules
the modules_install fail during depmod process because it no supports
cross compiling
I've then think to use the Klingauf scripts (make_modules_install.sh,
depmod.pl) but I was afraid that the command
make modules_install copy modules in the host lib/modules directory.
SO I manually proceed as follow from the kernel root :
make ARCH=ppc CROSS_COMPILE=powerpc-405-linux-gnu- modules_install
INSTALL_MOD_PATH=/home/alayrac/
and then
./depmod.pl -k ./vmlinux -F ./System.map -b /home/alayrac/lib/modules -n
> /home/alayrac/lib/modules/2.4.26/modules.dep
Modules seems to be created properly but after board and linux start up
I receive the following error message:
insmod xilinx_gpio
Using /lib/modules/2.4.26/kernel/drivers/char/xilinx_gpio/xilinx_gpio.o
/lib/modules/2.4.26/kernel/drivers/char/xilinx_gpio/xilinx_gpio.o:
couldn't find the kernel version the module was compiled for
modprobe xilinx_gpio
/lib/modules/2.4.26/kernel/drivers/char/xilinx_gpio/xilinx_gpio.o:
couldn't find the kernel version the module was compiled
r/lib/modules/2.4.26/kernel/drivers/char/xilinx_gpio/xilinx_gpio.o:
insmod /lib/modules/2.4.26/kernel/drivers/char/xilinx_gpid/lib/modules/2.4.26/kernel/drivers/char/xilinx_gpio.o: couldn't find the kernel version the module was compiled for
/lib/modules/2.4.26/kernel/drivers/char/xilinx_gpio.o:
insmod /lib/modules/2.4.26/kernel/drivers/char/xilinx_gpio.o failed
/lib/modules/2.4.26/kernel/drivers/char/xilinx_gpio.o: insmod
xilinx_gpio failed
Further more the date of files in /lib/modules/2.4.26 are to a very hold
date during the boot process. Thus the modules.conf is declared as more
recent than modules.dep.
Any help would be appreciated .
Kinds regards
Chris
^ permalink raw reply
* [PATCH]: PowerPC: make sure the rtas stop-self token is defined.
From: Linas Vepstas @ 2006-11-10 18:22 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Paul,
I presume this looks reasonable, please apply.
--linas
There are a variety of code paths that lead to rtas_stop_self()
being called, primarily through cpu_die(). However, rtas_stop_self()
has a BUG_ON(rtas_args->token == RTAS_UNKNOWN_SERVICE); in it, and
this rtas token is only set up if CONFIG_HOTPLUG_CPU is defined.
Rather than wrapping all of the callers of rtas_stop_self()
with CONFIG_HOTPLUG_CPU, it seems wiser to just unwrap the token
definition.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
arch/powerpc/kernel/rtas.c | 2 --
1 file changed, 2 deletions(-)
Index: linux-2.6.19-rc4-git3/arch/powerpc/kernel/rtas.c
===================================================================
--- linux-2.6.19-rc4-git3.orig/arch/powerpc/kernel/rtas.c 2006-11-10 12:13:17.000000000 -0600
+++ linux-2.6.19-rc4-git3/arch/powerpc/kernel/rtas.c 2006-11-10 12:13:40.000000000 -0600
@@ -879,9 +879,7 @@ void __init rtas_initialize(void)
#endif
rtas_rmo_buf = lmb_alloc_base(RTAS_RMOBUF_MAX, PAGE_SIZE, rtas_region);
-#ifdef CONFIG_HOTPLUG_CPU
rtas_stop_self_args.token = rtas_token("stop-self");
-#endif
#ifdef CONFIG_RTAS_ERROR_LOGGING
rtas_last_error_token = rtas_token("rtas-last-error");
#endif
^ permalink raw reply
* RE: minor progress with plb_temac v3.00a, EDK 8.2, & 2.6.18.1
From: robert corley @ 2006-11-10 19:53 UTC (permalink / raw)
To: linux linuxppc-embedded
Rimas;=0A=0AGood call on the PHY address. I thought that I was on to somet=
hing when=0AI saw that a week or so ago; however, after I checked the datas=
heet on the=0AMARVELL 88E1111 PHY chip and its connection on the ML403 boar=
d, I=0Afound that it is addressed to 0b00000.=0A=0AIt does appear that acce=
ss to the mgmt registers is working, albeit not completely=0Aas expected (s=
ee boot dump, below) with regards to the PHY ID.=0A=0AThe initialization pr=
ocess is pretty simple:=0A=0A1. Query the PHY [using XTemac_PhyRead(...)=
] and see what speed it's set to:=0A=0A [ 5.358347] XTemac(set_mac_sp=
eed): PHY Speed from XTemac_PhyRead() =3D 0M, where 2=3D1000M, 1=3D100M, an=
d 0=3D10M=0A=0A=0A2. Set the MAC to the same speed (in a switch statemen=
t):=0A XTemac_SetOperatingSpeed(&lp->Emac, 10);=0A=0AI suspect t=
hat the problem is with the first step as it is reporting a different speed=
than what the LED's on the board show.=0A=0AAny thoughts?=0A =0ARobert Cor=
ley (rdcorle@yahoo.com)=0A=0A=0A=0A=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0Apartial boot dump fol=
lows...=0A=0A=0A[ 2.706547] XTemac (xtenet_probe): Device initialized to=
:=0A[ 2.712064] Device ID 0=0A[ 2.714595] Base Addr 0x6=
0000000=0A[ 2.717918] Rx FIFO 131072=0A[ 2.720723] Tx FIFO=
131072=0A[ 2.723508] MAC FIFO 64=0A[ 2.726052] DMA mod=
e 3=0A[ 2.728514] TX Dre 2=0A[ 2.730782] Rx Dre 2=0A=
[ 2.733067] Tx CSUM 0=0A[ 2.735421] Rx CSUM 0=0A[ 2.=
737792] Phy Type 1=0A[ 2.740268] XTemac (xtenet_probe): MAC initi=
alized to: 00:0A:35:00:22:00=0A[ 2.746964] XTemac: using sgDMA mode.=0A[=
2.750637] XTemac: using TxDRE mode=0A[ 2.754221] XTemac: using RxDRE=
mode=0A[ 2.757815] XTemac: buffer descriptor size: 32768 (0x8000)=0A[ =
2.763779] XTemac: (buffer_descriptor_init) phy: 0x978000, virt: 0xff10000=
0, size: 0x8000=0A[ 2.777432] eth0: Dropping NETIF_F_SG since no checksu=
m feature.=0A[ 2.784323] eth0: Xilinx TEMAC #0 at 0x60000000 mapped to 0=
xC5050000, irq=3D0=0A[ 2.791327] eth0: XTemac id 1.0f, block id 5, type =
8=0A[ 2.796886] mice: PS/2 mouse device common for all mice=0A[ 2.802=
782] TCP bic registered=0A[ 3.308299] eth0: XTemac: Options: 0xb8f2=0A[ =
5.306282] XTemac(marvell_reset): Marvell 88E1111 reset.=0A[ 5.311715]=
XTemac: (set_mac_speed) Marvell 88E1111 basic-mode status register(#1) =3D=
0x0148=0A[ 5.320083] XTemac: (set_mac_speed) Marvell 88E1111 PHY ID 1 =
=3D 0x0000=0A[ 5.326547] XTemac: (set_mac_speed) Marvell 88E1111 PHY ID =
2 =3D 0x0400=0A[ 5.333009] XTemac: (set_mac_speed) Marvell 88E1111 1000B=
ASE-T status register(#10) =3D 0x0000=0A[ 5.341466] XTemac: (set_mac_spe=
ed) Marvell 88E1111 extended status register(#15) =3D 0x0000=0A[ 5.34975=
2] XTemac: (set_mac_speed) Marvell 88E1111 PHY specific status register(#17=
) =3D 0x0000=0A[ 5.358347] XTemac(set_mac_speed): PHY Speed from XTemac_=
PhyRead() =3D 0M, where 2=3D1000M, 1=3D100M, and 0=3D10M=0A[ 5.367887] e=
th0: XTemac: EMAC speed set to 10Mb/s=0A[ 5.372666] XTemac (set_mac_spee=
d): verifying speed settings. Expect 10M=0A[ 5.379480] XTemac: (set_mac=
_speed) Marvell 88E1111 PHY specific status register(#17) =3D 0x0900=0A[ =
5.388074] eth0: XTemac: PHY Speed from XTemac_PhyRead() =3D 0M, where 2=3D=
1000M, 1=3D100M, and 0=3D10M=0A[ 5.396839] eth0: XTemac: EMAC Speed from=
XTemac_GetOperatingSpeed() =3D 10M=0A[ 5.405544] eth0: XTemac: Send Thr=
eshold =3D 16, Receive Threshold =3D 2=0A[ 5.411917] eth0: XTemac: Send =
Wait bound =3D 1, Receive Wait bound =3D 1=0A[ 6.420309] IP-Config: Comp=
lete:=0A[ 6.423375] device=3Deth0, addr=3D192.168.1.100, mask=3D25=
5.255.255.0, gw=3D192.168.1.1,=0A[ 6.431272] host=3Dnab, domain=3D,=
nis-domain=3D(none),=0A[ 6.436422] bootserver=3D192.168.1.144, roo=
tserver=3D192.168.1.144, rootpath=3D=0A=0A=0A=0A=0A=0A
^ permalink raw reply
* [PATCH 0/16] patches for 2.6.20
From: Geoff Levand @ 2006-11-10 20:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Paul,
This is the set of patches I have queued for 2.6.20. Patches 1-6 have
already been posted, but I did some re-work on a few to bring them up
to the latest powerpc.git. Patches 7-16 are new and add the core
platform support for the PS3 game console.
For the convenience of anyone interested, I have put this patchset, plus
a few other drivers I am working on with some info here:
http://67.117.136.164/pub/cell/
-Geoff
^ permalink raw reply
* [PATCH 2/16] spufs: change ppc_rtas declaration to weak
From: Geoff Levand @ 2006-11-10 20:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Arnd Bergmann
Change the definition of powerpc's cond_syscall() to use the standard gcc
weak attribute specifier which provides proper support for C linkage as
needed by spu_syscall_table[].
Fixes this powerpc build error with CONFIG_SPU_FS=y, CONFIG_PPC_RTAS=n:
arch/powerpc/platforms/built-in.o: undefined reference to `ppc_rtas'
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
include/asm-powerpc/unistd.h | 12 ++----------
1 file changed, 2 insertions(+), 10 deletions(-)
Index: cell--common--6/include/asm-powerpc/unistd.h
===================================================================
--- cell--common--6.orig/include/asm-powerpc/unistd.h
+++ cell--common--6/include/asm-powerpc/unistd.h
@@ -445,7 +445,6 @@
#include <linux/types.h>
#include <linux/compiler.h>
#include <linux/linkage.h>
-#include <asm/syscalls.h>
#define __ARCH_WANT_IPC_PARSE_VERSION
#define __ARCH_WANT_OLD_READDIR
@@ -480,16 +479,9 @@
/*
* "Conditional" syscalls
- *
- * What we want is __attribute__((weak,alias("sys_ni_syscall"))),
- * but it doesn't work on all toolchains, so we just do it by hand
*/
-#ifdef CONFIG_PPC32
-#define cond_syscall(x) asm(".weak\t" #x "\n\t.set\t" #x ",sys_ni_syscall")
-#else
-#define cond_syscall(x) asm(".weak\t." #x "\n\t.set\t." #x ",.sys_ni_syscall")
-#endif
-
+#define cond_syscall(x) \
+ asmlinkage long x (void) __attribute__((weak,alias("sys_ni_syscall")))
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
^ permalink raw reply
* [PATCH 3/16] cell: set ARCH_SPARSEMEM_DEFAULT in Kconfig
From: Geoff Levand @ 2006-11-10 20:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Arnd Bergmann
The current cell processor support needs sparsemem, so set it as
the default memory model.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
As noted by Benjamin Herrenschmidt.
Index: cell--common--6/arch/powerpc/Kconfig
===================================================================
--- cell--common--6.orig/arch/powerpc/Kconfig
+++ cell--common--6/arch/powerpc/Kconfig
@@ -734,7 +734,7 @@
config ARCH_SPARSEMEM_DEFAULT
def_bool y
- depends on SMP && PPC_PSERIES
+ depends on (SMP && PPC_PSERIES) || PPC_CELL
config ARCH_POPULATES_NODE_MAP
def_bool y
^ permalink raw reply
* [PATCH 4/16] powerpc: check for null init_early routine
From: Geoff Levand @ 2006-11-10 20:01 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Add a check for a null ppc_md.init_early to allow platforms that
don't require an init_early routine to just set this member to null.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
arch/powerpc/kernel/setup_64.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: cell--common--6/arch/powerpc/kernel/setup_64.c
===================================================================
--- cell--common--6.orig/arch/powerpc/kernel/setup_64.c
+++ cell--common--6/arch/powerpc/kernel/setup_64.c
@@ -392,7 +392,8 @@
* setting up the hash table pointers. It also sets up some interrupt-mapping
* related options that will be used by finish_device_tree()
*/
- ppc_md.init_early();
+ if (ppc_md.init_early)
+ ppc_md.init_early();
/*
* We can discover serial ports now since the above did setup the
^ 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