* Re: [PATCH] powerpc: setup Marvell mv64x60 platform devices for EDAC
From: Dale Farnsworth @ 2007-05-23 20:23 UTC (permalink / raw)
To: djiang, Linuxppc-dev, paulus, bluesmoke-devel
In-Reply-To: <20070522232432.GA26046@blade.az.mvista.com>
Dave Jiang wrote:
> Creating platform devices (memory controller, sram error registers, cpu error
> registers, PCI error registers) for Error Detection and Correction (EDAC)
> driver on the Marvell mv64x60 based platforms.
>
> The platform devices allow the mv64x60 EDAC driver to detect errors from the
> memory controller (ECC erorrs), SRAM controller, CPU data path error registers,
> and PCI error registers. The errors are reported to syslog. Software ECC
> scrubbing is provided. These replace the mv64x60 error handlers in the
> ppc branch
> They are being moved to EDAC subsystem in order to centralize error reporting.
>
> The error reporting can be triggered via interrupts from the mv64x60 bridge chip
> or via polling mechanism provided by the EDAC core code.
>
> The mv64x60 EDAC driver can be found at:
> http://bluesmoke.sourceforge.net/
>
> It's in development to be pushed into the kernel.
>
> Signed-off-by: Dave Jiang <djiang@mvista.com>
Acked-by: Dale Farnsworth <dale@farnsworth.org>
^ permalink raw reply
* Re: [PATCH] pseries: asm/pci-bridge.h CONFIG_ minor cleanup
From: Linas Vepstas @ 2007-05-23 20:51 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1179882692.6145.8.camel@concordia.ozlabs.ibm.com>
On Wed, May 23, 2007 at 11:11:32AM +1000, Michael Ellerman wrote:
>
> Yeah who knows. The hole doesn't really matter unless the struct gets
> bigger, having the EEH stuff at the bottom makes it read better which is
> probably more important.
Havin become proficient at adding hex addrs in my head, I have also
come to appreciate structs which have all the important/hot stuff
at the top, instead of large filler holes that one has to skip over
during debugging.
--linas
^ permalink raw reply
* Re: powerpc_flash_init(), wtf!?
From: Mark A. Greer @ 2007-05-23 21:57 UTC (permalink / raw)
To: linuxppc-dev
Sorry, I've lost the thread in my inbox so I can't reply to it directly.
Is something like this what everyone agreed upon?
Mark
--
diff --git a/arch/powerpc/platforms/embedded6xx/prpmc2800.c b/arch/powerpc/platforms/embedded6xx/prpmc2800.c
index d9db135..44c3144 100644
--- a/arch/powerpc/platforms/embedded6xx/prpmc2800.c
+++ b/arch/powerpc/platforms/embedded6xx/prpmc2800.c
@@ -20,6 +20,7 @@
#include <asm/system.h>
#include <asm/time.h>
#include <asm/kexec.h>
+#include <asm/of_platform.h>
#include <mm/mmu_decl.h>
@@ -134,6 +135,18 @@ void prpmc2800_show_cpuinfo(struct seq_file *m)
}
/*
+ * Register a platform device for MTD.
+ */
+static int __init prpmc2800_register_mtd(void)
+{
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, "rom", "direct-mapped");
+ of_platform_device_create(np, np->name, NULL);
+}
+arch_initcall(prpmc2800_register_mtd);
+
+/*
* Called very early, device-tree isn't unflattened
*/
static int __init prpmc2800_probe(void)
^ permalink raw reply related
* [PATCH] powerpc: Add Marvell mv64x60 udbg putc/getc functions
From: Dale Farnsworth @ 2007-05-23 22:05 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Currently, when the Marvell mpsc driver is used as console,
any console output that occurs before the Marvell mpsc driver
is initialized is discarded by the udbg console.
This patch resolves that issue by providing udbg_putc() and
udbg_getc() functions for the Marvell mv64x60 chips. These functions
are enabled if an mv64x60 port is to be used as the console as
determined from the device tree.
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
Acked-by: Mark A. Greer <mgreer@mvista.com>
---
Paul, this patch is unchanged from the one I posted 10 days ago.
At that time, I saw no discussion, other than Mark's ACK. I'd
argue that this is a bugfix, and hope that it could go into 2.6.22.
Thanks.
-Dale
arch/powerpc/platforms/embedded6xx/prpmc2800.c | 1
arch/powerpc/sysdev/Makefile | 3
arch/powerpc/sysdev/mv64x60.h | 1
arch/powerpc/sysdev/mv64x60_udbg.c | 152 +++++++++++++++
4 files changed, 156 insertions(+), 1 deletion(-)
Index: linux-2.6-powerpc-df/arch/powerpc/sysdev/mv64x60_udbg.c
===================================================================
--- /dev/null
+++ linux-2.6-powerpc-df/arch/powerpc/sysdev/mv64x60_udbg.c
@@ -0,0 +1,152 @@
+/*
+ * udbg serial input/output routines for the Marvell MV64x60 (Discovery).
+ *
+ * Author: Dale Farnsworth <dale@farnsworth.org>
+ *
+ * 2007 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#include <asm/io.h>
+#include <asm/prom.h>
+#include <asm/udbg.h>
+
+#include <sysdev/mv64x60.h>
+
+#define MPSC_0_CR1_OFFSET 0x000c
+
+#define MPSC_0_CR2_OFFSET 0x0010
+#define MPSC_CHR_2_TCS (1 << 9)
+
+#define MPSC_0_CHR_10_OFFSET 0x0030
+
+#define MPSC_INTR_CAUSE_OFF_0 0x0004
+#define MPSC_INTR_CAUSE_OFF_1 0x000c
+#define MPSC_INTR_CAUSE_RCC (1<<6)
+
+static void __iomem *mpsc_base;
+static void __iomem *mpsc_intr_cause;
+
+static void mv64x60_udbg_putc(char c)
+{
+ if (c == '\n')
+ mv64x60_udbg_putc('\r');
+
+ while(in_le32(mpsc_base + MPSC_0_CR2_OFFSET) & MPSC_CHR_2_TCS)
+ ;
+ out_le32(mpsc_base + MPSC_0_CR1_OFFSET, c);
+ out_le32(mpsc_base + MPSC_0_CR2_OFFSET, MPSC_CHR_2_TCS);
+}
+
+static int mv64x60_udbg_testc(void)
+{
+ return (in_le32(mpsc_intr_cause) & MPSC_INTR_CAUSE_RCC) != 0;
+}
+
+static int mv64x60_udbg_getc(void)
+{
+ int cause = 0;
+ int c;
+
+ while (!mv64x60_udbg_testc())
+ ;
+
+ c = in_8(mpsc_base + MPSC_0_CHR_10_OFFSET + 2);
+ out_8(mpsc_base + MPSC_0_CHR_10_OFFSET + 2, c);
+ out_le32(mpsc_intr_cause, cause & ~MPSC_INTR_CAUSE_RCC);
+ return c;
+}
+
+static int mv64x60_udbg_getc_poll(void)
+{
+ if (!mv64x60_udbg_testc())
+ return -1;
+
+ return mv64x60_udbg_getc();
+}
+
+static void mv64x60_udbg_init(void)
+{
+ struct device_node *np, *mpscintr, *stdout = NULL;
+ const char *path;
+ const phandle *ph;
+ struct resource r[2];
+ const int *block_index;
+ int intr_cause_offset;
+ int err;
+
+ path = of_get_property(of_chosen, "linux,stdout-path", NULL);
+ if (!path)
+ return;
+
+ stdout = of_find_node_by_path(path);
+ if (!stdout)
+ return;
+
+ for (np = NULL;
+ (np = of_find_compatible_node(np, "serial", "marvell,mpsc")); )
+ if (np == stdout)
+ break;
+
+ of_node_put(stdout);
+ if (!np)
+ return;
+
+ block_index = of_get_property(np, "block-index", NULL);
+ if (!block_index)
+ goto error;
+
+ switch (*block_index) {
+ case 0:
+ intr_cause_offset = MPSC_INTR_CAUSE_OFF_0;
+ break;
+ case 1:
+ intr_cause_offset = MPSC_INTR_CAUSE_OFF_1;
+ break;
+ default:
+ goto error;
+ }
+
+ err = of_address_to_resource(np, 0, &r[0]);
+ if (err)
+ goto error;
+
+ ph = of_get_property(np, "mpscintr", NULL);
+ mpscintr = of_find_node_by_phandle(*ph);
+ if (!mpscintr)
+ goto error;
+
+ err = of_address_to_resource(mpscintr, 0, &r[1]);
+ of_node_put(mpscintr);
+ if (err)
+ goto error;
+
+ of_node_put(np);
+
+ mpsc_base = ioremap(r[0].start, r[0].end - r[0].start + 1);
+ if (!mpsc_base)
+ return;
+
+ mpsc_intr_cause = ioremap(r[1].start, r[1].end - r[1].start + 1);
+ if (!mpsc_intr_cause) {
+ iounmap(mpsc_base);
+ return;
+ }
+ mpsc_intr_cause += intr_cause_offset;
+
+ udbg_putc = mv64x60_udbg_putc;
+ udbg_getc = mv64x60_udbg_getc;
+ udbg_getc_poll = mv64x60_udbg_getc_poll;
+
+ return;
+
+error:
+ of_node_put(np);
+}
+
+void mv64x60_init_early(void)
+{
+ mv64x60_udbg_init();
+}
Index: linux-2.6-powerpc-df/arch/powerpc/sysdev/Makefile
===================================================================
--- linux-2.6-powerpc-df.orig/arch/powerpc/sysdev/Makefile
+++ linux-2.6-powerpc-df/arch/powerpc/sysdev/Makefile
@@ -17,7 +17,8 @@ obj-$(CONFIG_FSL_PCIE) += fsl_pcie.o
obj-$(CONFIG_TSI108_BRIDGE) += tsi108_pci.o tsi108_dev.o
obj-$(CONFIG_QUICC_ENGINE) += qe_lib/
mv64x60-$(CONFIG_PCI) += mv64x60_pci.o
-obj-$(CONFIG_MV64X60) += $(mv64x60-y) mv64x60_pic.o mv64x60_dev.o
+obj-$(CONFIG_MV64X60) += $(mv64x60-y) mv64x60_pic.o mv64x60_dev.o \
+ mv64x60_udbg.o
# contains only the suspend handler for time
obj-$(CONFIG_PM) += timer.o
Index: linux-2.6-powerpc-df/arch/powerpc/platforms/embedded6xx/prpmc2800.c
===================================================================
--- linux-2.6-powerpc-df.orig/arch/powerpc/platforms/embedded6xx/prpmc2800.c
+++ linux-2.6-powerpc-df/arch/powerpc/platforms/embedded6xx/prpmc2800.c
@@ -158,6 +158,7 @@ define_machine(prpmc2800){
.name = prpmc2800_platform_name,
.probe = prpmc2800_probe,
.setup_arch = prpmc2800_setup_arch,
+ .init_early = mv64x60_init_early,
.show_cpuinfo = prpmc2800_show_cpuinfo,
.init_IRQ = mv64x60_init_irq,
.get_irq = mv64x60_get_irq,
Index: linux-2.6-powerpc-df/arch/powerpc/sysdev/mv64x60.h
===================================================================
--- linux-2.6-powerpc-df.orig/arch/powerpc/sysdev/mv64x60.h
+++ linux-2.6-powerpc-df/arch/powerpc/sysdev/mv64x60.h
@@ -7,5 +7,6 @@ extern void __init mv64x60_init_irq(void
extern unsigned int mv64x60_get_irq(void);
extern void __init mv64x60_pci_init(void);
+extern void __init mv64x60_init_early(void);
#endif /* __MV64X60_H__ */
^ permalink raw reply
* RE: [PATCH 0/5] Add the support for MPC8641 silicon rev 2.0 andMPC8641HPCN board 2.0
From: Wade Farnsworth @ 2007-05-23 22:37 UTC (permalink / raw)
To: Zhang Wei-r63237; +Cc: linuxppc-dev, paulus
In-Reply-To: <46B96294322F7D458F9648B60E15112C234A09@zch01exm26.fsl.freescale.net>
On Wed, 2007-05-23 at 10:48 +0800, Zhang Wei-r63237 wrote:
> Hi,
>
> They are against to Paul's git tree and I've verified these patches
> again today.
>
> They can be applied to Paul's top git tree successfully.
>
> Thanks!
> Wei
>
You're right, they do apply. My local copy must have been messed up
somehow. Sorry for the noise.
--Wade
^ permalink raw reply
* RE: TSI ethernet PHY question
From: Benjamin Herrenschmidt @ 2007-05-23 22:52 UTC (permalink / raw)
To: Alexandre Bounine; +Cc: linuxppc-dev list, David Gibson
In-Reply-To: <1B5F013528140F45B5C671039279CA5701BBBDE3@NANUK.pc.tundra.com>
> On power up, because this pin is pulled high by the LED, the
> TXC_RXC_DELAY mode is enabled, causing a 1.9ns delay between the clock
> and data on the GMII interface. Tsi109 could not operate properly with
> this delay. The TXC_RXC_DELAY mode has to be disabled by software.
>
> If the Quality/TXC_RXC_DELAY pin is left not connected PHY will work in
> normal mode without delay and therefore the workaround is not required.
Ok, so this is a workaround that is specific to the Holly board...
interesting. I have to figure out what is the best way of having it in a
"generic" PHY driver for the BCM5461A chip.
Right now, we're seeing a problem where the driver doesn't detect a link
up. It detects the link at boot fine. If we disconnect the cable, it
sees the link going down, but it never sees the link going back up. I
haven't investigated much yet but I wanted to understand this workaround
in case it could be related.
> I think that for situations like one on the Holly board we may need
> board-specific hooks which modify normal initialization. As in our case:
> no LED - no trouble.
Yes, I need to look into that.
> I have put into my plans switching Tsi108/9 driver to common PHY lib
> (after Josh released his patch for Holly) but it looks like you will
> beat me here - I still have to close some other tasks. Let me know if I
> can help with anything around Tsi109.
We'll see, I said I'm contemplating the idea, doesn't mean I'll actually
do it anytime soon :-)
Cheers,
Ben.
^ permalink raw reply
* Re: Porting RapidIO from ppc arch to powerpc arch in support of MPC8641D
From: Segher Boessenkool @ 2007-05-23 23:05 UTC (permalink / raw)
To: pterry; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <1179937253.11247.44.camel@pterry-fc6.micromemory.com>
>> If the firmware sets up the "law", it should put a property
>> in the node describing the setting. If Linux sets up the
>> laws, there shouldn't be a property (since it is a policy
>> decision).
> Ooops, I just posted a question to you before I saw this pop up sorry?
No problem.
> But when you say "firmware" do you mean u-boot or your kernel loading
> code or do you mean some aspect of the hardware, eg, its EEPROM program
> which can vary from hardware to hardware instantiation?
Any of those. Anything before the kernel takes control.
> If you mean u-boot I'm confused (so whats new?). AFAIK u-boot can't
> probe and set this up
Maybe it should.
> and even if it did, linux in the arch's I'm
> familiar with sets everything up anew regardless of what the boot
> loader
> did.
...and maybe that needs changing.
If it's a platform thing, it's the platform firmware code
that should configure it (and then it belongs in the device
tree). If reasonably the kernel should configure it later,
_it_ should do it (and then there shouldn't be a device tree
property).
I have no clue which it is.
Segher
^ permalink raw reply
* Re: Porting RapidIO from ppc arch to powerpc arch in support of MPC8641D
From: Segher Boessenkool @ 2007-05-23 23:17 UTC (permalink / raw)
To: pterry; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <1179938586.11247.62.camel@pterry-fc6.micromemory.com>
> OK, but if the device tree is not allowed to dictate policy, to use
> Segher's term, just hardware characteristics, how does that help us get
> the embedded soc kernels away from being designed and built to specific
> demo/eval board setups and make them more configurable?
I don't see the problem really. Could you point out one
specific problem, and then we solve it? Repeat as necessary.
> I got the impression that to some extent thats how you/we/?? were
> trying
> to use the dts stuff. If my board is exactly like freescales xyz demo
> board except I move my rio map to here, my pci map to here, change a
> few
> sizes etc., why do I have to go and patchup the arch setup code, modify
> ppc_md routines, etc.
That shouldn't be necessary.
> Isn't the plan that I just edit the dts, compile
> with dtc and have u-boot pass in the dtb to the stock kernel and its
> boots on my board?
Mostly, yes.
> If dts can't do this because its not allowed policy statements then
> what
> will do this?
You pass policy decisions to the kernel some other way. Like,
on the kernel command line, for example.
> Segher is right,
Yes, I always am.
> Please I'm not trying to start up any previous turf wars here,
Much appreciated!
--
Okay, if I am to help at all here, please someone explain what
"law"s and mboxes and doorbells are (in the context of rapidio).
Also how they are used, etc.
Segher
^ permalink raw reply
* Re: [PATCH 1/4] powerpc: Add EEH sysfs blinkenlights
From: Nathan Lynch @ 2007-05-23 23:22 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070523171646.GA32380@austin.ibm.com>
Hi Linas-
Linas Vepstas wrote:
>
> Add sysfs blinkenlights for EEH statistics. Shuffle the
> eeh_add_device_tree() call so that it appears in the correct
> sequence.
( blinkenlights? :)
To me this seems a somewhat terse changelog considering that the patch
introduces a user-visible interface. The changelog does not really
say what the code is doing or why, or who will use it.
> Index: linux-2.6.22-rc1/arch/powerpc/platforms/pseries/eeh_sysfs.c
> ===================================================================
> --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> +++ linux-2.6.22-rc1/arch/powerpc/platforms/pseries/eeh_sysfs.c 2007-05-23 11:57:23.000000000 -0500
> @@ -0,0 +1,84 @@
> +/*
> + * Sysfs entries for PCI Error Recovery for PAPR-compliant platform.
platforms?
> +#include <linux/pci.h>
> +#include <asm/ppc-pci.h>
> +#include <asm/pci-bridge.h>
> +#include <linux/kobject.h>
Include linux/ before asm/ please.
> +/**
> + * EEH_SHOW_ATTR -- create sysfs entry for eeh statistic
> + * @_name: name of file in sysfs directory
> + * @_memb: name of member in struct pci_dn to access
> + * @_format: printf format for display
> + *
> + * All of the attributes look very similar, so just
> + * auto-gen a cut-n-paste routine to display them.
> + */
> +#define EEH_SHOW_ATTR(_name,_memb,_format) \
> +static ssize_t eeh_show_##_name(struct device *dev, \
> + struct device_attribute *attr, char *buf) \
I have been frustrated by similar constructions more than once in the
midst of debugging. I know this has become a common practice with
sysfs-related code, but using cpp to generate function names
completely defeats grep etc. when you're trying to track down a
problem, and I'd not like to see this sort of thing propagated.
> --- linux-2.6.22-rc1.orig/include/asm-powerpc/ppc-pci.h 2007-05-23 11:43:42.000000000 -0500
> +++ linux-2.6.22-rc1/include/asm-powerpc/ppc-pci.h 2007-05-23 11:44:43.000000000 -0500
> @@ -139,6 +139,9 @@ void eeh_clear_slot (struct device_node
> */
> struct device_node * find_device_pe(struct device_node *dn);
>
> +void eeh_sysfs_add_device(struct pci_dev *pdev);
> +void eeh_sysfs_remove_device(struct pci_dev *pdev);
Don't you need dummy static inline placeholders for CONFIG_EEH=n?
^ permalink raw reply
* Re: [PATCH] powerpc: Add Marvell mv64x60 udbg putc/getc functions
From: Olof Johansson @ 2007-05-23 23:27 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070523220518.GA2312@xyzzy.farnsworth.org>
On Wed, May 23, 2007 at 03:05:18PM -0700, Dale Farnsworth wrote:
> arch/powerpc/platforms/embedded6xx/prpmc2800.c | 1
> arch/powerpc/sysdev/Makefile | 3
> arch/powerpc/sysdev/mv64x60.h | 1
> arch/powerpc/sysdev/mv64x60_udbg.c | 152 +++++++++++++++
> 4 files changed, 156 insertions(+), 1 deletion(-)
Is there a reason you're not putting it with the other udbg code, and
not naming it with the same scheme (kernel/udbg_<xxx>)?
Or maybe we should just move the udbg_16550 code to sysdev instead, it's
roots are from ppc64 where we didn't have sysdev.
-Olof
^ permalink raw reply
* Re: [PATCH 1/4] powerpc: Add EEH sysfs blinkenlights
From: Stephen Rothwell @ 2007-05-23 23:42 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070523171646.GA32380@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 297 bytes --]
Hi Linas,
On Wed, 23 May 2007 12:16:46 -0500 linas@austin.ibm.com (Linas Vepstas) wrote:
>
>
> + if (rc)
> + printk(KERN_WARNING "EEH: Unable to create sysfs entries\n");
Maybe use dev_warn?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] powerpc: remove dead EEH code.
From: Stephen Rothwell @ 2007-05-23 23:53 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070523172338.GC32380@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 721 bytes --]
On Wed, 23 May 2007 12:23:38 -0500 linas@austin.ibm.com (Linas Vepstas) wrote:
>
> @@ -1221,11 +1220,10 @@ static int proc_eeh_show(struct seq_file
> "check not wanted=%ld\n"
> "eeh_total_mmio_ffs=%ld\n"
> "eeh_false_positives=%ld\n"
> - "eeh_ignored_failures=%ld\n"
> "eeh_slot_resets=%ld\n",
> no_device, no_dn, no_cfg_addr,
> ignored_check, total_mmio_ffs,
> - false_positives, ignored_failures,
> + false_positives,
> slot_resets);
This changes a user visible interface - are we sure noone uses it?
(I suspect it is fine because of the format, but just asking anyway.)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] powerpc: tweak EEH copyright info
From: Stephen Rothwell @ 2007-05-23 23:55 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070523172801.GD32380@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 335 bytes --]
On Wed, 23 May 2007 12:28:01 -0500 linas@austin.ibm.com (Linas Vepstas) wrote:
>
>
> Twiddle the copyright notices. Per current guidelines, the use
> of the (C) or (c) in source code is deprecated.
What no UTF-8 '©' symbol? :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Add Marvell mv64x60 udbg putc/getc functions
From: Dale Farnsworth @ 2007-05-24 0:02 UTC (permalink / raw)
To: Olof Johansson; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <20070523232745.GA4611@lixom.net>
On Wed, May 23, 2007 at 06:27:45PM -0500, Olof Johansson wrote:
> On Wed, May 23, 2007 at 03:05:18PM -0700, Dale Farnsworth wrote:
>
> > arch/powerpc/platforms/embedded6xx/prpmc2800.c | 1
> > arch/powerpc/sysdev/Makefile | 3
> > arch/powerpc/sysdev/mv64x60.h | 1
> > arch/powerpc/sysdev/mv64x60_udbg.c | 152 +++++++++++++++
> > 4 files changed, 156 insertions(+), 1 deletion(-)
>
> Is there a reason you're not putting it with the other udbg code, and
> not naming it with the same scheme (kernel/udbg_<xxx>)?
Not really. I just put it with some other mv64x60 code.
> Or maybe we should just move the udbg_16550 code to sysdev instead, it's
> roots are from ppc64 where we didn't have sysdev.
Shrug.
-Dale
^ permalink raw reply
* Re: Porting RapidIO from ppc arch to powerpc arch in support of MPC8641D
From: David Gibson @ 2007-05-24 0:52 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Zhang Wei-r63237
In-Reply-To: <Pine.LNX.4.64.0705230916170.535@localhost.localdomain>
On Wed, May 23, 2007 at 09:21:48AM -0500, Kumar Gala wrote:
> On Wed, 23 May 2007, Zhang Wei-r63237 wrote:
>
> > > So I'm taking the boot/dts/mpc8641_hpcn.dts and producing a new
> > > mpc8641D_umem.dts with the following addition to the soc.
> > >
> > > srio@c0000 {
> > > device_type = "srio";
> > > compatible = "86xx,85xx";
This is quite tangential to the rest of this discussion, but "xx"s in
compatible properties always alarm me if they're the only thing
listed. It's generally best to give a precise model, then a more
general one: the trade-off is that if you're too precise, it's fairly
easy for the driver to workaround by recognizing and binding to
multiple compatible strings, whereas if you're too general you risk
the driver not being able to determine whether it needs a
model-specific workaround or not.
--
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: powerpc_flash_init(), wtf!?
From: David Gibson @ 2007-05-24 0:56 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20070523215735.GA16140@mag.az.mvista.com>
On Wed, May 23, 2007 at 02:57:35PM -0700, Mark A. Greer wrote:
> Sorry, I've lost the thread in my inbox so I can't reply to it directly.
>
> Is something like this what everyone agreed upon?
That's the right approach if your flash device isn't on a bus that's
already being scanned with of_platform_bus_probe().
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] powerpc: Add Marvell mv64x60 udbg putc/getc functions
From: Olof Johansson @ 2007-05-24 1:53 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070524000237.GB11608@xyzzy.farnsworth.org>
On Wed, May 23, 2007 at 05:02:37PM -0700, Dale Farnsworth wrote:
> On Wed, May 23, 2007 at 06:27:45PM -0500, Olof Johansson wrote:
> > On Wed, May 23, 2007 at 03:05:18PM -0700, Dale Farnsworth wrote:
> >
> > > arch/powerpc/platforms/embedded6xx/prpmc2800.c | 1
> > > arch/powerpc/sysdev/Makefile | 3
> > > arch/powerpc/sysdev/mv64x60.h | 1
> > > arch/powerpc/sysdev/mv64x60_udbg.c | 152 +++++++++++++++
> > > 4 files changed, 156 insertions(+), 1 deletion(-)
> >
> > Is there a reason you're not putting it with the other udbg code, and
> > not naming it with the same scheme (kernel/udbg_<xxx>)?
>
> Not really. I just put it with some other mv64x60 code.
>
> > Or maybe we should just move the udbg_16550 code to sysdev instead, it's
> > roots are from ppc64 where we didn't have sysdev.
>
> Shrug.
Yeah, shrug. :) This shouldn't stop this from going in, it just made
me realize that we should probably move the 16550 stuff.
-Olof
^ permalink raw reply
* Don't store a command line in the Holly device tree
From: David Gibson @ 2007-05-24 4:02 UTC (permalink / raw)
To: Josh Boyer; +Cc: Hugh Blemings, Paul Mackerras, linuxppc-dev
Currently, the Holly device tree includes a bootargs property in
/chosen, which gives a commandline. This is somewhat inconvenient,
because it means an alternative default command line can't be given in
the kernel config - the value obtained from the dts via the
bootwrapper will always override CONFIG_CMDLINE.
This patch removes the command line from the dts, and instead puts the
same command line as a default in holly_defconfig.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: working-2.6/arch/powerpc/boot/dts/holly.dts
===================================================================
--- working-2.6.orig/arch/powerpc/boot/dts/holly.dts 2007-05-08 14:58:06.000000000 +1000
+++ working-2.6/arch/powerpc/boot/dts/holly.dts 2007-05-24 13:55:38.000000000 +1000
@@ -193,6 +193,5 @@
chosen {
linux,stdout-path = "/tsi109@c0000000/serial@7808";
- bootargs = "console=ttyS0,115200";
};
};
Index: working-2.6/arch/powerpc/configs/holly_defconfig
===================================================================
--- working-2.6.orig/arch/powerpc/configs/holly_defconfig 2007-05-24 13:55:53.000000000 +1000
+++ working-2.6/arch/powerpc/configs/holly_defconfig 2007-05-24 13:56:16.000000000 +1000
@@ -182,7 +182,8 @@ CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
CONFIG_PROC_DEVICETREE=y
-# CONFIG_CMDLINE_BOOL is not set
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE="console=ttyS0,115200"
# CONFIG_PM is not set
# CONFIG_SECCOMP is not set
# CONFIG_WANT_DEVICE_TREE is not set
--
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
* [PATCH] [POWERPC] suppress modpost warnings for references from the .toc
From: Stephen Rothwell @ 2007-05-24 4:16 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: ppc-dev, Andrew Morton, paulus, LKML
We should do better here by effetively "dereferencing" references to
the .toc (or the .got2) section, but that is much harder.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
scripts/mod/modpost.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 8e5610d..fe5f89b 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -865,9 +865,12 @@ static void warn_sec_mismatch(const char *modname, const char *fromsec,
return;
/* fromsec whitelist - without a valid 'before'
- * powerpc has a GOT table in .got2 section */
+ * powerpc has a GOT table in .got2 section
+ * and also a .toc section */
if (strcmp(fromsec, ".got2") == 0)
return;
+ if (strcmp(fromsec, ".toc") == 0)
+ return;
if (before && after) {
warn("%s(%s+0x%llx): Section mismatch: reference to %s:%s "
--
1.5.1.4
^ permalink raw reply related
* Fix problems with Holly's DT representation of ethernet PHYs
From: David Gibson @ 2007-05-24 4:16 UTC (permalink / raw)
To: Alexandre Bounine, Josh Boyer; +Cc: linuxppc-dev list
This patch fixes some problems with the way the Ethernet PHYs are
represented in the device tree for the Holly board. This means
changes to the dts itself, and to the code with instantiates the
tsi108 ethernet platform devices based on the device tree.
- First, and most importantly, the PHYs are given with an
identical 'reg' property. This reg currently encodes the accessible
register used to initiate mdio interaction with the PHYs, rather than
a meaningful address on the parent bus (mdio in this case), which is
incorrect. Instead we give the address of these registers as 'reg' in
the mdio node itself, and encode the ID of each phy in their 'reg'
propertys. The PHY's unit name addresses are updated to match.
- Second, the PHYs give only "bcm54xx" as a compatible
property. This is unfortunate, because there are many bcm54xx PHY
models, and they have differences which can matter. We add a more
precise compatible string, giving the precise PHY model (bcm5461A in
this case).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: working-2.6/arch/powerpc/boot/dts/holly.dts
===================================================================
--- working-2.6.orig/arch/powerpc/boot/dts/holly.dts 2007-05-24 13:55:38.000000000 +1000
+++ working-2.6/arch/powerpc/boot/dts/holly.dts 2007-05-24 14:11:56.000000000 +1000
@@ -63,19 +63,20 @@
mdio@6000 {
device_type = "mdio";
compatible = "tsi-ethernet";
+ reg = <6000 50>;
+ #address-cells = <1>;
+ #size-cells = <0>;
- PHY1: ethernet-phy@6000 {
+ PHY1: ethernet-phy@1 {
device_type = "ethernet-phy";
- compatible = "bcm54xx";
- reg = <6000 50>;
- phy-id = <1>;
+ compatible = "bcm5461A", "bcm54xx";
+ reg = <1>;
};
- PHY2: ethernet-phy@6400 {
+ PHY2: ethernet-phy@2 {
device_type = "ethernet-phy";
- compatible = "bcm54xx";
- reg = <6000 50>;
- phy-id = <2>;
+ compatible = "bcm5461A", "bcm54xx";
+ reg = <2>;
};
};
Index: working-2.6/arch/powerpc/sysdev/tsi108_dev.c
===================================================================
--- working-2.6.orig/arch/powerpc/sysdev/tsi108_dev.c 2007-05-24 13:55:38.000000000 +1000
+++ working-2.6/arch/powerpc/sysdev/tsi108_dev.c 2007-05-24 14:12:11.000000000 +1000
@@ -75,9 +75,8 @@ static int __init tsi108_eth_of_init(voi
(np = of_find_compatible_node(np, "network", "tsi-ethernet")) != NULL;
i++) {
struct resource r[2];
- struct device_node *phy;
+ struct device_node *phy, *mdio;
hw_info tsi_eth_data;
- const unsigned int *id;
const unsigned int *phy_id;
const void *mac_addr;
const phandle *ph;
@@ -119,13 +118,13 @@ static int __init tsi108_eth_of_init(voi
goto unreg;
}
- id = of_get_property(phy, "reg", NULL);
- phy_id = of_get_property(phy, "phy-id", NULL);
- ret = of_address_to_resource(phy, 0, &res);
- if (ret) {
- of_node_put(phy);
+ phy_id = of_get_property(phy, "reg", NULL);
+
+ mdio = of_get_parent(phy);
+ ret = of_address_to_resource(mdio, 0, &res);
+ of_node_put(mdio);
+ if (ret)
goto unreg;
- }
tsi_eth_data.regs = r[0].start;
tsi_eth_data.phyregs = res.start;
tsi_eth_data.phy = *phy_id;
--
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: Fix problems with Holly's DT representation of ethernet PHYs
From: Kumar Gala @ 2007-05-24 4:22 UTC (permalink / raw)
To: David Gibson; +Cc: Alexandre Bounine, linuxppc-dev list
In-Reply-To: <20070524041625.GD20078@localhost.localdomain>
On May 23, 2007, at 11:16 PM, David Gibson wrote:
> This patch fixes some problems with the way the Ethernet PHYs are
> represented in the device tree for the Holly board. This means
> changes to the dts itself, and to the code with instantiates the
> tsi108 ethernet platform devices based on the device tree.
>
> - First, and most importantly, the PHYs are given with an
> identical 'reg' property. This reg currently encodes the accessible
> register used to initiate mdio interaction with the PHYs, rather than
> a meaningful address on the parent bus (mdio in this case), which is
> incorrect. Instead we give the address of these registers as 'reg' in
> the mdio node itself, and encode the ID of each phy in their 'reg'
> propertys. The PHY's unit name addresses are updated to match.
> - Second, the PHYs give only "bcm54xx" as a compatible
> property. This is unfortunate, because there are many bcm54xx PHY
> models, and they have differences which can matter. We add a more
> precise compatible string, giving the precise PHY model (bcm5461A in
> this case).
Is the compatible really need here? We are able to provide and bind
drivers based on MII_PHYSID1/2. I don't see what putting the
compatible proper gets us.
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>
> Index: working-2.6/arch/powerpc/boot/dts/holly.dts
> ===================================================================
> --- working-2.6.orig/arch/powerpc/boot/dts/holly.dts 2007-05-24
> 13:55:38.000000000 +1000
> +++ working-2.6/arch/powerpc/boot/dts/holly.dts 2007-05-24
> 14:11:56.000000000 +1000
> @@ -63,19 +63,20 @@
> mdio@6000 {
> device_type = "mdio";
> compatible = "tsi-ethernet";
> + reg = <6000 50>;
> + #address-cells = <1>;
> + #size-cells = <0>;
>
> - PHY1: ethernet-phy@6000 {
> + PHY1: ethernet-phy@1 {
> device_type = "ethernet-phy";
> - compatible = "bcm54xx";
> - reg = <6000 50>;
> - phy-id = <1>;
> + compatible = "bcm5461A", "bcm54xx";
> + reg = <1>;
> };
>
> - PHY2: ethernet-phy@6400 {
> + PHY2: ethernet-phy@2 {
> device_type = "ethernet-phy";
> - compatible = "bcm54xx";
> - reg = <6000 50>;
> - phy-id = <2>;
> + compatible = "bcm5461A", "bcm54xx";
> + reg = <2>;
> };
> };
>
> Index: working-2.6/arch/powerpc/sysdev/tsi108_dev.c
> ===================================================================
> --- working-2.6.orig/arch/powerpc/sysdev/tsi108_dev.c 2007-05-24
> 13:55:38.000000000 +1000
> +++ working-2.6/arch/powerpc/sysdev/tsi108_dev.c 2007-05-24
> 14:12:11.000000000 +1000
> @@ -75,9 +75,8 @@ static int __init tsi108_eth_of_init(voi
> (np = of_find_compatible_node(np, "network", "tsi-
> ethernet")) != NULL;
> i++) {
> struct resource r[2];
> - struct device_node *phy;
> + struct device_node *phy, *mdio;
> hw_info tsi_eth_data;
> - const unsigned int *id;
> const unsigned int *phy_id;
> const void *mac_addr;
> const phandle *ph;
> @@ -119,13 +118,13 @@ static int __init tsi108_eth_of_init(voi
> goto unreg;
> }
>
> - id = of_get_property(phy, "reg", NULL);
> - phy_id = of_get_property(phy, "phy-id", NULL);
> - ret = of_address_to_resource(phy, 0, &res);
> - if (ret) {
> - of_node_put(phy);
> + phy_id = of_get_property(phy, "reg", NULL);
> +
> + mdio = of_get_parent(phy);
> + ret = of_address_to_resource(mdio, 0, &res);
> + of_node_put(mdio);
> + if (ret)
> goto unreg;
> - }
> tsi_eth_data.regs = r[0].start;
> tsi_eth_data.phyregs = res.start;
> tsi_eth_data.phy = *phy_id;
>
>
> --
> 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
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] powerpc: Fix ppc32 single step out of syscalls
From: Benjamin Herrenschmidt @ 2007-05-24 5:41 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
The ppc32 kernel didn't properly set/clear the TIF_SINGLESTEP
flag causing return from syscalls to not SIGTRAP, thus executing
one more instruction before stopping again.
This fixes it. The ptrace code is a bit of a mess, and is overdue
of at least a -proper- 32/64 bits split and possibly more cleanups
but this minimum fix should be ok for 2.6.22
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/ptrace.c | 2 ++
1 file changed, 2 insertions(+)
Index: linux-cell/arch/powerpc/kernel/ptrace.c
===================================================================
--- linux-cell.orig/arch/powerpc/kernel/ptrace.c 2007-05-24 15:18:42.000000000 +1000
+++ linux-cell/arch/powerpc/kernel/ptrace.c 2007-05-24 15:19:15.000000000 +1000
@@ -218,6 +218,7 @@ set_single_step(struct task_struct *task
regs->msr |= MSR_SE;
#endif
}
+ set_tsk_thread_flag(task, TIF_SINGLESTEP);
}
static inline void
@@ -233,6 +234,7 @@ clear_single_step(struct task_struct *ta
regs->msr &= ~MSR_SE;
#endif
}
+ clear_tsk_thread_flag(task, TIF_SINGLESTEP);
}
#endif /* CONFIG_PPC32 */
^ permalink raw reply
* Re: Fix problems with Holly's DT representation of ethernet PHYs
From: David Gibson @ 2007-05-24 5:59 UTC (permalink / raw)
To: Kumar Gala; +Cc: Alexandre Bounine, linuxppc-dev list
In-Reply-To: <BB9A8C3A-0BC5-4DF0-9201-2742124A4AF5@kernel.crashing.org>
On Wed, May 23, 2007 at 11:22:34PM -0500, Kumar Gala wrote:
>
> On May 23, 2007, at 11:16 PM, David Gibson wrote:
>
> > This patch fixes some problems with the way the Ethernet PHYs are
> > represented in the device tree for the Holly board. This means
> > changes to the dts itself, and to the code with instantiates the
> > tsi108 ethernet platform devices based on the device tree.
> >
> > - First, and most importantly, the PHYs are given with an
> > identical 'reg' property. This reg currently encodes the accessible
> > register used to initiate mdio interaction with the PHYs, rather than
> > a meaningful address on the parent bus (mdio in this case), which is
> > incorrect. Instead we give the address of these registers as 'reg' in
> > the mdio node itself, and encode the ID of each phy in their 'reg'
> > propertys. The PHY's unit name addresses are updated to match.
> > - Second, the PHYs give only "bcm54xx" as a compatible
> > property. This is unfortunate, because there are many bcm54xx PHY
> > models, and they have differences which can matter. We add a more
> > precise compatible string, giving the precise PHY model (bcm5461A in
> > this case).
>
> Is the compatible really need here? We are able to provide and bind
> drivers based on MII_PHYSID1/2. I don't see what putting the
> compatible proper gets us.
That's a good point (except that having a node without compatible is
kind of odd). At the moment the code which instantiates the platform
device looks at compatible to enable a workaround. But actually that
workaround is holly specific, rather than related to the PHY model,
and so should be encoded differently.
--
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: Porting RapidIO from ppc arch to powerpc arch in support ofMPC8641D
From: Zhang Wei-r63237 @ 2007-05-24 6:48 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev, pterry
In-Reply-To: <200705230105.53013.arnd@arndb.de>
Hi, Arnd,
> >=20
> > Then I should pass np into the various setup routines as=20
> above so that
> > they can find the interrupts, etc.
> >=20
> > Is this the right kind of flavor or have I misunderstood how the dtb
> > stuff is supposed to integrate with the susbsys_initcall stuff.
>=20
> the thing you are missing is probably the of_platform_driver. Your
> driver should have something like
>=20
> static struct of_device_id mpc85xx_rio_ids[] =3D {
> { .compatible =3D "fsl,8641d-rapidio", .data =3D RIO_8641 },
> { .compatible =3D "fsl,8540-rapidio", .data =3D RIO_8540 },
> { },
> };
> static struct of_platform_driver mpc85xx_rio_driver =3D {
> .name =3D "mpc85xx_rio",
> .match_table =3D &mpc85xx_rio_ids,
> .probe =3D mpc85xx_rio_probe,
> };
> static int __init mpc85xx_rio_init(void)
> {
> return of_register_platform_driver(&mpc85xx_rio_driver);
> }
> subsys_initcall(mpc85xx_rio_init);
>=20
> > I'm assuming we are supposed to do away with all the CONFIG_RAPIDIO,
> > CONFIG_MPCxyz etc so that the kernel is driven by the dtb?
>=20
I'm not agree with you.
Of_platform_driver is a good framework. But this RapidIO driver is not a
device driver. It's a _bus_ driver very similar to PCI bus. So,
of_platform_driver is not fit here.
Thanks!
Wei.
^ permalink raw reply
* RE: Porting RapidIO from ppc arch to powerpc arch in support ofMPC8641D
From: Zhang Wei-r63237 @ 2007-05-24 7:31 UTC (permalink / raw)
To: pterry, galak; +Cc: linuxppc-dev
In-Reply-To: <1179934657.11247.14.camel@pterry-fc6.micromemory.com>
> > > interrupts =3D <30 1 31 1 32 1 35 1 36 1=20
> 37 1 38 1>;
> > > > };
> > > >
> > > Do you really use all of this interrupts? In my test,=20
> three <32 2 35 2
> > > 36 2> are okay, and the sense is 2.
> >=20
> > I think we need to list all the interrupts possible from=20
> RIO, not just the
> > ones the driver happens to use.
> Sorry about the senses, again I just threw that in the email as a
> strawman to kick off discussion (which now seems moot as Wei has the
> patches (yippee)). The second set of interrupts 37 and 38 are for the
> second message unit which I want to use (see above). 30 is for
> port-write/error which I will be using to get interrupts from my
> switches for topology changes. 31 is the out doorbell done which the
> driver doesn't use cos of the synchronous nature of the out doorbell I
> suppose.
About this interrupts, I suggest to put the BELL, Tx, Rx to the front of
others. These three is already be used in ppc rio codes.
For example:
/* bell_irq tx_irq rx_irq */
interrupts =3D <32 2 35 2 36 2>;
Thanks!
Wei.
^ 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