LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [RFC][PATCH] MPC832x_RDB: update dts to use spi, register mmc_spi stub
From: Segher Boessenkool @ 2007-08-06 22:08 UTC (permalink / raw)
  To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <20070806163137.136cc689.kim.phillips@freescale.com>

>>>>>>> +				max-speed-hz = <bebc20>; /* 12500000 Hz */
>>>>
>>>> Just max-speed.
>>>
>>> Segher, how is this different from:
>>>
>>> http://ozlabs.org/pipermail/linuxppc-dev/2007-April/034557.html
>>
>> Not sure what you mean.  I'm just saying that "speed-hz" is a
>> terrible name, I'm not saying that "max-speed" is perfect at all.
>
> yet you suggest a /more/ generic name, contrary to your prior comments.

Uh, you mean "hz" doesn't mean "Hertz"?  What a great name,
then</sarcasm>.

> My interpretation of your recent comments is that 'max-speed' is now a
> valid property name for devices such as ucc_geth.  Do I have that 
> right?

It is (and always was) a _valid_ name.  Whether it is a _good_
name depends on the context; if there is only one speed it can
be (reasonably) referring to, it is okay; if not (or even if so),
you're better off being a bit more verbose in your property names.
No need to go over the top though, it's all a tradeoff.


Segher

^ permalink raw reply

* Re: [PATCH] mark PCI resource with start 0 as unassigned
From: Benjamin Herrenschmidt @ 2007-08-06 22:14 UTC (permalink / raw)
  To: Segher Boessenkool; +Cc: linuxppc-dev, Olaf Hering, Alan Cox, linux-ide
In-Reply-To: <04ce93c63dfaa543b4068d448c8115d8@kernel.crashing.org>

On Mon, 2007-08-06 at 20:04 +0200, Segher Boessenkool wrote:
> That's of course the smarter choice, _if_ we have a choice at
> all -- on PowerPC, the PCI setup on certain platforms is done
> by the firmware (and we don't want to mess with it for various
> reasons), and some _do_ map PCI legacy I/O at 0.
> 
> Not in this case though, so let's just ignore that possibility
> until it hits us in the face :-) 

Agreed. We can always try to remap just that device if it becomes an
issue.

Ben.

^ permalink raw reply

* Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
From: Benjamin Herrenschmidt @ 2007-08-06 22:15 UTC (permalink / raw)
  To: Sergei Shtylyov; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <46B76A5A.3030300@ru.mvista.com>

On Mon, 2007-08-06 at 22:37 +0400, Sergei Shtylyov wrote:
> 
>     Actually, checking for the presence of all possible perverted
> mapping 
> props doesn't seem a good idea -- it's simpler to check for the
> presence of 
> one prop (like "direct-mapped" I was thinking about, or maybe
> "simple-map").

Or more simply... if it's not a direct mapping, it doesn't have a ranges
property and can't be walked down by conventional means.

Ben.

^ permalink raw reply

* Re: [PATCH 2.6.22.y] ieee1394: revert "sbp2: enforce 32bit DMA mapping"
From: Stefan Richter @ 2007-08-06 22:22 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: Robert Hancock, linuxppc-dev, stable, linux-kernel, Olaf Hering
In-Reply-To: <1186436848.938.75.camel@localhost.localdomain>

Benjamin Herrenschmidt wrote:
> Oh and, don't do the set_dma_mask() in sbp2, it has nothing to do there.
> It should be in the ohci1394 driver.

That's not quite right.  OHCI-1394 implementations can go beyond 4GB bus
address space.  (Although I don't know if there are such implementations
available.  At least there are two implementations which can set the
so-called Physical Range bigger than 4GB.)

Sbp2 however requires that everything which it DMA-maps resides in the
Physical Range of the controller.  This way the CPU is not involved in
most of the data transfers.  The OHCI-1394 controller acts as bus bridge
between IEEE 1394 bus and local bus, with a 1:1 mapping of IEEE 1394 bus
addresses to and from local bus addresses --- but not in the whole 48
bits white IEEE 1394 bus address range, only in the
implementation-dependent Physical Range.  The minimum Physical Range
that all OHCI-1394 implementations guarantee is 4GB.  I could actually
have set a bigger mask in sbp2 when the controller supports a
programmable bigger range.

So that's the story why that dma_set_mask went into sbp2:  Sbp2 wants
mappings in a _subset_ of the OHCI-1394 controllers DMA range.

Anyway.  For now I will simply go with what 2.6.23-rc has and what
2.6.21 had:  No dma_set_mask anywhere in the 1394 subsystem.  We can
revisit this whenever an actual need arises.
-- 
Stefan Richter
-=====-=-=== =--- --==-
http://arcgraph.de/sr/

^ permalink raw reply

* Re: [PATCH] Use 1TB segments
From: Jon Tollefson @ 2007-08-06 22:23 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18095.59959.698141.565343@cargo.ozlabs.ibm.com>

Paul Mackerras wrote:
> diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
>   
A couple of hunks fail in this file when applying to the current tree.

...
> diff --git a/include/asm-powerpc/mmu-hash64.h b/include/asm-powerpc/mmu-hash64.h
> index 695962f..053f86b 100644
> --- a/include/asm-powerpc/mmu-hash64.h
> +++ b/include/asm-powerpc/mmu-hash64.h
> @@ -47,6 +47,8 @@ extern char initial_stab[];
>
>  /* Bits in the SLB VSID word */
>  #define SLB_VSID_SHIFT		12
> +#define SLB_VSID_SHIFT_1T	24
> +#define SLB_VSID_SSIZE_SHIFT	62
>  #define SLB_VSID_B		ASM_CONST(0xc000000000000000)
>  #define SLB_VSID_B_256M		ASM_CONST(0x0000000000000000)
>  #define SLB_VSID_B_1T		ASM_CONST(0x4000000000000000)
> @@ -66,6 +68,7 @@ extern char initial_stab[];
>  #define SLB_VSID_USER		(SLB_VSID_KP|SLB_VSID_KS|SLB_VSID_C)
>
>  #define SLBIE_C			(0x08000000)
> +#define SLBIE_SSIZE_SHIFT	25
>
>  /*
>   * Hash table
> @@ -77,7 +80,7 @@ extern char initial_stab[];
>  #define HPTE_V_AVPN_SHIFT	7
>  #define HPTE_V_AVPN		ASM_CONST(0x3fffffffffffff80)
>  #define HPTE_V_AVPN_VAL(x)	(((x) & HPTE_V_AVPN) >> HPTE_V_AVPN_SHIFT)
> -#define HPTE_V_COMPARE(x,y)	(!(((x) ^ (y)) & HPTE_V_AVPN))
> +#define HPTE_V_COMPARE(x,y)	(!(((x) ^ (y)) & 0xffffffffffffff80))
>  #define HPTE_V_BOLTED		ASM_CONST(0x0000000000000010)
>  #define HPTE_V_LOCK		ASM_CONST(0x0000000000000008)
>  #define HPTE_V_LARGE		ASM_CONST(0x0000000000000004)
> @@ -164,16 +167,25 @@ struct mmu_psize_def
>  #define MMU_SEGSIZE_256M	0
>  #define MMU_SEGSIZE_1T		1
>
> +/*
> + * Supported segment sizes
> + */
> +#define MMU_SEGSIZE_256M	0
> +#define MMU_SEGSIZE_1T		1
>   
It looks like this is repeating the definitions just above it.


Jon

^ permalink raw reply

* Re: [PATCH 2.6.22.y] ieee1394: revert "sbp2: enforce 32bit DMA mapping"
From: Benjamin Herrenschmidt @ 2007-08-06 22:29 UTC (permalink / raw)
  To: Stefan Richter
  Cc: Robert Hancock, linuxppc-dev, stable, linux-kernel, Olaf Hering
In-Reply-To: <46B79F25.50205@s5r6.in-berlin.de>

On Tue, 2007-08-07 at 00:22 +0200, Stefan Richter wrote:
> Benjamin Herrenschmidt wrote:
> > Oh and, don't do the set_dma_mask() in sbp2, it has nothing to do there.
> > It should be in the ohci1394 driver.
> 
> That's not quite right.  OHCI-1394 implementations can go beyond 4GB bus
> address space.  (Although I don't know if there are such implementations
> available.  At least there are two implementations which can set the
> so-called Physical Range bigger than 4GB.)

Hrm..

> Sbp2 however requires that everything which it DMA-maps resides in the
> Physical Range of the controller.  This way the CPU is not involved in
> most of the data transfers.  The OHCI-1394 controller acts as bus bridge
> between IEEE 1394 bus and local bus, with a 1:1 mapping of IEEE 1394 bus
> addresses to and from local bus addresses --- but not in the whole 48
> bits white IEEE 1394 bus address range, only in the
> implementation-dependent Physical Range.  The minimum Physical Range
> that all OHCI-1394 implementations guarantee is 4GB.  I could actually
> have set a bigger mask in sbp2 when the controller supports a
> programmable bigger range.
> 
> So that's the story why that dma_set_mask went into sbp2:  Sbp2 wants
> mappings in a _subset_ of the OHCI-1394 controllers DMA range.
> 
> Anyway.  For now I will simply go with what 2.6.23-rc has and what
> 2.6.21 had:  No dma_set_mask anywhere in the 1394 subsystem.  We can
> revisit this whenever an actual need arises.

Ok, I see your point, however, the problem is that at this stage, in
linux, you really can only set the dma mask on the pci device of the
ohci. That means that sbp2 will effectively change the ohci's DMA mask
for all OHCI operations...

Architectures like powerpc (and possibly others) need to track what
iommu/bridge/etc... a device is on for proper mapping and provide
different DMA operations for different busses. Thus, only devices that
have properly been "setup" by the architecture for DMA can use the DMA
operations.

So while ideally, sbp2 should set the dma mask on itself (or rather on
the sbp2 device) and then use that device for dma mapping operations,
this will not work.

Now, we could try to devise a generic API for use by things such as
ieee1394 to "make DMA'able" sub devices of a pci device with local dma
masks. At least for powerpc, it wouldn't be too hard, but other archs
might have issues if they do things like test for the bus_type.

Cheers,
Ben.

^ permalink raw reply

* Re: [PATCH] powerpc: Fix initialization and usage of dma_mask
From: Olaf Hering @ 2007-08-06 22:30 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: Robert Hancock, linux-kernel, linuxppc-dev, Stefan Richter,
	Paul Mackerras, stable
In-Reply-To: <1186437910.938.79.camel@localhost.localdomain>

On Tue, Aug 07, Benjamin Herrenschmidt wrote:

> powerpc has a couple of bugs in the usage of dma_masks that tend to
> break when drivers explicitely try to set a 32 bits mask for example.
> 
> First the code that generates the pci devices from the OF device-tree
> doesn't initialize the mask properly, then our implementation of
> set_dma_mask() was trying to validate the -previous- mask value, not the
> one passed in as an argument.
> 
> This patch should fix these.
> 
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> 
> Does this fix the problem you've noticed ?

This patch fixes it. Thanks.

^ permalink raw reply

* Re: [PATCH 2.6.22.y] ieee1394: revert "sbp2: enforce 32bit DMA mapping"
From: Benjamin Herrenschmidt @ 2007-08-06 22:32 UTC (permalink / raw)
  To: Robert Hancock
  Cc: linuxppc-dev, Stefan Richter, stable, linux-kernel, Olaf Hering
In-Reply-To: <46B79FD7.9020801@shaw.ca>

