Fix i8259 kernel crash on ML510 [with signed-off]

2009-09-03 Thread Roderick Colenbrander
Hi,

This is the same patch but with a signed-off message which I forgot.

Regards,
Roderick Colenbrander

Signed-off-by: Roderick Colenbrander thunderbir...@gmail.com

From 11a2072b285c2eb0f19980ad729229d4ebf22291 Mon Sep 17 00:00:00 2001
From: Roderick Colenbrander colenbran...@ce202.(none)
Date: Thu, 3 Sep 2009 15:11:08 +0200
Subject: [PATCH] This patch fixes a null pointer exception caused by
removal of 'ack()' for level interrupts in the Xilinx interrupt driver.

---
 arch/powerpc/sysdev/xilinx_intc.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/sysdev/xilinx_intc.c
b/arch/powerpc/sysdev/xilinx_intc.c
index 3ee1fd3..40edad5 100644
--- a/arch/powerpc/sysdev/xilinx_intc.c
+++ b/arch/powerpc/sysdev/xilinx_intc.c
@@ -234,7 +234,6 @@ static void xilinx_i8259_cascade(unsigned int irq,
struct irq_desc *desc)
generic_handle_irq(cascade_irq);
 
/* Let xilinx_intc end the interrupt */
-   desc-chip-ack(irq);
desc-chip-unmask(irq);
 }
 
-- 
1.6.0.4



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Fix i8259 kernel crash on ML510

2009-09-03 Thread Roderick Colenbrander
From 11a2072b285c2eb0f19980ad729229d4ebf22291 Mon Sep 17 00:00:00 2001
From: Roderick Colenbrander colenbran...@ce202.(none)
Date: Thu, 3 Sep 2009 15:11:08 +0200
Subject: [PATCH] This patch fixes a null pointer exception caused by
removal of 'ack()' for level interrupts in the Xilinx interrupt driver.

---
 arch/powerpc/sysdev/xilinx_intc.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/sysdev/xilinx_intc.c
b/arch/powerpc/sysdev/xilinx_intc.c
index 3ee1fd3..40edad5 100644
--- a/arch/powerpc/sysdev/xilinx_intc.c
+++ b/arch/powerpc/sysdev/xilinx_intc.c
@@ -234,7 +234,6 @@ static void xilinx_i8259_cascade(unsigned int irq,
struct irq_desc *desc)
generic_handle_irq(cascade_irq);
 
/* Let xilinx_intc end the interrupt */
-   desc-chip-ack(irq);
desc-chip-unmask(irq);
 }
 
-- 
1.6.0.4



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: PowerPC PCI DMA issues (prefetch/coherency?)

2009-06-16 Thread Roderick Colenbrander
Hi Chris,

The last couple of months I had the 'pleasure' to work with a Xilinx
ML510 ATX board which contains a Virtex-5 FXT. In my case I had to set
up the plbv46 pci soft-core to function properly with PCI add-on
boards and onboard pci devices. I have had a lot of issues including
ones with DMA but in the end it worked properly. I'm not sure how in
your case the Virtex-5 is wired to the PCI bus but in my case it was
connected to the crossbar switch of the PowerPC 440 which is inside
the Virtex-5 FXT. Not all Xilinx reference designs were interfaced
properly to this (sometimes the MPLB-SPLB connection from the
soft-core to the crossbar wasn't connected) and even then the PCI
soft-core wasn't configured properly by Xilinx and this MIGHT be
similar to your issue.

In the explanation of the issue I will use the terminology used by
Xilinx. The CPU side is the 'IPIF' side and the and the PCI side is
the 'PCI' side. Both domains have their own address domains and hence
translation from IPIFtoPCI and PCItoIPIF is needed. From what I
understood is that the 'incoming window' (ipif-pci) and outgoing
window (pciipif) should use different address ranges else the bridge
gets confused. I don't have access to my design right now but by head
Xilinx doesn't set C_IPIFBAR2PCIBAR_0 properly in a lot of cases and
just sets it to 0. Which means that cpu - ipif (lets say the soft
core is accessible from 0xa000 from the cpu) 0xa0001234 translates
to 0x1234 on the PCI side but PCI cards expect that when they
write low memory addresses that they write to system memory. What
should be done is to set C_IPIFBAR2PCIBAR_0 to 0xa000 in this
case, so that the incoming window is 0xa000-0x
and the outgoing window 0x-0x9fff or just set it half way
at 0x8000.

I'm not saying this is your issue but it could be it.

Regards,
Roderick Colenbrander


On Tue, Jun 16, 2009 at 4:08 PM, Chris Pringlechris.prin...@oxtel.com wrote:
 Hello All

 We're developing on a Freescale MPC8272 and are having some nasty problems
 with PCI bus mastering and data corruption.

 We have some custom hardware that is bus mastering, reading data from the
 CPUs memory for it's own use. Most of the time, the data is correct, however
 occasionally we are seeing data that appears to be from somewhere else in
 memory (usually memory that has already been read by the PCI device). The
 problem looks like stale data on the PCI bridge prefetch buffers or a cache
 coherency problem, but we've been unable to come up with a solution to our
 problem. It is my understanding that it shouldn't be a cache coherency
 problem as the CPU cache should be snooped as the data is read from memory.
 Even if it were an issue, the pci_map_sg* functions should have sorted out
 any cache coherency issues before the DMA operation started.

 I've not been able to find anything on the Freescale data sheet that
 provides any way of flushing the prefetch cache on the PCI bridge. We've
 done a bit of experimenting, and found that turning off prefetch appears to
 solve (or possibly mask?) the problem (at the expensive of massive
 performance problems). I've also tried DMA'ing two adjacent userspace
 buffers in memory (from the same page), and see corruption on the second
 buffer. If I populate both buffers, then DMA them both, the data is fine. If
 I populate the first, DMA the first, then populate the second and DMA the
 second, corruption occurs at the start of the second buffer. If I add 8-32
 bytes of padding between the buffers, the problem goes away.

 The PCI spec says that the PCI bridge is supposed to flush any data from
 it's prefetch buffers that are not read by the bus master, so technically,
 this isn't supposed to happen.

 I've tried making sure that buffers are cache line (and page) aligned, and
 are multiples of cache lines, but it's made no difference. PIO mode works
 fine, and I've checked the data with the CPU just before, and immediately
 after the DMA and the driver sees no data integrity issues. There are memory
 write barriers just before the DMA start, so all the registers should be
 correct before the DMA starts.

 For background info, the device doing the bus mastering is a Xilinx Virtex 5
 FPGA. We've monitored the data as it comes off the PCI bus using ChipScope -
 so the firmware should not be manipulating the data in any way.

 We have some hardware/firmware/drivers that has a lot of common code that
 runs on an x86 platform (as opposed to powerpc), and that works without any
 issues whatsoever.

 Has anyone got any ideas what this might be? Does anyone of know issues with
 PCI bridges on the PowerPC platform? Is there extra things that need to be
 done from the driver when DMAing on PowerPC (I've looked at other drivers
 and there's nothing obvious). The chip errata doesn't have anything on it
 that looks like it could cause this.

 I'm really hoping this is something that we're doing wrong in the driver or
 the firmware

Re: [PATCH v5 0/4] Series short description

2009-05-26 Thread Roderick Colenbrander
On Mon, May 25, 2009 at 10:47 PM, Roderick Colenbrander
thunderbir...@gmail.com wrote:
 On Mon, May 25, 2009 at 4:41 PM, Grant Likely grant.lik...@secretlab.ca 
 wrote:
 Repost of ml510 series.  This time against 2.6.30-rc7 and with the .dts
 file included.

 g.

 --
 Grant Likely, B.Sc. P.Eng.
 Secret Lab Technologies Ltd.


 Thanks, I will check it out tomorrow.

 Roderick


Hi,

I have tested the ml510 patches. The code works properly but I had to
make a few slight changes to get it functioning. The most important
change was in xilinx_intc driver. For level interrupts the ack command
was removed during the xilinx_intc rewrite which caused a null pointer
derefence in the i8259 cascade code. I have now changed it to:
/* Let xilinx_intc end the interrupt */
desc-chip-mask(irq);
desc-chip-unmask(irq);

This seems to work properly. Further the driver now also has proper
level support, so i think my dts file has some errors. The pci
interrupts (a/b/c/d) are all active low, so they need to be changed to
'3' for the sense level. Further the i8259 is active high which needs
to be set to 2 instead of 3.

Further I have tested the need for the outb to 0x4d0/0x4d1. Removing
those lines causes interrupt timeouts and ide won't function.
Freescale does the same in arch/powerpc/platforms/fsl_uli1575.c (which
is a much newer version of this chipset) in quirk_final_uli1575 but
they are doing it for some more interrupts. I think this code should
be done using a similar quirk in virtex_ml510.c

Roderick
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH v5 0/4] Series short description

2009-05-26 Thread Roderick Colenbrander
On Tue, May 26, 2009 at 2:41 PM, Roderick Colenbrander
thunderbir...@gmail.com wrote:
 On Mon, May 25, 2009 at 10:47 PM, Roderick Colenbrander
 thunderbir...@gmail.com wrote:
 On Mon, May 25, 2009 at 4:41 PM, Grant Likely grant.lik...@secretlab.ca 
 wrote:
 Repost of ml510 series.  This time against 2.6.30-rc7 and with the .dts
 file included.

 g.

 --
 Grant Likely, B.Sc. P.Eng.
 Secret Lab Technologies Ltd.


 Thanks, I will check it out tomorrow.

 Roderick


 Hi,

 I have tested the ml510 patches. The code works properly but I had to
 make a few slight changes to get it functioning. The most important
 change was in xilinx_intc driver. For level interrupts the ack command
 was removed during the xilinx_intc rewrite which caused a null pointer
 derefence in the i8259 cascade code. I have now changed it to:
 /* Let xilinx_intc end the interrupt */
 desc-chip-mask(irq);
 desc-chip-unmask(irq);

 This seems to work properly. Further the driver now also has proper
 level support, so i think my dts file has some errors. The pci
 interrupts (a/b/c/d) are all active low, so they need to be changed to
 '3' for the sense level. Further the i8259 is active high which needs
 to be set to 2 instead of 3.

 Further I have tested the need for the outb to 0x4d0/0x4d1. Removing
 those lines causes interrupt timeouts and ide won't function.
 Freescale does the same in arch/powerpc/platforms/fsl_uli1575.c (which
 is a much newer version of this chipset) in quirk_final_uli1575 but
 they are doing it for some more interrupts. I think this code should
 be done using a similar quirk in virtex_ml510.c

 Roderick


I have just tested the following and it seemed to work fine.
static void __devinit ml510_ali_quirk_final(struct pci_dev *dev)
{
/* Program irq 7 (usb/audio), 14/15 (ide) to level sensitive */
/* This looks like a dirty hack to me --gcl */
outb(0xc0, 0x4d0);
outb(0xc0, 0x4d1);
}
DECLARE_PCI_FIXUP_FINAL(0x10b9, 0x1533, ml510_ali_quirk_final);

I'm not sure what is preferred level or edge interrupts as the ide
controller can be programmed to both (I would just have to write to
config register 0x44 and 0x75).

Roderick
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH v5 0/4] Series short description

