LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH v2 0/9] DMA engine cookie handling cleanups
From: Vinod Koul @ 2012-03-13  8:40 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Stephen Warren, Linus Walleij, Srinidhi Kasagar, Barry Song,
	Dan Williams, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1331569438.1727.3.camel@vkoul-udesk3>

On Mon, 2012-03-12 at 21:53 +0530, Vinod Koul wrote:
> > > I applied the v2 on a branch and also rebased on top of
> slave-dma.next.
> > > There were few conflicts in imx-dma.c. Sacha, Javier, pls see that
> merge
> > > is right.
> > > 
> > > This branch (rmk_cookie_fixes2_rebased) is not yet pushed, as I am
> not
> > > able to connect to infradead.org, should be done when server is
> back.
> > 
> > Are you going to pick up Shawn Guo's tested-by for these patches, or
> are
> > we saying its too late for that now?
> Sure, his and others we have received on this series.
> Also, IIRC there was one fixup from Jassi on pl330?
> 
> I should be able to merge this tomorrow, if thats fine with you. 
I have merged this to my next, but haven't pushed out yet. This is
available on branch next_cookie2_merge.
Also I got few (more than expected build failures) and a merge issue on
imx driver. Sascha, Russell can you see if fix on imx is right

Please see if the below patch is the right fix for build failures in
addition to one suggested by Jassi.

-------------------x-------------------------x----------------------

>From 949ff5b8d46b5e3435d21b2651ce3a2599208d44 Mon Sep 17 00:00:00 2001
From: Vinod Koul <vinod.koul@linux.intel.com>
Date: Tue, 13 Mar 2012 11:58:12 +0530
Subject: [PATCH] dmaengine: fix for cookie changes and merge

Fixed trivial issues in drivers:
	drivers/dma/imx-sdma.c
	drivers/dma/intel_mid_dma.c
	drivers/dma/ioat/dma_v3.c
	drivers/dma/iop-adma.c
	drivers/dma/sirf-dma.c
	drivers/dma/timb_dma.c

Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
---
 drivers/dma/imx-sdma.c      |    1 +
 drivers/dma/intel_mid_dma.c |    1 +
 drivers/dma/ioat/dma_v3.c   |    1 +
 drivers/dma/iop-adma.c      |    1 +
 drivers/dma/sirf-dma.c      |    2 ++
 drivers/dma/timb_dma.c      |    6 +-----
 6 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index ccfc7c4..81f9d57 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1127,6 +1127,7 @@ static void sdma_issue_pending(struct dma_chan *chan)
 	struct sdma_engine *sdma = sdmac->sdma;
 
 	if (sdmac->status == DMA_IN_PROGRESS)
+		sdma_enable_channel(sdma, sdmac->channel);
 }
 
 #define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V1	34
