All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonas Bonn <jonas@southpole.se>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	devicetree-discuss@lists.ozlabs.org
Subject: Re: [PATCH v2 02/19] OpenRISC: Device tree
Date: Mon, 04 Jul 2011 06:58:28 +0200	[thread overview]
Message-ID: <1309755508.16393.18.camel@localhost> (raw)
In-Reply-To: <CACxGe6tFX=EQjaL-4EjSXquY5eh+bca29=d=cE5-YAVCUVRCvA@mail.gmail.com>


On Sun, 2011-07-03 at 14:51 -0600, Grant Likely wrote:
> On Sat, Jul 2, 2011 at 3:15 PM, Jonas Bonn <jonas@southpole.se> wrote:
> Does it really make sense to have an SoC node for this board?  I
> assume this is for a soft CPU system on a Diligent FPGA board.  It is
> best if the device tree structure matches the actual bus layout of the
> chip and/or FPGA design.  If the devices are directly on the CPU bus,
> then it is better to do without an soc node entirely and just put
> everything at the root.

Not sure I quite understand the distinction here.  Yes, it's a soft CPU,
but conceptually it has an internal bus (Wishbone) comparable to the
Avalon bus that the peripherals sit on.  I'd say it's an SoC; but I need
to ask: what constitutes a valid use of the "soc" node?

> > diff --git a/arch/openrisc/kernel/setup.c b/arch/openrisc/kernel/setup.c
> > index 49342e9..6ce6583 100644
> > --- a/arch/openrisc/kernel/setup.c
> > +++ b/arch/openrisc/kernel/setup.c
> > @@ -173,8 +173,7 @@ void __init setup_cpuinfo(void)
> >        unsigned long iccfgr,dccfgr;
> >        unsigned long cache_set_size, cache_ways;;
> >
> > -       cpu = (struct device_node *) of_find_compatible_node(NULL,
> > -                                       NULL, "opencores,openrisc-1200");
> > +       cpu = of_find_compatible_node(NULL, NULL, "opencores,openrisc-1200");
> 
> This looks odd.  Is it a stale hunk from a previous patch version?
> 

Hmmm... no, it's a hunk that should have been in patch 01/19 of the
series.  That said, there's a bit of devicetree code in that patch too.
Can I just say, "please have a look there, too", or do I need to pull
those bits out into the devicetree patch?

I've pasted in just the relevant parts from patch 01/19 below for ease
of review.

/Jonas

From arch/openrisc/kernel/setup.c:

+static inline unsigned int fcpu(struct device_node *cpu, char *n)
+{
+        const int *val;
+        return (val = of_get_property(cpu, n, NULL)) ? *val : 0;
+}
+
+void __init setup_cpuinfo(void)
+{
+       struct device_node *cpu = NULL;
+       unsigned long iccfgr,dccfgr;
+       unsigned long cache_set_size, cache_ways;;
+
+       cpu = (struct device_node *) of_find_compatible_node(NULL,
+                                       NULL,
"opencores,openrisc-1200");
+       if (!cpu) {
+               panic("No compatible CPU found in device tree...\n");
+       }
+
+       iccfgr = mfspr(SPR_ICCFGR);
+       cache_ways = 1 << (iccfgr & SPR_ICCFGR_NCW);
+       cache_set_size = 1 << ((iccfgr & SPR_ICCFGR_NCS) >> 3);
+       cpuinfo.icache_block_size = 16 << ((iccfgr & SPR_ICCFGR_CBS) >>
7);
+       cpuinfo.icache_size = cache_set_size * cache_ways *
cpuinfo.icache_block_size;
+
+       dccfgr = mfspr(SPR_DCCFGR);
+       cache_ways = 1 << (dccfgr & SPR_DCCFGR_NCW);
+       cache_set_size = 1 << ((dccfgr & SPR_DCCFGR_NCS) >> 3);
+       cpuinfo.dcache_block_size = 16 << ((dccfgr & SPR_DCCFGR_CBS) >>
7);
+       cpuinfo.dcache_size = cache_set_size * cache_ways *
cpuinfo.dcache_block_size;
+
+       cpuinfo.clock_frequency =  fcpu(cpu, "clock-frequency");
+
+       of_node_put(cpu);
+
+       print_cpuinfo();
+}
+
+/**
+ * or32_early_setup
+ *
+ * Handles the pointer to the device tree that this kernel is to use
+ * for establishing the available platform devices.
+ *
+ * For now, this is limited to using the built-in device tree.  In the
future,
+ * it is intended that this function will take a pointer to the device
tree
+ * that is potentially built-in, but potentially also passed in by the
+ * bootloader, or discovered by some equally clever means...
+ */
+
+void __init or32_early_setup(void) {
+
+       early_init_devtree((void *) __dtb_start);
+
+       printk(KERN_INFO "Compiled-in FDT at 0x%08x\n",
+              (unsigned int) __dtb_start);
+}
+
+const struct of_device_id openrisc_bus_ids[] = {
+        { .type = "soc", },
+        { .compatible = "soc", },
+        {},
+};
+
+static int __init openrisc_device_probe(void)
+{
+        of_platform_bus_probe(NULL, openrisc_bus_ids, NULL);
+        return 0;
+}
+device_initcall(openrisc_device_probe);