On Mon, 2007-08-06 at 16:25 -0600, Robert Hancock wrote:
> > Anyway.  For now I will simply go with what 2.6.23-rc has and what
> > 2.6.21 had:  No dma_set_mask anywhere in the 1394 subsystem.  We can
> > revisit this whenever an actual need arises.
> 
> Not sure this is a very good idea. This seems rather likely to fail on
> x86_64 machines with >4GB of RAM for example.. 

Would it ? Isn't the default DMA mask for PCI devices set to 32 bits
anyway ? In which case, swiotlb will take care of the matter.

Cheers,
Ben.

^ permalink raw reply

* Re: 2.6.23-rc1-mm2
From: Mariusz Kozlowski @ 2007-08-06 22:34 UTC (permalink / raw)
  To: Segher Boessenkool
  Cc: linux-usb-devel, gregkh, linux-kernel, linuxppc-dev, paulus,
	Andrew Morton
In-Reply-To: <236b147ed4a92945baa3c6b29e7e5f31@kernel.crashing.org>

> >>> Second issue as reported earilier allmodconfig fails to build on imac
> >>> g3.
> >>>
> >>>   CC      arch/powerpc/kernel/lparmap.s
> >>>   AS      arch/powerpc/kernel/head_64.o
> >>> lparmap.c: Assembler messages:
> >>> lparmap.c:84: Error: file number 1 already allocated
> >>> make[1]: *** [arch/powerpc/kernel/head_64.o] Blad 1
> >>> make: *** [arch/powerpc/kernel] Blad 2
> >>
> >> Please send me the full output of:
> >>
> >> gcc --version    (or whatever your gcc is called)
> >> ld --version
> >> ld --help        (I know no better way to get the supported binutils
> >>                    targets, and the default target)
> >>
> >> and the lparmap.s file.  You might want to skip sending it
> >> to the lists, it will be a bit big (and off-topic on most
> >> of those lists, anyway).
> >
> > Well ... its 66kB. Not that bad. Please find it attached.
> > Needed gcc and ld info below.
> 
> Thanks.
> 
> It seems like things go wrong when lparmap.s is generated with
> (DWARF) debug info; could you try building it (manually) with -g0
> added on the end of the compile line, and see if head_64.o compiles
> okay for you then?  If so, I'll prepare a proper patch for it, I
> have a similar one (also for lparmap!) in my queue already...

Ok it worked. I had to add -g0 to Makefile under arch/powerpc/kernel because
-g0 was added before -g and didn't have any effect when adding to Makefile
in top dir. But yes - it compiles now.

Thanks,

	Mariusz

^ permalink raw reply

* Re: [PATCH 2.6.22.y] ieee1394: revert "sbp2: enforce 32bit DMA mapping"
From: Robert Hancock @ 2007-08-06 22:35 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: linuxppc-dev, Stefan Richter, stable, linux-kernel, Olaf Hering
In-Reply-To: <1186439529.938.95.camel@localhost.localdomain>

Benjamin Herrenschmidt wrote:
> On Mon, 2007-08-06 at 16:25 -0600, Robert Hancock wrote:
>>> Anyway.  For now I will simply go with what 2.6.23-rc has and what
>>> 2.6.21 had:  No dma_set_mask anywhere in the 1394 subsystem.  We can
>>> revisit this whenever an actual need arises.
>> Not sure this is a very good idea. This seems rather likely to fail on
>> x86_64 machines with >4GB of RAM for example.. 
> 
> Would it ? Isn't the default DMA mask for PCI devices set to 32 bits
> anyway ? In which case, swiotlb will take care of the matter.
> 
> Cheers,
> Ben.

Hmm, that's true, yes. Suppose it shouldn't be a problem then.

I would agree, though, that sbp2 isn't really the place for setting 
this, since the DMA mask is presently a property of the device, not of 
the user..

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

^ permalink raw reply

* Re: [PATCH 2.6.22.y] ieee1394: revert "sbp2: enforce 32bit DMA mapping"
From: Stefan Richter @ 2007-08-06 22:48 UTC (permalink / raw)
  To: Robert Hancock; +Cc: linuxppc-dev, stable, linux-kernel, Olaf Hering
In-Reply-To: <46B79FD7.9020801@shaw.ca>

Robert Hancock wrote:
> Stefan Richter wrote:
>> So that's the story why that dma_set_mask went into sbp2:  Sbp2 wants
>> mappings in a _subset_ of the OHCI-1394 controllers DMA range.
>>
>> Anyway.  For now I will simply go with what 2.6.23-rc has and what
>> 2.6.21 had:  No dma_set_mask anywhere in the 1394 subsystem.  We can
>> revisit this whenever an actual need arises.
> 
> Not sure this is a very good idea. This seems rather likely to fail on
> x86_64 machines with >4GB of RAM for example..

I'll deal with it when a bug report comes in.

  1.) The ieee1394 subsystem is known to work on x86_64 with more than 4
GB RAM, so I gather that architecture code already sets a proper DMA
mask for all those 32bit PCI OHCI-1394 implementations out there.

  2.) I haven't heard of an OHCI-1394 chip whose overall DMA range was
bigger than the Physical Range.  There are only two chips, from ALi and
from Fujitsu, whose Physical Range is curiously bigger than the actual
DMA range.
-- 
Stefan Richter
-=====-=-=== =--- --===
http://arcgraph.de/sr/

^ permalink raw reply

* [PATCH] Generic configuration selector for Xilinx devices
From: Wolfgang Reissnegger @ 2007-08-06 22:54 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 121 bytes --]

This is intended to make visible all device driver options for
both powerpc and microblaze systems.

Thanks,
   Wolfgang

[-- Attachment #2: [PATCH] Generic configuration selector for Xilinx devices.txt --]
[-- Type: text/plain, Size: 1833 bytes --]


Signed-off-by: Wolfgang Reissnegger <wolfgang.reissnegger@xilinx.com>
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>

---
 arch/ppc/platforms/4xx/Kconfig |    1 +
 drivers/misc/Kconfig           |    1 +
 drivers/misc/xilinx/Kconfig    |    9 +++++++++
 drivers/video/Kconfig          |    2 +-
 4 files changed, 12 insertions(+), 1 deletions(-)
 create mode 100644 drivers/misc/xilinx/Kconfig

diff --git a/arch/ppc/platforms/4xx/Kconfig b/arch/ppc/platforms/4xx/Kconfig
index 76551b6..d7db7e4 100644
--- a/arch/ppc/platforms/4xx/Kconfig
+++ b/arch/ppc/platforms/4xx/Kconfig
@@ -228,6 +228,7 @@ config XILINX_VIRTEX_4_FX
 
 config XILINX_VIRTEX
 	bool
+	select XILINX_DRIVERS
 
 config STB03xxx
 	bool
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 2f2fbff..f8a504c 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -195,5 +195,6 @@ config BLINK
 	  output something to the screen like kexec kernels to give the user
 	  a visual indication that the kernel is doing something.
 
+source "drivers/misc/xilinx/Kconfig"
 
 endmenu
diff --git a/drivers/misc/xilinx/Kconfig b/drivers/misc/xilinx/Kconfig
new file mode 100644
index 0000000..93c41a7
--- /dev/null
+++ b/drivers/misc/xilinx/Kconfig
@@ -0,0 +1,9 @@
+#
+# Xilinx devices and common device driver infrastructure
+#
+
+config XILINX_DRIVERS
+  bool
+  help
+    Enable visibility of all Xilinx device drivers.
+
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 403dac7..13910a8 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1811,7 +1811,7 @@ config FB_PS3_DEFAULT_SIZE_M
 
 config FB_XILINX
 	tristate "Xilinx frame buffer support"
-	depends on FB && XILINX_VIRTEX
+	depends on FB && XILINX_DRIVERS
 	select FB_CFB_FILLRECT
 	select FB_CFB_COPYAREA
 	select FB_CFB_IMAGEBLIT
-- 
1.5.1


^ permalink raw reply related

* [PATCH] Consolidate XILINX_VIRTEX board support
From: Wolfgang Reissnegger @ 2007-08-06 22:57 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 152 bytes --]

Make support for Xilinx boards more generic, making it easier
to add new boards.  Add initial support for xupv2p and ml410 boards.

Thanks,
   Wolfgang

[-- Attachment #2: [PATCH] Consolidate XILINX_VIRTEX board support.txt --]
[-- Type: text/plain, Size: 34090 bytes --]


Signed-off-by: Wolfgang Reissnegger <wolfgang.reissnegger@xilinx.com>
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
---
 arch/ppc/boot/simple/Makefile                      |    3 +-
 arch/ppc/boot/simple/embed_config.c                |    4 +-
 arch/ppc/platforms/4xx/Kconfig                     |   15 +
 arch/ppc/platforms/4xx/Makefile                    |    2 +
 arch/ppc/platforms/4xx/virtex.h                    |    9 +
 arch/ppc/platforms/4xx/xilinx_generic_ppc.c        |  129 ++++++++
 arch/ppc/platforms/4xx/xilinx_xupv2p.c             |   43 +++
 arch/ppc/platforms/4xx/xparameters/xparameters.h   |    4 +
 .../platforms/4xx/xparameters/xparameters_ml41x.h  |  277 +++++++++++++++++
 .../platforms/4xx/xparameters/xparameters_xupv2p.h |  327 ++++++++++++++++++++
 10 files changed, 809 insertions(+), 4 deletions(-)
 create mode 100644 arch/ppc/platforms/4xx/xilinx_generic_ppc.c
 create mode 100644 arch/ppc/platforms/4xx/xilinx_xupv2p.c
 create mode 100644 arch/ppc/platforms/4xx/xparameters/xparameters_ml41x.h
 create mode 100644 arch/ppc/platforms/4xx/xparameters/xparameters_xupv2p.h

diff --git a/arch/ppc/boot/simple/Makefile b/arch/ppc/boot/simple/Makefile
index 5b87779..05631fe 100644
--- a/arch/ppc/boot/simple/Makefile
+++ b/arch/ppc/boot/simple/Makefile
@@ -187,8 +187,7 @@ boot-$(CONFIG_REDWOOD_6)	+= embed_config.o
 boot-$(CONFIG_8xx)		+= embed_config.o
 boot-$(CONFIG_8260)		+= embed_config.o
 boot-$(CONFIG_EP405)		+= embed_config.o
-boot-$(CONFIG_XILINX_ML300)	+= embed_config.o
-boot-$(CONFIG_XILINX_ML403)	+= embed_config.o
+boot-$(CONFIG_XILINX_VIRTEX)	+= embed_config.o
 boot-$(CONFIG_BSEIP)		+= iic.o
 boot-$(CONFIG_MBX)		+= iic.o pci.o qspan_pci.o
 boot-$(CONFIG_MV64X60)		+= misc-mv64x60.o
diff --git a/arch/ppc/boot/simple/embed_config.c b/arch/ppc/boot/simple/embed_config.c
index 840bff2..e0b8954 100644
--- a/arch/ppc/boot/simple/embed_config.c
+++ b/arch/ppc/boot/simple/embed_config.c
@@ -744,7 +744,7 @@ embed_config(bd_t **bdp)
 }
 #endif /* WILLOW */
 
-#if defined(CONFIG_XILINX_ML300) || defined(CONFIG_XILINX_ML403)
+#if defined(CONFIG_XILINX_VIRTEX)
 void
 embed_config(bd_t ** bdp)
 {
@@ -781,7 +781,7 @@ embed_config(bd_t ** bdp)
 	timebase_period_ns = 1000000000 / bd->bi_tbfreq;
 	/* see bi_tbfreq definition in arch/ppc/platforms/4xx/xilinx_ml300.h */
 }