diff --git a/drivers/dma/intel_mid_dma.c b/drivers/dma/intel_mid_dma.c
index d599d96..2449812 100644
--- a/drivers/dma/intel_mid_dma.c
+++ b/drivers/dma/intel_mid_dma.c
@@ -477,6 +477,7 @@ static enum dma_status intel_mid_dma_tx_status(struct dma_chan *chan,
 						dma_cookie_t cookie,
 						struct dma_tx_state *txstate)
 {
+	struct intel_mid_dma_chan *midc = to_intel_mid_dma_chan(chan);
 	enum dma_status ret;
 
 	ret = dma_cookie_status(chan, cookie, txstate);
diff --git a/drivers/dma/ioat/dma_v3.c b/drivers/dma/ioat/dma_v3.c
index 145eda2..2c4476c 100644
--- a/drivers/dma/ioat/dma_v3.c
+++ b/drivers/dma/ioat/dma_v3.c
@@ -61,6 +61,7 @@
 #include <linux/dmaengine.h>
 #include <linux/dma-mapping.h>
 #include <linux/prefetch.h>
+#include "../dmaengine.h"
 #include "registers.h"
 #include "hw.h"
 #include "dma.h"
diff --git a/drivers/dma/iop-adma.c b/drivers/dma/iop-adma.c
index 1f3a703..4499f88 100644
--- a/drivers/dma/iop-adma.c
+++ b/drivers/dma/iop-adma.c
@@ -894,6 +894,7 @@ static enum dma_status iop_adma_status(struct dma_chan *chan,
 					struct dma_tx_state *txstate)
 {
 	struct iop_adma_chan *iop_chan = to_iop_adma_chan(chan);
+	int ret;
 
 	ret = dma_cookie_status(chan, cookie, txstate);
 	if (ret == DMA_SUCCESS)
diff --git a/drivers/dma/sirf-dma.c b/drivers/dma/sirf-dma.c
index a2cde85..45ba352 100644
--- a/drivers/dma/sirf-dma.c
+++ b/drivers/dma/sirf-dma.c
@@ -18,6 +18,8 @@
 #include <linux/of_platform.h>
 #include <linux/sirfsoc_dma.h>
 
+#include "dmaengine.h"
+
 #define SIRFSOC_DMA_DESCRIPTORS                 16
 #define SIRFSOC_DMA_CHANNELS                    16
 
diff --git a/drivers/dma/timb_dma.c b/drivers/dma/timb_dma.c
index 7805996..d408c22 100644
--- a/drivers/dma/timb_dma.c
+++ b/drivers/dma/timb_dma.c
@@ -510,17 +510,13 @@ static void td_free_chan_resources(struct dma_chan *chan)
 static enum dma_status td_tx_status(struct dma_chan *chan, dma_cookie_t cookie,
 				    struct dma_tx_state *txstate)
 {
-	struct timb_dma_chan *td_chan =
-		container_of(chan, struct timb_dma_chan, chan);
 	enum dma_status ret;
 
 	dev_dbg(chan2dev(chan), "%s: Entry\n", __func__);
 
 	ret = dma_cookie_status(chan, cookie, txstate);
 
-	dev_dbg(chan2dev(chan),
-		"%s: exit, ret: %d, last_complete: %d, last_used: %d\n",
-		__func__, ret, last_complete, last_used);
+	dev_dbg(chan2dev(chan), "%s: exit, ret: %d\n", 	__func__, ret);
 
 	return ret;
 }
-- 
1.7.0.4




-- 
~Vinod

^ permalink raw reply related

* linux-next: manual merge of the akpm tree with the powerpc tree
From: Stephen Rothwell @ 2012-03-13  9:10 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Gavin Shan, linux-kernel, Oleg Nesterov, linux-next,
	Paul Mackerras, linuxppc-dev

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

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
arch/powerpc/platforms/pseries/eeh_event.c between commit 29f8bf1b7f79
("powerpc/pseries: Cleanup comments in EEH aux components") from the
powerpc tree and commit "powerpc/eeh: remove eeh_event_handler()
->daemonize()" from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/powerpc/platforms/pseries/eeh_event.c
index 4a47525,a6d33c8..0000000
--- a/arch/powerpc/platforms/pseries/eeh_event.c
+++ b/arch/powerpc/platforms/pseries/eeh_event.c
@@@ -56,10 -58,10 +56,10 @@@ DEFINE_MUTEX(eeh_event_mutex)
  static int eeh_event_handler(void * dummy)
  {
  	unsigned long flags;
 -	struct eeh_event	*event;
 -	struct pci_dn *pdn;
 +	struct eeh_event *event;
 +	struct eeh_dev *edev;
  
- 	daemonize("eehd");
+ 	set_task_comm(current, "eehd");
  	set_current_state(TASK_INTERRUPTIBLE);
  
  	spin_lock_irqsave(&eeh_eventlist_lock, flags);

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply

* Re: [PATCH v3 4/4] powerpc: Board support for GE IMP3A
From: Linus Walleij @ 2012-03-13 11:51 UTC (permalink / raw)
  To: Martyn Welch
  Cc: linux-kernel, Wim Van Sebroeck, Uwe Kleine-König,
	linuxppc-dev
In-Reply-To: <1331572380-1064-5-git-send-email-martyn.welch@ge.com>

On Mon, Mar 12, 2012 at 6:13 PM, Martyn Welch <martyn.welch@ge.com> wrote:

> Initial board support for the GE IMP3A, a 3U compactPCI card with a p2020
> processor.
(...)
> +++ b/arch/powerpc/configs/ge_imp3a_defconfig
> @@ -0,0 +1,257 @@
> +CONFIG_PPC_85xx=y
> +CONFIG_SMP=y
> +CONFIG_NR_CPUS=2
> +CONFIG_EXPERIMENTAL=y
> +CONFIG_SYSVIPC=y
> +CONFIG_POSIX_MQUEUE=y
> +CONFIG_BSD_PROCESS_ACCT=y
> +CONFIG_BSD_PROCESS_ACCT_V3=y
> +CONFIG_SPARSE_IRQ=y

This habit of changing a lot of defconfig stuff in a patch dealing with other
stuff is alien in the ARM world. Especially when changing a horde of stuff
that has nothing to do with the patch subject.

But I don't really know how PPC does these things so who am I to
speak ...

BTW: doesn't the "make saveconfig" reduce defconfigs on PPC?
Paging Uwe on this.

Yours,
Linus Walleij

^ permalink raw reply

* Re: [PATCH v2 0/9] DMA engine cookie handling cleanups
From: Nicolas Ferre @ 2012-03-13 11:45 UTC (permalink / raw)
  To: Russell King - ARM Linux, Vinod Koul
  Cc: Stephen Warren, Linus Walleij, Srinidhi Kasagar, Barry Song,
	Dan Williams, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20120306223321.GD15201@n2100.arm.linux.org.uk>

On 03/06/2012 11:33 PM, Russell King - ARM Linux :
> [v2 - more or less same description.  Including lakml in cc for the full
> set]
> 
> This patch series cleans up the handling of cookies in DMA engine drivers.
> This is done by providing a set of inline library functions for common
> tasks:
> 
> - moving the 'last completed cookie' into struct dma_chan - everyone
>   has this in their driver private channel data structure
> 
> - consolidate allocation of cookies to DMA descriptors
> 
> - common way to update 'last completed cookie' value
> 
> - standard way to implement tx_status callback and update the residue
> 
> - consolidate initialization of cookies
> 
> - update implementations differing from the majority of DMA engine drivers
>   to behave the same as the majority implementation in respect of cookies
> 
> What this means is that we get to the point where all DMA engine drivers
> will hand out cookie value '2' as the first, and incrementing cookie
> values up to INT_MAX, returning to cookie '1' as the next cookie.
> 
> Think of this patch series as round 1...  I am hoping over time that more
> code can be consolidated between the DMA engine drivers and end up with a
> consistent way to handle various common themes in DMA engine hardware
> (like physical channel<->peripheral request signal selection.)
> 
> Overall, the diffstat looks like this:
> 
>  arch/arm/include/asm/hardware/iop_adma.h |    2 -
>  drivers/dma/amba-pl08x.c                 |   38 ++++---------
>  drivers/dma/at_hdmac.c                   |   48 ++++------------
>  drivers/dma/at_hdmac_regs.h              |    2 -

For at_hdmac Atmel DMA driver:

Tested-by: Nicolas Ferre <nicolas.ferre@atmel.com>

Thanks a lot Russell.

Best regards,
-- 
Nicolas Ferre

^ permalink raw reply

* Re: [PATCH v2 0/9] DMA engine cookie handling cleanups
From: Russell King - ARM Linux @ 2012-03-13 12:31 UTC (permalink / raw)
  To: Vinod Koul
  Cc: Stephen Warren, Linus Walleij, Srinidhi Kasagar, Barry Song,
	Dan Williams, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1331628036.1727.22.camel@vkoul-udesk3>

On Tue, Mar 13, 2012 at 02:10:36PM +0530, Vinod Koul wrote:
> Please see if the below patch is the right fix for build failures in
> addition to one suggested by Jassi.

I'm not sure that Jassi's solution is correct - and I'm wondering whether
any of the DMA engine drivers do the right thing when transfers are
terminated.  Is it right for the DMA status function to return IN_PROGRESS
for a previously submitted cookie which has been terminated?

I can see two answers to that, both equally valid:

1. It allows you to find out exactly where the DMA engine got to before
   the transfer was terminated, and therefore recover from the termination
   if you wish to.

2. Returning in-progress when a cookie will never be completed is
   misleading, and could be misinterpreted by users of the tx_status
   function, especially if they are waiting for a particular transaction
   to complete.

Maybe we need to introduce a DMA_TERMINATED status?

> -------------------x-------------------------x----------------------
> 
> >From 949ff5b8d46b5e3435d21b2651ce3a2599208d44 Mon Sep 17 00:00:00 2001
> From: Vinod Koul <vinod.koul@linux.intel.com>
> Date: Tue, 13 Mar 2012 11:58:12 +0530
> Subject: [PATCH] dmaengine: fix for cookie changes and merge
> 
> Fixed trivial issues in drivers:
> 	drivers/dma/imx-sdma.c
> 	drivers/dma/intel_mid_dma.c
> 	drivers/dma/ioat/dma_v3.c
> 	drivers/dma/iop-adma.c
> 	drivers/dma/sirf-dma.c
> 	drivers/dma/timb_dma.c
> 
> Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
> ---
>  drivers/dma/imx-sdma.c      |    1 +
>  drivers/dma/intel_mid_dma.c |    1 +
>  drivers/dma/ioat/dma_v3.c   |    1 +
>  drivers/dma/iop-adma.c      |    1 +
>  drivers/dma/sirf-dma.c      |    2 ++
>  drivers/dma/timb_dma.c      |    6 +-----
>  6 files changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> index ccfc7c4..81f9d57 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -1127,6 +1127,7 @@ static void sdma_issue_pending(struct dma_chan *chan)
>  	struct sdma_engine *sdma = sdmac->sdma;
>  
>  	if (sdmac->status == DMA_IN_PROGRESS)
> +		sdma_enable_channel(sdma, sdmac->channel);
>  }
>  
>  #define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V1	34

This looks like a merge conflict resolution.  I don't see this being
caused by my patches as I haven't touched this function.

> diff --git a/drivers/dma/intel_mid_dma.c b/drivers/dma/intel_mid_dma.c
> index d599d96..2449812 100644
> --- a/drivers/dma/intel_mid_dma.c
> +++ b/drivers/dma/intel_mid_dma.c
> @@ -477,6 +477,7 @@ static enum dma_status intel_mid_dma_tx_status(struct dma_chan *chan,
>  						dma_cookie_t cookie,
>  						struct dma_tx_state *txstate)
>  {
> +	struct intel_mid_dma_chan *midc = to_intel_mid_dma_chan(chan);
>  	enum dma_status ret;
>  
>  	ret = dma_cookie_status(chan, cookie, txstate);

Ditto (my patches don't introduce new this new midc, nor do they remove
that line.)

> diff --git a/drivers/dma/ioat/dma_v3.c b/drivers/dma/ioat/dma_v3.c
> index 145eda2..2c4476c 100644
> --- a/drivers/dma/ioat/dma_v3.c
> +++ b/drivers/dma/ioat/dma_v3.c
> @@ -61,6 +61,7 @@
>  #include <linux/dmaengine.h>
>  #include <linux/dma-mapping.h>
>  #include <linux/prefetch.h>
> +#include "../dmaengine.h"
>  #include "registers.h"
>  #include "hw.h"
>  #include "dma.h"
> diff --git a/drivers/dma/iop-adma.c b/drivers/dma/iop-adma.c
> index 1f3a703..4499f88 100644
> --- a/drivers/dma/iop-adma.c
> +++ b/drivers/dma/iop-adma.c
> @@ -894,6 +894,7 @@ static enum dma_status iop_adma_status(struct dma_chan *chan,
>  					struct dma_tx_state *txstate)
>  {
>  	struct iop_adma_chan *iop_chan = to_iop_adma_chan(chan);
> +	int ret;

This was "enum dma_status ret;" before I accidentally removed it.  It
probably should be again, rather than an int.

>  
>  	ret = dma_cookie_status(chan, cookie, txstate);
>  	if (ret == DMA_SUCCESS)
> diff --git a/drivers/dma/sirf-dma.c b/drivers/dma/sirf-dma.c
> index a2cde85..45ba352 100644
> --- a/drivers/dma/sirf-dma.c
> +++ b/drivers/dma/sirf-dma.c
> @@ -18,6 +18,8 @@
>  #include <linux/of_platform.h>
>  #include <linux/sirfsoc_dma.h>
>  
> +#include "dmaengine.h"
> +
>  #define SIRFSOC_DMA_DESCRIPTORS                 16
>  #define SIRFSOC_DMA_CHANNELS                    16
>  

Hmm, guess that's what happens when old patches are brought forward and
things from the original series are forgotten...

> diff --git a/drivers/dma/timb_dma.c b/drivers/dma/timb_dma.c
> index 7805996..d408c22 100644
> --- a/drivers/dma/timb_dma.c
> +++ b/drivers/dma/timb_dma.c
> @@ -510,17 +510,13 @@ static void td_free_chan_resources(struct dma_chan *chan)
>  static enum dma_status td_tx_status(struct dma_chan *chan, dma_cookie_t cookie,
>  				    struct dma_tx_state *txstate)
>  {
> -	struct timb_dma_chan *td_chan =
> -		container_of(chan, struct timb_dma_chan, chan);
>  	enum dma_status ret;
>  
>  	dev_dbg(chan2dev(chan), "%s: Entry\n", __func__);
>  
>  	ret = dma_cookie_status(chan, cookie, txstate);
>  
> -	dev_dbg(chan2dev(chan),
> -		"%s: exit, ret: %d, last_complete: %d, last_used: %d\n",
> -		__func__, ret, last_complete, last_used);
> +	dev_dbg(chan2dev(chan), "%s: exit, ret: %d\n", 	__func__, ret);
>  
>  	return ret;
>  }
> -- 
> 1.7.0.4
> 
> 
> 
> 
> -- 
> ~Vinod
> 

^ permalink raw reply

* Re: [PATCH v3 4/4] powerpc: Board support for GE IMP3A
From: Martyn Welch @ 2012-03-13 12:32 UTC (permalink / raw)
  To: Linus Walleij
  Cc: linux-kernel, Wim Van Sebroeck, Uwe Kleine-König,
	linuxppc-dev
In-Reply-To: <CACRpkdZv84PKts4jFscsNcOq6rggZXSYzu3CBe8NFDTPwsd1aw@mail.gmail.com>

On 13/03/12 11:51, Linus Walleij wrote:
> On Mon, Mar 12, 2012 at 6:13 PM, Martyn Welch <martyn.welch@ge.com> wrote:
> 
>> Initial board support for the GE IMP3A, a 3U compactPCI card with a p2020
>> processor.
> (...)
>> +++ b/arch/powerpc/configs/ge_imp3a_defconfig
>> @@ -0,0 +1,257 @@
>> +CONFIG_PPC_85xx=y
>> +CONFIG_SMP=y
>> +CONFIG_NR_CPUS=2
>> +CONFIG_EXPERIMENTAL=y
>> +CONFIG_SYSVIPC=y
>> +CONFIG_POSIX_MQUEUE=y
>> +CONFIG_BSD_PROCESS_ACCT=y
>> +CONFIG_BSD_PROCESS_ACCT_V3=y
>> +CONFIG_SPARSE_IRQ=y
> 
> This habit of changing a lot of defconfig stuff in a patch dealing with other
> stuff is alien in the ARM world. Especially when changing a horde of stuff
> that has nothing to do with the patch subject.
> 

This is adding the defconfig, it's support for a new board:

diff --git a/arch/powerpc/configs/ge_imp3a_defconfig
b/arch/powerpc/configs/ge_imp3a_defconfig
new file mode 100644
index 0000000..f8c51a4
--- /dev/null
+++ b/arch/powerpc/configs/ge_imp3a_defconfig


> But I don't really know how PPC does these things so who am I to
> speak ...
> 
> BTW: doesn't the "make saveconfig" reduce defconfigs on PPC?
> Paging Uwe on this.

This is the output of "make savedefconfig".

Martyn

-- 
Martyn Welch (Lead Software Engineer)  | Registered in England and Wales
GE Intelligent Platforms               | (3828642) at 100 Barbirolli Square
T +44(0)1327322748                     | Manchester, M2 3AB
E martyn.welch@ge.com                  | VAT:GB 927559189

^ permalink raw reply

* RE: [PATCH v3] powerpc/srio: Fix the compile errors when building with 64bit
From: Liu Gang-B34182 @ 2012-03-13 12:44 UTC (permalink / raw)
  To: 'linuxppc-dev@lists.ozlabs.org',
	'galak@kernel.crashing.org',
	'Alexandre.Bounine@idt.com'
  Cc: Li Yang-R58472, Xie Shaohui-B21989, Zang Roy-R61911,
	'linux-kernel@vger.kernel.org',
	'paul.gortmaker@windriver.com',
	'akpm@linux-foundation.org'
In-Reply-To: <1331280638-23525-1-git-send-email-Gang.Liu@freescale.com>

Hi, Kumar,
Can you help to apply the two patches?

powerpc/srio: Fix the compile errors when building with 64bit
http://patchwork.ozlabs.org/patch/145687/

powerpc/srio: Fix the relocation errors when building with 64bit
http://patchwork.ozlabs.org/patch/144829/

Thanks a lot.

Best Regards,

Liu Gang

^ permalink raw reply

* Re: [PATCH v3 4/4] powerpc: Board support for GE IMP3A
From: Linus Walleij @ 2012-03-13 13:03 UTC (permalink / raw)
  To: Martyn Welch
  Cc: linux-kernel, Wim Van Sebroeck, Uwe Kleine-König,
	linuxppc-dev
In-Reply-To: <4F5F3E79.5030809@ge.com>

2012/3/13 Martyn Welch <martyn.welch@ge.com>:
> On 13/03/12 11:51, Linus Walleij wrote:

>> This habit of changing a lot of defconfig stuff in a patch dealing with other
>> stuff is alien in the ARM world. Especially when changing a horde of stuff
>> that has nothing to do with the patch subject.
>>
>
> This is adding the defconfig, it's support for a new board:

Ah I was confused by thinking the patch series was all about GPIO.
Sorry...

Yours,
Linus Walleij

^ permalink raw reply

* Re: [PATCH v2 0/9] DMA engine cookie handling cleanups
From: Vinod Koul @ 2012-03-13 14:38 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Stephen Warren, Linus Walleij, Srinidhi Kasagar, Barry Song,
	Dan Williams, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20120313123121.GA20133@n2100.arm.linux.org.uk>

On Tue, 2012-03-13 at 12:31 +0000, Russell King - ARM Linux wrote:
> On Tue, Mar 13, 2012 at 02:10:36PM +0530, Vinod Koul wrote:
> > Please see if the below patch is the right fix for build failures in
> > addition to one suggested by Jassi.
> 
> I'm not sure that Jassi's solution is correct - and I'm wondering whether
> any of the DMA engine drivers do the right thing when transfers are
> terminated.  Is it right for the DMA status function to return IN_PROGRESS
> for a previously submitted cookie which has been terminated?
> 
> I can see two answers to that, both equally valid:
> 
> 1. It allows you to find out exactly where the DMA engine got to before
>    the transfer was terminated, and therefore recover from the termination
>    if you wish to.
> 
> 2. Returning in-progress when a cookie will never be completed is
>    misleading, and could be misinterpreted by users of the tx_status
>    function, especially if they are waiting for a particular transaction
>    to complete.
> 
> Maybe we need to introduce a DMA_TERMINATED status?
I would agree with you that DMA_TERMINATED seems to be correct option.
IN_PROGRESS would certainly confuse... 
I will drop Jassi's fix from this branch. Care to send the patch?
> 
> > -------------------x-------------------------x----------------------
> > 
> > >From 949ff5b8d46b5e3435d21b2651ce3a2599208d44 Mon Sep 17 00:00:00 2001
> > From: Vinod Koul <vinod.koul@linux.intel.com>
> > Date: Tue, 13 Mar 2012 11:58:12 +0530
> > Subject: [PATCH] dmaengine: fix for cookie changes and merge
> > 
> > Fixed trivial issues in drivers:
> > 	drivers/dma/imx-sdma.c
> > 	drivers/dma/intel_mid_dma.c
> > 	drivers/dma/ioat/dma_v3.c
> > 	drivers/dma/iop-adma.c
> > 	drivers/dma/sirf-dma.c
> > 	drivers/dma/timb_dma.c
> > 
> > Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
> > ---
> >  drivers/dma/imx-sdma.c      |    1 +
> >  drivers/dma/intel_mid_dma.c |    1 +
> >  drivers/dma/ioat/dma_v3.c   |    1 +
> >  drivers/dma/iop-adma.c      |    1 +
> >  drivers/dma/sirf-dma.c      |    2 ++
> >  drivers/dma/timb_dma.c      |    6 +-----
> >  6 files changed, 7 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> > index ccfc7c4..81f9d57 100644
> > --- a/drivers/dma/imx-sdma.c
> > +++ b/drivers/dma/imx-sdma.c
> > @@ -1127,6 +1127,7 @@ static void sdma_issue_pending(struct dma_chan *chan)
> >  	struct sdma_engine *sdma = sdmac->sdma;
> >  
> >  	if (sdmac->status == DMA_IN_PROGRESS)
> > +		sdma_enable_channel(sdma, sdmac->channel);
> >  }
> >  
> >  #define SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V1	34
> 
> This looks like a merge conflict resolution.  I don't see this being
> caused by my patches as I haven't touched this function.
> 
> > diff --git a/drivers/dma/intel_mid_dma.c b/drivers/dma/intel_mid_dma.c
> > index d599d96..2449812 100644
> > --- a/drivers/dma/intel_mid_dma.c
> > +++ b/drivers/dma/intel_mid_dma.c
> > @@ -477,6 +477,7 @@ static enum dma_status intel_mid_dma_tx_status(struct dma_chan *chan,
> >  						dma_cookie_t cookie,
> >  						struct dma_tx_state *txstate)
> >  {
> > +	struct intel_mid_dma_chan *midc = to_intel_mid_dma_chan(chan);
> >  	enum dma_status ret;
> >  
> >  	ret = dma_cookie_status(chan, cookie, txstate);
> 
> Ditto (my patches don't introduce new this new midc, nor do they remove
> that line.)
> 
> > diff --git a/drivers/dma/ioat/dma_v3.c b/drivers/dma/ioat/dma_v3.c
> > index 145eda2..2c4476c 100644
> > --- a/drivers/dma/ioat/dma_v3.c
> > +++ b/drivers/dma/ioat/dma_v3.c
> > @@ -61,6 +61,7 @@
> >  #include <linux/dmaengine.h>
> >  #include <linux/dma-mapping.h>
> >  #include <linux/prefetch.h>
> > +#include "../dmaengine.h"
> >  #include "registers.h"
> >  #include "hw.h"
> >  #include "dma.h"
> > diff --git a/drivers/dma/iop-adma.c b/drivers/dma/iop-adma.c
> > index 1f3a703..4499f88 100644
> > --- a/drivers/dma/iop-adma.c
> > +++ b/drivers/dma/iop-adma.c
> > @@ -894,6 +894,7 @@ static enum dma_status iop_adma_status(struct dma_chan *chan,
> >  					struct dma_tx_state *txstate)
> >  {
> >  	struct iop_adma_chan *iop_chan = to_iop_adma_chan(chan);
> > +	int ret;
> 
> This was "enum dma_status ret;" before I accidentally removed it.  It
> probably should be again, rather than an int.
> 
> >  
> >  	ret = dma_cookie_status(chan, cookie, txstate);
> >  	if (ret == DMA_SUCCESS)
> > diff --git a/drivers/dma/sirf-dma.c b/drivers/dma/sirf-dma.c
> > index a2cde85..45ba352 100644
> > --- a/drivers/dma/sirf-dma.c
> > +++ b/drivers/dma/sirf-dma.c
> > @@ -18,6 +18,8 @@
> >  #include <linux/of_platform.h>
> >  #include <linux/sirfsoc_dma.h>
> >  
> > +#include "dmaengine.h"
> > +
> >  #define SIRFSOC_DMA_DESCRIPTORS                 16
> >  #define SIRFSOC_DMA_CHANNELS                    16
> >  
> 
> Hmm, guess that's what happens when old patches are brought forward and
> things from the original series are forgotten...
> 
> > diff --git a/drivers/dma/timb_dma.c b/drivers/dma/timb_dma.c
> > index 7805996..d408c22 100644
> > --- a/drivers/dma/timb_dma.c
> > +++ b/drivers/dma/timb_dma.c
> > @@ -510,17 +510,13 @@ static void td_free_chan_resources(struct dma_chan *chan)
> >  static enum dma_status td_tx_status(struct dma_chan *chan, dma_cookie_t cookie,
> >  				    struct dma_tx_state *txstate)
> >  {
> > -	struct timb_dma_chan *td_chan =
> > -		container_of(chan, struct timb_dma_chan, chan);
> >  	enum dma_status ret;
> >  
> >  	dev_dbg(chan2dev(chan), "%s: Entry\n", __func__);
> >  
> >  	ret = dma_cookie_status(chan, cookie, txstate);
> >  
> > -	dev_dbg(chan2dev(chan),
> > -		"%s: exit, ret: %d, last_complete: %d, last_used: %d\n",
> > -		__func__, ret, last_complete, last_used);
> > +	dev_dbg(chan2dev(chan), "%s: exit, ret: %d\n", 	__func__, ret);
> >  
> >  	return ret;
> >  }
> > -- 
> > 1.7.0.4
> > 
> > 
> > 
> > 
> > -- 
> > ~Vinod
> > 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


-- 
~Vinod

^ permalink raw reply

* Re: linux-next: manual merge of the devicetree tree with the powerpc tree
From: Grant Likely @ 2012-03-13 18:26 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Gavin Shan, linux-kernel, linux-next, Paul Mackerras,
	linuxppc-dev
In-Reply-To: <20120313160100.c8cc3fd2b3d1f485ef7e7954@canb.auug.org.au>

On Tue, 13 Mar 2012 16:01:00 +1100, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Grant,
> 
> Today's linux-next merge of the devicetree tree got a conflict in
> include/linux/of.h between commit eb740b5f3e65 ("powerpc/eeh: Introduce
> EEH device") from the powerpc tree and commit 0f22dd395fc4 ("of: Only
> compile OF_DYNAMIC on PowerPC pseries and iseries") from the devicetree
> tree.
> 
> Just context changes.  I fixed it up (see below) and can carry the fix as
> necessary.
> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> 
> diff --cc include/linux/of.h
> index bdb1c07,533603e..0000000
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@@ -75,14 -72,10 +75,17 @@@ struct of_phandle_args 
>   	uint32_t args[MAX_PHANDLE_ARGS];
>   };
>   
>  +#if defined(CONFIG_EEH)
>  +static inline struct eeh_dev *of_node_to_eeh_dev(struct device_node *dn)
>  +{
>  +	return dn->edev;
>  +}
>  +#endif

Ben, What is this?  I don't want the eeh_dev pointer in struct device_node.  Up to
now we've avoided putting any reverse references into device_nodes.  For everything
else we use a reverse lookup, particularly for devices, to avoid growing the
device_node for each new type of lookup.

g.

^ permalink raw reply

* Re: linux-next: manual merge of the devicetree tree with the powerpc tree
From: Gavin Shan @ 2012-03-14  1:53 UTC (permalink / raw)
  To: Grant Likely, benh
  Cc: linuxppc-dev, linux-next, Paul Mackerras, linux-kernel,
	Stephen Rothwell
In-Reply-To: <20120313182612.0546D3E053B@localhost>

Hi Grant,

> > 
> > Today's linux-next merge of the devicetree tree got a conflict in
> > include/linux/of.h between commit eb740b5f3e65 ("powerpc/eeh: Introduce
> > EEH device") from the powerpc tree and commit 0f22dd395fc4 ("of: Only
> > compile OF_DYNAMIC on PowerPC pseries and iseries") from the devicetree
> > tree.
> > 
> > Just context changes.  I fixed it up (see below) and can carry the fix as
> > necessary.
> > -- 
> > Cheers,
> > Stephen Rothwell                    sfr@canb.auug.org.au
> > 
> > diff --cc include/linux/of.h
> > index bdb1c07,533603e..0000000
> > --- a/include/linux/of.h
> > +++ b/include/linux/of.h
> > @@@ -75,14 -72,10 +75,17 @@@ struct of_phandle_args 
> >   	uint32_t args[MAX_PHANDLE_ARGS];
> >   };
> >   
> >  +#if defined(CONFIG_EEH)
> >  +static inline struct eeh_dev *of_node_to_eeh_dev(struct device_node *dn)
> >  +{
> >  +	return dn->edev;
> >  +}
> >  +#endif
> 
> Ben, What is this?  I don't want the eeh_dev pointer in struct device_node.  Up to
> now we've avoided putting any reverse references into device_nodes.  For everything
> else we use a reverse lookup, particularly for devices, to avoid growing the
> device_node for each new type of lookup.
> 

It's used to trace the EEH device. When EEH (Enhanced Error Hanlding) is enabled,
EEH device will be created against PCI sensitive OF node to trace the EEH state
accordingly. Since you don't want see this in struct device_node, we have to change
struct eeh_dev for a little bit to so that all struct eeh_dev instances will form
a global list and we can search eeh_dev according to the given device_node through
the global list. 

I don't know the policy or rule here for much. I think we can have 2 options.

1. Keep the code as being, and fix it later.
2. Fix it now.

Thanks,
Gavin

^ permalink raw reply

* How to make a memory region to be cache disabled ? Cpu is mpc82XX or mpc83XX.
From: hellohello @ 2012-03-14  2:37 UTC (permalink / raw)
  To: linuxppc-dev

SG93IHRvIG1ha2UgYSBtZW1vcnkgcmVnaW9uICB0byBiZSBjYWNoZSBkaXNhYmxlZCBpbiBsaW51
eD8NCkknbSBwb3J0aW5nIG1wYzgzWFggZnJvbSB2eHdvcmtzIHRvIGxpbnV4LiBOb3cgbWVldCBh
IHF1ZXN0aW9uOiBDcHUgdXNlIGEgbWVtb3J5IHJlZ2lvbiAoR1BDTSBtb2RlIG9mIGJ1cykgIHRv
IGFjY2VzcyBwZXJpcGhlcmFscywgd2UgbmVlZCB0aGlzIG1lbW9yeSB0byBiZSBjYWNoZSBkaXNh
YmxlZC4NCkxpbnV4IEtlcm5lbCBpcyAyLjYuMjUuDQpUaGFua3MgdmVyeSBtdWNoIGZvciBhbnkg
aGludCEgDQoNCg==

^ permalink raw reply

* Re: How to make a memory region to be cache disabled ? Cpu is mpc82XX or mpc83XX.
From: Vineeth @ 2012-03-14  4:34 UTC (permalink / raw)
  To: hellohello; +Cc: linuxppc-dev
In-Reply-To: <EF9AEBBC0B9942B48CE5D29FF5CE814B@sfdomain.com>

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

You can disable the cache with the help of TLBs. See where it is creating
TLBs for the memory regions for that processor.

On Wed, Mar 14, 2012 at 8:07 AM, hellohello <hellohello008@163.com> wrote:

> How to make a memory region  to be cache disabled in linux?
> I'm porting mpc83XX from vxworks to linux. Now meet a question: Cpu use a
> memory region (GPCM mode of bus)  to access peripherals, we need this
> memory to be cache disabled.
> Linux Kernel is 2.6.25.
> Thanks very much for any hint!
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>

[-- Attachment #2: Type: text/html, Size: 1052 bytes --]

^ permalink raw reply

* Re: How to make a memory region to be cache disabled ? Cpu is mpc82XX or mpc83XX.
From: tiejun.chen @ 2012-03-14  5:09 UTC (permalink / raw)
  To: hellohello; +Cc: linuxppc-dev
In-Reply-To: <EF9AEBBC0B9942B48CE5D29FF5CE814B@sfdomain.com>

hellohello wrote:
> How to make a memory region  to be cache disabled in linux?
> I'm porting mpc83XX from vxworks to linux. Now meet a question: Cpu use a memory region (GPCM mode of bus)  to access peripherals, we need this memory to be cache disabled.
> Linux Kernel is 2.6.25.
> Thanks very much for any hint! 

ioremap() is fine enough since it always set I|G as TLB entry attribute.

Tiejun

^ permalink raw reply

* [PATCH] powerpc/hvc_udbg: Don't crash when udbg_putc is NULL
From: Benjamin Herrenschmidt @ 2012-03-14  7:38 UTC (permalink / raw)
  To: linuxppc-dev

Also while at it, add some help text indicating why you shouldn't
enable that driver under normal circumstances

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
 drivers/tty/hvc/Kconfig    |    4 ++++
 drivers/tty/hvc/hvc_udbg.c |    8 +++++++-
 2 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/drivers/tty/hvc/Kconfig b/drivers/tty/hvc/Kconfig
index 8ea7f07..48cb8d3 100644
--- a/drivers/tty/hvc/Kconfig
+++ b/drivers/tty/hvc/Kconfig
@@ -71,6 +71,10 @@ config HVC_UDBG
        depends on PPC && EXPERIMENTAL
        select HVC_DRIVER
        default n
+       help
+         This is meant to be used during HW bring up or debugging when
+	 no other console mechanism exist but udbg, to get you a quick
+	 console for userspace. Do NOT enable in production kernels. 
 
 config HVC_DCC
        bool "ARM JTAG DCC console"
diff --git a/drivers/tty/hvc/hvc_udbg.c b/drivers/tty/hvc/hvc_udbg.c
index b0957e6..2259c6e 100644
--- a/drivers/tty/hvc/hvc_udbg.c
+++ b/drivers/tty/hvc/hvc_udbg.c
@@ -36,7 +36,7 @@ static int hvc_udbg_put(uint32_t vtermno, const char *buf, int count)
 {
 	int i;
 
-	for (i = 0; i < count; i++)
+	for (i = 0; i < count && udbg_putc; i++)
 		udbg_putc(buf[i]);
 
 	return i;
@@ -67,6 +67,9 @@ static int __init hvc_udbg_init(void)
 {
 	struct hvc_struct *hp;
 
+	if (!udbg_putc)
+		return -ENODEV;
+
 	BUG_ON(hvc_udbg_dev);
 
 	hp = hvc_alloc(0, NO_IRQ, &hvc_udbg_ops, 16);
@@ -88,6 +91,9 @@ module_exit(hvc_udbg_exit);
 
 static int __init hvc_udbg_console_init(void)
 {
+	if (!udbg_putc)
+		return -ENODEV;
+
 	hvc_instantiate(0, 0, &hvc_udbg_ops);
 	add_preferred_console("hvc", 0, NULL);
 
-- 
1.7.9

^ permalink raw reply related

* Re: linux-next: manual merge of the devicetree tree with the powerpc tree
From: Benjamin Herrenschmidt @ 2012-03-14  8:29 UTC (permalink / raw)
  To: Gavin Shan
  Cc: Stephen Rothwell, linux-kernel, linux-next, Paul Mackerras,
	linuxppc-dev
In-Reply-To: <20120314015356.GA4028@shangw>

On Wed, 2012-03-14 at 09:53 +0800, Gavin Shan wrote:
> >  +#if defined(CONFIG_EEH)
> > >  +static inline struct eeh_dev *of_node_to_eeh_dev(struct device_node *dn)
> > >  +{
> > >  +  return dn->edev;
> > >  +}
> > >  +#endif
> > 
> > Ben, What is this?  I don't want the eeh_dev pointer in struct device_node.  Up to
> > now we've avoided putting any reverse references into device_nodes.  For everything
> > else we use a reverse lookup, particularly for devices, to avoid growing the
> > device_node for each new type of lookup.
> > 
> 
> It's used to trace the EEH device. When EEH (Enhanced Error Hanlding) is enabled,
> EEH device will be created against PCI sensitive OF node to trace the EEH state
> accordingly. Since you don't want see this in struct device_node, we have to change
> struct eeh_dev for a little bit to so that all struct eeh_dev instances will form
> a global list and we can search eeh_dev according to the given device_node through
> the global list. 
> 
> I don't know the policy or rule here for much. I think we can have 2 options.
> 
> 1. Keep the code as being, and fix it later.
> 2. Fix it now. 

My bad, it's a mis-review, I thought it was still in pci_dn, I din't
catch Gavin moving it to device-node.

Yes, Gavin, we need to do something else, a chained list we walk or
something like that. For the "fast path" which is when we have a pci_dev
around, we can either add it to dev_archdata or hijack the pci-dev
platform_data (I don't think anything uses it, Grant, do you know of
anything ?)

The patches are already in -next and I won't rebase, so we need to fix
it on top of the existing patches. Gavin, can you make a patch that puts
it back into pci_dn to begin with, then we can contemplate what better
long term solution we have ?

Cheers,
Ben.

^ permalink raw reply

* [PATCH 2/4] powerpc/85xx: add P1020UTM-PC platform support
From: Chang-Ming.Huang @ 2012-03-14  9:08 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: Jerry Huang
In-Reply-To: <1331716110-25545-1-git-send-email-Chang-Ming.Huang@freescale.com>

From: Jerry Huang <Chang-Ming.Huang@freescale.com>

The p1020utm-pc has the similar feature as the p1020rdb.
Therefore, p1020utm-pc use the same platform file as the p1/p2 rdb board.
Overview of P1020UTM-PC platform:
        - DDR3 1GB
        - NOR flash 32MB
        - I2C EEPROM 256Kb
        - eTSEC1 (RGMII PHY Atheros AR8021)
        - eTSEC2 (SGMII PHY Vitesse VSC8221)
        - eTSEC3 (RGMII PHY Atheros AR8021)
        - SDHC
        - 2 USB ports
        - PCIe (Lane1 to dual SATA controller)

Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
---
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c |   23 +++++++++++++++++++++++
 1 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index 5c6334a..e121d80 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -179,6 +179,7 @@ machine_arch_initcall(p2020_rdb, mpc85xxrdb_publish_pci_device);
 machine_arch_initcall(p1020_rdb, mpc85xxrdb_publish_pci_device);
 machine_arch_initcall(p1020_rdb_pc, mpc85xxrdb_publish_pci_device);
 machine_arch_initcall(p1020_mbg_pc, mpc85xxrdb_publish_pci_device);
+machine_arch_initcall(p1020_utm_pc, mpc85xxrdb_publish_pci_device);
 machine_arch_initcall(p2020_rdb_pc, mpc85xxrdb_publish_pci_device);
 machine_arch_initcall(p1024_rdb, mpc85xxrdb_publish_pci_device);
 machine_arch_initcall(p1021_rdb_pc, mpc85xxrdb_publish_pci_device);
@@ -201,6 +202,7 @@ machine_device_initcall(p2020_rdb, mpc85xxrdb_publish_devices);
 machine_device_initcall(p1020_rdb, mpc85xxrdb_publish_devices);
 machine_device_initcall(p1020_rdb_pc, mpc85xxrdb_publish_devices);
 machine_device_initcall(p1020_mbg_pc, mpc85xxrdb_publish_devices);
+machine_device_initcall(p1020_utm_pc, mpc85xxrdb_publish_devices);
 machine_device_initcall(p2020_rdb_pc, mpc85xxrdb_publish_devices);
 machine_device_initcall(p1024_rdb, mpc85xxrdb_publish_devices);
 machine_device_initcall(p1021_rdb_pc, mpc85xxrdb_publish_devices);
@@ -269,6 +271,13 @@ static int __init p1020_mbg_pc_probe(void)
 	return of_flat_dt_is_compatible(root, "fsl,P1020MBG-PC");
 }
 
+static int __init p1020_utm_pc_probe(void)
+{
+	unsigned long root = of_get_flat_dt_root();
+
+	return of_flat_dt_is_compatible(root, "fsl,P1020UTM-PC");
+}
+
 define_machine(p2020_rdb) {
 	.name			= "P2020 RDB",
 	.probe			= p2020_rdb_probe,
@@ -380,3 +389,17 @@ define_machine(p1020_mbg_pc) {
 	.calibrate_decr		= generic_calibrate_decr,
 	.progress		= udbg_progress,
 };
+
+define_machine(p1020_utm_pc) {
+	.name			= "P1020 UTM-PC",
+	.probe			= p1020_utm_pc_probe,
+	.setup_arch		= mpc85xx_rdb_setup_arch,
+	.init_IRQ		= mpc85xx_rdb_pic_init,
+#ifdef CONFIG_PCI
+	.pcibios_fixup_bus	= fsl_pcibios_fixup_bus,
+#endif
+	.get_irq		= mpic_get_irq,
+	.restart		= fsl_rstcr_restart,
+	.calibrate_decr		= generic_calibrate_decr,
+	.progress		= udbg_progress,
+};
-- 
1.7.5.4

^ permalink raw reply related

* [PATCH 3/4] powerpc/85xx: add the P1020MBG-PC DTS support
From: Chang-Ming.Huang @ 2012-03-14  9:08 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: Jerry Huang
In-Reply-To: <1331716110-25545-2-git-send-email-Chang-Ming.Huang@freescale.com>

From: Jerry Huang <Chang-Ming.Huang@freescale.com>

Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
---
 arch/powerpc/boot/dts/p1020mbg-pc.dtsi    |  153 +++++++++++++++++++++++++++++
 arch/powerpc/boot/dts/p1020mbg-pc_32b.dts |   89 +++++++++++++++++
 arch/powerpc/boot/dts/p1020mbg-pc_36b.dts |   89 +++++++++++++++++
 3 files changed, 331 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/p1020mbg-pc.dtsi
 create mode 100644 arch/powerpc/boot/dts/p1020mbg-pc_32b.dts
 create mode 100644 arch/powerpc/boot/dts/p1020mbg-pc_36b.dts

diff --git a/arch/powerpc/boot/dts/p1020mbg-pc.dtsi b/arch/powerpc/boot/dts/p1020mbg-pc.dtsi
new file mode 100644
index 0000000..dc0f0dd
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1020mbg-pc.dtsi
@@ -0,0 +1,153 @@
+/*
+ * P1020 MBG-PC Device Tree Source stub (no addresses or top-level ranges)
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *     * Redistributions of source code must retain the above copyright
+ *       notice, this list of conditions and the following disclaimer.
+ *     * Redistributions in binary form must reproduce the above copyright
+ *       notice, this list of conditions and the following disclaimer in the
+ *       documentation and/or other materials provided with the distribution.
+ *     * Neither the name of Freescale Semiconductor nor the
+ *       names of its contributors may be used to endorse or promote products
+ *       derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&lbc {
+	nor@0,0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "cfi-flash";
+		reg = <0x0 0x0 0x4000000>;
+		bank-width = <2>;
+		device-width = <1>;
+
+		partition@0 {
+			/* 128KB for DTB Image */
+			reg = <0x0 0x00020000>;
+			label = "NOR (RO) DTB Image";
+			read-only;
+		};
+
+		partition@20000 {
+			/* 3.875 MB for Linux Kernel Image */
+			reg = <0x00020000 0x003e0000>;
+			label = "NOR (RO) Linux Kernel Image";
+			read-only;
+		};
+
+		partition@400000 {
+			/* 58MB for Root file System */
+			reg = <0x00400000 0x03a00000>;
+			label = "NOR (RW) Root File System";
+		};
+
+		partition@3e00000 {
+			/* This location must not be altered  */
+			/* 1M for Vitesse 7385 Switch firmware */
+			reg = <0x3e00000 0x00100000>;
+			label = "NOR (RO) Vitesse-7385 Firmware";
+			read-only;
+		};
+
+		partition@3f00000 {
+			/* This location must not be altered  */
+			/* 512KB for u-boot Bootloader Image */
+			/* 512KB for u-boot Environment Variables */
+			reg = <0x03f00000 0x00100000>;
+			label = "NOR (RO) U-Boot Image";
+			read-only;
+		};
+	};
+
+	L2switch@2,0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "vitesse-7385";
+		reg = <0x2 0x0 0x20000>;
+	};
+};
+
+&soc {
+	i2c@3000 {
+		rtc@68 {
+			compatible = "dallas,ds1339";
+			reg = <0x68>;
+		};
+	};
+
+	mdio@24000 {
+		phy0: ethernet-phy@0 {
+			interrupts = <3 1 0 0>;
+			reg = <0x0>;
+		};
+		phy1: ethernet-phy@1 {
+			interrupts = <2 1 0 0>;
+			reg = <0x1>;
+		};
+	};
+
+	mdio@25000 {
+		tbi1: tbi-phy@11 {
+			reg = <0x11>;
+			device_type = "tbi-phy";
+		};
+	};
+
+	mdio@26000 {
+		tbi2: tbi-phy@11 {
+			reg = <0x11>;
+			device_type = "tbi-phy";
+		};
+	};
+
+	enet0: ethernet@b0000 {
+		fixed-link = <1 1 1000 0 0>;
+		phy-connection-type = "rgmii-id";
+	};
+
+	enet1: ethernet@b1000 {
+		phy-handle = <&phy0>;
+		tbi-handle = <&tbi1>;
+		phy-connection-type = "sgmii";
+	};
+
+	enet2: ethernet@b2000 {
+		phy-handle = <&phy1>;
+		phy-connection-type = "rgmii-id";
+	};
+
+	usb@22000 {
+		phy_type = "ulpi";
+	};
+
+	/* USB2 is shared with localbus, so it must be disabled
+	   by default. We can't put 'status = "disabled";' here
+	   since U-Boot doesn't clear the status property when
+	   it enables USB2. OTOH, U-Boot does create a new node
+	   when there isn't any. So, just comment it out.
+	*/
+	usb@23000 {
+		status = "disabled";
+		phy_type = "ulpi";
+	};
+};
diff --git a/arch/powerpc/boot/dts/p1020mbg-pc_32b.dts b/arch/powerpc/boot/dts/p1020mbg-pc_32b.dts
new file mode 100644
index 0000000..ab8f076
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1020mbg-pc_32b.dts
@@ -0,0 +1,89 @@
+/*
+ * P1020 MBG-PC Device Tree Source (32-bit address map)
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *     * Redistributions of source code must retain the above copyright
+ *       notice, this list of conditions and the following disclaimer.
+ *     * Redistributions in binary form must reproduce the above copyright
+ *       notice, this list of conditions and the following disclaimer in the
+ *       documentation and/or other materials provided with the distribution.
+ *     * Neither the name of Freescale Semiconductor nor the
+ *       names of its contributors may be used to endorse or promote products
+ *       derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/p1020si-pre.dtsi"
+/ {
+	model = "fsl,P1020MBG-PC";
+	compatible = "fsl,P1020MBG-PC";
+
+	memory {
+		device_type = "memory";
+	};
+
+	lbc: localbus@ffe05000 {
+		reg = <0x0 0xffe05000 0x0 0x1000>;
+
+		/* NOR and L2 switch */
+		ranges = <0x0 0x0 0x0 0xec000000 0x04000000
+			  0x1 0x0 0x0 0xffa00000 0x00040000
+			  0x2 0x0 0x0 0xffb00000 0x00020000>;
+	};
+
+	soc: soc@ffe00000 {
+		ranges = <0x0 0x0 0xffe00000 0x100000>;
+	};
+
+	pci0: pcie@ffe09000 {
+		reg = <0x0 0xffe09000 0x0 0x1000>;
+		ranges = <0x2000000 0x0 0xe0000000 0x0 0xa0000000 0x0 0x20000000
+			  0x1000000 0x0 0x00000000 0x0 0xffc10000 0x0 0x10000>;
+		pcie@0 {
+			ranges = <0x2000000 0x0 0xe0000000
+				  0x2000000 0x0 0xe0000000
+				  0x0 0x20000000
+
+				  0x1000000 0x0 0x0
+				  0x1000000 0x0 0x0
+				  0x0 0x100000>;
+		};
+	};
+
+	pci1: pcie@ffe0a000 {
+		reg = <0x0 0xffe0a000 0x0 0x1000>;
+		ranges = <0x2000000 0x0 0xe0000000 0x0 0x80000000 0x0 0x20000000
+			  0x1000000 0x0 0x00000000 0x0 0xffc00000 0x0 0x10000>;
+		pcie@0 {
+			ranges = <0x2000000 0x0 0xe0000000
+				  0x2000000 0x0 0xe0000000
+				  0x0 0x20000000
+
+				  0x1000000 0x0 0x0
+				  0x1000000 0x0 0x0
+				  0x0 0x100000>;
+		};
+	};
+};
+
+/include/ "p1020mbg-pc.dtsi"
+/include/ "fsl/p1020si-post.dtsi"
diff --git a/arch/powerpc/boot/dts/p1020mbg-pc_36b.dts b/arch/powerpc/boot/dts/p1020mbg-pc_36b.dts
new file mode 100644
index 0000000..9e9f401
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1020mbg-pc_36b.dts
@@ -0,0 +1,89 @@
+/*
+ * P1020 MBG-PC Device Tree Source (36-bit address map)
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *     * Redistributions of source code must retain the above copyright
+ *       notice, this list of conditions and the following disclaimer.
+ *     * Redistributions in binary form must reproduce the above copyright
+ *       notice, this list of conditions and the following disclaimer in the
+ *       documentation and/or other materials provided with the distribution.
+ *     * Neither the name of Freescale Semiconductor nor the
+ *       names of its contributors may be used to endorse or promote products
+ *       derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/p1020si-pre.dtsi"
+/ {
+	model = "fsl,P1020MBG-PC";
+	compatible = "fsl,P1020MBG-PC";
+
+	memory {
+		device_type = "memory";
+	};
+
+	lbc: localbus@fffe05000 {
+		reg = <0xf 0xffe05000 0x0 0x1000>;
+
+		/* NOR and L2 switch */
+		ranges = <0x0 0x0 0xf 0xec000000 0x04000000
+			  0x1 0x0 0xf 0xffa00000 0x00040000
+			  0x2 0x0 0xf 0xffb00000 0x00020000>;
+	};
+
+	soc: soc@fffe00000 {
+		ranges = <0x0 0xf 0xffe00000 0x100000>;
+	};
+
+	pci0: pcie@fffe09000 {
+		reg = <0xf 0xffe09000 0x0 0x1000>;
+		ranges = <0x2000000 0x0 0xe0000000 0xc 0x20000000 0x0 0x20000000
+			  0x1000000 0x0 0x00000000 0xf 0xffc10000 0x0 0x10000>;
+		pcie@0 {
+			ranges = <0x2000000 0x0 0xe0000000
+				  0x2000000 0x0 0xe0000000
+				  0x0 0x20000000
+
+				  0x1000000 0x0 0x0
+				  0x1000000 0x0 0x0
+				  0x0 0x100000>;
+		};
+	};
+
+	pci1: pcie@fffe0a000 {
+		reg = <0xf 0xffe0a000 0 0x1000>;
+		ranges = <0x2000000 0x0 0xe0000000 0xc 0x00000000 0x0 0x20000000
+			  0x1000000 0x0 0x00000000 0xf 0xffc00000 0x0 0x10000>;
+		pcie@0 {
+			ranges = <0x2000000 0x0 0xe0000000
+				  0x2000000 0x0 0xe0000000
+				  0x0 0x20000000
+
+				  0x1000000 0x0 0x0
+				  0x1000000 0x0 0x0
+				  0x0 0x100000>;
+		};
+	};
+};
+
+/include/ "p1020mbg-pc.dtsi"
+/include/ "fsl/p1020si-post.dtsi"
-- 
1.7.5.4

^ permalink raw reply related

* [PATCH 1/4] powerpc/85xx: add P1020MBG-PC platform support
From: Chang-Ming.Huang @ 2012-03-14  9:08 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: Jerry Huang

From: Jerry Huang <Chang-Ming.Huang@freescale.com>

The p1020mbg-pc has the similar feature as the p1020rdb.
Therefore, p1020mbg-pc use the same platform file as the p1/p2 rdb board.
Overview of P1020MBG-PC platform:
        - DDR3 2GB
        - NOR flash 64MB
        - I2C EEPROM 256Kb
        - eTSEC1 (RGMII PHY) connected to VSC7385 L2 switch
        - eTSEC2 (SGMII PHY)
        - eTSEC3 (RGMII PHY)
        - SDHC
        - 2 USB ports
        - 4 TDM ports
        - PCIe (Lane1 to dual SATA controller)

Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
---
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c |   23 +++++++++++++++++++++++
 1 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index 6de10bf..5c6334a 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
@@ -178,6 +178,7 @@ static int __init mpc85xxrdb_publish_pci_device(void)
 machine_arch_initcall(p2020_rdb, mpc85xxrdb_publish_pci_device);
 machine_arch_initcall(p1020_rdb, mpc85xxrdb_publish_pci_device);
 machine_arch_initcall(p1020_rdb_pc, mpc85xxrdb_publish_pci_device);
+machine_arch_initcall(p1020_mbg_pc, mpc85xxrdb_publish_pci_device);
 machine_arch_initcall(p2020_rdb_pc, mpc85xxrdb_publish_pci_device);
 machine_arch_initcall(p1024_rdb, mpc85xxrdb_publish_pci_device);
 machine_arch_initcall(p1021_rdb_pc, mpc85xxrdb_publish_pci_device);
@@ -199,6 +200,7 @@ static int __init mpc85xxrdb_publish_devices(void)
 machine_device_initcall(p2020_rdb, mpc85xxrdb_publish_devices);
 machine_device_initcall(p1020_rdb, mpc85xxrdb_publish_devices);
 machine_device_initcall(p1020_rdb_pc, mpc85xxrdb_publish_devices);
+machine_device_initcall(p1020_mbg_pc, mpc85xxrdb_publish_devices);
 machine_device_initcall(p2020_rdb_pc, mpc85xxrdb_publish_devices);
 machine_device_initcall(p1024_rdb, mpc85xxrdb_publish_devices);
 machine_device_initcall(p1021_rdb_pc, mpc85xxrdb_publish_devices);
@@ -260,6 +262,13 @@ static int __init p1025_rdb_probe(void)
 	return of_flat_dt_is_compatible(root, "fsl,P1025RDB");
 }
 
