Re: Anyone have a PrPmc 280/2800 handy?
On Sat, Jan 19, 2013 at 08:59:18PM -0500, Paul Gortmaker wrote: > On Thu, Jan 17, 2013 at 5:33 PM, Mark A. Greer wrote: > > Hello. > > > > I want to make some fixups to the marvell hostbridge and > > mpsc code and would like to test them on a PrPmc280/2800. > > The problem is, I don't have one anymore. > > Hi Mark, Hi Paul. > Is there another platform that uses mpsc that can be used for > testing? I ask because I did spend a lot of time with PrPMC-280 > and motload/powerboot; some standalone, some on ATCA-F101. > And with that hindsight, I can't help thinking that the right thing > to do some eight years later is to simply consider removing the > support for these old platforms. Would that make your validation > easier? If so, then I'd recommend it. This is of course, just my opinion. Hmm, yeah, the c2k platform uses that bridge too. I'll see if I can find someone with one of those handy. Since nobody seems to have a prmpc280/2800 anymore, it does seem prudent to remove it. It would make validation easier for me in that its one less platform to worry about breaking. If I don't hear anything in the next few days, I'll make a patches to remove prpmc280/2800 support. Thanks, Mark -- ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Anyone have a PrPmc 280/2800 handy?
Hello. I want to make some fixups to the marvell hostbridge and mpsc code and would like to test them on a PrPmc280/2800. The problem is, I don't have one anymore. If you have one handy and don't mind running a quick boot test for me, please let me know. Thanks, Mark -- ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Reminder: removal of arch/ppc
On Thu, Jan 31, 2008 at 09:33:09PM -0600, Kumar Gala wrote: > > On Jan 31, 2008, at 4:54 PM, Mark A. Greer wrote: > > >On Fri, Jan 25, 2008 at 10:55:25AM -0600, Kumar Gala wrote: > >>Just a reminder that the plan is to remove arch/ppc this summer (June > >>2008). The following boards still existing over in arch/ppc. Some > >>of > >>them have been ported over to arch/powerpc. If you care about one of > >>these boards and its not ported speak up (it helps if you have access > >>to the board). Also, if you know a given board is free to die of > >>bitrot let us know so we know not to worry about it: > > > >I guess I'm just not a nice guy but I say let them die. No need > >to worry. The code really isn't going anywhere -- git-checkout > >v2.6. and its back. > > > >/me's $0.02. > > this is where I poke you about the sandpoint port ;) Heh, I know, I know. jdl was asking me about it a few days ago too. I haven't forgotten, it just never makes it to the top of my stack. RSN tho... :) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Reminder: removal of arch/ppc
On Fri, Jan 25, 2008 at 10:55:25AM -0600, Kumar Gala wrote: > Just a reminder that the plan is to remove arch/ppc this summer (June > 2008). The following boards still existing over in arch/ppc. Some of > them have been ported over to arch/powerpc. If you care about one of > these boards and its not ported speak up (it helps if you have access > to the board). Also, if you know a given board is free to die of > bitrot let us know so we know not to worry about it: I guess I'm just not a nice guy but I say let them die. No need to worry. The code really isn't going anywhere -- git-checkout v2.6. and its back. /me's $0.02. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] powerpc: Katana750i - Add DTS file
On Thu, Jan 17, 2008 at 12:06:34PM +1100, David Gibson wrote:
> On Wed, Jan 16, 2008 at 01:48:09PM -0700, Mark A. Greer wrote:
> > On Wed, Jan 16, 2008 at 11:22:28AM +1100, David Gibson wrote:
> > > On Tue, Jan 15, 2008 at 12:08:06PM -0700, Mark A. Greer wrote:
> > > > On Tue, Jan 15, 2008 at 10:34:06AM +1100, David Gibson wrote:
> > > > > On Mon, Jan 14, 2008 at 03:59:26PM -0700, Mark A. Greer wrote:
> > > > > > From: Mark A. Greer <[EMAIL PROTECTED]>
> > > >
> > > > Hi David. Thanks for the review.
> > > >
> > > > > > Add DTS file for the Emerson Katana 750i & 752i platforms.
> > > > >
> > > > > [snip]
> > > > > > +/dts-v1/;
> > > > > > +
> > > > > > +/ {
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <1>;
> > > > > > + model = "Katana-75xi"; /* Default */
> > > > > > + compatible = "emerson,katana-750i";
> > > > > > + coherency-off;
> > > > >
> > > > > Where is this flag used from?
> > > >
> > > > Its used in the bootwrapper if & when you use the mv64x60 code to setup
> > > > some of the windows to the I/O ctlrs. This port does use that code
> > > > (because firmware doesn't do it properly) so I need the flag.
> > >
> > > Hrm.. ok. I'm just wondering if a new flag is really the right
> > > approach for this, or whether you should be basing the setup off the
> > > compatible property, either for the board or for the main bridge.
> >
> > I'd prefer to keep the flag. Otherwise, the bootwrapper will need a
> > table to look up the compatible field to see if coherency is supposed
> > to be on or off. We'd have to add an entry to that table for any
> > compatible that need coherency off, etc. A flag seems cleaner.
>
> Hrm. Except that you already have such a table in the cuboot file,
> adding another flag to that wouldn't be hard.
>
> What piece of hardware is it that actually determines whether
> coherency works or not? The CPU? The bridge?
The bridge + the platform. There's a hw erratum that some boards have
worked around and other haven't.
Spoze I can just code it in the cuboot file as you say.
I'll have to remove the sanity check in the kernel that ensures
that coherency-off & CONFIG_NOT_COHERENT_CACHE match.
> [snip]
> > > > > > + CUNIT: [EMAIL PROTECTED] {
> > > > >
> > > > > What is this device? It needs some sort of "compatible" value.
> > > >
> > > > Does it? Its a separate block of regs but its only used in the mpsc
> > > > node--its never looked up on its own by kernel code. Do all nodes need
> > > > "compatible" even when it'll never be used? (Just want to know.)
> > >
> > > Hrm.. if it's really just extra mpsc registers, should it be a
> > > seperate device, or just another range in the mpsc's "reg" property?
> >
> > Okay, putting into the reg property makes sense. Its values will be
> > put into both [EMAIL PROTECTED] 'reg' properties since its share. That
> > doesn't
> > matter, correct?
>
> Ah, sorry, I forgot there were multiple mpscs. Their reg properties
> certainly shouldn't overlap, so you will need a separate node.
Okay.
> However, you could combine your several nodes with MPSC common
> registers into a single "mpsc-common" (or something) block. That
> would also reduce the number of phandles you need in the mpsc nodes,
> too.
True, that will help.
> Or possibly this should be arranged as for the multiethernet.
Do you mean putting sdma/brg/... as subnodes of the mpsc node?
I remember debating this way back when. IIRC, leaving them out seemed
like the right thing to do (tm). If you think that's better, I can do
that.
> > Also, would you mind letting it go thru as it is now and I'll make a
> > separate patch to change this dts, the prpmc2800.dts, and related code
> > afterwards?
>
> Well, that's not really up to me.
Yeah, but paulus is looing to you to monitor bootwrapper stuff so... :)
> [snip]
> > > Yes :(. I've looked at this before, though obviously I never got to
> > > figuring out what to do about it.
> > >
> > > > IMHO we need a way to change the default cmdline in the field so
> > > > sysadmins can change it p
Re: [PATCH 1/4] powerpc: mv64x60 - Use early_* PCI accessors for hotswap reg
On Thu, Jan 17, 2008 at 09:48:59AM +1100, Benjamin Herrenschmidt wrote: > > On Mon, 2008-01-14 at 15:51 -0700, Mark A. Greer wrote: > > From: Mark A. Greer <[EMAIL PROTECTED]> > > > > The mv64x60 Hotswap register is on the first hose of the mv64x60 > > hostbridge. To access it, manually find the hose structure and > > use the early_* PCI accessor routines because the hostbridge is > > normally hidden. > > Can't we unhide the NB instead ? Hi Ben. Possibly but it may cause issues since many hostbridge have BARs that don't comply with the PCI spec which may get hosed when scanning the PCI bus. Maybe fixups/quirks/whatever will help but I'm not sure that's any cleaner. TBH, I'm not familiar enough with the PCI subsystem to answer this intelligently. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4 v2] powerpc: Katana750i - Add platform support
On Thu, Jan 17, 2008 at 10:27:02AM +1100, Stephen Rothwell wrote:
> Hi Mark,
>
> On Wed, 16 Jan 2008 15:12:10 -0700 "Mark A. Greer" <[EMAIL PROTECTED]> wrote:
> >
> > +static void __init katana750i_setup_arch(void)
> > +{
> > + struct device_node *np;
> > + phys_addr_t paddr;
> > + const unsigned int *reg;
> > +
> > + np = of_find_compatible_node(NULL, NULL, "katana750i,cpld");
> > + if (!np)
> > + printk(KERN_WARNING "No CPLD DT node; functionality reduced\n");
> > + else {
> > + reg = of_get_property(np, "reg", NULL);
> > + if (!reg)
> > + printk(KERN_WARNING "No CPLD reg property; "
> > + "functionality reduced\n");
> > + else {
> > + paddr = of_translate_address(np, reg);
> > + of_node_put(np);
> > + cpld_base = ioremap(paddr, reg[1]);
> > + }
> > + }
>
> You need an of_node_put(np) for the !reg case above. Maybe you should
> just put it after the else clause instead of in it.
Erg, yes...duh.
Thanks again, Stephen.
Mark
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/4 v2] powerpc: Katana750i - Add platform support
From: Mark A. Greer <[EMAIL PROTECTED]>
Add support for the Emerson Katana 750i & 752i platforms.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
This patch should address all of Stephen's comments.
I also did some cleanup that I missed the first time through.
arch/powerpc/boot/Makefile |3
arch/powerpc/boot/cuboot-katana750i.c | 248 ++
arch/powerpc/configs/katana750i_defconfig | 1315 ++
arch/powerpc/platforms/embedded6xx/Kconfig | 10
arch/powerpc/platforms/embedded6xx/Makefile |1
arch/powerpc/platforms/embedded6xx/katana750i.c | 312 +++
6 files changed, 1888 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index d1e625c..b04ecc0 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -62,7 +62,7 @@ src-plat := of.c cuboot-52xx.c cuboot-83xx.c cuboot-85xx.c
holly.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c cuboot-bamboo.c
\
fixed-head.S ep88xc.c cuboot-hpc2.c ep405.c cuboot-taishan.c \
- cuboot-katmai.c cuboot-rainier.c
+ cuboot-katmai.c cuboot-rainier.c cuboot-katana750i.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -206,6 +206,7 @@ image-$(CONFIG_RAINIER) +=
cuImage.rainier
image-$(CONFIG_WALNUT) += treeImage.walnut
image-$(CONFIG_TAISHAN)+= cuImage.taishan
image-$(CONFIG_KATMAI) += cuImage.katmai
+image-$(CONFIG_PPC_KATANA750I) += cuImage.katana750i
endif
# For 32-bit powermacs, build the COFF and miboot images
diff --git a/arch/powerpc/boot/cuboot-katana750i.c
b/arch/powerpc/boot/cuboot-katana750i.c
new file mode 100644
index 000..996d65f
--- /dev/null
+++ b/arch/powerpc/boot/cuboot-katana750i.c
@@ -0,0 +1,248 @@
+/*
+ * Emerson Katana-750i/752i
+ *
+ * Author: Mark A. Greer <[EMAIL PROTECTED]>
+ *
+ * 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 "stdio.h"
+#include "io.h"
+#include "ops.h"
+#include "cuboot.h"
+#include "ppcboot.h"
+#include "mv64x60.h"
+
+static u8 *bridge_base;
+static u8 *cpld_base;
+static bd_t bd;
+
+#define KATANA750I_CPLD_RST_CMD0x1000
+#define KATANA750I_CPLD_RST_CMD_HR 0x01
+
+#define KATANA750I_CPLD_PRODUCT_ID 0x4000
+#define KATANA750I_PRODUCT_ID_750I 0x02
+#define KATANA750I_PRODUCT_ID_752I 0x04
+
+#define KATANA750I_CPLD_BD_CFG_0 0x9000
+#define KATANA750I_CPLD_BD_CFG_0_SYSCLK_MASK 0xc0
+#define KATANA750I_CPLD_BD_CFG_0_SYSCLK_2000x00
+#define KATANA750I_CPLD_BD_CFG_0_SYSCLK_1660x80
+#define KATANA750I_CPLD_BD_CFG_0_SYSCLK_1330xc0
+#define KATANA750I_CPLD_BD_CFG_0_SYSCLK_1000x40
+
+#define BOARD_MODEL_MAX32
+
+typedef enum {
+ BOARD_TYPE_750I,
+ BOARD_TYPE_752I,
+} katana750i_board_type;
+
+struct katana750i_board_info {
+ charcpld_prod_id;
+ char*model;
+ char*bridge_type;
+};
+
+static struct katana750i_board_info katana750i_board_info[] = {
+ [BOARD_TYPE_750I] = {
+ .cpld_prod_id = KATANA750I_PRODUCT_ID_750I,
+ .model = "Katana-750i",
+ .bridge_type= "mv64360",
+ },
+ [BOARD_TYPE_752I] = {
+ .cpld_prod_id = KATANA750I_PRODUCT_ID_752I,
+ .model = "Katana-752i",
+ .bridge_type= "mv64460",
+ },
+};
+
+static struct katana750i_board_info *katana750i_get_bip(void)
+{
+ struct katana750i_board_info *bip;
+ int i;
+ u8 id;
+
+ id = in_8(cpld_base + KATANA750I_CPLD_PRODUCT_ID);
+
+ for (i = 0, bip = katana750i_board_info;
+ i < ARRAY_SIZE(katana750i_board_info); i++, bip++)
+ if (bip->cpld_prod_id == id)
+ return bip;
+
+ return NULL;
+}
+
+static void katana750i_bridge_setup(void)
+{
+ u32 i, v[12], enables, acc_bits;
+ u32 pci_base_hi, pci_base_lo, size, buf[2];
+ unsigned long cpu_base;
+ int rc;
+ void *devp;
+ u8 *bridge_pbase, is_coherent;
+ struct mv64x60_cpu2pci_win *tbl;
+
+ bridge_pbase = mv64x60_get_bridge_pbase();
+ is_coherent = mv64x60_is_coherent();
+
+ if (is_coherent)
+ acc_bits = MV64x60_PCI_ACC_CNTL_SNOOP_WB
+ | MV64x60_PCI_ACC_CNTL_SWAP_NONE
+
[PATCH 3/4 v2] powerpc: Katana750i - Add DTS file
From: Mark A. Greer <[EMAIL PROTECTED]>
Add DTS file for the Emerson Katana 750i & 752i platforms.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
This patch should address most of David's comments.
Some notes:
- Even though there are still several virtual-reg's remaining, all
are used by the bootwrapper.
- I'll make a separate patch to get rid fo the cunit & mpscrouting nodes.
- I left /chosen/bootargs since its nice to have the default cmdline
printed by the bootwrapper and then have the opportunity to edit it.
arch/powerpc/boot/dts/katana750i.dts | 360 +
1 file changed, 360 insertions(+)
diff --git a/arch/powerpc/boot/dts/katana750i.dts
b/arch/powerpc/boot/dts/katana750i.dts
new file mode 100644
index 000..a4806da
--- /dev/null
+++ b/arch/powerpc/boot/dts/katana750i.dts
@@ -0,0 +1,360 @@
+/* Device Tree Source for Emerson Katana 750i/752i
+ *
+ * Author: Mark A. Greer <[EMAIL PROTECTED]>
+ *
+ * 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.
+ *
+ * Property values that are labeled as "Default" will be updated by bootwrapper
+ * if it can determine the exact PrPMC type.
+ */
+
+/dts-v1/;
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ model = "Katana-75xi"; /* Default */
+ compatible = "emerson,katana-750i";
+ coherency-off;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,750 {
+ device_type = "cpu";
+ reg = <0>;
+ clock-frequency = <7>; /* Default */
+ bus-frequency = <1>;/* Default */
+ timebase-frequency = <>;/* Default */
+ i-cache-line-size = <0x20>;
+ d-cache-line-size = <0x20>;
+ i-cache-size = <0x8000>;
+ d-cache-size = <0x8000>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x0400>; /* Default (64MB) */
+ };
+
+ [EMAIL PROTECTED] { /* Marvell Discovery */
+ #address-cells = <1>;
+ #size-cells = <1>;
+ model = "mv64360"; /* Default */
+ compatible = "marvell,mv64360";
+ clock-frequency = <1>;
+ hs_reg_valid;
+ reg = <0xf810 0x0001>;
+ virtual-reg = <0xf810>;
+ ranges = <0xb000 0xb000 0x0400 /* PCI 1 I/O Space */
+ 0x8000 0x8000 0x3000 /* PCI 1 MEM Space */
+ 0xe800 0xe800 0x1000 /* User FLASH */
+ 0x 0xf810 0x0001 /* Bridge's regs */
+ 0xf808 0xf808 0x0001 /* PCI 0 I/O Space */
+ 0xf809 0xf809 0x0001 /* PCI 0 MEM Space */
+ 0xf820 0xf820 0x0020 /* CPLD & HSL Regs */
+ 0xf830 0xf830 0x0004>;/* Integrated SRAM*/
+
+ [EMAIL PROTECTED] {
+ compatible = "katana750i,cpld";
+ reg = <0xf820 0x0020>;
+ virtual-reg = <0xf820>;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ bank-width = <4>;
+ device-width = <2>;
+ reg = <0xe800 0x0400>;
+ [EMAIL PROTECTED] {
+ label = "Monitor";
+ reg = <0x 0x0010>;
+ };
+ [EMAIL PROTECTED] {
+ label = "Primary Kernel";
+ reg = <0x0010 0x0018>;
+ };
+ [EMAIL PROTECTED] {
+ label = "Primary Filesystem";
+ reg = <0x0028 0x01e0>;
+ };
+ [EMAIL PROTECTED] {
+ label = "Secondary Kernel";
+ reg = <0x02080
[PATCH 1/4 v2] powerpc: mv64x60 - Use early_* PCI accessors for hotswap reg
From: Mark A. Greer <[EMAIL PROTECTED]>
The mv64x60 Hotswap register is on the first hose of the mv64x60
hostbridge. To access it, manually find the hose structure and
use the early_* PCI accessor routines because the hostbridge is
normally hidden.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
This patch should address all of Stephen's comments.
arch/powerpc/sysdev/mv64x60.h |4 ++
arch/powerpc/sysdev/mv64x60_pci.c | 46 +---
2 files changed, 39 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/sysdev/mv64x60.h b/arch/powerpc/sysdev/mv64x60.h
index 4f618fa..51c4293 100644
--- a/arch/powerpc/sysdev/mv64x60.h
+++ b/arch/powerpc/sysdev/mv64x60.h
@@ -2,11 +2,15 @@
#define __MV64X60_H__
#include
+#include
+
+#include
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);
+extern struct pci_controller *mv64x60_find_hose(u32 idx);
#endif /* __MV64X60_H__ */
diff --git a/arch/powerpc/sysdev/mv64x60_pci.c
b/arch/powerpc/sysdev/mv64x60_pci.c
index 1456015..1e6f186 100644
--- a/arch/powerpc/sysdev/mv64x60_pci.c
+++ b/arch/powerpc/sysdev/mv64x60_pci.c
@@ -13,10 +13,12 @@
#include
#include
#include
+#include
-#include
#include
+#include
+
#define PCI_HEADER_TYPE_INVALID0x7f/* Invalid PCI header
type */
#ifdef CONFIG_SYSFS
@@ -24,11 +26,31 @@
#define MV64X60_VAL_LEN_MAX11
#define MV64X60_PCICFG_CPCI_HOTSWAP0x68
+struct pci_controller *mv64x60_find_hose(u32 idx)
+{
+ struct device_node *phb;
+ struct pci_controller *hose;
+ const u32 *prop;
+ int len;
+
+ for_each_compatible_node(phb, "pci", "marvell,mv64360-pci") {
+ prop = of_get_property(phb, "cell-index", &len);
+ if (prop && (len == sizeof(prop)) && (*prop == idx)) {
+ hose = pci_find_hose_for_OF_device(phb);
+ of_node_put(phb);
+ return hose;
+ }
+ }
+
+ return NULL;
+}
+
+/* cPCI Hotswap register only supported on PCI 0 interface */
static ssize_t mv64x60_hs_reg_read(struct kobject *kobj,
struct bin_attribute *attr, char *buf,
loff_t off, size_t count)
{
- struct pci_dev *phb;
+ struct pci_controller *hose;
u32 v;
if (off > 0)
@@ -36,11 +58,12 @@ static ssize_t mv64x60_hs_reg_read(struct kobject *kobj,
if (count < MV64X60_VAL_LEN_MAX)
return -EINVAL;
- phb = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
- if (!phb)
+ hose = mv64x60_find_hose(0);
+ if (!hose)
return -ENODEV;
- pci_read_config_dword(phb, MV64X60_PCICFG_CPCI_HOTSWAP, &v);
- pci_dev_put(phb);
+
+ early_read_config_dword(hose, 0, PCI_DEVFN(0, 0),
+ MV64X60_PCICFG_CPCI_HOTSWAP, &v);
return sprintf(buf, "0x%08x\n", v);
}
@@ -49,7 +72,7 @@ static ssize_t mv64x60_hs_reg_write(struct kobject *kobj,
struct bin_attribute *attr, char *buf,
loff_t off, size_t count)
{
- struct pci_dev *phb;
+ struct pci_controller *hose;
u32 v;
if (off > 0)
@@ -60,11 +83,12 @@ static ssize_t mv64x60_hs_reg_write(struct kobject *kobj,
if (sscanf(buf, "%i", &v) != 1)
return -EINVAL;
- phb = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
- if (!phb)
+ hose = mv64x60_find_hose(0);
+ if (!hose)
return -ENODEV;
- pci_write_config_dword(phb, MV64X60_PCICFG_CPCI_HOTSWAP, v);
- pci_dev_put(phb);
+
+ early_write_config_dword(hose, 0, PCI_DEVFN(0, 0),
+ MV64X60_PCICFG_CPCI_HOTSWAP, v);
return count;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] powerpc: Katana750i - Add DTS file
On Wed, Jan 16, 2008 at 11:22:28AM +1100, David Gibson wrote:
> On Tue, Jan 15, 2008 at 12:08:06PM -0700, Mark A. Greer wrote:
> > On Tue, Jan 15, 2008 at 10:34:06AM +1100, David Gibson wrote:
> > > On Mon, Jan 14, 2008 at 03:59:26PM -0700, Mark A. Greer wrote:
> > > > From: Mark A. Greer <[EMAIL PROTECTED]>
> >
> > Hi David. Thanks for the review.
> >
> > > > Add DTS file for the Emerson Katana 750i & 752i platforms.
> > >
> > > [snip]
> > > > +/dts-v1/;
> > > > +
> > > > +/ {
> > > > + #address-cells = <1>;
> > > > + #size-cells = <1>;
> > > > + model = "Katana-75xi"; /* Default */
> > > > + compatible = "emerson,katana-750i";
> > > > + coherency-off;
> > >
> > > Where is this flag used from?
> >
> > Its used in the bootwrapper if & when you use the mv64x60 code to setup
> > some of the windows to the I/O ctlrs. This port does use that code
> > (because firmware doesn't do it properly) so I need the flag.
>
> Hrm.. ok. I'm just wondering if a new flag is really the right
> approach for this, or whether you should be basing the setup off the
> compatible property, either for the board or for the main bridge.
I'd prefer to keep the flag. Otherwise, the bootwrapper will need a
table to look up the compatible field to see if coherency is supposed
to be on or off. We'd have to add an entry to that table for any
compatible that need coherency off, etc. A flag seems cleaner.
> > > > + [EMAIL PROTECTED] {
> > > > + #address-cells = <1>;
> > > > + #size-cells = <1>;
> > > > + compatible = "cfi-flash";
> > > > + bank-width = <4>;
> > > > + device-width = <2>;
> > > > + reg = <0xe800 0x0400>;
> > > > + [EMAIL PROTECTED] {
> > > > + label = "Monitor";
> > >
> > > If you're using the "label" property, it would be normal to name the
> > > nodes simply "[EMAIL PROTECTED]".
> >
> > I'm using the partition names that were used in the equivalent code
> > under arch/ppc. I'm trying to keep things looking the same as they used
> > to as much as possible. Besides, I don't see any others doing it that
> > way.
>
> My point is that the partition code uses either "label" (if present)
> or the node name for the partition name. If label properties are
> present, the node name is redundant information, so it seems more
> sensible to leave something generic there.
Ah, okay. I'll do:
[EMAIL PROTECTED] {
label = "Monitor";
reg = <0x 0x0010>;
}
[EMAIL PROTECTED] {
label = "Primary Kernel";
reg = <0x0010 0x0018>;
}
...
> [snip]
> > > > + CUNIT: [EMAIL PROTECTED] {
> > >
> > > What is this device? It needs some sort of "compatible" value.
> >
> > Does it? Its a separate block of regs but its only used in the mpsc
> > node--its never looked up on its own by kernel code. Do all nodes need
> > "compatible" even when it'll never be used? (Just want to know.)
>
> Hrm.. if it's really just extra mpsc registers, should it be a
> seperate device, or just another range in the mpsc's "reg" property?
Okay, putting into the reg property makes sense. Its values will be
put into both [EMAIL PROTECTED] 'reg' properties since its share. That doesn't
matter, correct?
Also, would you mind letting it go thru as it is now and I'll make a
separate patch to change this dts, the prpmc2800.dts, and related code
afterwards?
> [snip]
> > > > + [EMAIL PROTECTED] {
> > > > + compatible = "marvell,mv64360-mpp";
> > > > + reg = <0xf000 0x10>;
> > > > + };
> > > > +
> > > > + [EMAIL PROTECTED] {
> > > > + compatible = "marvell,mv64360-gpp";
> > > > + reg = <0xf100 0x20>;
> > > > + };
> > >
> > > What are these two devices?
> &
Re: [PATCH 3/4] powerpc: Katana750i - Add DTS file
On Tue, Jan 15, 2008 at 10:34:06AM +1100, David Gibson wrote:
> On Mon, Jan 14, 2008 at 03:59:26PM -0700, Mark A. Greer wrote:
> > From: Mark A. Greer <[EMAIL PROTECTED]>
Hi David. Thanks for the review.
> > Add DTS file for the Emerson Katana 750i & 752i platforms.
>
> [snip]
> > +/dts-v1/;
> > +
> > +/ {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + model = "Katana-75xi"; /* Default */
> > + compatible = "emerson,katana-750i";
> > + coherency-off;
>
> Where is this flag used from?
Its used in the bootwrapper if & when you use the mv64x60 code to setup
some of the windows to the I/O ctlrs. This port does use that code
(because firmware doesn't do it properly) so I need the flag.
> > + [EMAIL PROTECTED] { /* Marvell Discovery */
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + model = "mv64360"; /* Default */
> > + compatible = "marvell,mv64360";
> > + clock-frequency = <1>;
> > + hs_reg_valid;
> > + reg = <0xf810 0x0001>;
> > + virtual-reg = <0xf810>;
>
> You seem to have virtual-reg properties on a *lot* of nodes, are they
> really necessary?
Actually, not all of them for this board. I copied them from prpmc2800
which does need all the ones that are there. I'l remove the ones that
aren't used.
> virtual-reg should be used *only* for things which
> you need to access very early in the bootwrapper. Usually that's only
> the serial port for the console. Come to that, the CPU is a 750 which
> has a real mode, so it seems dubious that you would need any
> virtual-reg values at all.
Well, this came from a discussion about a year ago when we agreed that
this is how it should be done. Just because MSR[IR,DR] can be cleared
doesn't mean that they are cleared when the firmware jumps to the
bootwraper (for all possible firmwares that are out there).
To be able to eliminate virtual-reg, we'd have to add "mmu_off" code to
the bootwrapper which isn't hard but its already in the kernel (for
32-bit anyway). So why duplicate?
I'm not that attached to virtual-reg. In fact, I'd be happy to get rid
of it but only if we can be sure it doesn't cause more mess down the
road.
> [snip]
> > + [EMAIL PROTECTED] {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + compatible = "cfi-flash";
> > + bank-width = <4>;
> > + device-width = <2>;
> > + reg = <0xe800 0x0400>;
> > + [EMAIL PROTECTED] {
> > + label = "Monitor";
>
> If you're using the "label" property, it would be normal to name the
> nodes simply "[EMAIL PROTECTED]".
I'm using the partition names that were used in the equivalent code
under arch/ppc. I'm trying to keep things looking the same as they used
to as much as possible. Besides, I don't see any others doing it that
way.
> > + mdio {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + device_type = "mdio";
>
> This device_type value should not be here.
Yep. Will fix.
> > + [EMAIL PROTECTED] {
>
> This needs some sort of "compatible" value.
Okay.
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0x2000 0x2000>;
> > + [EMAIL PROTECTED] {
>
> [snip]
> > + CUNIT: [EMAIL PROTECTED] {
>
> What is this device? It needs some sort of "compatible" value.
Does it? Its a separate block of regs but its only used in the mpsc
node--its never looked up on its own by kernel code. Do all nodes need
"compatible" even when it'll never be used? (Just want to know.)
> > + reg = <0xf200 0x200>;
> > + };
> > +
> > + MPSCROUTING: [EMAIL PROTECTED] {
>
> Ditto.
Ditto.
> > + reg = <0xb400 0xc>;
> > + };
> > +
> > + MPSCINTR: [EMAIL PROTECTED] {
>
> Ditto.
Ditto.
> > + reg = <0xb800 0x100>;
> > + virtual-reg = <0xf810b800>;
> > + };
>
> [snip]
> > +
Re: [PATCH 4/4] powerpc: Katana750i - Add platform support
On Tue, Jan 15, 2008 at 10:33:46AM +1100, Stephen Rothwell wrote:
> Hi Mark,
>
> On Mon, 14 Jan 2008 16:00:57 -0700 "Mark A. Greer" <[EMAIL PROTECTED]> wrote:
> >
> > +++ b/arch/powerpc/platforms/embedded6xx/katana750i.c
> > @@ -0,0 +1,314 @@
> > +/*
> > + * Board setup routines for the Emerson Katana-750i/752i
> > + *
> > + * Author: Mark A. Greer <[EMAIL PROTECTED]>
> > + *
> > + * Based on code prpmc2800.c by Dale Farnsworth <[EMAIL PROTECTED]>
> > + * and original katana port by Tim Montgomery <[EMAIL PROTECTED]>
> > + *
> > + * 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; either version 2 of the License, or (at your
> > + * option) any later version.
>
> A Copyright notice would be nice.
Okay.
> > +static void __init katana750i_setup_arch(void)
> > +{
> > + struct device_node *np;
> > + phys_addr_t paddr;
> > + const unsigned int *reg;
> > +
> > + /*
> > +* ioremap mpp and gpp registers in case they are later
> > +* needed by katana750i_reset_board().
> > +*/
> > + np = of_find_compatible_node(NULL, NULL, "marvell,mv64360-mpp");
> > + reg = of_get_property(np, "reg", NULL);
>
> What happens if np == NULL?
It'll explode. :D I'll fix.
> > + paddr = of_translate_address(np, reg);
> > + of_node_put(np);
> > + mv64x60_mpp_reg_base = ioremap(paddr, reg[1]);
> > +
> > + np = of_find_compatible_node(NULL, NULL, "marvell,mv64360-gpp");
> > + reg = of_get_property(np, "reg", NULL);
>
> Ditto.
>
> > + paddr = of_translate_address(np, reg);
> > + of_node_put(np);
> > + mv64x60_gpp_reg_base = ioremap(paddr, reg[1]);
> > +
> > +#ifdef CONFIG_PCI
> > + mv64x60_pci_init();
> > +#endif
>
> Maybe there should be a stub of mv64x60_pci_init for the non PCI case -
> that would save the ifdefs in C code.
Good idea.
> > + np = of_find_compatible_node(NULL, NULL, "katana750i,cpld");
> > + reg = of_get_property(np, "reg", NULL);
>
> What if np == NULL?
Thanks again, Stephen.
Mark
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] powerpc: mv64x60 - Use early_* PCI accessors for hotswap reg
On Tue, Jan 15, 2008 at 10:21:29AM +1100, Stephen Rothwell wrote: > Hi Mark, > > On Mon, 14 Jan 2008 15:51:50 -0700 "Mark A. Greer" <[EMAIL PROTECTED]> wrote: > > > > +++ b/arch/powerpc/sysdev/mv64x60.h > > @@ -3,10 +3,32 @@ > > > > #include > > > > +#include > > You probably meant to include linux/of.h here Umm, apparently... :) Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] powerpc: mv64x60 - Use early_* PCI accessors for hotswap reg
On Tue, Jan 15, 2008 at 10:19:36AM +1100, Stephen Rothwell wrote:
> Hi Mark,
Hi Stephen. Thanks for taking the time to review these patches.
> On Mon, 14 Jan 2008 15:51:50 -0700 "Mark A. Greer" <[EMAIL PROTECTED]> wrote:
> >
> > +static inline struct pci_controller *mv64x60_find_hose(u32 idx)
> > +{
> > + struct device_node *phb;
> > + struct pci_controller *hose;
> > + const u32 *prop;
> > + int len;
> > +
> > + for_each_compatible_node(phb, "pci", "marvell,mv64360-pci") {
> > + prop = of_get_property(phb, "cell-index", &len);
> > + if (prop && (len == sizeof(prop)) && (*prop == idx)) {
> > + hose = pci_find_hose_for_OF_device(phb);
> > + of_node_put(phb);
> > + return hose;
> > + }
> > + }
> > +
> > + return NULL;
> > +}
>
> I would think that this is way to big to inline ...
Yeah, I suppose. I'm not sure why I made it an inline, TBH. I'll make
it a "real" routine.
Mark
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/4] powerpc: Katana750i - Add platform support
From: Mark A. Greer <[EMAIL PROTECTED]>
Add support for the Emerson Katana 750i & 752i platforms.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
This patch depends on 2 other patch series. This is the list of all the
patches in the two series (not all of them are actually required):
http://patchwork.ozlabs.org/linuxppc/patch?id=14397
http://patchwork.ozlabs.org/linuxppc/patch?id=14396
http://patchwork.ozlabs.org/linuxppc/patch?id=14631
http://patchwork.ozlabs.org/linuxppc/patch?id=14632
http://patchwork.ozlabs.org/linuxppc/patch?id=14633
http://patchwork.ozlabs.org/linuxppc/patch?id=15007
http://patchwork.ozlabs.org/linuxppc/patch?id=15453
http://patchwork.ozlabs.org/linuxppc/patch?id=15454
http://patchwork.ozlabs.org/linuxppc/patch?id=15455
http://patchwork.ozlabs.org/linuxppc/patch?id=15456
http://patchwork.ozlabs.org/linuxppc/patch?id=15457
http://patchwork.ozlabs.org/linuxppc/patch?id=15458
http://patchwork.ozlabs.org/linuxppc/patch?id=15459
http://patchwork.ozlabs.org/linuxppc/patch?id=15460
arch/powerpc/boot/Makefile |3
arch/powerpc/boot/cuboot-katana750i.c | 248 ++
arch/powerpc/configs/katana750i_defconfig | 1315 ++
arch/powerpc/platforms/embedded6xx/Kconfig | 10
arch/powerpc/platforms/embedded6xx/Makefile |1
arch/powerpc/platforms/embedded6xx/katana750i.c | 314 +++
6 files changed, 1890 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index d1e625c..b04ecc0 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -62,7 +62,7 @@ src-plat := of.c cuboot-52xx.c cuboot-83xx.c cuboot-85xx.c
holly.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c cuboot-bamboo.c
\
fixed-head.S ep88xc.c cuboot-hpc2.c ep405.c cuboot-taishan.c \
- cuboot-katmai.c cuboot-rainier.c
+ cuboot-katmai.c cuboot-rainier.c cuboot-katana750i.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -206,6 +206,7 @@ image-$(CONFIG_RAINIER) +=
cuImage.rainier
image-$(CONFIG_WALNUT) += treeImage.walnut
image-$(CONFIG_TAISHAN)+= cuImage.taishan
image-$(CONFIG_KATMAI) += cuImage.katmai
+image-$(CONFIG_PPC_KATANA750I) += cuImage.katana750i
endif
# For 32-bit powermacs, build the COFF and miboot images
diff --git a/arch/powerpc/boot/cuboot-katana750i.c
b/arch/powerpc/boot/cuboot-katana750i.c
new file mode 100644
index 000..41d4105
--- /dev/null
+++ b/arch/powerpc/boot/cuboot-katana750i.c
@@ -0,0 +1,248 @@
+/*
+ * Emerson Katana-750i/752i
+ *
+ * Author: Mark A. Greer <[EMAIL PROTECTED]>
+ *
+ * 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 "stdio.h"
+#include "io.h"
+#include "ops.h"
+#include "cuboot.h"
+#include "ppcboot.h"
+#include "mv64x60.h"
+
+static u8 *bridge_base;
+static u8 *cpld_base;
+static bd_t bd;
+
+#define KATANA750I_CPLD_RST_CMD0x1000
+#define KATANA750I_CPLD_RST_CMD_HR 0x01
+
+#define KATANA750I_CPLD_PRODUCT_ID 0x4000
+#defineKATANA750I_PRODUCT_ID_750I 0x02
+#defineKATANA750I_PRODUCT_ID_752I 0x04
+
+#define KATANA750I_CPLD_BD_CFG_0 0x9000
+#define KATANA750I_CPLD_BD_CFG_0_SYSCLK_MASK 0xc0
+#define KATANA750I_CPLD_BD_CFG_0_SYSCLK_2000x00
+#define KATANA750I_CPLD_BD_CFG_0_SYSCLK_1660x80
+#define KATANA750I_CPLD_BD_CFG_0_SYSCLK_1330xc0
+#define KATANA750I_CPLD_BD_CFG_0_SYSCLK_1000x40
+
+#define BOARD_MODEL_MAX32
+
+typedef enum {
+ BOARD_TYPE_750I,
+ BOARD_TYPE_752I,
+} katana750i_board_type;
+
+struct katana750i_board_info {
+ charcpld_prod_id;
+ char*model;
+ char*bridge_type;
+};
+
+static struct katana750i_board_info katana750i_board_info[] = {
+ [BOARD_TYPE_750I] = {
+ .cpld_prod_id = KATANA750I_PRODUCT_ID_750I,
+ .model = "Katana-750i",
+ .bridge_type= "mv64360",
+ },
+ [BOARD_TYPE_752I] = {
+ .cpld_prod_id = KATANA750I_PRODUCT_ID_752I,
+ .model = "Katana-752i",
+ .bridge_type= "mv64460",
+ },
+};
+
+static struct katana750i_board_info *katana750i_get_bip(void)
+{
+ struct katana750i_board_info *bip;
+ int i;
+ u8 id;
+
+ id = in_8(cpld_base + KATANA750I_CPLD_PRODUCT_ID);
+
+ for (i = 0, bip = katana750
[PATCH 3/4] powerpc: Katana750i - Add DTS file
From: Mark A. Greer <[EMAIL PROTECTED]>
Add DTS file for the Emerson Katana 750i & 752i platforms.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/katana750i.dts | 372 +
1 file changed, 372 insertions(+)
diff --git a/arch/powerpc/boot/dts/katana750i.dts
b/arch/powerpc/boot/dts/katana750i.dts
new file mode 100644
index 000..03d9fd1
--- /dev/null
+++ b/arch/powerpc/boot/dts/katana750i.dts
@@ -0,0 +1,372 @@
+/* Device Tree Source for Emerson Katana 750i/752i
+ *
+ * Author: Mark A. Greer <[EMAIL PROTECTED]>
+ *
+ * 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.
+ *
+ * Property values that are labeled as "Default" will be updated by bootwrapper
+ * if it can determine the exact PrPMC type.
+ */
+
+/dts-v1/;
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ model = "Katana-75xi"; /* Default */
+ compatible = "emerson,katana-750i";
+ coherency-off;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,750 {
+ device_type = "cpu";
+ reg = <0>;
+ clock-frequency = <7>; /* Default */
+ bus-frequency = <1>;/* Default */
+ timebase-frequency = <>;/* Default */
+ i-cache-line-size = <0x20>;
+ d-cache-line-size = <0x20>;
+ i-cache-size = <0x8000>;
+ d-cache-size = <0x8000>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x0400>; /* Default (64MB) */
+ };
+
+ [EMAIL PROTECTED] { /* Marvell Discovery */
+ #address-cells = <1>;
+ #size-cells = <1>;
+ model = "mv64360"; /* Default */
+ compatible = "marvell,mv64360";
+ clock-frequency = <1>;
+ hs_reg_valid;
+ reg = <0xf810 0x0001>;
+ virtual-reg = <0xf810>;
+ ranges = <0xb000 0xb000 0x0400 /* PCI 1 I/O Space */
+ 0x8000 0x8000 0x3000 /* PCI 1 MEM Space */
+ 0xe800 0xe800 0x1000 /* User FLASH */
+ 0x 0xf810 0x0001 /* Bridge's regs */
+ 0xf808 0xf808 0x0001 /* PCI 0 I/O Space */
+ 0xf809 0xf809 0x0001 /* PCI 0 MEM Space */
+ 0xf820 0xf820 0x0020 /* CPLD & HSL Regs */
+ 0xf830 0xf830 0x0004>;/* Integrated SRAM*/
+
+ [EMAIL PROTECTED] {
+ compatible = "katana750i,cpld";
+ reg = <0xf820 0x0020>;
+ virtual-reg = <0xf820>;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ bank-width = <4>;
+ device-width = <2>;
+ reg = <0xe800 0x0400>;
+ [EMAIL PROTECTED] {
+ label = "Monitor";
+ reg = <0x 0x0010>;
+ };
+ [EMAIL PROTECTED] {
+ label = "Primary Kernel";
+ reg = <0x0010 0x0018>;
+ };
+ [EMAIL PROTECTED] {
+ label = "Primary Filesystem";
+ reg = <0x0028 0x01e0>;
+ };
+ [EMAIL PROTECTED] {
+ label = "Secondary Kernel";
+ reg = <0x0208 0x0018>;
+ };
+ [EMAIL PROTECTED] {
+ label = "Secondary Filesystem";
+ reg = <0x0220 0x01e0>;
+ };
+ [EMAIL PROTECTED] { /* overlay all but monitor */
+ label = "User FLASH";
[PATCH 2/4] powerpc: mv64x60 - Exit when no hs_reg_valid property
From: Mark A. Greer <[EMAIL PROTECTED]>
mv64x60_sysfs_init() should exit as soon as it discovers there is no
'hs_reg_valid' property in the Device Tree.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/mv64x60_pci.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/sysdev/mv64x60_pci.c
b/arch/powerpc/sysdev/mv64x60_pci.c
index 2115177..7cc1abf 100644
--- a/arch/powerpc/sysdev/mv64x60_pci.c
+++ b/arch/powerpc/sysdev/mv64x60_pci.c
@@ -97,6 +97,8 @@ static int __init mv64x60_sysfs_init(void)
prop = of_get_property(np, "hs_reg_valid", NULL);
of_node_put(np);
+ if (!prop)
+ return 0;
pdev = platform_device_register_simple("marvell,mv64360", 0, NULL, 0);
if (IS_ERR(pdev))
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/4] powerpc: mv64x60 - Use early_* PCI accessors for hotswap reg
From: Mark A. Greer <[EMAIL PROTECTED]>
The mv64x60 Hotswap register is on the first hose of the mv64x60
hostbridge. To access it, manually find the hose structure and
use the early_* PCI accessor routines because the hostbridge is
normally hidden.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/mv64x60.h | 22 ++
arch/powerpc/sysdev/mv64x60_pci.c | 25 +++--
2 files changed, 37 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/sysdev/mv64x60.h b/arch/powerpc/sysdev/mv64x60.h
index 4f618fa..27e22f4 100644
--- a/arch/powerpc/sysdev/mv64x60.h
+++ b/arch/powerpc/sysdev/mv64x60.h
@@ -3,10 +3,32 @@
#include
+#include
+#include
+
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);
+static inline struct pci_controller *mv64x60_find_hose(u32 idx)
+{
+ struct device_node *phb;
+ struct pci_controller *hose;
+ const u32 *prop;
+ int len;
+
+ for_each_compatible_node(phb, "pci", "marvell,mv64360-pci") {
+ prop = of_get_property(phb, "cell-index", &len);
+ if (prop && (len == sizeof(prop)) && (*prop == idx)) {
+ hose = pci_find_hose_for_OF_device(phb);
+ of_node_put(phb);
+ return hose;
+ }
+ }
+
+ return NULL;
+}
+
#endif /* __MV64X60_H__ */
diff --git a/arch/powerpc/sysdev/mv64x60_pci.c
b/arch/powerpc/sysdev/mv64x60_pci.c
index 1456015..2115177 100644
--- a/arch/powerpc/sysdev/mv64x60_pci.c
+++ b/arch/powerpc/sysdev/mv64x60_pci.c
@@ -17,6 +17,8 @@
#include
#include
+#include
+
#define PCI_HEADER_TYPE_INVALID0x7f/* Invalid PCI header
type */
#ifdef CONFIG_SYSFS
@@ -24,11 +26,12 @@
#define MV64X60_VAL_LEN_MAX11
#define MV64X60_PCICFG_CPCI_HOTSWAP0x68
+/* cPCI Hotswap register only supported on PCI 0 interface */
static ssize_t mv64x60_hs_reg_read(struct kobject *kobj,
struct bin_attribute *attr, char *buf,
loff_t off, size_t count)
{
- struct pci_dev *phb;
+ struct pci_controller *hose;
u32 v;
if (off > 0)
@@ -36,11 +39,12 @@ static ssize_t mv64x60_hs_reg_read(struct kobject *kobj,
if (count < MV64X60_VAL_LEN_MAX)
return -EINVAL;
- phb = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
- if (!phb)
+ hose = mv64x60_find_hose(0);
+ if (!hose)
return -ENODEV;
- pci_read_config_dword(phb, MV64X60_PCICFG_CPCI_HOTSWAP, &v);
- pci_dev_put(phb);
+
+ early_read_config_dword(hose, 0, PCI_DEVFN(0, 0),
+ MV64X60_PCICFG_CPCI_HOTSWAP, &v);
return sprintf(buf, "0x%08x\n", v);
}
@@ -49,7 +53,7 @@ static ssize_t mv64x60_hs_reg_write(struct kobject *kobj,
struct bin_attribute *attr, char *buf,
loff_t off, size_t count)
{
- struct pci_dev *phb;
+ struct pci_controller *hose;
u32 v;
if (off > 0)
@@ -60,11 +64,12 @@ static ssize_t mv64x60_hs_reg_write(struct kobject *kobj,
if (sscanf(buf, "%i", &v) != 1)
return -EINVAL;
- phb = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
- if (!phb)
+ hose = mv64x60_find_hose(0);
+ if (!hose)
return -ENODEV;
- pci_write_config_dword(phb, MV64X60_PCICFG_CPCI_HOTSWAP, v);
- pci_dev_put(phb);
+
+ early_write_config_dword(hose, 0, PCI_DEVFN(0, 0),
+ MV64X60_PCICFG_CPCI_HOTSWAP, v);
return count;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] powerpc: #address-cells & #size-cells properties not inherited
From: Mark A. Greer <[EMAIL PROTECTED]> Fix error in booting-without-of.txt that indicates that a node can inherit its #address-cells and #size-cells definitions from its parent's parent. This is not correct. Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]> --- Documentation/powerpc/booting-without-of.txt |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt index ee0209a..58db5ea 100644 --- a/Documentation/powerpc/booting-without-of.txt +++ b/Documentation/powerpc/booting-without-of.txt @@ -671,10 +671,10 @@ device or bus to be described by the device tree. In general, the format of an address for a device is defined by the parent bus type, based on the #address-cells and #size-cells -property. In the absence of such a property, the parent's parent -values are used, etc... The kernel requires the root node to have -those properties defining addresses format for devices directly mapped -on the processor bus. +properties. Note that the parent's parent definitions of #address-cells +and #size-cells are not inhereted so every node with children must specify +them. The kernel requires the root node to have those properties defining +addresses format for devices directly mapped on the processor bus. Those 2 properties define 'cells' for representing an address and a size. A "cell" is a 32-bit number. For example, if both contain 2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: #address-cells & #size-cells properties not inherited
On Wed, Jan 02, 2008 at 07:46:40PM -0600, Josh Boyer wrote: > On Wed, 2 Jan 2008 17:07:50 -0700 > "Mark A. Greer" <[EMAIL PROTECTED]> wrote: > > > From: Mark A. Greer <[EMAIL PROTECTED]> > > > > Fix error in booting-without-of.txt that indicates that a node can inherit > > its #address-cells and #size-cells definitions from its parent's parent. > > This is not correct and the latest dtc enforces it. > > I'm lazy so I haven't checked myself, but by "latest dtc" does that > mean the DTC that's in the kernel now? > > Things are going to be fun when we start saying generic things like > "latest DTC". And when upstream DTC gets new features or enforcements, > we'll have to have all the in-kernel DTS files patched up when that > version of DTC gets merged in-kernel. Just something to keep in mind > as we move along. Yeah, I thought about that last night, actually. I think I'll just change that sentence to "This is not correct." Avoid the issue :) Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: #address-cells & #size-cells properties not inherited
From: Mark A. Greer <[EMAIL PROTECTED]> Fix error in booting-without-of.txt that indicates that a node can inherit its #address-cells and #size-cells definitions from its parent's parent. This is not correct and the latest dtc enforces it. Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]> --- Documentation/powerpc/booting-without-of.txt |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt index ee0209a..58db5ea 100644 --- a/Documentation/powerpc/booting-without-of.txt +++ b/Documentation/powerpc/booting-without-of.txt @@ -671,10 +671,10 @@ device or bus to be described by the device tree. In general, the format of an address for a device is defined by the parent bus type, based on the #address-cells and #size-cells -property. In the absence of such a property, the parent's parent -values are used, etc... The kernel requires the root node to have -those properties defining addresses format for devices directly mapped -on the processor bus. +properties. Note that the parent's parent definitions of #address-cells +and #size-cells are not inhereted so every node with children must specify +them. The kernel requires the root node to have those properties defining +addresses format for devices directly mapped on the processor bus. Those 2 properties define 'cells' for representing an address and a size. A "cell" is a 32-bit number. For example, if both contain 2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/8] powerpc: prpmc2800 - Convert dts file to v1
On Sat, Dec 15, 2007 at 09:03:35AM +1100, David Gibson wrote:
> On Mon, Dec 10, 2007 at 05:37:38PM -0700, Mark A. Greer wrote:
> > From: Mark A. Greer <[EMAIL PROTECTED]>
> >
> > Convert the prpmc2800.dts file to dts-v1. Basically, this means
> > converting the numeric constants to be 'C'-like (e.g., hexadecimal
> > numbers start with '0x').
>
> [snip]
> > interrupt-parent = <&/mv64x60/pic>;
>
> If you're converting to dts-v1, you should also convert any path
> references like this to &{/mv64x60/pic} or else use a label. Yes,
> some early dts-v1 supporting dtc versions supported these as is, but
> the idea is to try to forget that they existed and always require the
> {} quoting in dts-v1.
I did convert to use labels in a later patch but it uses <&label> as
well. I can change them to &{label} that it appears you are suggesting
(I haven't tested to see that they work yet though).
Mark
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/5] PowerPC 74xx: Katana Qp base support
On Thu, Nov 29, 2007 at 06:42:00PM +0300, Andrei Dolnikov wrote: > Emerson Katana Qp platform specific code > > Signed-off-by: Andrei Dolnikov <[EMAIL PROTECTED]> Acked-by: Mark A. Greer <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/5] PowerPC 74xx: Katana Qp bootwrapper
On Thu, Nov 29, 2007 at 06:39:51PM +0300, Andrei Dolnikov wrote:
> Bootwrapper sources for Emerson Katana Qp
>
> Signed-off-by: Andrei Dolnikov <[EMAIL PROTECTED]>
>
> ---
> Makefile |3
> cuboot-katanaqp.c | 470
> ++
> 2 files changed, 472 insertions(+), 1 deletion(-)
> diff --git a/arch/powerpc/boot/cuboot-katanaqp.c
> b/arch/powerpc/boot/cuboot-katanaqp.c
> new file mode 100644
> index 000..19ba901
> --- /dev/null
> +++ b/arch/powerpc/boot/cuboot-katanaqp.c
> @@ -0,0 +1,470 @@
> + /* Get the cpu -> pci i/o & mem mappings from the device tree */
> + devp = finddevice("/mv64x60");
> + if (devp == NULL)
> + fatal("Error: Missing /mv64x60 device tree node\n\r");
> +
> +
> + enables = in_le32((u32 *) (bridge_base + MV64x60_CPU_BAR_ENABLE));
> + enables |= 0x0007fe00; /* Disable all cpu->pci windows */
> + out_le32((u32 *) (bridge_base + MV64x60_CPU_BAR_ENABLE), enables);
> +
> + for (i = 0; i < 12; i += 6) {
> + switch (v[i] & 0xff00) {
> + case 0x0100:/* PCI I/O Space */
> + tbl = mv64x60_cpu2pci_io;
> + break;
> + case 0x0200:/* PCI MEM Space */
> + tbl = mv64x60_cpu2pci_mem;
> + break;
> + default:
> + continue;
> + }
> +
> + pci_base_hi = v[i + 1];
> + pci_base_lo = v[i + 2];
> + cpu_base = v[i + 3];
> + size = v[i + 5];
> +
> + buf[0] = cpu_base;
> + buf[1] = size;
> +
> + if (!dt_xlate_addr(devp, buf, sizeof(buf), &cpu_base))
> + fatal("Error: Can't translate PCI address 0x%x\n\r",
> + (u32) cpu_base);
> +
> + mv64x60_config_cpu2pci_window(bridge_base, 1, pci_base_hi,
> + pci_base_lo, cpu_base, size, tbl);
> + }
Looks like we could factor out some of this code that's the same here
and in prpmc2800.c. I can do that later, though.
> +void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
> +unsigned long r6, unsigned long r7)
> +{
> +
> + CUBOOT_INIT();
> +
> + if (ft_init(_dtb_start, _dtb_end - _dtb_start, 16))
> + exit();
This should be replaced by fdt_init(dtb) now.
Mark
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/5] PowerPC 74xx: Minor updates to MV64x60 boot code
On Thu, Nov 29, 2007 at 06:35:55PM +0300, Andrei Dolnikov wrote:
Hi Andrei. I have a few comments below.
> This patch adds new functionality to MV64x60 boot code. The changes are
> required
> to access DevCS windows registers and set PCI bus and devfn numbers for
> MV644x60
> PCI/PCI-X interfaces.
>
> Signed-off-by: Andrei Dolnikov <[EMAIL PROTECTED]>
>
> ---
> mv64x60.c | 74
> ++
> mv64x60.h | 10
> 2 files changed, 84 insertions(+)
>
> diff --git a/arch/powerpc/boot/mv64x60.c b/arch/powerpc/boot/mv64x60.c
> index d207a0b..787a124 100644
> --- a/arch/powerpc/boot/mv64x60.c
> +++ b/arch/powerpc/boot/mv64x60.c
> @@ -32,6 +32,16 @@
> #define MV64x60_CPU2MEM_3_BASE 0x0218
> #define MV64x60_CPU2MEM_3_SIZE 0x0220
>
> +#define MV64x60_DEV2MEM_WINDOWS 4
> +#define MV64x60_DEV2MEM_0_BASE 0x0028
> +#define MV64x60_DEV2MEM_0_SIZE 0x0030
> +#define MV64x60_DEV2MEM_1_BASE 0x0228
> +#define MV64x60_DEV2MEM_1_SIZE 0x0230
> +#define MV64x60_DEV2MEM_2_BASE 0x0248
> +#define MV64x60_DEV2MEM_2_SIZE 0x0250
> +#define MV64x60_DEV2MEM_3_BASE 0x0038
> +#define MV64x60_DEV2MEM_3_SIZE 0x0040
> +
These aren't device->memory windows, they're CPU->device windows so
they should be named MV64x60_CPU2DEV_xxx to be consistent with the
previously established naming convention.
> #define MV64x60_ENET2MEM_BAR_ENABLE 0x2290
> #define MV64x60_ENET2MEM_0_BASE 0x2200
> #define MV64x60_ENET2MEM_0_SIZE 0x2204
> @@ -219,6 +229,25 @@ static struct mv64x60_mem_win
> mv64x60_cpu2mem[MV64x60_CPU2MEM_WINDOWS] = {
> },
> };
>
> +static struct mv64x60_mem_win mv64x60_devcs[MV64x60_DEV2MEM_WINDOWS] = {
Why not call this mv64x60_cpu2dev[]?
> @@ -586,6 +645,21 @@ u32 mv64x60_get_mem_size(u8 *bridge_base)
> return mem;
> }
>
> +/* Read a size of DEV_CS window */
> +u32 mv64x60_get_devcs_size(u8 *bridge_base, u32 devcs)
u32 mv64x60_get_cpu2dev_size(...)
> diff --git a/arch/powerpc/boot/mv64x60.h b/arch/powerpc/boot/mv64x60.h
> index d0b29a7..a633d2e 100644
> --- a/arch/powerpc/boot/mv64x60.h
> +++ b/arch/powerpc/boot/mv64x60.h
> @@ -12,6 +12,14 @@
>
> #define MV64x60_CPU_BAR_ENABLE 0x0278
>
> +#define MV64x60_PCI0_MODE0x0d00
> +#define MV64x60_PCI1_MODE0x0d80
> +#define MV64x60_PCI0_P2P_CONF0x1d14
> +#define MV64x60_PCI1_P2P_CONF0x1d94
> +
> +#define MV64x60_PCI_MODE_MASK0x0030
> +#define MV64x60_PCI_CONVENTIONAL_MODE0x
> +
AFAICS these macros are only used in mv64x60.c so just put them there.
They only need to go in mv64x60.h if they're used in more than one .c
file.
Mark
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 8/8] powerpc: prpmc2800 - Miscellaneous DTS file fixups
From: Mark A. Greer <[EMAIL PROTECTED]>
Remove unnecessary device_type properties and leading zeroes in node names.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/prpmc2800.dts |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/prpmc2800.dts
b/arch/powerpc/boot/dts/prpmc2800.dts
index 054f028..6af5a3a 100644
--- a/arch/powerpc/boot/dts/prpmc2800.dts
+++ b/arch/powerpc/boot/dts/prpmc2800.dts
@@ -133,7 +133,6 @@
};
SDMA0: [EMAIL PROTECTED] {
- device_type = "dma";
compatible = "marvell,mv64360-sdma";
reg = <0x4000 0xc18>;
virtual-reg = <0xf1004000>;
@@ -143,7 +142,6 @@
};
SDMA1: [EMAIL PROTECTED] {
- device_type = "dma";
compatible = "marvell,mv64360-sdma";
reg = <0x6000 0xc18>;
virtual-reg = <0xf1006000>;
@@ -300,14 +298,14 @@
>;
};
- [EMAIL PROTECTED] {
+ [EMAIL PROTECTED] {
compatible = "marvell,mv64360-cpu-error";
reg = <0x0070 0x10 0x0128 0x28>;
interrupts = <3>;
interrupt-parent = <&PIC>;
};
- [EMAIL PROTECTED] {
+ [EMAIL PROTECTED] {
compatible = "marvell,mv64360-sram-ctrl";
reg = <0x0380 0x80>;
interrupts = <13>;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 7/8] powerpc: mv64x60 - Remove timeout property for WDT
From: Mark A. Greer <[EMAIL PROTECTED]>
Remove support for the DTS timeout property that's currently there for
the watchdog timer on mv64x60 hostbridges. The platform_data remains
and can be modified by platform-specific code when necessary.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/prpmc2800.dts |1 -
arch/powerpc/sysdev/mv64x60_dev.c |5 +
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/powerpc/boot/dts/prpmc2800.dts
b/arch/powerpc/boot/dts/prpmc2800.dts
index b608e6c..054f028 100644
--- a/arch/powerpc/boot/dts/prpmc2800.dts
+++ b/arch/powerpc/boot/dts/prpmc2800.dts
@@ -226,7 +226,6 @@
[EMAIL PROTECTED] { /* watchdog timer */
compatible = "marvell,mv64360-wdt";
reg = <0xb410 0x8>;
- timeout = <10>; /* wdt timeout in seconds */
};
[EMAIL PROTECTED] {
diff --git a/arch/powerpc/sysdev/mv64x60_dev.c
b/arch/powerpc/sysdev/mv64x60_dev.c
index e0244d8..f998330 100644
--- a/arch/powerpc/sysdev/mv64x60_dev.c
+++ b/arch/powerpc/sysdev/mv64x60_dev.c
@@ -403,10 +403,7 @@ static int __init mv64x60_wdt_device_setup(struct
device_node *np, int id)
memset(&pdata, 0, sizeof(pdata));
- prop = of_get_property(np, "timeout", NULL);
- if (!prop)
- return -ENODEV;
- pdata.timeout = *prop;
+ pdata.timeout = 10; /* Default: 10 seconds */
np = of_get_parent(np);
if (!np)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 6/8] powerpc: mv64x60 - Update i2c DTS properties
From: Mark A. Greer <[EMAIL PROTECTED]> DTS files should not specify the default timeout value for the mv64360 i2c controller. Also, remove deprecated 'retries' property. Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]> --- FYI, the 'retries' property use and related platform_data will be removed in a patch that is working its way through the i2c community. arch/powerpc/boot/dts/prpmc2800.dts |2 -- arch/powerpc/sysdev/mv64x60_dev.c |6 +- 2 files changed, 1 insertion(+), 7 deletions(-) diff --git a/arch/powerpc/boot/dts/prpmc2800.dts b/arch/powerpc/boot/dts/prpmc2800.dts index e670e3f..b608e6c 100644 --- a/arch/powerpc/boot/dts/prpmc2800.dts +++ b/arch/powerpc/boot/dts/prpmc2800.dts @@ -236,8 +236,6 @@ virtual-reg = <0xf100c000>; freq_m = <8>; freq_n = <3>; - timeout = <1000>; /* 1000 = 1 second */ - retries = <1>; interrupts = <37>; interrupt-parent = <&PIC>; }; diff --git a/arch/powerpc/sysdev/mv64x60_dev.c b/arch/powerpc/sysdev/mv64x60_dev.c index 587c40f..e0244d8 100644 --- a/arch/powerpc/sysdev/mv64x60_dev.c +++ b/arch/powerpc/sysdev/mv64x60_dev.c @@ -355,11 +355,7 @@ static int __init mv64x60_i2c_device_setup(struct device_node *np, int id) return -ENODEV; pdata.freq_n = *prop; - prop = of_get_property(np, "timeout", NULL); - if (prop) - pdata.timeout = *prop; - else - pdata.timeout = 1000; /* 1 second */ + pdata.timeout = 1000; /* 1 second */ prop = of_get_property(np, "retries", NULL); if (prop) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 5/8] powerpc: MPSC - Update DTS entries
From: Mark A. Greer <[EMAIL PROTECTED]>
MPSC DTS nodes should use 'cell-index' to distinguish between MPSC
controllers (just like all the other DTS files). Also, rename the
compatible property from 'marvell,mpsc' to 'marvell,mv64360-mpsc'
for consistency.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/prpmc2800.dts |8
arch/powerpc/boot/mpsc.c|2 +-
arch/powerpc/boot/serial.c |2 +-
arch/powerpc/sysdev/mv64x60_dev.c |8
arch/powerpc/sysdev/mv64x60_udbg.c |4 ++--
5 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/boot/dts/prpmc2800.dts
b/arch/powerpc/boot/dts/prpmc2800.dts
index 1447faa..e670e3f 100644
--- a/arch/powerpc/boot/dts/prpmc2800.dts
+++ b/arch/powerpc/boot/dts/prpmc2800.dts
@@ -185,7 +185,7 @@
[EMAIL PROTECTED] {
device_type = "serial";
- compatible = "marvell,mpsc";
+ compatible = "marvell,mv64360-mpsc";
reg = <0x8000 0x38>;
virtual-reg = <0xf1008000>;
sdma = <&SDMA0>;
@@ -193,7 +193,7 @@
cunit = <&CUNIT>;
mpscrouting = <&MPSCROUTING>;
mpscintr = <&MPSCINTR>;
- block-index = <0>;
+ cell-index = <0>;
max_idle = <40>;
chr_1 = <0>;
chr_2 = <0>;
@@ -205,7 +205,7 @@
[EMAIL PROTECTED] {
device_type = "serial";
- compatible = "marvell,mpsc";
+ compatible = "marvell,mv64360-mpsc";
reg = <0x9000 0x38>;
virtual-reg = <0xf1009000>;
sdma = <&SDMA1>;
@@ -213,7 +213,7 @@
cunit = <&CUNIT>;
mpscrouting = <&MPSCROUTING>;
mpscintr = <&MPSCINTR>;
- block-index = <1>;
+ cell-index = <1>;
max_idle = <40>;
chr_1 = <0>;
chr_2 = <0>;
diff --git a/arch/powerpc/boot/mpsc.c b/arch/powerpc/boot/mpsc.c
index 802ea53..425ad88 100644
--- a/arch/powerpc/boot/mpsc.c
+++ b/arch/powerpc/boot/mpsc.c
@@ -141,7 +141,7 @@ int mpsc_console_init(void *devp, struct
serial_console_data *scdp)
if (mpscintr_base == NULL)
goto err_out;
- n = getprop(devp, "block-index", &v, sizeof(v));
+ n = getprop(devp, "cell-index", &v, sizeof(v));
if (n != sizeof(v))
goto err_out;
reg_set = (int)v;
diff --git a/arch/powerpc/boot/serial.c b/arch/powerpc/boot/serial.c
index cafeece..cbcbb20 100644
--- a/arch/powerpc/boot/serial.c
+++ b/arch/powerpc/boot/serial.c
@@ -119,7 +119,7 @@ int serial_console_init(void)
if (dt_is_compatible(devp, "ns16550"))
rc = ns16550_console_init(devp, &serial_cd);
- else if (dt_is_compatible(devp, "marvell,mpsc"))
+ else if (dt_is_compatible(devp, "marvell,mv64360-mpsc"))
rc = mpsc_console_init(devp, &serial_cd);
else if (dt_is_compatible(devp, "fsl,cpm1-scc-uart") ||
dt_is_compatible(devp, "fsl,cpm1-smc-uart") ||
diff --git a/arch/powerpc/sysdev/mv64x60_dev.c
b/arch/powerpc/sysdev/mv64x60_dev.c
index 20cd5e3..587c40f 100644
--- a/arch/powerpc/sysdev/mv64x60_dev.c
+++ b/arch/powerpc/sysdev/mv64x60_dev.c
@@ -127,7 +127,7 @@ static int __init mv64x60_mpsc_device_setup(struct
device_node *np, int id)
if (err)
return err;
- prop = of_get_property(np, "block-index", NULL);
+ prop = of_get_property(np, "cell-index", NULL);
if (!prop)
return -ENODEV;
port_number = *(int *)prop;
@@ -452,7 +452,7 @@ static int __init mv64x60_device_setup(void)
int err;
id = 0;
- for_each_compatible_node(np, "serial", "marvell,mpsc")
+ for_each_compatible_node(np, "serial", "marvell,mv64360-mpsc")
if ((err = mv64x60_mpsc_device_setup(np, id++)))
goto error;
@@ -495,10 +495,10 @@ static int __init mv64x60_add_mpsc_console(void)
if (!np)
goto not_mpsc;
- if (!of_device_is_compatible(np, "marvell,mpsc"))
+ if (!of_device_is_compatible(np, "marvell,mv64360-mpsc"))
goto not_mpsc;
-
[PATCH 4/8] powerpc: mv64x60 - Update ethernet DTS nodes
From: Mark A. Greer <[EMAIL PROTECTED]>
DTS entries for mv64360 ethernet controllers should use 'reg' property
instead of the 'block-index' property. Also, use 'multiethernet'
instead of 'ethernet' for parent node and use '[EMAIL PROTECTED]' instead of
'eth?' for subnodes.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/prpmc2800.dts | 10 +-
arch/powerpc/sysdev/mv64x60_dev.c |2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/boot/dts/prpmc2800.dts
b/arch/powerpc/boot/dts/prpmc2800.dts
index a4a3622..1447faa 100644
--- a/arch/powerpc/boot/dts/prpmc2800.dts
+++ b/arch/powerpc/boot/dts/prpmc2800.dts
@@ -110,21 +110,21 @@
};
};
- [EMAIL PROTECTED] {
+ [EMAIL PROTECTED] {
reg = <0x2000 0x2000>;
- eth0 {
+ [EMAIL PROTECTED] {
device_type = "network";
compatible = "marvell,mv64360-eth";
- block-index = <0>;
+ reg = <0>;
interrupts = <32>;
interrupt-parent = <&PIC>;
phy = <&PHY0>;
local-mac-address = [ 00 00 00 00 00 00 ];
};
- eth1 {
+ [EMAIL PROTECTED] {
device_type = "network";
compatible = "marvell,mv64360-eth";
- block-index = <1>;
+ reg = <1>;
interrupts = <33>;
interrupt-parent = <&PIC>;
phy = <&PHY1>;
diff --git a/arch/powerpc/sysdev/mv64x60_dev.c
b/arch/powerpc/sysdev/mv64x60_dev.c
index dca205f..20cd5e3 100644
--- a/arch/powerpc/sysdev/mv64x60_dev.c
+++ b/arch/powerpc/sysdev/mv64x60_dev.c
@@ -248,7 +248,7 @@ static int __init mv64x60_eth_device_setup(struct
device_node *np, int id)
memset(&pdata, 0, sizeof(pdata));
- prop = of_get_property(np, "block-index", NULL);
+ prop = of_get_property(np, "reg", NULL);
if (!prop)
return -ENODEV;
pdata.port_number = *prop;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/8] powerpc: mv64x60 - Replace marvell, mv64x60 with marvell, mv64360
From: Mark A. Greer <[EMAIL PROTECTED]>
Compatible property names like "marvell,mv64x60..." are not acceptable
so replace them with name like "marvell,mv64360..."
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/prpmc2800.dts| 34 +++
arch/powerpc/platforms/embedded6xx/prpmc2800.c |4 -
arch/powerpc/sysdev/mv64x60_dev.c |6 +-
arch/powerpc/sysdev/mv64x60_pci.c |6 +-
arch/powerpc/sysdev/mv64x60_pic.c |4 -
5 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/arch/powerpc/boot/dts/prpmc2800.dts
b/arch/powerpc/boot/dts/prpmc2800.dts
index 1657ee6..a4a3622 100644
--- a/arch/powerpc/boot/dts/prpmc2800.dts
+++ b/arch/powerpc/boot/dts/prpmc2800.dts
@@ -93,7 +93,7 @@
#address-cells = <1>;
#size-cells = <0>;
device_type = "mdio";
- compatible = "marvell,mv64x60-mdio";
+ compatible = "marvell,mv64360-mdio";
PHY0: [EMAIL PROTECTED] {
device_type = "ethernet-phy";
compatible = "broadcom,bcm5421";
@@ -114,7 +114,7 @@
reg = <0x2000 0x2000>;
eth0 {
device_type = "network";
- compatible = "marvell,mv64x60-eth";
+ compatible = "marvell,mv64360-eth";
block-index = <0>;
interrupts = <32>;
interrupt-parent = <&PIC>;
@@ -123,7 +123,7 @@
};
eth1 {
device_type = "network";
- compatible = "marvell,mv64x60-eth";
+ compatible = "marvell,mv64360-eth";
block-index = <1>;
interrupts = <33>;
interrupt-parent = <&PIC>;
@@ -134,7 +134,7 @@
SDMA0: [EMAIL PROTECTED] {
device_type = "dma";
- compatible = "marvell,mv64x60-sdma";
+ compatible = "marvell,mv64360-sdma";
reg = <0x4000 0xc18>;
virtual-reg = <0xf1004000>;
interrupt-base = <0>;
@@ -144,7 +144,7 @@
SDMA1: [EMAIL PROTECTED] {
device_type = "dma";
- compatible = "marvell,mv64x60-sdma";
+ compatible = "marvell,mv64360-sdma";
reg = <0x6000 0xc18>;
virtual-reg = <0xf1006000>;
interrupt-base = <0>;
@@ -153,7 +153,7 @@
};
BRG0: [EMAIL PROTECTED] {
- compatible = "marvell,mv64x60-brg";
+ compatible = "marvell,mv64360-brg";
reg = <0xb200 0x8>;
clock-src = <8>;
clock-frequency = <13300>;
@@ -162,7 +162,7 @@
};
BRG1: [EMAIL PROTECTED] {
- compatible = "marvell,mv64x60-brg";
+ compatible = "marvell,mv64360-brg";
reg = <0xb208 0x8>;
clock-src = <8>;
clock-frequency = <13300>;
@@ -224,14 +224,14 @@
};
[EMAIL PROTECTED] { /* watchdog timer */
- compatible = "marvell,mv64x60-wdt";
+ compatible = "marvell,mv64360-wdt";
reg = <0xb410 0x8>;
timeout = <10>; /* wdt timeout in seconds */
};
[EMAIL PROTECTED] {
device_type = "i2c";
- compatible = "marvell,mv64x60-i2c";
+ compatible = "marvell,mv64360-i2c";
reg = <0xc000 0x20>;
virtual-reg = <0xf100c000>;
freq_m = <8>;
@@ -245,18 +245,18 @@
PIC: pic {
#interrupt-cells = <1>;
#address-cells = <0>;
- compatible = "marvell,mv64x60-pic";
+ compatible = "mar
[PATCH 2/8] powerpc: prpmc2800 - Add labels to dts file
From: Mark A. Greer <[EMAIL PROTECTED]>
Add & use labels for dts nodes that are referenced in the prpmc2800.dts
file to improve readability.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/prpmc2800.dts | 104 +-
1 file changed, 52 insertions(+), 52 deletions(-)
diff --git a/arch/powerpc/boot/dts/prpmc2800.dts
b/arch/powerpc/boot/dts/prpmc2800.dts
index 15247a4..1657ee6 100644
--- a/arch/powerpc/boot/dts/prpmc2800.dts
+++ b/arch/powerpc/boot/dts/prpmc2800.dts
@@ -94,18 +94,18 @@
#size-cells = <0>;
device_type = "mdio";
compatible = "marvell,mv64x60-mdio";
- [EMAIL PROTECTED] {
+ PHY0: [EMAIL PROTECTED] {
device_type = "ethernet-phy";
compatible = "broadcom,bcm5421";
interrupts = <76>; /* GPP 12 */
- interrupt-parent = <&/mv64x60/pic>;
+ interrupt-parent = <&PIC>;
reg = <1>;
};
- [EMAIL PROTECTED] {
+ PHY1: [EMAIL PROTECTED] {
device_type = "ethernet-phy";
compatible = "broadcom,bcm5421";
interrupts = <76>; /* GPP 12 */
- interrupt-parent = <&/mv64x60/pic>;
+ interrupt-parent = <&PIC>;
reg = <3>;
};
};
@@ -117,8 +117,8 @@
compatible = "marvell,mv64x60-eth";
block-index = <0>;
interrupts = <32>;
- interrupt-parent = <&/mv64x60/pic>;
- phy = <&/mv64x60/mdio/[EMAIL PROTECTED]>;
+ interrupt-parent = <&PIC>;
+ phy = <&PHY0>;
local-mac-address = [ 00 00 00 00 00 00 ];
};
eth1 {
@@ -126,33 +126,33 @@
compatible = "marvell,mv64x60-eth";
block-index = <1>;
interrupts = <33>;
- interrupt-parent = <&/mv64x60/pic>;
- phy = <&/mv64x60/mdio/[EMAIL PROTECTED]>;
+ interrupt-parent = <&PIC>;
+ phy = <&PHY1>;
local-mac-address = [ 00 00 00 00 00 00 ];
};
};
- [EMAIL PROTECTED] {
+ SDMA0: [EMAIL PROTECTED] {
device_type = "dma";
compatible = "marvell,mv64x60-sdma";
reg = <0x4000 0xc18>;
virtual-reg = <0xf1004000>;
interrupt-base = <0>;
interrupts = <36>;
- interrupt-parent = <&/mv64x60/pic>;
+ interrupt-parent = <&PIC>;
};
- [EMAIL PROTECTED] {
+ SDMA1: [EMAIL PROTECTED] {
device_type = "dma";
compatible = "marvell,mv64x60-sdma";
reg = <0x6000 0xc18>;
virtual-reg = <0xf1006000>;
interrupt-base = <0>;
interrupts = <38>;
- interrupt-parent = <&/mv64x60/pic>;
+ interrupt-parent = <&PIC>;
};
- [EMAIL PROTECTED] {
+ BRG0: [EMAIL PROTECTED] {
compatible = "marvell,mv64x60-brg";
reg = <0xb200 0x8>;
clock-src = <8>;
@@ -161,7 +161,7 @@
bcr = <0>;
};
- [EMAIL PROTECTED] {
+ BRG1: [EMAIL PROTECTED] {
compatible = "marvell,mv64x60-brg";
reg = <0xb208 0x8>;
clock-src = <8>;
@@ -170,15 +170,15 @@
bcr = <0>;
};
- [EMAIL PROTECTED] {
+ CUNIT: [EMAIL PROTECTED] {
reg = <
[PATCH 1/8] powerpc: prpmc2800 - Convert dts file to v1
From: Mark A. Greer <[EMAIL PROTECTED]>
Convert the prpmc2800.dts file to dts-v1. Basically, this means
converting the numeric constants to be 'C'-like (e.g., hexadecimal
numbers start with '0x').
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/prpmc2800.dts | 188 +-
1 file changed, 96 insertions(+), 92 deletions(-)
diff --git a/arch/powerpc/boot/dts/prpmc2800.dts
b/arch/powerpc/boot/dts/prpmc2800.dts
index 24944ca..15247a4 100644
--- a/arch/powerpc/boot/dts/prpmc2800.dts
+++ b/arch/powerpc/boot/dts/prpmc2800.dts
@@ -11,6 +11,8 @@
* if it can determine the exact PrPMC type.
*/
+/dts-v1/;
+
/ {
#address-cells = <1>;
#size-cells = <1>;
@@ -25,64 +27,64 @@
PowerPC,7447 {
device_type = "cpu";
reg = <0>;
- clock-frequency = <2bb0b140>; /* Default (733 MHz) */
- bus-frequency = <7f28155>; /* 133.33 MHz */
- timebase-frequency = <1fca055>; /* 33.33 MHz */
- i-cache-line-size = <20>;
- d-cache-line-size = <20>;
- i-cache-size = <8000>;
- d-cache-size = <8000>;
+ clock-frequency = <7>; /* Default */
+ bus-frequency = <1>;
+ timebase-frequency = <>;
+ i-cache-line-size = <0x20>;
+ d-cache-line-size = <0x20>;
+ i-cache-size = <0x8000>;
+ d-cache-size = <0x8000>;
};
};
memory {
device_type = "memory";
- reg = < 2000>; /* Default (512MB) */
+ reg = <0x 0x2000>; /* Default (512MB) */
};
[EMAIL PROTECTED] { /* Marvell Discovery */
#address-cells = <1>;
#size-cells = <1>;
model = "mv64360"; /* Default */
- compatible = "marvell,mv64x60";
- clock-frequency = <7f28155>;/* 133.33 MHz */
- reg = ;
- virtual-reg = ;
- ranges = <8800 8800 0100/* PCI 0 I/O Space */
- 8000 8000 0800/* PCI 0 MEM Space */
- a000 a000 0400/* User FLASH */
- f100 0001/* Bridge's regs */
- f200 f200 0004>; /* Integrated SRAM */
+ compatible = "marvell,mv64360";
+ clock-frequency = <1>;
+ reg = <0xf100 0x0001>;
+ virtual-reg = <0xf100>;
+ ranges = <0x8800 0x8800 0x0100 /* PCI 0 I/O Space */
+ 0x8000 0x8000 0x0800 /* PCI 0 MEM Space */
+ 0xa000 0xa000 0x0400 /* User FLASH */
+ 0x 0xf100 0x0001 /* Bridge's regs */
+ 0xf200 0xf200 0x0004>;/* Integrated SRAM*/
[EMAIL PROTECTED] {
compatible = "cfi-flash";
- reg = ;
+ reg = <0xa000 0x0400>;
bank-width = <4>;
device-width = <2>;
#address-cells = <1>;
#size-cells = <1>;
[EMAIL PROTECTED] {
label = "FW Image A";
- reg = < 0010>;
+ reg = <0x 0x0010>;
read-only;
};
[EMAIL PROTECTED] {
label = "FW Config Data"; /* RW */
- reg = <0010 0004>;
+ reg = <0x0010 0x0004>;
};
[EMAIL PROTECTED] {
label = "Kernel Image";
- reg = <0014 0040>;
+ reg = <0x0014 0x0040>;
read-only;
};
[EMAIL PROTECTED] {
label = "Filesystem";
- reg = <0054 039c>;
+
[PATCH 0/8] powerpc: mv64x60/prpmc2800 - DTS updates, etc.
This is the broken out patch series that equates to the "big blob" patch (with minor modifications) that was sent here: http://patchwork.ozlabs.org/linuxppc/patch?id=15382 These patches depend on the following patches to apply cleanly: http://patchwork.ozlabs.org/linuxppc/patch?id=14397 http://patchwork.ozlabs.org/linuxppc/patch?id=14396 http://patchwork.ozlabs.org/linuxppc/patch?id=14631 http://patchwork.ozlabs.org/linuxppc/patch?id=14632 http://patchwork.ozlabs.org/linuxppc/patch?id=14633 http://patchwork.ozlabs.org/linuxppc/patch?id=15007 Please let me know if you have any issues with these patches. Thanks, Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
On Sat, Dec 08, 2007 at 12:33:09PM +1100, David Gibson wrote: > On Thu, Dec 06, 2007 at 04:27:56PM -0700, Mark A. Greer wrote: > > David, et. al., > > > > This is a big blob patch of what I've changed for the prpmc2800. It > > includes the necessary changes in the kernel which you can probably > > ignore but they're there for reference. If you like the dts, then I'll > > split the blob up into logical pieces and Andrei can make similar > > changes for the Katana Qp. > > > > Let me know what you think. > > Looks pretty reasonable. I would have preferred that labels be > uppercase by convention, to make them easier to pick out by eyeball, > but I think that's a lost cause at this stage. I can do that. Thanks for the feedback. I'll break the blob up into pieces and submit with the labels in uppercase. Thanks, Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
David, et. al.,
This is a big blob patch of what I've changed for the prpmc2800. It
includes the necessary changes in the kernel which you can probably
ignore but they're there for reference. If you like the dts, then I'll
split the blob up into logical pieces and Andrei can make similar
changes for the Katana Qp.
Let me know what you think.
Mark
---
This patch is based on the latest powerpc.git tree
(44032af0e7d5467b12f998dbf2f1cd23c5324fd5) with the following patches
applied:
http://patchwork.ozlabs.org/linuxppc/patch?id=14339
http://patchwork.ozlabs.org/linuxppc/patch?id=14397
http://patchwork.ozlabs.org/linuxppc/patch?id=14396
http://patchwork.ozlabs.org/linuxppc/patch?id=14631
http://patchwork.ozlabs.org/linuxppc/patch?id=14632
http://patchwork.ozlabs.org/linuxppc/patch?id=14633
http://patchwork.ozlabs.org/linuxppc/patch?id=15007
arch/powerpc/boot/dts/prpmc2800.dts| 320 +++
arch/powerpc/boot/mpsc.c |2
arch/powerpc/boot/serial.c |2
arch/powerpc/platforms/embedded6xx/prpmc2800.c |4
arch/powerpc/sysdev/mv64x60_dev.c | 29 -
arch/powerpc/sysdev/mv64x60_pci.c |6
arch/powerpc/sysdev/mv64x60_pic.c |4
arch/powerpc/sysdev/mv64x60_udbg.c |4
8 files changed, 181 insertions(+), 190 deletions(-)
diff --git a/arch/powerpc/boot/dts/prpmc2800.dts
b/arch/powerpc/boot/dts/prpmc2800.dts
index 24944ca..080130e 100644
--- a/arch/powerpc/boot/dts/prpmc2800.dts
+++ b/arch/powerpc/boot/dts/prpmc2800.dts
@@ -11,6 +11,8 @@
* if it can determine the exact PrPMC type.
*/
+/dts-v1/;
+
/ {
#address-cells = <1>;
#size-cells = <1>;
@@ -25,64 +27,64 @@
PowerPC,7447 {
device_type = "cpu";
reg = <0>;
- clock-frequency = <2bb0b140>; /* Default (733 MHz) */
- bus-frequency = <7f28155>; /* 133.33 MHz */
- timebase-frequency = <1fca055>; /* 33.33 MHz */
- i-cache-line-size = <20>;
- d-cache-line-size = <20>;
- i-cache-size = <8000>;
- d-cache-size = <8000>;
+ clock-frequency = <7>; /* Default */
+ bus-frequency = <1>;
+ timebase-frequency = <>;
+ i-cache-line-size = <0x20>;
+ d-cache-line-size = <0x20>;
+ i-cache-size = <0x8000>;
+ d-cache-size = <0x8000>;
};
};
memory {
device_type = "memory";
- reg = < 2000>; /* Default (512MB) */
+ reg = <0x 0x2000>; /* Default (512MB) */
};
[EMAIL PROTECTED] { /* Marvell Discovery */
#address-cells = <1>;
#size-cells = <1>;
model = "mv64360"; /* Default */
- compatible = "marvell,mv64x60";
- clock-frequency = <7f28155>;/* 133.33 MHz */
- reg = ;
- virtual-reg = ;
- ranges = <8800 8800 0100/* PCI 0 I/O Space */
- 8000 8000 0800/* PCI 0 MEM Space */
- a000 a000 0400/* User FLASH */
- f100 0001/* Bridge's regs */
- f200 f200 0004>; /* Integrated SRAM */
+ compatible = "marvell,mv64360";
+ clock-frequency = <1>;
+ reg = <0xf100 0x0001>;
+ virtual-reg = <0xf100>;
+ ranges = <0x8800 0x8800 0x0100 /* PCI 0 I/O Space */
+ 0x8000 0x8000 0x0800 /* PCI 0 MEM Space */
+ 0xa000 0xa000 0x0400 /* User FLASH */
+ 0x 0xf100 0x0001 /* Bridge's regs */
+ 0xf200 0xf200 0x0004>;/* Integrated SRAM*/
[EMAIL PROTECTED] {
compatible = "cfi-flash";
- reg = ;
+ reg = <0xa000 0x0400>;
bank-width = <4>;
device-width = <2>;
#address-cells = <1>;
#size-cells = <1>;
[EMAIL PROTECTED] {
label = "FW Image A";
- reg = < 0010>;
+ reg = <0x 0x0010>;
read-only;
};
[EMAIL PROTECTED] {
label = "FW Config Data"; /* R
Re: [PATCH] Add aliases node to 8641hpcn DTS file.
On Wed, Dec 05, 2007 at 11:32:50AM -0600, Jon Loeliger wrote:
> diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> index abb26dc..b039f21 100644
> --- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> +++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
> @@ -16,6 +16,17 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> + aliases {
> + ethernet0 = &enet0;
> + ethernet1 = &enet1;
> + ethernet2 = &enet2;
> + ethernet3 = &enet3;
> + serial0 = &serial0;
> + serial1 = &serial1;
> + pci0 = &pci0;
> + pci1 = &pci1;
> + };
> +
> cpus {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -107,7 +118,7 @@
> };
> };
>
> - [EMAIL PROTECTED] {
> + enet0: [EMAIL PROTECTED] {
> #address-cells = <1>;
> #size-cells = <0>;
> device_type = "network";
This is probably a dumb question but I'll ask it anyway.
What's the point of 'aliases' when you already have labels?
E.g., why not just use enet0 instead of making an ethernet0 alias?
Mark
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/7] powerpc: Replace ppc_md.power_off with pm_power_off
On Tue, Dec 04, 2007 at 01:05:46PM -0700, Grant Likely wrote: > On 12/4/07, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > > > On Tue, 2007-12-04 at 11:01 -0700, Mark A. Greer wrote: > > > On Tue, Dec 04, 2007 at 06:23:09PM +1100, Benjamin Herrenschmidt wrote: > > > > > > > > On Mon, 2007-12-03 at 22:48 -0700, Mark A. Greer wrote: > > > > > From: Mark A. Greer <[EMAIL PROTECTED]> > > > > > > > > > > The ppc_md.power_off hook performs the same function that the > > > > > pm_power_off hook is supposed to. However, it is powerpc-specific > > > > > and prevents kernel drivers (e.g., IPMI) from changing how a platform > > > > > is powered off. So, get rid of ppc_md.power_off and replace it with > > > > > pm_power_off. > > > > > > > > I'm less happy with that one... probably aesthetics :-) > > > > > > > > Can't we just have the generic code call pm_power_off and ppc_md and > > > > which ever powers the machine off wins ? > > > > > > Yes, that would be easy to do. Seems like duplication though. > > > If you are sure you're okay with the duplication, I'll do that. > > > > Let's ask Paulus what he thinks. > > We could simply have the setup code copy the ppc_md.power_off pointer > into pm_power_off; that we retain the nice assignment in > define_machine(), but eliminate the duplicated calls. Hmm, yeah, that would look nice--nicer than what I have. The only issue I have with it is that we still have duplication and potential for reassigning the wrong one (e.g., reassigning ppc_md.power_off instead of pm_power_off in maple/setup.c:maple_use_rtas_reboot_and_halt_if_present()). We could call both in machine_power_off but that's messy too (IMHO). Paul, do you have an opinion? Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/7] powerpc: Replace ppc_md.power_off with pm_power_off
On Tue, Dec 04, 2007 at 06:23:09PM +1100, Benjamin Herrenschmidt wrote: > > On Mon, 2007-12-03 at 22:48 -0700, Mark A. Greer wrote: > > From: Mark A. Greer <[EMAIL PROTECTED]> > > > > The ppc_md.power_off hook performs the same function that the > > pm_power_off hook is supposed to. However, it is powerpc-specific > > and prevents kernel drivers (e.g., IPMI) from changing how a platform > > is powered off. So, get rid of ppc_md.power_off and replace it with > > pm_power_off. > > I'm less happy with that one... probably aesthetics :-) > > Can't we just have the generic code call pm_power_off and ppc_md and > which ever powers the machine off wins ? Yes, that would be easy to do. Seems like duplication though. If you are sure you're okay with the duplication, I'll do that. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
On Tue, Dec 04, 2007 at 08:28:57PM +0300, Andrei Dolnikov wrote: > Mark A. Greer wrote: > >On Tue, Dec 04, 2007 at 07:52:50AM +1100, Benjamin Herrenschmidt wrote: > > > >>> #address-cells = <1>; > >>>+ #size-cells = <1>; > >>>+ model = "Katana-Qp"; /* Default */ > >>>+ compatible = "emerson,Katana-Qp"; > >>>+ coherency-off; > >>>+ > >>> > >>What do that mean (coherency-off) ? > >> > >>Somebody is trying again to use a 74xx with non cache coherent DMA ? > >> > > > >Hi Ben. > > > >I suspect Andrei got that from the prpmc2800 dts which I made so I'll > >jump in. (BTW, this is the same debate we have every year or two. :) > > > >By looking at the dts, that board has an mv64460 which has a couple > >issues when it comes to coherency (depending on the rev of the chip). > > > >One is about not being able to use DCBST instructions with coherency on > >and the other is about limiting the length of one of the traces (which > >at least one board manufacturer that I know of refuses to implement). > >The first one is supposed to be fixed by rev A1 of the part and the second > >is supposed to be fixed by rev B0 of the part. I don't know what rev(s) > >are on the board(s) Andrei is using. If its B0 or later, in theory, the > >part should work with coherency on. > > > >Andrei, have you tested with coherency on? > > > Yes, I tested it with "coherency on", but it didn't work. > > I checked chip revisions on all boards I have and they all are >= > mv64_4_60 B0. FWIW, this is consistent with what I see. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 7/7] powerpc: Remove incorrect panic() calls
From: Mark A. Greer <[EMAIL PROTECTED]>
Platform-specific restart routines should not call panic() when they
fail. Instead, they should return so the caller (machine_restart())
can halt the system more gracefully.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/82xx/pq2.c |2 --
arch/powerpc/platforms/8xx/m8xx_setup.c|1 -
arch/powerpc/platforms/embedded6xx/prpmc2800.c |1 -
3 files changed, 4 deletions(-)
diff --git a/arch/powerpc/platforms/82xx/pq2.c
b/arch/powerpc/platforms/82xx/pq2.c
index a497cba..16cd460 100644
--- a/arch/powerpc/platforms/82xx/pq2.c
+++ b/arch/powerpc/platforms/82xx/pq2.c
@@ -31,8 +31,6 @@ void pq2_restart(char *cmd)
/* Clear the ME,EE,IR & DR bits in MSR to cause checkstop */
mtmsr(mfmsr() & ~(MSR_ME | MSR_EE | MSR_IR | MSR_DR));
in_8(&cpm2_immr->im_clkrst.res[0]);
-
- panic("Restart failed\n");
}
#ifdef CONFIG_PCI
diff --git a/arch/powerpc/platforms/8xx/m8xx_setup.c
b/arch/powerpc/platforms/8xx/m8xx_setup.c
index d35eda8..1014310 100644
--- a/arch/powerpc/platforms/8xx/m8xx_setup.c
+++ b/arch/powerpc/platforms/8xx/m8xx_setup.c
@@ -221,7 +221,6 @@ void mpc8xx_restart(char *cmd)
mtmsr(mfmsr() & ~0x1000);
in_8(&clk_r->res[0]);
- panic("Restart failed\n");
}
static void cpm_cascade(unsigned int irq, struct irq_desc *desc)
diff --git a/arch/powerpc/platforms/embedded6xx/prpmc2800.c
b/arch/powerpc/platforms/embedded6xx/prpmc2800.c
index 653a5eb..fe5920c 100644
--- a/arch/powerpc/platforms/embedded6xx/prpmc2800.c
+++ b/arch/powerpc/platforms/embedded6xx/prpmc2800.c
@@ -108,7 +108,6 @@ static void prpmc2800_restart(char *cmd)
prpmc2800_reset_board();
while (i-- > 0);
- panic("restart failed\n");
}
#ifdef CONFIG_NOT_COHERENT_CACHE
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 6/7] powerpc: Remove redundant power_off and halt routines
From: Mark A. Greer <[EMAIL PROTECTED]>
Remove platform-specific power_off and halt routines, and ppc_md
initializations that are not necessary.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/embedded6xx/holly.c| 12
arch/powerpc/platforms/embedded6xx/linkstation.c |7 ---
arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c | 11 ---
arch/powerpc/platforms/iseries/setup.c|1 -
arch/powerpc/platforms/maple/setup.c |6 --
arch/powerpc/platforms/powermac/setup.c |7 ---
6 files changed, 44 deletions(-)
diff --git a/arch/powerpc/platforms/embedded6xx/holly.c
b/arch/powerpc/platforms/embedded6xx/holly.c
index b6de2b5..70cfd37 100644
--- a/arch/powerpc/platforms/embedded6xx/holly.c
+++ b/arch/powerpc/platforms/embedded6xx/holly.c
@@ -253,18 +253,6 @@ void holly_restart(char *cmd)
for (;;) ;
}
-void holly_power_off(void)
-{
- local_irq_disable();
- /* No way to shut power off with software */
- for (;;) ;
-}
-
-void holly_halt(void)
-{
- holly_power_off();
-}
-
/*
* Called very early, device-tree isn't unflattened
*/
diff --git a/arch/powerpc/platforms/embedded6xx/linkstation.c
b/arch/powerpc/platforms/embedded6xx/linkstation.c
index 8792840..3382eef 100644
--- a/arch/powerpc/platforms/embedded6xx/linkstation.c
+++ b/arch/powerpc/platforms/embedded6xx/linkstation.c
@@ -162,12 +162,6 @@ static void linkstation_power_off(void)
/* NOTREACHED */
}
-static void linkstation_halt(void)
-{
- linkstation_power_off();
- /* NOTREACHED */
-}
-
static void linkstation_show_cpuinfo(struct seq_file *m)
{
seq_printf(m, "vendor\t\t: Buffalo Technology\n");
@@ -195,6 +189,5 @@ define_machine(linkstation){
.show_cpuinfo = linkstation_show_cpuinfo,
.get_irq= mpic_get_irq,
.restart= linkstation_restart,
- .halt = linkstation_halt,
.calibrate_decr = generic_calibrate_decr,
};
diff --git a/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
b/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
index a2c04b9..557a6fe 100644
--- a/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
+++ b/arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c
@@ -179,17 +179,6 @@ void mpc7448_hpc2_restart(char *cmd)
for (;;) ; /* Spin until reset happens */
}
-void mpc7448_hpc2_power_off(void)
-{
- local_irq_disable();
- for (;;) ; /* No way to shut power off with software */
-}
-
-void mpc7448_hpc2_halt(void)
-{
- mpc7448_hpc2_power_off();
-}
-
/*
* Called very early, device-tree isn't unflattened
*/
diff --git a/arch/powerpc/platforms/iseries/setup.c
b/arch/powerpc/platforms/iseries/setup.c
index 362084e..0eabbc3 100644
--- a/arch/powerpc/platforms/iseries/setup.c
+++ b/arch/powerpc/platforms/iseries/setup.c
@@ -650,7 +650,6 @@ define_machine(iseries) {
.init_early = iSeries_init_early,
.pcibios_fixup = iSeries_pci_final_fixup,
.restart= mf_reboot,
- .halt = mf_power_off,
.get_boot_time = iSeries_get_boot_time,
.set_rtc_time = iSeries_set_rtc_time,
.get_rtc_time = iSeries_get_rtc_time,
diff --git a/arch/powerpc/platforms/maple/setup.c
b/arch/powerpc/platforms/maple/setup.c
index d0eb901..ac5f99a 100644
--- a/arch/powerpc/platforms/maple/setup.c
+++ b/arch/powerpc/platforms/maple/setup.c
@@ -151,11 +151,6 @@ static void maple_power_off(void)
printk(KERN_EMERG "Maple: Manual Power-Down Required\n");
}
-static void maple_halt(void)
-{
- maple_power_off();
-}
-
#ifdef CONFIG_SMP
struct smp_ops_t maple_smp_ops = {
.probe = smp_mpic_probe,
@@ -329,7 +324,6 @@ define_machine(maple_md) {
.pci_irq_fixup = maple_pci_irq_fixup,
.pci_get_legacy_ide_irq = maple_pci_get_legacy_ide_irq,
.restart= maple_restart,
- .halt = maple_halt,
.get_boot_time = maple_get_boot_time,
.set_rtc_time = maple_set_rtc_time,
.get_rtc_time = maple_get_rtc_time,
diff --git a/arch/powerpc/platforms/powermac/setup.c
b/arch/powerpc/platforms/powermac/setup.c
index 8429002..002b0b4 100644
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
@@ -499,12 +499,6 @@ static void pmac_power_off(void)
}
}
-static void
-pmac_halt(void)
-{
- pmac_power_off();
-}
-
/*
* Early initialization.
*/
@@ -677,7 +671,6 @@ define_machine(powermac) {
.get_irq= NULL, /* changed later */
.pci_irq_fixup = pmac_pci_irq_fixup,
.restart= pmac_restart,
- .halt = pmac_halt,
.time_init
[PATCH 5/7] powerpc: Replace ppc_md.power_off with pm_power_off
From: Mark A. Greer <[EMAIL PROTECTED]>
The ppc_md.power_off hook performs the same function that the
pm_power_off hook is supposed to. However, it is powerpc-specific
and prevents kernel drivers (e.g., IPMI) from changing how a platform
is powered off. So, get rid of ppc_md.power_off and replace it with
pm_power_off.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/setup-common.c | 14 +--
arch/powerpc/platforms/52xx/efika.c |2
arch/powerpc/platforms/cell/setup.c |2
arch/powerpc/platforms/celleb/setup.c|2
arch/powerpc/platforms/chrp/setup.c |2
arch/powerpc/platforms/embedded6xx/linkstation.c |3
arch/powerpc/platforms/iseries/setup.c |2
arch/powerpc/platforms/maple/setup.c |4
arch/powerpc/platforms/powermac/setup.c |2
arch/powerpc/platforms/ps3/setup.c |2
arch/powerpc/platforms/pseries/setup.c | 59 ++---
include/asm-powerpc/machdep.h|1
12 files changed, 48 insertions(+), 47 deletions(-)
diff --git a/arch/powerpc/kernel/setup-common.c
b/arch/powerpc/kernel/setup-common.c
index 1f8f9aa..d9f2e07 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -76,6 +76,9 @@ EXPORT_SYMBOL(ppc_md);
struct machdep_calls *machine_id;
EXPORT_SYMBOL(machine_id);
+void (*pm_power_off)(void);
+EXPORT_SYMBOL_GPL(pm_power_off);
+
unsigned long klimit = (unsigned long) _end;
char cmd_line[COMMAND_LINE_SIZE];
@@ -127,8 +130,8 @@ void machine_restart(char *cmd)
void machine_power_off(void)
{
machine_shutdown();
- if (ppc_md.power_off)
- ppc_md.power_off();
+ if (pm_power_off)
+ pm_power_off();
printk(KERN_EMERG "System not powered off; halting instead.\n");
if (ppc_md.halt)
ppc_md.halt();
@@ -137,17 +140,14 @@ void machine_power_off(void)
/* Used by the G5 thermal driver */
EXPORT_SYMBOL_GPL(machine_power_off);
-void (*pm_power_off)(void) = machine_power_off;
-EXPORT_SYMBOL_GPL(pm_power_off);
-
void machine_halt(void)
{
machine_shutdown();
if (ppc_md.halt)
ppc_md.halt();
- if (ppc_md.power_off) {
+ if (pm_power_off) {
printk(KERN_EMERG "System not halted; powering off instead.\n");
- ppc_md.power_off();
+ pm_power_off();
printk(KERN_EMERG "Poweroff failed.\n");
}
default_halt("OK to turn off power\n");
diff --git a/arch/powerpc/platforms/52xx/efika.c
b/arch/powerpc/platforms/52xx/efika.c
index a0da70c..c2d5f06 100644
--- a/arch/powerpc/platforms/52xx/efika.c
+++ b/arch/powerpc/platforms/52xx/efika.c
@@ -205,6 +205,7 @@ static int __init efika_probe(void)
DMA_MODE_READ = 0x44;
DMA_MODE_WRITE = 0x48;
+ pm_power_off = rtas_power_off;
return 1;
}
@@ -218,7 +219,6 @@ define_machine(efika)
.init_IRQ = mpc52xx_init_irq,
.get_irq= mpc52xx_get_irq,
.restart= rtas_restart,
- .power_off = rtas_power_off,
.halt = rtas_halt,
.set_rtc_time = rtas_set_rtc_time,
.get_rtc_time = rtas_get_rtc_time,
diff --git a/arch/powerpc/platforms/cell/setup.c
b/arch/powerpc/platforms/cell/setup.c
index 98e7ef8..06f44f5 100644
--- a/arch/powerpc/platforms/cell/setup.c
+++ b/arch/powerpc/platforms/cell/setup.c
@@ -191,6 +191,7 @@ static int __init cell_probe(void)
return 0;
hpte_init_native();
+ pm_power_off = rtas_power_off;
return 1;
}
@@ -201,7 +202,6 @@ define_machine(cell) {
.setup_arch = cell_setup_arch,
.show_cpuinfo = cell_show_cpuinfo,
.restart= rtas_restart,
- .power_off = rtas_power_off,
.halt = rtas_halt,
.get_boot_time = rtas_get_boot_time,
.get_rtc_time = rtas_get_rtc_time,
diff --git a/arch/powerpc/platforms/celleb/setup.c
b/arch/powerpc/platforms/celleb/setup.c
index ddfb35a..450841a 100644
--- a/arch/powerpc/platforms/celleb/setup.c
+++ b/arch/powerpc/platforms/celleb/setup.c
@@ -116,6 +116,7 @@ static int __init celleb_probe(void)
powerpc_firmware_features |= FW_FEATURE_CELLEB_POSSIBLE;
hpte_init_beat_v3();
+ pm_power_off = beat_power_off;
return 1;
}
@@ -145,7 +146,6 @@ define_machine(celleb) {
.setup_arch = celleb_setup_arch,
.show_cpuinfo = celleb_show_cpuinfo,
.restart= beat_restart,
- .power_off = beat_power_off,
.halt = beat_halt,
.get_rtc_time = beat_get_rtc_time,
.se
[PATCH 4/7] powerpc: Rework the machine_[restart|power_off|halt] routines
From: Mark A. Greer <[EMAIL PROTECTED]>
Factor out common code from the machine_xxx routines and make them better
handle a ppc_md hook that doesn't exist or fails better. In particular,
have machine_power_off() try ppc_md.halt if ppc_md.power_off is NULL or fails,
and have machine_halt() try to power off when ppc_md.halt is NULL or fails.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/setup-common.c | 40 ++-
1 file changed, 22 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/kernel/setup-common.c
b/arch/powerpc/kernel/setup-common.c
index 6adb5a1..1f8f9aa 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -105,17 +105,23 @@ void machine_shutdown(void)
ppc_md.machine_shutdown();
}
-void machine_restart(char *cmd)
+static void default_halt(const char *s)
{
- machine_shutdown();
- if (ppc_md.restart)
- ppc_md.restart(cmd);
#ifdef CONFIG_SMP
smp_send_stop();
#endif
- printk(KERN_EMERG "System Halted, OK to turn off power\n");
+ printk(KERN_EMERG "%s", s);
local_irq_disable();
- while (1) ;
+ while (1);
+}
+
+void machine_restart(char *cmd)
+{
+ machine_shutdown();
+ if (ppc_md.restart)
+ ppc_md.restart(cmd);
+ default_halt("System not restarted; halting instead.\n"
+ "OK to turn off power\n");
}
void machine_power_off(void)
@@ -123,12 +129,10 @@ void machine_power_off(void)
machine_shutdown();
if (ppc_md.power_off)
ppc_md.power_off();
-#ifdef CONFIG_SMP
- smp_send_stop();
-#endif
- printk(KERN_EMERG "System Halted, OK to turn off power\n");
- local_irq_disable();
- while (1) ;
+ printk(KERN_EMERG "System not powered off; halting instead.\n");
+ if (ppc_md.halt)
+ ppc_md.halt();
+ default_halt("OK to turn off power\n");
}
/* Used by the G5 thermal driver */
EXPORT_SYMBOL_GPL(machine_power_off);
@@ -141,12 +145,12 @@ void machine_halt(void)
machine_shutdown();
if (ppc_md.halt)
ppc_md.halt();
-#ifdef CONFIG_SMP
- smp_send_stop();
-#endif
- printk(KERN_EMERG "System Halted, OK to turn off power\n");
- local_irq_disable();
- while (1) ;
+ if (ppc_md.power_off) {
+ printk(KERN_EMERG "System not halted; powering off instead.\n");
+ ppc_md.power_off();
+ printk(KERN_EMERG "Poweroff failed.\n");
+ }
+ default_halt("OK to turn off power\n");
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/7] powerpc: ras.c should call machine_power_off()
From: Mark A. Greer <[EMAIL PROTECTED]>
machine_power_off() is the proper interface to use for powering
off a machine.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/pseries/ras.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/ras.c
b/arch/powerpc/platforms/pseries/ras.c
index a1ab25c..64564b2 100644
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -242,7 +242,7 @@ static irqreturn_t ras_error_interrupt(int irq, void
*dev_id)
* without actually failing while injecting errors.
* Error data will not be logged to syslog.
*/
- ppc_md.power_off();
+ machine_power_off();
#endif
} else {
udbg_printf("Recoverable HW Error <0x%lx 0x%x>\n",
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/7] powerpc: xmon should call machine_xxx not ppc_md.xxx directly
From: Mark A. Greer <[EMAIL PROTECTED]> xmon should call machine_[restart|halt|power_off] instead of ppc_md.[restart|halt|power_off]. Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]> --- I'm not sure about this one. Does anyone see a problem with this? arch/powerpc/xmon/xmon.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c index 121b04d..56267e3 100644 --- a/arch/powerpc/xmon/xmon.c +++ b/arch/powerpc/xmon/xmon.c @@ -908,11 +908,11 @@ static void bootcmds(void) cmd = inchar(); if (cmd == 'r') - ppc_md.restart(NULL); + machine_restart(); else if (cmd == 'h') - ppc_md.halt(); + machine_halt(); else if (cmd == 'p') - ppc_md.power_off(); + machine_power_off(); } static int cpu_cmd(void) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/7] powerpc: Drivers should call machine_power_off not pm_power_off
From: Mark A. Greer <[EMAIL PROTECTED]>
Drivers should call machine_power_off() not pm_power_off to power off
a machine.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
drivers/parisc/power.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/parisc/power.c b/drivers/parisc/power.c
index 90cca5e..188a1ac 100644
--- a/drivers/parisc/power.c
+++ b/drivers/parisc/power.c
@@ -93,11 +93,9 @@ static void process_shutdown(void)
lcd_print(msg);
/* send kill signal */
- if (kill_cad_pid(SIGINT, 1)) {
+ if (kill_cad_pid(SIGINT, 1))
/* just in case killing init process failed */
- if (pm_power_off)
- pm_power_off();
- }
+ machine_power_off();
}
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC 0/7] powerpc: Rework pm_power_off & machine_[restart|power_off|halt]
We seem to have the pm_power_off hook wrong in arch/powerpc. From the other arches and from how its used by the rest of the kernel (e.g., ipmi), it should point to the lowest-level power off function not to machine_power_off(). Actually, machine_power_off() should call pm_power_off since AFAICT it is the one and only interface used by the rest of the kernel to power a machine off (with one exception which I believe to be a bug and have a patch in this series to fix). While looking at this, I found several bits of code that needed minor rework and/or cleaning up. These bits include: refactoring some common code used by the machine_xxx routines, having machine_power_off call ppc_md.halt if there ppc_md.power_off is NULL or returns, having machine_halt call ppc_md.power_off it ppc_md.halt is NULL or returns, and removing some useless xxx_halt and xxx_power_off routines in platform code. With the new usage of pm_power_off, the ppc_md.power_off hook is no longer needed and pm_power_off will be assigned in the platform probe routine. The end result of all of these patches should make the check of pm_power_off being NULL in kernel/sys.c:sys_reboot useful for powerpc, eliminate the need for platform halt routines to call the power off routine (and vice versa), allow things like IPMI to take over pm_power_off when they need to, and make the power off/halt related code a bit cleaner & consistent. I still have to make sure I didn't miss anything and I haven't compiled all the files I've touched so these aren't submission candidates yet. I'd appreciate any feedback. Thanks, Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
On Tue, Dec 04, 2007 at 01:14:43PM +1100, Benjamin Herrenschmidt wrote: > > .../... (snip scary bunch of errata) > > > - "FEr PCI-#4" (Detailed by Application Note AN-84): > > > > [This isn't strictly a coherency issue but having coherency enabled > > exacerbates the problem.] Basically, the bridge can let the cpu read > > a pci device's registers before all of the data the PCI devices has > > written has actually made it to memory. This and the fact that the > > device's write data may be stuck in the PCI Slave Write Buffer > > (which isn't checked for coherency), the cpu can get stale data. > > > > There are no plans to fix that erratum. > > So if I understand correctly, there's no plan to fix a major PCI spec > violation which prevent any kind of reliable implementation whatsoever ? That's just for that particular part (e.g., 64360). Newer parts like the 64460 have it fixed. > > So, the answer depends on what part & what rev of the part you have > > (e.g., the pegasos doesn't use the MPSC and apparently has the other > > issues worked around so it can turn on coherency but the prpmc2800 > > doesn't so it needs coherency off). > > > > BTW, I haven't forgotten the inherent bug you described when coherency > > is off (/me too lazy to find link to the email) but AFAIK I've never run > > into it. However, if I turn on coherency and stress the PCI bus, it > > hangs (I can't even look at memory thru a bdi). > > Well, as it is today, the "classic" MMU code cannot deal with !coherent. > The entire linear mapping is always mapped cacheable with BATs, so stuff > may be brought into the cache at any time, potentially polluting DMA > data. > > Dealing with that would be hard. It might be possible by using G on the > entire linear mapping like we do on 4xx (yuck), and/or by not using > D-BATs (the kernel will blow up in various areas without I-BATs). Hrm, I didn't realize it was in such bad shape. I'll have to take a closer look. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
On Tue, Dec 04, 2007 at 01:50:32PM +1100, David Gibson wrote:
> On Mon, Dec 03, 2007 at 07:10:26PM -0700, Mark A. Greer wrote:
> > On Mon, Dec 03, 2007 at 12:50:18PM +1100, David Gibson wrote:
> > > On Thu, Nov 29, 2007 at 06:28:36PM +0300, Andrei Dolnikov wrote:
> > > > + eth0 {
> > > > + device_type = "network";
> > > > + compatible = "marvell,mv64x60-eth";
> > > > + block-index = <0>;
> > >
> > > This block-index thing is crap. If you really need to subindex nodes
> > > like this, use "reg", with an appropriate #address-cells in the
> > > parent, then the nodes will also get sensible unit addresses.
> >
> > So how would that work for the "PHY Address Register 0x2000", say,
> > where bits 0-4 set the device addr for PHY 0; bits 5-9 set the device
> > addr for PHY 1; bts 10-14 set the devce addr for PHY 2?
>
> So use 'reg' to do the indexing. As long as you have no 'ranges'
> property in the parent 'ethernet' node, which you don't, you can use
> 'reg' as a private index. That's basically what non-translatable reg
> values are about.
>
> Incidentally you should probably call the subnodes "[EMAIL PROTECTED]"
> etc. and the parent one "multiethernet" or something. It's the
> subnodes that represent an individual ethernet interface, so they
> should take the "ethernet" name and not the parent, by generic names
> conventions.
Okay, thanks for the advice. I'll fix the prpmc2800 dts file.
Presumably Andrei will fix his.
> [snip]
> > > > + [EMAIL PROTECTED] {
> > > > + compatible = "marvell,mv64x60-sdma";
> > > > + reg = <4000 c18>;
> > > > + virtual-reg = ;
> > >
> > > Why does this node have virtual-reg?
> >
> > "virtual-reg" is a special property that doesn't get translated thru
> > the parent mappings. It should never be used in the kernel. Its
> > purpose is to give code in the bootwrapper the exact address that it
> > should use to access a register or block of registers or ...
> > Its needed here because the MPSC (serial) driver uses the SDMA unit
> > to perform console I/O in the bootwrapper (e.g., cmdline editing, printf's).
> >
> > Yes, this needs to be documented.
>
> Ok. "it's used for serial in the bootwrapper" would have sufficed - I
> questioned it because it wasn't obvious that this was needed to use
> the mpsc.
Sorry :)
> >
> > > > + [EMAIL PROTECTED] {
> > > > + device_type = "serial";
> > > > + compatible = "marvell,mpsc";
> > > > + reg = <8000 38>;
> > > > + virtual-reg = ;
> > > > + sdma = <&/mv64x60/[EMAIL PROTECTED]>;
> > > > + brg = <&/mv64x60/[EMAIL PROTECTED]>;
> > > > + cunit = <&/mv64x60/[EMAIL PROTECTED]>;
> > > > + mpscrouting = <&/mv64x60/[EMAIL PROTECTED]>;
> > > > + mpscintr = <&/mv64x60/[EMAIL PROTECTED]>;
> > > > + block-index = <0>;
> > >
> > > What is this block-index thing about here? Since the devices are
> > > disambiguated by their register address, why do you need it?
> >
> > This particular one is needed to access the correct MPSC interrupt reg.
> > Maybe it would be better to make a new property for this but it was only
> > one reg and block-index was already there and basically served that
> > purpose so I used it. I'd be happy to use an alternative if you have
> > something you think is better.
>
> No, that's an acceptable use for something like this, except that
> "cell-index" seems to be the name we've standardised on for other
> similar cases.
Yeah, I realize that but block-index was here first!
More seriously, I don't like "cell" because it isn't a cell, its a
block or an instance or an...I dunno but its not a cell IMHO.
Anyway, I'll think about changing it to cell but I already feel
dirty just thinking about it.
Mark
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/5] PowerPC 74xx: Katana Qp base support
On Tue, Dec 04, 2007 at 07:54:59AM +1100, Benjamin Herrenschmidt wrote: > > On Thu, 2007-11-29 at 18:42 +0300, Andrei Dolnikov wrote: > > +config PPC_KATANAQP > > + bool "Emerson-Katana Qp" > > + depends on EMBEDDED6xx > > + select MV64X60 > > + select NOT_COHERENT_CACHE > ^^ > > Just one word: ARG ! > > Oh and another one: WHY ? I responded to your other email regarding this. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
On Mon, Dec 03, 2007 at 12:50:18PM +1100, David Gibson wrote:
> On Thu, Nov 29, 2007 at 06:28:36PM +0300, Andrei Dolnikov wrote:
> > Device tree source file for the Emerson Katana Qp board
> >
> > Signed-off-by: Andrei Dolnikov <[EMAIL PROTECTED]>
> >
> > ---
> > katanaqp.dts | 360
> > +++
> > 1 files changed, 360 insertions(+)
> >
> > diff --git a/arch/powerpc/boot/dts/katanaqp.dts
> > b/arch/powerpc/boot/dts/katanaqp.dts
> > new file mode 100644
> > index 000..98257a2
> > --- /dev/null
> > +++ b/arch/powerpc/boot/dts/katanaqp.dts
> > @@ -0,0 +1,360 @@
> > +/* Device Tree Source for Emerson Katana Qp
> > + *
> > + * Authors: Vladislav Buzov <[EMAIL PROTECTED]>
> > + * Andrei Dolnikov <[EMAIL PROTECTED]>
> > + *
> > + * Based on prpmc8200.dts by Mark A. Greer <[EMAIL PROTECTED]>
> > + *
> > + * 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.
> > + *
> > + */
> > +
> > +/ {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + model = "Katana-Qp"; /* Default */
> > + compatible = "emerson,Katana-Qp";
> > + coherency-off;
>
> What is this property for?
Its needed to tell the bootwrapper that the platform does not have
coherency enabled (since our policy is that you can't use a CONFIG_ option).
The bootwrapper needs to know that if/when it sets up the windows for
its I/O devices (e.g., enet, mpsc) to system memory. I needed to do
this on the prpmc2800 because the firmware didn't set up those windows
correctly. I don't know if the Katana Qp's firmware sets the up
correctly or not.
> > + [EMAIL PROTECTED] { /* Marvell Discovery */
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + model = "mv64460"; /* Default */
> > + compatible = "marvell,mv64x60";
>
> Compatible properties should not have "x" asn in 64x60 here. If
> there's a suitable name for the general register interface use that,
> otherwise use the specific model number of the earliest device to
> implement this register interface. Later models should have a
> compatible property which lists their specific model, followed by the
> earlier model number with which they're compatible.
This came from the prpmc2800's dts which has become out-of-date.
Both dts files need to be updated.
> > + [EMAIL PROTECTED] {
> > + reg = <2000 2000>;
>
> Are the registers for the 3 ethernets really all together? This bank
> can't be subdivided into seperate register blocks for each MAC?
Unfortunately there are some registers that are shared so you can't
divide them up nicely.
> > + eth0 {
> > + device_type = "network";
> > + compatible = "marvell,mv64x60-eth";
> > + block-index = <0>;
>
> This block-index thing is crap. If you really need to subindex nodes
> like this, use "reg", with an appropriate #address-cells in the
> parent, then the nodes will also get sensible unit addresses.
So how would that work for the "PHY Address Register 0x2000", say,
where bits 0-4 set the device addr for PHY 0; bits 5-9 set the device
addr for PHY 1; bts 10-14 set the devce addr for PHY 2?
> > + interrupts = <20>;
> > + interrupt-parent = <&/mv64x60/pic>;
>
> You should use a label for the PIC to make things more readable.
More that needs to be updated in prpmc2800. :(
> > + [EMAIL PROTECTED] {
> > + compatible = "marvell,mv64x60-sdma";
> > + reg = <4000 c18>;
> > + virtual-reg = ;
>
> Why does this node have virtual-reg?
"virtual-reg" is a special property that doesn't get translated thru
the parent mappings. It should never be used in the kernel. Its
purpose is to give code in the bootwrapper the exact address that it
should use to access a register or block of registers or ...
Its needed here because the MPSC (serial) driver uses the SDMA unit
to perform console I/O in the bootwrapper (e.g., cmdline editing, printf's).
Yes, this needs to be documented.
Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
On Tue, Dec 04, 2007 at 07:52:50AM +1100, Benjamin Herrenschmidt wrote: > > #address-cells = <1>; > > + #size-cells = <1>; > > + model = "Katana-Qp"; /* Default */ > > + compatible = "emerson,Katana-Qp"; > > + coherency-off; > > + > > What do that mean (coherency-off) ? > > Somebody is trying again to use a 74xx with non cache coherent DMA ? Hi Ben. I suspect Andrei got that from the prpmc2800 dts which I made so I'll jump in. (BTW, this is the same debate we have every year or two. :) By looking at the dts, that board has an mv64460 which has a couple issues when it comes to coherency (depending on the rev of the chip). One is about not being able to use DCBST instructions with coherency on and the other is about limiting the length of one of the traces (which at least one board manufacturer that I know of refuses to implement). The first one is supposed to be fixed by rev A1 of the part and the second is supposed to be fixed by rev B0 of the part. I don't know what rev(s) are on the board(s) Andrei is using. If its B0 or later, in theory, the part should work with coherency on. Andrei, have you tested with coherency on? -- As far as the prpmc2800 (mv64360)... [I don't know what an NDA let's me say or not so I'll just give summaries of the errata. If you or another reader has signed the NDA you/they can look them up.] I don't recall all of the details anymore but these are the errata I saw by quickly scanning the 64360's list. - "FEr CPU-#1": Basically the CPU could read a stale cache line. Supposed to be fixed in rev A2 & B0 but I haven't verified. - "FEr MPSC-#1": The MPSC can't access a coherent memory region. This is pretty much a show stopper for the prpmc2800. There are no plans to fix that erratum. - "FEr PCI-#4" (Detailed by Application Note AN-84): [This isn't strictly a coherency issue but having coherency enabled exacerbates the problem.] Basically, the bridge can let the cpu read a pci device's registers before all of the data the PCI devices has written has actually made it to memory. This and the fact that the device's write data may be stuck in the PCI Slave Write Buffer (which isn't checked for coherency), the cpu can get stale data. There are no plans to fix that erratum. - "FEr PCI-#5" (Detailed by Application Note AN-85): With certain PCI devices and with coherency enabled, some combinations of PCI transactions can cause a deadlock. There is a workaround documented but I've tried it and it didn't work for me (but I can't be sure that was the erratum I was bumping into). There are no plans to fix that erratum. -- So, the answer depends on what part & what rev of the part you have (e.g., the pegasos doesn't use the MPSC and apparently has the other issues worked around so it can turn on coherency but the prpmc2800 doesn't so it needs coherency off). BTW, I haven't forgotten the inherent bug you described when coherency is off (/me too lazy to find link to the email) but AFAIK I've never run into it. However, if I turn on coherency and stress the PCI bus, it hangs (I can't even look at memory thru a bdi). Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: prpmc2800 - Enable L2 cache
From: Mark A. Greer <[EMAIL PROTECTED]> Turn on the L2 cache on the prpmc2800 platform. Signed-off-by: Mark A. Greer <[EMAIL PROTECTED] --- arch/powerpc/platforms/embedded6xx/prpmc2800.c |1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/platforms/embedded6xx/prpmc2800.c b/arch/powerpc/platforms/embedded6xx/prpmc2800.c index e484cac..653a5eb 100644 --- a/arch/powerpc/platforms/embedded6xx/prpmc2800.c +++ b/arch/powerpc/platforms/embedded6xx/prpmc2800.c @@ -144,6 +144,7 @@ static int __init prpmc2800_probe(void) strncpy(prpmc2800_platform_name, m, min((int)len, PLATFORM_NAME_MAX - 1)); + _set_L2CR(_get_L2CR() | L2CR_L2E); return 1; } ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/3] powerpc: mv64x60 - Aesthetic fixups for bootwrapper code
From: Mark A. Greer <[EMAIL PROTECTED]>
Specify locations when initializing arrays. This has already been done
for one array so may as well do it for them all.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
I don't know if this one is worth the bother (it is a little anal)
but it keeps things consistent. I'm happy with or without it.
arch/powerpc/boot/mv64x60.c | 72 +-
1 file changed, 36 insertions(+), 36 deletions(-)
diff --git a/arch/powerpc/boot/mv64x60.c b/arch/powerpc/boot/mv64x60.c
index c3f..d207a0b 100644
--- a/arch/powerpc/boot/mv64x60.c
+++ b/arch/powerpc/boot/mv64x60.c
@@ -174,11 +174,11 @@ struct {
u32 addr;
u32 data;
} static mv64x60_pci_cfgio[2] = {
- { /* hose 0 */
+ [0] = { /* hose 0 */
.addr = 0xcf8,
.data = 0xcfc,
},
- { /* hose 1 */
+ [1] = { /* hose 1 */
.addr = 0xc78,
.data = 0xc7c,
}
@@ -201,76 +201,76 @@ void mv64x60_cfg_write(u8 *bridge_base, u8 hose, u8 bus,
u8 devfn, u8 offset,
/* I/O ctlr -> system memory setup */
static struct mv64x60_mem_win mv64x60_cpu2mem[MV64x60_CPU2MEM_WINDOWS] = {
- {
+ [0] = {
.lo = MV64x60_CPU2MEM_0_BASE,
.size = MV64x60_CPU2MEM_0_SIZE,
},
- {
+ [1] = {
.lo = MV64x60_CPU2MEM_1_BASE,
.size = MV64x60_CPU2MEM_1_SIZE,
},
- {
+ [2] = {
.lo = MV64x60_CPU2MEM_2_BASE,
.size = MV64x60_CPU2MEM_2_SIZE,
},
- {
+ [3] = {
.lo = MV64x60_CPU2MEM_3_BASE,
.size = MV64x60_CPU2MEM_3_SIZE,
},
};
static struct mv64x60_mem_win mv64x60_enet2mem[MV64x60_CPU2MEM_WINDOWS] = {
- {
+ [0] = {
.lo = MV64x60_ENET2MEM_0_BASE,
.size = MV64x60_ENET2MEM_0_SIZE,
},
- {
+ [1] = {
.lo = MV64x60_ENET2MEM_1_BASE,
.size = MV64x60_ENET2MEM_1_SIZE,
},
- {
+ [2] = {
.lo = MV64x60_ENET2MEM_2_BASE,
.size = MV64x60_ENET2MEM_2_SIZE,
},
- {
+ [3] = {
.lo = MV64x60_ENET2MEM_3_BASE,
.size = MV64x60_ENET2MEM_3_SIZE,
},
};
static struct mv64x60_mem_win mv64x60_mpsc2mem[MV64x60_CPU2MEM_WINDOWS] = {
- {
+ [0] = {
.lo = MV64x60_MPSC2MEM_0_BASE,
.size = MV64x60_MPSC2MEM_0_SIZE,
},
- {
+ [1] = {
.lo = MV64x60_MPSC2MEM_1_BASE,
.size = MV64x60_MPSC2MEM_1_SIZE,
},
- {
+ [2] = {
.lo = MV64x60_MPSC2MEM_2_BASE,
.size = MV64x60_MPSC2MEM_2_SIZE,
},
- {
+ [3] = {
.lo = MV64x60_MPSC2MEM_3_BASE,
.size = MV64x60_MPSC2MEM_3_SIZE,
},
};
static struct mv64x60_mem_win mv64x60_idma2mem[MV64x60_CPU2MEM_WINDOWS] = {
- {
+ [0] = {
.lo = MV64x60_IDMA2MEM_0_BASE,
.size = MV64x60_IDMA2MEM_0_SIZE,
},
- {
+ [1] = {
.lo = MV64x60_IDMA2MEM_1_BASE,
.size = MV64x60_IDMA2MEM_1_SIZE,
},
- {
+ [2] = {
.lo = MV64x60_IDMA2MEM_2_BASE,
.size = MV64x60_IDMA2MEM_2_SIZE,
},
- {
+ [3] = {
.lo = MV64x60_IDMA2MEM_3_BASE,
.size = MV64x60_IDMA2MEM_3_SIZE,
},
@@ -338,7 +338,7 @@ void mv64x60_config_ctlr_windows(u8 *bridge_base, u8
*bridge_pbase,
/* PCI MEM -> system memory, et. al. setup */
static struct mv64x60_pci_win mv64x60_pci2mem[2][MV64x60_CPU2MEM_WINDOWS] = {
- { /* hose 0 */
+ [0] = { /* hose 0 */
[0] = {
.fcn= 0,
.hi = 0x14,
@@ -364,7 +364,7 @@ static struct mv64x60_pci_win
mv64x60_pci2mem[2][MV64x60_CPU2MEM_WINDOWS] = {
.size = MV64x60_PCI02MEM_3_SIZE,
},
},
- { /* hose 1 */
+ [1] = { /* hose 1 */
[0] = {
.fcn= 0,
.hi = 0x94,
@@ -394,45 +394,45 @@ static struct mv64x60_pci_win
mv64x60_pci2mem[2][MV64x60_CPU2MEM_WINDOWS] = {
static struct
mv64x60_mem_win mv64x60_pci_acc[2][MV64x60_PCI_ACC_CNTL_WINDOWS] = {
- { /* hose 0 */
- {
+ [0] = { /* hose 0 */
+ [0] = {
.hi = MV64x60_PCI0_ACC_CNTL_0_BASE_HI,
.lo = MV64x60_PCI0_ACC_CNTL_0_BASE_LO,
.size = MV64x60_PCI0_ACC_CNTL_0_SIZE,
},
- {
+ [1] = {
[PATCH 2/3] powerpc: prpmc2800 - Use new mv64x60_config_pci_windows() interface
From: Mark A. Greer <[EMAIL PROTECTED]>
Make the prpmc2800 bootwrapper code use the new interface to
mv64x60_config_pci_windows(). With that change, some minor code
rearrangement is possible to make things neater.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/prpmc2800.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/boot/prpmc2800.c b/arch/powerpc/boot/prpmc2800.c
index 9614e1d..d72400d 100644
--- a/arch/powerpc/boot/prpmc2800.c
+++ b/arch/powerpc/boot/prpmc2800.c
@@ -315,7 +315,7 @@ static struct prpmc2800_board_info *prpmc2800_get_bip(void)
return bip;
}
-static void prpmc2800_bridge_setup(u32 mem_size)
+static void prpmc2800_bridge_setup(void)
{
u32 i, v[12], enables, acc_bits;
u32 pci_base_hi, pci_base_lo, size, buf[2];
@@ -340,8 +340,7 @@ static void prpmc2800_bridge_setup(u32 mem_size)
| MV64x60_PCI_ACC_CNTL_RDSIZE_256_BYTES;
mv64x60_config_ctlr_windows(bridge_base, bridge_pbase, is_coherent);
- mv64x60_config_pci_windows(bridge_base, bridge_pbase, 0, 0, mem_size,
- acc_bits);
+ mv64x60_config_pci_windows(bridge_base, bridge_pbase, 0, 0, acc_bits);
/* Get the cpu -> pci i/o & mem mappings from the device tree */
devp = finddevice("/mv64x60/[EMAIL PROTECTED]");
@@ -397,20 +396,19 @@ static void prpmc2800_bridge_setup(u32 mem_size)
static void prpmc2800_fixups(void)
{
- u32 v[2], l, mem_size;
+ u32 v[2], l;
int rc;
void *devp;
char model[BOARD_MODEL_MAX];
struct prpmc2800_board_info *bip;
- bip = prpmc2800_get_bip(); /* Get board info based on VPD */
-
- mem_size = (bip) ? bip->mem_size : mv64x60_get_mem_size(bridge_base);
- prpmc2800_bridge_setup(mem_size); /* Do necessary bridge setup */
+ prpmc2800_bridge_setup(); /* Do necessary bridge setup */
- /* If the VPD doesn't match what we know about, just use the
+ /*
+* If the VPD doesn't match what we know about, just use the
* defaults already in the device tree.
*/
+ bip = prpmc2800_get_bip(); /* Get board info based on VPD */
if (!bip)
return;
@@ -439,8 +437,8 @@ static void prpmc2800_fixups(void)
devp = finddevice("/memory");
if (devp == NULL)
fatal("Error: Missing /memory device tree node\n\r");
- v[0] = 0;
- v[1] = bip->mem_size;
+ v[0] = 0; /* Take min of DT's mem size and what mem ctlr is setup for */
+ v[1] = min(mv64x60_get_mem_size(bridge_base), bip->mem_size);
setprop(devp, "reg", v, sizeof(v));
/* Update /mv64x60/model, if this is a mv64362 */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3] powerpc: mv64x60 - Fix PCI MEM->System Mem window setup
From: Mark A. Greer <[EMAIL PROTECTED]>
The Marvell mv64x60 line of host bridges just don't like
PCI MEM->System Memory windows setups that don't match
the CPU->System Memory window setups. For example, if there
is 1GB of System Memory and 2 CPU->System Memory windows set up
for 512MB each, then there had better be 2 PCI->System Memory
windows set up for 512MB each as well.
This restriction was documented in early versions of the bridge
but isn't supposed to apply to recent versions. It seems as though
it still applies to recent versions as well.
mv64x60_config_pci_windows() is now changed to make the windows match
as described above.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/mv64x60.c | 133 --
arch/powerpc/boot/mv64x60.h |2
2 files changed, 96 insertions(+), 39 deletions(-)
diff --git a/arch/powerpc/boot/mv64x60.c b/arch/powerpc/boot/mv64x60.c
index b432594..c3f 100644
--- a/arch/powerpc/boot/mv64x60.c
+++ b/arch/powerpc/boot/mv64x60.c
@@ -92,6 +92,9 @@
#define MV64x60_PCI0_BAR_ENABLE0x0c3c
#define MV64x60_PCI02MEM_0_SIZE0x0c08
+#define MV64x60_PCI02MEM_1_SIZE0x0d08
+#define MV64x60_PCI02MEM_2_SIZE0x0c0c
+#define MV64x60_PCI02MEM_3_SIZE0x0d0c
#define MV64x60_PCI0_ACC_CNTL_0_BASE_LO0x1e00
#define MV64x60_PCI0_ACC_CNTL_0_BASE_HI0x1e04
#define MV64x60_PCI0_ACC_CNTL_0_SIZE 0x1e08
@@ -113,6 +116,9 @@
#define MV64x60_PCI1_BAR_ENABLE0x0cbc
#define MV64x60_PCI12MEM_0_SIZE0x0c88
+#define MV64x60_PCI12MEM_1_SIZE0x0d88
+#define MV64x60_PCI12MEM_2_SIZE0x0c8c
+#define MV64x60_PCI12MEM_3_SIZE0x0d8c
#define MV64x60_PCI1_ACC_CNTL_0_BASE_LO0x1e80
#define MV64x60_PCI1_ACC_CNTL_0_BASE_HI0x1e84
#define MV64x60_PCI1_ACC_CNTL_0_SIZE 0x1e88
@@ -331,18 +337,58 @@ void mv64x60_config_ctlr_windows(u8 *bridge_base, u8
*bridge_pbase,
}
/* PCI MEM -> system memory, et. al. setup */
-static struct mv64x60_pci_win mv64x60_pci2mem[2] = {
+static struct mv64x60_pci_win mv64x60_pci2mem[2][MV64x60_CPU2MEM_WINDOWS] = {
{ /* hose 0 */
- .fcn= 0,
- .hi = 0x14,
- .lo = 0x10,
- .size = MV64x60_PCI02MEM_0_SIZE,
+ [0] = {
+ .fcn= 0,
+ .hi = 0x14,
+ .lo = 0x10,
+ .size = MV64x60_PCI02MEM_0_SIZE,
+ },
+ [1] = {
+ .fcn= 0,
+ .hi = 0x1c,
+ .lo = 0x18,
+ .size = MV64x60_PCI02MEM_1_SIZE,
+ },
+ [2] = {
+ .fcn= 1,
+ .hi = 0x14,
+ .lo = 0x10,
+ .size = MV64x60_PCI02MEM_2_SIZE,
+ },
+ [3] = {
+ .fcn= 1,
+ .hi = 0x1c,
+ .lo = 0x18,
+ .size = MV64x60_PCI02MEM_3_SIZE,
+ },
},
{ /* hose 1 */
- .fcn= 0,
- .hi = 0x94,
- .lo = 0x90,
- .size = MV64x60_PCI12MEM_0_SIZE,
+ [0] = {
+ .fcn= 0,
+ .hi = 0x94,
+ .lo = 0x90,
+ .size = MV64x60_PCI12MEM_0_SIZE,
+ },
+ [1] = {
+ .fcn= 0,
+ .hi = 0x9c,
+ .lo = 0x98,
+ .size = MV64x60_PCI12MEM_1_SIZE,
+ },
+ [2] = {
+ .fcn= 1,
+ .hi = 0x94,
+ .lo = 0x90,
+ .size = MV64x60_PCI12MEM_2_SIZE,
+ },
+ [3] = {
+ .fcn= 1,
+ .hi = 0x9c,
+ .lo = 0x98,
+ .size = MV64x60_PCI12MEM_3_SIZE,
+ },
},
};
@@ -394,70 +440,81 @@ mv64x60_mem_win
mv64x60_pci_acc[2][MV64x60_PCI_ACC_CNTL_WINDOWS] = {
},
};
-static struct mv64x60_mem_win mv64x60_pci2reg[2] = {
- {
+static struct mv64x60_pci_win mv64x60_pci2reg[2] = {
+ { /* hose 0 */
+ .fcn= 0,
.hi = 0x24,
.lo = 0x20,
.size = 0,
},
- {
+ { /* hose 1 */
+ .fcn= 0,
.hi = 0xa4,
.
Re: [PATCH] powerpc: prpmc2800 - Don't trust documented memory size
On Mon, Nov 05, 2007 at 06:28:05PM -0700, Mark A. Greer wrote: > It turns out that the firmware on some PrPMC2800 processor modules > initializes the memory controller for 512 MB even when there is more > memory. As a simple work around, set the amount of memory in the > device tree passed to the kernel to the lesser of what the memory > controller is set up for and the actual amount of memory. > > Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]> > --- Paul, please ignore this patch. There is still something wrong. Sorry for the noise. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: prpmc2800 - Don't trust documented memory size
It turns out that the firmware on some PrPMC2800 processor modules initializes the memory controller for 512 MB even when there is more memory. As a simple work around, set the amount of memory in the device tree passed to the kernel to the lesser of what the memory controller is set up for and the actual amount of memory. Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]> --- arch/powerpc/boot/prpmc2800.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/boot/prpmc2800.c b/arch/powerpc/boot/prpmc2800.c index 9614e1d..559c45e 100644 --- a/arch/powerpc/boot/prpmc2800.c +++ b/arch/powerpc/boot/prpmc2800.c @@ -405,7 +405,10 @@ static void prpmc2800_fixups(void) bip = prpmc2800_get_bip(); /* Get board info based on VPD */ - mem_size = (bip) ? bip->mem_size : mv64x60_get_mem_size(bridge_base); + mem_size = mv64x60_get_mem_size(bridge_base); + if (bip) + mem_size = min(mem_size, bip->mem_size); + prpmc2800_bridge_setup(mem_size); /* Do necessary bridge setup */ /* If the VPD doesn't match what we know about, just use the ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2 1/2] powerpc: prpmc2800 - Add MTD support
From: Mark A. Greer <[EMAIL PROTECTED]>
Create necessary device nodes so that the MTD subsystem recognizes
the MTD entries in the prpmc2800's DTS file. Also bring MTD section
of the prpmc2800's DTS file up to the current DTS specification.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
With Stephen's comments addressed. Much nicer. Thanks again, Stephen.
arch/powerpc/boot/dts/prpmc2800.dts| 39 +++
arch/powerpc/platforms/embedded6xx/prpmc2800.c | 12
2 files changed, 41 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/boot/dts/prpmc2800.dts
b/arch/powerpc/boot/dts/prpmc2800.dts
index 297dfa5..24944ca 100644
--- a/arch/powerpc/boot/dts/prpmc2800.dts
+++ b/arch/powerpc/boot/dts/prpmc2800.dts
@@ -55,17 +55,36 @@
f200 f200 0004>; /* Integrated SRAM */
[EMAIL PROTECTED] {
- device_type = "rom";
- compatible = "direct-mapped";
- reg = ; /* Default (64MB) */
- probe-type = "CFI";
+ compatible = "cfi-flash";
+ reg = ;
bank-width = <4>;
- partitions = < 0010 /* RO */
- 0010 00040001 /* RW */
- 0014 0040 /* RO */
- 0054 039c /* RO */
- 03f0 0010>; /* RO */
- partition-names = "FW Image A", "FW Config Data",
"Kernel Image", "Filesystem", "FW Image B";
+ device-width = <2>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ [EMAIL PROTECTED] {
+ label = "FW Image A";
+ reg = < 0010>;
+ read-only;
+ };
+ [EMAIL PROTECTED] {
+ label = "FW Config Data"; /* RW */
+ reg = <0010 0004>;
+ };
+ [EMAIL PROTECTED] {
+ label = "Kernel Image";
+ reg = <0014 0040>;
+ read-only;
+ };
+ [EMAIL PROTECTED] {
+ label = "Filesystem";
+ reg = <0054 039c>;
+ read-only;
+ };
+ [EMAIL PROTECTED] {
+ label = "FW Image B";
+ reg = <03f0 0010>;
+ read-only;
+ };
};
mdio {
diff --git a/arch/powerpc/platforms/embedded6xx/prpmc2800.c
b/arch/powerpc/platforms/embedded6xx/prpmc2800.c
index e484cac..2506f38 100644
--- a/arch/powerpc/platforms/embedded6xx/prpmc2800.c
+++ b/arch/powerpc/platforms/embedded6xx/prpmc2800.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -68,6 +69,17 @@ static void __init prpmc2800_setup_arch(void)
printk("Motorola %s\n", prpmc2800_platform_name);
}
+static int __init prpmc2800_register_mtd(void)
+{
+ struct device_node *np;
+
+ for_each_compatible_node(np, NULL, "cfi-flash")
+ of_platform_device_create(np, NULL, NULL);
+
+ return 0;
+}
+device_initcall(prpmc2800_register_mtd);
+
static void prpmc2800_reset_board(void)
{
u32 temp;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: prpmc2800 - Add MTD support
On Fri, Oct 26, 2007 at 10:23:53AM +1000, Stephen Rothwell wrote:
> Hi Mark,
>
> On Thu, 25 Oct 2007 16:39:48 -0700 "Mark A. Greer" <[EMAIL PROTECTED]> wrote:
> >
> > +static int __init prpmc2800_register_mtd(void)
> > +{
> > + struct device_node *np = NULL;
> ^^^
> Not needed if you use for_each_compatible_node().
>
> > +
> > + while ((np = of_find_compatible_node(np, NULL, "cfi-flash")) != NULL)
>
> for_each_compatible_node(np, NULL, "cfi-flash")
>
> > + of_platform_device_create(np, NULL, NULL);
> > +
> > + of_node_put(np);
>
> Not needed as np must be NULL when you get here.
Ah, yes, true on all points. Thanks Stephen.
Update coming shortly...
Mark
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] powerpc: prpmc2800 - Don't overwrite user FLASH size
From: Mark A. Greer <[EMAIL PROTECTED]>
The prpmc2800 bootwrapper code currently overwrites the DTS' user FLASH
size with a predetermined value. Intead make it use whatever is specified
in the DTS unless the prpmc2800 variant the bootwrapper is running on has
no user FLASH. In that case, set the user FLASH size to 0.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/prpmc2800.c | 54
1 file changed, 28 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/boot/prpmc2800.c b/arch/powerpc/boot/prpmc2800.c
index 9614e1d..a8b3213 100644
--- a/arch/powerpc/boot/prpmc2800.c
+++ b/arch/powerpc/boot/prpmc2800.c
@@ -58,7 +58,7 @@ struct prpmc2800_board_info {
u32 core_speed;
u32 mem_size;
u32 boot_flash;
- u32 user_flash;
+ u8 has_user_flash;
};
static struct prpmc2800_board_info prpmc2800_board_info[] = {
@@ -73,7 +73,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] = {
.core_speed = 1*GHz,
.mem_size = 512*MB,
.boot_flash = 1*MB,
- .user_flash = 64*MB,
+ .has_user_flash = 1,
},
{
.model = BOARD_MODEL_PRPMC280,
@@ -86,7 +86,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] = {
.core_speed = 1*GHz,
.mem_size = 512*MB,
.boot_flash = 0,
- .user_flash = 0,
+ .has_user_flash = 0,
},
{
.model = BOARD_MODEL_PRPMC280,
@@ -99,7 +99,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] = {
.core_speed = 733*MHz,
.mem_size = 512*MB,
.boot_flash = 1*MB,
- .user_flash = 64*MB,
+ .has_user_flash = 1,
},
{
.model = BOARD_MODEL_PRPMC280,
@@ -112,7 +112,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] =
{
.core_speed = 1*GHz,
.mem_size = 1*GB,
.boot_flash = 1*MB,
- .user_flash = 64*MB,
+ .has_user_flash = 1,
},
{
.model = BOARD_MODEL_PRPMC280,
@@ -125,7 +125,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] =
{
.core_speed = 1*GHz,
.mem_size = 512*MB,
.boot_flash = 1*MB,
- .user_flash = 64*MB,
+ .has_user_flash = 1,
},
{
.model = BOARD_MODEL_PRPMC280,
@@ -138,7 +138,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] =
{
.core_speed = 733*MHz,
.mem_size = 128*MB,
.boot_flash = 1*MB,
- .user_flash = 0,
+ .has_user_flash = 0,
},
{
.model = BOARD_MODEL_PRPMC280,
@@ -151,7 +151,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] =
{
.core_speed = 1*GHz,
.mem_size = 256*MB,
.boot_flash = 1*MB,
- .user_flash = 0,
+ .has_user_flash = 0,
},
{
.model = BOARD_MODEL_PRPMC280,
@@ -164,7 +164,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] =
{
.core_speed = 1*GHz,
.mem_size = 1*GB,
.boot_flash = 1*MB,
- .user_flash = 64*MB,
+ .has_user_flash = 1,
},
{
.model = BOARD_MODEL_PRPMC2800,
@@ -177,7 +177,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] =
{
.core_speed = 1*GHz,
.mem_size = 512*MB,
.boot_flash = 2*MB,
- .user_flash = 64*MB,
+ .has_user_flash = 1,
},
{
.model = BOARD_MODEL_PRPMC2800,
@@ -190,7 +190,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] =
{
.core_speed = 1*GHz,
.mem_size = 512*MB,
.boot_flash = 0,
- .user_flash = 0,
+ .has_user_flash = 0,
},
{
.model = BOARD_MODEL_PRPMC2800,
@@ -203,7 +203,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] =
{
.core_speed = 733*MHz,
.mem_size = 512*MB,
.boot_flash = 2*MB,
- .user_flash = 64*MB,
+ .has_user_flash = 1,
},
{
.model = BOARD_MODEL_PRPMC2800,
@@ -216,7 +216,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] =
{
.core_
[PATCH 1/2] powerpc: prpmc2800 - Add MTD support
From: Mark A. Greer <[EMAIL PROTECTED]>
Create necessary device nodes so that the MTD subsystem recognizes
the MTD entries in the prpmc2800's DTS file. Also bring MTD section
of the prpmc2800's DTS file up to the current DTS specification.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/prpmc2800.dts| 39 +++
arch/powerpc/platforms/embedded6xx/prpmc2800.c | 13 +
2 files changed, 42 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/boot/dts/prpmc2800.dts
b/arch/powerpc/boot/dts/prpmc2800.dts
index 297dfa5..50fc0a7 100644
--- a/arch/powerpc/boot/dts/prpmc2800.dts
+++ b/arch/powerpc/boot/dts/prpmc2800.dts
@@ -55,17 +55,36 @@
f200 f200 0004>; /* Integrated SRAM */
[EMAIL PROTECTED] {
- device_type = "rom";
- compatible = "direct-mapped";
- reg = ; /* Default (64MB) */
- probe-type = "CFI";
+ compatible = "cfi-flash";
+ reg = ;
bank-width = <4>;
- partitions = < 0010 /* RO */
- 0010 00040001 /* RW */
- 0014 0040 /* RO */
- 0054 039c /* RO */
- 03f0 0010>; /* RO */
- partition-names = "FW Image A", "FW Config Data",
"Kernel Image", "Filesystem", "FW Image B";
+ device-width = <2>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ [EMAIL PROTECTED] {
+ label = "FW Image A";
+ reg = < 0010>;
+ read-only;
+ };
+ [EMAIL PROTECTED] {
+ label = "FW Config Data"; /* RW */
+ reg = <0010 0004>;
+ };
+ [EMAIL PROTECTED] {
+ label = "Kernel Image";
+ reg = <0014 0040>;
+ read-only;
+ };
+ [EMAIL PROTECTED] {
+ label = "Filesystem";
+ reg = <0054 039c>;
+ read-only;
+ };
+ [EMAIL PROTECTED] {
+ label = "FW Image B";
+ reg = <03f0 0010>;
+ read-only;
+ };
};
mdio {
diff --git a/arch/powerpc/platforms/embedded6xx/prpmc2800.c
b/arch/powerpc/platforms/embedded6xx/prpmc2800.c
index e484cac..a356a19 100644
--- a/arch/powerpc/platforms/embedded6xx/prpmc2800.c
+++ b/arch/powerpc/platforms/embedded6xx/prpmc2800.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -68,6 +69,18 @@ static void __init prpmc2800_setup_arch(void)
printk("Motorola %s\n", prpmc2800_platform_name);
}
+static int __init prpmc2800_register_mtd(void)
+{
+ struct device_node *np = NULL;
+
+ while ((np = of_find_compatible_node(np, NULL, "cfi-flash")) != NULL)
+ of_platform_device_create(np, NULL, NULL);
+
+ of_node_put(np);
+ return 0;
+}
+device_initcall(prpmc2800_register_mtd);
+
static void prpmc2800_reset_board(void)
{
u32 temp;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Override timer interrupt
On Fri, Oct 12, 2007 at 04:39:53PM -0500, Rune Torgersen wrote: > > From: Mark A. Greer > > > Is there an easy way to use something other than the decrementer for > the > > > timer interrupt? > > > Check out the clocksource stuff. It let's you set up numerous clock > > sources and set the rating of each one. You can start looking in > > arch/powerpc/kernel/time.c for example code. > > Thanks I will. > Currently our board port lives in /arch/ppc (2.6.18) but I will take a > look in powerpc. Okay. Just an FYI, arch/ppc will evaporate next summer. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
On Sun, Oct 07, 2007 at 08:31:46PM -0500, Scott Wood wrote: Sorry for the delay, Scott. > Mark A. Greer wrote: > >Why? Because its only safe to download a zImage to certain "safe" > >locations. > >Where those "safe" locations are vary by firmware, firmware version, and > >zImage size. This is the issue we're discussing. > > In theory, yes -- but in practice the odds of this particular heuristic > choosing an unsuitable address seem slim. Yes, it probably will work fairly well for most powerpc 32-bit platforms since the default in arch/ppc was 8MB (but there was a manual override that was used by some platforms). That still doesn't make it safe for everyone 32-bit or 64-bit. > >I've already explained _why_ the link address matters WRT where its > >downloaded. > > Sorry, I was being a bit too pendantic with respect to the distinction > between link and load address. And I was probably too impatient. Sorry. > >>>Also, being able to control the link address (that is, the download > >>>address with some firmwares) is not a u-boot specific issue and we > >>>shouldn't make a u-boot specific solution. > >>How is this a u-boot specific solution? > > > >Because the hoops being jumped through in the patch(es) are to make > >u-boot happy and no other firmware. > > No, the "hoops" (which I don't think are sufficiently complicated to > warrant such a name) Not yet maybe but as exceptions come along ". = ALIGN((_kend - _kstart + 64*1024), (4*1024*1024));" will become more complicated. > are to address a generic issue with the bootwrapper > -- it wants to put the kernel at zero. It'd be really nice if, in the > absense of a vmlinux_alloc method, the generic code would do an ordinary > malloc() if there's not enough room at zero. Actually, that's a good idea but its only for safety sake. When you unpack the kernel at somewhere other than 0, there will be an additional copy very early during kernel boot to copy itself to address 0. So, if we add that feature we should print a warning so the user knows extra time was spent copying the kernel to 0. If we can come up with a simple way to control the link address we can avoid that copy. > >>I'd much rather it be automatic than require the user to guess an > >>appropriate value (and be aware in the first place that it needs to be > >>set). > > > >Sure, automatic is nice; conjuring up the magic to make it work in all > >situations isn't. > > I think this heuristic would work in most situations, so if we do add a > manual override it should be an override, and not something that > everybody has to put up with. Okay, so how about we just leave the default at 4MB and come up with that manual override?? ;) > >Having the link address--and therefore the download address on some > >systems--mysteriously and uncontrollably jump around based on the zImage > >size is asking for trouble. > > It's a source of potential issues, but I think "asking for trouble" is > exaggerating somewhat. Noted and disagreed with. :) Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Override timer interrupt
On Fri, Oct 12, 2007 at 03:49:02PM -0500, Rune Torgersen wrote: > Is there an easy way to use something other than the decrementer for the > timer interrupt? > > Reason i'm asking is tha t on our board, the decrementer cannot be > divided to 1khz evenly, so we have rounding errors for time, but we do > have a 1KHz timer interrupt from an FPGA that is source of a T1 clock. > > Right now I let the decrementer interrupt do nothing, and made my own > timer interrupt handler that calls the stuff the timer_interrupt usually > does. > > This works, but there are some instability (ie unexplained hangs) that > showed up when I did this. I just responded to you on -embedded with this: "Check out the clocksource stuff. It let's you set up numerous clock sources and set the rating of each one. You can start looking in arch/powerpc/kernel/time.c for example code." Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
On Fri, Oct 05, 2007 at 12:30:54PM -0500, Scott Wood wrote: > On Thu, Oct 04, 2007 at 06:58:49PM -0700, Mark A. Greer wrote: > > Having the link address jump around depending on the size of the kernel > > or zImage is wrong IMHO. It just screams "weird can't boot issues." > > We need a way to specify exactly where we want the zImage linked no > > matter what the kernel or zImage size. > > Why? Why? Because its only safe to download a zImage to certain "safe" locations. Where those "safe" locations are vary by firmware, firmware version, and zImage size. This is the issue we're discussing. I've already explained _why_ the link address matters WRT where its downloaded. > The zImage is relocatable. It doesn't matter where it's linked. We know...and a zImage running at an address it wasn't linked at is not the issue. > > Also, being able to control the link address (that is, the download > > address with some firmwares) is not a u-boot specific issue and we > > shouldn't make a u-boot specific solution. > > How is this a u-boot specific solution? Because the hoops being jumped through in the patch(es) are to make u-boot happy and no other firmware. > > The more general problem is that some firmwares examine the ELF header > > and download the zImage to address it was linked at. Some firmwares let > > you override this but some don't and those are the problem ones. > > That's not the more general problem; it's the same problem with a different > file format. True, I misspoke. I'll restate it this way: The more general problem is that some firmwares will only download to the address the zImage is linked at. So, we need to control what that link address is." > > I still like my idea best. I haven't coded yet it so I don't have a patch > > but this is what I mean: > > > > 1) add a config option (default 4MB) for the link address > > 2) add a parameter to the wrapper script thru which we pass the value in > >the config option > > 3) the wrapper script changes the VMA/LMA to the address specified > >(objcopy --change-addresses= ?). > > I'd much rather it be automatic than require the user to guess an > appropriate value (and be aware in the first place that it needs to be set). Sure, automatic is nice; conjuring up the magic to make it work in all situations isn't. Having the link address--and therefore the download address on some systems--mysteriously and uncontrollably jump around based on the zImage size is asking for trouble. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
On Thu, Oct 04, 2007 at 07:59:30PM -0700, Mark A. Greer wrote: > On Fri, Oct 05, 2007 at 12:25:54PM +1000, David Gibson wrote: > > The zImage is already hardware and > > firmware specific; > > And [potentially] firmware version and zImage size specific. I meant to add, "which is why it'll be difficult to come up with a heuristic that will work in all situations." Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
On Fri, Oct 05, 2007 at 12:25:54PM +1000, David Gibson wrote: > On Thu, Oct 04, 2007 at 06:58:49PM -0700, Mark A. Greer wrote: > > On Wed, Oct 03, 2007 at 03:50:05PM +1000, David Gibson wrote: > > > On Fri, Sep 28, 2007 at 06:23:09PM +0400, Valentine Barshak wrote: > > > > David Gibson wrote: > > > > > On Mon, Sep 24, 2007 at 03:36:27PM +0400, Valentine Barshak wrote: > > > > > > Looking deeper at this I've found that currently u-boot thinks that > > > > memory space over 8MB is not reached by Linux kernel (CFG_BOOTMAPSZ > > > > defined as (8 << 20)), although all physical memory is identity mapped. > > > > That's why it puts command line and board info structure as high as > > > > possible within the first 8MB. This worked fine with uImage, since > > > > u-boot always unpacked it to 0. Now, cuImage has to be unpacked higher > > > > (we need space at the start of the memory to eventually put vmlinux > > > > image there). So, if unpacked kernel image crosses 8MB boundary, it > > > > gets > > > > damaged by u-boot when it prepares cmd_line and bdinfo. The possible > > > > workaround for that is to always link zImage at >=8MB base or to have > > > > 4MB granularity like this: > > > > > > > > + . = ALIGN((_kend - _kstart + 64*1024), (4*1024*1024)); > > > > > > > > Reserve at least 64K for u-boot cmd_line and bdinfo. > > > > > > Ah. Right. That makes things a bit tricky. Even this 4MB > > > granularity may not be enough (say, if the vmlinux is < 4MB, but the > > > zImage has a really big initrd and is > 4MB). > > > > > > Except... it shouldn't really be the link address that matters. The > > > zImage is relocatable, so it should only be the load address specified > > > in the uImage header which matters. I think that's currently derived > > > from the link address, but it doesn't have to be. > > > > Having the link address jump around depending on the size of the kernel > > or zImage is wrong IMHO. It just screams "weird can't boot issues." > > Hrm. Except we already have that - the zImage is linked at a fixed > location, and will just not work if the sizes are wrong. Yes, its an issue now (which is why we're having this discussion) but at least its predictable ATM. Having it jump around on you because you happened to set/clear a CONFIG option is worse. My point is that the address needs to be set manually--no fancy heuristics or whatever to guess. > > We need a way to specify exactly where we want the zImage linked no > > matter what the kernel or zImage size. > > > > Also, being able to control the link address (that is, the download > > address with some firmwares) is not a u-boot specific issue and we > > shouldn't make a u-boot specific solution. > > > > The more general problem is that some firmwares examine the ELF header > > and download the zImage to address it was linked at. Some firmwares let > > you override this but some don't and those are the problem ones. > > > > We talked about this a bit back in February, > > http://ozlabs.org/pipermail/linuxppc-dev/2007-February/031532.html > > > > In that thread Geoff Levand suggested a config option and running it > > thru a preprocessor. David Gibson suggested making a replaceable linker > > script. I suggested passing the value of a config option to the wrapper > > script which would use objcopy/whatever to change the section addresses > > in the image (maybe this is what Geoff had in mind, I'm not sure). > > > > I still like my idea best. I haven't coded yet it so I don't have a patch > > but this is what I mean: > > > > 1) add a config option (default 4MB) for the link address > > 2) add a parameter to the wrapper script thru which we pass the value in > >the config option > > 3) the wrapper script changes the VMA/LMA to the address specified > >(objcopy --change-addresses= ?). > > > > I'll code it up in the next day or two unless someone doesn't like the idea. > > A config option just doesn't seem right to me, except as a > special-circumstances hack. Acutally, I started to hack up the patch and noticed that its already there. Its 'CONFIG_BOOT_LOAD' which is an "Advanced setup" option in arch/powerpc/Kconfig (probably migrated from arch/ppc/Kconfig). Several defconfig's have it set but its not used AFAICS. > The zImage is already hardware
Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
On Wed, Oct 03, 2007 at 03:50:05PM +1000, David Gibson wrote: > On Fri, Sep 28, 2007 at 06:23:09PM +0400, Valentine Barshak wrote: > > David Gibson wrote: > > > On Mon, Sep 24, 2007 at 03:36:27PM +0400, Valentine Barshak wrote: > > Looking deeper at this I've found that currently u-boot thinks that > > memory space over 8MB is not reached by Linux kernel (CFG_BOOTMAPSZ > > defined as (8 << 20)), although all physical memory is identity mapped. > > That's why it puts command line and board info structure as high as > > possible within the first 8MB. This worked fine with uImage, since > > u-boot always unpacked it to 0. Now, cuImage has to be unpacked higher > > (we need space at the start of the memory to eventually put vmlinux > > image there). So, if unpacked kernel image crosses 8MB boundary, it gets > > damaged by u-boot when it prepares cmd_line and bdinfo. The possible > > workaround for that is to always link zImage at >=8MB base or to have > > 4MB granularity like this: > > > > + . = ALIGN((_kend - _kstart + 64*1024), (4*1024*1024)); > > > > Reserve at least 64K for u-boot cmd_line and bdinfo. > > Ah. Right. That makes things a bit tricky. Even this 4MB > granularity may not be enough (say, if the vmlinux is < 4MB, but the > zImage has a really big initrd and is > 4MB). > > Except... it shouldn't really be the link address that matters. The > zImage is relocatable, so it should only be the load address specified > in the uImage header which matters. I think that's currently derived > from the link address, but it doesn't have to be. Having the link address jump around depending on the size of the kernel or zImage is wrong IMHO. It just screams "weird can't boot issues." We need a way to specify exactly where we want the zImage linked no matter what the kernel or zImage size. Also, being able to control the link address (that is, the download address with some firmwares) is not a u-boot specific issue and we shouldn't make a u-boot specific solution. The more general problem is that some firmwares examine the ELF header and download the zImage to address it was linked at. Some firmwares let you override this but some don't and those are the problem ones. We talked about this a bit back in February, http://ozlabs.org/pipermail/linuxppc-dev/2007-February/031532.html In that thread Geoff Levand suggested a config option and running it thru a preprocessor. David Gibson suggested making a replaceable linker script. I suggested passing the value of a config option to the wrapper script which would use objcopy/whatever to change the section addresses in the image (maybe this is what Geoff had in mind, I'm not sure). I still like my idea best. I haven't coded yet it so I don't have a patch but this is what I mean: 1) add a config option (default 4MB) for the link address 2) add a parameter to the wrapper script thru which we pass the value in the config option 3) the wrapper script changes the VMA/LMA to the address specified (objcopy --change-addresses= ?). I'll code it up in the next day or two unless someone doesn't like the idea. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: MAINTAINERS shouldn't reference linuxppc-embedded
Powerpc patches should be posted to linuxppc-dev@ozlabs.org so modify MAINTAINERS to no longer reference [EMAIL PROTECTED] Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]> --- MAINTAINERS | 17 - 1 file changed, 8 insertions(+), 9 deletions(-) --- diff --git a/MAINTAINERS b/MAINTAINERS index 8f80068..06259b4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1543,7 +1543,7 @@ P:Pantelis Antoniou M: [EMAIL PROTECTED] P: Vitaly Bordug M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org L: [EMAIL PROTECTED] S: Maintained @@ -1551,14 +1551,14 @@ FREESCALE HIGHSPEED USB DEVICE DRIVER P: Li Yang M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org S: Maintained FREESCALE QUICC ENGINE UCC ETHERNET DRIVER P: Li Yang M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org S: Maintained FILE LOCKING (flock() and fcntl()/lockf()) @@ -2291,7 +2291,6 @@ M:[EMAIL PROTECTED] W: http://www.246tNt.com/mpc52xx/ W: http://www.penguinppc.org/ L: linuxppc-dev@ozlabs.org -L: [EMAIL PROTECTED] S: Maintained LINUX FOR POWERPC EMBEDDED PPC4XX @@ -2300,7 +2299,7 @@ M:[EMAIL PROTECTED] P: Matt Porter M: [EMAIL PROTECTED] W: http://www.penguinppc.org/ -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org T: git kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc.git S: Maintained @@ -2308,21 +2307,21 @@ LINUX FOR POWERPC BOOT CODE P: Tom Rini M: [EMAIL PROTECTED] W: http://www.penguinppc.org/ -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org S: Maintained LINUX FOR POWERPC EMBEDDED PPC8XX P: Marcelo Tosatti M: [EMAIL PROTECTED] W: http://www.penguinppc.org/ -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org S: Maintained LINUX FOR POWERPC EMBEDDED PPC83XX AND PPC85XX P: Kumar Gala M: [EMAIL PROTECTED] W: http://www.penguinppc.org/ -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org S: Maintained LINUX FOR POWERPC PA SEMI PWRFICIENT @@ -2978,7 +2977,7 @@ POWERPC 4xx EMAC DRIVER P: Eugene Surovegin M: [EMAIL PROTECTED] W: http://kernel.ebshome.net/emac/ -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org L: [EMAIL PROTECTED] S: Maintained ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Change MAINTAINER references linuxppc-embedded
On Mon, Oct 01, 2007 at 05:20:53PM -0700, Mark A. Greer wrote: > Powerpc patches should be posted to linuxppc-dev@ozlabs.org so modify > MAINTAINERS to no longer reference [EMAIL PROTECTED] > > Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]> /me sighs. Disregard this. I send before I had the proper subject Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Change MAINTAINER references linuxppc-embedded
Powerpc patches should be posted to linuxppc-dev@ozlabs.org so modify MAINTAINERS to no longer reference [EMAIL PROTECTED] Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]> --- MAINTAINERS | 17 - 1 file changed, 8 insertions(+), 9 deletions(-) --- diff --git a/MAINTAINERS b/MAINTAINERS index 8f80068..06259b4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1543,7 +1543,7 @@ P:Pantelis Antoniou M: [EMAIL PROTECTED] P: Vitaly Bordug M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org L: [EMAIL PROTECTED] S: Maintained @@ -1551,14 +1551,14 @@ FREESCALE HIGHSPEED USB DEVICE DRIVER P: Li Yang M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org S: Maintained FREESCALE QUICC ENGINE UCC ETHERNET DRIVER P: Li Yang M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org S: Maintained FILE LOCKING (flock() and fcntl()/lockf()) @@ -2291,7 +2291,6 @@ M:[EMAIL PROTECTED] W: http://www.246tNt.com/mpc52xx/ W: http://www.penguinppc.org/ L: linuxppc-dev@ozlabs.org -L: [EMAIL PROTECTED] S: Maintained LINUX FOR POWERPC EMBEDDED PPC4XX @@ -2300,7 +2299,7 @@ M:[EMAIL PROTECTED] P: Matt Porter M: [EMAIL PROTECTED] W: http://www.penguinppc.org/ -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org T: git kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc.git S: Maintained @@ -2308,21 +2307,21 @@ LINUX FOR POWERPC BOOT CODE P: Tom Rini M: [EMAIL PROTECTED] W: http://www.penguinppc.org/ -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org S: Maintained LINUX FOR POWERPC EMBEDDED PPC8XX P: Marcelo Tosatti M: [EMAIL PROTECTED] W: http://www.penguinppc.org/ -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org S: Maintained LINUX FOR POWERPC EMBEDDED PPC83XX AND PPC85XX P: Kumar Gala M: [EMAIL PROTECTED] W: http://www.penguinppc.org/ -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org S: Maintained LINUX FOR POWERPC PA SEMI PWRFICIENT @@ -2978,7 +2977,7 @@ POWERPC 4xx EMAC DRIVER P: Eugene Surovegin M: [EMAIL PROTECTED] W: http://kernel.ebshome.net/emac/ -L: [EMAIL PROTECTED] +L: linuxppc-dev@ozlabs.org L: [EMAIL PROTECTED] S: Maintained ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] Get rid of linuxppc-embedded?
On Mon, Oct 01, 2007 at 02:59:14PM -0600, Grant Likely wrote: > On 10/1/07, Mark A. Greer <[EMAIL PROTECTED]> wrote: > > With the merging of the powerpc trees I'm not sure there is a clear > > reason why we have 2 separate powerpc lists anymore (linuxppc-dev and > > linuxppc-embedded). > > > > linuxppc-embedded is fairly low volume/noise but there is still the > > occasional > > patch posted there that should really be posted to linuxppc-dev. I think > > it would be nice to have just one list where all eyes are focused. > > > > Is it time to get rid of linuxppc-embedded? > > Ack Ack Ack! > > I agree 100% Okay. Even if we keep the list around, we should update MAINTAINERS to only refer to -dev. I'll post a patch in a second. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC] Get rid of linuxppc-embedded?
With the merging of the powerpc trees I'm not sure there is a clear reason why we have 2 separate powerpc lists anymore (linuxppc-dev and linuxppc-embedded). linuxppc-embedded is fairly low volume/noise but there is still the occasional patch posted there that should really be posted to linuxppc-dev. I think it would be nice to have just one list where all eyes are focused. Is it time to get rid of linuxppc-embedded? Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/5] embedded6xx: Remove unnecessary loops_per_jiffy initialization code.
On Fri, Jul 27, 2007 at 01:25:09PM -0500, Jon Loeliger wrote: > Signed-off-by: Jon Loeliger <[EMAIL PROTECTED]> FWIW for the prpmc2800 part... Acked-by: Mark A. Greer <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Someone broke my allmodconfig build
On Mon, Jul 23, 2007 at 11:43:37AM +1000, David Gibson wrote: > On Sat, Jul 21, 2007 at 09:04:13PM -0500, Josh Boyer wrote: > > On Sun, Jul 22, 2007 at 10:37:06AM +1000, Paul Mackerras wrote: > > > Stephen Rothwell writes: > > > > > > > WRAParch/powerpc/boot/zImage.ps3 > > > > /home/sfr/kernels/linus/arch/powerpc/boot/wrapper: line 113: dtc: > > > > command not found > > > > make[2]: *** [arch/powerpc/boot/zImage.ps3] Error 1 > > > > > > Hmmm, we should be shipping .dtb files with the tree, so people don't > > > have to have dtc installed. > > > > Really? I don't think we're quite ready for that. Particularly for the > > embedded boards. Those DTS files still get lots of churn, and having to > > update both the .dts and .dtb at the same time seems a bit fragile. > > I sort of prefer this option in theory, but it's basically > impossible. People updating dts files by patch would also have to > update the dtb, which can't be done in a normal patch, since they're > binary. I agree. Shipping a magic binary blob, especially ones that haven't really settled out, will be a real headache for poeple. > I'm working with sfr now on importing dtc into the kernel tree. IIRC, this was discussed when dtc first came into existence but it was pooh-poohed. I forget why now. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mv64x60 use mutex instead of semaphore
On Thu, Jul 19, 2007 at 11:50:49PM +0200, Christoph Hellwig wrote: > > Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]> Acked-by: Mark A. Greer <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Do we need to reset the master branch?
On Fri, Jul 20, 2007 at 01:46:18AM +1000, Stephen Rothwell wrote: > On Fri, 20 Jul 2007 01:44:32 +1000 Stephen Rothwell <[EMAIL PROTECTED]> wrote: > > > > git remote add powerpc > > git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git > > git fetch powerpc > > > > This will track the tree in branches called powerpc/ and do > > resets as necessary. > > You should not make any local commits to the powerpc/* branches, of course. Right. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Do we need to reset the master branch?
On Fri, Jul 20, 2007 at 01:44:32AM +1000, Stephen Rothwell wrote: > On Thu, 19 Jul 2007 08:32:17 -0700 "Mark A. Greer" <[EMAIL PROTECTED]> wrote: > > > > I was in the master branch of powerpc.git and did a 'git-pull' > > Sorry, I hadn't updated since this afternoon. Looks like Paul has reset > his master tree to be the same as Linus', so you do need to do a reset. > Or checkout a separate branch and use > > git fetch -f master: > > Using recent git (after 1.5.something), you can track the whole powerpc > tree like this: > > git remote add powerpc > git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git > git fetch powerpc > > This will track the tree in branches called powerpc/ and do > resets as necessary. Oh, that's cool Thanks Stephen. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Do we need to reset the master branch?
On Fri, Jul 20, 2007 at 01:27:08AM +1000, Stephen Rothwell wrote: > Hi Mark, > > On Thu, 19 Jul 2007 08:17:46 -0700 "Mark A. Greer" <[EMAIL PROTECTED]> wrote: > > > > I did a git-pull this morning but it had a conflict. Should I have > > reset it to something? > > What did you pull it into? There were conflicts with Linus' tree in the > last merge, so there may be conflicts with master as well. I am sure > Paul will pull Linus's tree back into his master branch when he returns > which should resolve the conflicts. I was in the master branch of powerpc.git and did a 'git-pull' Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Do we need to reset the master branch?
Hi Paul, I did a git-pull this morning but it had a conflict. Should I have reset it to something? Thanks, Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] Kconfig cleanup revisited
On Fri, Jul 13, 2007 at 11:54:34AM +0200, Arnd Bergmann wrote: > On Friday 13 July 2007, Mark A. Greer wrote: > > I really like what you've done here, thanks. > > > > The patches don't apply straight up so what other patches do these go > > on top of? > > They are meant to apply on top of powerpc.git. Yep, me too. > I found now that > the first patch has a trivial reject against the for-2.6.23 branch, > but works fine for the master branch. Hrm, I'm on master and it doesn't apply but its minor so NBD. > Should I resend? Not for me but Paul might appreciate it. :) Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] Kconfig cleanup revisited
On Thu, Jul 12, 2007 at 11:01:56PM +0200, Arnd Bergmann wrote: > Since this was brought up by Mark, here is a resend of the > Kconfig cleanup patches that have not been merged so far, > with updates for the comments I received. > > I stumbled over another bug in the process, and fear I have > found a can of worms there (not opened yet): There are > still many files under arch/powerpc that include headers > from include/asm-ppc/. Most of these includes can simply > be removed, but some are real bugs, where generic code still > relies on board-specific macro definitions. Hi Arnd, I really like what you've done here, thanks. The patches don't apply straight up so what other patches do these go on top of? Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/9] move 82xx/83xx/86xx Kconfig options to platform selection
On Wed, Jul 11, 2007 at 10:33:51PM +0200, Arnd Bergmann wrote: > On Wednesday 11 July 2007, Mark A. Greer wrote: > > > > +config CLASSIC32 > > > + def_bool y > > > + depends on 6xx && PPC_MULTIPLATFORM > > > > Arnd, is this really what you wanted? With it, none of the embedded > > classics have CLASSIC32 defined which means they don't get TAU or > > ALTIVEC defined which isn't good. > > Sorry, this was the result of a wrong patch reordering. In my initial > patch set I ended up with 6xx == CLASSIC32 and PPC_MULTIPLATFORM=y, > but then I backed out a few patches in the middle. Ah, okay. > I guess the best is to do another patch that moves PPC_EMBEDDED6xx into > PPC_MULTIPLATFORM again and leaves this one as it is. > Alternatively, we could kill CONFIG_CLASSIC32 entirely as it is used > only in a few places. Especially after I resubmit my CPU type selection > patch again, which allows you do it in a more fine grained way. Yes, it seems like getting rid of CLASSIC32 would be okay since it is hardly used. > Which systems in particular should allow CONFIG_TAU? Is there a more > specific dependency than (6xx && !(82xx || 83xx || 86xx || 52xx))? I think Segher pretty much answered this. We definitely need to get ALTIVEC back soon for 74xx--currently SIGILL's my init when booting. Since it sounds like you're still tweaking things in Kconfig files, I'll leave it to you to take care of it. If not, just let me know. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/9] move 82xx/83xx/86xx Kconfig options to platform selection
On Sat, Jun 16, 2007 at 02:05:12AM +0200, [EMAIL PROTECTED] wrote: > The cores used in the MPC82xx/83xx/86xx embedded controllers are very similar > to those in the 32 bit general-purpose processors, so it makes sense to > treat them as the same CPU family. > > Choosing between the embedded platforms and the multiplatform code is > now done in the platform menu, but functionally everything stays the > same. > > Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]> > Index: linux-2.6/arch/powerpc/platforms/Kconfig > === > --- linux-2.6.orig/arch/powerpc/platforms/Kconfig > +++ linux-2.6/arch/powerpc/platforms/Kconfig > @@ -16,8 +16,31 @@ config EMBEDDED6xx > bool "Embedded 6xx/7xx/7xxx-based board" > depends on PPC32 && (BROKEN||BROKEN_ON_SMP) > +config CLASSIC32 > + def_bool y > + depends on 6xx && PPC_MULTIPLATFORM Arnd, is this really what you wanted? With it, none of the embedded classics have CLASSIC32 defined which means they don't get TAU or ALTIVEC defined which isn't good. Mark ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Schedule removal of arch/ppc
On Fri, Jun 29, 2007 at 04:14:42PM +0100, David Woodhouse wrote: > On Fri, 2007-06-29 at 10:13 -0500, Josh Boyer wrote: > > That's it? I'm scheduling the demise of an entire architecture > > sub-tree and the only comment you can make is about a superfluous > > apostrophe? ;) > > Sorry, allow me to rephrase... > > http://www.angryflower.com/itsits.gif > DIE arch/ppc DIE! I second that motion. ;) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