-#endif /* CONFIG_XILINX_ML300 || CONFIG_XILINX_ML403 */
+#endif /* CONFIG_XILINX_VIRTEX */
 
 #ifdef CONFIG_IBM_OPENBIOS
 /* This could possibly work for all treeboot roms.
diff --git a/arch/ppc/platforms/4xx/Kconfig b/arch/ppc/platforms/4xx/Kconfig
index d7db7e4..56965cb 100644
--- a/arch/ppc/platforms/4xx/Kconfig
+++ b/arch/ppc/platforms/4xx/Kconfig
@@ -60,12 +60,27 @@ config XILINX_ML300
 	help
 	  This option enables support for the Xilinx ML300 evaluation board.
 
+config XILINX_XUPV2P
+	bool "Xilinx-XUPV2P"
+	select XILINX_VIRTEX_II_PRO
+	select EMBEDDEDBOOT
+	help
+	  This option enables support for the Xilinx University Program (XUP) Virtex 2 Pro board.
+
 config XILINX_ML403
 	bool "Xilinx-ML403"
 	select XILINX_VIRTEX_4_FX
 	select EMBEDDEDBOOT
 	help
 	  This option enables support for the Xilinx ML403 evaluation board.
+
+config XILINX_ML41x
+	bool "Xilinx-ML41x"
+	select XILINX_VIRTEX_4_FX
+	select EMBEDDEDBOOT
+	help
+	  This option enables support for the Xilinx ML410/411 evaluation boards.
+
 endchoice
 
 choice
diff --git a/arch/ppc/platforms/4xx/Makefile b/arch/ppc/platforms/4xx/Makefile
index 723ad79..bcf1a63 100644
--- a/arch/ppc/platforms/4xx/Makefile
+++ b/arch/ppc/platforms/4xx/Makefile
@@ -15,7 +15,9 @@ obj-$(CONFIG_SYCAMORE)		+= sycamore.o
 obj-$(CONFIG_TAISHAN)		+= taishan.o
 obj-$(CONFIG_WALNUT)		+= walnut.o
 obj-$(CONFIG_XILINX_ML300)	+= xilinx_ml300.o
+obj-$(CONFIG_XILINX_XUPV2P)	+= xilinx_generic_ppc.o xilinx_xupv2p.o
 obj-$(CONFIG_XILINX_ML403)	+= xilinx_ml403.o
+obj-$(CONFIG_XILINX_ML41x)	+= xilinx_generic_ppc.o
 
 obj-$(CONFIG_405GP)		+= ibm405gp.o
 obj-$(CONFIG_REDWOOD_5)		+= ibmstb4.o
diff --git a/arch/ppc/platforms/4xx/virtex.h b/arch/ppc/platforms/4xx/virtex.h
index 7382804..47f67b3 100644
--- a/arch/ppc/platforms/4xx/virtex.h
+++ b/arch/ppc/platforms/4xx/virtex.h
@@ -31,5 +31,14 @@ extern const char* virtex_machine_name;
 #define PPC4xx_ONB_IO_VADDR	0u
 #define PPC4xx_ONB_IO_SIZE	0u
 
+
+#if defined(CONFIG_XILINX_VIRTEX_II_PRO)
+#define XILINX_ARCH "Virtex-II Pro"
+#elif defined(CONFIG_XILINX_VIRTEX_4_FX)
+#define XILINX_ARCH "Virtex-4 FX"
+#else
+#error "No Xilinx Architecture recognized."
+#endif
+
 #endif				/* __ASM_VIRTEX_H__ */
 #endif				/* __KERNEL__ */
diff --git a/arch/ppc/platforms/4xx/xilinx_generic_ppc.c b/arch/ppc/platforms/4xx/xilinx_generic_ppc.c
new file mode 100644
index 0000000..103e762
--- /dev/null
+++ b/arch/ppc/platforms/4xx/xilinx_generic_ppc.c
@@ -0,0 +1,129 @@
+/*
+ * Xilinx Generic PPC evaluation board initialization
+ *
+ * Author: MontaVista Software, Inc.
+ *         source@mvista.com
+ *
+ * 2002-2004 (c) MontaVista Software, 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.
+ */
+
+#include <linux/init.h>
+#include <linux/irq.h>
+#include <linux/tty.h>
+#include <linux/serial.h>
+#include <linux/serial_core.h>
+#include <linux/serial_8250.h>
+#include <linux/serialP.h>
+#include <linux/io.h>
+#include <asm/machdep.h>
+
+#include <syslib/gen550.h>
+#include <syslib/virtex_devices.h>
+#include <platforms/4xx/xparameters/xparameters.h>
+
+/*
+ * As an overview of how the following functions (platform_init,
+ * xilinx_generic_ppc_map_io, xilinx_generic_ppc_setup_arch and xilinx_generic_ppc_init_IRQ) fit into the
+ * kernel startup procedure, here's a call tree:
+ *
+ * start_here					arch/ppc/kernel/head_4xx.S
+ *  early_init					arch/ppc/kernel/setup.c
+ *  machine_init				arch/ppc/kernel/setup.c
+ *    platform_init				this file
+ *      ppc4xx_init				arch/ppc/syslib/ppc4xx_setup.c
+ *        parse_bootinfo
+ *          find_bootinfo
+ *        "setup some default ppc_md pointers"
+ *  MMU_init					arch/ppc/mm/init.c
+ *    *ppc_md.setup_io_mappings == xilinx_generic_ppc_map_io	this file
+ *      ppc4xx_map_io				arch/ppc/syslib/ppc4xx_setup.c
+ *  start_kernel				init/main.c
+ *    setup_arch				arch/ppc/kernel/setup.c
+ * #if defined(CONFIG_KGDB)
+ *      *ppc_md.kgdb_map_scc() == gen550_kgdb_map_scc
+ * #endif
+ *      *ppc_md.setup_arch == xilinx_generic_ppc_setup_arch	this file
+ *        ppc4xx_setup_arch			arch/ppc/syslib/ppc4xx_setup.c
+ *          ppc4xx_find_bridges			arch/ppc/syslib/ppc405_pci.c
+ *    init_IRQ					arch/ppc/kernel/irq.c
+ *      *ppc_md.init_IRQ == xilinx_generic_ppc_init_IRQ	this file
+ *        ppc4xx_init_IRQ			arch/ppc/syslib/ppc4xx_setup.c
+ *          ppc4xx_pic_init			arch/ppc/syslib/xilinx_pic.c
+ */
+
+#if defined(CONFIG_XILINX_ML300)
+const char *virtex_machine_name = "Xilinx ML300";
+#elif defined(CONFIG_XILINX_XUPV2P)
+const char *virtex_machine_name = "Xilinx XUPV2P";
+#elif defined(CONFIG_XILINX_ML40x)
+const char *virtex_machine_name = "Xilinx ML40x";
+#elif defined(CONFIG_XILINX_ML41x)
+const char *virtex_machine_name = "Xilinx ML41x";
+#else
+const char *virtex_machine_name = "Unknown Xilinx with PowerPC";
+#endif
+
+
+#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
+static volatile unsigned *powerdown_base =
+    (volatile unsigned *) XPAR_POWER_0_POWERDOWN_BASEADDR;
+
+static void
+xilinx_power_off(void)
+{
+	local_irq_disable();
+	out_be32(powerdown_base, XPAR_POWER_0_POWERDOWN_VALUE);
+	while (1) ;
+}
+#endif
+
+void __init
+xilinx_generic_ppc_map_io(void)
+{
+	ppc4xx_map_io();
+
+#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
+	powerdown_base = ioremap((unsigned long) powerdown_base,
+				 XPAR_POWER_0_POWERDOWN_HIGHADDR -
+				 XPAR_POWER_0_POWERDOWN_BASEADDR + 1);
+#endif
+}
+
+void __init
+xilinx_generic_ppc_setup_arch(void)
+{
+	virtex_early_serial_map();
+	ppc4xx_setup_arch();	/* calls ppc4xx_find_bridges() */
+
+	/* Identify the system */
+	printk(KERN_INFO "Xilinx Generic PowerPC board support package (%s) (%s)\n", PPC4xx_MACHINE_NAME, XILINX_ARCH);
+}
+
+/* Called after board_setup_irq from ppc4xx_init_IRQ(). */
+void __init
+xilinx_generic_ppc_init_irq(void)
+{
+	ppc4xx_init_IRQ();
+}
+
+void __init
+platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+	 unsigned long r6, unsigned long r7)
+{
+	ppc4xx_init(r3, r4, r5, r6, r7);
+
+	ppc_md.setup_arch = xilinx_generic_ppc_setup_arch;
+	ppc_md.setup_io_mappings = xilinx_generic_ppc_map_io;
+	ppc_md.init_IRQ = xilinx_generic_ppc_init_irq;
+
+#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
+	ppc_md.power_off = xilinx_power_off;
+#endif
+
+#ifdef CONFIG_KGDB
+	ppc_md.early_serial_map = virtex_early_serial_map;
+#endif
+}
+
diff --git a/arch/ppc/platforms/4xx/xilinx_xupv2p.c b/arch/ppc/platforms/4xx/xilinx_xupv2p.c
new file mode 100644
index 0000000..aa2d890
--- /dev/null
+++ b/arch/ppc/platforms/4xx/xilinx_xupv2p.c
@@ -0,0 +1,43 @@
+/*
+ * Xilinx XUPV2P board initialization
+ *
+ * Author: Stephen.Neuendorffer@xilinx.com
+ *
+ * 2007 (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.
+ */
+
+#include <linux/xilinx_devices.h>
+#include <platforms/4xx/xparameters/xparameters.h>
+
+int virtex_device_fixup(struct platform_device *dev)
+{
+ int i;
+#ifdef XPAR_ONEWIRE_0_BASEADDR
+ /* Use the Silicon Serial ID attached on the onewire bus to */
+ /* generate sensible MAC addresses. */
+ unsigned char *pOnewire = ioremap(XPAR_ONEWIRE_0_BASEADDR, 6);
+ struct xemac_platform_data *pdata = dev->dev.platform_data;
+ if (strcmp(dev->name, "xilinx_emac") == 0) {
+  printk(KERN_INFO "Fixup MAC address for %s:%d\n",
+    dev->name, dev->id);
+  /* FIXME.. this doesn't seem to return data that is consistent */
+  /* with the self test... why not? */
+  pdata->mac_addr[0] = 0x00;
+  pdata->mac_addr[1] = 0x0A;
+  pdata->mac_addr[2] = 0x35;
+  pdata->mac_addr[3] = dev->id;
+  pdata->mac_addr[4] = pOnewire[4];
+  pdata->mac_addr[5] = pOnewire[5];
+  printk(KERN_INFO "MAC address is now %2x:%2x:%2x:%2x:%2x:%2x\n",
+   pdata->mac_addr[0],
+   pdata->mac_addr[1],
+   pdata->mac_addr[2],
+   pdata->mac_addr[3],
+   pdata->mac_addr[4],
+   pdata->mac_addr[5]);
+ }
+#endif
+ return 0;
+}
diff --git a/arch/ppc/platforms/4xx/xparameters/xparameters.h b/arch/ppc/platforms/4xx/xparameters/xparameters.h
index 01aa043..34d9844 100644
--- a/arch/ppc/platforms/4xx/xparameters/xparameters.h
+++ b/arch/ppc/platforms/4xx/xparameters/xparameters.h
@@ -15,8 +15,12 @@
 
 #if defined(CONFIG_XILINX_ML300)
   #include "xparameters_ml300.h"
