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
...@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
-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:
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 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
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.
- 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
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
...@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
Peter,
Sorry, this has taken so long... I've undertaken some significant
refactorings, and included support for the new EDK9.2 xps_hwicap.
Responses below.
Please don't put the HWICAP option in the middle of the HVC options.
oops! fixed.
+config XILINX_HWICAP
+ tristate Xilinx OPB
What if it was something like:
image-$(CONFIG_MPC832x_MDS) += cuImage.mpc832x_mds
image-$(CONFIG_MPC832x_RDB) += cuImage.mpc832x_rdb
image-$(CONFIG_MPC834x_ITX) += cuImage.mpc8349emitx \
cuImage.mpc8349emitxgp
The ICAP device in Xilinx FPGAs differs slightly between different
FPGAs. The driver needs an additional attribute in the device tree to
distinguish this.
Signed-off-by: Stephen Neuendorffer [EMAIL PROTECTED]
---
Documentation/powerpc/booting-without-of.txt | 14 ++
1 files
Fix some missing __user tags and incorrect section tags.
Convert semaphores to mutexes.
Make probed_devices re-entrancy and error condition safe.
Fix some backwards memcpys.
Some other minor cleanups.
Use kerneldoc format.
Signed-off-by: Stephen Neuendorffer [EMAIL PROTECTED]
---
Grant, Since
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
= get_property(np, reg-shift, NULL);
ditto...
Otherwise,
Acked-by: Stephen Neuendorffer [EMAIL PROTECTED]
Also, can you post a patch to the Xilinx portion of
booting-without-of.txt that has the device tree entries necessary to get
the uart to work? (Since I happened to be tracking down what I assume
gcc knows better. :)
-Original Message-
From: Stephen Rothwell [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 14, 2008 3:27 PM
To: Stephen Neuendorffer
Cc: Pavel Kiryukhin; linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] [POWERPC] Enable correct operation of serial
ports
+ - reg-shift : registers offset shift (standard uart_port
field).
+ Property is optional if regshift is zero.
I was hoping to get an idea of what is required here, or when I might
use it?
It looks like the ARCH=ppc code instantiates this with a reg-shift of
2... Is this the
-Original Message-
From: Pavel Kiryukhin [mailto:[EMAIL PROTECTED]
Sent: Friday, February 15, 2008 9:41 AM
To: Stephen Neuendorffer
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] booting-without-of: add Xilinx uart 16550.
Stephen Neuendorffer wrote:
+ - reg-shift
Instead of attempting to come up with a generic description
of this, I recommend just naming it after the actual device
instance;
something like compatible=xlnx,opb-uart16550;
Well, that means that we'll need a to add a code which glues the
chip to
8250.c driver... well, of_serial.c
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Grant Likely
Sent: Saturday, February 23, 2008 10:17 PM
To: Stephen Neuendorffer
Cc: linuxppc-dev@ozlabs.org; git-dev; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [PATCH] Xilinx: hwicap: cleanup
a comment that didn't match the function name
fixed argument with 'register' keyword.
Signed-off-by: Stephen Neuendorffer [EMAIL PROTECTED]
---
Grant, Since it appears that the driver will stay in as-is, here are
the updates against mainline, based on Jiri's comments.
---
drivers/char
Josh,
Specifically, we're trying to get console on of_serial, but there
doesn't seem to be any code to register a console, except in
legacy_serial? But legacy_serial doesn't implement the offsets
necessary for the Xilinx uart16550 cores. Does it seem reasonable to
add code to of_serial.c to
reading the IDCODE, in order to avoid entering this
unrecoverable state. This patch also adds additional NOOP commands
into the sychronization sequence, which appears to be necessary to
avoid the condition on some hardware.
Signed-off-by: Stephen Neuendorffer [EMAIL PROTECTED]
---
drivers/char
The following sequence of patches makes the icap driver more robust,
by making better use of the status information from the cores. In
addition, Lanana has assigned Major 259 for FPGA configuration
interfaces, so we now use it, rather than dynamically finding a major
number.
Grant: please pick
Major 259 has been assigned by lanana. Use it. Also, publish
/dev/icap[0-k] as the device entries, and register platform devices
named 'icap' to be consistent.
Signed-off-by: Stephen Neuendorffer [EMAIL PROTECTED]
---
drivers/char/xilinx_hwicap/xilinx_hwicap.c | 43
with some masks for the differnet bits.
Signed-off-by: Stephen Neuendorffer [EMAIL PROTECTED]
---
drivers/char/xilinx_hwicap/buffer_icap.c | 22 ---
drivers/char/xilinx_hwicap/buffer_icap.h |5 ++-
drivers/char/xilinx_hwicap/fifo_icap.c | 31
Grant,
If you have working platform code using libfdt, can you publish it?
Steve
-Original Message-
From: [EMAIL PROTECTED]
[mailto:linuxppc-dev-
[EMAIL PROTECTED] On Behalf Of Grant
Likely
Sent: Monday, March 17, 2008 1:08 PM
To: John Linn
Cc: linuxppc-dev@ozlabs.org
Subject:
Sorry, guess I missed it...
Steve
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Grant Likely
Sent: Monday, March 17, 2008 1:25 PM
To: Stephen Neuendorffer
Cc: John Linn; linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] [POWERPC] Xilinx: Boot: Fix
.
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
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
-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
-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: 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
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
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
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]
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
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
-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
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
On a similar note, is there interest in actually factoring the device
tree code out from the different architectures into a common codebase?
Steve
-Original Message-
From:
[EMAIL PROTECTED]
g
[mailto:[EMAIL PROTECTED]
zlabs.org] On Behalf Of Grant Likely
Sent: Monday, October
-Original Message-
From:
[EMAIL PROTECTED]
g
[mailto:[EMAIL PROTECTED]
zlabs.org] On Behalf Of David Gibson
Sent: Monday, October 15, 2007 8:24 PM
To: Grant Likely
Cc: Olof Johansson; linuxppc-dev; [EMAIL PROTECTED]
Subject: Re: Refactor booting-without-of.txt
On Mon, Oct
+ n) Xilinx EMAC and Xilinx TEMAC
+
+ Xilinx Ethernet devices. Uses common properties from
other Ethernet
+ devices with the following constraints:
+
+ Required properties:
+- compatible : Must include one of: xilinx,plb-temac,
+ xilinx,plb-emac,
-Original Message-
From:
[EMAIL PROTECTED]
g
[mailto:[EMAIL PROTECTED]
zlabs.org] On Behalf Of Grant Likely
Sent: Wednesday, October 17, 2007 6:15 AM
To: Grant Likely; Paul Mackerras; Josh Boyer; linuxppc-dev@ozlabs.org
Subject: Re: Merge dtc
On 10/16/07, David Gibson [EMAIL
-Original Message-
From: Grant Likely [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 18, 2007 10:23 AM
To: linuxppc-dev@ozlabs.org; Stephen Neuendorffer; Wolfgang
Reissnegger; Leonid; [EMAIL PROTECTED]; Josh
Boyer; Arnd Bergmann
Subject: [PATCH v3] Device tree bindings
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Grant Likely
Sent: Thursday, October 18, 2007 11:13 AM
To: Stephen Neuendorffer
Cc: linuxppc-dev@ozlabs.org; Wolfgang Reissnegger; Leonid;
[EMAIL PROTECTED]; Josh Boyer; Arnd Bergmann
Subject: Re
Here's a full .dts generated using an updated version of
gen_mhs_devtree.py, following the proposal.
It happens to be a microblaze system, but you get the idea.
Grant: Is this pretty what you intend?
Steve
/ {
#address-cells = 1;
#size-cells = 1;
compatible = ibm,plb4;
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Michal Simek
Sent: Friday, October 19, 2007 7:28 PM
To: [EMAIL PROTECTED]
Cc: Stephen Neuendorffer; Grant Likely; Leonid; Arnd
Bergmann; linuxppc-dev@ozlabs.org; Wolfgang Reissnegger
Subject
-Original Message-
From:
[EMAIL PROTECTED]
g
[mailto:[EMAIL PROTECTED]
zlabs.org] On Behalf Of Michal Simek
Sent: Monday, October 22, 2007 9:08 PM
To: [EMAIL PROTECTED]
Cc: Leonid; Wolfgang Reissnegger; Arnd Bergmann;
linuxppc-dev@ozlabs.org
Subject: RE:
:[EMAIL PROTECTED] On Behalf Of
Stephen Neuendorffer
Sent: Friday, October 19, 2007 4:43 PM
To: Stephen Neuendorffer; Grant Likely
Cc: Leonid; Arnd Bergmann; [EMAIL PROTECTED];
linuxppc-dev@ozlabs.org; Wolfgang Reissnegger
Subject: [microblaze-uclinux] RE: [PATCH v3] Device tree
bindings
-Original Message-
From:
[EMAIL PROTECTED]
g
[mailto:[EMAIL PROTECTED]
zlabs.org] On Behalf Of Scott Wood
Sent: Monday, November 12, 2007 9:13 AM
To: David Gibson
Cc: linuxppc-dev@ozlabs.org; Paul Mackerras
Subject: Re: [PATCH 1/4] Merge dtc and libfdt upstream source
On
structure better represents the actual system, there is another
organization for people to be confused about.
Steve
-Original Message-
From: [EMAIL PROTECTED] on behalf of Stephen Neuendorffer
Sent: Tue 11/20/2007 11:44 AM
To: [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org; Grant Likely
I've pushed the current state up to
git://git.xilinx.com/gen-mhs-devtree.git for your perusing. Comments
below.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Grant Likely
Sent: Sunday, November 25, 2007 2:47 PM
To: Stephen Neuendorffer; Segher
-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;
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
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
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
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
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
-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
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
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
-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
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
. 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
-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
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
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
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,
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
+
, 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
1 - 100 of 166 matches
Mail list logo