WARNING: multiple messages have this Message-ID (diff)
From: Jonas Bonn <jonas@southpole.se>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	devicetree-discuss@lists.ozlabs.org
Subject: Re: [PATCH v2 02/19] OpenRISC: Device tree
Date: Mon, 04 Jul 2011 06:58:28 +0200	[thread overview]
Message-ID: <1309755508.16393.18.camel@localhost> (raw)
In-Reply-To: <CACxGe6tFX=EQjaL-4EjSXquY5eh+bca29=d=cE5-YAVCUVRCvA@mail.gmail.com>


On Sun, 2011-07-03 at 14:51 -0600, Grant Likely wrote:
> On Sat, Jul 2, 2011 at 3:15 PM, Jonas Bonn <jonas@southpole.se> wrote:
> Does it really make sense to have an SoC node for this board?  I
> assume this is for a soft CPU system on a Diligent FPGA board.  It is
> best if the device tree structure matches the actual bus layout of the
> chip and/or FPGA design.  If the devices are directly on the CPU bus,
> then it is better to do without an soc node entirely and just put
> everything at the root.

Not sure I quite understand the distinction here.  Yes, it's a soft CPU,
but conceptually it has an internal bus (Wishbone) comparable to the
Avalon bus that the peripherals sit on.  I'd say it's an SoC; but I need
to ask: what constitutes a valid use of the "soc" node?

> > diff --git a/arch/openrisc/kernel/setup.c b/arch/openrisc/kernel/setup.c
> > index 49342e9..6ce6583 100644
> > --- a/arch/openrisc/kernel/setup.c
> > +++ b/arch/openrisc/kernel/setup.c
> > @@ -173,8 +173,7 @@ void __init setup_cpuinfo(void)
> >        unsigned long iccfgr,dccfgr;
> >        unsigned long cache_set_size, cache_ways;;
> >
> > -       cpu = (struct device_node *) of_find_compatible_node(NULL,
> > -                                       NULL, "opencores,openrisc-1200");
> > +       cpu = of_find_compatible_node(NULL, NULL, "opencores,openrisc-1200");
> 
> This looks odd.  Is it a stale hunk from a previous patch version?
> 

Hmmm... no, it's a hunk that should have been in patch 01/19 of the
series.  That said, there's a bit of devicetree code in that patch too.
Can I just say, "please have a look there, too", or do I need to pull
those bits out into the devicetree patch?

I've pasted in just the relevant parts from patch 01/19 below for ease
of review.

/Jonas

>From arch/openrisc/kernel/setup.c:

+static inline unsigned int fcpu(struct device_node *cpu, char *n)
+{
+        const int *val;
+        return (val = of_get_property(cpu, n, NULL)) ? *val : 0;
+}
+
+void __init setup_cpuinfo(void)
+{
+       struct device_node *cpu = NULL;
+       unsigned long iccfgr,dccfgr;
+       unsigned long cache_set_size, cache_ways;;
+
+       cpu = (struct device_node *) of_find_compatible_node(NULL,
+                                       NULL,
"opencores,openrisc-1200");
+       if (!cpu) {
+               panic("No compatible CPU found in device tree...\n");
+       }
+
+       iccfgr = mfspr(SPR_ICCFGR);
+       cache_ways = 1 << (iccfgr & SPR_ICCFGR_NCW);
+       cache_set_size = 1 << ((iccfgr & SPR_ICCFGR_NCS) >> 3);
+       cpuinfo.icache_block_size = 16 << ((iccfgr & SPR_ICCFGR_CBS) >>
7);
+       cpuinfo.icache_size = cache_set_size * cache_ways *
cpuinfo.icache_block_size;
+
+       dccfgr = mfspr(SPR_DCCFGR);
+       cache_ways = 1 << (dccfgr & SPR_DCCFGR_NCW);
+       cache_set_size = 1 << ((dccfgr & SPR_DCCFGR_NCS) >> 3);
+       cpuinfo.dcache_block_size = 16 << ((dccfgr & SPR_DCCFGR_CBS) >>
7);
+       cpuinfo.dcache_size = cache_set_size * cache_ways *
cpuinfo.dcache_block_size;
+
+       cpuinfo.clock_frequency =  fcpu(cpu, "clock-frequency");
+
+       of_node_put(cpu);
+
+       print_cpuinfo();
+}
+
+/**
+ * or32_early_setup
+ *
+ * Handles the pointer to the device tree that this kernel is to use
+ * for establishing the available platform devices.
+ *
+ * For now, this is limited to using the built-in device tree.  In the
future,
+ * it is intended that this function will take a pointer to the device
tree
+ * that is potentially built-in, but potentially also passed in by the
+ * bootloader, or discovered by some equally clever means...
+ */
+
+void __init or32_early_setup(void) {
+
+       early_init_devtree((void *) __dtb_start);
+
+       printk(KERN_INFO "Compiled-in FDT at 0x%08x\n",
+              (unsigned int) __dtb_start);
+}
+
+const struct of_device_id openrisc_bus_ids[] = {
+        { .type = "soc", },
+        { .compatible = "soc", },
+        {},
+};
+
+static int __init openrisc_device_probe(void)
+{
+        of_platform_bus_probe(NULL, openrisc_bus_ids, NULL);
+        return 0;
+}
+device_initcall(openrisc_device_probe);




  parent reply	other threads:[~2011-07-04  4:58 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-02 21:15 OpenRISC Architecture: Patch set version 2 Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 01/19] OpenRISC: Boot code Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 02/19] OpenRISC: Device tree Jonas Bonn
2011-07-03 18:07   ` Segher Boessenkool
2011-07-03 20:51   ` Grant Likely
     [not found]     ` <CACxGe6tFX=EQjaL-4EjSXquY5eh+bca29=d=cE5-YAVCUVRCvA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-07-03 21:39       ` Benjamin Herrenschmidt
2011-07-03 21:39         ` Benjamin Herrenschmidt
2011-07-04  4:58     ` Jonas Bonn [this message]
2011-07-04  4:58       ` Jonas Bonn
2011-07-04  5:35       ` Grant Likely
2011-07-02 21:15 ` [PATCH v2 03/19] OpenRISC: Memory management Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 04/19] OpenRISC: Signal handling Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 05/19] OpenRISC: Build infrastructure Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 06/19] OpenRISC: PTrace Jonas Bonn
2011-07-03 19:40   ` Marcin Slusarz
2011-07-05 15:42   ` Arnd Bergmann
2011-07-05 16:05     ` Jonas Bonn
2011-07-05 16:42       ` Arnd Bergmann
2011-07-02 21:15 ` [PATCH v2 07/19] OpenRISC: DMA Jonas Bonn
2011-07-05 15:37   ` Arnd Bergmann
2011-07-08  7:36     ` Jonas Bonn
2011-07-08  7:36       ` Jonas Bonn
2011-07-08  7:44       ` Arnd Bergmann
2011-07-02 21:15 ` [PATCH v2 08/19] OpenRISC: Timekeeping Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 09/19] OpenRISC: IRQ Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 10/19] OpenRISC: System calls Jonas Bonn
2011-07-05 15:39   ` Arnd Bergmann
2011-07-02 21:15 ` [PATCH v2 11/19] OpenRISC: Idle/Power management Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 12/19] OpenRISC: Scheduling/Process management Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 13/19] OpenRISC: GPIO Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 14/19] OpenRISC: Module support Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 15/19] OpenRISC: Traps Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 16/19] OpenRISC: Headers Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 17/19] OpenRISC: Library routines Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 18/19] OpenRISC: Miscellaneous Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 19/19] OpenRISC: Add MAINTAINERS entry Jonas Bonn
2011-07-05 15:56 ` OpenRISC Architecture: Patch set version 2 Arnd Bergmann
2011-07-06 15:51   ` linux-next inclusion request: OpenRISC architecture Jonas Bonn
2011-07-16  3:55     ` Stephen Rothwell
     [not found]     ` <20110707163231.ebc75eef6be02f5490c949d7@canb.auug.org.au>
     [not found]       ` <201107071305.02061.arnd@arndb.de>
2011-07-16  4:01         ` arm-soc tree inclusion Stephen Rothwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1309755508.16393.18.camel@localhost \
    --to=jonas@southpole.se \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.