+#elif defined(CONFIG_XILINX_XUPV2P)
+  #include "xparameters_xupv2p.h"
 #elif defined(CONFIG_XILINX_ML403)
   #include "xparameters_ml403.h"
+#elif defined(CONFIG_XILINX_ML41x)
+  #include "xparameters_ml41x.h"
 #else
   /* Add other board xparameter includes here before the #else */
   #error No xparameters_*.h file included
diff --git a/arch/ppc/platforms/4xx/xparameters/xparameters_ml41x.h b/arch/ppc/platforms/4xx/xparameters/xparameters_ml41x.h
new file mode 100644
index 0000000..ff6956f
--- /dev/null
+++ b/arch/ppc/platforms/4xx/xparameters/xparameters_ml41x.h
@@ -0,0 +1,277 @@
+
+/*******************************************************************
+*
+* CAUTION: This file is automatically generated by libgen.
+* Version: Xilinx EDK 8.2.02 EDK_Im_Sp2.4
+* DO NOT EDIT.
+*
+* Copyright (c) 2005 Xilinx, Inc.  All rights reserved.
+*
+* Description: Driver parameters
+*
+*******************************************************************/
+
+/* Definitions for driver PLBARB */
+#define XPAR_XPLBARB_NUM_INSTANCES 1
+
+/* Definitions for peripheral PLB */
+#define XPAR_PLB_BASEADDR 0x00000000
+#define XPAR_PLB_HIGHADDR 0x00000000
+#define XPAR_PLB_DEVICE_ID 0
+#define XPAR_PLB_PLB_NUM_MASTERS 3
+
+
+/******************************************************************/
+
+/* Definitions for driver OPBARB */
+#define XPAR_XOPBARB_NUM_INSTANCES 1
+
+/* Definitions for peripheral OPB */
+#define XPAR_OPB_BASEADDR 0xFFFFFFFF
+#define XPAR_OPB_HIGHADDR 0x00000000
+#define XPAR_OPB_DEVICE_ID 0
+#define XPAR_OPB_NUM_MASTERS 1
+
+/******************************************************************/
+
+
+/* Definitions for peripheral OPB_SOCKET_0 */
+#define XPAR_OPB_SOCKET_0_BASEADDR 0x40000000
+#define XPAR_OPB_SOCKET_0_HIGHADDR 0x7FFFFFFF
+#define XPAR_OPB_SOCKET_0_DCR_BASEADDR 0x40700300
+#define XPAR_OPB_SOCKET_0_DCR_HIGHADDR 0x40700307
+
+/******************************************************************/
+
+/* Definitions for driver UARTNS550 */
+#define XPAR_XUARTNS550_NUM_INSTANCES 2
+#define XPAR_XUARTNS550_CLOCK_HZ 100000000
+
+/* Definitions for peripheral RS232_UART_1 */
+#define XPAR_RS232_UART_1_BASEADDR 0x40400000
+#define XPAR_RS232_UART_1_HIGHADDR 0x4040FFFF
+#define XPAR_RS232_UART_1_DEVICE_ID 0
+
+
+/* Definitions for peripheral RS232_UART_2 */
+#define XPAR_RS232_UART_2_BASEADDR 0x40420000
+#define XPAR_RS232_UART_2_HIGHADDR 0x4042FFFF
+#define XPAR_RS232_UART_2_DEVICE_ID 1
+
+
+/******************************************************************/
+
+/* Definitions for driver SPI */
+#define XPAR_XSPI_NUM_INSTANCES 1
+
+/* Definitions for peripheral SPI_EEPROM */
+#define XPAR_SPI_EEPROM_BASEADDR 0x40A00000
+#define XPAR_SPI_EEPROM_HIGHADDR 0x40A0FFFF
+#define XPAR_SPI_EEPROM_DEVICE_ID 0
+#define XPAR_SPI_EEPROM_FIFO_EXIST 1
+#define XPAR_SPI_EEPROM_SPI_SLAVE_ONLY 0
+#define XPAR_SPI_EEPROM_NUM_SS_BITS 1
+
+
+/******************************************************************/
+
+#define XPAR_XSYSACE_MEM_WIDTH 16
+/* Definitions for driver SYSACE */
+#define XPAR_XSYSACE_NUM_INSTANCES 1
+
+/* Definitions for peripheral SYSACE_COMPACTFLASH */
+#define XPAR_SYSACE_COMPACTFLASH_BASEADDR 0x41800000
+#define XPAR_SYSACE_COMPACTFLASH_HIGHADDR 0x4180FFFF
+#define XPAR_SYSACE_COMPACTFLASH_DEVICE_ID 0
+#define XPAR_SYSACE_COMPACTFLASH_MEM_WIDTH 16
+
+
+/******************************************************************/
+
+/* Definitions for driver IIC */
+#define XPAR_XIIC_NUM_INSTANCES 1
+
+/* Definitions for peripheral IIC_BUS */
+#define XPAR_IIC_BUS_BASEADDR 0x40800000
+#define XPAR_IIC_BUS_HIGHADDR 0x4080FFFF
+#define XPAR_IIC_BUS_DEVICE_ID 0
+#define XPAR_IIC_BUS_TEN_BIT_ADR 0
+#define XPAR_IIC_BUS_GPO_WIDTH 1
+
+
+/******************************************************************/
+
+#define XPAR_INTC_MAX_NUM_INTR_INPUTS 6
+#define XPAR_XINTC_HAS_IPR 1
+#define XPAR_XINTC_USE_DCR 0
+/* Definitions for driver INTC */
+#define XPAR_XINTC_NUM_INSTANCES 1
+
+/* Definitions for peripheral OPB_INTC_0 */
+#define XPAR_OPB_INTC_0_BASEADDR 0x41200000
+#define XPAR_OPB_INTC_0_HIGHADDR 0x4120FFFF
+#define XPAR_OPB_INTC_0_DEVICE_ID 0
+#define XPAR_OPB_INTC_0_KIND_OF_INTR 0x00000000
+
+
+/******************************************************************/
+
+#define XPAR_INTC_SINGLE_BASEADDR 0x41200000
+#define XPAR_INTC_SINGLE_HIGHADDR 0x4120FFFF
+#define XPAR_INTC_SINGLE_DEVICE_ID XPAR_OPB_INTC_0_DEVICE_ID
+#define XPAR_ETHERNET_MAC_IP2INTC_IRPT_MASK 0X000001
+#define XPAR_OPB_INTC_0_ETHERNET_MAC_IP2INTC_IRPT_INTR 0
+#define XPAR_IIC_BUS_IP2INTC_IRPT_MASK 0X000002
+#define XPAR_OPB_INTC_0_IIC_BUS_IP2INTC_IRPT_INTR 1
+#define XPAR_SYSACE_COMPACTFLASH_SYSACE_IRQ_MASK 0X000004
+#define XPAR_OPB_INTC_0_SYSACE_COMPACTFLASH_SYSACE_IRQ_INTR 2
+#define XPAR_SPI_EEPROM_IP2INTC_IRPT_MASK 0X000008
+#define XPAR_OPB_INTC_0_SPI_EEPROM_IP2INTC_IRPT_INTR 3
+#define XPAR_RS232_UART_2_IP2INTC_IRPT_MASK 0X000010
+#define XPAR_OPB_INTC_0_RS232_UART_2_IP2INTC_IRPT_INTR 4
+#define XPAR_RS232_UART_1_IP2INTC_IRPT_MASK 0X000020
+#define XPAR_OPB_INTC_0_RS232_UART_1_IP2INTC_IRPT_INTR 5
+
+/******************************************************************/
+
+/* Definitions for driver HWICAP */
+#define XPAR_XHWICAP_NUM_INSTANCES 1
+
+/* Definitions for peripheral OPB_HWICAP_0 */
+#define XPAR_OPB_HWICAP_0_BASEADDR 0x41300000
+#define XPAR_OPB_HWICAP_0_HIGHADDR 0x4130FFFF
+#define XPAR_OPB_HWICAP_0_DEVICE_ID 0
+
+/******************************************************************/
+
+/* Definitions for driver DDR */
+#define XPAR_XDDR_NUM_INSTANCES 1
+
+/* Definitions for peripheral DDR_SDRAM_32MX64 */
+#define XPAR_DDR_SDRAM_32MX64_ECC_BASEADDR 0xFFFFFFFF
+#define XPAR_DDR_SDRAM_32MX64_ECC_HIGHADDR 0x00000000
+#define XPAR_DDR_SDRAM_32MX64_DEVICE_ID 0
+#define XPAR_DDR_SDRAM_32MX64_INCLUDE_ECC_INTR 0
+
+
+/******************************************************************/
+
+/* Definitions for peripheral DDR_SDRAM_32MX64 */
+#define XPAR_DDR_SDRAM_32MX64_MEM0_BASEADDR 0x00000000
+#define XPAR_DDR_SDRAM_32MX64_MEM0_HIGHADDR 0x03FFFFFF
+
+/******************************************************************/
+
+/* Definitions for driver EMAC */
+#define XPAR_XEMAC_NUM_INSTANCES 1
+
+/* Definitions for peripheral ETHERNET_MAC */
+#define XPAR_ETHERNET_MAC_BASEADDR 0x80400000
+#define XPAR_ETHERNET_MAC_HIGHADDR 0x8040FFFF
+#define XPAR_ETHERNET_MAC_DEVICE_ID 0
+#define XPAR_ETHERNET_MAC_ERR_COUNT_EXIST 1
+#define XPAR_ETHERNET_MAC_DMA_PRESENT 1
+#define XPAR_ETHERNET_MAC_MII_EXIST 1
+
+
+/******************************************************************/
+
+
+/* Definitions for peripheral PLB_BRAM_IF_CNTLR_1 */
+#define XPAR_PLB_BRAM_IF_CNTLR_1_BASEADDR 0xfffff000
+#define XPAR_PLB_BRAM_IF_CNTLR_1_HIGHADDR 0xffffffff
+
+
+/******************************************************************/
+
+#define XPAR_CPU_PPC405_CORE_CLOCK_FREQ_HZ 300000000
+
+/******************************************************************/
+
+
+/******************************************************************/
+
+/* Cannonical Constant Names */
+
+/******************************************************************/
+
+#define XPAR_UARTNS550_0_BASEADDR (XPAR_RS232_UART_1_BASEADDR+0x1000)
+#define XPAR_UARTNS550_0_HIGHADDR XPAR_RS232_UART_1_HIGHADDR
+#define XPAR_UARTNS550_0_CLOCK_FREQ_HZ XPAR_XUARTNS550_CLOCK_HZ
+#define XPAR_UARTNS550_0_DEVICE_ID XPAR_RS232_UART_1_DEVICE_ID
+#define XPAR_UARTNS550_1_BASEADDR (XPAR_RS232_UART_2_BASEADDR+0x1000)
+#define XPAR_UARTNS550_1_HIGHADDR XPAR_RS232_UART_2_HIGHADDR
+#define XPAR_UARTNS550_1_CLOCK_FREQ_HZ XPAR_XUARTNS550_CLOCK_HZ
+#define XPAR_UARTNS550_1_DEVICE_ID XPAR_RS232_UART_2_DEVICE_ID
+
+/******************************************************************/
+
+#define XPAR_SPI_0_BASEADDR XPAR_SPI_EEPROM_BASEADDR
+#define XPAR_SPI_0_HIGHADDR XPAR_SPI_EEPROM_HIGHADDR
+#define XPAR_SPI_0_FIFO_EXIST XPAR_SPI_EEPROM_FIFO_EXIST
+#define XPAR_SPI_0_SPI_SLAVE_ONLY XPAR_SPI_EEPROM_SPI_SLAVE_ONLY
+#define XPAR_SPI_0_NUM_SS_BITS XPAR_SPI_EEPROM_NUM_SS_BITS
+#define XPAR_SPI_0_DEVICE_ID XPAR_SPI_EEPROM_DEVICE_ID
+
+/******************************************************************/
+
+#define XPAR_SYSACE_0_BASEADDR XPAR_SYSACE_COMPACTFLASH_BASEADDR
+#define XPAR_SYSACE_0_HIGHADDR XPAR_SYSACE_COMPACTFLASH_HIGHADDR
+#define XPAR_SYSACE_0_DEVICE_ID XPAR_SYSACE_COMPACTFLASH_DEVICE_ID
+
+/******************************************************************/
+
+#define XPAR_IIC_0_BASEADDR XPAR_IIC_BUS_BASEADDR
+#define XPAR_IIC_0_HIGHADDR XPAR_IIC_BUS_HIGHADDR
+#define XPAR_IIC_0_TEN_BIT_ADR XPAR_IIC_BUS_TEN_BIT_ADR
+#define XPAR_IIC_0_DEVICE_ID XPAR_IIC_BUS_DEVICE_ID
+
+/******************************************************************/
+
+#define XPAR_EMAC_0_BASEADDR XPAR_ETHERNET_MAC_BASEADDR
+#define XPAR_EMAC_0_HIGHADDR XPAR_ETHERNET_MAC_HIGHADDR
+#define XPAR_EMAC_0_DMA_PRESENT XPAR_ETHERNET_MAC_DMA_PRESENT
+#define XPAR_EMAC_0_MII_EXIST XPAR_ETHERNET_MAC_MII_EXIST
+#define XPAR_EMAC_0_ERR_COUNT_EXIST XPAR_ETHERNET_MAC_ERR_COUNT_EXIST
+#define XPAR_EMAC_0_DEVICE_ID XPAR_ETHERNET_MAC_DEVICE_ID
+
+/******************************************************************/
+
+#define XPAR_HWICAP_0_BASEADDR XPAR_OPB_HWICAP_0_BASEADDR
+#define XPAR_HWICAP_0_HIGHADDR XPAR_OPB_HWICAP_0_HIGHADDR
+#define XPAR_HWICAP_0_DEVICE_ID XPAR_OPB_HWICAP_0_DEVICE_ID
+
+/******************************************************************/
+
+#define XPAR_INTC_0_BASEADDR XPAR_OPB_INTC_0_BASEADDR
+#define XPAR_INTC_0_HIGHADDR XPAR_OPB_INTC_0_HIGHADDR
+#define XPAR_INTC_0_KIND_OF_INTR XPAR_OPB_INTC_0_KIND_OF_INTR
+#define XPAR_INTC_0_DEVICE_ID XPAR_OPB_INTC_0_DEVICE_ID
+
+/******************************************************************/
+
+#define XPAR_INTC_0_EMAC_0_VEC_ID XPAR_OPB_INTC_0_ETHERNET_MAC_IP2INTC_IRPT_INTR
+#define XPAR_INTC_0_IIC_0_VEC_ID XPAR_OPB_INTC_0_IIC_BUS_IP2INTC_IRPT_INTR
+#define XPAR_INTC_0_SYSACE_0_VEC_ID XPAR_OPB_INTC_0_SYSACE_COMPACTFLASH_SYSACE_IRQ_INTR
+#define XPAR_INTC_0_SPI_0_VEC_ID XPAR_OPB_INTC_0_SPI_EEPROM_IP2INTC_IRPT_INTR
+#define XPAR_INTC_0_UARTNS550_1_VEC_ID XPAR_OPB_INTC_0_RS232_UART_2_IP2INTC_IRPT_INTR
+#define XPAR_INTC_0_UARTNS550_0_VEC_ID XPAR_OPB_INTC_0_RS232_UART_1_IP2INTC_IRPT_INTR
+
+/******************************************************************/
+
+#define XPAR_PLB_CLOCK_FREQ_HZ 100000000
+#define XPAR_CORE_CLOCK_FREQ_HZ XPAR_CPU_PPC405_CORE_CLOCK_FREQ_HZ
+#define XPAR_DDR_0_SIZE 64000000
+
+/******************************************************************/
+
+#define XPAR_PERSISTENT_0_IIC_0_BASEADDR 1024
+#define XPAR_PERSISTENT_0_IIC_0_HIGHADDR 2047
+#define XPAR_PERSISTENT_0_IIC_0_EEPROMADDR 0xA0
+
+/******************************************************************/
+
+#define XPAR_PCI_0_CLOCK_FREQ_HZ    0
+
+/******************************************************************/
+
diff --git a/arch/ppc/platforms/4xx/xparameters/xparameters_xupv2p.h b/arch/ppc/platforms/4xx/xparameters/xparameters_xupv2p.h
new file mode 100644
index 0000000..cdaf28f
--- /dev/null
+++ b/arch/ppc/platforms/4xx/xparameters/xparameters_xupv2p.h
@@ -0,0 +1,327 @@
+
+/*******************************************************************
+*
+* CAUTION: This file is automatically generated by libgen.
+* Version: Xilinx EDK 8.2.02 EDK_Im_Sp2.4
+* DO NOT EDIT.
+*
+* Copyright (c) 2005 Xilinx, Inc.  All rights reserved.
+*
+* Description: Driver parameters
+*
+*******************************************************************/
+
+/* Definitions for driver PLBARB */
+#define XPAR_XPLBARB_NUM_INSTANCES 1
+
+/* Definitions for peripheral PLB */
+#define XPAR_PLB_BASEADDR 0x00000000
+#define XPAR_PLB_HIGHADDR 0x00000000
+#define XPAR_PLB_DEVICE_ID 0
+#define XPAR_PLB_PLB_NUM_MASTERS 3
+
+
+/******************************************************************/
+
+/* Definitions for driver OPBARB */
+#define XPAR_XOPBARB_NUM_INSTANCES 1
+
+/* Definitions for peripheral OPB */
+#define XPAR_OPB_BASEADDR 0xFFFFFFFF
+#define XPAR_OPB_HIGHADDR 0x00000000
+#define XPAR_OPB_DEVICE_ID 0
+#define XPAR_OPB_NUM_MASTERS 1
+
+
+/******************************************************************/
+
+
+/* Definitions for peripheral OPB_SOCKET_0 */
+#define XPAR_OPB_SOCKET_0_BASEADDR 0x7D400000
+#define XPAR_OPB_SOCKET_0_HIGHADDR 0x7D4000FF
+#define XPAR_OPB_SOCKET_0_DCR_BASEADDR 0x40700300
+#define XPAR_OPB_SOCKET_0_DCR_HIGHADDR 0x40700307
+
+/******************************************************************/
+
+/* Definitions for driver OPB_ONEWIRE */
+#define XPAR_OPB_ONEWIRE_NUM_INSTANCES 1
+
+/* Definitions for peripheral ONEWIRE_0 */
+#define XPAR_ONEWIRE_0_BASEADDR 0x7A200000
+#define XPAR_ONEWIRE_0_HIGHADDR 0x7A20FFFF
+
+
+/******************************************************************/
+
+/* Definitions for driver UARTNS550 */
+#define XPAR_XUARTNS550_NUM_INSTANCES 1
+#define XPAR_XUARTNS550_CLOCK_HZ 100000000
+
+/* Definitions for peripheral RS232_UART_1 */
+#define XPAR_RS232_UART_1_BASEADDR 0x40400000
+#define XPAR_RS232_UART_1_HIGHADDR 0x4040FFFF
+#define XPAR_RS232_UART_1_DEVICE_ID 0
+
+
+/******************************************************************/
+
+#define XPAR_XSYSACE_MEM_WIDTH 16
+/* Definitions for driver SYSACE */
+#define XPAR_XSYSACE_NUM_INSTANCES 1
+
+/* Definitions for peripheral SYSACE_COMPACTFLASH */
+#define XPAR_SYSACE_COMPACTFLASH_BASEADDR 0x41800000
+#define XPAR_SYSACE_COMPACTFLASH_HIGHADDR 0x4180FFFF
+#define XPAR_SYSACE_COMPACTFLASH_DEVICE_ID 0
+#define XPAR_SYSACE_COMPACTFLASH_MEM_WIDTH 16
+
+
+/******************************************************************/
+
+/* Definitions for driver GPIO */
+#define XPAR_XGPIO_NUM_INSTANCES 3
+
+/* Definitions for peripheral LEDS_4BIT */
+#define XPAR_LEDS_4BIT_BASEADDR 0x40000000
+#define XPAR_LEDS_4BIT_HIGHADDR 0x4000FFFF
+#define XPAR_LEDS_4BIT_DEVICE_ID 0
+#define XPAR_LEDS_4BIT_INTERRUPT_PRESENT 0
+#define XPAR_LEDS_4BIT_IS_DUAL 0
+
+
+/* Definitions for peripheral DIPSWS_4BIT */
+#define XPAR_DIPSWS_4BIT_BASEADDR 0x40020000
+#define XPAR_DIPSWS_4BIT_HIGHADDR 0x4002FFFF
+#define XPAR_DIPSWS_4BIT_DEVICE_ID 1
+#define XPAR_DIPSWS_4BIT_INTERRUPT_PRESENT 0
+#define XPAR_DIPSWS_4BIT_IS_DUAL 0
+
+
+/* Definitions for peripheral PUSHBUTTONS_5BIT */
+#define XPAR_PUSHBUTTONS_5BIT_BASEADDR 0x40040000
+#define XPAR_PUSHBUTTONS_5BIT_HIGHADDR 0x4004FFFF
+#define XPAR_PUSHBUTTONS_5BIT_DEVICE_ID 2
+#define XPAR_PUSHBUTTONS_5BIT_INTERRUPT_PRESENT 0
+#define XPAR_PUSHBUTTONS_5BIT_IS_DUAL 0
+
+
+/******************************************************************/
+
+#define XPAR_XPS2_NUM_INSTANCES 2
+#define XPAR_PS2_PORTS_DEVICE_ID_0 0
+#define XPAR_PS2_PORTS_BASEADDR_0 0x7a400000
+#define XPAR_PS2_PORTS_HIGHADDR_0 (0x7a400000+0x3F)
+#define XPAR_PS2_PORTS_DEVICE_ID_1 1
+#define XPAR_PS2_PORTS_BASEADDR_1 (0x7a400000+0x1000)
+#define XPAR_PS2_PORTS_HIGHADDR_1 (0x7a400000+0x103F)
+
+/******************************************************************/
+
+#define XPAR_INTC_MAX_NUM_INTR_INPUTS 7
+#define XPAR_XINTC_HAS_IPR 1
+#define XPAR_XINTC_USE_DCR 0
+/* Definitions for driver INTC */
+#define XPAR_XINTC_NUM_INSTANCES 1
+
+/* Definitions for peripheral OPB_INTC_0 */
+#define XPAR_OPB_INTC_0_BASEADDR 0x41200000
+#define XPAR_OPB_INTC_0_HIGHADDR 0x4120FFFF
+#define XPAR_OPB_INTC_0_DEVICE_ID 0
+#define XPAR_OPB_INTC_0_KIND_OF_INTR 0x00000000
+
+
+/******************************************************************/
+
+#define XPAR_INTC_SINGLE_BASEADDR 0x41200000
+#define XPAR_INTC_SINGLE_HIGHADDR 0x4120FFFF
+#define XPAR_INTC_SINGLE_DEVICE_ID XPAR_OPB_INTC_0_DEVICE_ID
+#define XPAR_OPB_TIMER_0_INTERRUPT_MASK 0X000001
+#define XPAR_OPB_INTC_0_OPB_TIMER_0_INTERRUPT_INTR 0
+#define XPAR_OPB_SOCKET_IP2INTC_IRPT_MASK 0X000002
+#define XPAR_OPB_INTC_0_OPB_SOCKET_IP2INTC_IRPT_INTR 1
+#define XPAR_ETHERNET_MAC_IP2INTC_IRPT_MASK 0X000004
+#define XPAR_OPB_INTC_0_ETHERNET_MAC_IP2INTC_IRPT_INTR 2
+#define XPAR_SYSACE_COMPACTFLASH_SYSACE_IRQ_MASK 0X000008
+#define XPAR_OPB_INTC_0_SYSACE_COMPACTFLASH_SYSACE_IRQ_INTR 3
+#define XPAR_RS232_UART_1_IP2INTC_IRPT_MASK 0X000010
+#define XPAR_OPB_INTC_0_RS232_UART_1_IP2INTC_IRPT_INTR 4
+#define XPAR_PS2_PORTS_SYS_INTR2_MASK 0X000020
+#define XPAR_OPB_INTC_0_PS2_PORTS_SYS_INTR2_INTR 5
+#define XPAR_PS2_PORTS_SYS_INTR1_MASK 0X000040
+#define XPAR_OPB_INTC_0_PS2_PORTS_SYS_INTR1_INTR 6
+
+/******************************************************************/
+
+/* Definitions for driver HWICAP */
+#define XPAR_XHWICAP_NUM_INSTANCES 1
+
+/* Definitions for peripheral OPB_HWICAP_0 */
+#define XPAR_OPB_HWICAP_0_BASEADDR 0x41300000
+#define XPAR_OPB_HWICAP_0_HIGHADDR 0x4130FFFF
+#define XPAR_OPB_HWICAP_0_DEVICE_ID 0
+
+/******************************************************************/
+
+/* Definitions for driver TFT_REF */
+#define XPAR_XTFT_NUM_INSTANCES 1
+
+/* Definitions for peripheral VGA_FRAMEBUFFER */
+#define XPAR_VGA_FRAMEBUFFER_DCR_BASEADDR 0x40700200
+#define XPAR_VGA_FRAMEBUFFER_DCR_HIGHADDR 0x40700207
+#define XPAR_VGA_FRAMEBUFFER_DEVICE_ID 0
+
+
+/******************************************************************/
+
+/* Definitions for driver TMRCTR */
+#define XPAR_XTMRCTR_NUM_INSTANCES 1
+
+/* Definitions for peripheral OPB_TIMER_0 */
+#define XPAR_OPB_TIMER_0_BASEADDR 0x40800000
+#define XPAR_OPB_TIMER_0_HIGHADDR 0x408000FF
+#define XPAR_OPB_TIMER_0_DEVICE_ID 0
+
+
+/******************************************************************/
+
+/* Definitions for driver EMAC */
+#define XPAR_XEMAC_NUM_INSTANCES 1
+
+/* Definitions for peripheral ETHERNET_MAC */
+#define XPAR_ETHERNET_MAC_BASEADDR 0x80400000
+#define XPAR_ETHERNET_MAC_HIGHADDR 0x8040FFFF
+#define XPAR_ETHERNET_MAC_DEVICE_ID 0
+#define XPAR_ETHERNET_MAC_ERR_COUNT_EXIST 1
+#define XPAR_ETHERNET_MAC_DMA_PRESENT 1
+#define XPAR_ETHERNET_MAC_MII_EXIST 1
+
+
+/******************************************************************/
+
+/* Definitions for driver DDR */
+#define XPAR_XDDR_NUM_INSTANCES 1
+
+/* Definitions for peripheral DDR_256MB_32MX64_RANK1_ROW13_COL10_CL2_5 */
+#define XPAR_DDR_256MB_32MX64_RANK1_ROW13_COL10_CL2_5_ECC_BASEADDR 0xFFFFFFFF
+#define XPAR_DDR_256MB_32MX64_RANK1_ROW13_COL10_CL2_5_ECC_HIGHADDR 0x00000000
+#define XPAR_DDR_256MB_32MX64_RANK1_ROW13_COL10_CL2_5_DEVICE_ID 0
+#define XPAR_DDR_256MB_32MX64_RANK1_ROW13_COL10_CL2_5_INCLUDE_ECC_INTR 0
+
+
+/******************************************************************/
+
+/* Definitions for peripheral DDR_256MB_32MX64_RANK1_ROW13_COL10_CL2_5 */
+#define XPAR_DDR_256MB_32MX64_RANK1_ROW13_COL10_CL2_5_MEM0_BASEADDR 0x00000000
+#define XPAR_DDR_256MB_32MX64_RANK1_ROW13_COL10_CL2_5_MEM0_HIGHADDR 0x0FFFFFFF
+
+/******************************************************************/
+
+
+/* Definitions for peripheral PLB_BRAM_IF_CNTLR_1 */
+#define XPAR_PLB_BRAM_IF_CNTLR_1_BASEADDR 0xffffc000
+#define XPAR_PLB_BRAM_IF_CNTLR_1_HIGHADDR 0xffffffff
+
+
+/******************************************************************/
+
+#define XPAR_CPU_PPC405_CORE_CLOCK_FREQ_HZ 300000000
+
+/******************************************************************/
+
+
+/******************************************************************/
+
+/* Cannonical Constant Names */
+
+/******************************************************************/
+
+#define XPAR_UARTNS550_0_BASEADDR (XPAR_RS232_UART_1_BASEADDR+0x1000)
+#define XPAR_UARTNS550_0_HIGHADDR XPAR_RS232_UART_1_HIGHADDR
+#define XPAR_UARTNS550_0_CLOCK_FREQ_HZ XPAR_XUARTNS550_CLOCK_HZ
+#define XPAR_UARTNS550_0_DEVICE_ID XPAR_RS232_UART_1_DEVICE_ID
+
+/******************************************************************/
+
+#define XPAR_EMAC_0_BASEADDR XPAR_ETHERNET_MAC_BASEADDR
+#define XPAR_EMAC_0_HIGHADDR XPAR_ETHERNET_MAC_HIGHADDR
+#define XPAR_EMAC_0_DMA_PRESENT XPAR_ETHERNET_MAC_DMA_PRESENT
+#define XPAR_EMAC_0_MII_EXIST XPAR_ETHERNET_MAC_MII_EXIST
+#define XPAR_EMAC_0_ERR_COUNT_EXIST XPAR_ETHERNET_MAC_ERR_COUNT_EXIST
+#define XPAR_EMAC_0_DEVICE_ID XPAR_ETHERNET_MAC_DEVICE_ID
+
+/******************************************************************/
+
+#define XPAR_SYSACE_0_BASEADDR XPAR_SYSACE_COMPACTFLASH_BASEADDR
+#define XPAR_SYSACE_0_HIGHADDR XPAR_SYSACE_COMPACTFLASH_HIGHADDR
+#define XPAR_SYSACE_0_DEVICE_ID XPAR_SYSACE_COMPACTFLASH_DEVICE_ID
+
+/******************************************************************/
+
+#define XPAR_TMRCTR_0_BASEADDR XPAR_OPB_TIMER_0_BASEADDR
+#define XPAR_TMRCTR_0_HIGHADDR XPAR_OPB_TIMER_0_HIGHADDR
+#define XPAR_TMRCTR_0_DEVICE_ID XPAR_OPB_TIMER_0_DEVICE_ID
+
+/******************************************************************/
+
+#define XPAR_HWICAP_0_BASEADDR XPAR_OPB_HWICAP_0_BASEADDR
+#define XPAR_HWICAP_0_HIGHADDR XPAR_OPB_HWICAP_0_HIGHADDR
+#define XPAR_HWICAP_0_DEVICE_ID XPAR_OPB_HWICAP_0_DEVICE_ID
+
+/******************************************************************/
+
+#define XPAR_GPIO_0_BASEADDR XPAR_LEDS_4BIT_BASEADDR
+#define XPAR_GPIO_0_HIGHADDR XPAR_LEDS_4BIT_HIGHADDR
+#define XPAR_GPIO_0_IS_DUAL XPAR_LEDS_4BIT_IS_DUAL
+#define XPAR_GPIO_0_DEVICE_ID XPAR_LEDS_4BIT_DEVICE_ID
+#define XPAR_GPIO_1_BASEADDR XPAR_DIPSWS_4BIT_BASEADDR
+#define XPAR_GPIO_1_HIGHADDR XPAR_DIPSWS_4BIT_HIGHADDR
+#define XPAR_GPIO_1_IS_DUAL XPAR_DIPSWS_4BIT_IS_DUAL
+#define XPAR_GPIO_1_DEVICE_ID XPAR_DIPSWS_4BIT_DEVICE_ID
+#define XPAR_GPIO_2_BASEADDR XPAR_PUSHBUTTONS_5BIT_BASEADDR
+#define XPAR_GPIO_2_HIGHADDR XPAR_PUSHBUTTONS_5BIT_HIGHADDR
+#define XPAR_GPIO_2_IS_DUAL XPAR_PUSHBUTTONS_5BIT_IS_DUAL
+#define XPAR_GPIO_2_DEVICE_ID XPAR_PUSHBUTTONS_5BIT_DEVICE_ID
+
+/******************************************************************/
+
+#define XPAR_PS2_0_BASEADDR XPAR_PS2_PORTS_BASEADDR_0
+#define XPAR_PS2_0_HIGHADDR XPAR_PS2_PORTS_HIGHADDR_0
+#define XPAR_PS2_0_DEVICE_ID XPAR_PS2_PORTS_DEVICE_ID_0
+#define XPAR_PS2_1_BASEADDR XPAR_PS2_PORTS_BASEADDR_1
+#define XPAR_PS2_1_HIGHADDR XPAR_PS2_PORTS_HIGHADDR_1
+#define XPAR_PS2_1_DEVICE_ID XPAR_PS2_PORTS_DEVICE_ID_1
+
+/******************************************************************/
+
+#define XPAR_INTC_0_BASEADDR XPAR_OPB_INTC_0_BASEADDR
+#define XPAR_INTC_0_HIGHADDR XPAR_OPB_INTC_0_HIGHADDR
+#define XPAR_INTC_0_KIND_OF_INTR XPAR_OPB_INTC_0_KIND_OF_INTR
+#define XPAR_INTC_0_DEVICE_ID XPAR_OPB_INTC_0_DEVICE_ID
+
+/******************************************************************/
+
+#define XPAR_INTC_0_TMRCTR_0_VEC_ID XPAR_OPB_INTC_0_OPB_TIMER_0_INTERRUPT_INTR
+#define XPAR_INTC_0_OPB_SOCKET_0_VEC_ID XPAR_OPB_INTC_0_OPB_SOCKET_IP2INTC_IRPT_INTR
+#define XPAR_INTC_0_EMAC_0_VEC_ID XPAR_OPB_INTC_0_ETHERNET_MAC_IP2INTC_IRPT_INTR
+#define XPAR_INTC_0_SYSACE_0_VEC_ID XPAR_OPB_INTC_0_SYSACE_COMPACTFLASH_SYSACE_IRQ_INTR
+#define XPAR_INTC_0_UARTNS550_0_VEC_ID XPAR_OPB_INTC_0_RS232_UART_1_IP2INTC_IRPT_INTR
+#define XPAR_INTC_0_PS2_1_VEC_ID XPAR_OPB_INTC_0_PS2_PORTS_SYS_INTR2_INTR
+#define XPAR_INTC_0_PS2_0_VEC_ID XPAR_OPB_INTC_0_PS2_PORTS_SYS_INTR1_INTR
+
+/******************************************************************/
+
+#define XPAR_TFT_0_BASEADDR XPAR_VGA_FRAMEBUFFER_DCR_BASEADDR
+
+/******************************************************************/
+
+#define XPAR_PLB_CLOCK_FREQ_HZ 100000000
+#define XPAR_CORE_CLOCK_FREQ_HZ XPAR_CPU_PPC405_CORE_CLOCK_FREQ_HZ
+#define XPAR_DDR_0_SIZE 0x10000000
+
+/******************************************************************/
+
+#define XPAR_PCI_0_CLOCK_FREQ_HZ    0
+
+/******************************************************************/
+
-- 
1.5.1