2009-05-25 Thread Roderick Colenbrander
On Mon, May 25, 2009 at 4:41 PM, Grant Likely grant.lik...@secretlab.ca wrote:
 Repost of ml510 series.  This time against 2.6.30-rc7 and with the .dts
 file included.

 g.

 --
 Grant Likely, B.Sc. P.Eng.
 Secret Lab Technologies Ltd.


Thanks, I will check it out tomorrow.

Roderick
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH v4 3/3] powerpc/virtex: Add Xilinx ML510 reference designsupport

2009-05-21 Thread Roderick Colenbrander
 Yeow... I agree about the dirty hack part...  shouldn't this be in the
 device tree somewhere, or in the ali driver?

 I'm curious if this works on ml410 as well..  (Yes, I know, does this
 really matter much?  But there are still a bunch of them floating around
 in universities.)  It may be nice to factor this out so ml410/ppc405 and
 microblaze can get it as well.

 Steve

Yes the code can work one the ML410 as well. The thing is that you
would need a recent reference design from Xilinx. Before Xilinx used a
OPB pci bridge and these days they use a PLB (v46) pci bridge. The old
reference designs use the OPB core. I saw someone using a ML410
reference design which used the PBL pci soft-core and the same memory
addresses were even used as in the ml510 reference design I'm using.
I'm not sure where the guy got the design since the xilinx site only
shows old opb_pci stuff. (though the core is nearly the same) Further
most devices are also at the same locations on the pci bus.

Further the ml410 also offers good old lpt1 and some other things
which aren't on the ml510 but yes the pci code and big parts of the
dts file I wrote can be reused.

Roderick
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH v4 0/3] Add support for ML510 board

2009-05-21 Thread Roderick Colenbrander
On Thu, May 21, 2009 at 6:24 PM, Grant Likely grant.lik...@secretlab.ca wrote:
 Heck, I don't know if this stuff even works, but I've refactored
 Roderick's patches into something closer to the structure that I'd like
 to see.  There are still a few things that bother me, but I think it
 is mostly there.

 It at least boots on an ML507 board.

 Roderick, can you please take a look?

 Thanks,
 g.

 --
 Grant Likely, B.Sc. P.Eng.
 Secret Lab Technologies Ltd.


From a quick glance it looks good. I will test it on monday.

Roderick
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH v4 3/3] powerpc/virtex: Add Xilinx ML510 reference designsupport

2009-05-21 Thread Roderick Colenbrander
Hi Stephen,

Grant forgot to attach the dts file (but a next patch will add it).
The dts file contains some lines for the pci bus mapping. The lines
are attached below. For pci support I'm using the reference bsb with
pci 'ML510 BSB1 Pcores Design' for PowerPC at:
http://www.xilinx.com/products/boards/ml510/ml510_10.1_3_1/bsb.htm.
The patch also contains a tutorial on how to add pci yourself.

As I mention in the comment of the plbv46_pci stuff C_IPIFBAR2PCIBAR_0
is not set correctly. Benjamin Herrenschmidt told me that inbound and
outbound pci transactions shouldn't overlap. With the value at ipif
plb 0xa000 maps to 0 on the pci side while the pci soft-core also
thinks that 0 maps to address 0 of the system memory. Setting
C_IPIFBAR2PCIBAR_0 to e.g. 0xa000 like I'm doing maps ipif plb
0xa000 to 0xa000 on the pci side and prevents this confusion.
The same is also wrong in the guides for the ml410.

Could you forward it to the right people so that this can get fixed?
No other changes are needed except for this one.

Roderick


+   plbv46_pci_0: plbv46-...@85e0 {
+   #size-cells = 2;
+   #address-cells = 3;
+   compatible = xlnx,plbv46-pci-1.03.a;
+   device_type = pci;
+   reg =  0x85e0 0x1 ;
+   /* The default ML510 BSB has
C_IPIFBAR2PCIBAR_0 set to 0 which means that a read/write to
+* the memory mapped i/o region (which starts
at 0xa000) for pci bar 0 on the plb side
+* translates to 0.
+* It is important to this value to
0xa000, so that inbound and outbound pci transactions
+* work properly including DMA.
+*/
+   ranges = 0x0200 0x 0xa000
0xa000 0x 0x2000
+ 0x0100 0x 0x
0xf000 0x 0x0001;
+
+   #interrupt-cells = 1;
+   interrupt-parent = xps_intc_0;
+   interrupt-map-mask = 0xff00 0x0 0x0 0x7;
+   interrupt-map = 
+   /* IRQ mapping for pci slots and ALI
M1533 periperhals. In total there are
+* 5 interrupt lines connected to a
xps_intc controller. Four of them are PCI
+* IRQ A, B, C, D and which correspond
to respectively xpx_intc 5, 4, 3 and 2.
+* The fifth interrupt line is
connected to the south bridge and this one
+* uses irq 1 and is active high
instead of active low.
+*
+* The M1533 contains various
peripherals including AC97 audio, a modem, USB,
+* IDE and some power management
stuff. The modem isn't connected on the ML510
+* and the power management core also
isn't used.
+*/
+
+   /* IDSEL 0x16 / dev=6, bus=0 / PCI slot 3 */
+   0x3000 0 0 1 xps_intc_0 3 2
+   0x3000 0 0 2 xps_intc_0 2 2
+   0x3000 0 0 3 xps_intc_0 5 2
+   0x3000 0 0 4 xps_intc_0 4 2
+
+   /* IDSEL 0x13 / dev=3, bus=1 / PCI slot 4 */
+   /*
+   0x11800 0 0 1 xps_intc_0 5 0 2
+   0x11800 0 0 2 xps_intc_0 4 0 2
+   0x11800 0 0 3 xps_intc_0 3 0 2
+   0x11800 0 0 4 xps_intc_0 2 0 2
+   */
+
+   /* According to the datasheet +
schematic ABCD [FPGA] of slot 5 is mapped to DABC.
+* Testing showed that at least A maps
to B, the mapping of the other pins is a guess
+* and for that reason the lines have
been commented.
+*/
+   /* IDSEL 0x15 / dev=5, bus=0 / PCI slot 5 */
+   0x2800 0 0 1 xps_intc_0 4 2
+   /*
+   0x2800 0 0 2 xps_intc_0 3 2
+   0x2800 0 0 3 xps_intc_0 2 2
+   0x2800 0 0 4 xps_intc_0 5 2
+   */
+
+   /* IDSEL 0x12 / dev=2, bus=1 / PCI slot 6 */
+   /*
+   0x11000 0 0 1 xps_intc_0 4 0 2
+   0x11000 0 0 2 xps_intc_0 3 0 2
+   0x11000 0 0 3 xps_intc_0 2 0 2
+   0x11000 0 0 4 xps_intc_0 5 0 2
+   */
+

Patch 1/2: Add support for Xilinx PLB PCI soft-core [attempt3]

2009-05-15 Thread Roderick Colenbrander
Hi,

As requested here the same patch but now with a signed-off line which I forgot.

Regards,
Roderick Colenbrander

Signed-off-by: Roderick Colenbrander thunderbir...@gmail.com


From 2b34a315b18834448c0a8218d4da85ffaf76039e Mon Sep 17 00:00:00 2001
From: Roderick Colenbrander thunderbir...@gmail.com
Date: Tue, 14 Apr 2009 15:45:07 +0200
Subject: [PATCH] Add support for the Xilinx PLB PCI soft-core which is
used on Xilinx ML410 and ML510 FPGA boards.

---
 arch/powerpc/sysdev/Kconfig      |    4 ++
 arch/powerpc/sysdev/Makefile     |    1 +
 arch/powerpc/sysdev/virtex_pci.c |   99 ++
 3 files changed, 104 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/sysdev/virtex_pci.c

diff --git a/arch/powerpc/sysdev/Kconfig b/arch/powerpc/sysdev/Kconfig
index 3965828..2d0be14 100644
--- a/arch/powerpc/sysdev/Kconfig
+++ b/arch/powerpc/sysdev/Kconfig
@@ -12,3 +12,7 @@ config PPC_MSI_BITMAP
       depends on PCI_MSI
       default y if MPIC
       default y if FSL_PCI
+
+config XILINX_VIRTEX_PCI
+       bool
+       depends on PCI
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index b33b28a..b93794e 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_IPIC)            += ipic.o
 obj-$(CONFIG_4xx)              += uic.o
 obj-$(CONFIG_4xx_SOC)          += ppc4xx_soc.o
 obj-$(CONFIG_XILINX_VIRTEX)    += xilinx_intc.o
+obj-$(CONFIG_XILINX_VIRTEX_PCI)        += virtex_pci.o
 obj-$(CONFIG_OF_RTC)           += of_rtc.o
 ifeq ($(CONFIG_PCI),y)
 obj-$(CONFIG_4xx)              += ppc4xx_pci.o
diff --git a/arch/powerpc/sysdev/virtex_pci.c b/arch/powerpc/sysdev/virtex_pci.c
new file mode 100644
index 000..b5137b5
--- /dev/null
+++ b/arch/powerpc/sysdev/virtex_pci.c
@@ -0,0 +1,99 @@
+/*
+ * PCI support for Xilinx plbv46_pci soft-core which can be used on
+ * Xilinx Virtex ML410 / ML510 boards.
+ *
+ * Copyright 2009 Roderick Colenbrander
+ *
+ * The pci bridge fixup code was copied from ppc4xx_pci.c and was written
+ * by Benjamin Herrenschmidt.
+ * Copyright 2007 Ben. Herrenschmidt b...@kernel.crashing.org, IBM Corp.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include linux/pci.h
+#include mm/mmu_decl.h
+#include asm/io.h
+
+#define XPLB_PCI_ADDR 0x10c
+#define XPLB_PCI_DATA 0x110
+#define XPLB_PCI_BUS  0x114
+
+#define PCI_HOST_ENABLE_CMD PCI_COMMAND_SERR | PCI_COMMAND_PARITY |
PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY
+
+static void fixup_virtex_pci_bridge(struct pci_dev *dev)
+{
+       struct pci_controller *hose;
+       int i;
+
+       if (dev-devfn || dev-bus-self)
+               return;
+
+       hose = pci_bus_to_host(dev-bus);
+       if (!hose)
+               return;
+
+       if(!of_device_is_compatible(hose-dn, xlnx,plbv46-pci-1.03.a))
+               return;
+
+       /* Hide the PCI host BARs from the kernel as their content doesn't
+        * fit well in the resource management
+        */
+       for (i = 0; i  DEVICE_COUNT_RESOURCE; i++)
+       {
+               dev-resource[i].start = 0;
+               dev-resource[i].end = 0;
+               dev-resource[i].flags = 0;
+       }
+
+       dev_info(dev-dev, PCI: Hiding Xilinx plb-pci host bridge
resources %s\n, pci_name(dev));
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, fixup_virtex_pci_bridge);
+
+void virtex_pci_init(void)
+{
+       struct pci_controller *hose;
+       struct resource r;
+       void __iomem *pci_reg;
+       struct device_node *pci_node = of_find_compatible_node(NULL,
NULL, xlnx,plbv46-pci-1.03.a);
+
+       if(!pci_node)
+               return;
+
+       printk(Found a Xilinx plb-pci host bridge\n);
+
+       if(of_address_to_resource(pci_node, 0, r))
+       {
+               printk(No address for Xilinx plb-pci host bridge\n);
+               return;
+       }
+
+       hose = pcibios_alloc_controller(pci_node);
+       if (!hose)
+               return;
+
+       hose-first_busno = 0;
+       hose-last_busno = 0;
+
+       /* Setup config space */
+       setup_indirect_pci(hose, r.start + XPLB_PCI_ADDR, r.start +
XPLB_PCI_DATA, PPC_INDIRECT_TYPE_SET_CFG_TYPE);
+
+       /* According to the xilinx plbv46_pci documentation the soft-core starts
+        * a self-init when the bus master enable bit is set. Without this bit
+        * set the pci bus can't be scanned.
+        */
+       early_write_config_word(hose, 0, 0, PCI_COMMAND, PCI_HOST_ENABLE_CMD);
+
+       /* Set the max latency timer to 255 */
+       early_write_config_byte(hose, 0, 0, PCI_LATENCY_TIMER, 0xff);
+
+       /* Set the max bus number to 255 */
+       pci_reg = of_iomap(pci_node, 0);
+       out_8(pci_reg + XPLB_PCI_BUS, 0xff);
+       iounmap(pci_reg);
+
+       /* Register the host bridge with the linux kernel! */
+       pci_process_bridge_OF_ranges(hose

Fwd: Patch 2/2: Add Xilinx ML510 reference design support [attempt2]

2009-05-15 Thread Roderick Colenbrander
Hi,

As requested here the same patch but now with a signed-off line which I forgot.

Regards,
Roderick Colenbrander

Signed-off-by: Roderick Colenbrander thunderbir...@gmail.com


From f46fa90e4d066767cc4fc1c5b8dc2f9ee013ea0a Mon Sep 17 00:00:00 2001
From: Roderick Colenbrander thunderbir...@gmail.com
Date: Tue, 14 Apr 2009 15:49:32 +0200
Subject: [PATCH] Add Xilinx ML510 reference design support.

---
 arch/powerpc/boot/dts/virtex440-ml510.dts |  453 +
 arch/powerpc/platforms/44x/Kconfig        |   10 +
 arch/powerpc/platforms/44x/Makefile       |    1 +
 arch/powerpc/platforms/44x/ml510.c        |  161 ++
 4 files changed, 625 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/virtex440-ml510.dts
 create mode 100644 arch/powerpc/platforms/44x/ml510.c

diff --git a/arch/powerpc/boot/dts/virtex440-ml510.dts
b/arch/powerpc/boot/dts/virtex440-ml510.dts
new file mode 100644
index 000..7ded73c
--- /dev/null
+++ b/arch/powerpc/boot/dts/virtex440-ml510.dts
@@ -0,0 +1,453 @@
+/*
+ * Xilinx ML510 Reference Design support
+ * This DTS file was created for the ml510_bsb1_pcores_ppc440 reference design.
+ * The reference design contains a bug which prevent PCI DMA from
working properly.
+ * A description of the bug is given in the plbv46_pci section. It
needs to be fixed
+ * by the user until Xilinx updates their reference design.
+ *
+ * Copyright 2009, Roderick Colenbrander
+ */
+
+/dts-v1/;
+/ {
+       #address-cells = 1;
+       #size-cells = 1;
+       compatible = xlnx,ml510-ref-design;
+       dcr-parent = ppc440_0;
+       model = testing;
+       DDR2_SDRAM_DIMM0: mem...@0 {
+               device_type = memory;
+               reg =  0x0 0x2000 ;
+       } ;
+       alias {
+               ethernet0 = Hard_Ethernet_MAC;
+               serial0 = RS232_Uart_1;
+       } ;
+       chosen {
+                bootargs = console=ttyS0 root=/dev/xsa2 init=/etc/preinit;
+//                bootargs = console=ttyS0 root=/dev/ram;
+                linux,stdout-path = /p...@0/ser...@83e0;
+       } ;
+       cpus {
+               #address-cells = 1;
+               #cpus = 0x1;
+               #size-cells = 0;
+               ppc440_0: c...@0 {
+                       #address-cells = 1;
+                       #size-cells = 1;
+                       clock-frequency = 3;
+                       compatible = PowerPC,440, ibm,ppc440;
+                       d-cache-line-size = 0x20;
+                       d-cache-size = 0x8000;
+                       dcr-access-method = native;
+                       dcr-controller ;
+                       device_type = cpu;
+                       i-cache-line-size = 0x20;
+                       i-cache-size = 0x8000;
+                       model = PowerPC,440;
+                       reg = 0;
+                       timebase-frequency = 3;
+                       xlnx,apu-control = 0x2000;
+                       xlnx,apu-udi-0 = 0x0;
+                       xlnx,apu-udi-1 = 0x0;
+                       xlnx,apu-udi-10 = 0x0;
+                       xlnx,apu-udi-11 = 0x0;
+                       xlnx,apu-udi-12 = 0x0;
+                       xlnx,apu-udi-13 = 0x0;
+                       xlnx,apu-udi-14 = 0x0;
+                       xlnx,apu-udi-15 = 0x0;
+                       xlnx,apu-udi-2 = 0x0;
+                       xlnx,apu-udi-3 = 0x0;
+                       xlnx,apu-udi-4 = 0x0;
+                       xlnx,apu-udi-5 = 0x0;
+                       xlnx,apu-udi-6 = 0x0;
+                       xlnx,apu-udi-7 = 0x0;
+                       xlnx,apu-udi-8 = 0x0;
+                       xlnx,apu-udi-9 = 0x0;
+                       xlnx,dcr-autolock-enable = 0x1;
+                       xlnx,dcu-rd-ld-cache-plb-prio = 0x0;
+                       xlnx,dcu-rd-noncache-plb-prio = 0x0;
+                       xlnx,dcu-rd-touch-plb-prio = 0x0;
+                       xlnx,dcu-rd-urgent-plb-prio = 0x0;
+                       xlnx,dcu-wr-flush-plb-prio = 0x0;
+                       xlnx,dcu-wr-store-plb-prio = 0x0;
+                       xlnx,dcu-wr-urgent-plb-prio = 0x0;
+                       xlnx,dma0-control = 0x0;
+                       xlnx,dma0-plb-prio = 0x0;
+                       xlnx,dma0-rxchannelctrl = 0x101;
+                       xlnx,dma0-rxirqtimer = 0x3ff;
+                       xlnx,dma0-txchannelctrl = 0x101;
+                       xlnx,dma0-txirqtimer = 0x3ff;
+                       xlnx,dma1-control = 0x0;
+                       xlnx,dma1-plb-prio = 0x0;
+                       xlnx,dma1-rxchannelctrl = 0x101;
+                       xlnx,dma1-rxirqtimer = 0x3ff;
+                       xlnx,dma1-txchannelctrl = 0x101;
+                       xlnx,dma1-txirqtimer = 0x3ff;
+                       xlnx,dma2-control = 0x0;
+                       xlnx,dma2-plb-prio = 0x0;
+                       xlnx,dma2-rxchannelctrl = 0x101

Re: RFC Patch: Use x86 init_hwif in the alim15x3 for x86-like PowerPC systems

2009-04-17 Thread Roderick Colenbrander
On Fri, Apr 17, 2009 at 12:04 AM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
 On Thu, Apr 16, 2009 at 11:27:34PM +0200, Roderick Colenbrander wrote:
 On Thu, Apr 16, 2009 at 10:57 PM, Anton Vorontsov
 avoront...@ru.mvista.com wrote:
  On Thu, Apr 16, 2009 at 09:30:00PM +0200, Bartlomiej Zolnierkiewicz wrote:
 
  Hi,
 
  On Wednesday 15 April 2009 16:34:22 Roderick Colenbrander wrote:
   Hi,
  
   I'm using a Xilinx ML510 it features a PowerPC 440 cpu inside a
   Virtex-5 FPGA. The board also contains a ALI M1533 south bridge
   for IDE, USB and Audio. I did a lot of work to get the pci bus working
   on this board and it works correctly but the default init code
   of the alim15x3 driver doesn't work for me. The driver explicitly
   disabled some initialization code for powerpc after uncommenting this
   code it works properly. Benjamin Herrenschmidt and I think this
   !CONFIG_PPC check should be removed because the system behaves
   like a real 'x86' system (also the i8259 interrupt controller is used).
 
  Ben, I guess you are OK with the change and there are no longer other
  platforms requiring CONFIG_PPC check below?  [I don't see your ACK here]
 
  I'd like to nak this patch. It'll break MPC8610HPCD boards.
 
  See commit 6d1cee44361b8d06ccd1812e80448d86ae60dfe3
 
  I'm not sure how should we handle this for Xilinx PPC, MPC8610
  PPC and Sparc all at the same time, but it's obvious that #ifdef
  isn't enough any longer...
 
 
 

 If it is really a board specific issue (in case of powerpc it appears
 to be one) we could also use the default_irq override in ppc_md. What
 do you think?

 Um, I don't see default_irq in the ppc_md. Do you want to add one?

 I wonder if DECLARE_PCI_FIXUP_*() mechanism will work... see
 arch/powerpc/platforms/fsl_uli1575.c as an example for board-specific
 PCI fixups.

It seems default_irq was the name on old kernels. These days it is
called pci_get_legacy_ide_irq.

Roderick
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: pci32 code - early_*config*

2009-04-17 Thread Roderick Colenbrander
On Fri, Apr 17, 2009 at 9:25 AM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
 On Wed, 2009-04-15 at 01:17 -0500, Kumar Gala wrote:
 Ben,

 I was looking at what I need to get some additional bits of PCI code
 building w/your ppc64 booke patches.  One thing it looks like we need
 is the early config cycle code.  The question I have is do we think we
 still need the null_ops support?  Also do we think we every get called
 with a NULL hose?

 This is fake_pci_bus() in arch/powerpc/kernel/pci_32.c

 Hrm.

 I'm not fan of the early config stuff, remind me why we need it ?

 Ben.


 ___
 Linuxppc-dev mailing list
 Linuxppc-dev@ozlabs.org
 https://ozlabs.org/mailman/listinfo/linuxppc-dev


There are cases when it is really needed (or you would have to access
the address and data bus by hand). In my case I'm using a Xilinx PLB
soft-core and if certain options in the configuration header aren't
set (which aren't set by default) the soft-core is basically disabled.
Cases like this look like valid cases in which early config should be
used.

Roderick Colenbrander
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: PowerPC iotable_init equivalent?

2009-04-17 Thread Roderick Colenbrander
On Fri, Apr 17, 2009 at 11:21 PM, Eddie Dawydiuk ed...@embeddedarm.com wrote:
 Hello,

 In the past I've worked with ARM architectures where I could setup virtual /
 physical address mappings so I don't have to ioremap then pass around
 pointers. Does PowerPC have an equivalent abstraction? If not whats the
 recommended approach?

 That is, is there a better approach to the following...

 volatile static unsigned char *my_reg = NULL;

 static inline void read_func() {

        if (!my_reg)
                my_reg = (unsigned char *)
                        ioremap(REG_PHYS_BASE, REG_SIZE);
 //do something with the reg
 }


 static inline void write_func() {

        if (!my_reg)
                my_reg = (unsigned char *)
                        ioremap(REG_PHYS_BASE, REG_SIZE);
 //do something with the reg
 }

 --
 Best Regards,
 
  Eddie Dawydiuk, Technologic Systems | voice:  (480) 837-5200
  16525 East Laser Drive              | fax:    (480) 837-5300
  Fountain Hills, AZ 85268            | web: www.embeddedARM.com
 ___
 Linuxppc-dev mailing list
 Linuxppc-dev@ozlabs.org
 https://ozlabs.org/mailman/listinfo/linuxppc-dev


In general you set devices up a dts file. You can reach its contents
using openfirmware functions (of_*). In general you use an of_*
function to look up your periperhal in the device tree. Once you have
its node you would able to do e.g. of_iomap (which uses ioremap with
the right offsets behind its back) to map the device. So you don't
hard code physical addresses anymore in the code.

Regards,
Roderick Colenbrander
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: OF PCI howto?

2009-04-16 Thread Roderick Colenbrander
On Thu, Apr 16, 2009 at 10:05 AM, Joakim Tjernlund
joakim.tjernl...@transmode.se wrote:
 Kumar Gala ga...@kernel.crashing.org wrote on 15/04/2009 17:20:21:
 On Apr 15, 2009, at 8:08 AM, Wolfram Sang wrote:

  On Wed, Apr 15, 2009 at 02:54:57PM +0200, Joakim Tjernlund wrote:
 
  dts fragment correct for my setup? If not, is there a better
  example I can
  look at?
 
  Maybe this message/thread can help you:
 
  http://ozlabs.org/pipermail/devicetree-discuss/2009-March/000597.html

 You may also want to take a look at ePAPR on the power.org site

 Thanks guys

 Looking in ePAPR I see I should read the IDSEL like this:
                /* IDSEL 0x11 AD17 */
                0x8800 0x0 0x0 0x1 ipic 20 0x8 /* INTA */
                0x8800 0x0 0x0 0x2 ipic 21 0x8 /* INTB */
                0x8800 0x0 0x0 0x3 ipic 22 0x8 /* INTC */
                0x8800 0x0 0x0 0x4 ipic 23 0x8 /* INTD */

 grouping the first line into:
 0x8800 0x0 0x0 0x1 ipic 20 0x8 /* INTA */

 0x8800 0x0 0x0 = child unit address
 0x1 = child interrupt specifier = INTA
 ipic = interrupt parent
 20 0x8 = parent interrupt specifier

 Questions:
  MPC832x appears to only have INTA so why are the INTB,INTC
  and INTD lines there?

  I don't understand how IDSEL values are decided. Are IDSEL 0x11-0x18
 randomly
  selected or are they fixed for MPC832x?

The idsel values depend on how the pci slots are wired on your board.
The 0x8800 value is
in general a function of bus, device and function number. ( bus  16
| devfn  8)

Further I would also watch out with the parent interrupt specifier
e.g. '20 0x8'. The openfirmware spec
normally suggests to use a value of '2' for interrupts which are
active low. During parsing of the interrupt-map
this value is normally translated using 'xlate' to linux kernel values
(active low is defined as IRQ_TYPE_LEVEL_LOW  0x0008 in the
kernel).
The ipic driver code and various dts files are evil and store the
linux kernel value inside the DTS file, so they don't do any
conversion whis is EVIL
in my opinion. Watch out for that. (The corresponding DTS files and
drivers should be updated).

Regards,
Roderick Colenbrander
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: RFC Patch: Use x86 init_hwif in the alim15x3 for x86-like PowerPC systems

2009-04-16 Thread Roderick Colenbrander
On Thu, Apr 16, 2009 at 10:57 PM, Anton Vorontsov
avoront...@ru.mvista.com wrote:
 On Thu, Apr 16, 2009 at 09:30:00PM +0200, Bartlomiej Zolnierkiewicz wrote:

 Hi,

 On Wednesday 15 April 2009 16:34:22 Roderick Colenbrander wrote:
  Hi,
 
  I'm using a Xilinx ML510 it features a PowerPC 440 cpu inside a
  Virtex-5 FPGA. The board also contains a ALI M1533 south bridge
  for IDE, USB and Audio. I did a lot of work to get the pci bus working
  on this board and it works correctly but the default init code
  of the alim15x3 driver doesn't work for me. The driver explicitly
  disabled some initialization code for powerpc after uncommenting this
  code it works properly. Benjamin Herrenschmidt and I think this
  !CONFIG_PPC check should be removed because the system behaves
  like a real 'x86' system (also the i8259 interrupt controller is used).

 Ben, I guess you are OK with the change and there are no longer other
 platforms requiring CONFIG_PPC check below?  [I don't see your ACK here]

 I'd like to nak this patch. It'll break MPC8610HPCD boards.

 See commit 6d1cee44361b8d06ccd1812e80448d86ae60dfe3

 I'm not sure how should we handle this for Xilinx PPC, MPC8610
 PPC and Sparc all at the same time, but it's obvious that #ifdef
 isn't enough any longer...




If it is really a board specific issue (in case of powerpc it appears
to be one) we could also use the default_irq override in ppc_md. What
do you think?

Roderick
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Patch 1/2: Add support for Xilinx PLB PCI soft-core [attempt2]

2009-04-15 Thread Roderick Colenbrander
Hi,

This is an updated version of the patch which takes into account a few changes 
suggested by Grant which I forgot to add.

Regards,
Roderick Colenbrander

From 2b34a315b18834448c0a8218d4da85ffaf76039e Mon Sep 17 00:00:00 2001
From: Roderick Colenbrander thunderbir...@gmail.com
Date: Tue, 14 Apr 2009 15:45:07 +0200
Subject: [PATCH] Add support for the Xilinx PLB PCI soft-core which is used on 
Xilinx ML410 and ML510 FPGA boards.

---
 arch/powerpc/sysdev/Kconfig  |4 ++
 arch/powerpc/sysdev/Makefile |1 +
 arch/powerpc/sysdev/virtex_pci.c |   99 ++
 3 files changed, 104 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/sysdev/virtex_pci.c

diff --git a/arch/powerpc/sysdev/Kconfig b/arch/powerpc/sysdev/Kconfig
index 3965828..2d0be14 100644
--- a/arch/powerpc/sysdev/Kconfig
+++ b/arch/powerpc/sysdev/Kconfig
@@ -12,3 +12,7 @@ config PPC_MSI_BITMAP
depends on PCI_MSI
default y if MPIC
default y if FSL_PCI
+
+config XILINX_VIRTEX_PCI
+   bool
+   depends on PCI
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index b33b28a..b93794e 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_IPIC)+= ipic.o
 obj-$(CONFIG_4xx)  += uic.o
 obj-$(CONFIG_4xx_SOC)  += ppc4xx_soc.o
 obj-$(CONFIG_XILINX_VIRTEX)+= xilinx_intc.o
+obj-$(CONFIG_XILINX_VIRTEX_PCI)+= virtex_pci.o
 obj-$(CONFIG_OF_RTC)   += of_rtc.o
 ifeq ($(CONFIG_PCI),y)
 obj-$(CONFIG_4xx)  += ppc4xx_pci.o
diff --git a/arch/powerpc/sysdev/virtex_pci.c b/arch/powerpc/sysdev/virtex_pci.c
new file mode 100644
index 000..b5137b5
--- /dev/null
+++ b/arch/powerpc/sysdev/virtex_pci.c
@@ -0,0 +1,99 @@
+/*
+ * PCI support for Xilinx plbv46_pci soft-core which can be used on
+ * Xilinx Virtex ML410 / ML510 boards.
+ *
+ * Copyright 2009 Roderick Colenbrander
+ *
+ * The pci bridge fixup code was copied from ppc4xx_pci.c and was written
+ * by Benjamin Herrenschmidt.
+ * Copyright 2007 Ben. Herrenschmidt b...@kernel.crashing.org, IBM Corp.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include linux/pci.h
+#include mm/mmu_decl.h
+#include asm/io.h
+
+#define XPLB_PCI_ADDR 0x10c
+#define XPLB_PCI_DATA 0x110
+#define XPLB_PCI_BUS  0x114
+
+#define PCI_HOST_ENABLE_CMD PCI_COMMAND_SERR | PCI_COMMAND_PARITY | 
PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY
+
+static void fixup_virtex_pci_bridge(struct pci_dev *dev)
+{
+   struct pci_controller *hose;
+   int i;
+
+   if (dev-devfn || dev-bus-self)
+   return;
+
+   hose = pci_bus_to_host(dev-bus);
+   if (!hose)
+   return;
+
+   if(!of_device_is_compatible(hose-dn, xlnx,plbv46-pci-1.03.a))
+   return;
+
+   /* Hide the PCI host BARs from the kernel as their content doesn't
+* fit well in the resource management
+*/
+   for (i = 0; i  DEVICE_COUNT_RESOURCE; i++)
+   {
+   dev-resource[i].start = 0;
+   dev-resource[i].end = 0;
+   dev-resource[i].flags = 0;
+   }
+
+   dev_info(dev-dev, PCI: Hiding Xilinx plb-pci host bridge resources 
%s\n, pci_name(dev));
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, fixup_virtex_pci_bridge);
+
+void virtex_pci_init(void)
+{
+   struct pci_controller *hose;
+   struct resource r;
+   void __iomem *pci_reg;
+   struct device_node *pci_node = of_find_compatible_node(NULL, NULL, 
xlnx,plbv46-pci-1.03.a);
+
+   if(!pci_node)
+   return;
+
+   printk(Found a Xilinx plb-pci host bridge\n);
+
+   if(of_address_to_resource(pci_node, 0, r))
+   {
+   printk(No address for Xilinx plb-pci host bridge\n);
+   return;
+   }
+
+   hose = pcibios_alloc_controller(pci_node);
+   if (!hose)
+   return;
+
+   hose-first_busno = 0;
+   hose-last_busno = 0;
+
+   /* Setup config space */
+   setup_indirect_pci(hose, r.start + XPLB_PCI_ADDR, r.start + 
XPLB_PCI_DATA, PPC_INDIRECT_TYPE_SET_CFG_TYPE);
+
+   /* According to the xilinx plbv46_pci documentation the soft-core starts
+* a self-init when the bus master enable bit is set. Without this bit
+* set the pci bus can't be scanned.
+*/
+   early_write_config_word(hose, 0, 0, PCI_COMMAND, PCI_HOST_ENABLE_CMD);
+
+   /* Set the max latency timer to 255 */
+   early_write_config_byte(hose, 0, 0, PCI_LATENCY_TIMER, 0xff);
+
+   /* Set the max bus number to 255 */
+   pci_reg = of_iomap(pci_node, 0);
+   out_8(pci_reg + XPLB_PCI_BUS, 0xff);
+   iounmap(pci_reg);
+
+   /* Register the host bridge with the linux kernel! */
+   pci_process_bridge_OF_ranges(hose, pci_node, 1

Patch 2/2: Add Xilinx ML510 reference design support [attempt2]

2009-04-15 Thread Roderick Colenbrander
Hi,

This is an updated version of my patch from yesterday it contains some fixes. I 
had some c++ style comments
left in my previous version of this patch and there was a small error in the 
dts file.

Regards,
Roderick Colenbrander

From 018041061bc233c09340eff20fcd4e8bc75da1d3 Mon Sep 17 00:00:00 2001
From: Roderick Colenbrander thunderbir...@gmail.com
Date: Tue, 14 Apr 2009 15:49:32 +0200
Subject: [PATCH] Add Xilinx ML510 reference design support.

---
 arch/powerpc/boot/dts/virtex440-ml510.dts |  452 +
 arch/powerpc/platforms/44x/Kconfig|   10 +
 arch/powerpc/platforms/44x/Makefile   |1 +
 arch/powerpc/platforms/44x/ml510.c|  165 +++
 4 files changed, 628 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/virtex440-ml510.dts
 create mode 100644 arch/powerpc/platforms/44x/ml510.c

diff --git a/arch/powerpc/boot/dts/virtex440-ml510.dts 
b/arch/powerpc/boot/dts/virtex440-ml510.dts
new file mode 100644
index 000..908517a
--- /dev/null
+++ b/arch/powerpc/boot/dts/virtex440-ml510.dts
@@ -0,0 +1,452 @@
+/*
+ * Xilinx ML510 Reference Design support
+ * This DTS file was created for the ml510_bsb1_pcores_ppc440 reference design.
+ * The reference design contains a bug which prevent PCI DMA from working 
properly.
+ * A description of the bug is given in the plbv46_pci section. It needs to be 
fixed
+ * by the user until Xilinx updates their reference design.
+ *
+ * Copyright 2009, Roderick Colenbrander
+ */
+
+/dts-v1/;
+/ {
+   #address-cells = 1;
+   #size-cells = 1;
+   compatible = xlnx,ml510-ref-design;
+   dcr-parent = ppc440_0;
+   model = testing;
+   DDR2_SDRAM_DIMM0: mem...@0 {
+   device_type = memory;
+   reg =  0x0 0x2000 ;
+   } ;
+   alias {
+   ethernet0 = Hard_Ethernet_MAC;
+   serial0 = RS232_Uart_1;
+   } ;
+   chosen {
+   bootargs = console=ttyS0 root=/dev/ram;
+   linux,stdout-path = /p...@0/ser...@83e0;
+   } ;
+   cpus {
+   #address-cells = 1;
+   #cpus = 0x1;
+   #size-cells = 0;
+   ppc440_0: c...@0 {
+   #address-cells = 1;
+   #size-cells = 1;
+   clock-frequency = 3;
+   compatible = PowerPC,440, ibm,ppc440;
+   d-cache-line-size = 0x20;
+   d-cache-size = 0x8000;
+   dcr-access-method = native;
+   dcr-controller ;
+   device_type = cpu;
+   i-cache-line-size = 0x20;
+   i-cache-size = 0x8000;
+   model = PowerPC,440;
+   reg = 0;
+   timebase-frequency = 3;
+   xlnx,apu-control = 0x2000;
+   xlnx,apu-udi-0 = 0x0;
+   xlnx,apu-udi-1 = 0x0;
+   xlnx,apu-udi-10 = 0x0;
+   xlnx,apu-udi-11 = 0x0;
+   xlnx,apu-udi-12 = 0x0;
+   xlnx,apu-udi-13 = 0x0;
+   xlnx,apu-udi-14 = 0x0;
+   xlnx,apu-udi-15 = 0x0;
+   xlnx,apu-udi-2 = 0x0;
+   xlnx,apu-udi-3 = 0x0;
+   xlnx,apu-udi-4 = 0x0;
+   xlnx,apu-udi-5 = 0x0;
+   xlnx,apu-udi-6 = 0x0;
+   xlnx,apu-udi-7 = 0x0;
+   xlnx,apu-udi-8 = 0x0;
+   xlnx,apu-udi-9 = 0x0;
+   xlnx,dcr-autolock-enable = 0x1;
+   xlnx,dcu-rd-ld-cache-plb-prio = 0x0;
+   xlnx,dcu-rd-noncache-plb-prio = 0x0;
+   xlnx,dcu-rd-touch-plb-prio = 0x0;
+   xlnx,dcu-rd-urgent-plb-prio = 0x0;
+   xlnx,dcu-wr-flush-plb-prio = 0x0;
+   xlnx,dcu-wr-store-plb-prio = 0x0;
+   xlnx,dcu-wr-urgent-plb-prio = 0x0;
+   xlnx,dma0-control = 0x0;
+   xlnx,dma0-plb-prio = 0x0;
+   xlnx,dma0-rxchannelctrl = 0x101;
+   xlnx,dma0-rxirqtimer = 0x3ff;
+   xlnx,dma0-txchannelctrl = 0x101;
+   xlnx,dma0-txirqtimer = 0x3ff;
+   xlnx,dma1-control = 0x0;
+   xlnx,dma1-plb-prio = 0x0;
+   xlnx,dma1-rxchannelctrl = 0x101;
+   xlnx,dma1-rxirqtimer = 0x3ff;
+   xlnx,dma1-txchannelctrl = 0x101;
+   xlnx,dma1-txirqtimer = 0x3ff;
+   xlnx,dma2-control = 0x0;
+   xlnx,dma2-plb-prio = 0x0;
+   xlnx,dma2-rxchannelctrl = 0x101;
+   xlnx,dma2

Patch 1/2: Add support for Xilinx PLB PCI soft-core

2009-04-14 Thread Roderick Colenbrander
From c1cf80d7e5332240c2e54500476027c23b496b92 Mon Sep 17 00:00:00 2001
From: Roderick Colenbrander thunderbir...@gmail.com
Date: Tue, 14 Apr 2009 15:45:07 +0200
Subject: [PATCH] Add support for the Xilinx PLB PCI soft-core which is
used on Xilinx ML410 and ML510 FPGA boards.

---
 arch/powerpc/sysdev/Kconfig  |4 ++
 arch/powerpc/sysdev/Makefile |1 +
 arch/powerpc/sysdev/virtex_pci.c |   95
++
 3 files changed, 100 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/sysdev/virtex_pci.c

diff --git a/arch/powerpc/sysdev/Kconfig b/arch/powerpc/sysdev/Kconfig
index 3965828..2d0be14 100644
--- a/arch/powerpc/sysdev/Kconfig
+++ b/arch/powerpc/sysdev/Kconfig
@@ -12,3 +12,7 @@ config PPC_MSI_BITMAP
depends on PCI_MSI
default y if MPIC
default y if FSL_PCI
+
+config XILINX_VIRTEX_PCI
+   bool
+   depends on PCI
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index b33b28a..b93794e 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_IPIC)+= ipic.o
 obj-$(CONFIG_4xx)  += uic.o
 obj-$(CONFIG_4xx_SOC)  += ppc4xx_soc.o
 obj-$(CONFIG_XILINX_VIRTEX)+= xilinx_intc.o
+obj-$(CONFIG_XILINX_VIRTEX_PCI)+= virtex_pci.o
 obj-$(CONFIG_OF_RTC)   += of_rtc.o
 ifeq ($(CONFIG_PCI),y)
 obj-$(CONFIG_4xx)  += ppc4xx_pci.o
diff --git a/arch/powerpc/sysdev/virtex_pci.c
b/arch/powerpc/sysdev/virtex_pci.c
new file mode 100644
index 000..bf24aa4
--- /dev/null
+++ b/arch/powerpc/sysdev/virtex_pci.c
@@ -0,0 +1,95 @@
+/*
+ * PCI support for Xilinx plbv46_pci soft-core which can be used on
Xilinx Virtex ML410 / ML510 boards.
+ *
+ * Copyright 2009 Roderick Colenbrander
+ *
+ * The pci bridge fixup code was copied from ppc4xx_pci.c and was
written by Benjamin Herrenschmidt.
+ * Copyright 2007 Ben. Herrenschmidt b...@kernel.crashing.org, IBM
Corp.
+ *
+ * This file is licensed under the terms of the GNU General Public
License
+ * version 2. This program is licensed as is without any warranty of
any
+ * kind, whether express or implied.
+ */
+
+#include linux/pci.h
+#include mm/mmu_decl.h
+#include asm/io.h
+
+#define XPLB_PCI_ADDR 0x10c
+#define XPLB_PCI_DATA 0x110
+#define XPLB_PCI_BUS  0x114
+
+#define PCI_HOST_ENABLE_CMD PCI_COMMAND_SERR | PCI_COMMAND_PARITY |
PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY  
+
+static void fixup_virtex_pci_bridge(struct pci_dev *dev)
+{
+   struct pci_controller *hose;
+   int i;
+
+   if (dev-devfn != 0 || dev-bus-self != NULL)
+   return;
+
+   hose = pci_bus_to_host(dev-bus);
+   if (hose == NULL)
+   return;
+
+   if(!of_device_is_compatible(hose-dn, xlnx,plbv46-pci-1.03.a))
+   return;
+
+   /* Hide the PCI host BARs from the kernel as their content doesn't
+* fit well in the resource management
+*/
+   for (i = 0; i  DEVICE_COUNT_RESOURCE; i++) {
+   dev-resource[i].start = 0;
+   dev-resource[i].end = 0;
+   dev-resource[i].flags = 0;
+   }
+
+   dev_info(dev-dev, PCI: Hiding Xilinx plb-pci host bridge resources
%s\n, pci_name(dev));
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID,
fixup_virtex_pci_bridge);  
+
+void virtex_pci_init(void)
+{
+   struct device_node *pci_node = of_find_compatible_node(NULL, NULL,
xlnx,plbv46-pci-1.03.a);
+
+   if(pci_node)
+   {
+   struct pci_controller *hose;
+   struct resource r;
+   void __iomem *pci_reg;
+
+   printk(Found a Xilinx plb-pci host bridge\n);
+
+   if(of_address_to_resource(pci_node, 0, r))
+   {
+   printk(No address for Xilinx plb-pci host bridge\n);
+   return;
+   }
+
+   hose = pcibios_alloc_controller(pci_node);
+   if (!hose)
+   return;
+
+   hose-first_busno = 0;
+   hose-last_busno = 0;
+  
+   /* Setup config space */
+   setup_indirect_pci(hose, r.start + XPLB_PCI_ADDR, r.start +
XPLB_PCI_DATA, PPC_INDIRECT_TYPE_SET_CFG_TYPE);
+
+   /* According to the xilinx plbv46_pci documentation the 
soft-core
starts a self-init when the bus master enable bit is set.
+* Without this bit set the pci bus can't be scanned. */
+   early_write_config_word(hose, 0, 0, PCI_COMMAND,
PCI_HOST_ENABLE_CMD);
+
+   /* Set the max latency timer to 255 */
+   early_write_config_byte(hose, 0, 0, PCI_LATENCY_TIMER, 0xff);
+
+   /* Set the max bus number to 255 */
+   pci_reg = of_iomap(pci_node, 0);
+   out_8(pci_reg + XPLB_PCI_BUS, 0xff);
+   iounmap(pci_reg);
+
+   /* Register the host bridge with the linux kernel

Patch 2/2: Add Xilinx ML510 reference design support

2009-04-14 Thread Roderick Colenbrander
From f46fa90e4d066767cc4fc1c5b8dc2f9ee013ea0a Mon Sep 17 00:00:00 2001
From: Roderick Colenbrander thunderbir...@gmail.com
Date: Tue, 14 Apr 2009 15:49:32 +0200
Subject: [PATCH] Add Xilinx ML510 reference design support.

---
 arch/powerpc/boot/dts/virtex440-ml510.dts |  453 +
 arch/powerpc/platforms/44x/Kconfig|   10 +
 arch/powerpc/platforms/44x/Makefile   |1 +
 arch/powerpc/platforms/44x/ml510.c|  161 ++
 4 files changed, 625 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/virtex440-ml510.dts
 create mode 100644 arch/powerpc/platforms/44x/ml510.c

diff --git a/arch/powerpc/boot/dts/virtex440-ml510.dts 
b/arch/powerpc/boot/dts/virtex440-ml510.dts
new file mode 100644
index 000..7ded73c
--- /dev/null
+++ b/arch/powerpc/boot/dts/virtex440-ml510.dts
@@ -0,0 +1,453 @@
+/*
+ * Xilinx ML510 Reference Design support
+ * This DTS file was created for the ml510_bsb1_pcores_ppc440 reference design.
+ * The reference design contains a bug which prevent PCI DMA from working 
properly.
+ * A description of the bug is given in the plbv46_pci section. It needs to be 
fixed
+ * by the user until Xilinx updates their reference design.
+ *
+ * Copyright 2009, Roderick Colenbrander
+ */
+
+/dts-v1/;
+/ {
+   #address-cells = 1;
+   #size-cells = 1;
+   compatible = xlnx,ml510-ref-design;
+   dcr-parent = ppc440_0;
+   model = testing;
+   DDR2_SDRAM_DIMM0: mem...@0 {
+   device_type = memory;
+   reg =  0x0 0x2000 ;
+   } ;
+   alias {
+   ethernet0 = Hard_Ethernet_MAC;
+   serial0 = RS232_Uart_1;
+   } ;
+   chosen {
+bootargs = console=ttyS0 root=/dev/xsa2 init=/etc/preinit;
+//bootargs = console=ttyS0 root=/dev/ram;
+linux,stdout-path = /p...@0/ser...@83e0;
+   } ;
+   cpus {
+   #address-cells = 1;
+   #cpus = 0x1;
+   #size-cells = 0;
+   ppc440_0: c...@0 {
+   #address-cells = 1;
+   #size-cells = 1;
+   clock-frequency = 3;
+   compatible = PowerPC,440, ibm,ppc440;
+   d-cache-line-size = 0x20;
+   d-cache-size = 0x8000;
+   dcr-access-method = native;
+   dcr-controller ;
+   device_type = cpu;
+   i-cache-line-size = 0x20;
+   i-cache-size = 0x8000;
+   model = PowerPC,440;
+   reg = 0;
+   timebase-frequency = 3;
+   xlnx,apu-control = 0x2000;
+   xlnx,apu-udi-0 = 0x0;
+   xlnx,apu-udi-1 = 0x0;
+   xlnx,apu-udi-10 = 0x0;
+   xlnx,apu-udi-11 = 0x0;
+   xlnx,apu-udi-12 = 0x0;
+   xlnx,apu-udi-13 = 0x0;
+   xlnx,apu-udi-14 = 0x0;
+   xlnx,apu-udi-15 = 0x0;
+   xlnx,apu-udi-2 = 0x0;
+   xlnx,apu-udi-3 = 0x0;
+   xlnx,apu-udi-4 = 0x0;
+   xlnx,apu-udi-5 = 0x0;
+   xlnx,apu-udi-6 = 0x0;
+   xlnx,apu-udi-7 = 0x0;
+   xlnx,apu-udi-8 = 0x0;
+   xlnx,apu-udi-9 = 0x0;
+   xlnx,dcr-autolock-enable = 0x1;
+   xlnx,dcu-rd-ld-cache-plb-prio = 0x0;
+   xlnx,dcu-rd-noncache-plb-prio = 0x0;
+   xlnx,dcu-rd-touch-plb-prio = 0x0;
+   xlnx,dcu-rd-urgent-plb-prio = 0x0;
+   xlnx,dcu-wr-flush-plb-prio = 0x0;
+   xlnx,dcu-wr-store-plb-prio = 0x0;
+   xlnx,dcu-wr-urgent-plb-prio = 0x0;
+   xlnx,dma0-control = 0x0;
+   xlnx,dma0-plb-prio = 0x0;
+   xlnx,dma0-rxchannelctrl = 0x101;
+   xlnx,dma0-rxirqtimer = 0x3ff;
+   xlnx,dma0-txchannelctrl = 0x101;
+   xlnx,dma0-txirqtimer = 0x3ff;
+   xlnx,dma1-control = 0x0;
+   xlnx,dma1-plb-prio = 0x0;
+   xlnx,dma1-rxchannelctrl = 0x101;
+   xlnx,dma1-rxirqtimer = 0x3ff;
+   xlnx,dma1-txchannelctrl = 0x101;
+   xlnx,dma1-txirqtimer = 0x3ff;
+   xlnx,dma2-control = 0x0;
+   xlnx,dma2-plb-prio = 0x0;
+   xlnx,dma2-rxchannelctrl = 0x101;
+   xlnx,dma2-rxirqtimer = 0x3ff;
+   xlnx,dma2-txchannelctrl = 0x101;
+   xlnx,dma2-txirqtimer = 0x3ff

Re: [PATCH] Xilinx : Framebuffer Driver: Add PLB support (non-DCR)

2009-04-09 Thread Roderick Colenbrander
On Thu, Apr 9, 2009 at 2:46 PM, Josh Boyer jwbo...@linux.vnet.ibm.comwrote:

 On Wed, Apr 08, 2009 at 03:11:25PM -0600, John Linn wrote:
 From: Suneel [mailto:suneel.garap...@xilinx.com]
 
 Added support for the new xps tft controller.
 
 The new core has PLB interface support in addition to existing
 DCR interface.
 
 The driver has been modified to support this new core which
 can be connected on PLB or DCR bus.
 
 Signed-off-by: Suneel sune...@xilinx.com
 Signed-off-by: John Linn john.l...@xilinx.com
 ---
  drivers/video/xilinxfb.c |  227
 --
  1 files changed, 160 insertions(+), 67 deletions(-)
 
 diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
 index a82c530..a28a834 100644
 --- a/drivers/video/xilinxfb.c
 +++ b/drivers/video/xilinxfb.c
 @@ -1,17 +1,24 @@
  /*
 - * xilinxfb.c
   *
 - * Xilinx TFT LCD frame buffer driver
 + * Xilinx TFT frame buffer driver
   *
   * Author: MontaVista Software, Inc.
   * sou...@mvista.com
   *
   * 2002-2007 (c) MontaVista Software, Inc.
   * 2007 (c) Secret Lab Technologies, Ltd.
 + * 2009 (c) Xilinx Inc.
   *
 - * This file is licensed under the terms of the GNU General Public
 License
 - * version 2.  This program is licensed as is without any warranty of
 any
 - * kind, whether express or implied.
 + * This program is free software; you can redistribute it
 + * and/or modify it under the terms of the GNU General Public
 + * License as published by the Free Software Foundation;
 + * either version 2 of the License, or (at your option) any
 + * later version.
 + *
 + * You should have received a copy of the GNU General Public
 + * License along with this program; if not, write to the Free
 + * Software Foundation, Inc., 675 Mass Ave, Cambridge, MA
 + * 02139, USA.
   */

 What Stephen said.

  #define NUM_REGS  2
  #define REG_FB_ADDR   0
 @@ -112,6 +123,11 @@ struct xilinxfb_drvdata {
 
struct fb_info  info;   /* FB driver info record */
 
 +  u32 regs_phys;  /* phys. address of the control
 +  registers */

 Is this driver usable on the 440 based Xilinx devices?  If so, is it
 possible
 to have the physical address of the registers above 4GiB, so is common with
 almost all the I/O on the other 440 boards?


The driver works fine on 440 based Xilinx boards (the ML510 I use has a 440
core). It might be nice to move physical addresses above 4GB for devices but
in all Xilinx tools and reference designs addresses below 4GB are used for
periperhals and I think even below 2GB (or even below 1GB). It depends on
the design.

Roderick Colenbrander
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RFC ML510 Linux support

2009-04-01 Thread Roderick Colenbrander
Hi,

This is a draft version of my patch to add Linux support for the Xilinx ML510. 
The patch adds support for the board and a pci implementation which allows you 
to use onboard pci devices (usb, ide, audio) and pci slots (only slot 3 and 5 
for now).

This is an intial version of my work. There is some ide hack in which I need to 
submit to the ide list and I guess that I need to make my pci driver OF aware.

Regards,
Roderick Colenbrander
-- 
Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss 
für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
diff -urN -X linux-2.6.29/Documentation/dontdiff linux-2.6.29/arch/powerpc/boot/dts/virtex440-ml510.dts ml510-dev/linux-2.6.29/arch/powerpc/boot/dts/virtex440-ml510.dts
--- linux-2.6.29/arch/powerpc/boot/dts/virtex440-ml510.dts	1970-01-01 01:00:00.0 +0100
+++ ml510-dev/linux-2.6.29/arch/powerpc/boot/dts/virtex440-ml510.dts	2009-04-01 13:18:50.0 +0200
@@ -0,0 +1,452 @@
+/*
+ * Xilinx ML510 Reference Design support
+ * This DTS file was created for the ml510_bsb1_pcores_ppc440 reference design.
+ * The reference design contains two bugs which prevent PCI from working which
+ * should be fixed by the user:
+ * - the MPLB output of the soft-core should be connected to plbv46_plb_1 which
+ *   corresponds to SPLB0 of the ppc440 to allow the soft-core to access system
+ *   memory
+ * - C_IPIFBAR2PCIBAR_0 of the soft-core should be set to 0x8000 in order to
+ *   reserve 0x8000-0x (PCI) for memory mapped i/o and the lower addresses
+ *   can be used by PCI devices to access system memory (DMA).
+ *
+ * Copyright 2009, Roderick Colenbrander
+ */
+
+/dts-v1/;
+/ {
+	#address-cells = 1;
+	#size-cells = 1;
+	compatible = xlnx,ml510-ref-design;
+	dcr-parent = ppc440_0;
+	model = testing;
+	DDR2_SDRAM_DIMM0: mem...@0 {
+		device_type = memory;
+		reg =  0x0 0x2000 ;
+	} ;
+	chosen {
+		bootargs = console=ttyS0 root=/dev/xsa2 init=/etc/preinit;
+		linux,stdout-path = /p...@0/ser...@83e0;
+	} ;
+	cpus {
+		#address-cells = 1;
+		#cpus = 0x1;
+		#size-cells = 0;
+		ppc440_0: c...@0 {
+			#address-cells = 1;
+			#size-cells = 1;
+			clock-frequency = 3;
+			compatible = PowerPC,440, ibm,ppc440;
+			d-cache-line-size = 0x20;
+			d-cache-size = 0x8000;
+			dcr-access-method = native;
+			dcr-controller ;
+			device_type = cpu;
+			i-cache-line-size = 0x20;
+			i-cache-size = 0x8000;
+			model = PowerPC,440;
+			reg = 0;
+			timebase-frequency = 3;
+			xlnx,apu-control = 0x2000;
+			xlnx,apu-udi-0 = 0x0;
+			xlnx,apu-udi-1 = 0x0;
+			xlnx,apu-udi-10 = 0x0;
+			xlnx,apu-udi-11 = 0x0;
+			xlnx,apu-udi-12 = 0x0;
+			xlnx,apu-udi-13 = 0x0;
+			xlnx,apu-udi-14 = 0x0;
+			xlnx,apu-udi-15 = 0x0;
+			xlnx,apu-udi-2 = 0x0;
+			xlnx,apu-udi-3 = 0x0;
+			xlnx,apu-udi-4 = 0x0;
+			xlnx,apu-udi-5 = 0x0;
+			xlnx,apu-udi-6 = 0x0;
+			xlnx,apu-udi-7 = 0x0;
+			xlnx,apu-udi-8 = 0x0;
+			xlnx,apu-udi-9 = 0x0;
+			xlnx,dcr-autolock-enable = 0x1;
+			xlnx,dcu-rd-ld-cache-plb-prio = 0x0;
+			xlnx,dcu-rd-noncache-plb-prio = 0x0;
+			xlnx,dcu-rd-touch-plb-prio = 0x0;
+			xlnx,dcu-rd-urgent-plb-prio = 0x0;
+			xlnx,dcu-wr-flush-plb-prio = 0x0;
+			xlnx,dcu-wr-store-plb-prio = 0x0;
+			xlnx,dcu-wr-urgent-plb-prio = 0x0;
+			xlnx,dma0-control = 0x0;
+			xlnx,dma0-plb-prio = 0x0;
+			xlnx,dma0-rxchannelctrl = 0x101;
+			xlnx,dma0-rxirqtimer = 0x3ff;
+			xlnx,dma0-txchannelctrl = 0x101;
+			xlnx,dma0-txirqtimer = 0x3ff;
+			xlnx,dma1-control = 0x0;
+			xlnx,dma1-plb-prio = 0x0;
+			xlnx,dma1-rxchannelctrl = 0x101;
+			xlnx,dma1-rxirqtimer = 0x3ff;
+			xlnx,dma1-txchannelctrl = 0x101;
+			xlnx,dma1-txirqtimer = 0x3ff;
+			xlnx,dma2-control = 0x0;
+			xlnx,dma2-plb-prio = 0x0;
+			xlnx,dma2-rxchannelctrl = 0x101;
+			xlnx,dma2-rxirqtimer = 0x3ff;
+			xlnx,dma2-txchannelctrl = 0x101;
+			xlnx,dma2-txirqtimer = 0x3ff;
+			xlnx,dma3-control = 0x0;
+			xlnx,dma3-plb-prio = 0x0;
+			xlnx,dma3-rxchannelctrl = 0x101;
+			xlnx,dma3-rxirqtimer = 0x3ff;
+			xlnx,dma3-txchannelctrl = 0x101;
+			xlnx,dma3-txirqtimer = 0x3ff;
+			xlnx,endian-reset = 0x0;
+			xlnx,generate-plb-timespecs = 0x1;
+			xlnx,icu-rd-fetch-plb-prio = 0x0;
+			xlnx,icu-rd-spec-plb-prio = 0x0;
+			xlnx,icu-rd-touch-plb-prio = 0x0;
+			xlnx,interconnect-imask = 0x;
+			xlnx,mplb-allow-lock-xfer = 0x1;
+			xlnx,mplb-arb-mode = 0x0;
+			xlnx,mplb-awidth = 0x20;
+			xlnx,mplb-counter = 0x500;
+			xlnx,mplb-dwidth = 0x80;
+			xlnx,mplb-max-burst = 0x8;
+			xlnx,mplb-native-dwidth = 0x80;
+			xlnx,mplb-p2p = 0x0;
+			xlnx,mplb-prio-dcur = 0x2;
+			xlnx,mplb-prio-dcuw = 0x3;
+			xlnx,mplb-prio-icu = 0x4;
+			xlnx,mplb-prio-splb0 = 0x1;
+			xlnx,mplb-prio-splb1 = 0x0;
+			xlnx,mplb-read-pipe-enable = 0x1;
+			xlnx,mplb-sync-tattribute = 0x0;
+			xlnx,mplb-wdog-enable = 0x1;
+			xlnx,mplb-write-pipe-enable = 0x1;
+			xlnx,mplb-write-post-enable = 0x1;
+			xlnx,num-dma = 0x0;
+			xlnx,pir = 0xf;
+			xlnx,ppc440mc-addr

Draft version of ML510 Linux patch (patch inlined)

2009-04-01 Thread Roderick Colenbrander
Hi,

As requested by Grant Likely here the same patch but now inlined.

Regards,
Roderick Colenbrander


diff -urN -X linux-2.6.29/Documentation/dontdiff
linux-2.6.29/arch/powerpc/boot/dts/virtex440-ml510.dts
ml510-dev/linux-2.6.29/arch/powerpc/boot/dts/virtex440-ml510.dts
--- linux-2.6.29/arch/powerpc/boot/dts/virtex440-ml510.dts  1970-01-01
01:00:00.0 +0100
+++ ml510-dev/linux-2.6.29/arch/powerpc/boot/dts/virtex440-ml510.dts
2009-04-01 13:18:50.0 +0200
@@ -0,0 +1,452 @@
+/*
+ * Xilinx ML510 Reference Design support
+ * This DTS file was created for the ml510_bsb1_pcores_ppc440 reference
design.
+ * The reference design contains two bugs which prevent PCI from
working which
+ * should be fixed by the user:
+ * - the MPLB output of the soft-core should be connected to
plbv46_plb_1 which
+ *   corresponds to SPLB0 of the ppc440 to allow the soft-core to
access system
+ *   memory
+ * - C_IPIFBAR2PCIBAR_0 of the soft-core should be set to 0x8000 in
order to
+ *   reserve 0x8000-0x (PCI) for memory mapped i/o and the
lower addresses
+ *   can be used by PCI devices to access system memory (DMA).
+ *
+ * Copyright 2009, Roderick Colenbrander
+ */
+
+/dts-v1/;
+/ {
+   #address-cells = 1;
+   #size-cells = 1;
+   compatible = xlnx,ml510-ref-design;
+   dcr-parent = ppc440_0;
+   model = testing;
+   DDR2_SDRAM_DIMM0: mem...@0 {
+   device_type = memory;
+   reg =  0x0 0x2000 ;
+   } ;
+   chosen {
+   bootargs = console=ttyS0 root=/dev/xsa2 init=/etc/preinit;
+   linux,stdout-path = /p...@0/ser...@83e0;
+   } ;
+   cpus {
+   #address-cells = 1;
+   #cpus = 0x1;
+   #size-cells = 0;
+   ppc440_0: c...@0 {
+   #address-cells = 1;
+   #size-cells = 1;
+   clock-frequency = 3;
+   compatible = PowerPC,440, ibm,ppc440;
+   d-cache-line-size = 0x20;
+   d-cache-size = 0x8000;
+   dcr-access-method = native;
+   dcr-controller ;
+   device_type = cpu;
+   i-cache-line-size = 0x20;
+   i-cache-size = 0x8000;
+   model = PowerPC,440;
+   reg = 0;
+   timebase-frequency = 3;
+   xlnx,apu-control = 0x2000;
+   xlnx,apu-udi-0 = 0x0;
+   xlnx,apu-udi-1 = 0x0;
+   xlnx,apu-udi-10 = 0x0;
+   xlnx,apu-udi-11 = 0x0;
+   xlnx,apu-udi-12 = 0x0;
+   xlnx,apu-udi-13 = 0x0;
+   xlnx,apu-udi-14 = 0x0;
+   xlnx,apu-udi-15 = 0x0;
+   xlnx,apu-udi-2 = 0x0;
+   xlnx,apu-udi-3 = 0x0;
+   xlnx,apu-udi-4 = 0x0;
+   xlnx,apu-udi-5 = 0x0;
+   xlnx,apu-udi-6 = 0x0;
+   xlnx,apu-udi-7 = 0x0;
+   xlnx,apu-udi-8 = 0x0;
+   xlnx,apu-udi-9 = 0x0;
+   xlnx,dcr-autolock-enable = 0x1;
+   xlnx,dcu-rd-ld-cache-plb-prio = 0x0;
+   xlnx,dcu-rd-noncache-plb-prio = 0x0;
+   xlnx,dcu-rd-touch-plb-prio = 0x0;
+   xlnx,dcu-rd-urgent-plb-prio = 0x0;
+   xlnx,dcu-wr-flush-plb-prio = 0x0;
+   xlnx,dcu-wr-store-plb-prio = 0x0;
+   xlnx,dcu-wr-urgent-plb-prio = 0x0;
+   xlnx,dma0-control = 0x0;
+   xlnx,dma0-plb-prio = 0x0;
+   xlnx,dma0-rxchannelctrl = 0x101;
+   xlnx,dma0-rxirqtimer = 0x3ff;
+   xlnx,dma0-txchannelctrl = 0x101;
+   xlnx,dma0-txirqtimer = 0x3ff;
+   xlnx,dma1-control = 0x0;
+   xlnx,dma1-plb-prio = 0x0;
+   xlnx,dma1-rxchannelctrl = 0x101;
+   xlnx,dma1-rxirqtimer = 0x3ff;
+   xlnx,dma1-txchannelctrl = 0x101;
+   xlnx,dma1-txirqtimer = 0x3ff;
+   xlnx,dma2-control = 0x0;
+   xlnx,dma2-plb-prio = 0x0;
+   xlnx,dma2-rxchannelctrl = 0x101;
+   xlnx,dma2-rxirqtimer = 0x3ff;
+   xlnx,dma2-txchannelctrl = 0x101;
+   xlnx,dma2-txirqtimer = 0x3ff;
+   xlnx,dma3-control = 0x0;
+   xlnx,dma3-plb-prio = 0x0;
+   xlnx,dma3-rxchannelctrl = 0x101;
+   xlnx,dma3-rxirqtimer = 0x3ff;
+   xlnx,dma3-txchannelctrl = 0x101

Re: DTS file PCI / i8259 for Xilinx ML510

2009-03-16 Thread Roderick Colenbrander

 Original-Nachricht 
 Datum: Sun, 15 Mar 2009 11:43:13 +0100
 Von: Gerhard Pircher gerhard_pirc...@gmx.net
 An: Roderick Colenbrander thunderbir...@gmx.net, linuxppc-dev@ozlabs.org
 Betreff: Re: DTS file PCI / i8259 for Xilinx ML510

 
  Original-Nachricht 
  Datum: Sun, 15 Mar 2009 09:38:26 +0100
  Von: Roderick Colenbrander thunderbir...@gmx.net
  An: Gerhard Pircher gerhard_pirc...@gmx.net, linuxppc-dev@ozlabs.org
  Betreff: Re: DTS file PCI / i8259 for Xilinx ML510
 
At some point in the file they create some (dummy?) pcie section in
which they define a uli1575, an isa bus and attached to that isa bus
a i8259. Is this the correct way of doing things? The i8259 driver
seems to use io ports 0x20-21/0xa0-0xa1/0x4d0-0x4d1 those are also
defined below but how are those mapped to the south bridge? I have
seen some code in kernel/isa-bridge, is that code indeed responsible
for setting up these ports?
   Yes, the pcie node is the PCI host bridge node and the uli1571 node
   acts as PCI2ISA bridge node. AFAIK their ranges properties are parsed
   by pci_process_bridge_OF_ranges().
   IIRC the code in kernel/isa-bridge is used for 64bit PPC machines only
   for now. The I/O addresses for the i8259 PIC are currently hardcoded
   and setup (request_resource()) in sysdev/i8259.c.
  
  I got the i8259 south bridge working now after adding an io_base_virt
  offset to all inb/outb lines in sysdev/i8259.c. Would it be worth all
  the troubles to add ppc32 support to isa-bridge.c? The whole point of
  the code is basically to remap the io memory to low addresses for these
  64-bit ppc systems (mainly freescale boards with a i8259 and pseries
  systems with a i8259).
 pci_process_bridge_OF_ranges() should ioremap io_base_virt for you,
 if your board has only one PCI I/O space. It also sets isa_io_base to
 io_base_virt on PPC32, but expects that the ISA I/O space is mapped to
 PCI I/O address 0x0. Isn't that the case for your board?
 
  As far as I have seen it is only needed for i8259 interrupt controllers.
  Personally I think it would be better to pass a io base offset to
  i8259_setup or so. Or perhaps do some dts file parsing in i8259.c.
  I'm not sure what the proper layout would be for this in the dts file
  though.
 I think adding an io base offset parameter to i8259_setup isn't the
 right way to do it. I would expect other problems too, if ISA I/O space
 isn't mapped 1:1 to PCI I/O space on a PPC32 system. Maybe a more
 experienced kernel developer can comment on this?

I'm now back behind my ML510 board and have been doing some tests. As I 
mentioned before I was doing inb(isa_io_base + port) / outb(val, isa_io_base + 
port) which worked fine. As far as I see it the problem is the definition of 
inb/outb on ppc32 they don't take isa_io_base into account. They are:
__do_in_asm(_rec_inb, lbzx)
__do_out_asm(_rec_outb, stbx)
#define __do_outb(val, port)_rec_outb(val, port)
#define __do_inb(port)  _rec_inb(port)

While on 64-bit ppc they are:
#define __do_outb(val, port)writeb(val,(PCI_IO_ADDR)_IO_BASE+port);
#define __do_inb(port)  readb((PCI_IO_ADDR)_IO_BASE + port);

(On ppc32 _IO_BASE is isa_io_base but on 64-bit it is set to pci_io_base)

Am I correct that inb/outb are broken on ppc32? If so what is the right way to 
fix them?

Regards,
Roderick
-- 
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger01
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: DTS file PCI / i8259 for Xilinx ML510

2009-03-16 Thread Roderick Colenbrander

 Original-Nachricht 
 Datum: Mon, 16 Mar 2009 09:18:54 +0100
 Von: Roderick Colenbrander thunderbir...@gmx.net
 An: Gerhard Pircher gerhard_pirc...@gmx.net, linuxppc-dev@ozlabs.org
 Betreff: Re: DTS file PCI / i8259 for Xilinx ML510

 
  Original-Nachricht 
  Datum: Sun, 15 Mar 2009 11:43:13 +0100
  Von: Gerhard Pircher gerhard_pirc...@gmx.net
  An: Roderick Colenbrander thunderbir...@gmx.net,
 linuxppc-dev@ozlabs.org
  Betreff: Re: DTS file PCI / i8259 for Xilinx ML510
 
  
   Original-Nachricht 
   Datum: Sun, 15 Mar 2009 09:38:26 +0100
   Von: Roderick Colenbrander thunderbir...@gmx.net
   An: Gerhard Pircher gerhard_pirc...@gmx.net,
 linuxppc-dev@ozlabs.org
   Betreff: Re: DTS file PCI / i8259 for Xilinx ML510
  
 At some point in the file they create some (dummy?) pcie section
 in
 which they define a uli1575, an isa bus and attached to that isa
 bus
 a i8259. Is this the correct way of doing things? The i8259 driver
 seems to use io ports 0x20-21/0xa0-0xa1/0x4d0-0x4d1 those are also
 defined below but how are those mapped to the south bridge? I have
 seen some code in kernel/isa-bridge, is that code indeed
 responsible
 for setting up these ports?
Yes, the pcie node is the PCI host bridge node and the uli1571 node
acts as PCI2ISA bridge node. AFAIK their ranges properties are
 parsed
by pci_process_bridge_OF_ranges().
IIRC the code in kernel/isa-bridge is used for 64bit PPC machines
 only
for now. The I/O addresses for the i8259 PIC are currently hardcoded
and setup (request_resource()) in sysdev/i8259.c.
   
   I got the i8259 south bridge working now after adding an io_base_virt
   offset to all inb/outb lines in sysdev/i8259.c. Would it be worth all
   the troubles to add ppc32 support to isa-bridge.c? The whole point of
   the code is basically to remap the io memory to low addresses for
 these
   64-bit ppc systems (mainly freescale boards with a i8259 and pseries
   systems with a i8259).
  pci_process_bridge_OF_ranges() should ioremap io_base_virt for you,
  if your board has only one PCI I/O space. It also sets isa_io_base to
  io_base_virt on PPC32, but expects that the ISA I/O space is mapped to
  PCI I/O address 0x0. Isn't that the case for your board?
  
   As far as I have seen it is only needed for i8259 interrupt
 controllers.
   Personally I think it would be better to pass a io base offset to
   i8259_setup or so. Or perhaps do some dts file parsing in i8259.c.
   I'm not sure what the proper layout would be for this in the dts file
   though.
  I think adding an io base offset parameter to i8259_setup isn't the
  right way to do it. I would expect other problems too, if ISA I/O space
  isn't mapped 1:1 to PCI I/O space on a PPC32 system. Maybe a more
  experienced kernel developer can comment on this?
 
 I'm now back behind my ML510 board and have been doing some tests. As I
 mentioned before I was doing inb(isa_io_base + port) / outb(val, isa_io_base
 + port) which worked fine. As far as I see it the problem is the definition
 of inb/outb on ppc32 they don't take isa_io_base into account. They are:
 __do_in_asm(_rec_inb, lbzx)
 __do_out_asm(_rec_outb, stbx)
 #define __do_outb(val, port)_rec_outb(val, port)
 #define __do_inb(port)  _rec_inb(port)
 
 While on 64-bit ppc they are:
 #define __do_outb(val, port)writeb(val,(PCI_IO_ADDR)_IO_BASE+port);
 #define __do_inb(port)  readb((PCI_IO_ADDR)_IO_BASE + port);
 
 (On ppc32 _IO_BASE is isa_io_base but on 64-bit it is set to pci_io_base)
 
 Am I correct that inb/outb are broken on ppc32? If so what is the right
 way to fix them?
 
 Regards,
 Roderick

I just talked about this on IRC with Benjamin Herrenschmidt and I misunderstood 
the inb/outb command. the commands are using _IO_PORTS and I must be doing 
something wrong.

Roderick
-- 
Nur bis 16.03.! DSL-Komplettanschluss inkl. WLAN-Modem für nur 
17,95 ¿/mtl. + 1 Monat gratis!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: DTS file PCI / i8259 for Xilinx ML510

2009-03-15 Thread Roderick Colenbrander

  At some point in the file they create some (dummy?) pcie section in
  which they define a uli1575, an isa bus and attached to that isa bus a
  i8259. Is this the correct way of doing things? The i8259 driver seems
  to use io ports 0x20-21/0xa0-0xa1/0x4d0-0x4d1 those are also defined
  below but how are those mapped to the south bridge? I have seen some
  code in kernel/isa-bridge, is that code indeed responsible for setting
  up these ports?
 Yes, the pcie node is the PCI host bridge node and the uli1571 node acts
 as PCI2ISA bridge node. AFAIK their ranges properties are parsed by
 pci_process_bridge_OF_ranges().
 IIRC the code in kernel/isa-bridge is used for 64bit PPC machines only
 for now. The I/O addresses for the i8259 PIC are currently hardcoded and
 setup (request_resource()) in sysdev/i8259.c.

I got the i8259 south bridge working now after adding an io_base_virt offset to 
all inb/outb lines in sysdev/i8259.c. Would it be worth all the troubles to add 
ppc32 support to isa-bridge.c? The whole point of the code is basically to 
remap the io memory to low addresses for these 64-bit ppc systems (mainly 
freescale boards with a i8259 and pseries systems with a i8259). As far as I 
have seen it is only needed for i8259 interrupt controllers. Personally I think 
it would be better to pass a io base offset to i8259_setup or so. Or perhaps do 
some dts file parsing in i8259.c. I'm not sure what the proper layout would be 
for this in the dts file though.

With those changes I mentioned to i8259.c I got some PCI devices of my ali 
m1553 south bridge working. The code is ugly and I need to do cleanups. When it 
is done I will submit some patches.

Regards,
Roderick Colenbrander
-- 
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger01
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: DTS file PCI / i8259 for Xilinx ML510

2009-03-15 Thread Roderick Colenbrander
  I got the i8259 south bridge working now after adding an io_base_virt
  offset to all inb/outb lines in sysdev/i8259.c. Would it be worth all
  the troubles to add ppc32 support to isa-bridge.c? The whole point of
  the code is basically to remap the io memory to low addresses for these
  64-bit ppc systems (mainly freescale boards with a i8259 and pseries
  systems with a i8259).
 pci_process_bridge_OF_ranges() should ioremap io_base_virt for you,
 if your board has only one PCI I/O space. It also sets isa_io_base to
 io_base_virt on PPC32, but expects that the ISA I/O space is mapped to
 PCI I/O address 0x0. Isn't that the case for your board?
 

Ah then perhaps that is my problem. I'm using my own pci implementation for 
Xilinx their plbv46 soft core. The soft core might be compatible with a generic 
ibm plb-pci bridge (sysdev/ppc44x_pci.c). Basically I'm doing something like 
which is done in powermac/pci.c e.g. creating the pci_controller and filling it 
with cfg_addr / cfg_data pointers, io ranges, resource ranges and so on. The 
data is obtained from the dts file but from some xilinx generated fields and 
doesn't have the generic ranges fields and some others. I guess it is time to 
fix this part of the DTS file.

Some other issue I had which might be related to my DTS file bugs is some i/o 
port conflict. The M1553 south bridge is just a peripheral on the ML510 primary 
pci bus there are no PCI slots connected to it. There are four other pci slots 
of which two are directly connected to the fpga (they are on the same bus as 
the M1553) and two are connected using a pci-to-pci bridge because they use 5V 
instead of 3.3V. The bridge chip wanted 0x0-0xfff while some south bridge 
devices wanted low addresses (if I remember correctly the IDE controller wants 
0x1f0-0x1f1 and some 0x3** ports). This generated some Cannot allocate 
resource region .. will remap messages from kernel/pci-common.c. This 
remapping didn't happen. Should a proper DTS file prevent this issue? If not 
where is the remapping done (I didn't see it). For that reason I'm ignoring the 
pci-to-pci bridge for now.

Thanks,
Roderick Colenbrander
-- 
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger01
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


DTS file PCI / i8259 for Xilinx ML510

2009-03-12 Thread Roderick Colenbrander
;
#address-cells = 0;
#interrupt-cells = 2;
compatible = chrp,iic;
interrupts = 9 2;
interrupt-parent = mpic;
};
};
};
};

Thanks,
Roderick Colenbrander


-- 
Nur bis 16.03.! DSL-Komplettanschluss inkl. WLAN-Modem für nur 
17,95 ¿/mtl. + 1 Monat gratis!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


DTS file PCI / i8259 for Xilinx ML510

2009-03-12 Thread Roderick Colenbrander
;
#address-cells = 0;
#interrupt-cells = 2;
compatible = chrp,iic;
interrupts = 9 2;
interrupt-parent = mpic;
};
};
};
};

Thanks,
Roderick Colenbrander
-- 
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger01
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev