On Tue, 2009-10-06 at 22:30 -0600, Grant Likely wrote:
> --- /dev/null
> +++ b/include/linux/of_fdt.h
> @@ -0,0 +1,30 @@
> +/*
> + * Definitions for working with the Flattened Device Tree data format
> + *
> + * Copyright (C) 1996-2005 Paul Mackerras.
> + *
> + * Updates for PPC64 by Peter Bergner
On Tue, 2009-11-24 at 09:37 -0800, David Miller wrote:
> From: Grant Likely
> Date: Tue, 24 Nov 2009 01:20:05 -0700
>
> > In struct device_node, the phandle is named 'linux_phandle' for PowerPC
> > and MicroBlaze, and 'node' for SPARC. There is no good reason for the
> > difference, it is just a
On Tue, 2009-11-24 at 01:17 -0700, Grant Likely wrote:
> Merge common code between PowerPC and Microblaze
>
> Signed-off-by: Grant Likely
> Reviewed-by: Wolfram Sang
> Tested-by: Michal Simek
Acked-by: Benjamin Herrenschmidt
Remind me how you want to merge that ? via my tree
On Tue, 2009-11-24 at 01:18 -0700, Grant Likely wrote:
> Merge common code between PowerPC and Microblaze
>
> Signed-off-by: Grant Likely
> ---
Ok with that, like the precendent, however you are making global some
symbols that were previously static which sucks a bit... But then they
can be made
On Tue, 2009-11-24 at 01:18 -0700, Grant Likely wrote:
> Merge common code between PowerPC and Microblaze
>
> Signed-off-by: Grant Likely
> ---
>
> arch/microblaze/kernel/prom.c |8
> arch/powerpc/kernel/prom.c|8
> drivers/of/fdt.c |8
>
On Tue, 2009-11-24 at 01:18 -0700, Grant Likely wrote:
> A cell is firmly established as a u32. No need to do an ugly typedef
> to redefine it to cell_t. Eliminate the unnecessary typedef so that
> it doesn't have to be added to the of_fdt header file
>
> Signed-off-by: Grant Likely
> ---
I'm
On Tue, 2009-11-24 at 01:19 -0700, Grant Likely wrote:
>
> -static int __init early_init_dt_scan_cpus(unsigned long node,
> - const char *uname, int depth,
> - void *data)
> +int __init early_init_dt_scan_cpus(unsigned l
On Tue, 2009-11-24 at 01:19 -0700, Grant Likely wrote:
> Merge common code between PowerPC and Microblaze
I don't like moving this one to common code without the of_ prefix. I
think you should move it with the of_ prefix, and then add a alias in
powerpc and microblaze without of_ in a header until
On Tue, 2009-11-24 at 01:19 -0700, Grant Likely wrote:
>
> +#if !defined(CONFIG_SPARC) /* SPARC doesn't do ref counting (yet) */
> +/**
Make this a Kconfig symbol, something like CONFIG_OF_DYNAMIC. You need
refcounting when you can add/remove nodes dynamically. Some embedded
archs might want
On Tue, 2009-11-24 at 01:19 -0700, Grant Likely wrote:
> Merge common code between PowerPC and Microblaze
Some of those guys might wnat to be in of_dynamic (see previous email)
Remember: We want to keep the footprint low for embedded archs that
don't want to do dynamic stuff. Really low.
Cheers,
On Wed, 2009-11-25 at 21:05 -0700, Grant Likely wrote:
>
> You're right, it's not, but makes merging less complex, and then I can
> refactor properly.
Still, make them __be32 at least
Cheers,
Ben.
___
devicetree-discuss mailing list
devicetree-discus
On Wed, 2009-11-25 at 23:28 -0700, M. Warner Losh wrote:
> In message:
>
> Grant Likely writes:
> : Word from Mitch is the device tree is network byte order. period.
>
> OpenFirmware defines the order to be big endian always, even on little
> endian processors.
Right, that's the on
On Thu, 2009-11-26 at 22:36 +0100, Segher Boessenkool wrote:
> >> You're right, it's not, but makes merging less complex, and then I
> >> can
> >> refactor properly.
> >
> > Still, make them __be32 at least
>
> There is no alignment guarantee at all either, better make it all u8
> and use access
On Wed, 2009-12-09 at 16:15 -0800, David Miller wrote:
> From: Grant Likely
> Date: Wed, 9 Dec 2009 15:06:29 -0700
>
> > 1) of_platform will be deprecated in preference of the platform bus.
>
> What a shame, it's one of the cleanest driver probing models
> in the tree.
It is indeed. However, I'
On Thu, 2009-12-10 at 12:45 +1100, Benjamin Herrenschmidt wrote:
> I don't agree with grant idea however that just converting the content
> of the device node into properties is the way to go.
And here of course I meant " converting the content of the device node
into into pd
> The key to the solution IMHO is the ability to create an of_platform_device
> in a hardcoded way without data from a device tree, like we create a
> platform_device today. All these static of_devices would then be rooted
> in /sys/platform by default, while those that come from a device tree are
On Thu, 2010-01-07 at 11:50 +1100, David Gibson wrote:
> On Tue, Jan 05, 2010 at 04:28:12PM -0700, Yoder Stuart-B08248 wrote:
> >
> > The current open-pic binding defines that interrupt specifiers
> > have 2 cells-- an interrupt number and level/sense encoding.
> >
> > With chips like the P4080 t
yuki
> Cc: Mel Gorman
> Cc: Lee Schermerhorn
Acked-by: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Dave Hansen
> Cc: Milton Miller
> Cc: Nathan Fontenot
> Cc: Geoff Levand
> Cc: Grant Likely
> Cc: J. Bruce Fields
> Cc: Neil Brown
> Cc: Trond Myklebu
t; belongs in of.h instead of of_fdt.h
> of_machine_is_compatible()
> prom_add_property()
> prom_remove_property()
> prom_update_property()
>
> Signed-off-by: Grant Likely
Acked-by: Benjamin Herrenschmidt
> ---
>
> include/linux/of.h |8
>
necessary #include to get THIS_MODULE defined.
> While we could just replace it with NULL (PROC_FS is a bool, not a
> tristate), using THIS_MODULE will prevent unexpected breakage if we
> ever do compile this as a module.
>
> Signed-off-by: Jeremy Kerr
> Signed-off-by: Gra
ncluded, we need asm/page.h for __va.
>
> Signed-off-by: Jeremy Kerr
> Signed-off-by: Grant Likely
Acked-by: Benjamin Herrenschmidt
> ---
>
> arch/microblaze/kernel/prom.c |5 +
> arch/powerpc/kernel/prom.c|5 +
> drivers/of/fdt.c |
On Sat, 2010-02-13 at 09:02 -0700, Grant Likely wrote:
> Most architectures don't need to change these. Put them into common
> code to eliminate some duplication
>
> Signed-off-by: Grant Likely
> ---
Acked-by: Benjamin Herrenschmidt
>
> arch/microblaze
On Sat, 2010-02-13 at 09:02 -0700, Grant Likely wrote:
> Neither the powerpc nor the microblaze code use devtree_lock anymore.
> Remove the extern reference.
>
> Signed-off-by: Grant Likely
> ---
Acked-by: Benjamin Herrenschmidt
> arch/microblaze/include/asm/prom.h |2
ed there too.
>
> This patch removes the SPARC declarations and uses decls in of.h instead.
>
> Signed-off-by: Grant Likely
Acked-by: Benjamin Herrenschmidt
> ---
>
> arch/sparc/kernel/prom.h |3 ---
> include/linux/of.h |2 ++
> 2 files changed, 2 insert
On Sat, 2010-02-13 at 09:03 -0700, Grant Likely wrote:
> Neither request_OF_resource or release_OF_resource are defined
> anywhere. Remove the declarations.
>
> Signed-off-by: Grant Likely
> ---
Acked-by: Benjamin Herrenschmidt
> arch/microblaze/include/asm/prom.h |
On Sat, 2010-02-13 at 09:03 -0700, Grant Likely wrote:
> Rather than defining of_chosen in each arch, it can be defined for all
> in driver/of/base.c
>
> Signed-off-by: Grant Likely
Acked-by: Benjamin Herrenschmidt
> ---
>
> arch/microblaze/include/asm/prom.h |2
On Sat, 2010-02-13 at 09:02 -0700, Grant Likely wrote:
> From: Jeremy Kerr
>
> For platforms that have CONFIG_OF optional, we need to make the contents
> of linux/of.h conditional on CONFIG_OF.
>
> Signed-off-by: Jeremy Kerr
> Signed-off-by: Grant Likely
Acked-by: B
On Fri, 2010-02-26 at 16:07 -0700, John Linn wrote:
> Hi all,
>
> We are in the process of putting PCI/PCIe into the microblaze
> architecture.
>
> In order to not duplicate/fork the PCI code in Powerpc, we're proposing
> to move the PCI code from arch/powerpc into drivers/of such that it
> wou
On Fri, 2010-02-26 at 15:44 -0800, Jesse Barnes wrote:
>
> Dave and Ben have been talking about this for awhile; seems like a
> good
> excuse to do it. IIRC they had even thought about just dumping the
> code directly into drivers/pci so that API updates won't get
> missed...
Depends which part
At some stage, Grant wrote:
> > First off, I did a tiny amount of research, and I didn't find any
> > existing OpenFirmware bindings for describing video displays.
> > Otherwise, I'd suggest considering that.
There's a binding for framebuffers but it sucks big time :-) It doesn't
provide a reliab
evice is compatible with both
"foo" and "foo1", then the device should have both strings in its
"compatible" property.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/include/asm/prom.h |8
1 files changed, 8 insertions(+), 0 deletions(-)
dif
e should have both strings in its
> > "compatible" property.
> >
> > Signed-off-by: Benjamin Herrenschmidt
> > (for patch description)
> > Signed-off-by: Grant Likely
>
> Acked-by: David S. Miller
BTW. While at it... sparc still has it'
On Wed, 2010-04-28 at 17:13 -0500, Timur Tabi wrote:
> On Wed, Apr 28, 2010 at 4:58 PM, Grant Likely
> wrote:
>
> > The sound0 node needs a compatible value,
>
> I knew I was forgetting something
>
> > the sound-device node should
> > probably have one too.
>
> The aliases, cpus, and memory n
On Wed, 2010-05-19 at 14:53 -0500, Timur Tabi wrote:
> Add the DTS_PADDING Kconfig option, which allows users and board defconfig
> files to specify a padding value when compiling device trees.
>
> When a device tree source (DTS) is compiled into a binary (DTB), a hard-coded
> padding of 1024 byte
On Wed, 2010-05-19 at 16:33 -0500, Timur Tabi wrote:
> Benjamin Herrenschmidt wrote:
>
> >> So to accommodate future boards where more padding is needed, we make the
> >> option for the -p parameter configurable.
> >
> > Can't u-boot just allocate
On Wed, 2010-05-19 at 19:03 -0500, Timur Tabi wrote:
> The problem is that the code which allocates a block for the fdt is
> completely distinct from the code that manipulates the fdt. We'd need
> to put in either some kind of funky callback mechanism, or insist that
> every fdt exist in a block o
> The patch looks okay to me.
>
> BTW, where is the i8042 binding documented? Ben, is this location of
> the kbd/mouse irq historical, or is it just something that we happened
> to get when the .dts files were first created? Having the irq
> specified directly in the kbd or aux nodes would make
> You just introduced an unnamed structure of device + resources,
> it isn't declared anywhere but in the code itself (either via
> &foo[1] or buf + sizeof(*foo)).
>
> You're not the only one who hacks (or at least have to
> understand) the OF stuff, so let's try keep this stuff
> readable?
>
>
CC: "David S. Miller"
> CC: Stephen Rothwell
Acked-by : Benjamin Herrenschmidt
> CC: Jeremy Kerr
> CC: microblaze-ucli...@itee.uq.edu.au
> CC: linuxppc-...@ozlabs.org
> CC: sparcli...@vger.kernel.org
> CC: devicetree-discuss@lists.ozlabs.org
> ---
> arch/m
t; them just makes the code much harder to follow.
Also, if we stick to your approach the "default" variant should either
be an inline protected by an ifndef or a weak function.
Cheers,
Ben.
> Signed-off-by: Grant Likely
> CC: Michal Simek
> CC: Benjamin Herrenschmidt
On Fri, 2010-06-04 at 15:21 -0600, Grant Likely wrote:
> Merge common code between PowerPC and Microblaze
>
> Signed-off-by: Grant Likely
> CC: Michal Simek
> CC: Wolfram Sang
> CC: Stephen Rothwell
Acked-by : Benjamin Herrenschmidt
I haven't double checked that
reakup of functions causes more
complication and bloat than just keeping the quirks in the generic code.
Cheers,
Ben.
> Signed-off-by: Grant Likely
> CC: Michal Simek
> CC: Wolfram Sang
> CC: Stephen Rothwell
> CC: Benjamin Herrenschmidt
> CC: microblaze-ucli...@it
add it to the quirk list (which should really be
made generic) so I can disable it on more 'modern' powerpc as well.
Cheers,
Ben.
> Signed-off-by: Grant Likely
> CC: Stephen Rothwell
> CC: Benjamin Herrenschmidt
> CC: linuxppc-...@lists.ozlabs.org
> CC: devicetree-
On Thu, 2010-06-10 at 08:28 -0600, Grant Likely wrote:
> On Thu, Jun 10, 2010 at 12:44 AM, Benjamin Herrenschmidt
> wrote:
> > On Tue, 2010-06-08 at 08:10 -0600, Grant Likely wrote:
> >> Certain Apple machines don't use the ranges property correctly, but the
> >&g
On Thu, 2010-06-10 at 10:01 -0600, M. Warner Losh wrote:
> : Oh, come on. Both constructions are binary equivalent.
> :
> : So how can people seriously be with *that* code:
> :
> : dev->resource = (void *)&dev[1];
> :
> : which, semantically, is a nonsense and asks for a fix.
>
> It isn't
On Thu, 2010-06-10 at 17:36 -0600, Grant Likely wrote:
>
> Okay. I had been trying to avoid #ifdefs in the common code, but
> you're probably right. I'll rework.
Not even ifdef's ... just move the quirk map there. You can always
#define the quirk variable to 0 on archs that have no quirks, to
On Fri, 2010-06-11 at 09:30 +0800, jxnuxdy wrote:
> Hi guys,
>
> I encountered a PCIe problem under linux, the two PCIe bus on my board seems
> work,
> at least I can access the registers through the PCIe bus, however the dma for
> the
> PCIe bus can't work, so I just dumped the pci device, but
On Fri, 2010-06-11 at 16:47 -0700, Dan Malek wrote:
> Hi Grant.
>
> On Jun 11, 2010, at 3:59 PM, Grant Likely wrote:
>
> > I've been doing a bit of work on some introductory level documentation
> > of the flattened device tree.
>
> Wow, I feel empowered to create device trees now :-)
> Seriously
On Fri, 2010-06-11 at 16:59 -0600, Grant Likely wrote:
> I've been doing a bit of work on some introductory level documentation
> of the flattened device tree. I've got a rough copy up on the
> devicetree.org wiki, and I could use some feedback. If anyone has
> some time to look at it, you can fi
On Sat, 2010-06-12 at 13:00 +1000, Benjamin Herrenschmidt wrote:
>
> Quite nice. Maybe the introduction could use a very quick blurb on
> the
> various data types that dtc supports for properties, and something on
> labels & phandles (references to nodes).
>
> I just
On Fri, 2010-06-11 at 22:19 -1000, Mitch Bradley wrote:
> It seems that many of the differences at the CPU level can be determined
> by looking at "coprocessor" registers. For what purpose(s) do we need
> to identify the core? That will inform our choice of a core ID schema.
The primary thing
On Sat, 2010-06-12 at 20:45 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2010-06-11 at 22:19 -1000, Mitch Bradley wrote:
> > It seems that many of the differences at the CPU level can be determined
> > by looking at "coprocessor" registers. For what purpose(s) do we
On Sat, 2010-06-12 at 06:30 -1000, Mitch Bradley wrote:
> I'm certainly going to try keeping OFW alive. On the x86 OLPC machines,
> the ability to
> dive into OFW via a SysRq key combo was very helpful for debugging some
> difficult
> problems. The team has asked me to support the feature on A
On Sat, 2010-06-12 at 23:07 -0600, Grant Likely wrote:
>
> What is needed to keep OFW alive? I've got no problem with doing so
> if it isn't invasive, and as long as the same boot entry interface can
> be used.
Well, no. OF has a well defined "client interface" which is what gets us
in prom_init
On Sat, 2010-06-12 at 19:39 -1000, Mitch Bradley wrote:
> Minimally, OFW needs to own some memory that the kernel won't steal.
> OFW on ARM is position-independent, so it can be tucked up at the top of
> memory
> fairly easily.
Amen :-)
> To call back into OFW, the virtual mapping for that m
On Sat, 2010-06-12 at 20:45 -1000, Mitch Bradley wrote:
> Either fought or embraced. To the extent that it is possible to focus
> solely on Linux and ARM, one could image doing a good HAL.
That will come with a huge amount of comunity resistance sadly, but I
can imagine distros liking it.
In g
On Sat, 2010-06-12 at 20:45 -1000, Mitch Bradley wrote:
> > BTW. I notice no ARM list is CCed on this discussion ... maybe we
> should
> > fix that ?
> >
>
> Sounds like a good idea. Do you know which list(s) would be good
> candidates?
Forgot to reply to that one ... I'd say
linux-arm-ker
On Sun, 2010-06-13 at 23:13 -0600, Grant Likely wrote:
> > We use that to suck the device-tree, which we flatten, and then
> re-enter
> > the kernel with the "common" entry interface.
>
> I don't think I want to do the same on ARM. I'd rather have the
> prom_init stuff in a boot wrapper, or have
On Mon, 2010-06-14 at 10:25 +0100, Russell King - ARM Linux wrote:
> On Sun, Jun 13, 2010 at 09:45:50PM -1000, Mitch Bradley wrote:
> > None of this is a deal-breaker for the kind of debugging tasks that are
> > the primary use case for the callback.
>
> Would you mind explaining what kind of ta
scale parts, so I'll let others comment
on your settings since it's most likely to be where the problem is.
Cheers,
Ben.
>
> Many thanks,
> Denny
> ----
>
On Tue, 2010-06-15 at 18:23 +0200, Segher Boessenkool wrote:
> >> Certain Apple machines don't use the ranges property correctly,
> >> but the
> >> workaround should not be applied on other architectures. This patch
> >> disables the workaround for non-powerpc architectures.
> >
> > I'm half tem
On Thu, 2010-06-17 at 17:11 -0600, Grant Likely wrote:
> On Thu, Jun 10, 2010 at 7:17 PM, Benjamin Herrenschmidt
> wrote:
> > On Thu, 2010-06-10 at 17:36 -0600, Grant Likely wrote:
> >>
> >> Okay. I had been trying to avoid #ifdefs in the common code, but
> >&
> Sounds like we have a winner. I'll concentrate on that, thanks for
> the heads up.
Note that the conversion from OF -> fdt that powerpc does is a bit
"special". The code isn't quite a "wrapper" but almost. It shared pretty
much no symbols or variables with the rest of the kernel.
There are va
On Wed, 2010-07-14 at 17:31 -0600, Grant Likely wrote:
> There's no reason to use the powerpc-specific _ALIGN macro in the fdt
> code. Replace it with ALIGN() from kernel.h
>
> Signed-off-by: Grant Likely
Acked-by: Benjamin Herrenschmidt
> ---
> arch/microblaze/in
On Wed, 2010-07-14 at 17:31 -0600, Grant Likely wrote:
> Signed-off-by: Grant Likely
Acked-by: Benjamin Herrenschmidt
> ---
> arch/microblaze/include/asm/of_platform.h |2 --
> arch/microblaze/kernel/of_platform.c | 18 --
> arch/powerpc/include/as
On Wed, 2010-07-14 at 17:31 -0600, Grant Likely wrote:
> This patch fixes the condition where device tree support is compiled
> in, but no device tree was proved by firmware. It makes
> of_platform_bus_probe() explicitly check for a NULL device tree
> pointer, and adds an error message if the devi
ER and redefine IRQF_TIMER in terms of these new flags.
>
> Signed-off-by: Ian Campbell
> Cc: Thomas Gleixner
> Cc: Jeremy Fitzhardinge
> Cc: Dmitry Torokhov
Acked-by: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Grant Likely
> Cc: xen-de...@lists.xensource.com
> Cc:
Campbell
> Cc: Thomas Gleixner
Acked-by: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Grant Likely
> Cc: linuxppc-...@ozlabs.org
> Cc: devicetree-discuss@lists.ozlabs.org
> ---
> arch/powerpc/platforms/powermac/low_i2c.c |5 +++--
> drivers/macintosh/via-pm
On Tue, 2010-09-21 at 16:57 -0300, Grant Likely wrote:
> On Tue, Sep 21, 2010 at 7:25 AM, Shaju Abraham
> wrote:
> > Hi Grant
> >
> > Since there does not exist a mechanism to map the hw irq to linux irq
> > on ARM (device tree), I would like to discuss with you the plans or
> > ideas to impleme
On Wed, 2010-09-22 at 00:08 -0300, Grant Likely wrote:
> > Add all the I2C, SPI based irq extenders to that list. They seem to
> > pop up all over the place in rapid speed even in x86. We are happy
> > citizens of the embedded horror^Wuniverse now.
>
> *shudder*
>
> What's the irq handling latenc
On Thu, 2010-09-23 at 19:31 +0200, Richard Cochran wrote:
> A new syscall is introduced that allows tuning of a POSIX clock. The
> syscall is implemented for four architectures: arm, blackfin, powerpc,
> and x86.
>
> The new syscall, clock_adjtime, takes two parameters, the clock ID,
> and a point
On Fri, 2010-09-24 at 00:12 +0200, Thomas Gleixner wrote:
> > This list is getting way too much unrelated stuff, which I find
> > annoying, it would be nice if we were all a bit more careful here
> with
> > our CC lists.
>
> Says the guy who missed to trim the useless context of the original
> mai
> > This list is getting way too much unrelated stuff, which I find
> > annoying, it would be nice if we were all a bit more careful here with
> > our CC lists.
>
> Sorry, I only added device-tree because some one asked me to do so.
>
> http://marc.info/?l=linux-netdev&m=127273157912358
>
>
On Sat, 2010-10-02 at 21:15 -0600, Grant Likely wrote:
>
> But I won't merge this through my tree unless Ben asks me to.
Being careful heh ? :-)
I'll take care of these.
Cheers,
Ben.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozla
On Thu, 2010-11-25 at 15:01 +0100, Geert Uytterhoeven wrote:
>
> I always read it as "for each child-OF-node", so I would rename it to
> "dt_for_each_child_node".
Well, it was meant to be for_child_of_node not _OF_node :-)
Cheers,
Ben.
___
devicetree
On Fri, 2010-11-26 at 15:19 +0100, Sebastian Andrzej Siewior wrote:
> AFAIK Benh was thinking about renaming it. I don't know if this is
> still
> the case or when he intends to do so. Once he does so, this can be
> renamed
> as well.
That and moving the powerpc code to a generic place so you don
On Thu, 2010-11-25 at 18:39 +0100, Sebastian Andrzej Siewior wrote:
> This patch adds minimal support for device tree support on x86. It will
> be passed to the kernel via setup_data which requires atleast boot
> protocol 2.09.
> Memory size, restricted memory regions, boot arguments are gathered t
> + */
> +/dts-v1/;
> +/ {
> + model = "x86,CE4100";
> + compatible = "x86,CE4100";
Use a vendor name rather than "x86" here.
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + x86,a...@0 {
"Atom" would benefit from being more precise, like addin
On Thu, 2010-11-25 at 18:39 +0100, Sebastian Andrzej Siewior wrote:
> x86_of_pci_init() does two things:
> - it provides a generic irq enable and disable function. enable queries
> the device tree for the interrupt information, calls ->xlate on the
> irq host and updates the pci->irq informatio
On Sun, 2010-11-28 at 14:49 +0100, Sebastian Andrzej Siewior wrote:
>
> >(*) That brings a separate topic we shall discuss: A consistent way for
> >versionning the device-tree would be really useful.
> This isn't a problem unless you move nodes or deprecate them, right? Or
> do you think about ano
On Sun, 2010-11-28 at 15:04 +0100, Sebastian Andrzej Siewior wrote:
> Microblaze had its own copy of this code so I though there is
> something
> specific about it. If it is okay with you, I would move it to
> drivers/of
> and share. Then I would have the swizzle part :)
Appart from the accessor p
On Sun, 2010-11-28 at 17:04 +0100, Sebastian Andrzej Siewior wrote:
> * Benjamin Herrenschmidt | 2010-11-27 08:57:25 [+1100]:
>
> >> + */
> >> +/dts-v1/;
> >> +/ {
> >> + model = "x86,CE4100";
> >> + compatible = "x8
On Mon, 2010-11-29 at 10:26 -0800, H. Peter Anvin wrote:
> > The OLPC interface might be of some use as a starting point, but would
> > need some work. It is currently in use on AMD Geode, Via C7, and Intel
> > Atom based systems, but, among other issues, it conflicts with the
> > Physical Addr
On Mon, 2010-11-29 at 13:07 -0600, Scott Wood wrote:
>
> The motivation for simple-bus comes from Linux, but its definition is
> OS-neutral. It indicates that no special bus knowledge is required to
> access the devices under it.
That's never 100% true. In the case of ISA it's even less true due
On Mon, 2010-11-29 at 20:36 +0100, Sebastian Andrzej Siewior wrote:
>
> This also works with the flat tree, right?
Yes, of course. You use similar references in your interrupt-map :-)
> Okay, so we want this for a quirk at a later point in time. Now I
> understand.
More precisely, if something
On Mon, 2010-11-29 at 10:32 -1000, Mitch Bradley wrote:
> The usual layout is that the PCI bus is a direct child of
> the root node, and the ISA bus is a child of the PCI bus.
Right, tho we have been relaxing that on SoC for some time now, at least
on powerpc, since the PCI bus itself tend to hang
On Mon, 2010-11-29 at 23:47 +, Alan Cox wrote:
>
> That may not be wise. Your real bus heirarchy may not be architecturally
> defined on some systems so you can't incorporate it into code, nor is it
> necessarily a heirarchy - eg some of the Geodes.
Ok, so I'd suggest doing something like:
On Tue, 2010-11-30 at 12:51 +0100, Sebastian Andrzej Siewior wrote:
> My PCI node does not have a reg property but its child nodes.
> In x86_of_pci_init() [0] I walk through the PCI child nodes, read the reg
> property of each node which gives me the devfn of the device. I pass this
> pci_get_slot
On Fri, 2010-12-17 at 16:33 +0100, Sebastian Andrzej Siewior wrote:
> +
> +#if defined(CONFIG_PPC64) || defined(CONFIG_X86)
> +static struct device_node *pci_get_parent_node(struct pci_dev *pdev)
> +{
> + return pci_bus_to_OF_node(pdev->bus);
> +}
> +#endif
> +
> +#if defined(CONFIG_PPC32) ||
://lists.ozlabs.org/pipermail/devicetree-discuss/2011-January/004043.html
> [4]
> http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-February/004254.html
>
> Signed-off-by: Meador Inge
> Cc: Hollis Blanchard
> Cc: Benjamin Herrenschmidt
> ---
> arch/powerpc/include/
ng
that to take the powerpc patch at the end (that adds the entry to
the .dts file) with my
Acked-by: Benjamin Herrenschmidt
Cheers,
Ben.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
On Sun, 2011-02-06 at 19:32 -0600, Meador Inge wrote:
> So barring the removal of protected sources, does the inclusion of the
> "pic-no-reset" property seem reasonable?
Sure.
Ben.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.o
> In addition to the reserved regions block in the header, define a set
> of properties in the memory node that specify the reserved regions
> with the name reflecting the usage.
> For example:
>
> memory@0 {
> device_type = "memory";
> reg = <0 0x4000>;
>
> In my previous reply I said that "it is not so much as a need as it is a
> potential simplification." After further reflection, I don't think that
> is completely true. As we get into AMP systems with higher core counts,
> then implementing this functionality using the existing
> "protecte
On Mon, 2011-02-07 at 14:45 -0700, Grant Likely wrote:
> On Mon, Feb 7, 2011 at 2:39 PM, Benjamin Herrenschmidt
> wrote:
> >
> >> In addition to the reserved regions block in the header, define a set
> >> of properties in the memory node that specify the reser
On Mon, 2011-02-07 at 22:05 -0700, Grant Likely wrote:
>
> Hmmm, of all the ideas, I think I like this one the best. It is a
> little more verbose than I was thinking, but making each reserved
> region (or set of reserved regions) have separate node has some very
> real advantages. For one, the
On Thu, 2011-02-24 at 15:46 +0100, Arnd Bergmann wrote:
> On Wednesday 23 February 2011, Grant Likely wrote:
> > arch/powerpc/kernel/ibmebus.c is the only remaining user of the
> > of_bus_type support code for initializing the bus and registering
> > drivers. All others have either been switched t
On Fri, 2011-02-25 at 12:22 -0700, Grant Likely wrote:
> Hi Arnd and Ben,
>
> I forgot to cc you guys on this patch. Greg has it in his tree, but I
> wanted to make sure you noticed it. If you have any objections, let
> me know and I'll ask Greg to drop it.
No objection. Device-types are a thin
On Fri, 2011-02-25 at 08:22 -0700, Grant Likely wrote:
>
> Generally I've applied the argument that it's a good idea to populate
> the /cpus node as an anchor for future things that might require it.
> For example, a theoretical hypervisor which doesn't allow the guest
> access to all the CPUs wou
> diff --git a/arch/powerpc/include/asm/mpic.h b/arch/powerpc/include/asm/mpic.h
> index e000cce..7e1be12 100644
> --- a/arch/powerpc/include/asm/mpic.h
> +++ b/arch/powerpc/include/asm/mpic.h
> @@ -325,6 +325,8 @@ struct mpic
> #ifdef CONFIG_PM
> struct mpic_irq_save*save_data;
> #end
1 - 100 of 221 matches
Mail list logo
