Minor nit below
Acked-by: Stephen Neuendorffer
Steve
> -Original Message-
> From: linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org
[mailto:linuxppc-dev-
> bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of Grant
Likely
> Sent: Tuesday, Februar
> -Original Message-
> From: linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org
[mailto:linuxppc-dev-
> bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of Grant
Likely
> Sent: Sunday, January 30, 2011 11:46 PM
> To: devicetree-disc...@lists.ozlabs.org;
linuxppc-
gned-off-by: Grant Likely
>
reviewed-by: Stephen Neuendorffer
minor nits below.
> ---
> arch/powerpc/platforms/40x/ppc40x_simple.c| 13 +++---
> arch/powerpc/platforms/512x/mpc5121_generic.c | 13 +-
> arch/powerpc/platforms/52xx/lite5200.c| 16 +
On Sun, Nov 28, 2010 at 4:38 PM, Benjamin Herrenschmidt <
b...@kernel.crashing.org> wrote:
> On Wed, 2010-09-08 at 09:41 -0700, Ira W. Snyder wrote:
> > This adds basic support for the system controller FPGA on the OVRO CARMA
> > board. This patch only adds infrastructure that will be used by late
> -Original Message-
> From: David Daney [mailto:dda...@caviumnetworks.com]
> Sent: Wednesday, November 24, 2010 9:18 AM
> To: Stephen Neuendorffer
> Cc: mich...@ellerman.id.au; LKML; linux-mips;
> microblaze-ucli...@itee.uq.edu.au; devicetree-
> disc...@lists.ozl
> -Original Message-
> From: linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org
> [mailto:linuxppc-dev-
> bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of Michael
> Ellerman
> Sent: Wednesday, November 24, 2010 6:04 AM
> To: LKML
> Cc: linux-mips; microblaze
Move unflatten_dt_node to be grouped with non-__init functions.
Signed-off-by: Stephen Neuendorffer
---
drivers/of/fdt.c | 218 +++---
1 files changed, 109 insertions(+), 109 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index
Testing patch to verify that the device tree code can be compiled on X86.
---
arch/x86/Kconfig |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index cea0cd9..0f2ed5b 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -59,6 +59,8 @@
unflatten_dt_node is a helper function that does most of the work to
convert a device tree blob into tree of device nodes. This code
now uses a passed-in blob instead of using the single boot-time blob,
allowing it to be called in more contexts.
Signed-off-by: Stephen Neuendorffer
---
V2
In preparation for providing run-time handling of device trees, factor
out some of the basic functions so that they take an arbitrary blob,
rather than relying on the single boot-time tree.
Signed-off-by: Stephen Neuendorffer
--
V2: functions have of_fdt_* names
removed find_flat_dt_string
implement a driver-visible
fdt_unflatten_tree function, which can be used to unflatten a
blob after boot time.
Signed-off-by: Stephen Neuendorffer
--
V2: remove extra __va() call
make dt_alloc functions return void *. This doesn't fix the general
strangeness in this code
A few support device-tree related support functions that x86 didn't
have before.
Signed-off-by: Stephen Neuendorffer
Looks like just some irq related junk left!
---
arch/x86/include/asm/irq.h |2 ++
arch/x86/kernel/irq.c | 11 +++
2 files changed, 13 insertions(
compile it.
This also means that some of the requirements in the early code (such as
a cmd_line variable) that most architectures (e.g. X86) don't provide
can be ignored.
Signed-off-by: Stephen Neuendorffer
Grant,
We had discussed doing something like this a lng time ago. This (
and 4-7 are the interesting bits.
Patch 2 and 3 provide the ability to use this code on x86, and are provided
mostly for reference.
The non-early boot code has been compile-tested and executed on X86.
Stephen Neuendorffer (7):
fdt: Add Kconfig for EARLY_FLATTREE
arch/x86: Add support for
> -Original Message-
> From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
> Sent: Monday, June 28, 2010 7:39 PM
> To: Stephen Neuendorffer
> Cc: grant.lik...@secretlab.ca; devicetree-disc...@lists.ozlabs.org;
David Miller;
> sparcli...@vger.kernel.org; Michal Sime
> -Original Message-
> From: linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org
> [mailto:linuxppc-dev-
> bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of Grant Likely
> Sent: Wednesday, June 16, 2010 1:02 PM
> To: Sergey Temerkhanov
> Cc: linuxppc-dev@lists.oz
It seems to me like what's confused in the defconfigs is two concepts:
1) The requirements of a platform (what options must be set and must not
be set)
2) The guarantee that a particular config was known to work at some
point in time.
The first could allow you to drop 99% of the options (I think t
> -Original Message-
> From: linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org
[mailto:linuxppc-dev-
> bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of John
Linn
> Sent: Friday, March 12, 2010 5:06 PM
> To: net...@vger.kernel.org; linuxppc-...@ozlabs.org;
gra
> -Original Message-
> From: linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org
[mailto:linuxppc-dev-
> bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of Alon
Ziv
> Sent: Thursday, November 19, 2009 4:57 AM
> To: Stephen Neuendorffer; linuxppc
> -Original Message-
> From: linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org
[mailto:linuxppc-dev-
> bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of Arnd
Bergmann
> Sent: Thursday, November 19, 2009 9:33 AM
> To: Stephen Neuendorffer
> C
NAK.
If the problem is in the device trees that are being generated, we
should fix the issue there.
We've been trying to avoid putting the fully specified IP versions in
the kernel like this, since
the IP changes so often.
Steve
> -Original Message-
> From: linuxppc-dev-bounces+stephen=
> -Original Message-
> From: linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org
[mailto:linuxppc-dev-
> bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of Alon
Ziv
> Sent: Thursday, November 19, 2009 4:47 AM
> To: Arnd Bergmann; linuxppc-dev@lists.ozlabs.org
> S
Alon,
There are at least two other ways that you might be able to reset a
board:
1) Internally through the ICAP device.
2) Through a GPIO connected externally to the reset logic.
Part of this is board specific, part of is it design specific.
Probably it would be best to have a mechanism in the d
> -Original Message-
> From: linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org
> [mailto:linuxppc-dev-
> bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of Grant Likely
> Sent: Monday, November 09, 2009 1:22 PM
> To: Richard Röjfors
> Cc: spi-devel-gene...@lis
el free. And also feel free to add my:
>
> Acked-by: David S. Miller
>
> to your patches.
>
Thanks for doing this, Grant It's definitely needed.
Acked-by: Stephen Neuendorffer
Steve
This email and any attachments are intended for the sole use of the named
recipient(s) a
Sorry... you're right... brain fart on my part.. :)
Steve
> -Original Message-
> From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] On Behalf Of Grant
> Likely
> Sent: Thursday, August 20, 2009 10:45 AM
> To: Stephen Neuendorffer
> Cc: John Linn; net...@vg
John,
I just got a chance to browse this... Do you want to put in the
stripped device names?
.compatible = "xlnx,xps-ethernetlite-2", etc...
Steve
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be propri
> -Original Message-
> From: linuxppc-dev-bounces+stephen.neuendorffer=xilinx@ozlabs.org
[mailto:linuxppc-dev-
> bounces+stephen.neuendorffer=xilinx@ozlabs.org] On Behalf Of Grant
Likely
> Sent: Thursday, May 21, 2009 9:25 AM
> To: linuxppc-dev@ozlabs.org; Roderick Colenbrander
>
> 1) Probe the host controller in an of_platform driver. This has the
> advantage of simplicity. The probe routine will get automatically
> called when the PCI host controller device tree node is registered
> with the of_platform bus. The bus parenthood also gets reflected in
> the device model
>> Um.. one thing I'm missing in this discussion of attaching the dtb to
>> the bitstream: I don't see how the bitstream becomes accessible to
>> the kernel at runtime. Unless you were exposing the dtb as part of
>> the fpga programming, but I thought you explicitly weren't doing that
>> because
Another possibility is to pad the DTB with a DESYNC command and the correct pad
frame, just in case it cannot be prevented.
Steve
> -Original Message-
> From: Grant Likely [mailto:grant.lik...@secretlab.ca]
> Sent: Monday, May 11, 2009 10:30 PM
> To: Stephen Neuendorffer
&
> -Original Message-
> From: David H. Lynch Jr. [mailto:dh...@dlasys.net]
> Sent: Monday, May 11, 2009 7:35 PM
> To: Stephen Neuendorffer; linuxppc-dev@ozlabs.org
> Subject: Re: device trees.
>
> Stephen Neuendorffer wrote:
> >
> >> Many of our sys
> >>The best alternative to creating the device tree dynamically
would
> >> be to
> >>append the devicetree to the bitimage in a way the boot loader
could
> >> always find it.
> >>
> >
> > That sounds like a good solution to me.
> >
> I am glad you like it. If Xilinx would like to offe
> You *could* generate the device tree dynamically, but I think that is
> a path of diminishing returns considering that generating a .dts at
> the same time as bitstream creation time is cheap and it is small. At
> one time Steven Neuendorffer was playing with a scheme to preload a
> section of
...@itee.uq.edu.au
Cc: grant.lik...@secretlab.ca; Stephen Neuendorffer; linuxppc-dev;
linux-ker...@vger.kernel.org; John Linn
Subject: Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable
drivers for Microblaze
On Sun, Apr 19, 2009 at 12:41 PM, Stephen Neuendorffer
wrote:
>
>
> On
On Fri, Apr 17, 2009 at 10:49 PM, Grant Likely wrote:
> On Fri, Apr 17, 2009 at 11:06 AM, Stephen Neuendorffer
> wrote:
> >
> > Can we have XILINX_DRIVERS, please? That way this can also be enabled
> > on any architecture that has FPGA peripherals.
>
> I'
> -Original Message-
> From: Grant Likely [mailto:grant.lik...@secretlab.ca]
> Sent: Wednesday, April 15, 2009 9:03 AM
> To: Stephen Neuendorffer
> Cc: John Linn; jwbo...@linux.vnet.ibm.com;
> linux-fbdev-de...@lists.sourceforge.net; linuxppc-
> d...@ozlabs.org; ako
> > - rc = of_address_to_resource(op->node, 0, &res);
> > - if (rc) {
> > - dev_err(&op->dev, "invalid address\n");
> > - return rc;
> > + /*
> > + * To check whether the core is connected directly to DCR or PLB
> > + * interface and initi
I think the mainline driver might (still) assume the presence of a PLB->DCR
bridge?
So there are really 4 cases:
Core has DCR access, accessed directly using DCR.
Core has DCR access, accessed indirectly using DCR.
Core has DCR access, accessed through plb->dcr bridge.
Core has PLB access.
S
> One thing I had a crazy dream about was a GUI-based device tree
builder
> for platforms. Instead of editing them manually and passing them
> through the compiler, wouldn't it be fun to drag and drop system
> components (and build new ones) into something like a DirectX Filter
> Graph Builder (or
It doesn't seem to me that the problem (hierarchical interrupts) is one
that only happens with GPIOs, so why treat them specially? Since there
seems to be a reasonable solution that keeps them in a
separate namespace, that seems like the better way to go...
Steve
> -Original Message-
>
The problem (in my case) is that the legacy-serial driver doesn't accept
all of the 16550 configurations accepted by the regular ns16550 driver.
The problem is not related to simple-bus, but only became visible when
simple-bus bindings are used because the legacy-serial driver
specifically looks f
> -Original Message-
> From: John Linn [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 01, 2008 9:32 AM
> To: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; Stephen Neuendorffer
> Cc: John Linn
references cross from one fragment
to another.
Steve
> -Original Message-
> From: Benjamin Herrenschmidt [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 30, 2008 11:22 PM
> To: Stephen Neuendorffer
> Cc: John Williams; [EMAIL PROTECTED];
[EMAIL PROTECTED]; Michal Simek;
>
8 9:34 AM
> To: Stephen Neuendorffer
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
linuxppc-dev@ozlabs.org; git
> Subject: Re: [PATCH] [POWERPC] Xilinx: add compatibility for
'simple-bus'.
>
> Stephen Neuendorffer wrote:
> > Grant Likely wrote:
> > > > I th
route by claiming a copyright,
which at least at Xilinx has significant precedent.
Steve
-Original Message-
From: John Williams [mailto:[EMAIL PROTECTED]
Sent: Sun 6/29/2008 5:02 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
Likely
Sent: Sat 6/28/2008 1:33 PM
To: Stephen Neuendorffer
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org; git
Subject: Re: [PATCH] [POWERPC] Xilinx: add compatibility for 'simple-bus'.
On Fri, Jun 6, 2008 at 10:16 AM, Stephen Neuendorffer
<[EMAIL PROT
t need a device
tree. However, I don't see this happening before August.
Steve
-Original Message-
From: [EMAIL PROTECTED] on behalf of Grant Likely
Sent: Fri 6/27/2008 9:22 PM
To: Stephen Neuendorffer
Cc: Josh Boyer; John Linn; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL
PROTECTED
y, June 26, 2008 12:43 PM
> To: Michal Simek
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; Stephen Neuendorffer;
> John Linn; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED];
linuxppc-dev@ozlabs.o
It's on my list of things to do, but I'm swamped with a few deadlines at
the moment.
Steve
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-dev-
> [EMAIL PROTECTED] On Behalf Of
Michal Simek
> Sent: Thursday, June 26, 2008 11:57 AM
> To: Jon Loeliger
> Cc: [EMAIL PROTECTED
> -Original Message-
> From: Josh Boyer [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 26, 2008 12:07 PM
> To: Stephen Neuendorffer
> Cc: [EMAIL PROTECTED]; John Linn; [EMAIL PROTECTED];
[EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: RE: [PATCH] pow
board, which should I use?
2) The simpleImage target is capable of selecting a head.s file to link
based on the target name. This needs to be documented.
> -Original Message-
> From: Grant Likely [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 25, 2008 1:21 PM
> To: J
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index 3934e26..94adfe1 100644
> > --- a/arch/powerpc/Kconfig
> > +++ b/arch/powerpc/Kconfig
> > @@ -483,6 +483,81 @@ config SECCOMP
> >
> > If unsure, say Y. Only embedded should say N here.
> >
> > +config WANT_DEVICE_TREE
> >
Mark,
I'm very interested in trying to factor out board data from the device
tree, but for slightly different reasons, I think. (Although I don't
exactly understand what you're proposing...)
In FPGA-based designs, it would be nice to be able to describe a device
tree fragment for the board, whi
Good point. I'll see about integrating your patch.
Steve
> -Original Message-
> From: Johann Baudy [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 18, 2008 7:18 AM
> To: Stephen Neuendorffer
> Cc: linuxppc-dev@ozlabs.org
> Subject: gen-mhs-devtree - C_ALL
What board are you working on? Which phy option are you using?
I'm guessing that there's something wrong in that area.
Steve
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-dev-
> [EMAIL PROTECTED] On Behalf Of Simon
Frey
> Sent: Friday, June 13, 2008 7:46 AM
> To: linux
The kernel at git.xilinx.com has a rule to make zImage.virtex. Note
that this elf file will almost certainly *not* fit in blockram, hence
you can't use it to 'make a bitstream'. You can use it to generate a
SystemAce file, however.
If you are using a current mainline kernel, then you need to ma
rred, at least
Steve
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Grant Likely
> Sent: Friday, June 06, 2008 8:29 AM
> To: Stephen Neuendorffer
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
linuxppc-dev@ozlabs.org; git
>
>
> Excellent. My prompting has succeeded. Though now I won't get to be
> on top of the "top contributors" list in the lwn.net pages like Kumar
> was. Oh well.
>
> > Paulus, Can we just kill all of arch/ppc for .27 right now?
>
> Please. Pretty ple
It appears that this turns out to interact badly with the probing of
PPC_UDBG_16550, which is always enabled on PPC405 (and apparently
found!) even though Virtex devices don't have them.
Steve
> -Original Message-
> From: Stephen Neuendorffer [mailto:[EMAIL PROTECTED]
>
git.xilinx.com has a gen-mhs-devtree.git repository. This contains an
EDK BSP called 'fdt' which generates the device tree for an EDK design.
The easiest way to use this is to check it out, and then point the EDK
user repository at the edk_lib directory (under project->project
options->project pe
I don't think the GPIO driver has device tree bindings yet in the driver
for ARCH=powerpc.
Steve
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-dev-
> [EMAIL PROTECTED] On Behalf Of John
Bonesio
> Sent: Thursday, May 15, 2008 11:39 AM
> To: Guillaume Dargaud; linuxppc-d
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Grant Likely
> Sent: Wednesday, May 14, 2008 8:35 AM
> To: Stephen Neuendorffer
> Cc: linuxppc-dev@ozlabs.org; git-dev
> Subject: Re: [PATCH] Xilinx: framebuffer: add compatibility
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Grant Likely
> Sent: Monday, May 12, 2008 12:46 PM
> To: Stephen Neuendorffer
> Cc: linuxppc-dev@ozlabs.org; git-dev
> Subject: Re: [PATCH] Xilinx: framebuffer: add compatibility
to have to
just have the explicit versions in the drivers for the time being.
Steve
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Grant Likely
> Sent: Monday, May 12, 2008 11:30 AM
> To: Stephen Neuendorffer
> Cc: linuxppc-dev@ozlabs.
with the driver if it has to be anywhere.
Steve
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Grant Likely
> Sent: Monday, May 12, 2008 7:25 AM
> To: Stephen Neuendorffer
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] X
es in
for short term backward compatibility for existing device trees.
Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/40x/virtex.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/40x/virtex.c
b/arch/powerpc/pl
[POWERPC] Xilinx: add compatibility for
IBMcoreconnect busses.
>
> On Wed, May 07, 2008 at 09:46:30PM -0500, Josh Boyer wrote:
> > On Thu, 8 May 2008 10:18:50 +1000
> > David Gibson <[EMAIL PROTECTED]> wrote:
> >
> > > On Wed, May 07, 2008 at 01:47:31PM -0700, Steph
t, then it has to have ranges; and a
reg=<> property, which seems very strange, and not something I think is
a good thing to do.
Steve
-Original Message-
From: David Gibson [mailto:[EMAIL PROTECTED]
Sent: Wed 5/7/2008 6:59 PM
To: Stephen Neuendorffer
Cc: Grant Likely; linuxppc-dev
Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Grant Likely
> Sent: Wednesday, May 07, 2008 3:33 PM
> To: Stephen Neuendorffer
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] [POWERPC] Xilinx: add compatibility for IBM
coreconnect busses.
>
> On
ned-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/40x/virtex.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/40x/virtex.c
b/arch/powerpc/platforms/40x/virtex.c
index 6c72994..7e1c0e3 100644
--- a/arch/power
controller having a 'dcr-access-method' attribute
in the device tree. If only one of the above options is selected,
then the code uses #defines to select only the used code in order to
avoid introducing overhead in existing usage.
Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECT
ikely
> Sent: Monday, May 05, 2008 1:01 PM
> To: Stephen Neuendorffer
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] Xilinx: hwicap: cleanup polling timeout.
>
> On Mon, May 5, 2008 at 12:20 PM, Stephen Neuendorffer
> <[EMAIL PROTECTED]> wrote:
> > In order to
> -Original Message-
> From: David Gibson [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 05, 2008 11:15 PM
> To: Grant Likely
> Cc: Stephen Neuendorffer; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 4/4] [POWERPC] Xilinx: Framebuffer: Use
dcrinfrastructure.
>
>
I'll fix it.
> -Original Message-
> From: Benjamin Herrenschmidt [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 05, 2008 9:02 PM
> To: Stephen Rothwell
> Cc: Stephen Neuendorffer; [EMAIL PROTECTED];
[EMAIL PROTECTED]; linuxppc-
> [EMAIL PROTECTED]
> Subject: Re
Steve
> -Original Message-
> From: Benjamin Herrenschmidt [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 05, 2008 5:12 PM
> To: Stephen Neuendorffer
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 2/4] [POWERPC] Xilinx: Virtex: Enable
igned-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]>
---
drivers/char/xilinx_hwicap/buffer_icap.c | 10 --
drivers/char/xilinx_hwicap/fifo_icap.c |9 +
drivers/char/xilinx_hwicap/xilinx_hwicap.h |3 ---
3 files changed, 17 insertions(+), 5 deletions(-)
d
<4>;
reg = < 4070 1000 >;
xlnx,family = "virtex2p";
} ;
Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]>
---
drivers/video/xilinxfb.c | 54 +--
Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]>
---
drivers/video/xilinxfb.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index 848752e..a82c530 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers
controller having a 'dcr-access-method' attribute
in the device tree. If only one of the above options is selected,
then the code uses #defines to select only the used code in order to
avoid introducing overhead in existing usage.
Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECT
I've modified these patches to include Josh's comments, and also
modified the tft patches to not assume that patches to ARCH=ppc are
made. This breaks platform_device support and hence ARCH=ppc support.
I'd appreciate it if these patches could get queued up for 2.6.27 (and
hence get built a bit be
With ARCH=ppc going away, we don't really need platform device support
anymore. In fact it is hard, if we want to use the generic dcr
infrastructure.
Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]>
---
drivers/video/xilinxfb.c | 63 +-
FPGA designs may have need of both MMIO-based and NATIVE-based dcr
interfaces.
Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/40x/Kconfig |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/40x/Kconfig
Acked-by: Stephen Neuendorffer <[EMAIL PROTECTED]>
Grant, please pick this up.
Steve
> -Original Message-
> From: Adrian Bunk [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 23, 2008 2:52 AM
> To: Stephen Neuendorffer; Grant Likely; [EMAIL PROTECTED]
> Cc: li
For what it's worth:
Acked-by: Stephen Neuendorffer <[EMAIL PROTECTED]>
There's one or two other things I've been meaning to clean up, such as the
section mismatch on hwicap_of_match, too.
Steve
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:linuxppc-
The easiest way is to edit the .mhs by hand.
Steve
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-dev-
> [EMAIL PROTECTED] On Behalf Of
Guillaume Dargaud
> Sent: Monday, April 21, 2008 9:16 AM
> To: Rick Moleres; linuxppc-dev@ozlabs.org
> Subject: Re: Xilinx network trou
> > +void dcr_unmap_generic(dcr_host_t host, unsigned int dcr_c)
> > +{
> > + if (host.type == NATIVE)
> > + dcr_unmap_native(host.host.native, dcr_c);
> > + else
> > + dcr_unmap_mmio(host.host.mmio, dcr_c);
>
> What happens if host.type == INVALID? Same question for the
controller having a 'dcr-access-method' attribute
in the device tree. If only one of the above options is selected,
then the code uses #defines to select only the used code in order to
avoid introducing overhead in existing usage.
Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]>
-
FPGA designs may have need of both MMIO-based and NATIVE-based dcr
interfaces.
Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/40x/Kconfig |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/40x/Kconfig
description: The dcr-access-method attribute
is on the dcr-controller, not the dcr slave.
Steve
> -Original Message-
> From: Benjamin Herrenschmidt [mailto:[EMAIL PROTECTED]
> Sent: Sunday, March 30, 2008 3:03 PM
> To: Stephen Neuendorffer
> Cc: linuxppc-dev@ozlabs.org
>
Generally, speaking the easiest way to debug such errors is to examine
__log_buf using XMD.
Steve
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:linuxppc-dev-
> [EMAIL PROTECTED] On Behalf Of
Guillaume Dargaud
> Sent: Monday, April 07, 2008 8:34 AM
> To: linuxppc-dev@ozlabs.org
>
Ben,
Any thoughts about device tree bindings for indirect DCR?
Steve
> -Original Message-
> From: Benjamin Herrenschmidt [mailto:[EMAIL PROTECTED]
> Sent: Sunday, March 30, 2008 3:03 PM
> To: Stephen Neuendorffer
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH
The device tree generator now reflects this.
Steve
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:linuxppc-dev-
> [EMAIL PROTECTED] On Behalf Of Arnd Bergmann
> Sent: Wednesday, April 02, 2008 9:16 PM
> To: linuxppc-dev@ozlabs.org
> Cc: John Linn
> Subject: Re: [PATCH 2/3] [POWER
I don't think big-endian has the same context as reg-shift/reg-offset.
The OpenPOC is fundamentally a 32 bit device, but ns16550 is not... If
we were talking about a 32 bit device, then I'd probably agree with you,
but in this case, the reg-shift (and to some extent) reg-offset have
been used bef
the dcr slave.
I'd particularly appreciate it if someone with access to PPC64 would
test this...
Steve
> -Original Message-
> From: Benjamin Herrenschmidt [mailto:[EMAIL PROTECTED]
> Sent: Sunday, March 30, 2008 3:03 PM
> To: Stephen Neuendorffer
> Cc: linuxppc-dev@ozla
FPGA designs may have need of both MMIO-based and NATIVE-based dcr
interfaces.
Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/40x/Kconfig |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/40x/Kconfig
<4>;
reg = < 4070 1000 >;
xlnx,family = "virtex2p";
} ;
Note that this patch now requires PPC_DCR_MMIO to be set in order to
advertise the framebuffer as a platfo
Added literal mapping support if no device-tree support. Added
CONFIG_OF to guard device-tree parts, since literal support works for
arch=ppc.
Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/dcr.c | 82 -
inclu
device having a 'dcr-access-method' attribute
in the device tree. If only one of the above options is selected,
then the code uses #defines to select only the used code in order to
avoid interoducing overhead in existing usage.
Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTE
Generally speaking, I'm not sure about the validity of this patch. In
particular:
1) I'm not sure what architecture code relies on including
dcr support through ibm4xx.h.
2) I'm not sure how temporary the ifdef in
arch/powerpc/sysdev/Makefile really is. Is it still needed or not?
However, this
1 - 100 of 185 matches
Mail list logo