+static int __init p1020_mbg_pc_probe(void)
+{
+	unsigned long root = of_get_flat_dt_root();
+
+	return of_flat_dt_is_compatible(root, "fsl,P1020MBG-PC");
+}
+
 define_machine(p2020_rdb) {
 	.name			= "P2020 RDB",
 	.probe			= p2020_rdb_probe,
@@ -357,3 +366,17 @@ define_machine(p1025_rdb) {
 	.calibrate_decr		= generic_calibrate_decr,
 	.progress		= udbg_progress,
 };
+
+define_machine(p1020_mbg_pc) {
+	.name			= "P1020 MBG-PC",
+	.probe			= p1020_mbg_pc_probe,
+	.setup_arch		= mpc85xx_rdb_setup_arch,
+	.init_IRQ		= mpc85xx_rdb_pic_init,
+#ifdef CONFIG_PCI
+	.pcibios_fixup_bus	= fsl_pcibios_fixup_bus,
+#endif
+	.get_irq		= mpic_get_irq,
+	.restart		= fsl_rstcr_restart,
+	.calibrate_decr		= generic_calibrate_decr,
+	.progress		= udbg_progress,
+};
-- 
1.7.5.4

^ permalink raw reply related

* [PATCH 4/4] powerpc/85xx: add the P1020UTM-PC DTS support
From: Chang-Ming.Huang @ 2012-03-14  9:08 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: Jerry Huang
In-Reply-To: <1331716110-25545-3-git-send-email-Chang-Ming.Huang@freescale.com>

From: Jerry Huang <Chang-Ming.Huang@freescale.com>

Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
---
 arch/powerpc/boot/dts/p1020utm-pc.dtsi    |  142 +++++++++++++++++++++++++++++
 arch/powerpc/boot/dts/p1020utm-pc_32b.dts |   89 ++++++++++++++++++
 arch/powerpc/boot/dts/p1020utm-pc_36b.dts |   89 ++++++++++++++++++
 3 files changed, 320 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/p1020utm-pc.dtsi
 create mode 100644 arch/powerpc/boot/dts/p1020utm-pc_32b.dts
 create mode 100644 arch/powerpc/boot/dts/p1020utm-pc_36b.dts

diff --git a/arch/powerpc/boot/dts/p1020utm-pc.dtsi b/arch/powerpc/boot/dts/p1020utm-pc.dtsi
new file mode 100644
index 0000000..71557a6
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1020utm-pc.dtsi
@@ -0,0 +1,142 @@
+/*
+ * P1020 UTM-PC Device Tree Source stub (no addresses or top-level ranges)
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *     * Redistributions of source code must retain the above copyright
+ *       notice, this list of conditions and the following disclaimer.
+ *     * Redistributions in binary form must reproduce the above copyright
+ *       notice, this list of conditions and the following disclaimer in the
+ *       documentation and/or other materials provided with the distribution.
+ *     * Neither the name of Freescale Semiconductor nor the
+ *       names of its contributors may be used to endorse or promote products
+ *       derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+&lbc {
+	nor@0,0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "cfi-flash";
+		reg = <0x0 0x0 0x2000000>;
+		bank-width = <2>;
+		device-width = <1>;
+
+		partition@0 {
+			/* 256KB for DTB Image */
+			reg = <0x0 0x00040000>;
+			label = "NOR (RO) DTB Image";
+			read-only;
+		};
+
+		partition@40000 {
+			/* 3.75 MB for Linux Kernel Image */
+			reg = <0x00040000 0x003c0000>;
+			label = "NOR (RO) Linux Kernel Image";
+			read-only;
+		};
+
+		partition@400000 {
+			/* 27MB for Root file System */
+			reg = <0x00400000 0x01b00000>;
+			label = "NOR (RW) Root File System";
+		};
+
+		partition@1f00000 {
+			/* This location must not be altered  */
+			/* 512KB for u-boot Bootloader Image */
+			/* 512KB for u-boot Environment Variables */
+			reg = <0x01f00000 0x00100000>;
+			label = "NOR (RO) U-Boot Image";
+			read-only;
+		};
+	};
+};
+
+&soc {
+	i2c@3000 {
+		rtc@68 {
+			compatible = "dallas,ds1339";
+			reg = <0x68>;
+		};
+	};
+
+	mdio@24000 {
+		phy0: ethernet-phy@0 {
+			interrupts = <3 1 0 0>;
+			reg = <0x0>;
+		};
+		phy1: ethernet-phy@1 {
+			interrupts = <2 1 0 0>;
+			reg = <0x1>;
+		};
+		phy2: ethernet-phy@2 {
+			interrupts = <1 1 0 0>;
+			reg = <0x2>;
+		};
+	};
+
+	mdio@25000 {
+		tbi1: tbi-phy@11 {
+			reg = <0x11>;
+			device_type = "tbi-phy";
+		};
+	};
+
+	mdio@26000 {
+		tbi2: tbi-phy@11 {
+			reg = <0x11>;
+			device_type = "tbi-phy";
+		};
+	};
+
+	enet0: ethernet@b0000 {
+		phy-handle = <&phy2>;
+		phy-connection-type = "rgmii-id";
+	};
+
+	enet1: ethernet@b1000 {
+		phy-handle = <&phy0>;
+		tbi-handle = <&tbi1>;
+		phy-connection-type = "sgmii";
+	};
+
+	enet2: ethernet@b2000 {
+		phy-handle = <&phy1>;
+		phy-connection-type = "rgmii-id";
+	};
+
+	usb@22000 {
+		phy_type = "ulpi";
+	};
+
+	/* USB2 is shared with localbus, so it must be disabled
+	   by default. We can't put 'status = "disabled";' here
+	   since U-Boot doesn't clear the status property when
+	   it enables USB2. OTOH, U-Boot does create a new node
+	   when there isn't any. So, just comment it out.
+	*/
+	usb@23000 {
+		status = "disabled";
+		phy_type = "ulpi";
+	};
+};
diff --git a/arch/powerpc/boot/dts/p1020utm-pc_32b.dts b/arch/powerpc/boot/dts/p1020utm-pc_32b.dts
new file mode 100644
index 0000000..4bfdd89
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1020utm-pc_32b.dts
@@ -0,0 +1,89 @@
+/*
+ * P1020 UTM-PC Device Tree Source (32-bit address map)
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *     * Redistributions of source code must retain the above copyright
+ *       notice, this list of conditions and the following disclaimer.
+ *     * Redistributions in binary form must reproduce the above copyright
+ *       notice, this list of conditions and the following disclaimer in the
+ *       documentation and/or other materials provided with the distribution.
+ *     * Neither the name of Freescale Semiconductor nor the
+ *       names of its contributors may be used to endorse or promote products
+ *       derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/p1020si-pre.dtsi"
+/ {
+	model = "fsl,P1020UTM-PC";
+	compatible = "fsl,P1020UTM-PC";
+
+	memory {
+		device_type = "memory";
+	};
+
+	lbc: localbus@ffe05000 {
+		reg = <0x0 0xffe05000 0x0 0x1000>;
+
+		/* NOR */
+		ranges = <0x0 0x0 0x0 0xec000000 0x02000000
+			  0x1 0x0 0x0 0xffa00000 0x00040000
+			  0x2 0x0 0x0 0xffb00000 0x00020000>;
+	};
+
+	soc: soc@ffe00000 {
+		ranges = <0x0 0x0 0xffe00000 0x100000>;
+	};
+
+	pci0: pcie@ffe09000 {
+		reg = <0x0 0xffe09000 0x0 0x1000>;
+		ranges = <0x2000000 0x0 0xe0000000 0x0 0xa0000000 0x0 0x20000000
+			  0x1000000 0x0 0x00000000 0x0 0xffc10000 0x0 0x10000>;
+		pcie@0 {
+			ranges = <0x2000000 0x0 0xe0000000
+				  0x2000000 0x0 0xe0000000
+				  0x0 0x20000000
+
+				  0x1000000 0x0 0x0
+				  0x1000000 0x0 0x0
+				  0x0 0x100000>;
+		};
+	};
+
+	pci1: pcie@ffe0a000 {
+		reg = <0x0 0xffe0a000 0x0 0x1000>;
+		ranges = <0x2000000 0x0 0xe0000000 0x0 0x80000000 0x0 0x20000000
+			  0x1000000 0x0 0x00000000 0x0 0xffc00000 0x0 0x10000>;
+		pcie@0 {
+			ranges = <0x2000000 0x0 0xe0000000
+				  0x2000000 0x0 0xe0000000
+				  0x0 0x20000000
+
+				  0x1000000 0x0 0x0
+				  0x1000000 0x0 0x0
+				  0x0 0x100000>;
+		};
+	};
+};
+
+/include/ "p1020utm-pc.dtsi"
+/include/ "fsl/p1020si-post.dtsi"
diff --git a/arch/powerpc/boot/dts/p1020utm-pc_36b.dts b/arch/powerpc/boot/dts/p1020utm-pc_36b.dts
new file mode 100644
index 0000000..abec535
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1020utm-pc_36b.dts
@@ -0,0 +1,89 @@
+/*
+ * P1020 UTM-PC Device Tree Source (36-bit address map)
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *     * Redistributions of source code must retain the above copyright
+ *       notice, this list of conditions and the following disclaimer.
+ *     * Redistributions in binary form must reproduce the above copyright
+ *       notice, this list of conditions and the following disclaimer in the
+ *       documentation and/or other materials provided with the distribution.
+ *     * Neither the name of Freescale Semiconductor nor the
+ *       names of its contributors may be used to endorse or promote products
+ *       derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ "fsl/p1020si-pre.dtsi"
+/ {
+	model = "fsl,P1020UTM-PC";
+	compatible = "fsl,P1020UTM-PC";
+
+	memory {
+		device_type = "memory";
+	};
+
+	lbc: localbus@fffe05000 {
+		reg = <0xf 0xffe05000 0x0 0x1000>;
+
+		/* NOR */
+		ranges = <0x0 0x0 0xf 0xec000000 0x02000000
+			  0x1 0x0 0xf 0xffa00000 0x00040000
+			  0x2 0x0 0xf 0xffb00000 0x00020000>;
+	};
+
+	soc: soc@fffe00000 {
+		ranges = <0x0 0xf 0xffe00000 0x100000>;
+	};
+
+	pci0: pcie@fffe09000 {
+		reg = <0xf 0xffe09000 0x0 0x1000>;
+		ranges = <0x2000000 0x0 0xe0000000 0xc 0x20000000 0x0 0x20000000
+			  0x1000000 0x0 0x00000000 0xf 0xffc10000 0x0 0x10000>;
+		pcie@0 {
+			ranges = <0x2000000 0x0 0xe0000000
+				  0x2000000 0x0 0xe0000000
+				  0x0 0x20000000
+
+				  0x1000000 0x0 0x0
+				  0x1000000 0x0 0x0
+				  0x0 0x100000>;
+		};
+	};
+
+	pci1: pcie@fffe0a000 {
+		reg = <0xf 0xffe0a000 0 0x1000>;
+		ranges = <0x2000000 0x0 0xe0000000 0xc 0x00000000 0x0 0x20000000
+			  0x1000000 0x0 0x00000000 0xf 0xffc00000 0x0 0x10000>;
+		pcie@0 {
+			ranges = <0x2000000 0x0 0xe0000000
+				  0x2000000 0x0 0xe0000000
+				  0x0 0x20000000
+
+				  0x1000000 0x0 0x0
+				  0x1000000 0x0 0x0
+				  0x0 0x100000>;
+		};
+	};
+};
+
+/include/ "p1020utm-pc.dtsi"
+/include/ "fsl/p1020si-post.dtsi"
-- 
1.7.5.4

^ permalink raw reply related

* Re: linux-next: manual merge of the devicetree tree with the powerpc tree
From: Gavin Shan @ 2012-03-14  9:02 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: Stephen Rothwell, linux-kernel, linux-next, Paul Mackerras,
	linuxppc-dev
In-Reply-To: <1331713762.3105.121.camel@pasglop>

>> >  +#if defined(CONFIG_EEH)
>> > >  +static inline struct eeh_dev *of_node_to_eeh_dev(struct device_node *dn)
>> > >  +{
>> > >  +  return dn->edev;
>> > >  +}
>> > >  +#endif
>> > 
>> > Ben, What is this?  I don't want the eeh_dev pointer in struct device_node.  Up to
>> > now we've avoided putting any reverse references into device_nodes.  For everything
>> > else we use a reverse lookup, particularly for devices, to avoid growing the
>> > device_node for each new type of lookup.
>> > 
>> 
>> It's used to trace the EEH device. When EEH (Enhanced Error Hanlding) is enabled,
>> EEH device will be created against PCI sensitive OF node to trace the EEH state
>> accordingly. Since you don't want see this in struct device_node, we have to change
>> struct eeh_dev for a little bit to so that all struct eeh_dev instances will form
>> a global list and we can search eeh_dev according to the given device_node through
>> the global list. 
>> 
>> I don't know the policy or rule here for much. I think we can have 2 options.
>> 
>> 1. Keep the code as being, and fix it later.
>> 2. Fix it now. 
>
>My bad, it's a mis-review, I thought it was still in pci_dn, I din't
>catch Gavin moving it to device-node.
>
>Yes, Gavin, we need to do something else, a chained list we walk or
>something like that. For the "fast path" which is when we have a pci_dev
>around, we can either add it to dev_archdata or hijack the pci-dev
>platform_data (I don't think anything uses it, Grant, do you know of
>anything ?)
>

Yes, Ben. I'll come up another patch on top of -next. It's supposed
to introduce global list for newly created eeh_dev and retrieve
the corresponding eeh_dev according to the given device_node through
it.

>The patches are already in -next and I won't rebase, so we need to fix
>it on top of the existing patches. Gavin, can you make a patch that puts
>it back into pci_dn to begin with, then we can contemplate what better
>long term solution we have ?
>

I've had something more in my private git tree regarding this. I'll
talk with you for your comments ;-)

Thanks,
Gavin

^ permalink raw reply

* [PATCH 2/9 v2] powerpc/mpc85xxcds: Fix PCI I/O space resource of PCI bridge
From: Zhao Chenhui @ 2012-03-14 10:15 UTC (permalink / raw)
  To: linuxppc-dev

From: chenhui zhao <chenhui.zhao@freescale.com>

There is a PCI bridge(Tsi310) between the MPC8548 and a VIA
southbridge chip.

The bootloader sets the PCI bridge to open a window from 0x0000
to 0x1fff on the PCI I/O space. But the kernel can't set the I/O
resource. In the routine pci_read_bridge_io(), if the base which
is read from PCI_IO_BASE is equal to zero, the routine don't set
the I/O resource of the child bus.

To allow the legacy I/O space on the VIA southbridge to be accessed,
use the fixup to fix the PCI I/O space of the PCI bridge.

Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
Changes for v2:
 * merge patch 1/9 and 2/9
 * rename PCI_DEVICE_ID_IBM_PCIX_BRIDGE to PCI_DEVICE_ID_IDT_TSI310

 arch/powerpc/platforms/85xx/mpc85xx_cds.c |   31 +++++++++++++++++++++++++++-
 1 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/mpc85xx_cds.c b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
index 02d97e3..766b215 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_cds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
@@ -3,7 +3,7 @@
  *
  * Maintained by Kumar Gala (see MAINTAINERS for contact information)
  *
- * Copyright 2005 Freescale Semiconductor Inc.
+ * Copyright 2005, 2011-2012 Freescale Semiconductor Inc.
  *
  * 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
@@ -158,6 +158,33 @@ DECLARE_PCI_FIXUP_EARLY(0x1957, 0x3fff, skip_fake_bridge);
 DECLARE_PCI_FIXUP_EARLY(0x3fff, 0x1957, skip_fake_bridge);
 DECLARE_PCI_FIXUP_EARLY(0xff3f, 0x5719, skip_fake_bridge);
 
+#define PCI_DEVICE_ID_IDT_TSI310	0x01a7
+
+/*
+ * Fix Tsi310 PCI-X bridge resource.
+ * Force the bridge to open a window from 0x0000-0x1fff in PCI I/O space.
+ * This allows legacy I/O(i8259, etc) on the VIA southbridge to be accessed.
+ */
+void mpc85xx_cds_fixup_bus(struct pci_bus *bus)
+{
+	struct pci_dev *dev = bus->self;
+	struct resource *res = bus->resource[0];
+
+	if (dev != NULL &&
+	    dev->vendor == PCI_VENDOR_ID_IBM &&
+	    dev->device == PCI_DEVICE_ID_IDT_TSI310) {
+		if (res) {
+			res->start = 0;
+			res->end   = 0x1fff;
+			res->flags = IORESOURCE_IO;
+			pr_info("mpc85xx_cds: PCI bridge resource fixup applied\n");
+			pr_info("mpc85xx_cds: %pR\n", res);
+		}
+	}
+
+	fsl_pcibios_fixup_bus(bus);
+}
+
 #ifdef CONFIG_PPC_I8259
 static void mpc85xx_8259_cascade_handler(unsigned int irq,
 					 struct irq_desc *desc)
@@ -322,7 +349,7 @@ define_machine(mpc85xx_cds) {
 	.get_irq	= mpic_get_irq,
 #ifdef CONFIG_PCI
 	.restart	= mpc85xx_cds_restart,
-	.pcibios_fixup_bus	= fsl_pcibios_fixup_bus,
+	.pcibios_fixup_bus	= mpc85xx_cds_fixup_bus,
 #else
 	.restart	= fsl_rstcr_restart,
 #endif
-- 
1.6.4.1

^ permalink raw reply related

* [PATCH 2/4] fsl_pci: Add a workaround for PCI 5 errata
From: Zhao Chenhui @ 2012-03-14 10:15 UTC (permalink / raw)
  To: linuxppc-dev

From: chenhui zhao <chenhui.zhao@freescale.com>

Issue:
As a master, the PCI IP block can combine a memory write to the last PCI double
word (4 bytes) of a cacheline with a 4 byte memory write to the first PCI double
word of the subsequent cacheline. This affects 32-bit PCI target devices that
blindly assert STOP on memory-write transactions, without detecting that the
data beat being transferred is the last data beat of the transaction. It can
cause a hang. PCI-X operation is not affected by this erratum.

Workaround:
Setting the bit MDS in the PCI Bus Function Register will disable the combining
of crossing cacheline boundary requests into one burst transaction. Therefore,
it can prevent the errata scenario from occurring.

This errata exists in MPC8543, MPC8543E, MPC8545, MPC8545E, MPC8547, MPC8547E,
MPC8548 and MPC8548E. Refer to PCI 5 in MPC8548 errata document.

Signed-off-by: Gong Chen <g.chen@freescale.com>
Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
Changes for v2:
 * add 8543, 8545 and 8547

 arch/powerpc/include/asm/mpc85xx.h |    1 +
 arch/powerpc/sysdev/fsl_pci.c      |   23 +++++++++++++++++++++++
 2 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/include/asm/mpc85xx.h b/arch/powerpc/include/asm/mpc85xx.h
index 451777c..fafca9f 100644
--- a/arch/powerpc/include/asm/mpc85xx.h
+++ b/arch/powerpc/include/asm/mpc85xx.h
@@ -37,6 +37,7 @@
 #define SVR_8544_E	0x803C01
 #define SVR_8545	0x803102
 #define SVR_8545_E	0x803902
+#define SVR_8547	0x803101
 #define SVR_8547_E	0x803901
 #define SVR_8548	0x803100
 #define SVR_8548_E	0x803900
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 6073288..f595117 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -31,6 +31,7 @@
 #include <asm/prom.h>
 #include <asm/pci-bridge.h>
 #include <asm/machdep.h>
+#include <asm/mpc85xx.h>
 #include <sysdev/fsl_soc.h>
 #include <sysdev/fsl_pci.h>
 
@@ -426,6 +427,7 @@ int __init fsl_add_bridge(struct device_node *dev, int is_primary)
 	struct resource rsrc;
 	const int *bus_range;
 	u8 progif;
+	u16 temp;
 
 	if (!of_device_is_available(dev)) {
 		pr_warning("%s: disabled\n", dev->full_name);
@@ -476,6 +478,27 @@ int __init fsl_add_bridge(struct device_node *dev, int is_primary)
 			PPC_INDIRECT_TYPE_SURPRESS_PRIMARY_BUS;
 		if (fsl_pcie_check_link(hose))
 			hose->indirect_type |= PPC_INDIRECT_TYPE_NO_PCIE_LINK;
+	} else {
+		/*
+		 * Set PBFR(PCI Bus Function Register)[10] = 1 to
+		 * disable the combining of crossing cacheline
+		 * boundary requests into one burst transaction.
+		 * PCI-X operation is not affected.
+		 * Fix erratum PCI 5 on MPC8548
+		 */
+#define PCI_BUS_FUNCTION 0x44
+#define PCI_BUS_FUNCTION_MDS 0x400	/* Master disable streaming */
+		if ((fsl_svr_is(SVR_8543) || fsl_svr_is(SVR_8543_E) ||
+		     fsl_svr_is(SVR_8545) || fsl_svr_is(SVR_8545_E) ||
+		     fsl_svr_is(SVR_8547) || fsl_svr_is(SVR_8547_E) ||
+		     fsl_svr_is(SVR_8548) || fsl_svr_is(SVR_8548_E)) &&
+		    !early_find_capability(hose, 0, 0, PCI_CAP_ID_PCIX)) {
+			early_read_config_word(hose, 0, 0,
+						PCI_BUS_FUNCTION, &temp);
+			temp |= PCI_BUS_FUNCTION_MDS;
+			early_write_config_word(hose, 0, 0,
+						PCI_BUS_FUNCTION, temp);
+		}
 	}
 
 	printk(KERN_INFO "Found FSL PCI host bridge at 0x%016llx. "
-- 
1.6.4.1

^ permalink raw reply related

* [PATCH 3/4 v2] fsl_pci: Add a workaround for PCI 6 errata
From: Zhao Chenhui @ 2012-03-14 10:16 UTC (permalink / raw)
  To: linuxppc-dev

From: chenhui zhao <chenhui.zhao@freescale.com>

Issue:
The register bits ERR_DR[OWMSV] and ERR_DR[ORMSV] can erroneously set and
may trigger an interrupt if capturing and reporting of these events are enabled.

Workaround:
Disable OWMSV, ORMSV error capture and disable OWMSV, ORMSV error reporting.
Do not affect the functionality of the controller when the checking is disabled.

This errata exists in MPC8543, MPC8543E, MPC8545, MPC8545E, MPC8547, MPC8547E,
MPC8548 and MPC8548E. Refer to PCI 6 in MPC8548 errata document.

Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
Changes for v2:
 * add 8543, 8545 and 8547

 arch/powerpc/sysdev/fsl_pci.c |   19 ++++++++++++++
 arch/powerpc/sysdev/fsl_pci.h |   53 ++++++++++++++++++++++++++++++++++-------
 2 files changed, 63 insertions(+), 9 deletions(-)

diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index f595117..e925c1b 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -156,6 +156,25 @@ static void __init setup_pci_atmu(struct pci_controller *hose,
 	    return;
 	}
 
+	/*
+	 * PCI/PCI-X erroneous error detection
+	 * Fix erratum PCI 6 on MPC8548
+	 */
+#define OWMSV 0x10
+#define ORMSV 0x08
+	if ((fsl_svr_is(SVR_8543) || fsl_svr_is(SVR_8543_E) ||
+	     fsl_svr_is(SVR_8545) || fsl_svr_is(SVR_8545_E) ||
+	     fsl_svr_is(SVR_8547) || fsl_svr_is(SVR_8547_E) ||
+	     fsl_svr_is(SVR_8548) || fsl_svr_is(SVR_8548_E)) &&
+	     fsl_svr_older_than(2, 1)) {
+		if (of_device_is_compatible(hose->dn, "fsl,mpc8540-pci")) {
+			/* disable OWMSV and ORMSV error capture */
+			setbits32(&pci->pcier.pecdr, OWMSV | ORMSV);
+			/* disable OWMSV and ORMSV error reporting */
+			clrbits32(&pci->pcier.peer, OWMSV | ORMSV);
+		}
+	}
+
 	/* Disable all windows (except powar0 since it's ignored) */
 	for(i = 1; i < 5; i++)
 		out_be32(&pci->pow[i].powar, 0);
diff --git a/arch/powerpc/sysdev/fsl_pci.h b/arch/powerpc/sysdev/fsl_pci.h
index a39ed5c..f09a78d 100644
--- a/arch/powerpc/sysdev/fsl_pci.h
+++ b/arch/powerpc/sysdev/fsl_pci.h
@@ -43,6 +43,45 @@ struct pci_inbound_window_regs {
 	u8	res2[12];
 };
 
+/* PCI Error Management Registers */
+struct pci_err_regs {
+	/*   0x.e00 - PCI Error Detect Register */
+	__be32	pedr;
+	/*   0x.e04 - PCI Error Capture Disable Register */
+	__be32	pecdr;
+	/*   0x.e08 - PCI Error Interrupt Enable Register */
+	__be32	peer;
+	/*   0x.e0c - PCI Error Attributes Capture Register */
+	__be32	peattrcr;
+	/*   0x.e10 - PCI Error Address Capture Register */
+	__be32	peaddrcr;
+	/*   0x.e14 - PCI Error Extended Address Capture Register */
+	__be32	peextaddrcr;
+	/*   0x.e18 - PCI Error Data Low Capture Register */
+	__be32	pedlcr;
+	/*   0x.e1c - PCI Error Data High Capture Register */
+	__be32	pedhcr;
+	/*   0x.e20 - PCI Gasket Timer Register */
+	__be32	gas_timr;
+	u8	res21[4];
+};
+
+/* PCI Express Error Management Registers */
+struct pcie_err_regs {
+	/*  0x.e00 - PCI/PCIE error detect register */
+	__be32	pex_err_dr;
+	u8	res21[4];
+	/*  0x.e08 - PCI/PCIE error interrupt enable register */
+	__be32	pex_err_en;
+	u8	res22[4];
+	/*  0x.e10 - PCI/PCIE error disable register */
+	__be32	pex_err_disr;
+	u8	res23[12];
+	/*  0x.e20 - PCI/PCIE error capture status register */
+	__be32	pex_err_cap_stat;
+	u8	res24[4];
+};
+
 /* PCI/PCI Express IO block registers for 85xx/86xx */
 struct ccsr_pci {
 	__be32	config_addr;		/* 0x.000 - PCI/PCIE Configuration Address Register */
@@ -73,15 +112,11 @@ struct ccsr_pci {
  * define an inbound window base extended address register.
  */
 	struct pci_inbound_window_regs piw[4];
-
-	__be32	pex_err_dr;		/* 0x.e00 - PCI/PCIE error detect register */
-	u8	res21[4];
-	__be32	pex_err_en;		/* 0x.e08 - PCI/PCIE error interrupt enable register */
-	u8	res22[4];
-	__be32	pex_err_disr;		/* 0x.e10 - PCI/PCIE error disable register */
-	u8	res23[12];
-	__be32	pex_err_cap_stat;	/* 0x.e20 - PCI/PCIE error capture status register */
-	u8	res24[4];
+/* PCI/PCI Express Error Management Registers */
+	union {
+		struct pci_err_regs pcier;
+		struct pcie_err_regs pexer;
+	};
 	__be32	pex_err_cap_r0;		/* 0x.e28 - PCIE error capture register 0 */
 	__be32	pex_err_cap_r1;		/* 0x.e2c - PCIE error capture register 0 */
 	__be32	pex_err_cap_r2;		/* 0x.e30 - PCIE error capture register 0 */
-- 
1.6.4.1

^ permalink raw reply related

* [PATCH 0/2] Kdump support for PPC_47x
From: Suzuki K. Poulose @ 2012-03-14 10:22 UTC (permalink / raw)
  To: jwboyer; +Cc: linuxppc-dev

The following series implements Kexec/Kdump support for
PPC_47x based platforms. Doesn't support SMP yet.

I have tested these patches on simics simulator for ppc476.

---

Suzuki K. Poulose (2):
      [47x] Enable CRASH_DUMP
      [47x] Kernel support for KEXEC


 arch/powerpc/Kconfig          |    4 -
 arch/powerpc/kernel/misc_32.S |  197 ++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 193 insertions(+), 8 deletions(-)

-- 
Suzuki K. Poulose

^ 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