^ permalink raw reply related

* Re: [PATCH 2.6.22.y] ieee1394: revert "sbp2: enforce 32bit DMA mapping"
From: Stefan Richter @ 2007-08-06 22:59 UTC (permalink / raw)
  To: Robert Hancock; +Cc: linuxppc-dev, stable, linux-kernel, Olaf Hering
In-Reply-To: <46B7A22D.4030909@shaw.ca>

Robert Hancock wrote:
> I would agree, though, that sbp2 isn't really the place for setting
> this, since the DMA mask is presently a property of the device, not of
> the user..

The mask that sbp2 set was because sbp2 has (in theory, not yet in
practice) a _narrower requirement on address ranges than the chip_ ---
hence it has (in theory) a narrower requirement on DMA mappings than the
ohci1394 driver has.

That's because sbp2 uses the controller in a special mode, as a bus
bridge.  It is the only user of that feature among the higher-level IEEE
1394 drivers.  No other IEEE 1394 application-layer software has this
requirement.

(Well, debugging and forensic tools rely on that mode too, notably
BenH's firescope, but this software runs remote, hence it's a different
beast from sbp2.)
-- 
Stefan Richter
-=====-=-=== =--- --===
http://arcgraph.de/sr/

^ permalink raw reply

* RE: [PATCH] Generic configuration selector for Xilinx devices
From: Stephen Neuendorffer @ 2007-08-06 23:01 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <20070806225403.B430E550060@mail33-cpk.bigfish.com>


Please consider these a 'first experiment' in generating patches.. :)
Sorry the XILINX_DRIVERS patch took so long, but hopefully things should
be easier after getting the first patch out...

Feedback (especially WRT the structure of the patches and the process
of generating them) is greatly welcome...

Steve

> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
> =20
> [mailto:linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@oz
labs.org] On Behalf Of Wolfgang Reissnegger
> Sent: Monday, August 06, 2007 3:55 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: [PATCH] Generic configuration selector for Xilinx devices
>=20
> This is intended to make visible all device driver options for
> both powerpc and microblaze systems.
>=20
> Thanks,
>    Wolfgang
>=20

^ permalink raw reply

* Re: [PATCH 2/6] PowerPC 440EPx: Sequoia DTS
From: Segher Boessenkool @ 2007-08-06 23:09 UTC (permalink / raw)
  To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <1186438523.938.83.camel@localhost.localdomain>

>>     Actually, checking for the presence of all possible perverted
>> mapping
>> props doesn't seem a good idea -- it's simpler to check for the
>> presence of
>> one prop (like "direct-mapped" I was thinking about, or maybe
>> "simple-map").
>
> Or more simply... if it's not a direct mapping, it doesn't have a 
> ranges
> property and can't be walked down by conventional means.

That establishes that the flash address space is mapped 1-1 into
the host address space; however it doesn't say anything about
swizzling or interleaving or endianness etc., which are important
for NOR flash memory because of how the command sets work.


Segher

^ permalink raw reply

* Re: 2.6.23-rc1-mm2
From: Segher Boessenkool @ 2007-08-06 23:12 UTC (permalink / raw)
  To: Mariusz Kozlowski
  Cc: linux-usb-devel, gregkh, linux-kernel, linuxppc-dev, paulus,
	Andrew Morton
In-Reply-To: <200708070034.19193.m.kozlowski@tuxland.pl>

>> It seems like things go wrong when lparmap.s is generated with
>> (DWARF) debug info; could you try building it (manually) with -g0
>> added on the end of the compile line, and see if head_64.o compiles
>> okay for you then?  If so, I'll prepare a proper patch for it, I
>> have a similar one (also for lparmap!) in my queue already...
>
> Ok it worked. I had to add -g0 to Makefile under arch/powerpc/kernel 
> because
> -g0 was added before -g and didn't have any effect when adding to 
> Makefile
> in top dir.

Yeah, that's why I said "build lparmap.s manually" :-)

> But yes - it compiles now.

Great, I'll combine it with my other lparmap build patch then.
Thanks for the report and testing!


Segher

^ permalink raw reply

* Re: [PATCH] Consolidate XILINX_VIRTEX board support
From: Arnd Bergmann @ 2007-08-06 23:24 UTC (permalink / raw)
  To: linuxppc-embedded
In-Reply-To: <20070806225642.7D72A7B005B@mail34-fra.bigfish.com>

On Tuesday 07 August 2007, Wolfgang Reissnegger wrote:
>=20
> Make support for Xilinx boards more generic, making it easier
> to add new boards. =A0Add initial support for xupv2p and ml410 boards.

I really think we shouldn't add stuff to arch/ppc at this point,
it has been deprecated for over two years now.

> --- a/arch/ppc/platforms/4xx/virtex.h
> +++ b/arch/ppc/platforms/4xx/virtex.h
> @@ -31,5 +31,14 @@ extern const char* virtex_machine_name;
> =A0#define PPC4xx_ONB_IO_VADDR=A0=A0=A0=A00u
> =A0#define PPC4xx_ONB_IO_SIZE=A0=A0=A0=A0=A00u
> =A0
> +
> +#if defined(CONFIG_XILINX_VIRTEX_II_PRO)
> +#define XILINX_ARCH "Virtex-II Pro"
> +#elif defined(CONFIG_XILINX_VIRTEX_4_FX)
> +#define XILINX_ARCH "Virtex-4 FX"
> +#else
> +#error "No Xilinx Architecture recognized."
> +#endif
> +
> =A0#endif=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0/* __ASM_VIRTEX_H__ */
> =A0#endif=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0/* __KERNEL__ */

When you move over to arch/powerpc, you can't do it this way, because
that prevents you from building a multiplatform kernel.

Every macro and global function that gets defined must be able to coexist
with others that are enabled by nonexclusive configuration options.

> +#if defined(CONFIG_XILINX_ML300)
> +const char *virtex_machine_name =3D "Xilinx ML300";
> +#elif defined(CONFIG_XILINX_XUPV2P)
> +const char *virtex_machine_name =3D "Xilinx XUPV2P";
> +#elif defined(CONFIG_XILINX_ML40x)
> +const char *virtex_machine_name =3D "Xilinx ML40x";
> +#elif defined(CONFIG_XILINX_ML41x)
> +const char *virtex_machine_name =3D "Xilinx ML41x";
> +#else
> +const char *virtex_machine_name =3D "Unknown Xilinx with PowerPC";
> +#endif

same here.

> +
> +
> +#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
> +static volatile unsigned *powerdown_base =3D
> + =A0 =A0(volatile unsigned *) XPAR_POWER_0_POWERDOWN_BASEADDR;

volatile is a bug. This needs to be __iomem, and the address probably
needs to come from of_iomap() or a similar function.

> +static void
> +xilinx_power_off(void)
> +{
> +=A0=A0=A0=A0=A0=A0=A0local_irq_disable();
> +=A0=A0=A0=A0=A0=A0=A0out_be32(powerdown_base, XPAR_POWER_0_POWERDOWN_VAL=
UE);
> +=A0=A0=A0=A0=A0=A0=A0while (1) ;
> +}
> +#endif

You should run 'sparse' on your code before submitting patches. That
would have caught this bug in the out_be32() instruction that expects
an __iomem pointer.

> +
> +void __init
> +xilinx_generic_ppc_map_io(void)
> +{
> +=A0=A0=A0=A0=A0=A0=A0ppc4xx_map_io();
> +
> +#if defined(XPAR_POWER_0_POWERDOWN_BASEADDR)
> +=A0=A0=A0=A0=A0=A0=A0powerdown_base =3D ioremap((unsigned long) powerdow=
n_base,
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 XPAR_POWER_0_POWERDOWN_HIGHADDR -
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 XPAR_POWER_0_POWERDOWN_BASEADDR + 1);
> +#endif
> +}

It's a rather unconventional way of working with the addresses.
You should never use a single variable for pointers going to
two different address spaces (physical and kernel virtual in this
case).

> +void __init
> +xilinx_generic_ppc_setup_arch(void)
> +{
> +=A0=A0=A0=A0=A0=A0=A0virtex_early_serial_map();

Use legacy_serial/of_serial to do this, with proper device tree entries.

> +
> +int virtex_device_fixup(struct platform_device *dev)
> +{
> + int i;
> +#ifdef XPAR_ONEWIRE_0_BASEADDR
> + /* Use the Silicon Serial ID attached on the onewire bus to */
> + /* generate sensible MAC addresses. */
> + unsigned char *pOnewire =3D ioremap(XPAR_ONEWIRE_0_BASEADDR, 6);
> + struct xemac_platform_data *pdata =3D dev->dev.platform_data;
> + if (strcmp(dev->name, "xilinx_emac") =3D=3D 0) {

This is heavily whitespace damaged, use tabs for indentation instead
of spaces.

> diff --git a/arch/ppc/platforms/4xx/xparameters/xparameters.h b/arch/ppc/=
platforms/4xx/xparameters/xparameters.h
> index 01aa043..34d9844 100644
> --- a/arch/ppc/platforms/4xx/xparameters/xparameters.h
> +++ b/arch/ppc/platforms/4xx/xparameters/xparameters.h
> @@ -15,8 +15,12 @@
> =A0
> =A0#if defined(CONFIG_XILINX_ML300)
> =A0 =A0#include "xparameters_ml300.h"
> +#elif defined(CONFIG_XILINX_XUPV2P)
> + =A0#include "xparameters_xupv2p.h"
> =A0#elif defined(CONFIG_XILINX_ML403)
> =A0 =A0#include "xparameters_ml403.h"
> +#elif defined(CONFIG_XILINX_ML41x)
> + =A0#include "xparameters_ml41x.h"
> =A0#else
> =A0 =A0/* Add other board xparameter includes here before the #else */
> =A0 =A0#error No xparameters_*.h file included

see comment above.

> +/* Definitions for driver PLBARB */
> +#define XPAR_XPLBARB_NUM_INSTANCES 1
> +
> +/* Definitions for peripheral PLB */
> +#define XPAR_PLB_BASEADDR 0x00000000
> +#define XPAR_PLB_HIGHADDR 0x00000000
> +#define XPAR_PLB_DEVICE_ID 0
> +#define XPAR_PLB_PLB_NUM_MASTERS 3
> +
> +
> +/******************************************************************/
> +
> +/* Definitions for driver OPBARB */
> +#define XPAR_XOPBARB_NUM_INSTANCES 1
> +
> +/* Definitions for peripheral OPB */
> +#define XPAR_OPB_BASEADDR 0xFFFFFFFF
> +#define XPAR_OPB_HIGHADDR 0x00000000
> +#define XPAR_OPB_DEVICE_ID 0
> +#define XPAR_OPB_NUM_MASTERS 1
> +
> +/******************************************************************/
> +
> +
> +/* Definitions for peripheral OPB_SOCKET_0 */
> +#define XPAR_OPB_SOCKET_0_BASEADDR 0x40000000
> +#define XPAR_OPB_SOCKET_0_HIGHADDR 0x7FFFFFFF
> +#define XPAR_OPB_SOCKET_0_DCR_BASEADDR 0x40700300
> +#define XPAR_OPB_SOCKET_0_DCR_HIGHADDR 0x40700307
> +
> +/******************************************************************/
> +
> +/* Definitions for driver UARTNS550 */
> +#define XPAR_XUARTNS550_NUM_INSTANCES 2
> +#define XPAR_XUARTNS550_CLOCK_HZ 100000000
> +
> +/* Definitions for peripheral RS232_UART_1 */
> +#define XPAR_RS232_UART_1_BASEADDR 0x40400000
> +#define XPAR_RS232_UART_1_HIGHADDR 0x4040FFFF
> +#define XPAR_RS232_UART_1_DEVICE_ID 0
> +
> +
> +/* Definitions for peripheral RS232_UART_2 */
> +#define XPAR_RS232_UART_2_BASEADDR 0x40420000
> +#define XPAR_RS232_UART_2_HIGHADDR 0x4042FFFF
> +#define XPAR_RS232_UART_2_DEVICE_ID 1
> +

none of theses addresses, nor those following below should be hardcoded
in the kernel source, but should come from the device tree.

	Arnd <><

^ permalink raw reply

* Re: [PATCH 2.6.22.y] ieee1394: revert "sbp2: enforce 32bit DMA mapping"
From: Robert Hancock @ 2007-08-06 22:25 UTC (permalink / raw)
  To: Stefan Richter; +Cc: linuxppc-dev, stable, linux-kernel, Olaf Hering
In-Reply-To: <46B79F25.50205@s5r6.in-berlin.de>

Stefan Richter wrote:
> Benjamin Herrenschmidt wrote:
>> Oh and, don't do the set_dma_mask() in sbp2, it has nothing to do there.
>> It should be in the ohci1394 driver.
> 
> That's not quite right.  OHCI-1394 implementations can go beyond 4GB bus
> address space.  (Although I don't know if there are such implementations
> available.  At least there are two implementations which can set the
> so-called Physical Range bigger than 4GB.)
> 
> Sbp2 however requires that everything which it DMA-maps resides in the
> Physical Range of the controller.  This way the CPU is not involved in
> most of the data transfers.  The OHCI-1394 controller acts as bus bridge
> between IEEE 1394 bus and local bus, with a 1:1 mapping of IEEE 1394 bus
> addresses to and from local bus addresses --- but not in the whole 48
> bits white IEEE 1394 bus address range, only in the
> implementation-dependent Physical Range.  The minimum Physical Range
> that all OHCI-1394 implementations guarantee is 4GB.  I could actually
> have set a bigger mask in sbp2 when the controller supports a
> programmable bigger range.
> 
> So that's the story why that dma_set_mask went into sbp2:  Sbp2 wants
> mappings in a _subset_ of the OHCI-1394 controllers DMA range.
> 
> Anyway.  For now I will simply go with what 2.6.23-rc has and what
> 2.6.21 had:  No dma_set_mask anywhere in the 1394 subsystem.  We can
> revisit this whenever an actual need arises.

Not sure this is a very good idea. This seems rather likely to fail on 
x86_64 machines with >4GB of RAM for example..

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

^ permalink raw reply

* RE: [PATCH] Consolidate XILINX_VIRTEX board support
From: Stephen Neuendorffer @ 2007-08-06 23:36 UTC (permalink / raw)
  To: Arnd Bergmann, linuxppc-embedded
In-Reply-To: <200708070124.04748.arnd@arndb.de>


> On Tuesday 07 August 2007, Wolfgang Reissnegger wrote:
> >=20
> > Make support for Xilinx boards more generic, making it easier
> > to add new boards. =A0Add initial support for xupv2p and ml410 =
boards.
>=20
> I really think we shouldn't add stuff to arch/ppc at this point,
> it has been deprecated for over two years now.

This is a good point...  In fact the other patch (although tiny) is
more important, since it affects drivers, which should work in
arch/powerpc.  Thanks for the feedback anyway!

On this topic: has anyone tried using the recent Walnut patches for
arch/powerpc?   I briefly took a look at starting to port the Virtex
support to arch/powerpc but I'm a bit lost as to where to start... :)

Steve

^ permalink raw reply

* Re: [PATCH] Consolidate XILINX_VIRTEX board support
From: Grant Likely @ 2007-08-06 23:41 UTC (permalink / raw)
  To: Stephen Neuendorffer; +Cc: Arnd Bergmann, linuxppc-embedded
In-Reply-To: <20070806233630.95E233B0080@mail28-fra.bigfish.com>

On 8/6/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
>
> > On Tuesday 07 August 2007, Wolfgang Reissnegger wrote:
> > >
> > > Make support for Xilinx boards more generic, making it easier
> > > to add new boards. Add initial support for xupv2p and ml410 boards.
> >
> > I really think we shouldn't add stuff to arch/ppc at this point,
> > it has been deprecated for over two years now.
>
> This is a good point...  In fact the other patch (although tiny) is
> more important, since it affects drivers, which should work in
> arch/powerpc.  Thanks for the feedback anyway!
>
> On this topic: has anyone tried using the recent Walnut patches for
> arch/powerpc?   I briefly took a look at starting to port the Virtex
> support to arch/powerpc but I'm a bit lost as to where to start... :)

I plan to start hacking on it this week if things go well.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

^ permalink raw reply

* Re: [PING][PATCH] PPC 4xx HW Watchpoint
From: Josh Boyer @ 2007-08-07  0:08 UTC (permalink / raw)
  To: rrbranco; +Cc: linuxppc-dev
In-Reply-To: <OFC73E3C0F.0CFFE8F0-ON8325732F.00741361-8325732F.00749AD1@br.ibm.com>

On Mon, Aug 06, 2007 at 06:10:29PM -0300, rrbranco@br.ibm.com wrote:
> Hello guys,
> 
> I'm just writting to know if someone have some opinion about the patch I 
> sent a week ago.  I'm not sending it again cause I'm traveling and don't 
> have it here in this machine.

Sorry Rodrigo.  I'll try to find some time this week to review it.  It's been
on my list, I just haven't gotten to it yet.

josh

^ permalink raw reply

* Re: Please pull powerpc.git merge branch
From: Michael Ellerman @ 2007-08-07  1:06 UTC (permalink / raw)
  To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras, Zhang Wei-r63237
In-Reply-To: <FCAE5E05-7F25-436F-963B-B757765D343A@kernel.crashing.org>

On Mon, 2007-08-06 at 08:57 -0500, Kumar Gala wrote:
> On Aug 6, 2007, at 12:57 AM, Zhang Wei-r63237 wrote:
> 
> > Hi, Paul,
> >
> > How about following patches?
> >
> > [PATCH 1/2] Add sysdev/pci_quirks.c file into PowerPC architecture  
> > with
> > ULI chip quirk functions.
> > URL: http://ozlabs.org/pipermail/linuxppc-dev/2007-August/040363.html
> > [PATCH 2/2] Remove ULI chip quirks functions from MPC8641HPCN and
> > MPC8544DS boards.
> > URL: http://ozlabs.org/pipermail/linuxppc-dev/2007-August/040364.html
> >
> > [PATCH 1/3] Add a new member name to structure irq_host
> > URL: http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039896.html
> > [PATCH 2/3] Add irq host name for all powerpc interrupt controllors.
> > URL: http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039897.html
> > [PATCH 3/3] Add irq debugfs and virq_mapping for getting the virq
> > URL: http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039895.html
> 
> These patches aren't fixing any bugs and would be for 2.6.24 at this  
> point.

And I reworked them and posted new versions.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://ozlabs.org/pipermail/linuxppc-dev/attachments/20070807/bfb21f14/attachment.pgp 

^ permalink raw reply

* Re: [PATCH 2.6.22.y] ieee1394: revert "sbp2: enforce 32bit DMA mapping"
From: Andi Kleen @ 2007-08-07  2:18 UTC (permalink / raw)
  To: Stefan Richter
  Cc: Robert Hancock, linuxppc-dev, Olaf Hering, stable, linux-kernel
In-Reply-To: <46B7A537.9020807@s5r6.in-berlin.de>

Stefan Richter <stefanr@s5r6.in-berlin.de> writes:
> 
>   1.) The ieee1394 subsystem is known to work on x86_64 with more than 4
> GB RAM, 

It's actually ~3+GB where memory above the 4GB barrier starts appearing.
In some extreme cases even for 2+GB. 

> so I gather that architecture code already sets a proper DMA
> mask for all those 32bit PCI OHCI-1394 implementations out there.

If you don't set a DMA mask then the default is always 4GB.

-Andi

^ permalink raw reply

* Re: Please pull powerpc.git merge branch
From: Zang Roy-r61911 @ 2007-08-07  2:57 UTC (permalink / raw)
  To: michael; +Cc: linuxppc-dev list, Paul Mackerras, Zhang Wei-r63237
In-Reply-To: <1186448777.19257.0.camel@concordia.ozlabs.ibm.com>

On Tue, 2007-08-07 at 09:06, Michael Ellerman wrote:
> On Mon, 2007-08-06 at 08:57 -0500, Kumar Gala wrote:
> > On Aug 6, 2007, at 12:57 AM, Zhang Wei-r63237 wrote:
> > 
> > > Hi, Paul,
> > >
> > > How about following patches?
> > >
> > > [PATCH 1/2] Add sysdev/pci_quirks.c file into PowerPC
> architecture  
> > > with
> > > ULI chip quirk functions.
> > > URL:
> http://ozlabs.org/pipermail/linuxppc-dev/2007-August/040363.html
> > > [PATCH 2/2] Remove ULI chip quirks functions from MPC8641HPCN and
> > > MPC8544DS boards.
> > > URL:
> http://ozlabs.org/pipermail/linuxppc-dev/2007-August/040364.html
> > >
> > > [PATCH 1/3] Add a new member name to structure irq_host
> > > URL:
> http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039896.html
> > > [PATCH 2/3] Add irq host name for all powerpc interrupt
> controllors.
> > > URL:
> http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039897.html
> > > [PATCH 3/3] Add irq debugfs and virq_mapping for getting the virq
> > > URL:
> http://ozlabs.org/pipermail/linuxppc-dev/2007-July/039895.html
> > 
> > These patches aren't fixing any bugs and would be for 2.6.24 at
> this  
> > point.
> 
> And I reworked them and posted new versions.
Where are the new versions?
I missed them?
Roy

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox