* Re: [PATCH 1/2] powerpc/85xx: add ngPIXIS FPGA device tree node to the P1022DS board
From: Kumar Gala @ 2010-10-07 5:27 UTC (permalink / raw)
To: Timur Tabi; +Cc: Linuxppc-dev list, York Sun
In-Reply-To: <1284057597-17126-1-git-send-email-timur@freescale.com>
On Sep 9, 2010, at 1:39 PM, Timur Tabi wrote:
> The device tree for Freescale's P1022DS reference board is missing the =
node
> for the ngPIXIS FPGA.
>=20
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
> arch/powerpc/boot/dts/p1022ds.dts | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
>=20
> diff --git a/arch/powerpc/boot/dts/p1022ds.dts =
b/arch/powerpc/boot/dts/p1022ds.dts
> index 8bcb10b..e61b42d 100644
> --- a/arch/powerpc/boot/dts/p1022ds.dts
> +++ b/arch/powerpc/boot/dts/p1022ds.dts
> @@ -148,6 +148,15 @@
> label =3D "reserved-nand";
> };
> };
> +
> + board-control@3,0 {
> + #address-cells =3D <1>;
> + #size-cells =3D <1>;
these aren't need if we don't have a child node.
> + compatible =3D "fsl,fpga-pixis";
lets make this "fsl,p1022ds-pixis"
> + reg =3D <3 0 0x30>;
> + interrupt-parent =3D <&mpic>;
> + interrupts =3D <8 8>;
what do we think about adding a comment about what this interrupt is for
> + };
> };
>=20
> soc@fffe00000 {
> --=20
> 1.7.2.2
>=20
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 1/2] [v2] powerpc: export ppc_proc_freq and ppc_tb_freq as GPL symbols
From: Kumar Gala @ 2010-10-07 5:59 UTC (permalink / raw)
To: Timur Tabi; +Cc: linux-watchdog, linuxppc-dev
In-Reply-To: <1284999822-24753-1-git-send-email-timur@freescale.com>
On Sep 20, 2010, at 11:23 AM, Timur Tabi wrote:
> Export the global variable 'ppc_tb_freq', so that modules (like the =
Book-E
> watchdog driver) can use it. To maintain consistency, ppc_proc_freq =
is changed
> to a GPL-only export. This is okay, because any module that needs =
this symbol
> should be an actual Linux driver, which must be GPL-licensed.
>=20
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>=20
> This export is necessary for the Book-E watchdog driver to be compiled =
as a
> module.
>=20
> arch/powerpc/kernel/time.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH 1/4] powerpc/kexec: make masking/disabling interrupts generic
From: Kumar Gala @ 2010-10-07 6:00 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1284677906-23787-1-git-send-email-msm@freescale.com>
On Sep 16, 2010, at 5:58 PM, Matthew McClintock wrote:
> Right now just the kexec crash pathway turns turns off the
> interrupts. Pull that out and make a generic version for
> use elsewhere
>
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> arch/powerpc/include/asm/kexec.h | 1 +
> arch/powerpc/kernel/crash.c | 13 +------------
> arch/powerpc/kernel/machine_kexec.c | 24 ++++++++++++++++++++++++
> arch/powerpc/kernel/machine_kexec_32.c | 4 ++++
> 4 files changed, 30 insertions(+), 12 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH 3/4] powerpc/85xx: Minor fixups for kexec on 85xx
From: Kumar Gala @ 2010-10-07 6:00 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1284677906-23787-3-git-send-email-msm@freescale.com>
On Sep 16, 2010, at 5:58 PM, Matthew McClintock wrote:
> Make kexec_down_cpus atmoic since it will be incremented by all
> cores as they are coming down
>
> Remove duplicate calls to mpc85xx_smp_kexec_down, now it's called
> by the crash and normal kexec pathway only once
>
> Increase the timeout to wait for other cores to shutdown
>
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> arch/powerpc/platforms/85xx/smp.c | 24 +++++++++++-------------
> 1 files changed, 11 insertions(+), 13 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH][v3] mpc8308_p1m: support for MPC8308 P1M board
From: Kumar Gala @ 2010-10-07 6:00 UTC (permalink / raw)
To: Ilya Yanok; +Cc: scottwood, vlad, linuxppc-dev, wd, dzu
In-Reply-To: <1283990116-29441-1-git-send-email-yanok@emcraft.com>
On Sep 8, 2010, at 6:55 PM, Ilya Yanok wrote:
> This patch adds support for MPC8308 P1M board.
> Supported devices:
> DUART
> Dual Ethernet
> NOR flash
> Both I2C controllers
> USB in peripheral mode
> PCI Express
>=20
> Signed-off-by: Ilya Yanok <yanok@emcraft.com>
> ---
>=20
> Changed 'compatible' entry for 'cpld' node to "denx,mpc8308_p1m-cpld"
>=20
> arch/powerpc/boot/dts/mpc8308_p1m.dts | 332 =
+++++++++++++++++++++++++++++
> arch/powerpc/platforms/83xx/Kconfig | 4 +-
> arch/powerpc/platforms/83xx/mpc830x_rdb.c | 3 +-
> 3 files changed, 336 insertions(+), 3 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/mpc8308_p1m.dts
applied to next
- k=
^ permalink raw reply
* Re: [PATCH] powerpc/fsl-pci: Fix MSI support on 83xx platforms
From: Kumar Gala @ 2010-10-07 6:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, wd, yanok
In-Reply-To: <1280995347-6550-1-git-send-email-galak@kernel.crashing.org>
On Aug 5, 2010, at 3:02 AM, Kumar Gala wrote:
> The following commit broke 83xx because it assumed the 83xx platforms
> exposed the "IMMR" address in BAR0 like the 85xx/86xx/QoriQ devices =
do:
>=20
> commit 3da34aae03d498ee62f75aa7467de93cce3030fd
> Author: Kumar Gala <galak@kernel.crashing.org>
> Date: Tue May 12 15:51:56 2009 -0500
>=20
> powerpc/fsl: Support unique MSI addresses per PCIe Root Complex
>=20
> However that is not true, so we have to search through the inbound
> window settings on 83xx to find which one matches the IMMR address to
> determine its PCI address.
>=20
> Reported-by: Ilya Yanok <yanok@emcraft.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/sysdev/fsl_msi.c | 9 +++----
> arch/powerpc/sysdev/fsl_pci.c | 43 =
++++++++++++++++++++++++++++++++++++++++-
> arch/powerpc/sysdev/fsl_pci.h | 1 +
> 3 files changed, 47 insertions(+), 6 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH 2/4] powerpc/85xx: Remove call to mpic_teardown_this_cpu in kexec
From: Kumar Gala @ 2010-10-07 6:00 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1284677906-23787-2-git-send-email-msm@freescale.com>
On Sep 16, 2010, at 5:58 PM, Matthew McClintock wrote:
> We no longer need to call this explicitly as a generic version is
> called by default
>
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> arch/powerpc/platforms/85xx/smp.c | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH 2/2] [v2] powerpc/watchdog: allow the e500 watchdog driver to be compiled as a module
From: Kumar Gala @ 2010-10-07 6:00 UTC (permalink / raw)
To: Timur Tabi; +Cc: linux-watchdog, linuxppc-dev
In-Reply-To: <1284999822-24753-2-git-send-email-timur@freescale.com>
On Sep 20, 2010, at 11:23 AM, Timur Tabi wrote:
> Register the __init and __exit functions in the PowerPC e500 watchdog =
driver
> as module entry/exit functions, and modify the Kconfig entry.
>=20
> Add a .release method for the PowerPC e500 watchdog driver, so that =
the
> watchdog is disabled when the driver is closed.
>=20
> Loosely based on original code from Jiang Yutang =
<b14898@freescale.com>.
>=20
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>=20
> This patch requires:
>=20
> powerpc: export ppc_proc_freq and ppc_tb_freq as GPL symbols
>=20
> drivers/watchdog/Kconfig | 5 ++++-
> drivers/watchdog/booke_wdt.c | 39 =
+++++++++++++++++++++++++++++++++++++--
> 2 files changed, 41 insertions(+), 3 deletions(-)
applied to next [fixed comment message to say Book-E instead of e500]
- k=
^ permalink raw reply
* Re: [PATCH] powerpc: Fix invalid page flags in create TLB CAM path for PTE_64BIT
From: Kumar Gala @ 2010-10-07 6:05 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20100924164451.GA14042@windriver.com>
On Sep 24, 2010, at 11:44 AM, Paul Gortmaker wrote:
>>=20
>> =46rom d48ebb58b8214f9faec775a5e06902f638f165cf Mon Sep 17 00:00:00 =
2001
> From: Tiejun Chen <tiejun.chen@windriver.com>
> Date: Tue, 21 Sep 2010 19:31:31 +0800
> Subject: [PATCH] powerpc: Fix invalid page flags in create TLB CAM =
path for PTE_64BIT
>=20
> There exists a four line chunk of code, which when configured for
> 64 bit address space, can incorrectly set certain page flags during
> the TLB creation. It turns out that this is code which isn't used,
> but might still serve a purpose. Since it isn't obvious why it exists
> or why it causes problems, the below description covers both in =
detail.
>=20
> For powerpc bootstrap, the physical memory (at most 768M), is mapped
> into the kernel space via the following path:
>=20
> MMU_init()
> |
> + adjust_total_lowmem()
> |
> + map_mem_in_cams()
> |
> + settlbcam(i, virt, phys, cam_sz, PAGE_KERNEL_X, =
0);
>=20
> On settlbcam(), the kernel will create TLB entries according to the =
flag,
> PAGE_KERNEL_X.
>=20
> settlbcam()
> {
> ...
> TLBCAM[index].MAS1 =3D MAS1_VALID
> | MAS1_IPROT | MAS1_TSIZE(tsize) | =
MAS1_TID(pid);
> ^
> These entries cannot be invalidated by the
> kernel since MAS1_IPROT is set on TLB property.
> ...
> if (flags & _PAGE_USER) {
> TLBCAM[index].MAS3 |=3D MAS3_UX | MAS3_UR;
> TLBCAM[index].MAS3 |=3D ((flags & _PAGE_RW) ? MAS3_UW : 0);
> }
>=20
> For classic BookE (flags & _PAGE_USER) is 'zero' so it's fine.
> But on boards like the the Freescale P4080, we want to support 36-bit
> physical address on it. So the following options may be set:
>=20
> CONFIG_FSL_BOOKE=3Dy
> CONFIG_PTE_64BIT=3Dy
> CONFIG_PHYS_64BIT=3Dy
>=20
> As a result, boards like the P4080 will introduce PTE format as =
Book3E.
> As per the file: arch/powerpc/include/asm/pgtable-ppc32.h
>=20
> * #elif defined(CONFIG_FSL_BOOKE) && defined(CONFIG_PTE_64BIT)
> * #include <asm/pte-book3e.h>
>=20
> So PAGE_KERNEL_X is __pgprot(_PAGE_BASE | _PAGE_KERNEL_RWX) and the
> book3E version of _PAGE_KERNEL_RWX is defined with:
>=20
> (_PAGE_BAP_SW | _PAGE_BAP_SR | _PAGE_DIRTY | _PAGE_BAP_SX)
>=20
> Note the _PAGE_BAP_SR, which is also defined in the book3E _PAGE_USER:
>=20
> #define _PAGE_USER (_PAGE_BAP_UR | _PAGE_BAP_SR) /* Can be =
read */
>=20
> So the possibility exists to wrongly assign the user MAS3_U<RWX> bits
> to kernel (PAGE_KERNEL_X) address space via the following code =
fragment:
>=20
> if (flags & _PAGE_USER) {
> TLBCAM[index].MAS3 |=3D MAS3_UX | MAS3_UR;
> TLBCAM[index].MAS3 |=3D ((flags & _PAGE_RW) ? MAS3_UW : 0);
> }
>=20
> Here is a dump of the TLB info from Simics with the above code =
present:
> ------
> L2 TLB1
> GT SSS =
UUU V I
> Row Logical Physical SS TLPID TID WIMGE XWR =
XWR F P V
> ----- ----------------- ------------------- -- ----- ----- ----- --- =
--- - - -
> 0 c0000000-cfffffff 000000000-00fffffff 00 0 0 M XWR =
XWR 0 1 1
> 1 d0000000-dfffffff 010000000-01fffffff 00 0 0 M XWR =
XWR 0 1 1
> 2 e0000000-efffffff 020000000-02fffffff 00 0 0 M XWR =
XWR 0 1 1
>=20
> Actually this conditional code was used for two legacy functions:
>=20
> 1: support KGDB to set break point.
> KGDB already dropped this; now uses its core write to set break =
point.
>=20
> 2: io_block_mapping() to create TLB in segmentation size (not =
PAGE_SIZE)
> for device IO space.
> This use case is also removed from the latest PowerPC kernel.
>=20
> However, there may still be a use case for it in the future, like
> large user pages, so we can't remove it entirely. As an alternative,
> we match on all bits of _PAGE_USER instead of just any bits, so the
> case where just _PAGE_BAP_SR is set can't sneak through.
>=20
> With this done, the TLB appears without U having XWR as below:
>=20
> -------
> L2 TLB1
> GT SSS =
UUU V I
> Row Logical Physical SS TLPID TID WIMGE XWR =
XWR F P V
> ----- ----------------- ------------------- -- ----- ----- ----- --- =
--- - - -
> 0 c0000000-cfffffff 000000000-00fffffff 00 0 0 M XWR =
0 1 1
> 1 d0000000-dfffffff 010000000-01fffffff 00 0 0 M XWR =
0 1 1
> 2 e0000000-efffffff 020000000-02fffffff 00 0 0 M XWR =
0 1 1
>=20
> Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
> arch/powerpc/include/asm/pte-common.h | 7 +++++++
> arch/powerpc/mm/fsl_booke_mmu.c | 3 ++-
> 2 files changed, 9 insertions(+), 1 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH 4/4] powerpc/85xx: flush dcache before resetting cores
From: Kumar Gala @ 2010-10-07 6:00 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1284677906-23787-4-git-send-email-msm@freescale.com>
On Sep 16, 2010, at 5:58 PM, Matthew McClintock wrote:
> When we do an mpic_reset_core we need to make sure the dcache
> is flushed
>=20
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> arch/powerpc/platforms/85xx/smp.c | 50 =
+++++++++++++++++++++++++++++++++++++
> 1 files changed, 50 insertions(+), 0 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH v2] powerpc/fsl_soc: Search all global-utilities nodes for rstccr
From: Kumar Gala @ 2010-10-07 6:10 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev, timur
In-Reply-To: <1283294691-18765-1-git-send-email-msm@freescale.com>
On Aug 31, 2010, at 5:44 PM, Matthew McClintock wrote:
> The first global-utilities node might not contain the rstcr
> property, so we should search all the nodes
>
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> -Changed KERN_EMERG to KERN_ERR
> -Break if we do not find rstcr mapped
> -Restore of_put_node that was dropped
>
> arch/powerpc/sysdev/fsl_soc.c | 20 +++++++++++++-------
> 1 files changed, 13 insertions(+), 7 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH] edac: mpc85xx: Add support for new MPCxxx/Pxxxx EDAC controllers (fix)
From: Kumar Gala @ 2010-10-07 6:18 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev, linux-kernel, Dave Jiang, Peter Tyser,
Doug Thompson, Scott Wood, Andrew Morton
In-Reply-To: <20100801105419.GA352@oksana.dev.rtsoft.ru>
On Aug 1, 2010, at 5:54 AM, Anton Vorontsov wrote:
> On Wed, Jul 21, 2010 at 06:21:08PM -0500, Scott Wood wrote:
> [...]
>>>>> + { .compatible =3D "fsl,p4080-l2-cache-controller", },
>>>>=20
>>>> L2 on the p4080 is quite different from those other chips. It's =
part
>>>> of the core, controlled by SPRs.
>>>=20
>>> erm, was that an ack or a nack?
>>=20
>> NACK, p4080 doesn't belong in this table, at least not its L2.
>>=20
>> L3 on p4080 is similar to L2 on these other chips, though, and it
>> wouldn't take much to get this driver working on it -- but the match
>> table entry should wait until the differences are accommodated.
>=20
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
> ---
>=20
> Scott, thanks for catching this!
>=20
> Andrew, please merge this patch into
> edac-mpc85xx-add-support-for-new-mpcxxx-pxxxx-edac-controllers.patch
>=20
> Thanks!
>=20
> drivers/edac/mpc85xx_edac.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>=20
> diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
> index cfa86f7..b178cfa 100644
> --- a/drivers/edac/mpc85xx_edac.c
> +++ b/drivers/edac/mpc85xx_edac.c
> @@ -652,7 +652,6 @@ static struct of_device_id =
mpc85xx_l2_err_of_match[] =3D {
> { .compatible =3D "fsl,p1020-l2-cache-controller", },
> { .compatible =3D "fsl,p1021-l2-cache-controller", },
> { .compatible =3D "fsl,p2020-l2-cache-controller", },
> - { .compatible =3D "fsl,p4080-l2-cache-controller", },
> {},
> };
> MODULE_DEVICE_TABLE(of, mpc85xx_l2_err_of_match);
> --=20
> 1.7.0.5
Can you post a new patch as it doesn't look like this got merged by =
Andrew so we need to clean up after ourselves.
- k
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/fsl_booke: Add support to boot from core other than 0
From: Kumar Gala @ 2010-10-07 6:10 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1283297085-3455-2-git-send-email-msm@freescale.com>
On Aug 31, 2010, at 6:24 PM, Matthew McClintock wrote:
> First we check to see if we are the first core booting up. This
> is accomplished by comparing the boot_cpuid with -1, if it is we
> assume this is the first core coming up.
>
> Secondly, we need to update the initial thread info structure
> to reflect the actual cpu we are running on otherwise
> smp_processor_id() and related functions will return the default
> initialization value of the struct or 0.
>
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> arch/powerpc/kernel/head_fsl_booke.S | 10 ++++++++--
> arch/powerpc/kernel/setup_32.c | 2 +-
> 2 files changed, 9 insertions(+), 3 deletions(-)
Are we sticking with this or not?
- k
^ permalink raw reply
* Re: [PATCH] edac: mpc85xx: Add support for new MPCxxx/Pxxxx EDAC controllers (fix)
From: Anton Vorontsov @ 2010-10-07 6:29 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc-dev, linux-kernel, Dave Jiang, Peter Tyser,
Doug Thompson, Scott Wood, Andrew Morton
In-Reply-To: <5628792F-9A5F-4200-90B3-FB3939F02969@kernel.crashing.org>
On Thu, Oct 07, 2010 at 01:18:19AM -0500, Kumar Gala wrote:
[...]
> > diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
> > index cfa86f7..b178cfa 100644
> > --- a/drivers/edac/mpc85xx_edac.c
> > +++ b/drivers/edac/mpc85xx_edac.c
> > @@ -652,7 +652,6 @@ static struct of_device_id mpc85xx_l2_err_of_match[] = {
> > { .compatible = "fsl,p1020-l2-cache-controller", },
> > { .compatible = "fsl,p1021-l2-cache-controller", },
> > { .compatible = "fsl,p2020-l2-cache-controller", },
> > - { .compatible = "fsl,p4080-l2-cache-controller", },
> > {},
> > };
> > MODULE_DEVICE_TABLE(of, mpc85xx_l2_err_of_match);
> > --
> > 1.7.0.5
>
> Can you post a new patch as it doesn't look like this got merged by Andrew so we need to clean up after ourselves.
It's already in Linus' tree.
Thanks,
- - - -
commit cd1542c8197fc3c2eb3a8301505d5d9738fab1e4
Author: Anton Vorontsov <avorontsov@mvista.com>
Date: Tue Aug 10 18:03:21 2010 -0700
edac: mpc85xx: add support for new MPCxxx/Pxxxx EDAC controllers
Simply add proper IDs into the device table.
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Peter Tyser <ptyser@xes-inc.com>
Cc: Dave Jiang <djiang@mvista.com>
Cc: Doug Thompson <dougthompson@xmission.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index fdbad55..af75e27 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -647,7 +647,10 @@ static struct of_device_id mpc85xx_l2_err_of_match[] = {
{ .compatible = "fsl,mpc8555-l2-cache-controller", },
{ .compatible = "fsl,mpc8560-l2-cache-controller", },
{ .compatible = "fsl,mpc8568-l2-cache-controller", },
+ { .compatible = "fsl,mpc8569-l2-cache-controller", },
{ .compatible = "fsl,mpc8572-l2-cache-controller", },
+ { .compatible = "fsl,p1020-l2-cache-controller", },
+ { .compatible = "fsl,p1021-l2-cache-controller", },
{ .compatible = "fsl,p2020-l2-cache-controller", },
{},
};
@@ -1125,7 +1128,10 @@ static struct of_device_id mpc85xx_mc_err_of_match[] = {
{ .compatible = "fsl,mpc8569-memory-controller", },
{ .compatible = "fsl,mpc8572-memory-controller", },
{ .compatible = "fsl,mpc8349-memory-controller", },
+ { .compatible = "fsl,p1020-memory-controller", },
+ { .compatible = "fsl,p1021-memory-controller", },
{ .compatible = "fsl,p2020-memory-controller", },
+ { .compatible = "fsl,p4080-memory-controller", },
{},
};
MODULE_DEVICE_TABLE(of, mpc85xx_mc_err_of_match);
^ permalink raw reply related
* Re: [PATCH] powerpc/p1022: add probing for individual DMA channels, not just DMA controllers
From: Kumar Gala @ 2010-10-07 6:27 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <1282253292-19420-1-git-send-email-timur@freescale.com>
On Aug 19, 2010, at 4:28 PM, Timur Tabi wrote:
> Like the MPC8610 HPCD, the P1022DS ASoC DMA driver probes on =
individual DMA
> channel nodes, so the DMA controller nodes' compatible string must be =
listed in
> p1022_ds_ids[] to work.
>=20
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>=20
> This is for -next.
>=20
> I don't know why I forgot to include this change in the original =
P1022DS patch.
>=20
> arch/powerpc/platforms/85xx/p1022_ds.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH] edac: mpc85xx: Add support for new MPCxxx/Pxxxx EDAC controllers (fix)
From: Kumar Gala @ 2010-10-07 6:37 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev, linux-kernel, Dave Jiang, Peter Tyser,
Doug Thompson, Scott Wood, Andrew Morton
In-Reply-To: <20101007062909.GA27110@oksana.dev.rtsoft.ru>
>=20
> It's already in Linus' tree.
Yeah, the problem is what's merged in linus's tree has p4080 listed and =
it shouldn't
>=20
> Thanks,
>=20
> - - - -
> commit cd1542c8197fc3c2eb3a8301505d5d9738fab1e4
> Author: Anton Vorontsov <avorontsov@mvista.com>
> Date: Tue Aug 10 18:03:21 2010 -0700
>=20
> edac: mpc85xx: add support for new MPCxxx/Pxxxx EDAC controllers
>=20
> Simply add proper IDs into the device table.
>=20
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
> Cc: Scott Wood <scottwood@freescale.com>
> Cc: Peter Tyser <ptyser@xes-inc.com>
> Cc: Dave Jiang <djiang@mvista.com>
> Cc: Doug Thompson <dougthompson@xmission.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>=20
> diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
> index fdbad55..af75e27 100644
> --- a/drivers/edac/mpc85xx_edac.c
> +++ b/drivers/edac/mpc85xx_edac.c
> @@ -647,7 +647,10 @@ static struct of_device_id =
mpc85xx_l2_err_of_match[] =3D {
> { .compatible =3D "fsl,mpc8555-l2-cache-controller", },
> { .compatible =3D "fsl,mpc8560-l2-cache-controller", },
> { .compatible =3D "fsl,mpc8568-l2-cache-controller", },
> + { .compatible =3D "fsl,mpc8569-l2-cache-controller", },
> { .compatible =3D "fsl,mpc8572-l2-cache-controller", },
> + { .compatible =3D "fsl,p1020-l2-cache-controller", },
> + { .compatible =3D "fsl,p1021-l2-cache-controller", },
> { .compatible =3D "fsl,p2020-l2-cache-controller", },
> {},
> };
> @@ -1125,7 +1128,10 @@ static struct of_device_id =
mpc85xx_mc_err_of_match[] =3D {
> { .compatible =3D "fsl,mpc8569-memory-controller", },
> { .compatible =3D "fsl,mpc8572-memory-controller", },
> { .compatible =3D "fsl,mpc8349-memory-controller", },
> + { .compatible =3D "fsl,p1020-memory-controller", },
> + { .compatible =3D "fsl,p1021-memory-controller", },
> { .compatible =3D "fsl,p2020-memory-controller", },
> + { .compatible =3D "fsl,p4080-memory-controller", },
This line should be here ;)
> {},
> };
> MODULE_DEVICE_TABLE(of, mpc85xx_mc_err_of_match);
^ permalink raw reply
* Re: [PATCH] edac: mpc85xx: Add support for new MPCxxx/Pxxxx EDAC controllers (fix)
From: Kumar Gala @ 2010-10-07 7:00 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc-dev, Doug Thompson, linux-kernel, Dave Jiang,
Peter Tyser, Scott Wood, Andrew Morton
In-Reply-To: <0778A3B9-E242-4BCC-B318-154BE9ECB2C6@kernel.crashing.org>
On Oct 7, 2010, at 1:37 AM, Kumar Gala wrote:
>> @ -1125,7 +1128,10 @@ static struct of_device_id =
mpc85xx_mc_err_of_match[] =3D {
>> { .compatible =3D "fsl,mpc8569-memory-controller", },
>> { .compatible =3D "fsl,mpc8572-memory-controller", },
>> { .compatible =3D "fsl,mpc8349-memory-controller", },
>> + { .compatible =3D "fsl,p1020-memory-controller", },
>> + { .compatible =3D "fsl,p1021-memory-controller", },
>> { .compatible =3D "fsl,p2020-memory-controller", },
>> + { .compatible =3D "fsl,p4080-memory-controller", },
>=20
> This line should be here ;)
should NOT be here.
- k=
^ permalink raw reply
* Re: [PATCH] edac: mpc85xx: Add support for new MPCxxx/Pxxxx EDAC controllers (fix)
From: Anton Vorontsov @ 2010-10-07 7:12 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc-dev, linux-kernel, Dave Jiang, Peter Tyser,
Doug Thompson, Scott Wood, Andrew Morton
In-Reply-To: <4A00FECC-3840-45E1-AB2A-6BDBD0FE09E0@kernel.crashing.org>
On Thu, Oct 07, 2010 at 02:00:50AM -0500, Kumar Gala wrote:
>
> On Oct 7, 2010, at 1:37 AM, Kumar Gala wrote:
>
> >> @ -1125,7 +1128,10 @@ static struct of_device_id mpc85xx_mc_err_of_match[] = {
> >> { .compatible = "fsl,mpc8569-memory-controller", },
> >> { .compatible = "fsl,mpc8572-memory-controller", },
> >> { .compatible = "fsl,mpc8349-memory-controller", },
> >> + { .compatible = "fsl,p1020-memory-controller", },
> >> + { .compatible = "fsl,p1021-memory-controller", },
> >> { .compatible = "fsl,p2020-memory-controller", },
> >> + { .compatible = "fsl,p4080-memory-controller", },
> >
> > This line should be here ;)
>
> should NOT be here.
Hm. Are you sure? I thought that only L2 cache controller is
not applicable (and based on Scott's comment I removed
the l2 cache compatible entry for p4080). But I guess
memory-controller is somewhat similar to all other 85xx?
If it's not, I can surely prepare a patch that removes
p4080 entry.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: Linux on ppc440gp
From: Stefan Roese @ 2010-10-07 7:32 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Gorelik, Jacob (335F)
In-Reply-To: <1286409104.2463.373.camel@pasglop>
On Thursday 07 October 2010 01:51:44 Benjamin Herrenschmidt wrote:
> On Wed, 2010-10-06 at 07:35 -0700, Gorelik, Jacob (335F) wrote:
> > UIC0 (32 IRQ sources) at DCR 0xc0
> > UIC1 (32 IRQ sources) at DCR 0xd0
>
> That looks bad. Your device-tree probably. Check the DCR bindings.
Why does this look bad? On 440EPx this looks like this:
UIC0 (32 IRQ sources) at DCR 0xc0
UIC1 (32 IRQ sources) at DCR 0xd0
UIC2 (32 IRQ sources) at DCR 0xe0
So I don't see a problem with the output above.
Cheers,
Stefan
^ permalink raw reply
* Re: use of BAT before taking over the MMU
From: Benjamin Herrenschmidt @ 2010-10-07 8:00 UTC (permalink / raw)
To: Albert Cahalan; +Cc: linuxppc-dev
In-Reply-To: <AANLkTikH-f7MCxVyWr_mrfzeooQwRqTf4pGVEFSLO4Zy@mail.gmail.com>
On Wed, 2010-10-06 at 22:05 -0400, Albert Cahalan wrote:
> On Tue, Oct 5, 2010 at 11:31 AM, Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
>
> > An OS shouldn't expect to have more than its own program image
> > RAM mapped, in general.
>
> Linux actually makes calls to allocate more. I'm thankful
> that Linux always specifies an address, so I was able to
> get away with simply returning success. I wonder how this
> works for a firmware implementation that resides in RAM,
> using the memory that Linux demands. Must the firmware
> move itself out of the way?
No, Linux will retry somewhere else :-)
> >> Of course that faults immediately, so I have a handler that
> >> loads IBAT0 with a 128 KiB mapping. I treat the BAT like a
> >> direct-mapped software-loaded TLB. (like MIPS arch MMU)
> >
> > Just map the first 256MB and don't worry about anything else?
> > Seems a lot simpler to me ;-)
>
> I was expecting that Linux would demand plenty of mappings,
> including small ones and ones for IO. I was preparing myself
> for that.
No, not during prom_init. It's really just a trampoline code that sucks
out the device-tree and does a few other things. Once that's complete,
Linux takes over the MMU and from that point on, your FW is dead.
> >> Note that Linux can fail even with a firmware that doesn't touch
> >> the BAT registers. The MMU is on,
> >
> > You can boot Linux with the MMU off as well.
>
> That wasn't obvious for the prom_init path. IEEE docs seemed
> to suggest that the firmware must provide MMU handling.
1275 powerpc binding specifies both mode of operations. Linux doesn't
care which one is active
> >> and 0xc0000000 may be
> >> where the firmware expects to have... MMIO for the console,
> >> the client interface entry point, a forth stack, whatever.
> >> The BAT takes priority, and thus the firmware splatters stuff
> >> right onto the kernel or dies trying to read something it left there.
> >
> > Like I said, you're supposed to swap OS BATs with firmware BATs
> > in your client interface entry and exit. You have to switch
> > a lot of other registers there as well already, so that's no
> > big deal.
>
> Well no. This isn't real hardware. My prom entry point looks
> something like this:
>
> eciwx r0,r0,r0
> blr
>
> My ISI and DSI handlers look something like this:
>
> ecowx r0,r0,r0
> rfi
>
> The firmware doesn't need **any** registers. It's magic. I was
> just using the BAT registers to map what Linux wanted mapped.
Which is really just what any client program wants: You start with the
program ELF sections, and whatever it allocates with claim() calls.
> Anyway, I'm no longer able to reproduce the problem. I think
> something unrelated was causing strange behavior. This is a
> bit of a surprise since I would've expected a crash. Oh well.
Hard to tell from my side :-) But as I said, Linux doesn't rely on any
mapping at c0000000 or any BAT at this point. By the time it sets up
BATs the firmware is long gone and Linux is fully in control of the MMU.
Cheers,
Ben.
^ permalink raw reply
* Re: Linux on ppc440gp
From: Benjamin Herrenschmidt @ 2010-10-07 8:03 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, Gorelik, Jacob (335F)
In-Reply-To: <201010070932.56438.sr@denx.de>
On Thu, 2010-10-07 at 09:32 +0200, Stefan Roese wrote:
> On Thursday 07 October 2010 01:51:44 Benjamin Herrenschmidt wrote:
> > On Wed, 2010-10-06 at 07:35 -0700, Gorelik, Jacob (335F) wrote:
> > > UIC0 (32 IRQ sources) at DCR 0xc0
> > > UIC1 (32 IRQ sources) at DCR 0xd0
> >
> > That looks bad. Your device-tree probably. Check the DCR bindings.
>
> Why does this look bad? On 440EPx this looks like this:
Because of the shit in my eyes :-) I misread 0x00 for some reason...
> UIC0 (32 IRQ sources) at DCR 0xc0
> UIC1 (32 IRQ sources) at DCR 0xd0
> UIC2 (32 IRQ sources) at DCR 0xe0
>
> So I don't see a problem with the output above.
Right, me neither now that I had a shower !
Cheers,
Ben.
^ permalink raw reply
* Freescale P2020 / 85xx PCIe and Advance Error Reporting (AER) service problem
From: Eran Liberty @ 2010-10-07 12:30 UTC (permalink / raw)
To: Xianghua Xiao, ZHANG WEI, Roy Zang, Tony Li, Linas Vepstas,
linux-pci, linuxppc-dev
Dear Penguins,
SHORT:
There is a BUG in the current code design / Freescale P2020/85xx PCIe design that prevent it from registering to the PCIe AER... or that I have missed something :) ..
LESS SHORT:
I am in the process of a Freescale P2020 based board bring up. P2020 is basically two 85xx processors and their peripherals share most features.
PCIe has a very extensive error reporting section and the Kernel already has a very nice looking Advanced Error Reporting driver.
I encounter difficulties trying to connect the P2020/85xx PCIe device to this AER service driver.
My technical findings follows:
- pcie_portdrv_probe() will be called for every BRIDGE class PCI device. P2020 PCIe is a PCI-PCI BRIDGE class so no problem here.
- The code will continue to check that we have PCI_CAP_ID_EXP capability, which we have and continue to pcie_port_device_register().
- Now ,the function pcie_port_device_register() will FAIL. It will fail because it will call assign_interrupt_mode(), return with PCIE_PORT_NO_IRQ, and giveup with a reasonable remark in the code
"/*
* Don't use service devices that require interrupts if there is
* no way to generate them.
*/"
So now the question is why calling assign_interrupt_mode() with the P2020 PCIe ROOT device return empty? Well...
- First assign_interrupt_mode() will test for PCIE_PORT_MSIX_MODE. Freescale PCIe does not support this...
- Second attampt is made to discover PCIE_PORT_MSI_MODE, which Freescale should support but the PCIe PCI_CAP_ID_MSI capability is published on the device side of the bridge and NOT on the PCIe ROOT device, which is the one probed and thus fails.
- Last it attempts to look at "dev->pin" in order to set PCIE_PORT_INTx_MODE. On top of being the less recommended way (the old way), The Freescale PCIE ROOT device pin is not set anywhere.
Failing all those the probe fails and the AER service is not activated for the PCIE device.
QUESTION:
1. What am I missing?
2. Has anyone enabled the AER PCIe service for P2020/MPC85xx?
3. Should the PCIe ROOT end report MSI capabilities or should the device end report itself as bridge ???
-- Liberty
^ permalink raw reply
* Re: [PATCH] edac: mpc85xx: Add support for new MPCxxx/Pxxxx EDAC controllers (fix)
From: Kumar Gala @ 2010-10-07 13:21 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev, linux-kernel, Dave Jiang, Peter Tyser,
Doug Thompson, Scott Wood, Andrew Morton
In-Reply-To: <20101007071226.GA32189@oksana.dev.rtsoft.ru>
On Oct 7, 2010, at 2:12 AM, Anton Vorontsov wrote:
> On Thu, Oct 07, 2010 at 02:00:50AM -0500, Kumar Gala wrote:
>>=20
>> On Oct 7, 2010, at 1:37 AM, Kumar Gala wrote:
>>=20
>>>> @ -1125,7 +1128,10 @@ static struct of_device_id =
mpc85xx_mc_err_of_match[] =3D {
>>>> { .compatible =3D "fsl,mpc8569-memory-controller", },
>>>> { .compatible =3D "fsl,mpc8572-memory-controller", },
>>>> { .compatible =3D "fsl,mpc8349-memory-controller", },
>>>> + { .compatible =3D "fsl,p1020-memory-controller", },
>>>> + { .compatible =3D "fsl,p1021-memory-controller", },
>>>> { .compatible =3D "fsl,p2020-memory-controller", },
>>>> + { .compatible =3D "fsl,p4080-memory-controller", },
>>>=20
>>> This line should be here ;)
>>=20
>> should NOT be here.
>=20
> Hm. Are you sure? I thought that only L2 cache controller is
> not applicable (and based on Scott's comment I removed
> the l2 cache compatible entry for p4080). But I guess
> memory-controller is somewhat similar to all other 85xx?
>=20
> If it's not, I can surely prepare a patch that removes
> p4080 entry.
>=20
> Thanks,
Your correct, late night and looking at the wrong line. It was the L2 =
that should have been removed. Ignore me.
- k=
^ permalink raw reply
* P1020RDB PCI-E Interrupt problem
From: Fabian Bertholm @ 2010-10-07 13:45 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I try to run ath9k on a P1020RDB Freescale board.
I run into the problem similar to the Bug/Patch here:
http://patchwork.ozlabs.org/patch/52137/
I get irq 16: nobody cared....
I tried to fix the dts file in the same manner but this does not help.
Currently I am using 2.6.33.7
Any hints? Anybody?
The modified pci section from my dts:
pci0: pcie@ffe09000 {
cell-index = <1>;
compatible = "fsl,mpc8548-pcie";
device_type = "pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <0 0xffe09000 0 0x1000>;
bus-range = <0 255>;
ranges = <0x2000000 0x0 0xa0000000 0 0xa0000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0 0xffc30000 0x0 0x10000>;
clock-frequency = <33333333>;
interrupt-parent = <&mpic>;
interrupts = <16 2>;
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
interrupt-map = <
/* IDSEL 0x0 */
0000 0x0 0x0 0x1 &mpic 0x4 0x2
0000 0x0 0x0 0x2 &mpic 0x5 0x2
0000 0x0 0x0 0x3 &mpic 0x6 0x2
0000 0x0 0x0 0x4 &mpic 0x7 0x2
>;
pcie@0 {
reg = <0x0 0x0 0x0 0x0 0x0>;
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
ranges = <0x2000000 0x0 0xa0000000
0x2000000 0x0 0xa0000000
0x0 0x20000000
0x1000000 0x0 0x0
0x1000000 0x0 0x0
0x0 0x100000>;
};
};
pci1: pcie@ffe0a000 {
cell-index = <2>;
compatible = "fsl,mpc8548-pcie";
device_type = "pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <0 0xffe0a000 0 0x1000>;
bus-range = <0 255>;
ranges = <0x2000000 0x0 0xc0000000 0 0xc0000000 0x0 0x20000000
0x1000000 0x0 0x00000000 0 0xffc20000 0x0 0x10000>;
clock-frequency = <33333333>;
interrupt-parent = <&mpic>;
interrupts = <16 2>;
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
interrupt-map = <
/* IDSEL 0x0 */
0000 0x0 0x0 0x1 &mpic 0x0 0x1
0000 0x0 0x0 0x2 &mpic 0x1 0x1
0000 0x0 0x0 0x3 &mpic 0x2 0x1
0000 0x0 0x0 0x4 &mpic 0x3 0x1
>;
pcie@0 {
reg = <0x0 0x0 0x0 0x0 0x0>;
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
ranges = <0x2000000 0x0 0xc0000000
0x2000000 0x0 0xc0000000
0x0 0x20000000
0x1000000 0x0 0x0
0x1000000 0x0 0x0
0x0 0x100000>;
};
};
Best Regards,
Fabian
^ permalink raw reply
* Re: Serial RapidIO Maintaintance read causes lock up
From: Micha Nelissen @ 2010-10-07 14:21 UTC (permalink / raw)
To: Bastiaan Nijkamp; +Cc: linuxppc-dev
In-Reply-To: <AANLkTimFgrRbRfsQqN9d9GOZhth072F9TKGXunaqJNVB@mail.gmail.com>
Hi Bastian,
Bastiaan Nijkamp wrote:
> It seems i forgot to include the relevant TLB entries in U-Boot and the
> Device Tree in the e-mail, so here they are:
>
> The TLB entries in U-Boot:
The kernel maintains the TLB, you must not set those in U-boot. It might
cause conflicts when the kernel chooses its virtual memory space. You
should only configure LAWs in U-boot as the kernel does not do that.
That's the physical address you pass in the DTB (which seems to work,
reading your kernel log).
Do you access RapidIO space in U-boot also?
Do you have a logic analyser, then you can see whether the read is
actually coming out.
Check whether the time-to-live, packet and link timeouts have been set
to sane values to prevent deadlocks (especially time-to-live). At least
then your kernel will crash instead of lock up.
Micha
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox