I've got a design that is 405EXr based so its got 32 bit
address space. We have an FPGA that sits on our pcie bus
and we want it to have 2 BARs with 1G of space and maybe
256MB of space. I cannot figure out what I need to change
in the kernel/dts to make this work.
Right now, if I go over
I never did get this to work, and now I am back to it again.
On Fri, Oct 14, 2011 at 09:39:51AM +0200, Benjamin Herrenschmidt wrote:
On Wed, 2011-10-12 at 16:08 -0500, Ayman El-Khashab wrote:
I'm using the 460sx (440 core) so no snooping here. What
I've done is reserved the top of memory
I'm using the 460sx (440 core) so no snooping here. What
I've done is reserved the top of memory for my driver. My
driver can read/write the memory and I can mmap it just
fine. The problem is I want to enable caching on the mmap
for performance but I don't know / can't figure out how to
tell
On Mon, Jul 18, 2011 at 02:01:15PM +1000, Tony Breeds wrote:
On Fri, Jul 15, 2011 at 11:40:27AM -0500, Ayman Elkhashab wrote:
@@ -1582,8 +1628,8 @@ static int __init ppc4xx_setup_one_pciex_POM(struct
ppc4xx_pciex_port *port,
dcr_write(port-dcrs, DCRO_PEGPL_OMR2BAH, lah);
Thanks Tony, some comments below.
On Thu, Jul 14, 2011 at 11:16:27AM +1000, Tony Breeds wrote:
+static void __init ppc460sx_pciex_check_link(struct ppc4xx_pciex_port
*port)
+{
+ void __iomem *mbase;
+ int attempt = 50;
+
+ port-link = 0;
+
+ mbase =
I've had problems with the mpt2sas driver
(drivers/scsi/mpt2sas/mpt2sas_base.c) when using it on my
ppc44x. Basically, there is a check in the code for
BITS_PER_LONG and certain code is executed if it is 64 vs 32
bit. I am guessing it is a problem with the driver but it
only shows up on powerpc.
function to specialize the link detect for the 460sx.
Tested on an eiger and custom board. Note that is swaps the order of the link
check and dcr initialization since the config space needs the DCRs setup before
it can be mapped and used to check the link.
Ayman El-Khashab (1):
powerpc/4xx
and custom board
Signed-off-by: Ayman El-Khashab ay...@elkhashab.com
---
arch/powerpc/sysdev/ppc4xx_pci.c | 83 +
arch/powerpc/sysdev/ppc4xx_pci.h |3 +
2 files changed, 68 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch
On Fri, Jul 01, 2011 at 04:44:24PM +1000, Tony Breeds wrote:
All current pcie controllers unconditionally use SDR to check the link and
poll for reset.
I was able to apply this patch and then modify the 460SX to
work correctly, so I think it is fine. There is only 1
comment below. So how does
On Tue, Jul 12, 2011 at 02:04:04PM -0400, Josh Boyer wrote:
On Tue, Jul 12, 2011 at 12:40:07PM -0500, Ayman El-Khashab wrote:
On Fri, Jul 01, 2011 at 04:44:24PM +1000, Tony Breeds wrote:
All current pcie controllers unconditionally use SDR to check the link and
poll for reset.
I was able
On Wed, Jun 29, 2011 at 09:15:28AM +1000, Benjamin Herrenschmidt wrote:
On Tue, 2011-06-28 at 17:31 -0500, Ayman El-Khashab wrote:
+static int ppc4xx_setup_pcieh_hw(struct platform_device *dev,
+struct resource res, struct
ppc4xx_msi *msi
On Wed, Jun 29, 2011 at 11:42:03AM +1000, Benjamin Herrenschmidt wrote:
On Mon, 2011-06-27 at 06:31 -0500, Ayman El-Khashab wrote:
On Mon, Jun 27, 2011 at 08:19:56PM +1000, Benjamin Herrenschmidt wrote:
On Sat, 2011-06-25 at 18:52 -0500, Ayman El-Khashab wrote:
I noticed during a recent
On Thu, May 26, 2011 at 03:24:44PM +1000, Benjamin Herrenschmidt wrote:
Please check the result and send any fixup patch that might be
necessary.
+static int ppc4xx_setup_pcieh_hw(struct platform_device *dev,
+struct resource res, struct ppc4xx_msi *msi)
+{
On Tue, May 31, 2011 at 02:27:19PM -0700, Tirumala Marri wrote:
Not sure how I would know -- But with my eiger kit, I got a
cd from amcc that had a patched 2.6.30 or something kernel
in it to support the 460SX. The pci code was basically
subverted by adding a port-link=1 at the very end of
On Mon, Jun 27, 2011 at 08:19:56PM +1000, Benjamin Herrenschmidt wrote:
On Sat, 2011-06-25 at 18:52 -0500, Ayman El-Khashab wrote:
I noticed during a recent development with the 460SX that a
simple device that once worked stopped. I did a bisect to
find the offending commit and it turns
I noticed during a recent development with the 460SX that a
simple device that once worked stopped. I did a bisect to
find the offending commit and it turns out to be this one:
0e52247a2ed1f211f0c4f682dc999610a368903f is the first bad
commit
commit 0e52247a2ed1f211f0c4f682dc999610a368903f
On Tue, May 24, 2011 at 01:40:12PM +1000, Benjamin Herrenschmidt wrote:
On Thu, 2011-05-12 at 11:16 -0700, Tirumala Marri wrote:
The register above
PECFGn_DLLSTA is actually in the PCIe configuration space so
we would have to map that in to be able to read that
register during the link
On Thu, May 05, 2011 at 09:44:27AM -0700, Tirumala Marri wrote:
Also, the patch removes the code for waiting for the link to be up with
a comment What DCR has the link status on the 460SX?. Please fix that
(Tirumala, can you provide the missing information ?)
It is not one register.
On Tue, Apr 12, 2011 at 07:09:49PM -0700, Tirumala Marri wrote:
You originally submitted the support for 460ex. Can you chime in (and
review Ayman patch) please ?
[Marri] Ben sure I will review it and send you my feedback in couple of
days.
Is there any update on this patch? Any comment?
From: Ayman El-Khashab ay...@elkhashab.com
The 460SX uses a different register set than previous 44x PCIe CPUs,
so some of the checks were not valid. Added an enable for the TX
and RX. For the 460SX only: Bypassed VCO check and added PLL check.
Bypassed the link check. Changed to advertise gen
From: Ayman El-Khashab ay...@elkhashab.com
This patch is to fix the PCIe on the 460SX CPU. As far as I can tell,
the 460SX must be using a different core than the previous 4xx SOCs.
The registers aren't the same and it appears DCRs that existed on
previous parts don't exist on this one
On Sun, Apr 03, 2011 at 04:09:26PM -0600, Grant Likely wrote:
On Sun, Apr 3, 2011 at 3:52 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
Ok, I've narrowed the scope of the problem some. ?I moved forward
to a more recent kernel (2.6.31 to 2.6.36) and that resolved the
problem
On Fri, Apr 01, 2011 at 11:26:19AM -0500, Ayman El-Khashab wrote:
I've got an LSI SAS2008 controller (w/ firmware v9) that works
fine in a Linux PC w/ a recent kernel. It does NOT work on my
460EX board. What I find is that the device shows up as every
device on the subordinate bus where
I've got a custom 460SX board with PLX gen2 (8616) switches.
When u-boot comes up everything is fine and my switches are indicating they
are in Gen2 PCIe mode. If I let it boot my linux kernel (denx 2.6.36.1), boot
almost immediately, the LEDs on my switches start to blink indicating they
On Sat, Sep 25, 2010 at 08:11:04AM +1000, Benjamin Herrenschmidt wrote:
On Fri, 2010-09-24 at 08:08 -0500, Ayman El-Khashab wrote:
I suppose another option is to to use the kernel profiling option I
always see but have never used. Is that a viable option to figure out
what is happening
On Fri, Sep 24, 2010 at 06:30:34AM -0400, Josh Boyer wrote:
On Fri, Sep 24, 2010 at 02:43:52PM +1000, Benjamin Herrenschmidt wrote:
The DMA is what I use in the real world case to get data into and out
of these buffers. However, I can disable the DMA completely and do only
the kmalloc.
I've implemented a working driver on my 460EX. it allocates a couple
of buffers of 4MB each. I have a custom memcmp algorithm in asm that
is extremely fast in user space, but 1/2 as fast when run on these
buffers.
my tests are showing that the algorithm seems to be memory bandwidth
bound. my
On Fri, Sep 24, 2010 at 08:01:04AM +1000, Benjamin Herrenschmidt wrote:
On Thu, 2010-09-23 at 10:12 -0500, Ayman El-Khashab wrote:
I've implemented a working driver on my 460EX. it allocates a couple
of buffers of 4MB each. I have a custom memcmp algorithm in asm that
is extremely fast
On Fri, Sep 24, 2010 at 11:07:24AM +1000, Benjamin Herrenschmidt wrote:
On Thu, 2010-09-23 at 17:35 -0500, Ayman El-Khashab wrote:
Anything you allocate with kmalloc() is going to be mapped by bolted
256M TLB entries, so there should be no TLB misses happening in the
kernel case
I have an odd problem when using the 460ex rev b processors. Previously,
I'd used the rev A without any issues on the same pcbs. This happens on
multiple units now. Basically, while running the system will just
randomly kernel panic. We have seen this probably 4 or 5 times on a
over the
I've got custom boards that have been running for a while on rev A
460ex parts but when the rev B parts became available some problems
surfaced. We are trying to work around the issues in software. To make
this simple, I've got 2 460exs connected together via PCI and PCIe so i
can switch
On 7/7/2010 2:48 PM, ay...@austin.rr.com wrote:
rc = io_remap_pfn_range(vma, PLB_OCM_BASE_ADDRPAGE_SHIFT, vma-vm_start, len,
vma-vm_page_prot);
I am fairly certain the physical address is correct, I've verified that the
TLB entries in u-boot look ok. Any tips on how to make this work?
I've got a custom board akin to the walnut. I've successfully got u-boot,
the kernel, and a working filesystem. The only thing I lack is a clear idea
of how to set a GPIO.
I have the PHY reset connected to GPIO 3. I've got it setup in u-boot
correctly, but by the time linux boots, it has
On 1/5/2010 10:38 PM, Bill Gatliff wrote:
Ayman El-Khashab wrote:
I've got a custom board akin to the walnut. I've successfully got
u-boot,
the kernel, and a working filesystem. The only thing I lack is a
clear idea
of how to set a GPIO.
Isn't that the flags parameter, e.g.:
gpios
Hello, I am using the mpt2sas driver on the canyonlands / 460EX board.
I've already found and fixed one problem, but can't get past the
unhandled IRQ.
The first problem I noticed is that the physical address is read into a
32 bit variable, but the 460ex has a 36 bit bus so the ioremap would
Hello, I've got some trouble getting an LSI SAS controller (LSISAS200)
to function. It is at least enumerated correctly in a PC running
ubuntu, so it seems that it must be something particular to the PCI
implementation on the powerpc or the usage of u-boot.
If the board is initialized by
I am using the ppc460ex as an endpoint and I see that the mentioned
function setups a 32Mb
window at address 0 in sdram. what i want is some memory that the host
can read/write to.
But the 32Mb that are already mapped at the bottom of ram, so it would
not be good do writes
to those addresses. Am
My system consists of a pair of 460EXs attached by way of both PCI-E and
PCI. Ultimately my goal is to communicate between them via pci-e (is
there anything out there that does this already?). For a small step, I
am trying to get the PCI to work. I already have the PCI boot ability
of the
-Original Message-
From: Ira Snyder [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 10, 2008 6:18 PM
To: Ayman El-Khashab
Cc: linuxppc-dev@ozlabs.org
Subject: Re: Help enabling PCI endpoint on 460EX, host sees disabled
I can't help you with that exact board, but I've
Benjamin Herrenschmidt wrote:
Ayman, can you double check that this variant of the patch still
fixes your problem ? Thanks !
I've tried it out and it is working correctly with my devices. The
subordinate bus numbers on all the ports are correct.
Best Regards,
Ayman
Thank you Ben, I've had success with the patch, details below ...
Benjamin Herrenschmidt wrote:
Can you try this (untested) patch and send me the resulting dmesg log
(along with whether it helps).
Index: linux-work/drivers/pci/probe.c
Benjamin Herrenschmidt wrote:
+ /* Check if setup is sensible at all */
+ if ((buses 0xff) != bus-number ||
+ ((buses 8) 0xff) != = bus-number) {
Note that I removed the = from the above line -- I did not think it
was correct. Please let me know if that was wrong.
My
Benjamin Herrenschmidt wrote:
On Thu, 2008-10-16 at 10:01 -0500, Ayman El-Khashab wrote:
Benjamin Herrenschmidt wrote:
On Wed, 2008-10-15 at 10:47 -0500, Ayman El-Khashab wrote:
Note for people on CC: This is a problem on 460EX on a canyonland
using the 4x port.
Ok, can you send me
Benjamin Herrenschmidt wrote:
On Wed, 2008-10-15 at 10:47 -0500, Ayman El-Khashab wrote:
Note for people on CC: This is a problem on 460EX on a canyonland
using the 4x port.
The problem occurs when Linux boots. It sees the switch (and looking
in /sys/bus/... confirms it), but nothing
I am using the stock canyonlands 460EX development board. I have
the 4L (port 1) configured as a root-complex. I also have a SIL
pci-e sata card. When I plug the sata card directly into the
canyonlands, everything works as expected. The sil is detected
in Linux and I can read/write the disk.
45 matches
Mail list logo
