linux-arch.vger.kernel.org archive mirror
 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);

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

Thread overview: 47+ 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-02 21:15   ` 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   ` Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 05/19] OpenRISC: Build infrastructure Jonas Bonn
2011-07-02 21:15   ` 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: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:44       ` Arnd Bergmann
2011-07-02 21:15 ` [PATCH v2 08/19] OpenRISC: Timekeeping Jonas Bonn
2011-07-02 21:15   ` Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 09/19] OpenRISC: IRQ Jonas Bonn
2011-07-02 21:15   ` Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 10/19] OpenRISC: System calls Jonas Bonn
2011-07-02 21:15   ` 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   ` 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   ` Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 18/19] OpenRISC: Miscellaneous Jonas Bonn
2011-07-02 21:15   ` Jonas Bonn
2011-07-02 21:15 ` [PATCH v2 19/19] OpenRISC: Add MAINTAINERS entry Jonas Bonn
2011-07-02 21:15   ` Jonas Bonn
2011-07-05 15:56 ` OpenRISC Architecture: Patch set version 2 Arnd Bergmann

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).