Minor nit below
Acked-by: Stephen Neuendorffer stephen.neuendorf...@xilinx.com
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
-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;
.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
reviewed-by: Stephen Neuendorffer stephen.neuendorf...@xilinx.com
minor nits below.
---
arch/powerpc/platforms/40x/ppc40x_simple.c| 13 +++---
arch/powerpc/platforms/512x/mpc5121_generic.c | 13 +-
arch/powerpc/platforms
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 later
-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;
-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.ozlabs.org; linuxppc-dev list
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
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 stephen.neuendorf...@xilinx.com
Grant,
We had discussed doing something like
A few support device-tree related support functions that x86 didn't
have before.
Signed-off-by: Stephen Neuendorffer stephen.neuendorf...@xilinx.com
Looks like just some irq related junk left!
---
arch/x86/include/asm/irq.h |2 ++
arch/x86/kernel/irq.c | 11 +++
2 files
to implement a driver-visible
fdt_unflatten_tree function, which can be used to unflatten a
blob after boot time.
Signed-off-by: Stephen Neuendorffer stephen.neuendorf...@xilinx.com
--
V2: remove extra __va() call
make dt_alloc functions return void *. This doesn't fix the general
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 stephen.neuendorf...@xilinx.com
--
V2: functions have of_fdt_* names
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
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
Move unflatten_dt_node to be grouped with non-__init functions.
Signed-off-by: Stephen Neuendorffer stephen.neuendorf...@xilinx.com
---
drivers/of/fdt.c | 218 +++---
1 files changed, 109 insertions(+), 109 deletions(-)
diff --git a/drivers
-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 Simek;
microblaze-ucli
-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:
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
-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;
-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
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:
-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
Cc: John Linn; Alon Ziv
-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-dev
Cc: John Linn
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
-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:
...@davemloft.net
to your patches.
Thanks for doing this, Grant It's definitely needed.
Acked-by: Stephen Neuendorffer stephen.neuendorf...@xilinx.com
Steve
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information
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
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...@vger.kernel.org; linuxppc
-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 and
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 of
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
Cc: David H
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 BRAM
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 offer any advice as
to
-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 systems are LX systems but currently we
...@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
stephen.neuendorf
On Fri, Apr 17, 2009 at 10:49 PM, Grant Likely grant.lik...@secretlab.cawrote:
On Fri, Apr 17, 2009 at 11:06 AM, Stephen Neuendorffer
stephen.neuendorf...@xilinx.com wrote:
Can we have XILINX_DRIVERS, please? That way this can also be enabled
on any architecture that has FPGA peripherals
- 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 initialize the
-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; akonova...@ru.mvista.com; adap
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.
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 the
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
the 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;
[EMAIL PROTECTED]; [EMAIL
-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
Subject: [PATCH] powerpc
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 think the easiest solution is to change the Kconfig so that
PPC_UDBG_16550
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]; Scott Wood; Geoff
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 PROTECTED] wrote
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];
Stephen Neuendorffer; John Linn; [EMAIL
, 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: John Linn; Stephen Neuendorffer
-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] powerpc/bootwrapper: Add documentation
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];
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.org;
[EMAIL PROTECTED]; [EMAIL PROTECTED
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
+ bool
+
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,
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:
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_PIMS_SHARE_ADDRESSES=0
Hi
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
-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
Subject: Re: [PATCH] [POWERPC] Xilinx: add compatibility
. Pretty please?
Acked-by: Josh Boyer [EMAIL PROTECTED]
josh
For what it's worth,
Acked-by: Stephen Neuendorffer [EMAIL PROTECTED]
I'd like to see this happen soon so a few stacked patches we have can
finally go in.
Steve
This email and any attachments are intended for the sole use
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]
Sent: Thursday, May
-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 for ml507
dvi core
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] Xilinx: framebuffer: add
-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 for ml507
dvi core.
On Mon
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, Stephen Neuendorffer
wrote:
The IBM coreconnect names are pretty well defined
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/platforms/40x/virtex.c
index 6c72994
-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/powerpc/platforms/40x
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 Wed, May 7, 2008 at 2:47 PM, Stephen Neuendorffer
[EMAIL
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@ozlabs.org
Subject: Re: [PATCH 4
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: [PATCH 1/4] [v4][POWERPC
-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.
On Mon, May 05, 2008 at 10:55
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 avoid polling forever if an error occurs, this driver
includes a timeout counter
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]
--
[v4]
Converted
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
b/arch/powerpc
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 +-
1 files
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
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]
--
[v4]
Converted
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/video
;
} ;
Signed-off-by: Stephen Neuendorffer [EMAIL PROTECTED]
---
drivers/video/xilinxfb.c | 54 +-
1 files changed, 20 insertions(+), 34 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index 4d64402..848752e
-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(-)
diff --git a/drivers
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: linuxppc-dev@ozlabs.org; [EMAIL
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-dev-
[EMAIL PROTECTED
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 trouble
-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
Subject: Re: [PATCH 1/5] [v2][POWERPC] refactor
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
b/arch/powerpc
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]
---
arch/powerpc
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 1/5] [v2][POWERPC] refactor
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]
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
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 PROTECTED]
---
arch/powerpc
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 -
include/asm
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
b/arch/powerpc
-Original Message-
From: Benjamin Herrenschmidt [mailto:[EMAIL PROTECTED]
Sent: Monday, March 24, 2008 3:00 PM
To: Stephen Neuendorffer
Cc: Josh Boyer; linuxppc-dev@ozlabs.org; git-dev
Subject: RE: dcr stuff.
On Sun, 2008-03-23 at 21:34 -0700, Stephen Neuendorffer wrote
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 PROTECTED]
---
I did some
-Original Message-
From: Josh Boyer [mailto:[EMAIL PROTECTED]
Sent: Fri 3/21/2008 6:17 PM
To: Stephen Neuendorffer
Cc: linuxppc-dev@ozlabs.org; git-dev
Subject: Re: dcr stuff.
On Fri, 21 Mar 2008 12:05:40 -0700
Stephen Neuendorffer [EMAIL PROTECTED] wrote:
Is there a plan here
-Original Message-
From: [EMAIL PROTECTED]
[mailto:linuxppc-dev-
[EMAIL PROTECTED] On Behalf Of
Segher Boessenkool
Sent: Friday, March 21, 2008 9:46 AM
To: Sergei Shtylyov
Cc: linuxppc-dev@ozlabs.org; John Linn
Subject: Re: [PATCH 2/3] [POWERPC] Xilinx: of_serial support for
Is anybody working on the dcr infrastructure?
In particular, there seems to be inconsistency between what the kernel
does and what ePAPR thinks it should. The code in the kernel selects
mmio or native access based on a Kconfig parameter and uses some device
tree parameters to correctly
To: Stephen Neuendorffer
Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]
Subject: Re: [PATCH] [RFC] Xilinx: Add generic configuration option to
enable all xilinx drivers.
On Tue, Mar 18, 2008 at 10:32 PM, Stephen Neuendorffer
[EMAIL PROTECTED] wrote:
Hmm... interesting points. I guess my
In the future, this will be used to provide similar configuration for
PowerPC and Microblaze. It may also be convenient for those using
Xilinx cores as peripherals for external processors, rather than
explicitly having a dependance on the processor architecture.
Signed-off-by: Stephen
.
Would you feel differently if we flipped the dependencies around, like
XILINX_DRIVERS depends on PPC32 || MICROBLAZE?
Steve
-Original Message-
From: [EMAIL PROTECTED] on behalf of Grant Likely
Sent: Tue 3/18/2008 9:15 PM
To: Stephen Neuendorffer
Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED
1 - 100 of 166 matches
Mail list logo
