Re: [RFC PATCH] dt:numa: adding numa node mapping for memory nodes.
On Sep 17, 2014, at 1:56 AM, Ganapatrao Kulkarni
wrote:
> From: Ganapatrao Kulkarni
>
> This patch adds property "nid" to memory node to provide the memory range to
> numa node id mapping.
>
> Signed-off-by: Ganapatrao Kulkarni
>
> —
Adding the PPC guys as they’ve been doing NUMA on IBM Power Servers for years
with OF/DT. So we should really try and follow what they’ve done.
> Documentation/devicetree/bindings/numa.txt | 58 ++
> 1 file changed, 58 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/numa.txt
>
> diff --git a/Documentation/devicetree/bindings/numa.txt
> b/Documentation/devicetree/bindings/numa.txt
> new file mode 100644
> index 000..c4a94f2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/numa.txt
> @@ -0,0 +1,58 @@
> +==
> +numa id binding description
> +==
> +
> +==
> +1 - Introduction
> +==
> +The device node property "nid(numa node id)" can be added to memory
> +device node to map the range of memory addresses as defined in property
> "reg".
> +The property "nid" maps the memory range to the numa node id, which is used
> to
> +find the local and remory pages on numa aware systems.
> +
> +==
> +2 - nid property
> +==
> +Numa node id, "nid" is required property of memory device node for
> +numa enabled platforms.
> +
> +|--|
> +|Property Type | Usage | Value Type | Definition |
> +|--|
> +| nid | R| | Numa Node id|
> +| | || for this memory |
> +|--|
> +
> +
> +4 - Example memory nodes with numa node id mapping
> +
> +
> +Example 1 (2 memory nodes, each mapped to a numa node.):
> +
> + memory@ {
> + device_type = "memory";
> + reg = <0x0 0x 0x0 0x8000>;
> + nid = <0x0>;
> + };
> +
> + memory@100 {
> + device_type = "memory";
> + reg = <0x100 0x 0x0 0x8000>;
> + nid = <0x1>;
> + };
> +
> +Example 2 (multiple memory ranges in each memory node and mapped to numa
> node):
> +
> + memory@ {
> + device_type = "memory";
> + reg = <0x0 0x 0x0 0x8000>,
> + <0x0 0x8000 0x0 0x8000>;
> + nid = <0x0>;
> + };
> +
> + memory@100 {
> + device_type = "memory";
> + reg = <0x100 0x 0x0 0x8000>,
> + <0x100 0x8000 0x0 0x8000>;
> + nid = <0x1>;
> + };
> --
> 1.8.1.4
>
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] rheap: move rheap.c from arch/powerpc/lib/ to lib/
On Sep 25, 2014, at 4:47 AM, Zhao Qiang wrote:
> qe need to use the rheap, so move it to public directory.
>
> Signed-off-by: Zhao Qiang
> ---
> arch/powerpc/Kconfig| 3 ---
> arch/powerpc/include/asm/fsl_85xx_cache_sram.h | 2 +-
> arch/powerpc/lib/Makefile | 2 --
> arch/powerpc/platforms/44x/Kconfig | 2 +-
> arch/powerpc/platforms/85xx/Kconfig | 2 +-
> arch/powerpc/platforms/Kconfig | 2 +-
> arch/powerpc/platforms/Kconfig.cputype | 2 +-
> arch/powerpc/sysdev/cpm1.c | 2 +-
> arch/powerpc/sysdev/cpm2.c | 2 +-
> arch/powerpc/sysdev/cpm_common.c| 2 +-
> arch/powerpc/sysdev/ppc4xx_ocm.c| 2 +-
> drivers/dma/bestcomm/Kconfig| 2 +-
> drivers/soc/qe/Kconfig | 2 +-
> drivers/soc/qe/qe.c | 2 +-
> drivers/soc/qe/qe_common.c | 2 +-
> drivers/video/Kconfig | 2 +-
> include/linux/fsl/bestcomm/sram.h | 2 +-
> {arch/powerpc/include/asm => include/linux/fsl}/rheap.h | 0
> lib/Kconfig | 3 +++
> lib/Makefile| 2 ++
> {arch/powerpc/lib => lib}/rheap.c | 2 +-
> 21 files changed, 21 insertions(+), 21 deletions(-)
> rename {arch/powerpc/include/asm => include/linux/fsl}/rheap.h (100%)
> rename {arch/powerpc/lib => lib}/rheap.c (99%)
Have you guys looked at moving to lib/genalloc.c. If we are going to keep
rheap around the include should be just in include/linux/rheap.h not
include/linux/fsl/rheap.h
However, I think genalloc should be used and kill off rheap usage.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] cpufreq: qoriq: Make the driver usable on all QorIQ platforms
On Oct 17, 2014, at 5:13 AM, b29...@freescale.com wrote:
> From: Tang Yuantian
>
> Freescale introduced new ARM core-based SoCs which support dynamic
> frequency switch feature. DFS on new SoCs are compatible with current
> PowerPC CoreNet platforms. In order to support those new platforms,
> this driver needs to be slightly adjusted. The main changes include:
>
> 1. Changed the names of driver and functions in driver.
split the name changes/renaming into a separate patch from the other changes.
> 2. Added two new functions get_cpu_physical_id() and get_bus_freq().
> 3. Used a new way to get all the CPUs which sharing clock wire.
>
> Signed-off-by: Tang Yuantian
> ---
> drivers/cpufreq/Kconfig.arm| 8 ++
> drivers/cpufreq/Kconfig.powerpc| 11 +-
> drivers/cpufreq/Makefile | 2 +-
> .../{ppc-corenet-cpufreq.c => qoriq-cpufreq.c} | 150 ++---
> 4 files changed, 114 insertions(+), 57 deletions(-)
> rename drivers/cpufreq/{ppc-corenet-cpufreq.c => qoriq-cpufreq.c} (72%)
>
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 83a75dc..1925ae94 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -247,3 +247,11 @@ config ARM_TEGRA_CPUFREQ
> default y
> help
> This adds the CPUFreq driver support for TEGRA SOCs.
> +
> +config QORIQ_CPUFREQ
> + tristate "CPU frequency scaling driver for Freescale QorIQ SoCs"
> + depends on OF && COMMON_CLK
> + select CLK_PPC_CORENET
Why are you not also renaming ‘CLK_PPC_CORENET’ to ‘CLK_QORIQ’ or something
like that? Seems rather odd to select a PPC CLK support on ARM ;)
> + help
> + This adds the CPUFreq driver support for Freescale QorIQ SoCs
> + which are capable of changing the CPU's frequency dynamically.
> diff --git a/drivers/cpufreq/Kconfig.powerpc b/drivers/cpufreq/Kconfig.powerpc
> index 72564b7..3a34248 100644
> --- a/drivers/cpufreq/Kconfig.powerpc
> +++ b/drivers/cpufreq/Kconfig.powerpc
> @@ -23,14 +23,13 @@ config CPU_FREQ_MAPLE
> This adds support for frequency switching on Maple 970FX
> Evaluation Board and compatible boards (IBM JS2x blades).
>
> -config PPC_CORENET_CPUFREQ
> - tristate "CPU frequency scaling driver for Freescale E500MC SoCs"
> - depends on PPC_E500MC && OF && COMMON_CLK
> +config QORIQ_CPUFREQ
> + tristate "CPU frequency scaling driver for Freescale QorIQ SoCs"
> + depends on OF && COMMON_CLK
> select CLK_PPC_CORENET
> help
> - This adds the CPUFreq driver support for Freescale e500mc,
> - e5500 and e6500 series SoCs which are capable of changing
> - the CPU's frequency dynamically.
> + This adds the CPUFreq driver support for Freescale QorIQ SoCs
> + which are capable of changing the CPU's frequency dynamically.
>
> config CPU_FREQ_PMAC
> bool "Support for Apple PowerBooks"
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index 40c53dc..0020049 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -84,7 +84,7 @@ obj-$(CONFIG_CPU_FREQ_CBE) += ppc-cbe-cpufreq.o
> ppc-cbe-cpufreq-y += ppc_cbe_cpufreq_pervasive.o
> ppc_cbe_cpufreq.o
> obj-$(CONFIG_CPU_FREQ_CBE_PMI)+= ppc_cbe_cpufreq_pmi.o
> obj-$(CONFIG_CPU_FREQ_MAPLE) += maple-cpufreq.o
> -obj-$(CONFIG_PPC_CORENET_CPUFREQ) += ppc-corenet-cpufreq.o
> +obj-$(CONFIG_QORIQ_CPUFREQ) += qoriq-cpufreq.o
> obj-$(CONFIG_CPU_FREQ_PMAC) += pmac32-cpufreq.o
> obj-$(CONFIG_CPU_FREQ_PMAC64) += pmac64-cpufreq.o
> obj-$(CONFIG_PPC_PASEMI_CPUFREQ) += pasemi-cpufreq.o
> diff --git a/drivers/cpufreq/ppc-corenet-cpufreq.c
> b/drivers/cpufreq/qoriq-cpufreq.c
> similarity index 72%
> rename from drivers/cpufreq/ppc-corenet-cpufreq.c
> rename to drivers/cpufreq/qoriq-cpufreq.c
> index bee5df7..80def0c 100644
> --- a/drivers/cpufreq/ppc-corenet-cpufreq.c
> +++ b/drivers/cpufreq/qoriq-cpufreq.c
> @@ -1,7 +1,7 @@
> /*
> * Copyright 2013 Freescale Semiconductor, Inc.
> *
> - * CPU Frequency Scaling driver for Freescale PowerPC corenet SoCs.
> + * CPU Frequency Scaling driver for Freescale QorIQ SoCs.
> *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License version 2 as
> @@ -20,7 +20,6 @@
> #include
> #include
> #include
> -#include
>
> /**
> * struct cpu_data - per CPU data struct
> @@ -69,9 +68,6 @@ static const u32 *fmask;
>
> static DEFINE_PER_CPU(struct cpu_data *, cpu_data);
>
> -/* cpumask in a cluster */
> -static DEFINE_PER_CPU(cpumask_var_t, cpu_mask);
> -
> #ifndef CONFIG_SMP
> static inline const struct cpumask *cpu_core_mask(int cpu)
> {
> @@ -79,6 +75,79 @@ static inline const struct cpumask *cpu_core_mask(int cpu)
> }
> #endif
>
> +#if defined(CONFIG_PPC_E500MC)
Probably should just be CONFIG
Re: [PATCH 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
On Oct 22, 2014, at 9:09 AM, Emil Medve wrote:
> The Buffer Manager is part of the Data-Path Acceleration Architecture (DPAA).
> BMan supports hardware allocation and deallocation of buffers belonging to
> pools originally created by software with configurable depletion thresholds.
> This binding covers the CCSR space programming model
>
> Signed-off-by: Emil Medve
> Change-Id: I3ec479bfb3c91951e96902f091f5d7d2adbef3b2
> ---
> .../devicetree/bindings/powerpc/fsl/bman.txt | 98 ++
> 1 file changed, 98 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt
Should these really be in bindings/powerpc/fsl, aren’t you guys using this on
ARM SoCs as well?
I can’t remember if the TI guys had a HW allocator as part of their similar HW.
>
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
> b/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
> new file mode 100644
> index 000..c30bdde
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
> @@ -0,0 +1,98 @@
> +QorIQ DPAA Buffer Manager Device Tree Bindings
> +
> +Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
> +
> +CONTENTS
> +
> + - BMan Node
> + - BMan Private Memory Node
> + - Example
> +
> +NOTE:The bindings described in this document are preliminary and
> subject to
> + change
> +
> +BMan Node
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: Required
> + Value type:
> + Definition: Must include "fsl,bman"
> + May include "fsl,-bman"
> +
> +- reg
> + Usage: Required
> + Value type:
> + Definition: Registers region within the CCSR address space
> +
> +- fsl,liodn
> + Usage: See pamu.txt
> + Value type:
> + Definition: PAMU property used for static LIODN assignment
> +
> +- fsl,iommu-parent
> + Usage: See pamu.txt
> + Value type:
> + Definition: PAMU property used for dynamic LIODN assignment
> +
> + For additional details about the PAMU/LIODN binding(s) see pamu.txt
> +
interrupts should be in this list.
> +BMan Private Memory Node
> +
> +BMan requires a contiguous range of physical memory used for the backing
> store
> +for BMan Free Buffer Proxy Records. This memory is reserved/allocated as a
> node
> +under the /reserved-memory node
> +
> +The BMan FBPR memory node must be named "bman-fbpr"
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: required
> + Value type:
> + Definition: Must inclide "fsl,bman-fbpr"
> +
> +The following constraints are relevant to the FBPR private memory:
> + - The size must be 2^(size + 1), with size = 11..33. That is 4 KiB to
> + 16 GiB
> + - The alignment must be a muliptle of the memory size
> +
> +The size of the FBPR must be chosen by observing the hardware features
> configured
> +via the RCW and that are relevant to a specific board (e.g. number of MAC(s)
> +pinned-out, number of offline/host command FMan ports, etc.). The size
> configured
> +in the DT must reflect the hardware capabilities and not the specific needs
> of an
> +application
RCW doesn’t have any context here
> +
> +If the memory reserved in the device tree proves to be larger then the needs
> of
> +the application a BMan driver may provide a method to release the extra
> memory
> +back to the OS
> +
> +For additional details about reserved memory regions see reserved-memory.txt
> +
> +EXAMPLE
> +
> +The example below shows a BMan FBPR dynamic allocation memory node
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + bman-fbpr {
> + compatible = "fsl,bman-fbpr";
> + alloc-ranges = <0 0 0xf 0x>;
> + size = <0 0x100>;
> + alignment = <0 0x100>;
> + };
> +
> + };
> +
> +The example below shows a (P4080) BMan CCSR-space node
> +
> + bman@31a000 {
> + compatible = "fsl,bman";
> + reg = <0x31a000 0x1000>;
> + interrupts = <16 2 1 2>;
> + fsl,liodn = <0x17>;
no fsl,iommu-parent in the example?
> + };
Do you not need a phandle between the bman and the memory node?
- k
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
On Oct 28, 2014, at 4:15 AM, Emil Medve wrote:
> The Buffer Manager is part of the Data-Path Acceleration Architecture (DPAA).
> BMan supports hardware allocation and deallocation of buffers belonging to
> pools originally created by software with configurable depletion thresholds.
> This binding covers the CCSR space programming model
>
> Signed-off-by: Emil Medve
> Change-Id: I3ec479bfb3c91951e96902f091f5d7d2adbef3b2
> ---
> .../devicetree/bindings/powerpc/fsl/bman.txt | 95 ++
> 1 file changed, 95 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/bman.txt
Should these really be in bindings/powerpc/fsl, aren’t you guys using this on
ARM SoCs as well?
I can’t remember if the TI guys had a HW allocator as part of their similar HW.
If so, possibly worth while to see where they have their binding.
>
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
> b/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
> new file mode 100644
> index 000..d3fd1e3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/bman.txt
> @@ -0,0 +1,95 @@
> +QorIQ DPAA Buffer Manager Device Tree Bindings
> +
> +Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
> +
> +CONTENTS
> +
> + - BMan Node
> + - BMan Private Memory Node
> + - Example
> +
> +BMan Node
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: Required
> + Value type:
> + Definition: Must include "fsl,bman"
> + May include "fsl,-bman"
> +
> +- reg
> + Usage: Required
> + Value type:
> + Definition: Registers region within the CCSR address space
> +
> +- interrupts
> + Usage: Required
> + Value type:
> + Definition: Standard property. The error interrupt
> +
> +- fsl,liodn
> + Usage: See pamu.txt
> + Value type:
> + Definition: PAMU property used for static LIODN assignment
> +
> +- fsl,iommu-parent
> + Usage: See pamu.txt
> + Value type:
> + Definition: PAMU property used for dynamic LIODN assignment
> +
> + For additional details about the PAMU/LIODN binding(s) see pamu.txt
> +
> +BMan Private Memory Node
> +
> +BMan requires a contiguous range of physical memory used for the backing
> store
> +for BMan Free Buffer Proxy Records. This memory is reserved/allocated as a
> node
… Proxy Records (FBPR). This
[ so we get context for the acronym used later ]
> +under the /reserved-memory node
> +
> +The BMan FBPR memory node must be named "bman-fbpr"
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: required
> + Value type:
> + Definition: Must inclide "fsl,bman-fbpr"
> +
> +The following constraints are relevant to the FBPR private memory:
> + - The size must be 2^(size + 1), with size = 11..33. That is 4 KiB to
> + 16 GiB
> + - The alignment must be a muliptle of the memory size
> +
> +The size of the FBPR must be chosen by observing the hardware features
> configured
> +via the RCW and that are relevant to a specific board (e.g. number of MAC(s)
> +pinned-out, number of offline/host command FMan ports, etc.). The size
> configured
> +in the DT must reflect the hardware capabilities and not the specific needs
> of an
> +application
RCW doesn’t have any context here
> +
> +For additional details about reserved memory regions see reserved-memory.txt
> +
> +EXAMPLE
> +
> +The example below shows a BMan FBPR dynamic allocation memory node
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + bman-fbpr {
> + compatible = "fsl,bman-fbpr";
> + alloc-ranges = <0 0 0xf 0x>;
> + size = <0 0x100>;
> + alignment = <0 0x100>;
> + };
> + };
> +
> +The example below shows a (P4080) BMan CCSR-space node
> +
> + bman@31a000 {
> + compatible = "fsl,bman";
> + reg = <0x31a000 0x1000>;
> + interrupts = <16 2 1 2>;
> + fsl,liodn = <0x17>;
no fsl,iommu-parent in the example?
> + };
Do you not need a phandle between the bman and the memory node?
- k
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan portal(s)
On Oct 28, 2014, at 4:15 AM, Emil Medve wrote:
> Portals are memory mapped interfaces to BMan that allow low-latency,
> lock-less interaction by software running on processor cores, accelerators
> and network interfaces with the BMan
>
> Signed-off-by: Emil Medve
> Change-Id: I6d245ffc14ba3d0e91d403ac7c3b91b75a9e6a95
> ---
> .../bindings/powerpc/fsl/bman-portals.txt | 52 ++
> 1 file changed, 52 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
>
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
> b/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
similar comment about location of binding not being PPC specific.
> new file mode 100644
> index 000..02e0231
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/bman-portals.txt
> @@ -0,0 +1,52 @@
> +QorIQ DPAA Buffer Manager Portals Device Tree Binding
> +
Probably worth putting the text from the commit message here as well.
> +Copyright (C) 2008 - 2014 Freescale Semiconductor Inc.
> +
> +CONTENTS
> +
> + - BMan Portal
> + - Example
> +
> +BMan Portal Node
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: Required
> + Value type:
> + Definition: Must include "fsl,bman-portal-"
> + May include "fsl,-bman-portal" or "fsl,bman-portal"
> +
> +- reg
> + Usage: Required
> + Value type:
> + Definition: Two regions. The first is the cache-enabled region of
> + the portal. The second is the cache-inhibited region of
> + the portal
> +
> +- interrupts
> + Usage: Required
> + Value type:
> + Definition: Standard property
> +
> +EXAMPLE
> +
> +The example below shows a (P4080) BMan portals container/bus node with two
> portals
> +
> + bman-portals@ff400 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "simple-bus";
> + ranges = <0 0xf 0xf400 0x20>;
> +
> + bman-portal@0 {
> + compatible = "fsl,bman-portal-1.0.0", "fsl,bman-portal";
> + reg = <0x0 0x4000>, <0x10 0x1000>;
> + interrupts = <105 2 0 0>;
> + };
> + bman-portal@4000 {
> + compatible = "fsl,bman-portal-1.0.0", "fsl,bman-portal";
> + reg = <0x4000 0x4000>, <0x101000 0x1000>;
> + interrupts = <107 2 0 0>;
> + };
> + };
> --
> 2.1.2
>
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 3/3] rheap: move rheap.c from arch/powerpc/lib/ to lib/
On Oct 30, 2014, at 2:31 AM, Zhao Qiang wrote:
> qe need to use the rheap, so move it to public directory.
>
> Signed-off-by: Zhao Qiang
> ---
> arch/powerpc/Kconfig| 3 ---
> arch/powerpc/include/asm/fsl_85xx_cache_sram.h | 2 +-
> arch/powerpc/lib/Makefile | 2 --
> arch/powerpc/platforms/44x/Kconfig | 2 +-
> arch/powerpc/platforms/85xx/Kconfig | 2 +-
> arch/powerpc/platforms/Kconfig | 2 +-
> arch/powerpc/platforms/Kconfig.cputype | 2 +-
> arch/powerpc/sysdev/cpm1.c | 2 +-
> arch/powerpc/sysdev/cpm2.c | 2 +-
> arch/powerpc/sysdev/cpm_common.c| 2 +-
> arch/powerpc/sysdev/ppc4xx_ocm.c| 2 +-
> drivers/dma/bestcomm/Kconfig| 2 +-
> drivers/soc/fsl-qe/Kconfig | 2 +-
> drivers/soc/fsl-qe/qe.c | 2 +-
> drivers/soc/fsl-qe/qe_common.c | 2 +-
> include/linux/fsl/bestcomm/sram.h | 2 +-
> {arch/powerpc/include/asm => include/linux/fsl}/rheap.h | 0
> lib/Kconfig | 3 +++
> lib/Makefile| 2 ++
> {arch/powerpc/lib => lib}/rheap.c | 2 +-
> 20 files changed, 20 insertions(+), 20 deletions(-)
> rename {arch/powerpc/include/asm => include/linux/fsl}/rheap.h (100%)
> rename {arch/powerpc/lib => lib}/rheap.c (99%)
NAK. As I stated before you need to convert rheap users to lib/genalloc.c
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/3] QE: move qe code from arch/powerpc to drivers/soc
On Oct 30, 2014, at 2:31 AM, Zhao Qiang wrote:
> LS1 is arm cpu and it has qe ip block.
> move qe code from platform directory to public directory.
>
> QE is an IP block integrates several comunications peripheral
> controllers. It can implement a variety of applications, such
> as uart, usb and tdm and so on.
>
> Signed-off-by: Zhao Qiang
> ---
> Changes for v2:
> - move code to driver/soc
> Changes for v3:
> - change drivers/soc/qe to drivers/soc/fsl-qe
>
> arch/powerpc/Kconfig | 2 -
> arch/powerpc/platforms/83xx/km83xx.c | 4 +-
> arch/powerpc/platforms/83xx/misc.c | 2 +-
> arch/powerpc/platforms/83xx/mpc832x_mds.c | 4 +-
> arch/powerpc/platforms/83xx/mpc832x_rdb.c | 4 +-
> arch/powerpc/platforms/83xx/mpc836x_mds.c | 4 +-
> arch/powerpc/platforms/83xx/mpc836x_rdk.c | 4 +-
> arch/powerpc/platforms/85xx/common.c | 2 +-
> arch/powerpc/platforms/85xx/corenet_generic.c | 2 +-
> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 4 +-
> arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 4 +-
> arch/powerpc/platforms/85xx/twr_p102x.c| 4 +-
> arch/powerpc/platforms/Kconfig | 19 -
> arch/powerpc/sysdev/Makefile | 1 -
> arch/powerpc/sysdev/qe_lib/Kconfig | 27 -
> drivers/net/ethernet/freescale/fsl_pq_mdio.c | 2 +-
> drivers/net/ethernet/freescale/ucc_geth.c | 8 ++--
> drivers/net/ethernet/freescale/ucc_geth.h | 8 ++--
> drivers/soc/Kconfig| 2 +
> drivers/soc/Makefile | 1 +
> drivers/soc/fsl-qe/Kconfig | 45 ++
> .../sysdev/qe_lib => drivers/soc/fsl-qe}/Makefile | 0
> .../sysdev/qe_lib => drivers/soc/fsl-qe}/gpio.c| 2 +-
> .../sysdev/qe_lib => drivers/soc/fsl-qe}/qe.c | 4 +-
> .../sysdev/qe_lib => drivers/soc/fsl-qe}/qe_ic.c | 2 +-
> .../sysdev/qe_lib => drivers/soc/fsl-qe}/qe_ic.h | 2 +-
> .../sysdev/qe_lib => drivers/soc/fsl-qe}/qe_io.c | 2 +-
> .../sysdev/qe_lib => drivers/soc/fsl-qe}/ucc.c | 6 +--
> .../qe_lib => drivers/soc/fsl-qe}/ucc_fast.c | 8 ++--
> .../qe_lib => drivers/soc/fsl-qe}/ucc_slow.c | 8 ++--
> .../sysdev/qe_lib => drivers/soc/fsl-qe}/usb.c | 4 +-
> drivers/spi/spi-fsl-cpm.c | 2 +-
> drivers/tty/serial/ucc_uart.c | 2 +-
> drivers/usb/gadget/fsl_qe_udc.c| 2 +-
> drivers/usb/host/fhci-hcd.c| 2 +-
> drivers/usb/host/fhci-hub.c| 2 +-
> drivers/usb/host/fhci-sched.c | 2 +-
> drivers/usb/host/fhci.h| 4 +-
> .../include/asm => include/linux/fsl}/immap_qe.h | 0
> .../powerpc/include/asm => include/linux/fsl}/qe.h | 2 +-
> .../include/asm => include/linux/fsl}/qe_ic.h | 0
> .../include/asm => include/linux/fsl}/ucc.h| 4 +-
> .../include/asm => include/linux/fsl}/ucc_fast.h | 6 +--
> .../include/asm => include/linux/fsl}/ucc_slow.h | 6 +--
> 44 files changed, 112 insertions(+), 113 deletions(-)
> delete mode 100644 arch/powerpc/sysdev/qe_lib/Kconfig
> create mode 100644 drivers/soc/fsl-qe/Kconfig
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/Makefile (100%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/gpio.c (99%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/qe.c (99%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/qe_ic.c (99%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/qe_ic.h (98%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/qe_io.c (99%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/ucc.c (98%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/ucc_fast.c (98%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/ucc_slow.c (98%)
> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/usb.c (96%)
> rename {arch/powerpc/include/asm => include/linux/fsl}/immap_qe.h (100%)
> rename {arch/powerpc/include/asm => include/linux/fsl}/qe.h (99%)
> rename {arch/powerpc/include/asm => include/linux/fsl}/qe_ic.h (100%)
> rename {arch/powerpc/include/asm => include/linux/fsl}/ucc.h (96%)
> rename {arch/powerpc/include/asm => include/linux/fsl}/ucc_fast.h (98%)
> rename {arch/powerpc/include/asm => include/linux/fsl}/ucc_slow.h (99%)
So you should be moving things to drivers/soc/fsl/qe/ not drivers/soc/fsl-qe/
The headers should be in include/soc/fsl, not include/linux/fsl
In addition before this move is accepted, other changes need to be made to
convert to using standard frameworks for various functionality in QE lib.
1. gpio.c -> needs to be converted to GPIO framework and placed in drivers/gpio
2. qe_ic* should probably move into drivers/irqchip
3. qe_io.c should be converted over t
Re: [PATCH v3 1/3] QE: move qe code from arch/powerpc to drivers/soc
On Oct 31, 2014, at 2:24 AM, qiang.z...@freescale.com wrote:
> On Oct 30, 2014, at 9:37 AM, Kumar Gala wrote:
>
>
>> -Original Message-
>> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
>> Sent: Thursday, October 30, 2014 9:37 PM
>> To: Zhao Qiang-B45475
>> Cc: linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org; Wood
>> Scott-B07421; Xie Xiaobo-R63061
>> Subject: Re: [PATCH v3 1/3] QE: move qe code from arch/powerpc to
>> drivers/soc
>>
>>
>> On Oct 30, 2014, at 2:31 AM, Zhao Qiang wrote:
>>
>>> LS1 is arm cpu and it has qe ip block.
>>> move qe code from platform directory to public directory.
>>>
>>> QE is an IP block integrates several comunications peripheral
>>> controllers. It can implement a variety of applications, such as uart,
>>> usb and tdm and so on.
>>>
>>> Signed-off-by: Zhao Qiang
>>> ---
>>> Changes for v2:
>>> - move code to driver/soc
>>> Changes for v3:
>>> - change drivers/soc/qe to drivers/soc/fsl-qe
>>>
>>> arch/powerpc/Kconfig | 2 -
>>> arch/powerpc/platforms/83xx/km83xx.c | 4 +-
>>> arch/powerpc/platforms/83xx/misc.c | 2 +-
>>> arch/powerpc/platforms/83xx/mpc832x_mds.c | 4 +-
>>> arch/powerpc/platforms/83xx/mpc832x_rdb.c | 4 +-
>>> arch/powerpc/platforms/83xx/mpc836x_mds.c | 4 +-
>>> arch/powerpc/platforms/83xx/mpc836x_rdk.c | 4 +-
>>> arch/powerpc/platforms/85xx/common.c | 2 +-
>>> arch/powerpc/platforms/85xx/corenet_generic.c | 2 +-
>>> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 4 +-
>>> arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 4 +-
>>> arch/powerpc/platforms/85xx/twr_p102x.c| 4 +-
>>> arch/powerpc/platforms/Kconfig | 19 -
>>> arch/powerpc/sysdev/Makefile | 1 -
>>> arch/powerpc/sysdev/qe_lib/Kconfig | 27 -
>>> drivers/net/ethernet/freescale/fsl_pq_mdio.c | 2 +-
>>> drivers/net/ethernet/freescale/ucc_geth.c | 8 ++--
>>> drivers/net/ethernet/freescale/ucc_geth.h | 8 ++--
>>> drivers/soc/Kconfig| 2 +
>>> drivers/soc/Makefile | 1 +
>>> drivers/soc/fsl-qe/Kconfig | 45
>> ++
>>> .../sysdev/qe_lib => drivers/soc/fsl-qe}/Makefile | 0
>>> .../sysdev/qe_lib => drivers/soc/fsl-qe}/gpio.c| 2 +-
>>> .../sysdev/qe_lib => drivers/soc/fsl-qe}/qe.c | 4 +-
>>> .../sysdev/qe_lib => drivers/soc/fsl-qe}/qe_ic.c | 2 +-
>>> .../sysdev/qe_lib => drivers/soc/fsl-qe}/qe_ic.h | 2 +-
>>> .../sysdev/qe_lib => drivers/soc/fsl-qe}/qe_io.c | 2 +-
>>> .../sysdev/qe_lib => drivers/soc/fsl-qe}/ucc.c | 6 +--
>>> .../qe_lib => drivers/soc/fsl-qe}/ucc_fast.c | 8 ++--
>>> .../qe_lib => drivers/soc/fsl-qe}/ucc_slow.c | 8 ++--
>>> .../sysdev/qe_lib => drivers/soc/fsl-qe}/usb.c | 4 +-
>>> drivers/spi/spi-fsl-cpm.c | 2 +-
>>> drivers/tty/serial/ucc_uart.c | 2 +-
>>> drivers/usb/gadget/fsl_qe_udc.c| 2 +-
>>> drivers/usb/host/fhci-hcd.c| 2 +-
>>> drivers/usb/host/fhci-hub.c| 2 +-
>>> drivers/usb/host/fhci-sched.c | 2 +-
>>> drivers/usb/host/fhci.h| 4 +-
>>> .../include/asm => include/linux/fsl}/immap_qe.h | 0
>>> .../powerpc/include/asm => include/linux/fsl}/qe.h | 2 +-
>>> .../include/asm => include/linux/fsl}/qe_ic.h | 0
>>> .../include/asm => include/linux/fsl}/ucc.h| 4 +-
>>> .../include/asm => include/linux/fsl}/ucc_fast.h | 6 +--
>>> .../include/asm => include/linux/fsl}/ucc_slow.h | 6 +--
>>> 44 files changed, 112 insertions(+), 113 deletions(-) delete mode
>>> 100644 arch/powerpc/sysdev/qe_lib/Kconfig
>>> create mode 100644 drivers/soc/fsl-qe/Kconfig rename
>>> {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/Makefile (100%)
>>> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/gpio.c (99%)
>>> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/qe.c (99%)
>>> rename {arch/powerpc/sysdev/qe_lib => drivers/soc/fsl-qe}/qe_ic.c
>>
Re: [PATCH] powerpc/fsl-pci: don't unmap the PCI SoC controller registers in setup_pci_atmu
On Apr 13, 2013, at 2:14 AM, Kevin Hao wrote: > In patch 34642bbb (powerpc/fsl-pci: Keep PCI SoC controller registers in > pci_controller) we choose to keep the map of the PCI SoC controller > registers. But we missed to delete the unmap in setup_pci_atmu > function. This will cause the following call trace once we access > the PCI SoC controller registers later. > > Unable to handle kernel paging request for data at address 0x880080040f14 > Faulting instruction address: 0xc002ea58 > Oops: Kernel access of bad area, sig: 11 [#1] > SMP NR_CPUS=24 T4240 QDS > Modules linked in: > NIP: c002ea58 LR: c002eaf4 CTR: c002eac0 > REGS: c0017e10b4a0 TRAP: 0300 Not tainted > (3.9.0-rc1-00052-gfa3529f-dirty) > MSR: 80029000 CR: 28adbe22 XER: > SOFTE: 0 > DEAR: 880080040f14, ESR: > TASK = c0017e10[1] 'swapper/0' THREAD: c0017e108000 CPU: 2 > GPR00: c0017e10b720 c09928d8 c0017e578e00 > GPR04: 000c 0001 c0017e10bb40 > GPR08: 88008004 0016 > GPR12: 88adbe22 cfffa800 c0001ba0 > GPR16: > GPR20: c08a5b70 > GPR24: c08af938 c09a28d8 c09bb5dc c0017e10bb40 > GPR28: c0017e32a400 c0017e10bc00 c0017e32a400 c0017e578e00 > NIP [c002ea58] .fsl_pcie_check_link+0x88/0xf0 > LR [c002eaf4] .fsl_indirect_read_config+0x34/0xb0 > Call Trace: > [c0017e10b720] [c0017e10b7a0] 0xc0017e10b7a0 (unreliable) > [c0017e10ba30] [c002eaf4] .fsl_indirect_read_config+0x34/0xb0 > [c0017e10bad0] [c033aa08] .pci_bus_read_config_byte+0x88/0xd0 > [c0017e10bb90] [c088d708] .pci_apply_final_quirks+0x9c/0x18c > [c0017e10bc40] [c00013dc] .do_one_initcall+0x5c/0x1f0 > [c0017e10bcf0] [c086ebac] .kernel_init_freeable+0x180/0x26c > [c0017e10bdb0] [c0001bbc] .kernel_init+0x1c/0x460 > [c0017e10be30] [c880] .ret_from_kernel_thread+0x64/0xe4 > Instruction dump: > 38210310 2b800015 4fdde842 7c600026 5463fffe e8010010 7c0803a6 4e800020 > 6000 6000 e92301d0 7c0004ac <80690f14> 0c03 4c00012c 38210310 > ---[ end trace 7a8fe0cbccb7d992 ]--- > > Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b > > Signed-off-by: Kevin Hao > --- > This is based on Kumar's next branch. > > arch/powerpc/sysdev/fsl_pci.c | 7 ++- > 1 file changed, 2 insertions(+), 5 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl-booke: add the reg property for pci bridge device node for t4/b4xx boards
On Apr 14, 2013, at 12:40 AM, Kevin Hao wrote: > The reg property in the pci bridge device node is used to bind this > device node to the pci bridge device. Then all the pci devices under > this bridge could use the interrupt maps defined in this device node > to do the irq translation. So if this property is missed, the pci > traditional irq mechanism will not work. > > Signed-off-by: Kevin Hao > --- > arch/powerpc/boot/dts/fsl/b4si-post.dtsi| 1 + > arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 4 > 2 files changed, 5 insertions(+) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/dts: Fix the dts for p1025rdb 36bit
On Mar 24, 2013, at 8:23 PM, Zhicheng Fan wrote: > fix the following errors: > Error: arch/powerpc/boot/dts/p1025rdb.dtsi:326.2-3 label or path, 'qe', > not found > Error: arch/powerpc/boot/dts/fsl/p1021si-post.dtsi:242.2-3 label or > path, 'qe', not found > FATAL ERROR: Syntax error parsing input tree > > Signed-off-by: Zhicheng Fan > --- > arch/powerpc/boot/dts/p1025rdb_36b.dts |5 + > 1 files changed, 5 insertions(+), 0 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git next branch
Ben, Add support for T4 and B4 SoC families from Freescale, e6500 altivec support, some various board fixes and other minor cleanups. - k The following changes since commit 54c9b2253d34e8998e4bff9ac2d7a3ba0b861d52: powerpc: Set DSCR bit in FSCR setup (2013-03-05 16:56:30 +1100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git next for you to fetch changes up to 9e2ecdbba3b0745f9ed454ab86961e3ccf9dc224: powerpc/fsl-booke: add the reg prop for pci bridge device node for T4/B4 (2013-04-29 14:47:25 -0500) Ben Collins (1): powerpc/85xx: sgy-cts1000 - Remove __dev* attributes Chen-Hui Zhao (1): powerpc/85xx: fix a bug with the parameter of mpic_reset_core() Jia Hongtao (1): powerpc/85xx: Add platform_device declaration to fsl_pci.h Jiucheng Xu (1): powerpc/85xx: Reserve a partition of NOR flash for QE ucode firmware Kevin Hao (2): powerpc/fsl-pci: don't unmap the PCI SoC controller registers in setup_pci_atmu powerpc/fsl-booke: add the reg prop for pci bridge device node for T4/B4 Kumar Gala (11): powerpc/fsl-booke: Support detection of page sizes on e6500 powerpc/85xx: Add AltiVec support for e6500 powerpc/fsl-booke: Add initial silicon device tree for T4240 powerpc/fsl-booke: Add initial T4240QDS board device tree powerpc/fsl-booke: Add initial T4240QDS board support powerpc/85xx: Update corenet64_smp_defconfig for T4240 powerpc/qe: Fix Kconfig enablement of QE_USB support powerpc/fsl-booke: Update T4240 device config node in device tree powerpc/fsl-booke: Minor fixes to T4240 Si device tree powerpc/fsl-pci: Keep PCI SoC controller registers in pci_controller powerpc/85xx: Fix MPC8536DS 36-bit device tree Paul Bolle (2): powerpc: remove "config 8260_PCI9" powerpc: remove "config MPC10X_OPENPIC" Prabhakar Kushwaha (1): powerpc: add CONFIG(s) require for using flash controller Ramneek Mehresh (1): powerpc/85xx: Add first usb controller node for Qonverge platforms Rojhalat Ibrahim (1): powerpc/fsl-pci Make PCIe hotplug work with Freescale PCIe controllers Roy ZANG (2): powerpc/85xx: Add support for FSL PCIe controller v3.0 powerpc/85xx: enable Silicon image 3132 PCIe to SATA controller Roy Zang (2): powerpc/85xx: enable E1000 NIC to mpc85xx_defconfig powerpc/fsl_pci: fix 64 bit pci size issue Scott Wood (1): powerpc/85xx: add CONFIG_E1000E to corenet64_smp_defconfig Sebastian Andrzej Siewior (1): powerpc/fsl-msi: use a different lockclass for the cascade interrupt Shaveta Leekha (5): powerpc/85xx: add SEC-5.3 device tree powerpc/fsl-booke: Add initial silicon device tree files for B4860 and B4420 powerpc/fsl-booke: Add initial B4860QDS and B4420QDS board device tree powerpc/fsl-booke: Add B4_QDS board support powerpc/85xx: Update corenet64_smp_defconfig for B4_QDS Stephen George (2): powerpc/fsl-booke: Added device tree DCSR entries for T4240 Chassis v2 Debug IP powerpc/fsl-booke: Update DCSR EPU device tree entries for existing SoCs Stuart Yoder (3): powerpc/e6500: Add architecture categories for e6500 cores powerpc: add missing deo arch category to e500mc/e5500 dts powerpc: Add paravirt idle loop for 64-bit Book-E Tang Yuantian (1): powerpc/fsl: remove the PPC_CLOCK dependency Vakul Garg (3): powerpc/85xx: Added SEC-5.0 device tree. powerpc/fsl: removed qoriq-sec4.1-0.dtsi. powerpc/fsl: Add property for 'era' in SEC dts crypto node Zhicheng Fan (1): powerpc/dts: Fix the dts for p1025rdb 36bit .../devicetree/bindings/powerpc/fsl/cpus.txt | 22 + arch/powerpc/Kconfig | 6 - arch/powerpc/boot/dts/b4420qds.dts | 50 +++ arch/powerpc/boot/dts/b4860qds.dts | 61 +++ arch/powerpc/boot/dts/b4qds.dts| 169 arch/powerpc/boot/dts/fsl/b4420si-post.dtsi| 98 + arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi | 73 arch/powerpc/boot/dts/fsl/b4860si-post.dtsi| 142 +++ arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi | 83 arch/powerpc/boot/dts/fsl/b4si-post.dtsi | 268 + arch/powerpc/boot/dts/fsl/e500mc_power_isa.dtsi| 1 + arch/powerpc/boot/dts/fsl/e5500_power_isa.dtsi | 1 + arch/powerpc/boot/dts/fsl/e6500_power_isa.dtsi | 65 +++ arch/powerpc/boot/dts/fsl/p1023si-post.dtsi| 1 + arch/powerpc/boot/dts/fsl/p2041si-post.dtsi| 2 +- arch/powerpc/boot/dts/fsl/p3041si-post.dtsi| 2 +- arch/powerpc/boot/dts/fsl/p4080si-post.dtsi| 2 +- arch/powerpc/boot/dts/fsl/p5020si-post.dtsi| 2 +- arch/powerpc/boot/dts/fsl/p5040si-post.dtsi| 2 +- arch/pow
Re: [PATCH] powerpc/mpc85xx: match with the pci bus address used by u-boot for all p1_p2_rdb_pc boards
On May 28, 2013, at 5:45 PM, Scott Wood wrote: > On 05/16/2013 01:29:45 AM, Kevin Hao wrote: >> All these boards use the same configuration file p1_p2_rdb_pc.h in >> u-boot. So they have the same pci bus address set by the u-boot. >> But in some of these boards the bus address set in dtb don't match >> the one used by u-boot. And this will trigger a kernel bug in 32bit >> kernel and cause the pci device malfunction. For example, on a >> p2020rdb-pc board the u-boot use the 0xa000 as both bus address >> and cpu address for one pci controller and then assign bus address >> such as 0xa4000 to some pci device. But in the kernel, the dtb >> set the bus address to 0xe000 and the cpu address to 0xa000. >> The kernel assumes mistakenly the assigned bus address 0xa0004000 >> in pci device is correct and keep it unchanged. This will definitely >> cause the pci device malfunction. I have made two patches to fix >> this in the pci subsystem. >> http://patchwork.ozlabs.org/patch/243702/ >> http://patchwork.ozlabs.org/patch/243703/ >> But I still think it makes sense to set these bus address to match >> with the u-boot. This issue can't be reproduced on 36bit kernel. >> But I also tweak the 36bit dtb for the above reason. > > IIRC the reason for using 0xe000 on all PCIe roots is to maximize the > memory that is DMA-addressable without involving swiotlb. > > Maybe U-Boot should be fixed? > > -Scott I feel that u-boot was the way it is to allow accessing each bus from the command line in u-boot w/o big changes for >32-bit addressing. Linux was able to handle the PCI bus addresses all being the same. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] clk/mpc85xx: Update the compatible string
On May 30, 2013, at 2:21 PM, Mike Turquette wrote: > Quoting Mike Turquette (2013-05-30 11:57:32) >> Quoting yuantian.t...@freescale.com (2013-05-22 01:22:19) >>> From: Tang Yuantian >>> >>> The compatible string of clock is changed from *-2 to *-2.0 >>> on chassis 2. So updated it accordingly. >>> >>> Signed-off-by: Tang Yuantian >> >> Taken into clk-next. >> > > One small nitpick. I updated the $SUBJECT to: > > clk: mpc85xx: Update the compatible string > > The difference being "clk: mpc85xx:" versus "clk/mpc85xx:". Please use > the former format in the future. > > Thanks, > Mike Mike, If clk-ppc-corenet.c went into v3.10, than I think this fix is needed there and shouldn't wait til v3.11 - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: fsqrt
On Jun 7, 2013, at 7:14 AM, Benjamin Herrenschmidt wrote: > On Fri, 2013-06-07 at 11:48 +0100, David Laight wrote: >>> For those interested, this is the Quake3 sqrt from Carmack ... >> there's >>> plenty of literature about it one or two google clicks away :-) >> >> I guess that is a rough enough approximation for graphics. >> >> However it will be miscompiled unless i and y are put in a union. > > It won't in the kernel disables strict aliasing :-) > > Anyway, that was just a hack and plenty enough to get anaconda going, > the bloody thing only uses fsqrt because it's python crappola does > something like exp(1.0) / sqrt(2.0) as part of its random number stuff. > > Honestly I could have made it just return 1.0 and it would probably have > worked :-) > > However, my point remains, it would be very much worthwhile for the > kernel to have some reasonable emulation of those missing instructions > (afaik only a handful) like we have for isel, popcnt* etc... especially > since distros seem to be keen on enabling the use of them in their > toolchain. > > I don't personally have the bandwidth to do a clean implementation (that > handles FP exceptions, NaNs, FPSCR, etc...) but I believe it would be > valuable if somebody else did (hint hint hint :-) since without this, > Fedora ppc64 is basically going to be a non-started on those chips. > > BTW. Did you guys (ie. FSL) finally add fsqrt to e6500 or it's still > out ? > > Cheers, > Ben. Pretty sure fsqrt is still out of e6500. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Pull request: scottwood/linux.git for-3.10
On Jun 18, 2013, at 3:14 PM, Scott Wood wrote: > This fixes a regression that causes 83xx to oops on boot if a > non-express PCI bus is present. > > The following changes since commit 17858ca65eef148d335ffd4cfc09228a1c1cbfb5: > > Merge tag 'please-pull-fixia64' of > git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux (2013-06-18 06:29:19 > -1000) > > are available in the git repository at: > > > git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git for-3.10 > > for you to fetch changes up to 2383ea94854bcf5a0df3c6803b980868cef95418: > > powerpc/pci: Fix setup of Freescale PCI / PCIe controllers (2013-06-18 > 14:44:57 -0500) > > > Rojhalat Ibrahim (1): > powerpc/pci: Fix setup of Freescale PCI / PCIe controllers > > arch/powerpc/sysdev/fsl_pci.c | 24 +--- > 1 file changed, 9 insertions(+), 15 deletions(-) What about Rohit's patch: powerpc/pci: Fix setup of Freescale PCI / PCIe controllers? Seems like also a fix for 3.10 - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 1/2] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
On Jul 5, 2013, at 1:27 AM,
wrote:
> From: Hongbo Zhang
>
> Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch add
> the device tree nodes for them.
>
> Signed-off-by: Hongbo Zhang
> ---
> arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 90 +++
> arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 90 +++
> arch/powerpc/boot/dts/fsl/t4240si-post.dtsi |4 +-
> 3 files changed, 182 insertions(+), 2 deletions(-)
> create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
> create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
>
> diff --git a/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
> b/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
> new file mode 100644
> index 000..50cd911
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
> @@ -0,0 +1,90 @@
> +/*
> + * QorIQ DMA device tree stub [ controller @ offset 0x10 ]
> + *
> + * Copyright 2011-2013 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.
> + */
> +
> +dma0: dma@100300 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "fsl,elo3-dma";
why does this require a new compatible?
> + reg = <0x100300 0x4 0x100600 0x4>;
> + ranges = <0x0 0x100100 0x500>;
> + cell-index = <0>;
> + dma-channel@0 {
> + compatible = "fsl,eloplus-dma-channel";
> + reg = <0x0 0x80>;
> + cell-index = <0>;
> + interrupts = <28 2 0 0>;
> + };
> + dma-channel@80 {
> + compatible = "fsl,eloplus-dma-channel";
> + reg = <0x80 0x80>;
> + cell-index = <1>;
> + interrupts = <29 2 0 0>;
> + };
> + dma-channel@100 {
> + compatible = "fsl,eloplus-dma-channel";
> + reg = <0x100 0x80>;
> + cell-index = <2>;
> + interrupts = <30 2 0 0>;
> + };
> + dma-channel@180 {
> + compatible = "fsl,eloplus-dma-channel";
> + reg = <0x180 0x80>;
> + cell-index = <3>;
> + interrupts = <31 2 0 0>;
> + };
> + dma-channel@300 {
> + compatible = "fsl,eloplus-dma-channel";
> + reg = <0x300 0x80>;
> + cell-index = <4>;
> + interrupts = <76 2 0 0>;
> + };
> + dma-channel@380 {
> + compatible = "fsl,eloplus-dma-channel";
> + reg = <0x380 0x80>;
> + cell-index = <5>;
> + interrupts = <77 2 0 0>;
> + };
> + dma-channel@400 {
> + compatible = "fsl,eloplus-dma-channel";
> + reg = <0x400 0x80>;
> + cell-index = <6>;
> + interrupts = <78 2 0 0>;
> + };
> + dma-channel@480 {
> + compatible = "fsl,eloplus-dma-channel";
> + reg = <0x480 0x80>;
> + cell-index = <7>;
> + interrupts = <79 2 0 0>;
> + };
> +};
> diff --git a/arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
> b/arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
> new file mode 100644
> index 000..c1aec68
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
> @@ -0,0 +1,90 @@
> +/*
> + * QorIQ
Re: [PATCH V2 1/2] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
On Jul 5, 2013, at 1:27 AM, wrote: > From: Hongbo Zhang > > Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch add > the device tree nodes for them. > > Signed-off-by: Hongbo Zhang > --- > arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 90 +++ > arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 90 +++ > arch/powerpc/boot/dts/fsl/t4240si-post.dtsi |4 +- > 3 files changed, 182 insertions(+), 2 deletions(-) > create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi > create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi Why didn't you update b4si-post.dtsi as well? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4 V2] mmc: esdhc: Correct host version of T4240-R1.0
On Jul 17, 2013, at 5:11 AM, Haijun Zhang wrote:
> Vender version and sdhc spec version of T4240-R1.0 is incorrect.
> The right value should be VVN=0x13, SVN = 0x1. The wrong version
> number will break down the ADMA data transfer.
> This defect only exist in T4240-R1.0. Will be fixed in T4240-R2.0.
> Also share vvn and svr for public use.
>
> Signed-off-by: Haijun Zhang
> ---
> changes for V2:
> - Remove broken ADMA quirk.
> - Rebuild patch of Add quirks to support T4240 board
>
> drivers/mmc/host/sdhci-of-esdhc.c | 29 +
> 1 file changed, 13 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c
> b/drivers/mmc/host/sdhci-of-esdhc.c
> index adfaadd..570bca8 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -26,7 +26,7 @@
> #define VENDOR_V_22 0x12
> #define VENDOR_V_23 0x13
>
> -static u32 svr;
> +static u32 svr, vvn;
>
> static u32 esdhc_readl(struct sdhci_host *host, int reg)
> {
> @@ -43,11 +43,9 @@ static u32 esdhc_readl(struct sdhci_host *host, int reg)
>* For FSL eSDHC, must aligned 4-byte, so use 0xFC to read the
>* the verdor version number, oxFE is SDHCI_HOST_VERSION.
>*/
> - if ((reg == SDHCI_CAPABILITIES) && (ret & SDHCI_CAN_DO_ADMA1)) {
> - u32 tmp = in_be32(host->ioaddr + SDHCI_SLOT_INT_STATUS);
> - tmp = (tmp & SDHCI_VENDOR_VER_MASK) >> SDHCI_VENDOR_VER_SHIFT;
> - if (tmp > VENDOR_V_22)
> - ret |= SDHCI_CAN_DO_ADMA2;
> + if ((reg == SDHCI_CAPABILITIES) && (ret & SDHCI_CAN_DO_ADMA1) &&
> + (vvn > VENDOR_V_22)) {
> + ret |= SDHCI_CAN_DO_ADMA2;
> }
>
> return ret;
> @@ -63,6 +61,12 @@ static u16 esdhc_readw(struct sdhci_host *host, int reg)
> ret = in_be32(host->ioaddr + base) & 0x;
> else
> ret = (in_be32(host->ioaddr + base) >> shift) & 0x;
> +
> + /* T4240-R1.0 had a incorrect vendor version and spec version */
> + if ((reg == SDHCI_HOST_VERSION) &&
> + ((SVR_SOC_VER(svr) == SVR_T4240) && (SVR_REV(svr) == 0x10)))
> + ret = (VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) | SDHCI_SPEC_200;
> +
is this check correct if this is on v2.0 Si as well?
- k
> return ret;
> }
>
> @@ -175,17 +179,12 @@ static void esdhc_reset(struct sdhci_host *host, u8
> mask)
> */
> static void esdhci_of_adma_workaround(struct sdhci_host *host, u32 intmask)
> {
> - u32 tmp;
> bool applicable;
> dma_addr_t dmastart;
> dma_addr_t dmanow;
>
> - tmp = esdhc_readl(host, SDHCI_SLOT_INT_STATUS);
> - tmp = (tmp & SDHCI_VENDOR_VER_MASK) >> SDHCI_VENDOR_VER_SHIFT;
> -
> applicable = (intmask & SDHCI_INT_DATA_END) &&
> - (intmask & SDHCI_INT_BLK_GAP) &&
> - (tmp == VENDOR_V_23);
> + (intmask & SDHCI_INT_BLK_GAP) && (vvn == VENDOR_V_23);
> if (applicable) {
>
> esdhc_reset(host, SDHCI_RESET_DATA);
> @@ -318,10 +317,9 @@ static void esdhc_of_resume(struct sdhci_host *host)
>
> static void esdhc_of_platform_init(struct sdhci_host *host)
> {
> - u32 vvn;
> + svr = mfspr(SPRN_SVR);
> + vvn = esdhc_readw(host, SDHCI_HOST_VERSION);
>
> - vvn = in_be32(host->ioaddr + SDHCI_SLOT_INT_STATUS);
> - vvn = (vvn & SDHCI_VENDOR_VER_MASK) >> SDHCI_VENDOR_VER_SHIFT;
> if (vvn == VENDOR_V_22)
> host->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;
>
> @@ -390,7 +388,6 @@ static int sdhci_esdhc_probe(struct platform_device *pdev)
> struct device_node *np;
> int ret;
>
> - svr = mfspr(SPRN_SVR);
> host = sdhci_pltfm_init(pdev, &sdhci_esdhc_pdata, 0);
> if (IS_ERR(host))
> return PTR_ERR(host);
> --
> 1.8.0
>
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: split the math emulation into two parts
On Jul 16, 2013, at 6:57 AM, Kevin Hao wrote: > For some SoC (such as the FSL BookE) even though there does have > a hardware FPU, but not all floating point instructions are > implemented. Unfortunately some versions of gcc do use these > unimplemented instructions. Then we have to enable the math emulation > to workaround this issue. It seems a little redundant to have the > support to emulate all the floating point instructions in this case. > So split the math emulation into two parts. One is for the SoC which > doesn't have FPU at all and the other for the SoC which does have the > hardware FPU and only need some special floating point instructions to > be emulated. > > Signed-off-by: Kevin Hao > --- > arch/powerpc/Kconfig | 20 > arch/powerpc/math-emu/Makefile | 24 > arch/powerpc/math-emu/math.c | 20 ++-- > 3 files changed, 46 insertions(+), 18 deletions(-) why make the split, what harm is there in just turning on the full emulation code to handle the unimplemented cases? who says what some other implementation doesn't need something that you have in CONFIG_MATH_EMULATION_FULL? Is the kernel code size really an issue? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] Powerpc: Add voltage ranges support for T4
On Jul 22, 2013, at 4:47 AM, Wrobel Heinz-R39252 wrote:
>> Subject: [PATCH 1/2] Powerpc: Add voltage ranges support for T4
>>
>> Special voltages that can be support by eSDHC of T4 in esdhc node.
>>
>> Signed-off-by: Haijun Zhang
>> Signed-off-by: Anton Vorontsov
>
>> --- a/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt
>> +++ b/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt
>> @@ -19,6 +19,8 @@ Optional properties:
>> "bus-width = <1>" property.
>> - sdhci,auto-cmd12: specifies that a controller can only handle auto
>> CMD12.
>> + - 3300 3300: specifies that eSDHC controller can support voltages
>> ranges
>> +from 3300 to 3300. This is an optional.
>
> "This is an optional." is an unclear statement.
>
>> +++ b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
>> @@ -399,6 +399,7 @@
>> sdhc@114000 {
>> compatible = "fsl,t4240-esdhc", "fsl,esdhc";
>> sdhci,auto-cmd12;
>> +voltage-ranges = <1800 1800 3300 3300>;
>
> This is IMHO incorrect and potentially dangerous.
> The T4 silicon will only support 1.8V on SDHC pins per hardware specification.
> The Freescale T4240QDS reference board has extra voltage shifters added to
> allow 3.3V operation, but that is _not_ a silicon feature. It is a specific
> board feature that may or may not translate to other boards, depending on how
> SD spec conformant a board builder wants to be.
>
> If the intent is to state that a physical SDHC interface on a board has to be
> built to support 3.3V operation to be SD spec conformant for off-the-shelf
> cards because a reset would change the signal voltage to 3.3V, then I am not
> sure that putting this down as silicon "feature" without further explanation
> about the background anywhere is the right way to go.
> IMHO silicon features are really just silicon features and not technically
> optional external circuitry additions implied by common use.
>
> Best regards,
>
> Heinz
I'd say that the t4240si-post.dtsi should be:
voltage-ranges = <1800 1800>;
Than have the t4240qds.dts do:
voltage-ranges = <1800 1800 3300 3300>;
As the 3.3V sounds like a board specific feature.
[ send this as 2 patches, on for the t4240si-post.dtsi and another for the
t4240qds.dts ]
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: Update compilation flags with core specific options
On Jul 25, 2013, at 6:54 AM, Catalin Udma wrote: > If CONFIG_E500 is enabled, the compilation flags are updated > specifying the target core -mcpu=e5500/e500mc/8540 > Also remove -Wa,-me500, being incompatible with -mcpu=e5500/e6500 > The assembler option is redundant if the -mcpu= flag is set. > The patch fixes the kernel compilation problem for e5500/e6500 > when using gcc option -mcpu=e5500/e6500. > > Signed-off-by: Catalin Udma > --- > changes for v2: >- update also KBUILD_AFLAGS with -mcpu and -msoft-float flags > > arch/powerpc/Makefile | 16 +++- > 1 files changed, 15 insertions(+), 1 deletions(-) Is the assembler redundant for older toolchains? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: Convert platforms to smp_generic_cpu_bootable
On Jul 25, 2013, at 5:02 PM, Andy Fleming wrote: > T4, Cell, powernv, and pseries had the same implementation, so switch > them to use a generic version. A2 apparently had a version, but > removed it at some point, so we remove the declaration, too. > > Signed-off-by: Andy Fleming > > Conflicts: > > arch/powerpc/platforms/cell/smp.c > arch/powerpc/platforms/powernv/smp.c > arch/powerpc/platforms/pseries/smp.c > > Change-Id: If12e2f83f7187ee5982dca9f89c68e0600f0cc49 clean this up for sending upstream. - k > --- > arch/powerpc/platforms/85xx/smp.c|1 + > arch/powerpc/platforms/cell/smp.c| 15 +-- > arch/powerpc/platforms/powernv/smp.c | 18 +- > arch/powerpc/platforms/pseries/smp.c | 18 +- > arch/powerpc/platforms/wsp/wsp.h |1 - > 5 files changed, 4 insertions(+), 49 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Add device file bindings for MAPLE
On Aug 1, 2013, at 6:02 AM, Shaveta Leekha wrote:
> Signed-off-by: Shaveta Leekha
> ---
> .../devicetree/bindings/powerpc/fsl/maple.txt | 30
> 1 files changed, 30 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/maple.txt
>
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/maple.txt
> b/Documentation/devicetree/bindings/powerpc/fsl/maple.txt
> new file mode 100644
> index 000..da51c5f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/maple.txt
> @@ -0,0 +1,30 @@
> +* Freescale MAPLE Multi Accelerator Platform Engine Baseband 3
> + (MAPLE-B3)device nodes
> +
> +Supported chips:
> +Example: B4860
> +
> +Required properties:
> +
> +- compatible:Should contain "fsl,maple-b3-liodn" as the value
> + This identifies Multi Accelerator Platform Engine
> + Baseband 3 block.This representation is required
> + for doing the PAMU/LIODN programming on the Linux side.
This compatible makes no sense, we shouldn't be marking a full HW block with
some name that is just intended for LIODN convenance.
Is this version 3 of the block? If so a name like "fsl,maple-v3" or
"fsl,maple-v3.0" would be more appropriate.
- k
> +
> +- reg: offset and length of the register set for the device
> +
> +Devices that have LIODNs need to specify links to the parent PAMU controller
> +(the actual PAMU controller that this device is connected to) and a pointer
> to
> +the LIODN register, if applicable.
Does Maple not have any IRQs associated with it?
If you are going to have a minimal binding, at least cover the basics
associated with a device.
> +
> +- fsl,iommu-parent
> + :
> + This property should be present
> +
> +Example:
> + /* B4860 */
> + maple@80 {
> + compatible = "fsl,maple-b3-liodn";
> + reg = <0x800 0x1>;
> + fsl,iommu-parent = <&pamu1>;
> + };
> --
> 1.7.6.GIT
>
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Add device file bindings for MAPLE
On Aug 5, 2013, at 4:11 PM, Scott Wood wrote: > On Thu, 2013-08-01 at 11:05 -0500, Kumar Gala wrote: >> On Aug 1, 2013, at 6:02 AM, Shaveta Leekha wrote: >> >>> Signed-off-by: Shaveta Leekha >>> --- >>> .../devicetree/bindings/powerpc/fsl/maple.txt | 30 >>> >>> 1 files changed, 30 insertions(+), 0 deletions(-) >>> create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/maple.txt >>> >>> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/maple.txt >>> b/Documentation/devicetree/bindings/powerpc/fsl/maple.txt >>> new file mode 100644 >>> index 000..da51c5f >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/powerpc/fsl/maple.txt >>> @@ -0,0 +1,30 @@ >>> +* Freescale MAPLE Multi Accelerator Platform Engine Baseband 3 >>> + (MAPLE-B3)device nodes >>> + >>> +Supported chips: >>> +Example: B4860 >>> + >>> +Required properties: >>> + >>> +- compatible: Should contain "fsl,maple-b3-liodn" as the value >>> + This identifies Multi Accelerator Platform Engine >>> + Baseband 3 block.This representation is required >>> + for doing the PAMU/LIODN programming on the Linux side. >> >> This compatible makes no sense, we shouldn't be marking a full HW block with >> some name that is just intended for LIODN convenance. > > The point is we're not describing the whole block here, because the rest > of the block is owned by an external entity (the DSP cores). So the binding should make that far more clear that the MAPLE would be controlled by DSP SW. > >> Is this version 3 of the block? If so a name like "fsl,maple-v3" or >> "fsl,maple-v3.0" would be more appropriate. >> >> - k >> >>> + >>> +- reg: offset and length of the register set for the device >>> + So the reg should limit itself to the LIODN registers only. >>> +Devices that have LIODNs need to specify links to the parent PAMU >>> controller >>> +(the actual PAMU controller that this device is connected to) and a >>> pointer to >>> +the LIODN register, if applicable. >> >> >> Does Maple not have any IRQs associated with it? > > maple-liodn doesn't. > > -Scott > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 00/31] add COMMON_CLK support for PowerPC MPC512x
On Aug 6, 2013, at 3:43 PM, Gerhard Sittig wrote:
> this series
> - fixes several drivers that are used in the MPC512x platform (UART,
> SPI, ethernet, PCI, USB, CAN, NAND flash, video capture) in how they
> handle clocks (appropriately acquire and setup them, hold references
> during use, release clocks after use)
> - introduces support for the common clock framework (CCF, COMMON_CLK
> Kconfig option) in the PowerPC based MPC512x platform, which brings
> device tree based clock lookup as well
>
> although the series does touch several subsystems -- tty (serial), spi,
> net (can, fs_enet), mtd (nfc), usb, i2c, media (viu), and dts -- all of
> the patches are strictly clock related or trivial
>
> it appears most appropriate to take this series through either the clk
> or the powerpc trees after it has passed review and other subsystem
> maintainers ACKed the clock setup related driver modifications
>
> the series passes 'checkpatch.pl --strict' except for one warning which
> cannot get resolved, since that either breaks compilation (the data type
> is preset by the clk-provider.h API) or requires a cast which shadows
> real mismatches:
>
> WARNING: static const char * array should probably be static const char *
> const
> #431: FILE: arch/powerpc/platforms/512x/clock-commonclk.c:334:
> +static const char *parent_names_mux0[] = {
>
> total: 0 errors, 1 warnings, 0 checks, 807 lines checked
>
> each step in the series was build and run tested (with a display that is
> attached to the DIU as well as SPI, with an SPI attached NOR flash, with
> multiple UART ports such that one is not the boot console, with EEPROMs
> attached to I2C, with an SD card, booting from network)
>
How do the driver changes impact other PPC SoCs that use the same drivers (i2c,
fs_enet, usb) ?
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100.
On Aug 7, 2013, at 7:03 PM, Stephen N Chivers wrote: > Add support for the Motorola/Emerson MVME5100 Single Board Computer. > > The MVME5100 is a 6U form factor VME64 computer with: > >- A single MPC7410 or MPC750 CPU >- A HAWK Processor Host Bridge (CPU to PCI) and > MultiProcessor Interrupt Controller (MPIC) >- Up to 500Mb of onboard memory >- A M48T37 Real Time Clock (RTC) and Non-Volatile Memory chip >- Two 16550 compatible UARTS >- Two Intel E100 Fast Ethernets >- Two PCI Mezzanine Card (PMC) Slots >- PPCBug Firmware > > The HAWK PHB/MPIC is compatible with the MPC10x devices. > > There is no onboard disk support. This is usually provided by installing a > PMC > in first PMC slot. > > This patch revives the board support, it was present in early 2.6 > series kernels. The board support in those days was by Matt Porter of > MontaVista Software. > > CSC Australia has around 31 of these boards in service. The kernel in use > for the boards is based on 2.6.31. The boards are operated without disks > from a file server. > > This patch is based on linux-3.11-rc4 and has been boot tested. > > Signed-off-by: Stephen Chivers > --- > arch/powerpc/boot/dts/mvme5100.dts| 195 ++ > arch/powerpc/boot/mvme5100.c | 28 + > arch/powerpc/configs/mvme5100_defconfig | 2597 > + > arch/powerpc/platforms/embedded6xx/mvme5100.c | 288 +++ > 4 files changed, 3108 insertions(+), 0 deletions(-) Please look at fixing the white space issues you seem to have throughout this patch. Also, we don't take full defconfigs in the tree, look at 'make savedefconfig' - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC] powerpc: put the common parts of the ppc64*defconfigs in a Kconfig file
On Aug 9, 2013, at 1:24 AM, Stephen Rothwell wrote: > We cannot put the unsetting of config options in the Kconfig file, nor > the integer or string options. > > I checked that after this we get the same .config files generated (except > for the addition of the new PPC64_DEFCONFIG* config options. > > Any thoughts? > --- > arch/powerpc/Kconfig | 2 + > arch/powerpc/configs/Kconfig | 295 + > arch/powerpc/configs/ppc64_defconfig | 301 +- > arch/powerpc/configs/ppc64e_defconfig | 297 + > 4 files changed, 302 insertions(+), 593 deletions(-) > create mode 100644 arch/powerpc/configs/Kconfig Am I missing something here, isn't this a bit of a maintenance pain if symbol names change? Also, how much of a benefit is this? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Pull request: scottwood/linux.git next
On Aug 9, 2013, at 1:03 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2013-08-08 at 17:45 -0500, Scott Wood wrote:
>> The following changes since commit 3b2f64d00c46e1e4e9bd0bb9bb12619adac27a4b:
>>
>> Linux 3.11-rc2 (2013-07-21 12:05:29 -0700)
>>
>> are available in the git repository at:
>
> Next time, put a little blurb at the head of the pull request giving a
> rough highlight, like I do when I send a pull request to Linus.
>
> Thanks !
>
> Cheers,
> Ben.
Also, I think we should pull a few of the commits in here out and submit for
3.11
powerpc/msi: Fix compile error on mpc83xx
powerpc/fsl_msi: fix error return code in fsl_of_msi_probe()
powerpc/pci: fix PCI-e check link issue
- k
>
>> git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next
>>
>> for you to fetch changes up to c8db32c8669f7de05b820ee4934926405af52188:
>>
>> powerpc/e500: Update compilation flags with core specific options
>> (2013-08-07 18:49:44 -0500)
>>
>>
>> Catalin Udma (2):
>> powerpc/perf: increase the perf HW events to 6
>> powerpc/e500: Update compilation flags with core specific options
>>
>> Dongsheng Wang (1):
>> powerpc/mpc85xx: invalidate TLB after hibernation resume
>>
>> Haijun.Zhang (2):
>> powerpc/85xx: add P1020RDB-PD platform support
>> powerpc/85xx: add the P1020RDB-PD DTS support
>>
>> Hongtao Jia (3):
>> powerpc: Move opcode definitions from kvm/emulate.c to asm/ppc-opcode.h
>> powerpc/85xx: Add machine check handler to fix PCIe erratum on mpc85xx
>> powerpc/msi: Fix compile error on mpc83xx
>>
>> Ian Campbell (1):
>> powerpc/fsl-booke: Rename b4qds.dts -> b4qds.dtsi.
>>
>> Kevin Hao (3):
>> powerpc/mpc85xx: remove the unneeded pci init functions for corenet ds
>> board
>> powerpc/fsl-pci: fix the unreachable warning message
>> powerpc/fsl-pci: enable SWIOTLB in function setup_pci_atmu
>>
>> Laurentiu TUDOR (1):
>> powerpc/85xx: Move ePAPR paravirt initialization earlier
>>
>> Lijun Pan (2):
>> powerpc/perf: correct typos in counter enumeration
>> powerpc/perf: add 2 additional performance monitor counters for e6500
>> core
>>
>> Minghuan Lian (3):
>> powerpc/dts: update MSI bindings doc for MPIC v4.3
>> powerpc/dts: add MPIC v4.3 dts node
>> powerpc/fsl_msi: add MSIIR1 support for MPIC v4.3
>>
>> Priyanka Jain (1):
>> powerpc/perf: Add e6500 PMU driver
>>
>> Wei Yongjun (1):
>> powerpc/fsl_msi: fix error return code in fsl_of_msi_probe()
>>
>> Yuanquan Chen (1):
>> powerpc/pci: fix PCI-e check link issue
>>
>> Zhenhua Luo (1):
>> powerpc/fsl: Enable CONFIG_DEVTMPFS_MOUNT so /dev can be mounted
>> correctly
>>
>> .../devicetree/bindings/powerpc/fsl/msi-pic.txt| 53 +++-
>> arch/powerpc/Makefile | 18 +-
>> arch/powerpc/boot/dts/b4420qds.dts | 2 +-
>> arch/powerpc/boot/dts/b4860qds.dts | 2 +-
>> arch/powerpc/boot/dts/{b4qds.dts => b4qds.dtsi}| 0
>> arch/powerpc/boot/dts/fsl/b4si-post.dtsi | 2 +-
>> arch/powerpc/boot/dts/fsl/qoriq-mpic4.3.dtsi | 149 +++
>> arch/powerpc/boot/dts/fsl/t4240si-post.dtsi| 2 +-
>> arch/powerpc/boot/dts/p1020rdb-pd.dts | 280
>> +
>> arch/powerpc/configs/85xx/p1023rds_defconfig | 1 +
>> arch/powerpc/configs/corenet32_smp_defconfig | 1 +
>> arch/powerpc/configs/corenet64_smp_defconfig | 1 +
>> arch/powerpc/configs/mpc83xx_defconfig | 1 +
>> arch/powerpc/configs/mpc85xx_defconfig | 1 +
>> arch/powerpc/configs/mpc85xx_smp_defconfig | 1 +
>> arch/powerpc/include/asm/epapr_hcalls.h| 6 +
>> arch/powerpc/include/asm/mpic.h| 7 +
>> arch/powerpc/include/asm/perf_event_fsl_emb.h | 2 +-
>> arch/powerpc/include/asm/ppc-opcode.h | 47
>> arch/powerpc/include/asm/reg_fsl_emb.h | 24 +-
>> arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
>> arch/powerpc/kernel/cputable.c | 2 +-
>> arch/powerpc/kernel/epapr_paravirt.c | 28 ++-
>> arch/powerpc/kernel/setup_32.c | 4 +-
>> arch/powerpc/kernel/setup_64.c | 3 +
>> arch/powerpc/kernel/swsusp_booke.S | 8 +
>> arch/powerpc/kernel/traps.c| 3 +
>> arch/powerpc/kvm/emulate.c | 45 +---
>> arch/powerpc/oprofile/op_model_fsl_emb.c | 30 +++
>> arch/powerpc/perf/Makefile | 2 +-
>> arch/powerpc/perf/core-fsl-emb.c | 30 +++
>> arch/powerpc/perf/e6500-pmu.c | 121 +
>> arch/powerpc/platforms/85xx/corenet_ds.c | 6 -
>> arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 22 ++
>> arch/powerpc/sysdev/fsl_msi.c
Re: [PATCH 1/3 V2] mmc:core: parse voltage from device-tree
On Jul 31, 2013, at 1:25 AM, Haijun Zhang wrote: > Add function to support get voltage from device-tree. > If there are voltage-range specified in device-tree node, this function > will parse it and return the avail voltage mask. > > Signed-off-by: Haijun Zhang > --- > changes for v2: > - Update the parameters of function > > drivers/mmc/core/core.c | 46 ++ > include/linux/mmc/core.h | 1 + > 2 files changed, 47 insertions(+) There should be a device tree binding spec update to go with this patch series. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Build errors on mainline kernel
On Aug 9, 2013, at 1:24 PM, Sukadev Bhattiprolu wrote:
>
> I am tryng to compile clean mainline kernel with a few different config files
> and running into errors with some configs.
>
> I am building on RHEL6.3 with following binaries:
>
> gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4)
> GNU ld version 2.20.51.0.2-5.34.el6 20100205
> binutils-2.20.51.0.2-5.34.el6.ppc64
> binutils-devel-2.20.51.0.2-5.34.el6.ppc64
>
> I am getting the error with several files and configs, but other configs
> (eg: ppc64_defconfig, pmac32_defconfig) build fine.
>
> For instance, with latest mainline kernel (commit 6c2580c) and
> ppc64_defconfig, I get:
>
> make O=linux-obj mrproper
> make O=linux-obj ppc64e_defconfig
> make O=linux-obj arch/powerpc/platforms/85xx/smp.o
> ...
>
> CC arch/powerpc/platforms/85xx/smp.o
> {standard input}: Assembler messages:
> {standard input}:240: Error: junk at end of line: `1'
> make[2]: *** [arch/powerpc/platforms/85xx/smp.o] Error 1
> make[1]: *** [arch/powerpc/platforms/85xx/smp.o] Error 2
>
> Not sure if 240 is a line number in smp.c, but looking through the function
> containing line 240, I was able to compile the smp.c after commenting out
> the two WARN_ON() messages.
>
> diff --git a/arch/powerpc/platforms/85xx/smp.c
> b/arch/powerpc/platforms/85xx/smp
> index 5ced4f5..9705850 100644
> --- a/arch/powerpc/platforms/85xx/smp.c
> +++ b/arch/powerpc/platforms/85xx/smp.c
> @@ -151,8 +151,10 @@ static int smp_85xx_kick_cpu(int nr)
>int ioremappable;
>int ret = 0;
>
> +#if 0
>WARN_ON(nr < 0 || nr >= NR_CPUS);
>WARN_ON(hw_cpu < 0 || hw_cpu >= NR_CPUS);
> +#endif
>
>pr_debug("smp_85xx_kick_cpu: kick CPU #%d\n", nr);
>
> ---
>
> The pre-processor output for the first WARN_ON() is:
>
> ---
> ({ int __ret_warn_on = !!(nr < 0 || nr >= 32); if
> (__builtin_constant_p(__ret_warn_on)) { if (__ret_warn_on) do { __asm__
> __volatile__( "1:twi 31,0,0\n" ".section __bug_table,\"a\"\n" "2:\t"
> ".llong" " " "1b, %0\n" "\t.short %1, %2\n" ".org 2b+%3\n" ".previous\n" : :
> "i" ("/root/tmp/linux.git/arch/powerpc/platforms/85xx/smp.c"), "i" (154), "i"
> (((1 << 0) | ((9) << 8))), "i" (sizeof(struct bug_entry))); } while (0); }
> else { __asm__ __volatile__( "1: ""tdnei" " "" %4,0\n" ".section
> __bug_table,\"a\"\n" "2:\t" ".llong" " " "1b, %0\n" "\t.short %1, %2\n" ".org
> 2b+%3\n" ".previous\n" : : "i"
> ("/root/tmp/linux.git/arch/powerpc/platforms/85xx/smp.c"), "i" (154), "i"
> (((1 << 0) | ((9) << 8))), "i" (sizeof(struct bug_entry)), "r"
> (__ret_warn_on)); } __builtin_expect(!!(__ret_warn_on), 0); });
>
> ---
>
>
> Should I be doing something different to build with these configs ?
>
Hmm, that is odd.
How about doing:
$ make V=1
so we can see what compiler flags are being passed around.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/85xx: add hardware automatically enter altivec idle state
On Aug 16, 2013, at 2:23 AM, Dongsheng Wang wrote: > From: Wang Dongsheng > > Each core's AltiVec unit may be placed into a power savings mode > by turning off power to the unit. Core hardware will automatically > power down the AltiVec unit after no AltiVec instructions have > executed in N cycles. The AltiVec power-control is triggered by hardware. > > Signed-off-by: Wang Dongsheng Why treat this as a idle HW governor vs just some one time setup at boot of the time delay? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Critical Interrupt Input
On Aug 15, 2013, at 11:57 PM, Henry Bausley wrote:
>
> Is there any reason that a Critical Input Interrupt will not work reliably on
> a 44x powerpc?
>
> I am using an AMCC now Applied Micro AMCC460EX
>
> and changed
>
> CRITICAL_EXCEPTION(0x0100, CriticalInput, unknown_exception)
> to
> CRITICAL_EXCEPTION(0x0100, CriticalInput, do_MyCritIntr)
>
> The code for the handler is trivial
> ie.
> int crintrcount;
>
> void do_MyCritIntr(void)
> {
> crintrcount++;
> }
>
> The code runs for a while but eventually I get panic messages and the system
> hangs. Is there something I must alter in the kernel to do this reliably?
The 44x low level code needs to handle exception stacks properly for this to
work. Since its possible to have a critical exception occur while in a normal
exception level, you have to have proper saving of additional register state
and a stack frame for the critical exception, etc. I'm not sure if that was
ever done for 44x.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/7] powerpc/pci: use pci_is_pcie() to simplify code
On Sep 3, 2013, at 2:35 AM, Yijing Wang wrote: > Use pci_is_pcie() to simplify code. > > Signed-off-by: Yijing Wang > Cc: Gavin Shan > Cc: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: linuxppc-dev@lists.ozlabs.org > Cc: linux-ker...@vger.kernel.org > --- > arch/powerpc/kernel/eeh.c |3 +-- > arch/powerpc/sysdev/fsl_pci.c |2 +- > 2 files changed, 2 insertions(+), 3 deletions(-) Acked-by: Kumar Gala (for the fsl_pci.c) change - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 2/2] powerpc/85xx: workaround for chips with MSI hardware errata
On Apr 2, 2013, at 9:03 PM, Jia Hongtao wrote:
> The MPIC version 2.0 has a MSI errata (errata PIC1 of mpc8544), It causes
> that neither MSI nor MSI-X can work fine. This is a workaround to allow
> MSI-X to function properly.
>
> Signed-off-by: Liu Shuo
> Signed-off-by: Li Yang
> Signed-off-by: Jia Hongtao
> ---
> Changes for V2:
> * change the name of function mpic_has_errata() to mpic_has_erratum_pic1().
> * move MSI_HW_ERRATA_ENDIAN define to fsl_msi.h with all other defines.
>
> arch/powerpc/sysdev/fsl_msi.c | 40 +---
> arch/powerpc/sysdev/fsl_msi.h | 2 ++
> 2 files changed, 39 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
> index 178c994..ca1157a 100644
> --- a/arch/powerpc/sysdev/fsl_msi.c
> +++ b/arch/powerpc/sysdev/fsl_msi.c
> @@ -98,8 +98,18 @@ static int fsl_msi_init_allocator(struct fsl_msi *msi_data)
>
> static int fsl_msi_check_device(struct pci_dev *pdev, int nvec, int type)
> {
> - if (type == PCI_CAP_ID_MSIX)
> - pr_debug("fslmsi: MSI-X untested, trying anyway.\n");
> + struct fsl_msi *msi;
> +
> + if (type == PCI_CAP_ID_MSI) {
> + /*
> + * MPIC version 2.0 has erratum PIC1. For now MSI
> + * could not work. So check to prevent MSI from
> + * being used on the board with this erratum.
> + */
> + list_for_each_entry(msi, &msi_head, list)
> + if (msi->feature & MSI_HW_ERRATA_ENDIAN)
> + return -EINVAL;
> + }
>
> return 0;
> }
> @@ -142,7 +152,17 @@ static void fsl_compose_msi_msg(struct pci_dev *pdev,
> int hwirq,
> msg->address_lo = lower_32_bits(address);
> msg->address_hi = upper_32_bits(address);
>
> - msg->data = hwirq;
> + /*
> + * MPIC version 2.0 has erratum PIC1. It causes
> + * that neither MSI nor MSI-X can work fine.
> + * This is a workaround to allow MSI-X to function
> + * properly. It only works for MSI-X, we prevent
> + * MSI on buggy chips in fsl_msi_check_device().
> + */
> + if (msi_data->feature & MSI_HW_ERRATA_ENDIAN)
> + msg->data = __swab32(hwirq);
> + else
> + msg->data = hwirq;
>
> pr_debug("%s: allocated srs: %d, ibs: %d\n",
> __func__, hwirq / IRQS_PER_MSI_REG, hwirq % IRQS_PER_MSI_REG);
> @@ -361,6 +381,15 @@ static int fsl_msi_setup_hwirq(struct fsl_msi *msi,
> struct platform_device *dev,
> return 0;
> }
>
> +/* MPIC version 2.0 has erratum PIC1 */
> +static int mpic_has_erratum_pic1(void)
> +{
> + if (fsl_mpic_primary_get_version() == 0x0200)
> + return 1;
> +
> + return 0;
> +}
> +
> static const struct of_device_id fsl_of_msi_ids[];
> static int fsl_of_msi_probe(struct platform_device *dev)
> {
> @@ -423,6 +452,11 @@ static int fsl_of_msi_probe(struct platform_device *dev)
>
> msi->feature = features->fsl_pic_ip;
>
> + if ((features->fsl_pic_ip & FSL_PIC_IP_MASK) == FSL_PIC_IP_MPIC) {
> + if (mpic_has_erratum_pic1())
Get ride of the mpic_has_erratum_pic1() function and just put the test here
> + msi->feature |= MSI_HW_ERRATA_ENDIAN;
> + }
> +
> /*
>* Remember the phandle, so that we can match with any PCI nodes
>* that have an "fsl,msi" property.
> diff --git a/arch/powerpc/sysdev/fsl_msi.h b/arch/powerpc/sysdev/fsl_msi.h
> index 8225f86..7389e8e 100644
> --- a/arch/powerpc/sysdev/fsl_msi.h
> +++ b/arch/powerpc/sysdev/fsl_msi.h
> @@ -25,6 +25,8 @@
> #define FSL_PIC_IP_IPIC 0x0002
> #define FSL_PIC_IP_VMPIC 0x0003
>
> +#define MSI_HW_ERRATA_ENDIAN 0x0010
> +
Why does this need to be in the header, why not just have it in the .c only
> struct fsl_msi {
> struct irq_domain *irqhost;
>
> --
> 1.8.0
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2] powerpc: Add I2C bus multiplexer node for B4 and T4240QDS
On Sep 4, 2013, at 9:41 PM, Jia Hongtao wrote:
> In both B4 and T4240QDS platform PCA9547 I2C bus multiplexer is used.
> The sub-nodes are also reorganized according to right I2C topology.
>
> Signed-off-by: Jia Hongtao
> ---
> V2 change log:
> Reorganized the sub-nodes under I2C multiplexer to represent right topology.
>
> arch/powerpc/boot/dts/b4qds.dtsi | 49 +---
> arch/powerpc/boot/dts/t4240qds.dts | 67 ++
> 2 files changed, 69 insertions(+), 47 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/b4qds.dtsi
> b/arch/powerpc/boot/dts/b4qds.dtsi
> index e6d2f8f..de8cb38 100644
> --- a/arch/powerpc/boot/dts/b4qds.dtsi
> +++ b/arch/powerpc/boot/dts/b4qds.dtsi
> @@ -120,25 +120,36 @@
> };
>
> i2c@118000 {
> - eeprom@50 {
> - compatible = "at24,24c64";
> - reg = <0x50>;
> - };
> - eeprom@51 {
> - compatible = "at24,24c256";
> - reg = <0x51>;
> - };
> - eeprom@53 {
> - compatible = "at24,24c256";
> - reg = <0x53>;
> - };
> - eeprom@57 {
> - compatible = "at24,24c256";
> - reg = <0x57>;
> - };
> - rtc@68 {
> - compatible = "dallas,ds3232";
> - reg = <0x68>;
> + pca9547@77 {
> + compatible = "philips,pca9547";
We seem to be using nxp instead of philips now.
> + reg = <0x77>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + channel@0 {
channel should probably be i2c
[same comments below]
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> + eeprom@50 {
> + compatible = "at24,24c64";
> + reg = <0x50>;
> + };
> + eeprom@51 {
> + compatible = "at24,24c256";
> + reg = <0x51>;
> + };
> + eeprom@53 {
> + compatible = "at24,24c256";
> + reg = <0x53>;
> + };
> + eeprom@57 {
> + compatible = "at24,24c256";
> + reg = <0x57>;
> + };
> + rtc@68 {
> + compatible = "dallas,ds3232";
> + reg = <0x68>;
> + };
> + };
> };
> };
>
> diff --git a/arch/powerpc/boot/dts/t4240qds.dts
> b/arch/powerpc/boot/dts/t4240qds.dts
> index 0555976..ae68595 100644
> --- a/arch/powerpc/boot/dts/t4240qds.dts
> +++ b/arch/powerpc/boot/dts/t4240qds.dts
> @@ -118,34 +118,45 @@
> };
>
> i2c@118000 {
> - eeprom@51 {
> - compatible = "at24,24c256";
> - reg = <0x51>;
> - };
> - eeprom@52 {
> - compatible = "at24,24c256";
> - reg = <0x52>;
> - };
> - eeprom@53 {
> - compatible = "at24,24c256";
> - reg = <0x53>;
> - };
> - eeprom@54 {
> - compatible = "at24,24c256";
> - reg = <0x54>;
> - };
> - eeprom@55 {
> - compatible = "at24,24c256";
> - reg = <0x55>;
> - };
> - eeprom@56 {
> - compatible = "at24,24c256";
> - reg = <0x56>;
> - };
> - rtc@68 {
> - compatible = "dallas,ds3232";
> - reg = <0x68>;
> - interrupts = <0x1 0x1 0 0>;
> + pca9547@77 {
> +
Re: [PATCH V2 2/2] powerpc/85xx: workaround for chips with MSI hardware errata
On Sep 5, 2013, at 1:37 PM, Scott Wood wrote: > On Thu, 2013-09-05 at 13:34 -0500, Kumar Gala wrote: >> On Apr 2, 2013, at 9:03 PM, Jia Hongtao wrote: >>> + msi->feature |= MSI_HW_ERRATA_ENDIAN; >>> + } >>> + >>> /* >>> * Remember the phandle, so that we can match with any PCI nodes >>> * that have an "fsl,msi" property. >>> diff --git a/arch/powerpc/sysdev/fsl_msi.h b/arch/powerpc/sysdev/fsl_msi.h >>> index 8225f86..7389e8e 100644 >>> --- a/arch/powerpc/sysdev/fsl_msi.h >>> +++ b/arch/powerpc/sysdev/fsl_msi.h >>> @@ -25,6 +25,8 @@ >>> #define FSL_PIC_IP_IPIC 0x0002 >>> #define FSL_PIC_IP_VMPIC 0x0003 >>> >>> +#define MSI_HW_ERRATA_ENDIAN 0x0010 >>> + >> >> Why does this need to be in the header, why not just have it in the .c only > > Didn't you ask this last time around? :-) > > This flag is part of the same numberspace as FSL_PIC_IP_xxx and thus > should be defined in the same place. I probably did, if its part of the FSL_PIC_IP_xxx namespace, than lets remove blank line between things to make that a bit more clear - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2] powerpc: Add I2C bus multiplexer node for B4 and T4240QDS
On Sep 5, 2013, at 10:33 PM, Jia Hongtao-B38951 wrote:
>> -Original Message-
>> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
>> Sent: Friday, September 06, 2013 2:41 AM
>> To: Jia Hongtao-B38951
>> Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421;
>> wei.y...@windriver.com
>> Subject: Re: [PATCH V2] powerpc: Add I2C bus multiplexer node for B4 and
>> T4240QDS
>>
>>
>> On Sep 4, 2013, at 9:41 PM, Jia Hongtao wrote:
>>
>>> In both B4 and T4240QDS platform PCA9547 I2C bus multiplexer is used.
>>> The sub-nodes are also reorganized according to right I2C topology.
>>>
>>> Signed-off-by: Jia Hongtao
>>> ---
>>> V2 change log:
>>> Reorganized the sub-nodes under I2C multiplexer to represent right
>> topology.
>>>
>>> arch/powerpc/boot/dts/b4qds.dtsi | 49 +---
>>> arch/powerpc/boot/dts/t4240qds.dts | 67 ++-
>> ---
>>> 2 files changed, 69 insertions(+), 47 deletions(-)
>>>
>>> diff --git a/arch/powerpc/boot/dts/b4qds.dtsi
>> b/arch/powerpc/boot/dts/b4qds.dtsi
>>> index e6d2f8f..de8cb38 100644
>>> --- a/arch/powerpc/boot/dts/b4qds.dtsi
>>> +++ b/arch/powerpc/boot/dts/b4qds.dtsi
>>> @@ -120,25 +120,36 @@
>>> };
>>>
>>> i2c@118000 {
>>> - eeprom@50 {
>>> - compatible = "at24,24c64";
>>> - reg = <0x50>;
>>> - };
>>> - eeprom@51 {
>>> - compatible = "at24,24c256";
>>> - reg = <0x51>;
>>> - };
>>> - eeprom@53 {
>>> - compatible = "at24,24c256";
>>> - reg = <0x53>;
>>> - };
>>> - eeprom@57 {
>>> - compatible = "at24,24c256";
>>> - reg = <0x57>;
>>> - };
>>> - rtc@68 {
>>> - compatible = "dallas,ds3232";
>>> - reg = <0x68>;
>>> + pca9547@77 {
>>> + compatible = "philips,pca9547";
>>
>> We seem to be using nxp instead of philips now.
This is based on Documentation/devicetree/bindings/vendor-prefixes.txt
>>
>>> + reg = <0x77>;
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + channel@0 {
>>
>> channel should probably be i2c
>
>
> Is there any standard for the name?
> i2c is ok but I think channel is more intuitional.
>
> Hi Scott,
> What do you think of it.
Basing my comments on Documentation/devicetree/bindings/i2c/i2c-mux.txt
>
> Thanks.
> -Hongtao
>
>
>>
>> [same comments below]
>>
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + reg = <0>;
>>> + eeprom@50 {
>>> + compatible = "at24,24c64";
>>> + reg = <0x50>;
>>> + };
>>> + eeprom@51 {
>>> + compatible = "at24,24c256";
>>> + reg = <0x51>;
>>> + };
>>> + eeprom@53 {
>>> + compatible = "at24,24c256";
>>> + reg = <0x53>;
>>> + };
>>> + eeprom@57 {
>>> + compatible = "at24,24c256";
>>> + reg = <0x57>;
>>> + };
>>> + rtc@68 {
>>> + compatible = "dallas,d
Re: [PATCH V2 2/2] powerpc/85xx: workaround for chips with MSI hardware errata
On Sep 6, 2013, at 10:36 AM, Scott Wood wrote: > On Fri, 2013-09-06 at 10:01 -0500, Kumar Gala wrote: >> On Sep 5, 2013, at 1:37 PM, Scott Wood wrote: >> >>> On Thu, 2013-09-05 at 13:34 -0500, Kumar Gala wrote: >>>> On Apr 2, 2013, at 9:03 PM, Jia Hongtao wrote: >>>>> + msi->feature |= MSI_HW_ERRATA_ENDIAN; >>>>> + } >>>>> + >>>>> /* >>>>>* Remember the phandle, so that we can match with any PCI nodes >>>>>* that have an "fsl,msi" property. >>>>> diff --git a/arch/powerpc/sysdev/fsl_msi.h b/arch/powerpc/sysdev/fsl_msi.h >>>>> index 8225f86..7389e8e 100644 >>>>> --- a/arch/powerpc/sysdev/fsl_msi.h >>>>> +++ b/arch/powerpc/sysdev/fsl_msi.h >>>>> @@ -25,6 +25,8 @@ >>>>> #define FSL_PIC_IP_IPIC 0x0002 >>>>> #define FSL_PIC_IP_VMPIC 0x0003 >>>>> >>>>> +#define MSI_HW_ERRATA_ENDIAN 0x0010 >>>>> + >>>> >>>> Why does this need to be in the header, why not just have it in the .c only >>> >>> Didn't you ask this last time around? :-) >>> >>> This flag is part of the same numberspace as FSL_PIC_IP_xxx and thus >>> should be defined in the same place. >> >> I probably did, if its part of the FSL_PIC_IP_xxx namespace, than lets >> remove blank line between things to make that a bit more clear > > It's not part of the FSL_PIC_IP_MASK subnumberspace though, just the > overall msi->features numberspace. > > It would be nice if these symbols could have some sort of prefix in > common, though. > > -Scott Maybe we should do something like MSI_FTR_ as a prefix - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/p1010rdb:update phy node in dts
On Sep 10, 2013, at 12:50 AM, Zhao Qiang wrote:
> Update phy node according to new P1010RDB-PB board.
>
> Signed-off-by: Shengzhou Liu
> Signed-off-by: Zhao Qiang
> ---
> arch/powerpc/boot/dts/p1010rdb.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
What about the old boards?
- k
>
> diff --git a/arch/powerpc/boot/dts/p1010rdb.dtsi
> b/arch/powerpc/boot/dts/p1010rdb.dtsi
> index 7fc3402..8c675bf 100644
> --- a/arch/powerpc/boot/dts/p1010rdb.dtsi
> +++ b/arch/powerpc/boot/dts/p1010rdb.dtsi
> @@ -199,7 +199,7 @@
>
> mdio@24000 {
> phy0: ethernet-phy@0 {
> - interrupts = <3 1 0 0>;
> + interrupts = <0 1 0 0>;
> reg = <0x1>;
> };
>
> @@ -209,7 +209,7 @@
> };
>
> phy2: ethernet-phy@2 {
> - interrupts = <2 1 0 0>;
> + interrupts = <1 1 0 0>;
> reg = <0x2>;
> };
>
> --
> 1.8.0
>
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/p1010rdb:remove interrupts of ethernet-phy in device tree
On Sep 10, 2013, at 10:49 PM, Zhao Qiang wrote: > Since P1010RDB-PA and P1010RDB-PB boards use different external PHY > interrupt signals. > And actually the PHY interrupt is not used effectively with > corresponding interrupt handler. > So we can remove the interrupts node without side-effect to comply > with both P1010RDB-PA and P1010RDB-PB. > > Signed-off-by: Shengzhou Liu > Signed-off-by: Zhao Qiang > --- > arch/powerpc/boot/dts/p1010rdb.dtsi | 3 --- > 1 file changed, 3 deletions(-) > NAK. The device tree should represent the HW not what drivers decide to do with it. If different board revs have different interrupt signals than create dts's to handle the 2 board revs. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/p1010rdb:remove interrupts of ethernet-phy in device tree
On Sep 12, 2013, at 1:54 AM, Liu Shengzhou-B36685 wrote: > > >> -Original Message----- >> From: Kumar Gala [mailto:ga...@kernel.crashing.org] >> Sent: Wednesday, September 11, 2013 11:13 PM >> To: Zhao Qiang-B45475 >> Cc: linuxppc-dev@lists.ozlabs.org; Liu Shengzhou-B36685 >> Subject: Re: [PATCH] powerpc/p1010rdb:remove interrupts of ethernet-phy in >> device tree >> >> >> On Sep 10, 2013, at 10:49 PM, Zhao Qiang wrote: >> >>> Since P1010RDB-PA and P1010RDB-PB boards use different external PHY >>> interrupt signals. >>> And actually the PHY interrupt is not used effectively with >>> corresponding interrupt handler. >>> So we can remove the interrupts node without side-effect to comply >>> with both P1010RDB-PA and P1010RDB-PB. >>> >>> Signed-off-by: Shengzhou Liu >>> Signed-off-by: Zhao Qiang >>> --- >>> arch/powerpc/boot/dts/p1010rdb.dtsi | 3 --- >>> 1 file changed, 3 deletions(-) >>> >> >> NAK. The device tree should represent the HW not what drivers decide to do >> with >> it. >> >> If different board revs have different interrupt signals than create dts's to >> handle the 2 board revs. >> >> - k >> > You mean we need to create p1010rdb-pa.dtsi and p1010rdb-pb.dtsi replacing > current p1010rdb.dtsi just because of the unused phy interrupt? > and phy interrupt is not present in those dts of P3/P4/P5 platforms. > Actually currently many hardware are not present in dts, such as a lot of i2c > devices, temperature monitor, etc. > > -Shengzhou > I'm saying of the board revs are different w/regards to how the PHY interrupt is wired, than create two .dts one for each of the board revs. If the p3/p4/p5 platforms are missing the phy interrupt in the .dts than its an error. Other devices like i2c, temp mon, etc should be added. There is a difference between something not existing because people haven't gotten around to it / there isn't a binding vs a using the lack of information as a configuration mechanism. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mpc85xx:Add initial device tree support of T104x
On Sep 13, 2013, at 4:14 AM, Valentin Longchamp wrote:
> On 09/11/2013 08:58 AM, Prabhakar Kushwaha wrote:
>> The QorIQ T1040/T1042 processor support four integrated 64-bit e5500 PA
>> processor cores with high-performance data path acceleration architecture
>> and network peripheral interfaces required for networking &
>> telecommunications.
>>
>> T1042 personality is a reduced personality of T1040 without Integrated 8-port
>> Gigabit Ethernet switch.
>>
>> The T1040/T1042 SoC includes the following function and features:
>>
>> - Four e5500 cores, each with a private 256 KB L2 cache
>> - 256 KB shared L3 CoreNet platform cache (CPC)
>> - Interconnect CoreNet platform
>> - 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and interleaving
>> support
>> - Data Path Acceleration Architecture (DPAA) incorporating acceleration
>> for the following functions:
>>- Packet parsing, classification, and distribution
>>- Queue management for scheduling, packet sequencing, and congestion
>> management
>>- Cryptography Acceleration (SEC 5.0)
>>- RegEx Pattern Matching Acceleration (PME 2.2)
>>- IEEE Std 1588 support
>>- Hardware buffer management for buffer allocation and deallocation
>> - Ethernet interfaces
>>- Integrated 8-port Gigabit Ethernet switch (T1040 only)
>>- Four 1 Gbps Ethernet controllers
>> - Two RGMII interfaces or one RGMII and one MII interfaces
>> - High speed peripheral interfaces
>> - Four PCI Express 2.0 controllers running at up to 5 GHz
>> - Two SATA controllers supporting 1.5 and 3.0 Gb/s operation
>> - Upto two QSGMII interface
>> - Upto six SGMII interface supporting 1000 Mbps
>> - One SGMII interface supporting upto 2500 Mbps
>> - Additional peripheral interfaces
>> - Two USB 2.0 controllers with integrated PHY
>> - SD/eSDHC/eMMC
>> - eSPI controller
>> - Four I2C controllers
>> - Four UARTs
>> - Four GPIO controllers
>> - Integrated flash controller (IFC)
>> - Change this to LCD/ HDMI interface (DIU) with 12 bit dual data rate
>> - TDM interface
>> - Multicore programmable interrupt controller (PIC)
>> - Two 8-channel DMA engines
>> - Single source clocking implementation
>> - Deep Sleep power implementaion (wakeup from GPIO/Timer/Ethernet/USB)
>>
>> Signed-off-by: Poonam Aggrwal
>> Signed-off-by: Priyanka Jain
>> Signed-off-by: Varun Sethi
>> Signed-off-by: Prabhakar Kushwaha
>> ---
>> Based upon git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git
>>
>> TODO: Add noded for ethernet
>>
>> arch/powerpc/boot/dts/fsl/t1040si-post.dtsi | 116
>> arch/powerpc/boot/dts/fsl/t1042si-post.dtsi | 430
>> +++
>> arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi | 111 +++
>> 3 files changed, 657 insertions(+)
>> create mode 100644 arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
>> create mode 100644 arch/powerpc/boot/dts/fsl/t1042si-post.dtsi
>> create mode 100644 arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi
>>
>
> I am currently working on a design bases on the p2041 but my issue seems to be
> generic to all the QorIQ dtsi files since the structure is exactly the same,
> so
> I pick the opportunity that such a file is submitted to the mailing-list to
> raise it.
>
> DISCLAIMER: I am no DTS expert, so there may be a way to achieve what I want
> to
> I have not seen.
>
> My understanding is that the SOC-NAMEsi-post.dtsi and SOC-NAMEsi-pre.dtsi are
> files that describe the SoC internals. They will be maintained when new
> drivers
> are merged or changed and therefore they should be used by all boards using
> the
> SoCs. Can someone confirm this or am I already wrong (since there are on
> Freescale boards that use them in mainline) ?
That is the intent. of the SOC*.dtsi files.
>
> [snip]
>
>> +
>> +&pci0 {
>> +compatible = "fsl,t1042-pcie", "fsl,qoriq-pcie-v2.4", "fsl,qoriq-pcie";
>> +device_type = "pci";
>> +#size-cells = <2>;
>> +#address-cells = <3>;
>> +bus-range = <0x0 0xff>;
>> +interrupts = <20 2 0 0>;
>> +fsl,iommu-parent = <&pamu0>;
>> +pcie@0 {
>> +reg = <0 0 0 0 0>;
>> +#interrupt-cells = <1>;
>> +#size-cells = <2>;
>> +#address-cells = <3>;
>> +device_type = "pci";
>> +interrupts = <20 2 0 0>;
>> +interrupt-map-mask = <0xf800 0 0 7>;
>> +interrupt-map = <
>> +/* IDSEL 0x0 */
>> + 0 0 1 &mpic 40 1 0 0
>> + 0 0 2 &mpic 1 1 0 0
>> + 0 0 3 &mpic 2 1 0 0
>> + 0 0 4 &mpic 3 1 0 0
>> +>;
>> +};
>> +};
>> +
>> +&pci1 {
>> +compatible = "fsl,t1042-pcie", "fsl,qoriq-pcie-v2.4", "fsl,qoriq-pcie";
>> +device_type = "pci";
>> +#size-cells = <2>;
>> +#address-cells = <3>;
>> +bus-range = <0 0xff>;
>> +interrupts = <21 2 0 0>;
>> +fsl,iommu-parent = <&pamu0>;
>> +pcie@0
Re: [PATCH 1/2] powerpc/85xx: introduce cornet_generic machine
On Sep 12, 2013, at 8:11 PM, Kevin Hao wrote: > On Thu, Sep 12, 2013 at 01:44:46PM -0500, Scott Wood wrote: >> On Thu, 2013-09-12 at 15:13 +0800, Kevin Hao wrote: Just a nit, but subject is missing 'e' in 'cornet' :) - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 1/4] powerpc/fsl: add E6500 PVR and SPRN_PWRMGTCR0 define
On Sep 24, 2013, at 6:21 AM, Bhushan Bharat-R65777 wrote: > > >> -Original Message- >> From: Linuxppc-dev [mailto:linuxppc-dev- >> bounces+bharat.bhushan=freescale@lists.ozlabs.org] On Behalf Of Dongsheng >> Wang >> Sent: Tuesday, September 24, 2013 2:58 PM >> To: Wood Scott-B07421 >> Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534 >> Subject: [PATCH v4 1/4] powerpc/fsl: add E6500 PVR and SPRN_PWRMGTCR0 define >> >> From: Wang Dongsheng >> >> E6500 PVR and SPRN_PWRMGTCR0 will be used in subsequent pw20/altivec idle >> patches. >> >> Signed-off-by: Wang Dongsheng >> --- >> *v3: >> Add bit definitions for PWRMGTCR0. >> >> arch/powerpc/include/asm/reg.h | 2 ++ >> arch/powerpc/include/asm/reg_booke.h | 9 + >> 2 files changed, 11 insertions(+) >> >> diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h >> index 64264bf..d4160ca 100644 >> --- a/arch/powerpc/include/asm/reg.h >> +++ b/arch/powerpc/include/asm/reg.h >> @@ -1053,6 +1053,8 @@ >> #define PVR_8560 0x8020 >> #define PVR_VER_E500V1 0x8020 >> #define PVR_VER_E500V2 0x8021 >> +#define PVR_VER_E6500 0x8040 >> + >> /* >> * For the 8xx processors, all of them report the same PVR family for >> * the PowerPC core. The various versions of these processors must be diff -- >> git a/arch/powerpc/include/asm/reg_booke.h >> b/arch/powerpc/include/asm/reg_booke.h >> index ed8f836..4a6457e 100644 >> --- a/arch/powerpc/include/asm/reg_booke.h >> +++ b/arch/powerpc/include/asm/reg_booke.h >> @@ -170,6 +170,7 @@ >> #define SPRN_L2CSR1 0x3FA /* L2 Data Cache Control and Status Register 1 >> */ >> #define SPRN_DCCR0x3FA /* Data Cache Cacheability Register */ >> #define SPRN_ICCR0x3FB /* Instruction Cache Cacheability Register */ >> +#define SPRN_PWRMGTCR0 0x3FB /* Power management control register 0 >> */ > > Is this generic for booke or e6500 specific? I can't see this register either > in ISA and EREF. > Also I can see SPRN_ICCR also with same SPRN, how that is possible? Its possibly because the register maybe in implementation specific region. I'm guessing ICCR is a 40x specific register. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/83xx: gianfar_ptp: select 1588 clock source through dts file
On Sep 25, 2013, at 2:24 AM, Aida Mynzhasova wrote:
> Currently IEEE 1588 timer reference clock source is determined through
> hard-coded value in gianfar_ptp driver. This patch allows to select ptp
> clock source by means of device tree file node.
>
> For instance:
>
> fsl,cksel = <0>;
>
> for using external (TSEC_TMR_CLK input) high precision timer
> reference clock.
>
> Other acceptable values:
>
> <1> : eTSEC system clock
> <2> : eTSEC1 transmit clock
> <3> : RTC clock input
Do these value match some register field to select which clk? If so please add
that to the document.
- k
>
> When this attribute isn't used, eTSEC system clock will serve as
> IEEE 1588 timer reference clock.
>
> Signed-off-by: Aida Mynzhasova
> ---
> Documentation/devicetree/bindings/net/fsl-tsec-phy.txt | 16 +++-
> drivers/net/ethernet/freescale/gianfar_ptp.c | 4 +++-
> 2 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
> b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
> index 2c6be03..eb06059 100644
> --- a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
> +++ b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
> @@ -86,6 +86,7 @@ General Properties:
>
> Clock Properties:
>
> + - fsl,ckselTimer reference clock source.
> - fsl,tclk-period Timer reference clock period in nanoseconds.
> - fsl,tmr-prsc Prescaler, divides the output clock.
> - fsl,tmr-add Frequency compensation value.
> @@ -97,7 +98,7 @@ Clock Properties:
> clock. You must choose these carefully for the clock to work right.
> Here is how to figure good values:
>
> - TimerOsc = system clock MHz
> + TimerOsc = selected reference clock MHz
> tclk_period = desired clock period nanoseconds
> NominalFreq = 1000 / tclk_period MHz
> FreqDivRatio = TimerOsc / NominalFreq (must be greater that 1.0)
> @@ -114,6 +115,18 @@ Clock Properties:
> Pulse Per Second (PPS) signal, since this will be offered to the PPS
> subsystem to synchronize the Linux clock.
>
> + "fsl,cksel" property allows to select different reference clock
> + sources:
> +
> + <0> - external high precision timer reference clock (TSEC_TMR_CLK
> +input is used for this purpose);
> + <1> - eTSEC system clock;
> + <2> - eTSEC1 transmit clock;
> + <3> - RTC clock input.
> +
> + When this attribute is not used, eTSEC system clock will serve as
> + IEEE 1588 timer reference clock.
> +
> Example:
>
> ptp_clock@24E00 {
> @@ -121,6 +134,7 @@ Example:
> reg = <0x24E00 0xB0>;
> interrupts = <12 0x8 13 0x8>;
> interrupt-parent = < &ipic >;
> + fsl,cksel = <1>;
> fsl,tclk-period = <10>;
> fsl,tmr-prsc= <100>;
> fsl,tmr-add = <0x99A4>;
> diff --git a/drivers/net/ethernet/freescale/gianfar_ptp.c
> b/drivers/net/ethernet/freescale/gianfar_ptp.c
> index 098f133..e006a09 100644
> --- a/drivers/net/ethernet/freescale/gianfar_ptp.c
> +++ b/drivers/net/ethernet/freescale/gianfar_ptp.c
> @@ -452,7 +452,9 @@ static int gianfar_ptp_probe(struct platform_device *dev)
> err = -ENODEV;
>
> etsects->caps = ptp_gianfar_caps;
> - etsects->cksel = DEFAULT_CKSEL;
> +
> + if (get_of_u32(node, "fsl,cksel", &etsects->cksel))
> + etsects->cksel = DEFAULT_CKSEL;
>
> if (get_of_u32(node, "fsl,tclk-period", &etsects->tclk_period) ||
> get_of_u32(node, "fsl,tmr-prsc", &etsects->tmr_prsc) ||
> --
> 1.8.1.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] powerpc/83xx: gianfar_ptp: select 1588 clock source through dts file
On Sep 27, 2013, at 8:40 AM, Aida Mynzhasova wrote: > Currently IEEE 1588 timer reference clock source is determined through > hard-coded value in gianfar_ptp driver. This patch allows to select ptp > clock source by means of device tree file node. > > For instance: > > fsl,cksel = <0>; > > for using external (TSEC_TMR_CLK input) high precision timer > reference clock. > > Other acceptable values: > > <1> : eTSEC system clock > <2> : eTSEC1 transmit clock > <3> : RTC clock input > > When this attribute isn't used, eTSEC system clock will serve as > IEEE 1588 timer reference clock. > > Signed-off-by: Aida Mynzhasova > --- > Documentation/devicetree/bindings/net/fsl-tsec-phy.txt | 18 +- > drivers/net/ethernet/freescale/gianfar_ptp.c | 4 +++- > 2 files changed, 20 insertions(+), 2 deletions(-) Acked-by: Kumar Gala - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mpic: Disable preemption when calling mpic_processor_id()
On Sep 26, 2013, at 7:18 PM, Scott Wood wrote:
> Otherwise, we get a debug traceback due to the use of
> smp_processor_id() (or get_paca()) inside hard_smp_processor_id().
> mpic_host_map() is just looking for a default CPU, so it doesn't matter
> if we migrate after getting the CPU ID.
>
> Signed-off-by: Scott Wood
> ---
> arch/powerpc/sysdev/mpic.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> index 1be54fa..bdcb858 100644
> --- a/arch/powerpc/sysdev/mpic.c
> +++ b/arch/powerpc/sysdev/mpic.c
> @@ -1088,8 +1088,14 @@ static int mpic_host_map(struct irq_domain *h,
> unsigned int virq,
>* is done here.
>*/
> if (!mpic_is_ipi(mpic, hw) && (mpic->flags & MPIC_NO_RESET)) {
> + int cpu;
> +
> + preempt_disable();
> + cpu = mpic_processor_id(mpic);
> + preempt_enable();
> +
Any reason you didn't stick this inside of mpic_processor_id() ?
> mpic_set_vector(virq, hw);
> - mpic_set_destination(virq, mpic_processor_id(mpic));
> + mpic_set_destination(virq, cpu);
> mpic_irq_set_priority(virq, 8);
> }
>
> --
> 1.8.1.2
>
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mpic: Disable preemption when calling mpic_processor_id()
On Sep 27, 2013, at 11:15 AM, Scott Wood wrote:
> On Fri, 2013-09-27 at 10:52 -0500, Kumar Gala wrote:
>> On Sep 26, 2013, at 7:18 PM, Scott Wood wrote:
>>
>>> Otherwise, we get a debug traceback due to the use of
>>> smp_processor_id() (or get_paca()) inside hard_smp_processor_id().
>>> mpic_host_map() is just looking for a default CPU, so it doesn't matter
>>> if we migrate after getting the CPU ID.
>>>
>>> Signed-off-by: Scott Wood
>>> ---
>>> arch/powerpc/sysdev/mpic.c | 8 +++-
>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
>>> index 1be54fa..bdcb858 100644
>>> --- a/arch/powerpc/sysdev/mpic.c
>>> +++ b/arch/powerpc/sysdev/mpic.c
>>> @@ -1088,8 +1088,14 @@ static int mpic_host_map(struct irq_domain *h,
>>> unsigned int virq,
>>> * is done here.
>>> */
>>> if (!mpic_is_ipi(mpic, hw) && (mpic->flags & MPIC_NO_RESET)) {
>>> + int cpu;
>>> +
>>> + preempt_disable();
>>> + cpu = mpic_processor_id(mpic);
>>> + preempt_enable();
>>> +
>>
>> Any reason you didn't stick this inside of mpic_processor_id() ?
>
> Because the debug check might be valid for other callers and we don't
> want to defeat it. In this caller it's used only as a heuristic and
> thus it doesn't matter if we re-enable preemption before using the
> result.
Gotcha, I think you should reword the commit message. Reading it makes me
think that preemption should be disabled for all mpic_processor_id() calls.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/qe_lib: Share the qe_lib for the others architecture
On Oct 14, 2013, at 6:37 AM, Xie Xiaobo wrote: > The QUICC Engine (QE) is a communications coprocessors on Freescale > embedded processors. The QE had been applied in PowerPC architecture > previously, and it will be applied in ARM architecture too. > So move the qe_lib from arch/powerpc to driver/ firstly. > > Signed-off-by: Xie Xiaobo > --- > arch/powerpc/Kconfig | 2 - > arch/powerpc/include/asm/immap_qe.h | 491 - > arch/powerpc/include/asm/qe.h| 740 - > arch/powerpc/include/asm/qe_ic.h | 144 - > arch/powerpc/include/asm/ucc.h | 64 --- > arch/powerpc/include/asm/ucc_fast.h | 244 > arch/powerpc/include/asm/ucc_slow.h | 290 -- > arch/powerpc/platforms/85xx/mpc85xx_mds.c| 4 +- > arch/powerpc/platforms/85xx/mpc85xx_rdb.c| 4 +- > arch/powerpc/platforms/Kconfig | 19 - > arch/powerpc/sysdev/Makefile | 1 - > arch/powerpc/sysdev/qe_lib/Kconfig | 27 - > arch/powerpc/sysdev/qe_lib/Makefile | 10 - > arch/powerpc/sysdev/qe_lib/gpio.c| 317 --- > arch/powerpc/sysdev/qe_lib/qe.c | 708 > arch/powerpc/sysdev/qe_lib/qe_ic.c | 501 - > arch/powerpc/sysdev/qe_lib/qe_ic.h | 103 > arch/powerpc/sysdev/qe_lib/qe_io.c | 218 > arch/powerpc/sysdev/qe_lib/ucc.c | 213 --- > arch/powerpc/sysdev/qe_lib/ucc_fast.c| 364 > arch/powerpc/sysdev/qe_lib/ucc_slow.c| 380 - > arch/powerpc/sysdev/qe_lib/usb.c | 56 -- > drivers/Kconfig | 2 + > drivers/Makefile | 3 + > drivers/net/ethernet/freescale/fsl_pq_mdio.c | 2 +- > drivers/net/ethernet/freescale/ucc_geth.c| 8 +- > drivers/net/ethernet/freescale/ucc_geth.h| 8 +- > drivers/qe/Kconfig | 51 ++ > drivers/qe/Makefile | 10 + > drivers/qe/gpio.c| 317 +++ > drivers/qe/qe.c | 708 > drivers/qe/qe_common.c | 187 +++ > drivers/qe/qe_ic.c | 501 + > drivers/qe/qe_ic.h | 103 > drivers/qe/qe_io.c | 218 > drivers/qe/ucc.c | 213 +++ > drivers/qe/ucc_fast.c| 364 > drivers/qe/ucc_slow.c| 380 + > drivers/qe/usb.c | 56 ++ > drivers/spi/spi-fsl-cpm.c| 2 +- > drivers/tty/serial/ucc_uart.c| 2 +- > include/qe/immap_qe.h| 491 + > include/qe/qe.h | 794 +++ > include/qe/qe_ic.h | 144 + > include/qe/ucc.h | 64 +++ > include/qe/ucc_fast.h| 244 > include/qe/ucc_slow.h| 290 ++ > 47 files changed, 5155 insertions(+), 4907 deletions(-) > delete mode 100644 arch/powerpc/include/asm/immap_qe.h > delete mode 100644 arch/powerpc/include/asm/qe.h > delete mode 100644 arch/powerpc/include/asm/qe_ic.h > delete mode 100644 arch/powerpc/include/asm/ucc.h > delete mode 100644 arch/powerpc/include/asm/ucc_fast.h > delete mode 100644 arch/powerpc/include/asm/ucc_slow.h > delete mode 100644 arch/powerpc/sysdev/qe_lib/Kconfig > delete mode 100644 arch/powerpc/sysdev/qe_lib/Makefile > delete mode 100644 arch/powerpc/sysdev/qe_lib/gpio.c > delete mode 100644 arch/powerpc/sysdev/qe_lib/qe.c > delete mode 100644 arch/powerpc/sysdev/qe_lib/qe_ic.c > delete mode 100644 arch/powerpc/sysdev/qe_lib/qe_ic.h > delete mode 100644 arch/powerpc/sysdev/qe_lib/qe_io.c > delete mode 100644 arch/powerpc/sysdev/qe_lib/ucc.c > delete mode 100644 arch/powerpc/sysdev/qe_lib/ucc_fast.c > delete mode 100644 arch/powerpc/sysdev/qe_lib/ucc_slow.c > delete mode 100644 arch/powerpc/sysdev/qe_lib/usb.c > create mode 100644 drivers/qe/Kconfig > create mode 100644 drivers/qe/Makefile > create mode 100644 drivers/qe/gpio.c > create mode 100644 drivers/qe/qe.c > create mode 100644 drivers/qe/qe_common.c > create mode 100644 drivers/qe/qe_ic.c > create mode 100644 drivers/qe/qe_ic.h > create mode 100644 drivers/qe/qe_io.c > create mode 100644 drivers/qe/ucc.c > create mode 100644 drivers/qe/ucc_fast.c > create mode 100644 drivers/qe/ucc_slow.c > create mode 100644 drivers/qe/usb.c > create mode 100644 include/qe/immap_qe.h > create mode 100644 include/qe/qe.h > create mode 100644 include/qe/qe_ic.h > create mode 100644 include/qe/ucc.h > create mode 100644 include/qe/ucc_fast.h > create mode 100644 include/qe/ucc_slow.h Before this is mov
Re: [PATCH] powerpc/qe_lib: Share the qe_lib for the others architecture
On Oct 14, 2013, at 2:26 PM, Kumar Gala wrote:
>
> On Oct 14, 2013, at 6:37 AM, Xie Xiaobo wrote:
>
>> The QUICC Engine (QE) is a communications coprocessors on Freescale
>> embedded processors. The QE had been applied in PowerPC architecture
>> previously, and it will be applied in ARM architecture too.
>> So move the qe_lib from arch/powerpc to driver/ firstly.
>>
>> Signed-off-by: Xie Xiaobo
>> ---
>> arch/powerpc/Kconfig | 2 -
>> arch/powerpc/include/asm/immap_qe.h | 491 -
>> arch/powerpc/include/asm/qe.h| 740 -
>> arch/powerpc/include/asm/qe_ic.h | 144 -
>> arch/powerpc/include/asm/ucc.h | 64 ---
>> arch/powerpc/include/asm/ucc_fast.h | 244
>> arch/powerpc/include/asm/ucc_slow.h | 290 --
>> arch/powerpc/platforms/85xx/mpc85xx_mds.c| 4 +-
>> arch/powerpc/platforms/85xx/mpc85xx_rdb.c| 4 +-
>> arch/powerpc/platforms/Kconfig | 19 -
>> arch/powerpc/sysdev/Makefile | 1 -
>> arch/powerpc/sysdev/qe_lib/Kconfig | 27 -
>> arch/powerpc/sysdev/qe_lib/Makefile | 10 -
>> arch/powerpc/sysdev/qe_lib/gpio.c| 317 ---
>> arch/powerpc/sysdev/qe_lib/qe.c | 708
>> arch/powerpc/sysdev/qe_lib/qe_ic.c | 501 -
>> arch/powerpc/sysdev/qe_lib/qe_ic.h | 103
>> arch/powerpc/sysdev/qe_lib/qe_io.c | 218
>> arch/powerpc/sysdev/qe_lib/ucc.c | 213 ---
>> arch/powerpc/sysdev/qe_lib/ucc_fast.c| 364
>> arch/powerpc/sysdev/qe_lib/ucc_slow.c| 380 -
>> arch/powerpc/sysdev/qe_lib/usb.c | 56 --
> Before this is moved you should address the PPC specific issues in the code.
> Use of PPC_LIB_RHEAP, the IO macros which are not cross platform, etc.
>
> Also, copy linux-kernel list as I'm not sure drivers/qe would be the
> recommendation location for this to end up at.
Additionally, some of this should move to using standard driver models that now
exist. For example qe_ic.{c,h} should possibly look at going into
drivers/irqchip/. gpio.c should be looked to use gpiolib and move into
drivers/gpio. Some of the pinmux that exists in qe.c and ucc.c should look at
the drivers/pinctrl and there is some amount of clk config that I wonder if it
could move the common clk API and drivers/clk.
There will still be some qe_lib specific code, but vastly reduced.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/qe_lib: Share the qe_lib for the others architecture
On Oct 14, 2013, at 2:26 PM, Kumar Gala wrote: > > On Oct 14, 2013, at 6:37 AM, Xie Xiaobo wrote: > >> The QUICC Engine (QE) is a communications coprocessors on Freescale >> embedded processors. The QE had been applied in PowerPC architecture >> previously, and it will be applied in ARM architecture too. >> So move the qe_lib from arch/powerpc to driver/ firstly. >> >> Signed-off-by: Xie Xiaobo >> --- >> arch/powerpc/Kconfig | 2 - >> arch/powerpc/include/asm/immap_qe.h | 491 - >> arch/powerpc/include/asm/qe.h| 740 - >> arch/powerpc/include/asm/qe_ic.h | 144 - >> arch/powerpc/include/asm/ucc.h | 64 --- >> arch/powerpc/include/asm/ucc_fast.h | 244 >> arch/powerpc/include/asm/ucc_slow.h | 290 -- >> arch/powerpc/platforms/85xx/mpc85xx_mds.c| 4 +- >> arch/powerpc/platforms/85xx/mpc85xx_rdb.c| 4 +- >> arch/powerpc/platforms/Kconfig | 19 - >> arch/powerpc/sysdev/Makefile | 1 - >> arch/powerpc/sysdev/qe_lib/Kconfig | 27 - >> arch/powerpc/sysdev/qe_lib/Makefile | 10 - >> arch/powerpc/sysdev/qe_lib/gpio.c| 317 --- >> arch/powerpc/sysdev/qe_lib/qe.c | 708 >> arch/powerpc/sysdev/qe_lib/qe_ic.c | 501 - >> arch/powerpc/sysdev/qe_lib/qe_ic.h | 103 >> arch/powerpc/sysdev/qe_lib/qe_io.c | 218 >> arch/powerpc/sysdev/qe_lib/ucc.c | 213 --- >> arch/powerpc/sysdev/qe_lib/ucc_fast.c| 364 >> arch/powerpc/sysdev/qe_lib/ucc_slow.c| 380 - >> arch/powerpc/sysdev/qe_lib/usb.c | 56 -- >> drivers/Kconfig | 2 + >> drivers/Makefile | 3 + >> drivers/net/ethernet/freescale/fsl_pq_mdio.c | 2 +- >> drivers/net/ethernet/freescale/ucc_geth.c| 8 +- >> drivers/net/ethernet/freescale/ucc_geth.h| 8 +- >> drivers/qe/Kconfig | 51 ++ >> drivers/qe/Makefile | 10 + >> drivers/qe/gpio.c| 317 +++ >> drivers/qe/qe.c | 708 >> drivers/qe/qe_common.c | 187 +++ >> drivers/qe/qe_ic.c | 501 + >> drivers/qe/qe_ic.h | 103 >> drivers/qe/qe_io.c | 218 >> drivers/qe/ucc.c | 213 +++ >> drivers/qe/ucc_fast.c| 364 >> drivers/qe/ucc_slow.c| 380 + >> drivers/qe/usb.c | 56 ++ >> drivers/spi/spi-fsl-cpm.c| 2 +- >> drivers/tty/serial/ucc_uart.c| 2 +- >> include/qe/immap_qe.h| 491 + >> include/qe/qe.h | 794 >> +++ >> include/qe/qe_ic.h | 144 + >> include/qe/ucc.h | 64 +++ >> include/qe/ucc_fast.h| 244 >> include/qe/ucc_slow.h| 290 ++ >> 47 files changed, 5155 insertions(+), 4907 deletions(-) >> delete mode 100644 arch/powerpc/include/asm/immap_qe.h >> delete mode 100644 arch/powerpc/include/asm/qe.h >> delete mode 100644 arch/powerpc/include/asm/qe_ic.h >> delete mode 100644 arch/powerpc/include/asm/ucc.h >> delete mode 100644 arch/powerpc/include/asm/ucc_fast.h >> delete mode 100644 arch/powerpc/include/asm/ucc_slow.h >> delete mode 100644 arch/powerpc/sysdev/qe_lib/Kconfig >> delete mode 100644 arch/powerpc/sysdev/qe_lib/Makefile >> delete mode 100644 arch/powerpc/sysdev/qe_lib/gpio.c >> delete mode 100644 arch/powerpc/sysdev/qe_lib/qe.c >> delete mode 100644 arch/powerpc/sysdev/qe_lib/qe_ic.c >> delete mode 100644 arch/powerpc/sysdev/qe_lib/qe_ic.h >> delete mode 100644 arch/powerpc/sysdev/qe_lib/qe_io.c >> delete mode 100644 arch/powerpc/sysdev/qe_lib/ucc.c >> delete mode 100644 arch/powerpc/sysdev/qe_lib/ucc_fast.c >> delete mode 100644 arch/powerpc/sysdev/qe_lib/ucc_slow.c >> delete mode 100644 arch/powerpc/sysdev/qe_lib/usb.c >> create mode 100644 drivers/qe/Kconfig >> create mode 100644 drivers/qe/Makefile >> create mode 100644 drivers/qe/gpio.c >> create mode
Re: [PATCH] powerpc/qe_lib: Share the qe_lib for the others architecture
On Oct 15, 2013, at 8:16 AM, Gerhard Sittig wrote: > On Mon, Oct 14, 2013 at 13:09 -0700, Greg Kroah-Hartman wrote: >> >> On Mon, Oct 14, 2013 at 02:40:44PM -0500, Kumar Gala wrote: >>> >>> Greg, >>> >>> Wondering your thoughts on drivers/qe vs something like >>> drivers/soc/fsl/qe. The QuiccEngine (qe) is a communication core on >>> some of the Freescale networking SoCs that provides the ability to do >>> various networking/communication functionality. "Channels" on the QE >>> can be used for various different things from ethernet, ATM, UART, or >>> other functions. >> >> What makes the code "QE" specific? Are these devices that live on the >> QE "bus", or are they controlling the QE controller? > > You may think of the QUICC as a "programmable bitbang machine" if > you like. The very same component runs arbitrary and rather > different protocols depending on how you setup its parameters. > > There have been serial controllers capable of different protocols > like UART or SPI or I2S, but all of them are "serial > communication". There have been memory controllers which could > bitbang different protocols (NAND, NOR/SRAM, DRAM), but all of > them are "memory". > > The QUICC is just a little more versatile, and appears to cover > cases which reside in different Linux kernel subsystems (like: > it's neither serial nor network exclusively, but can be either > and potentially more). > > IIUC the question which Kumar Gala was asking is where to put > code for the component which is neither a strict subset of any > subsystem. Please correct me if I'm wrong. Thanks for the description. Yeah, the actual ethernet, usb, serial drivers that exist with QE live today in proper drivers/ dirs. This is the infrastructure that those drivers utilize that isn't quite related to an existing subsystem. Mostly set up of channel state/cfg/etc. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [RFC] Emulate "lwsync" to run standard user land on e500 cores
On Oct 18, 2013, at 2:38 AM, Wolfgang Denk wrote:
> Default Debian PowerPC doesn't work on e500 because the code contains
> "lwsync" instructions, which are unsupported on this core. As a
> result, applications using this will crash with an "unhandled signal 4"
> "Illegal instruction" error.
>
> As a work around we add code to emulate this insn. This is expensive
> performance-wise, but allows to run standard user land code.
>
> Signed-off-by: Wolfgang Denk
> Cc: Benjamin Herrenschmidt
> Cc: Scott Wood
> ---
> I am aware that the clean solution to the problem is to build user
> space with compiler options that match the target architecture.
> However, sometimes this is just too much effort.
>
> Also, of course the performance of such an emulation sucks. But the
> the occurrence of such instructions is so rare that no significant
> slowdown can be oserved.
>
> I'm not sure if this should / could go into mainline. I'm posting it
> primarily so it can be found should anybody else need this.
> - wd
>
> arch/powerpc/kernel/traps.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> index f783c93..f330374 100644
> --- a/arch/powerpc/kernel/traps.c
> +++ b/arch/powerpc/kernel/traps.c
> @@ -986,6 +986,13 @@ static int emulate_instruction(struct pt_regs *regs)
> return 0;
> }
>
> + /* Emulating the lwsync insn as a sync insn */
> + if (instword == PPC_INST_LWSYNC) {
> + PPC_WARN_EMULATED(lwsync, regs);
> + asm volatile("sync" : : : "memory");
Do we really need the inline asm? Doesn't the fact of just taking an exception
and returning from it equate to a sync.
> + return 0;
> + }
> +
> /* Emulate the mcrxr insn. */
> if ((instword & PPC_INST_MCRXR_MASK) == PPC_INST_MCRXR) {
> int shift = (instword >> 21) & 0x1c;
> --
> 1.8.3.1
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Missing _restvr_20 and _savevr_20 subroutines for lib/raid6/altivec8.o
On Oct 19, 2013, at 5:24 PM, Ben Hutchings wrote: > When building lib/raid6/altivec8.o with gcc 4.8 on Debian, the compiler > is generating references to two new runtime subroutines which are > apparently not included in the kernel: > > ERROR: "_restvr_20" [lib/raid6/raid6_pq.ko] undefined! > ERROR: "_savevr_20" [lib/raid6/raid6_pq.ko] undefined! > > The save/restore subroutines are specified in > http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.7.1.html#SAVE-RESTORE > and we do have the _restgpr_* and _savegpr_* subroutines in > arch/powerpc/boot/crtsavres.S. I'm not sure whether these subroutines > should be added or whether this indicates the compiler is doing > something wrong. > > A configuration that triggers this is included below. > > Ben. Try with CONFIG_CC_OPTIMIZE_FOR_SIZE=n. A feature was added to gcc for -Os to "outline" the save/restore routines. I'm surprised this hasn't shown up sooner. Well need to add _restvr_* / _savevr_* to the version in lib/crtsaveres.S. http://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libgcc/config/rs6000/crtrestvr.S;hb=HEAD http://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=libgcc/config/rs6000/crtsavevr.S;hb=HEAD - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [RFC] Emulate "lwsync" to run standard user land on e500 cores
On Oct 23, 2013, at 5:15 AM, Scott Wood wrote:
> On Wed, 2013-10-23 at 00:07 -0500, Kumar Gala wrote:
>> On Oct 18, 2013, at 2:38 AM, Wolfgang Denk wrote:
>>> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
>>> index f783c93..f330374 100644
>>> --- a/arch/powerpc/kernel/traps.c
>>> +++ b/arch/powerpc/kernel/traps.c
>>> @@ -986,6 +986,13 @@ static int emulate_instruction(struct pt_regs *regs)
>>> return 0;
>>> }
>>>
>>> + /* Emulating the lwsync insn as a sync insn */
>>> + if (instword == PPC_INST_LWSYNC) {
>>> + PPC_WARN_EMULATED(lwsync, regs);
>>> + asm volatile("sync" : : : "memory");
>>
>> Do we really need the inline asm? Doesn't the fact of just taking an
>> exception and returning from it equate to a sync.
>
> No, it doesn't equate to a sync. See the discussion here:
> http://patchwork.ozlabs.org/patch/256747/
>
Thanks.
I'm not sure I'm a fan of doing this as it silently hides a significant
performance impact.
Could we possible re-write the userspace instruction to be a 'sync' when we hit
this?
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 02/12][v3] pci: fsl: add structure fsl_pci
On Oct 23, 2013, at 5:41 AM, Minghuan Lian wrote:
> PowerPC uses structure pci_controller to describe PCI controller,
> but ARM uses structure pci_sys_data. In order to support PowerPC
> and ARM simultaneously, the patch adds a structure fsl_pci that
> contains most of the members of the pci_controller and pci_sys_data.
> Meanwhile, it defines a interface fsl_arch_sys_to_pci() which should
> be implemented in architecture-specific PCI controller driver to
> convert pci_controller or pci_sys_data to fsl_pci.
>
> Signed-off-by: Minghuan Lian
> ---
> change log:
> v1-v3:
> Derived from http://patchwork.ozlabs.org/patch/278965/
>
> Based on upstream master.
> Based on the discussion of RFC version here
> http://patchwork.ozlabs.org/patch/274487/
>
> include/linux/fsl/pci-common.h | 41 +
> 1 file changed, 41 insertions(+)
NAK.
We discussed this some at the ARM Summit this week and the feeling is we need
to move to a common interface between the various ARCHs.
- k
>
> diff --git a/include/linux/fsl/pci-common.h b/include/linux/fsl/pci-common.h
> index 5e4f683..e56a040 100644
> --- a/include/linux/fsl/pci-common.h
> +++ b/include/linux/fsl/pci-common.h
> @@ -102,5 +102,46 @@ struct ccsr_pci {
>
> };
>
> +/*
> + * Structure of a PCI controller (host bridge)
> + */
> +struct fsl_pci {
> + struct list_head node;
> + bool is_pcie;
> + struct device_node *dn;
> + struct device *dev;
> +
> + int first_busno;
> + int last_busno;
> + int self_busno;
> + struct resource busn;
> +
> + struct pci_ops *ops;
> + struct ccsr_pci __iomem *regs;
> +
> + u32 indirect_type;
> +
> + struct resource io_resource;
> + resource_size_t io_base_phys;
> + resource_size_t pci_io_size;
> +
> + struct resource mem_resources[3];
> + resource_size_t mem_offset[3];
> +
> + int global_number; /* PCI domain number */
> +
> + resource_size_t dma_window_base_cur;
> + resource_size_t dma_window_size;
> +
> + void *sys;
> +};
> +
> +/*
> + * Convert architecture specific pci controller structure to fsl_pci
> + * PowerPC uses structure pci_controller and ARM uses structure pci_sys_data
> + * to describe pci controller.
> + */
> +extern struct fsl_pci *fsl_arch_sys_to_pci(void *sys);
> +
> #endif /* __PCI_COMMON_H */
> #endif /* __KERNEL__ */
> --
> 1.8.1.2
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [RFC] Emulate "lwsync" to run standard user land on e500 cores
On Oct 24, 2013, at 4:45 AM, Benjamin Herrenschmidt wrote:
> On Wed, 2013-10-23 at 23:06 -0500, Kumar Gala wrote:
>> On Oct 23, 2013, at 5:15 AM, Scott Wood wrote:
>>
>>> On Wed, 2013-10-23 at 00:07 -0500, Kumar Gala wrote:
>>>> On Oct 18, 2013, at 2:38 AM, Wolfgang Denk wrote:
>>>>> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
>>>>> index f783c93..f330374 100644
>>>>> --- a/arch/powerpc/kernel/traps.c
>>>>> +++ b/arch/powerpc/kernel/traps.c
>>>>> @@ -986,6 +986,13 @@ static int emulate_instruction(struct pt_regs *regs)
>>>>> return 0;
>>>>> }
>>>>>
>>>>> + /* Emulating the lwsync insn as a sync insn */
>>>>> + if (instword == PPC_INST_LWSYNC) {
>>>>> + PPC_WARN_EMULATED(lwsync, regs);
>>>>> + asm volatile("sync" : : : "memory");
>>>>
>>>> Do we really need the inline asm? Doesn't the fact of just taking an
>>>> exception and returning from it equate to a sync.
>>>
>>> No, it doesn't equate to a sync. See the discussion here:
>>> http://patchwork.ozlabs.org/patch/256747/
>>>
>>
>> Thanks.
>>
>> I'm not sure I'm a fan of doing this as it silently hides a significant
>> performance impact.
>>
>> Could we possible re-write the userspace instruction to be a 'sync' when we
>> hit this?
>
> Rewriting user space is a can of worms I wouldn't get into ... is any
> other arch doing it ?
Fair enough
>
> I'm not too worried as long as we warn and account them.
Than, I'd ask this be under a Kconfig option that is disabled by default.
Users should have to explicitly enable this so they know what they are doing.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [RFC] Emulate "lwsync" to run standard user land on e500 cores
On Oct 24, 2013, at 4:05 PM, James Yang wrote:
> On Thu, 24 Oct 2013, Kumar Gala wrote:
>
>> On Oct 24, 2013, at 4:45 AM, Benjamin Herrenschmidt wrote:
>>
>>> On Wed, 2013-10-23 at 23:06 -0500, Kumar Gala wrote:
>>>> On Oct 23, 2013, at 5:15 AM, Scott Wood wrote:
>>>>
>>>>> On Wed, 2013-10-23 at 00:07 -0500, Kumar Gala wrote:
>>>>>> On Oct 18, 2013, at 2:38 AM, Wolfgang Denk wrote:
>>>>>>> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
>>>>>>> index f783c93..f330374 100644
>>>>>>> --- a/arch/powerpc/kernel/traps.c
>>>>>>> +++ b/arch/powerpc/kernel/traps.c
>>>>>>> @@ -986,6 +986,13 @@ static int emulate_instruction(struct pt_regs
>>>>>>> *regs)
>>>>>>> return 0;
>>>>>>> }
>>>>>>>
>>>>>>> + /* Emulating the lwsync insn as a sync insn */
>>>>>>> + if (instword == PPC_INST_LWSYNC) {
>>>>>>> + PPC_WARN_EMULATED(lwsync, regs);
>>>>>>> + asm volatile("sync" : : : "memory");
>>>>>>
>>>>>> Do we really need the inline asm? Doesn't the fact of just taking an
>>>>>> exception and returning from it equate to a sync.
>>>>>
>>>>> No, it doesn't equate to a sync. See the discussion here:
>>>>> http://patchwork.ozlabs.org/patch/256747/
>>>>>
>>>>
>>>> Thanks.
>>>>
>>>> I'm not sure I'm a fan of doing this as it silently hides a
>>>> significant performance impact.
>>>>
>>>> Could we possible re-write the userspace instruction to be a
>>>> 'sync' when we hit this?
>>>
>>> Rewriting user space is a can of worms I wouldn't get into ... is
>>> any other arch doing it ?
>>
>> Fair enough
>>>
>>> I'm not too worried as long as we warn and account them.
>>
>> Than, I'd ask this be under a Kconfig option that is disabled by
>> default. Users should have to explicitly enable this so they know
>> what they are doing.
>
>
> I think it should be enabled by default, rather than disabled, so that
> users would actually see a warning rather than get a sig 4. Or, let
> it not be Kconfig-able so that this doesn't become a problem any more.
> (It's been 4 years since I sent to you an earlier version of this
> patch.)
And clearly most users don't seem terrible annoyed enough about this issue to
have concerns. I don't see why making it a Kconfig option impacts the small
handful of people that happen to try and run a more generic distro on e500
cores.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [RFC] Emulate "lwsync" to run standard user land on e500 cores
On Oct 25, 2013, at 8:02 AM, Benjamin Herrenschmidt wrote: > On Fri, 2013-10-25 at 10:58 +0100, David Laight wrote: >>> This is not a distro issue. It's a libstdc++ portability issue. libstdc++ >>> hardcodes lwsync unless __NO_LWSYNC__ is explicitly defined, >>> which you only get with -mcpu=8540/-mcpu=8548. When compiled >>> for any powerpc target other than -mcpu=8540/-mcpu=8548, including >>> the default -mcpu=common, libstdc++ will end up containing lwsync. >>> There is no way to explicitly request libstdc++ to be built without lwsync >>> with an -mcpu target other than 8540/8548. >>> >>> The issue is easily demonstrated by running a program that throws a >>> C++ exception: __cxa_throw() is called, which has an lwsync. This >>> results in an illegal instruction exception when run on an e500v1/e500v2. >> >> Perhaps libstc++ should be working out at run time whether lwsync is valid? > > Do we have enough coats of paint on this bike shed yet ? :-) > > I'm personally tempted to take Scott's approach since that's what we do > for other things as well, it just works and is simple. > > Cheers, > Ben. > I give in, however some should test with CONFIG_PPC_EMULATED_STATS and fix what I'm guessing is a build breakage with either patch. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] dma: imx-sdma: Add ssi dual fifo script support
On Oct 29, 2013, at 7:33 AM, Nicolin Chen wrote: > There's a script for SSI missing in current sdma script list. Thus add it. > This script would allow SSI use its dual fifo mode to transimit/receive > data without occasional hardware underrun/overrun. > > This patch also fixed a counting error for total number of scripts. > > Signed-off-by: Nicolin Chen > --- > Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt | 1 + > drivers/dma/imx-sdma.c | 6 +- > include/linux/platform_data/dma-imx-sdma.h | 2 ++ > include/linux/platform_data/dma-imx.h | 1 + > 4 files changed, 9 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt > b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt > index 4fa814d..3b933c5 100644 > --- a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt > +++ b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt > @@ -42,6 +42,7 @@ The full ID of peripheral types can be found below. > 19 IPU Memory > 20 ASRC > 21 ESAI > + 22 SSI Dual FIFO > > The third cell specifies the transfer priority as below. For the DT-Binding portion: Acked-by: Kumar Gala - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
On Nov 11, 2013, at 1:25 PM, Lijun Pan wrote: > mpc85xx_smp_defconfig and mpc85xx_defconfig already have CONFIG_P1023RDS=y. > Merge CONFIG_P1023RDB=y and other relevant configurations into > mpc85xx_smp_defconfig and mpc85_defconfig. > > Signed-off-by: Lijun Pan > --- > arch/powerpc/configs/85xx/p1023_defconfig | 188 > arch/powerpc/configs/mpc85xx_defconfig | 18 +++ > arch/powerpc/configs/mpc85xx_smp_defconfig | 17 +++ > 3 files changed, 35 insertions(+), 188 deletions(-) > delete mode 100644 arch/powerpc/configs/85xx/p1023_defconfig How much of the changes to mpc85xx_defconfig & mpc85xx_smp_defconfig are based on just updating them vs changes for p1023? Can we do this as two patches. One that updates mpc85xx_defconfig & mpc85xx_smp_defconfig and one that makes the p1023 changes. That is much easier to review as well. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Revert "crypto: caam - Updated SEC-4.0 device tree binding for ERA information."
On Dec 7, 2012, at 2:57 AM, Vakul Garg wrote: > This reverts commit a2c0911c09190125f52c9941b9d187f601c2f7be. > > Signed-off-by: Vakul Garg > --- > Instead of adding SEC era information in crypto node's compatible, a new > property 'fsl,sec-era' is being introduced into crypto node. > > .../devicetree/bindings/crypto/fsl-sec4.txt|5 ++--- > 1 files changed, 2 insertions(+), 3 deletions(-) What tree do you think this has been applied to? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add support for context switching the TAR register
On Dec 19, 2012, at 12:03 AM, Ian Munsie wrote:
> From: Ian Munsie
>
> This patch adds support for enabling and context switching the Target
> Address Register in Power8. The TAR is a new special purpose register
> that can be used for computed branches with the bctar[l] (branch
> conditional to TAR) instruction in the same manner as the count and link
> registers.
>
> Signed-off-by: Ian Munsie
> Signed-off-by: Matt Evans
> ---
> arch/powerpc/include/asm/cputable.h |3 ++-
> arch/powerpc/include/asm/processor.h |1 +
> arch/powerpc/include/asm/reg.h|3 +++
> arch/powerpc/kernel/asm-offsets.c |1 +
> arch/powerpc/kernel/cpu_setup_power.S |7 +++
> arch/powerpc/kernel/entry_64.S| 16
> 6 files changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/cputable.h
> b/arch/powerpc/include/asm/cputable.h
> index 74458e69..cbbec56a 100644
> --- a/arch/powerpc/include/asm/cputable.h
> +++ b/arch/powerpc/include/asm/cputable.h
> @@ -172,6 +172,7 @@ extern const char *powerpc_base_platform;
> #define CPU_FTR_ICSWX LONG_ASM_CONST(0x1000)
> #define CPU_FTR_VMX_COPY LONG_ASM_CONST(0x2000)
> #define CPU_FTR_TMLONG_ASM_CONST(0x4000)
> +#define CPU_FTR_BCTAR
> LONG_ASM_CONST(0x8000)
>
> #ifndef __ASSEMBLY__
>
> @@ -417,7 +418,7 @@ extern const char *powerpc_base_platform;
> CPU_FTR_DSCR | CPU_FTR_SAO | \
> CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_POPCNTB | CPU_FTR_POPCNTD | \
> CPU_FTR_ICSWX | CPU_FTR_CFAR | CPU_FTR_HVMODE | CPU_FTR_VMX_COPY | \
> - CPU_FTR_DBELL | CPU_FTR_TM_COMP)
> + CPU_FTR_DBELL | CPU_FTR_TM_COMP | CPU_FTR_BCTAR)
> #define CPU_FTRS_CELL (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
> CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
> CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
> diff --git a/arch/powerpc/include/asm/processor.h
> b/arch/powerpc/include/asm/processor.h
> index 8b2bf7a..cbbd82d 100644
> --- a/arch/powerpc/include/asm/processor.h
> +++ b/arch/powerpc/include/asm/processor.h
> @@ -275,6 +275,7 @@ struct thread_struct {
> unsigned long dscr;
> int dscr_inherit;
> #endif
> + unsigned long tar;
This needs a #ifdef CONFIG_PPC64 and personally I'd rather it be a
CONFIG_PPC_BOOK3S_64. This will also ripple into other locations like
asm-offsets.c.
> };
>
> #define ARCH_MIN_TASKALIGN 16
> diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
> index 5c9fe38..1fa8a56 100644
> --- a/arch/powerpc/include/asm/reg.h
> +++ b/arch/powerpc/include/asm/reg.h
> @@ -257,6 +257,9 @@
> #define SPRN_HRMOR0x139 /* Real mode offset register */
> #define SPRN_HSRR00x13A /* Hypervisor Save/Restore 0 */
> #define SPRN_HSRR10x13B /* Hypervisor Save/Restore 1 */
> +#define SPRN_FSCR0x099 /* Facility Status & Control Register */
> +#define FSCR_TAR (1<<8) /* Enable Target Adress Register */
> +#define SPRN_TAR 0x32f /* Target Address Register */
> #define SPRN_LPCR 0x13E /* LPAR Control Register */
> #define LPCR_VPM0 (1ul << (63-0))
> #define LPCR_VPM1 (1ul << (63-1))
> diff --git a/arch/powerpc/kernel/asm-offsets.c
> b/arch/powerpc/kernel/asm-offsets.c
> index 42a4243..77e941e 100644
> --- a/arch/powerpc/kernel/asm-offsets.c
> +++ b/arch/powerpc/kernel/asm-offsets.c
> @@ -145,6 +145,7 @@ int main(void)
> DEFINE(TM_FRAME_SIZE, STACK_FRAME_OVERHEAD +
> sizeof(struct pt_regs) + 16);
> #endif /* CONFIG_TRANSACTIONAL_MEM */
> + DEFINE(THREAD_TAR, offsetof(struct thread_struct, tar));
>
> DEFINE(TI_FLAGS, offsetof(struct thread_info, flags));
> DEFINE(TI_LOCAL_FLAGS, offsetof(struct thread_info, local_flags));
> diff --git a/arch/powerpc/kernel/cpu_setup_power.S
> b/arch/powerpc/kernel/cpu_setup_power.S
> index 57cf140..d29facb 100644
> --- a/arch/powerpc/kernel/cpu_setup_power.S
> +++ b/arch/powerpc/kernel/cpu_setup_power.S
> @@ -56,6 +56,7 @@ _GLOBAL(__setup_cpu_power8)
> mfspr r3,SPRN_LPCR
> orisr3, r3, LPCR_AIL_3@h
> bl __init_LPCR
> + bl __init_FSCR
> bl __init_TLB
> mtlrr11
> blr
> @@ -112,6 +113,12 @@ __init_LPCR:
> isync
> blr
>
> +__init_FSCR:
> + mfspr r3,SPRN_FSCR
> + ori r3,r3,FSCR_TAR
> + mtspr SPRN_FSCR,r3
> + blr
> +
> __init_TLB:
> /* Clear the TLB */
> li r6,128
> diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
> index b3590c3..253885d 100644
> --- a/arch/powerpc/kernel/entry_64.S
> +++ b/arch/powerpc/kernel/entry_64.S
> @@ -451,6 +451,17 @@ END_FTR_SECTION_IFSET(CPU_FTR_DSCR)
> std r23,_CCR(r1)
> std r1,KSP(r3) /* Set old stack pointer */
>
> +BEGIN_FTR_SECTION
> + /*
> + * Back up the TAR across context swit
Re: [v1][PATCH 3/6] book3e/kgdb: update thread's dbcr0
On Dec 20, 2012, at 3:08 AM, Tiejun Chen wrote:
> gdb always need to generate a single step properly to invoke
> a kgdb state. But with lazy interrupt, book3e can't always
> trigger a debug exception with a single step since the current
> is blocked for handling those pending exception, then we miss
> that expected dbcr configuration at last to generate a debug
> exception.
>
> So here we also update thread's dbcr0 to make sure the current
> can go back with that missed dbcr0 configuration.
>
> Signed-off-by: Tiejun Chen
> ---
> arch/powerpc/kernel/kgdb.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
> index c470a40..516b44b 100644
> --- a/arch/powerpc/kernel/kgdb.c
> +++ b/arch/powerpc/kernel/kgdb.c
> @@ -426,8 +426,18 @@ int kgdb_arch_handle_exception(int vector, int signo,
> int err_code,
> /* set the trace bit if we're stepping */
> if (remcom_in_buffer[0] == 's') {
> #ifdef CONFIG_PPC_ADV_DEBUG_REGS
> +#ifdef CONFIG_PPC_BOOK3E
Should this really be CONFIG_PPC64 or CONFIG_PPC_BOOK3E_64?
> + /* With lazy interrut we have to update thread dbcr0
> here
> + * to make sure we can set debug properly at last to
> invoke
> + * kgdb again to work well.
> + */
> + current->thread.dbcr0 =
> + mfspr(SPRN_DBCR0) | DBCR0_IC | DBCR0_IDM;
> + mtspr(SPRN_DBCR0, current->thread.dbcr0);
> +#else
> mtspr(SPRN_DBCR0,
> mfspr(SPRN_DBCR0) | DBCR0_IC | DBCR0_IDM);
> +#endif
Can we code this so we don't need the #else?
> linux_regs->msr |= MSR_DE;
> #else
> linux_regs->msr |= MSR_SE;
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mm: eliminate unneeded for_each_memblock
On Jan 4, 2013, at 12:06 PM, Cody P Schafer wrote: > The only persistent change made by this loop is calling > memblock_set_node() once for each memblock, which is not useful (and has > no effect) as memblock_set_node() is not called with any > memblock-specific parameters. > > Subsistute a single memblock_set_node(). > --- > arch/powerpc/mm/mem.c | 9 ++--- > 1 file changed, 2 insertions(+), 7 deletions(-) Missing a signed-off-by - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/mpic: allow coreint to be determined by MPIC version
On Jan 21, 2013, at 7:56 PM, Scott Wood wrote: > This will be used by the qemu-e500 platform, as the MPIC version (and > thus whether we have coreint) depends on how QEMU is configured. > > Signed-off-by: Scott Wood > --- > arch/powerpc/sysdev/mpic.c | 26 +++--- > 1 file changed, 23 insertions(+), 3 deletions(-) Is the idea that we'd set mpic->flags such that MPIC_ENABLE_COREINT was set, but based on the controller version we'd ignore the flag? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: dts - add ranges property for SEC
On Jan 18, 2013, at 2:40 PM, Kim Phillips wrote: > On Fri, 18 Jan 2013 17:16:13 +0800 > Po Liu wrote: > >> This facilitates getting the physical address of the SEC node. >> >> Signed-off-by: Liu po >> --- > Reviewed-by: Kim Phillips > > Kim This was missing a trailing ';', so wondering if it was ever tested? I fixed when I applied. applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] powerpc/82xx: fix checkpatch warnings for km82xx.c
On Dec 7, 2012, at 9:09 AM, Holger Brunck wrote: > Signed-off-by: Holger Brunck > cc: Kumar Gala > --- > arch/powerpc/platforms/82xx/km82xx.c |6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) applied 1-5 to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] powerpc: split sbc8548 dts file into pre and post chunks
On Jan 23, 2013, at 2:13 PM, Paul Gortmaker wrote: > Updates to u-boot allow this board to boot off of either > the 8MB soldered on flash, or the 64MB SODIMM flash. > > This is achieved by changing JP12 and SW2.8 which in turn > swaps which flash device appears on /CS0 and /CS6 respectively. > > Since the flash devices are not the same size, this also > changes the MTD memory map layout on the local bus. > > Here we split the common chunks out into a pre and post > include, so they can be reused by an upcoming "alternative > boot" dts file; leaving only the local bus chunk behind. > > No content changes are made at this point - it is just purely > the move to using include files. > > Signed-off-by: Paul Gortmaker > --- > arch/powerpc/boot/dts/sbc8548-post.dtsi | 295 + > arch/powerpc/boot/dts/sbc8548-pre.dtsi | 52 ++ > arch/powerpc/boot/dts/sbc8548.dts | 322 +--- > 3 files changed, 351 insertions(+), 318 deletions(-) > create mode 100644 arch/powerpc/boot/dts/sbc8548-post.dtsi > create mode 100644 arch/powerpc/boot/dts/sbc8548-pre.dtsi applied 1-4 to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] powerpc/fsl: msi: sparse fixes
On Nov 30, 2012, at 5:34 PM, Kim Phillips wrote: > arch/powerpc/sysdev/fsl_msi.c:31:1: warning: symbol 'msi_head' was not > declared. Should it be static? > arch/powerpc/sysdev/fsl_msi.c:138:40: warning: incorrect type in argument 1 > (different base types) > arch/powerpc/sysdev/fsl_msi.c:138:40:expected restricted __be64 const > [usertype] *p > arch/powerpc/sysdev/fsl_msi.c:138:40:got unsigned long long const > [usertype] *[assigned] reg > > Signed-off-by: Kim Phillips > --- > arch/powerpc/sysdev/fsl_msi.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) applied 1-4 to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -next] powerpc/85xx: use for_each_compatible_node() macro
On Dec 3, 2012, at 7:36 AM, Wei Yongjun wrote: > From: Wei Yongjun > > Use for_each_compatible_node() macro instead of open coding it. > > Signed-off-by: Wei Yongjun > --- > arch/powerpc/platforms/85xx/mpc85xx_mds.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv1] crypto: caam - Added property fsl, sec-era in SEC4.0 device tree binding.
On Jan 23, 2013, at 1:21 AM, Vakul Garg wrote: > This new property defines the era of the particular SEC version. > The compatible property in device tree "crypto" node has been updated > not to contain SEC era numbers. > > Signed-off-by: Vakul Garg > --- > Changelog: > 1. Marked fsl,sec-era as 'optional'. > > .../devicetree/bindings/crypto/fsl-sec4.txt| 12 +--- > 1 files changed, 9 insertions(+), 3 deletions(-) applied to next. I assume this supersedes http://patchwork.ozlabs.org/patch/204431/ - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] powerpc/fsl: msi: sparse fixes
On Nov 30, 2012, at 5:34 PM, Kim Phillips wrote: > arch/powerpc/sysdev/fsl_msi.c:31:1: warning: symbol 'msi_head' was not > declared. Should it be static? > arch/powerpc/sysdev/fsl_msi.c:138:40: warning: incorrect type in argument 1 > (different base types) > arch/powerpc/sysdev/fsl_msi.c:138:40:expected restricted __be64 const > [usertype] *p > arch/powerpc/sysdev/fsl_msi.c:138:40:got unsigned long long const > [usertype] *[assigned] reg > > Signed-off-by: Kim Phillips > --- > arch/powerpc/sysdev/fsl_msi.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) applied 1-4 to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/1] powerpc/85xx: Board support for ppa8548
On Feb 4, 2013, at 9:30 AM, Timur Tabi wrote:
> On 02/03/2013 01:39 PM, Stef van Os wrote:
>
>> +pci0: pci@fe0008000 {
>> +status = "disabled";
>> +};
>> +
>> +pci1: pci@fe0009000 {
>> +status = "disabled";
>> +};
>> +
>> +pci2: pcie@fe000a000 {
>> +status = "disabled";
>> +};
>
> I was hoping you'd follow my example and include a comment indicating why the
> PCI devices are all disabled.
>
>> +static void ppa8548_show_cpuinfo(struct seq_file *m)
>> +{
>> +uint svid, phid1;
>
> Please don't used unsized integers for hardware registers.
>
> uint32_t svid, phid1;
Stef,
If you'd like this included for 3.9, please make the minor updates.
thanks
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 06/17] powerpc: Add transactional memory paca scratch register to show_regs
On Feb 12, 2013, at 10:31 PM, Michael Neuling wrote:
> Add transactional memory paca scratch register to show_regs. This is useful
> for debugging.
>
> Signed-off-by: Matt Evans
> Signed-off-by: Michael Neuling
> ---
> arch/powerpc/include/asm/paca.h |1 +
> arch/powerpc/kernel/asm-offsets.c |1 +
> arch/powerpc/kernel/entry_64.S|4
> arch/powerpc/kernel/process.c |3 +++
> 4 files changed, 9 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
> index c47d687..07e9851 100644
> --- a/arch/powerpc/include/asm/paca.h
> +++ b/arch/powerpc/include/asm/paca.h
> @@ -137,6 +137,7 @@ struct paca_struct {
> u8 irq_work_pending;/* IRQ_WORK interrupt while
> soft-disable */
> u8 nap_state_lost; /* NV GPR values lost in power7_idle */
> u64 sprg3; /* Saved user-visible sprg */
#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
> + u64 tm_scratch; /* TM scratch area for reclaim */
#endif
>
> #ifdef CONFIG_PPC_POWERNV
> /* Pointer to OPAL machine check event structure set by the
> diff --git a/arch/powerpc/kernel/asm-offsets.c
> b/arch/powerpc/kernel/asm-offsets.c
> index b67e4c3..f9654b6 100644
> --- a/arch/powerpc/kernel/asm-offsets.c
> +++ b/arch/powerpc/kernel/asm-offsets.c
> @@ -126,6 +126,7 @@ int main(void)
> DEFINE(THREAD_TAR, offsetof(struct thread_struct, tar));
> #endif
> #ifdef CONFIG_PPC_TRANSACTIONAL_MEM
> + DEFINE(PACATMSCRATCH, offsetof(struct paca_struct, tm_scratch));
> DEFINE(THREAD_TM_TFHAR, offsetof(struct thread_struct, tm_tfhar));
> DEFINE(THREAD_TM_TEXASR, offsetof(struct thread_struct, tm_texasr));
> DEFINE(THREAD_TM_TFIAR, offsetof(struct thread_struct, tm_tfiar));
> diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
> index 9ae8451..612ea13 100644
> --- a/arch/powerpc/kernel/entry_64.S
> +++ b/arch/powerpc/kernel/entry_64.S
> @@ -785,6 +785,10 @@ fast_exception_return:
> andcr4,r4,r0 /* r0 contains MSR_RI here */
> mtmsrd r4,1
>
> +#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
> + /* TM debug */
> + std r3, PACATMSCRATCH(r13) /* Stash returned-to MSR */
> +#endif
> /*
>* r13 is our per cpu area, only restore it if we are returning to
>* userspace the value stored in the stack frame may belong to
> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> index b0a0321..1cc4053 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -754,6 +754,9 @@ void show_regs(struct pt_regs * regs)
> printk("NIP ["REG"] %pS\n", regs->nip, (void *)regs->nip);
> printk("LR ["REG"] %pS\n", regs->link, (void *)regs->link);
> #endif
> +#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
> + printk("PACATMSCRATCH [%llx]\n", get_paca()->tm_scratch);
> +#endif
> show_stack(current, (unsigned long *) regs->gpr[1]);
> if (!user_mode(regs))
> show_instructions(regs);
> --
> 1.7.10.4
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 08/17] powerpc: Add FP/VSX and VMX register load functions for transactional memory
On Feb 12, 2013, at 10:31 PM, Michael Neuling wrote: > This adds functions to restore the state of the FP/VSX registers from > what's stored in the thread_struct. Two version for FP/VSX are required > since one restores them from transactional/checkpoint side of the > thread_struct and the other from the speculated side. > > Similar functions are added for VMX registers. > > Signed-off-by: Matt Evans > Signed-off-by: Michael Neuling > --- > arch/powerpc/kernel/fpu.S| 54 ++ > arch/powerpc/kernel/vector.S | 51 +++ > 2 files changed, 105 insertions(+) > > diff --git a/arch/powerpc/kernel/fpu.S b/arch/powerpc/kernel/fpu.S > index adb1551..0441ba6 100644 > --- a/arch/powerpc/kernel/fpu.S > +++ b/arch/powerpc/kernel/fpu.S > @@ -62,6 +62,60 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX); > \ > __REST_32FPVSRS_TRANSACT(n,__REG_##c,__REG_##base) > #define SAVE_32FPVSRS(n,c,base) __SAVE_32FPVSRS(n,__REG_##c,__REG_##base) > > +#ifdef CONFIG_PPC_TRANSACTIONAL_MEM > +/* > + * Wrapper to call load_up_fpu from C. > + * void do_load_up_fpu(struct pt_regs *regs); > + */ > +_GLOBAL(do_load_up_fpu) > + mflrr0 > + std r0, 16(r1) > + stdur1, -112(r1) > + > + subir6, r3, STACK_FRAME_OVERHEAD > + /* load_up_fpu expects r12=MSR, r13=PACA, and returns > + * with r12 = new MSR. > + */ > + ld r12,_MSR(r6) > + GET_PACA(r13) > + > + bl load_up_fpu > + std r12,_MSR(r6) > + > + ld r0, 112+16(r1) > + addir1, r1, 112 > + mtlrr0 > + blr > + > + > +/* void do_load_up_fpu(struct thread_struct *thread) Comment is wrong, should be void do_load_up_transact_fpu(...) > + * > + * This is similar to load_up_fpu but for the transactional version of the FP > + * register set. It doesn't mess with the task MSR or valid flags. > + * Furthermore, we don't do lazy FP with TM currently. > + */ > +_GLOBAL(do_load_up_transact_fpu) > + mfmsr r6 > + ori r5,r6,MSR_FP > +#ifdef CONFIG_VSX > +BEGIN_FTR_SECTION > + orisr5,r5,MSR_VSX@h > +END_FTR_SECTION_IFSET(CPU_FTR_VSX) > +#endif > + SYNC > + MTMSRD(r5) > + > + lfd fr0,THREAD_TRANSACT_FPSCR(r3) > + MTFSF_L(fr0) > + REST_32FPVSRS_TRANSACT(0, R4, R3) > + > + /* FP/VSX off again */ > + MTMSRD(r6) > + SYNC > + > + blr > +#endif /* CONFIG_PPC_TRANSACTIONAL_MEM */ > + > /* > * This task wants to use the FPU now. > * On UP, disable FP for the task which had the FPU previously, > diff --git a/arch/powerpc/kernel/vector.S b/arch/powerpc/kernel/vector.S > index e830289..7112a24 100644 > --- a/arch/powerpc/kernel/vector.S > +++ b/arch/powerpc/kernel/vector.S > @@ -7,6 +7,57 @@ > #include > #include > > +#ifdef CONFIG_PPC_TRANSACTIONAL_MEM > +/* > + * Wrapper to call load_up_altivec from C. > + * void do_load_up_altivec(struct pt_regs *regs); > + */ > +_GLOBAL(do_load_up_altivec) > + mflrr0 > + std r0, 16(r1) > + stdur1, -112(r1) > + > + subir6, r3, STACK_FRAME_OVERHEAD > + /* load_up_altivec expects r12=MSR, r13=PACA, and returns > + * with r12 = new MSR. > + */ > + ld r12,_MSR(r6) > + GET_PACA(r13) > + bl load_up_altivec > + std r12,_MSR(r6) > + > + ld r0, 112+16(r1) > + addir1, r1, 112 > + mtlrr0 > + blr > + > +/* void do_load_up_altivec(struct thread_struct *thread) comment wrong. > + * > + * This is similar to load_up_altivec but for the transactional version of > the > + * vector regs. It doesn't mess with the task MSR or valid flags. > + * Furthermore, VEC laziness is not supported with TM currently. > + */ > +_GLOBAL(do_load_up_transact_altivec) > + mfmsr r6 > + orisr5,r6,MSR_VEC@h > + MTMSRD(r5) > + isync > + > + li r4,1 > + stw r4,THREAD_USED_VR(r3) > + > + li r10,THREAD_TRANSACT_VSCR > + lvx vr0,r10,r3 > + mtvscr vr0 > + REST_32VRS_TRANSACT(0,r4,r3) > + > + /* Disable VEC again. */ > + MTMSRD(r6) > + isync > + > + blr > +#endif > + > /* > * load_up_altivec(unused, unused, tsk) > * Disable VMX for the task which had it previously, > -- > 1.7.10.4 > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 15/17] powerpc: Add config option for transactional memory
On Feb 12, 2013, at 10:31 PM, Michael Neuling wrote: > Kconfig option for transactional memory on powerpc. > > Signed-off-by: Matt Evans > Signed-off-by: Michael Neuling > --- > arch/powerpc/Kconfig |8 > 1 file changed, 8 insertions(+) > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index 4b27edb..fbeb6d2 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -313,6 +313,14 @@ config MATH_EMULATION > unit, which will allow programs that use floating-point > instructions to run. > > +config PPC_TRANSACTIONAL_MEM > + bool "Transactional Memory support for POWERPC" > + depends on PPC64 Should this really depend on PPC_BOOK3S_64 ? > + depends on SMP > + default n > + ---help--- > + Support user-mode Transactional Memory on POWERPC. > + > config 8XX_MINIMAL_FPEMU > bool "Minimal math emulation for 8xx" > depends on 8xx && !MATH_EMULATION > -- > 1.7.10.4 > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 8/15] arch/powerpc/platforms/85xx/p1022_ds.c: adjust duplicate test
On Jan 21, 2013, at 7:02 AM, Julia Lawall wrote:
> From: Julia Lawall
>
> Delete successive tests to the same location. The code tested the result
> of a previous call, that itself was already tested. It is changed to test
> the result of the most recent call.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> //
> @s exists@
> local idexpression y;
> expression x,e;
> @@
>
> *if ( \(x == NULL\|IS_ERR(x)\|y != 0\) )
> { ... when forall
> return ...; }
> ... when != \(y = e\|y += e\|y -= e\|y |= e\|y &= e\|y++\|y--\|&y\)
>when != \(XT_GETPAGE(...,y)\|WMI_CMD_BUF(...)\)
> *if ( \(x == NULL\|IS_ERR(x)\|y != 0\) )
> { ... when forall
> return ...; }
> //
>
> Signed-off-by: Julia Lawall
>
> ---
> arch/powerpc/platforms/85xx/p1022_ds.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
applied to next
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/1] powerpc/85xx: Board support for ppa8548
On Feb 13, 2013, at 8:09 AM, Stef van Os wrote: > Initial board support for the Prodrive PPA8548 AMC module. Board > is an MPC8548 AMC platform used in RapidIO systems. This module is > also used to test/work on mainline linux RapidIO software. > > PPA8548 overview: > - 1.3 GHz Freescale PowerQUICC III MPC8548 processor > - 1 GB DDR2 @ 266 MHz > - 8 MB NOR flash > - Serial RapidIO 1.2 > - 1 x 10/100/1000 BASE-T front ethernet > - 1 x 1000 BASE-BX ethernet on AMC connector > > Signed-off-by: Stef van Os > --- > arch/powerpc/boot/dts/ppa8548.dts | 166 +++ > arch/powerpc/configs/85xx/ppa8548_defconfig | 65 +++ > arch/powerpc/platforms/85xx/Kconfig |7 + > arch/powerpc/platforms/85xx/Makefile|1 + > arch/powerpc/platforms/85xx/ppa8548.c | 98 > 5 files changed, 337 insertions(+), 0 deletions(-) > create mode 100644 arch/powerpc/boot/dts/ppa8548.dts > create mode 100644 arch/powerpc/configs/85xx/ppa8548_defconfig > create mode 100644 arch/powerpc/platforms/85xx/ppa8548.c applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [linuxppc-dev][PATCH] powerpc/fsl_pci: Store the pci controller device pointer in the pci controller structure.
On Jan 14, 2013, at 5:28 AM, Varun Sethi wrote: > The pci controller structure has a provision to store the device strcuture > pointer of the corresponding platform device. Currently this information is > not stored during fsl pci controller initialization. This information is > required while dealing with iommu groups for pci devices connected to the fsl > pci controller. For the case where the pci devices can't be paritioned, they > would fall under the same device group as the pci controller. > > This patch stores the platform device information in the pci controller > structure during initialization. > > Signed-off-by: Varun Sethi > --- > arch/powerpc/sysdev/fsl_pci.c |9 +++-- > arch/powerpc/sysdev/fsl_pci.h |2 +- > 2 files changed, 8 insertions(+), 3 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/mpic: allow coreint to be determined by MPIC version
On Jan 21, 2013, at 7:56 PM, Scott Wood wrote: > This will be used by the qemu-e500 platform, as the MPIC version (and > thus whether we have coreint) depends on how QEMU is configured. > > Signed-off-by: Scott Wood > --- > arch/powerpc/sysdev/mpic.c | 26 +++--- > 1 file changed, 23 insertions(+), 3 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc/e500/qemu-e500: enable coreint
On Jan 21, 2013, at 7:56 PM, Scott Wood wrote: > The MPIC code will disable coreint if it detects an insufficient > MPIC version. > > Signed-off-by: Scott Wood > --- > arch/powerpc/platforms/85xx/qemu_e500.c |7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][UPSTEAM] powerpc/mpic: add irq_set_wake support
On Jan 30, 2013, at 9:10 PM, Wang Dongsheng wrote:
> Add irq_set_wake support. Just add IRQF_NO_SUSPEND to desc->action->flag.
> So the wake up interrupt will not be disable in suspend_device_irqs.
>
> Signed-off-by: Wang Dongsheng
> ---
> arch/powerpc/sysdev/mpic.c | 15 +++
> 1 files changed, 15 insertions(+), 0 deletions(-)
Why are we doing this globally for all interrupts? Don't we only have some
specific interrupts that wake us up?
Also, I'm guessing the wake behavior for interrupts is FSL specific so should
not apply to ALL users of MPIC.
- k
>
> diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> index 9c6e535..2ed0220 100644
> --- a/arch/powerpc/sysdev/mpic.c
> +++ b/arch/powerpc/sysdev/mpic.c
> @@ -920,6 +920,18 @@ int mpic_set_irq_type(struct irq_data *d, unsigned int
> flow_type)
> return IRQ_SET_MASK_OK_NOCOPY;
> }
>
> +static int mpic_irq_set_wake(struct irq_data *d, unsigned int on)
> +{
> + struct irq_desc *desc = container_of(d, struct irq_desc, irq_data);
> +
> + if (on)
> + desc->action->flags |= IRQF_NO_SUSPEND;
> + else
> + desc->action->flags &= ~IRQF_NO_SUSPEND;
> +
> + return 0;
> +}
> +
> void mpic_set_vector(unsigned int virq, unsigned int vector)
> {
> struct mpic *mpic = mpic_from_irq(virq);
> @@ -957,6 +969,7 @@ static struct irq_chip mpic_irq_chip = {
> .irq_unmask = mpic_unmask_irq,
> .irq_eoi= mpic_end_irq,
> .irq_set_type = mpic_set_irq_type,
> + .irq_set_wake = mpic_irq_set_wake,
> };
>
> #ifdef CONFIG_SMP
> @@ -971,6 +984,7 @@ static struct irq_chip mpic_tm_chip = {
> .irq_mask = mpic_mask_tm,
> .irq_unmask = mpic_unmask_tm,
> .irq_eoi= mpic_end_irq,
> + .irq_set_wake = mpic_irq_set_wake,
> };
>
> #ifdef CONFIG_MPIC_U3_HT_IRQS
> @@ -981,6 +995,7 @@ static struct irq_chip mpic_irq_ht_chip = {
> .irq_unmask = mpic_unmask_ht_irq,
> .irq_eoi= mpic_end_ht_irq,
> .irq_set_type = mpic_set_irq_type,
> + .irq_set_wake = mpic_irq_set_wake,
> };
> #endif /* CONFIG_MPIC_U3_HT_IRQS */
>
> --
> 1.7.5.1
>
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git next branch
Mostly misc code cleanups in various board ports and adding support for a new MPC85xx board - ppa8548. - k The following changes since commit 2468dcf641e4f3e1b0153e3e11ca20740b2f4ce8: Ian Munsie (1): powerpc: Add support for context switching the TAR register are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git next Gerlando Falauto (2): powerpc/83xx: refactor mpc8360e quirk for kmeter1 powerpc/83xx: apply mpc8360e quirk for kmeter1 only when par_io is present Harninder Rai (2): powerpc/85xx: bsc9131 - Correct typo in SDHC device node powerpc/85xx: l2sram - Add compatible string for BSC9131 platform Holger Brunck (3): powerpc/82xx: fix checkpatch warnings for km82xx.c powerpc/83xx: fix checkpatch warnings for km83xx.c powerpc/83xx: update kmeter1_defconfig Julia Lawall (1): arch/powerpc/platforms/85xx/p1022_ds.c: adjust duplicate test Kim Phillips (4): powerpc/fsl: lbc: sparse fixes powerpc/fsl: fsl_soc: sparse fixes powerpc/fsl: ifc: sparse fixes powerpc/fsl: msi: sparse fixes Paul Gortmaker (4): powerpc/85xx: split sbc8548 dts file into pre and post chunks powerpc/85xx: update sbc8548 flash information to match recent u-boot powerpc/85xx: add alternate dts file for sbc8548 boot via SODIMM powerpc/85xx: enable MTD options in sbc8548 defconfig Po Liu (1): powerpc/85xx: dts - add ranges property for SEC Scott Wood (2): powerpc/mpic: allow coreint to be determined by MPIC version powerpc/e500/qemu-e500: enable coreint Stef van Os (1): powerpc/85xx: Board support for ppa8548 Timur Tabi (3): powerpc/85xx: describe the PAMU topology in the device tree powerpc/85xx: fix various PCI node compatible strings powerpc/fsl: remove extraneous DIU platform functions Vakul Garg (1): crypto: caam - Added property fsl, sec-era in SEC4.0 device tree binding. Varun Sethi (1): powerpc/fsl_pci: Store the pci ctlr device ptr in the pci ctlr struct Wei Yongjun (1): powerpc/85xx: use for_each_compatible_node() macro .../devicetree/bindings/crypto/fsl-sec4.txt| 12 +- .../devicetree/bindings/powerpc/fsl/guts.txt | 13 +- .../devicetree/bindings/powerpc/fsl/pamu.txt | 140 arch/powerpc/boot/dts/bsc9131rdb.dtsi |2 +- arch/powerpc/boot/dts/fsl/p1010si-post.dtsi|4 +- arch/powerpc/boot/dts/fsl/p1022si-post.dtsi|6 +- arch/powerpc/boot/dts/fsl/p2041si-post.dtsi| 87 - arch/powerpc/boot/dts/fsl/p3041si-post.dtsi| 87 - arch/powerpc/boot/dts/fsl/p4080si-post.dtsi| 74 +++- arch/powerpc/boot/dts/fsl/p5020si-post.dtsi| 92 - arch/powerpc/boot/dts/fsl/p5040si-post.dtsi| 92 - arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi|1 + arch/powerpc/boot/dts/ppa8548.dts | 166 + arch/powerpc/boot/dts/sbc8548-altflash.dts | 115 +++ arch/powerpc/boot/dts/sbc8548-post.dtsi| 295 arch/powerpc/boot/dts/sbc8548-pre.dtsi | 52 +++ arch/powerpc/boot/dts/sbc8548.dts | 356 ++-- arch/powerpc/configs/83xx/kmeter1_defconfig|6 +- arch/powerpc/configs/85xx/ppa8548_defconfig| 65 arch/powerpc/configs/85xx/sbc8548_defconfig| 19 ++ arch/powerpc/platforms/512x/mpc512x_shared.c |5 - arch/powerpc/platforms/82xx/km82xx.c |6 +- arch/powerpc/platforms/83xx/km83xx.c | 161 - arch/powerpc/platforms/85xx/Kconfig|7 + arch/powerpc/platforms/85xx/Makefile |1 + arch/powerpc/platforms/85xx/mpc85xx_mds.c |4 +- arch/powerpc/platforms/85xx/p1022_ds.c | 40 +-- arch/powerpc/platforms/85xx/p1022_rdk.c| 12 - arch/powerpc/platforms/85xx/ppa8548.c | 98 ++ arch/powerpc/platforms/85xx/qemu_e500.c|7 +- arch/powerpc/sysdev/fsl_85xx_l2ctlr.c |1 + arch/powerpc/sysdev/fsl_ifc.c |2 +- arch/powerpc/sysdev/fsl_lbc.c |6 +- arch/powerpc/sysdev/fsl_msi.c |4 +- arch/powerpc/sysdev/fsl_pci.c | 24 +- arch/powerpc/sysdev/fsl_pci.h |2 +- arch/powerpc/sysdev/fsl_soc.c |4 +- arch/powerpc/sysdev/mpic.c | 26 +- 38 files changed, 1530 insertions(+), 564 deletions(-) create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/pamu.txt create mode 100644 arch/powerpc/boot/dts/ppa8548.dts create mode 100644 arch/powerpc/boot/dts/sbc8548-altflash.dts create mode 100644 arch/powerpc/boot/dts/sbc8548-post.dtsi create mode 100644 arch/powerpc/boot/dts/sbc8548-pre.dtsi create mode 100644 arch/powerpc/configs
Re: [PATCH 2/6] powerpc/fsl_pci: Store the platform device information corresponding to the pci controller.
On Feb 27, 2013, at 4:56 AM, Sethi Varun-B16395 wrote: > This patch is present in the "next branch" of linux ppc tree maintained by > Kumar Gala. > Following is the commit id: > 52c5affc545053d37c0b05224bbf70f5336caa20 > > I am not sure if this would be part of 3.9-rc1. > > Regards > varun This is now in Linus's tree so will be in 3.9-rc1 - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/6] powerpc/fsl_pci: Added defines for the FSL PCI controller BRR1 register.
On Feb 27, 2013, at 5:33 AM, Joerg Roedel wrote: > On Mon, Feb 18, 2013 at 06:22:16PM +0530, Varun Sethi wrote: >> Macros for checking FSL PCI controller version. >> >> Signed-off-by: Varun Sethi >> --- >> arch/powerpc/include/asm/pci-bridge.h |4 >> 1 files changed, 4 insertions(+), 0 deletions(-) >> >> diff --git a/arch/powerpc/include/asm/pci-bridge.h >> b/arch/powerpc/include/asm/pci-bridge.h >> index 025a130..c12ed78 100644 >> --- a/arch/powerpc/include/asm/pci-bridge.h >> +++ b/arch/powerpc/include/asm/pci-bridge.h >> @@ -14,6 +14,10 @@ >> >> struct device_node; >> >> +/* FSL PCI controller BRR1 register */ >> +#define PCI_FSL_BRR1 0xbf8 >> +#define PCI_FSL_BRR1_VER 0x >> + > > > Please merge this patch with the one where you actually make use of > these defines for the first time. > > > Joerg This also seems an odd place for these defines. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/6 v8] iommu/fsl: Store iommu domain information pointer in archdata.
On Feb 27, 2013, at 6:04 AM, Sethi Varun-B16395 wrote:
> Hi Kumar,Ben,
> I am implementing the Freescale PAMU (IOMMU) driver using the Linux IOMMU
> API. In this particular patch, I have added a new field to dev_archdata
> structure to store the dma domain information.
> This field is updated whenever we attach a device to an iommu domain.
>
> Regards
> Varun
Would be good to see if this overlaps with Alexey's work for IOMMU driver for
powernv.
- k
>
>> -Original Message-
>> From: Joerg Roedel [mailto:j...@8bytes.org]
>> Sent: Wednesday, February 27, 2013 5:01 PM
>> To: Sethi Varun-B16395
>> Cc: io...@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org;
>> linux-ker...@vger.kernel.org; Wood Scott-B07421; Yoder Stuart-B08248
>> Subject: Re: [PATCH 1/6 v8] iommu/fsl: Store iommu domain information
>> pointer in archdata.
>>
>> On Mon, Feb 18, 2013 at 06:22:14PM +0530, Varun Sethi wrote:
>>> Add a new field in the device (powerpc) archdata structure for storing
>>> iommu domain information pointer. This pointer is stored when the
>>> device is attached to a particular domain.
>>>
>>>
>>> Signed-off-by: Varun Sethi
>>> ---
>>> - no change.
>>> arch/powerpc/include/asm/device.h |4
>>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/powerpc/include/asm/device.h
>>> b/arch/powerpc/include/asm/device.h
>>> index 77e97dd..6dc79fe 100644
>>> --- a/arch/powerpc/include/asm/device.h
>>> +++ b/arch/powerpc/include/asm/device.h
>>> @@ -28,6 +28,10 @@ struct dev_archdata {
>>> void*iommu_table_base;
>>> } dma_data;
>>>
>>> + /* IOMMU domain information pointer. This would be set
>>> +* when this device is attached to an iommu_domain.
>>> +*/
>>> + void*iommu_domain;
>>
>> Please Cc the PowerPC Maintainers on this, so that they can have a look
>> at it. This also must be put this into an #ifdef CONFIG_IOMMU_API.
>>
>>
>> Joerg
>>
>>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/8] powerpc/fsl-booke: Support detection of page sizes on
The e6500 core used on T4240 and B4860 SoCs from FSL implements MMUv2 of
the Power Book-E Architecture. However there are some minor differences
between it and other Book-E implementations.
Add support to parse SPRN_TLB1PS for the variable page sizes supported.
In the future this should be expanded for more page sizes supported on
e6500 as well as other MMU features.
This patch is based on code from Scott Wood.
Signed-off-by: Kumar Gala
---
arch/powerpc/mm/tlb_nohash.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/tlb_nohash.c b/arch/powerpc/mm/tlb_nohash.c
index df32a83..6888cad 100644
--- a/arch/powerpc/mm/tlb_nohash.c
+++ b/arch/powerpc/mm/tlb_nohash.c
@@ -414,9 +414,9 @@ static void setup_page_sizes(void)
#ifdef CONFIG_PPC_FSL_BOOK3E
unsigned int mmucfg = mfspr(SPRN_MMUCFG);
+ int fsl_mmu = mmu_has_feature(MMU_FTR_TYPE_FSL_E);
- if (((mmucfg & MMUCFG_MAVN) == MMUCFG_MAVN_V1) &&
- (mmu_has_feature(MMU_FTR_TYPE_FSL_E))) {
+ if (fsl_mmu && (mmucfg & MMUCFG_MAVN) == MMUCFG_MAVN_V1) {
unsigned int tlb1cfg = mfspr(SPRN_TLB1CFG);
unsigned int min_pg, max_pg;
@@ -442,6 +442,20 @@ static void setup_page_sizes(void)
goto no_indirect;
}
+
+ if (fsl_mmu && (mmucfg & MMUCFG_MAVN) == MMUCFG_MAVN_V2) {
+ u32 tlb1ps = mfspr(SPRN_TLB1PS);
+
+ for (psize = 0; psize < MMU_PAGE_COUNT; ++psize) {
+ struct mmu_psize_def *def = &mmu_psize_defs[psize];
+
+ if (tlb1ps & (1U << (def->shift - 10))) {
+ def->flags |= MMU_PAGE_SIZE_DIRECT;
+ }
+ }
+
+ goto no_indirect;
+ }
#endif
tlb0cfg = mfspr(SPRN_TLB0CFG);
--
1.7.9.7
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/8] powerpc/85xx: Add support for FSL PCIe controller v3.0
From: Roy ZANG
The T4240 utilizes a new PCIe controller block that has some minor
programming model differences from previous versions.
The major one that impacts initialization is how we determine the link
state. On the 3.x controllers we have a memory mapped SoC register
instead of a PCI config register that reports the link state.
Signed-off-by: Roy Zang
Signed-off-by: Andy Fleming
Signed-off-by: Kumar Gala
---
arch/powerpc/sysdev/fsl_pci.c | 29 ++---
arch/powerpc/sysdev/fsl_pci.h | 11 +++
2 files changed, 37 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 682084d..3271177 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -54,13 +54,35 @@ static void quirk_fsl_pcie_header(struct pci_dev *dev)
return;
}
-static int __init fsl_pcie_check_link(struct pci_controller *hose)
+static int __init fsl_pcie_check_link(struct pci_controller *hose,
+ struct resource *rsrc)
{
+ struct ccsr_pci __iomem *pci = NULL;
u32 val;
+ /* for PCIe IP rev 3.0 or greater use CSR0 for link state */
+ if (rsrc) {
+ pr_debug("PCI memory map start 0x%016llx, size 0x%016llx\n",
+ (u64)rsrc->start, (u64)rsrc->end - (u64)rsrc->start + 1);
+ pci = ioremap(rsrc->start, rsrc->end - rsrc->start + 1);
+ if (!pci) {
+ dev_err(hose->parent, "Unable to map PCIe registers\n");
+ return -ENOMEM;
+ }
+ if (in_be32(&pci->block_rev1) >= PCIE_IP_REV_3_0) {
+ val = (in_be32(&pci->pex_csr0) & PEX_CSR0_LTSSM_MASK)
+ >> PEX_CSR0_LTSSM_SHIFT;
+ if (val != PEX_CSR0_LTSSM_L0)
+ return 1;
+ iounmap(pci);
+ return 0;
+ }
+ iounmap(pci);
+ }
early_read_config_dword(hose, 0, 0, PCIE_LTSSM, &val);
if (val < PCIE_LTSSM_L0)
return 1;
+
return 0;
}
@@ -483,7 +505,7 @@ int __init fsl_add_bridge(struct platform_device *pdev, int
is_primary)
if (early_find_capability(hose, 0, 0, PCI_CAP_ID_EXP)) {
hose->indirect_type |= PPC_INDIRECT_TYPE_EXT_REG |
PPC_INDIRECT_TYPE_SURPRESS_PRIMARY_BUS;
- if (fsl_pcie_check_link(hose))
+ if (fsl_pcie_check_link(hose, &rsrc))
hose->indirect_type |= PPC_INDIRECT_TYPE_NO_PCIE_LINK;
}
@@ -685,7 +707,7 @@ static int __init mpc83xx_pcie_setup(struct pci_controller
*hose,
out_le32(pcie->cfg_type0 + PEX_OUTWIN0_TAH, 0);
out_le32(pcie->cfg_type0 + PEX_OUTWIN0_TAL, 0);
- if (fsl_pcie_check_link(hose))
+ if (fsl_pcie_check_link(hose, NULL))
hose->indirect_type |= PPC_INDIRECT_TYPE_NO_PCIE_LINK;
return 0;
@@ -836,6 +858,7 @@ static const struct of_device_id pci_ids[] = {
{ .compatible = "fsl,qoriq-pcie-v2.2", },
{ .compatible = "fsl,qoriq-pcie-v2.3", },
{ .compatible = "fsl,qoriq-pcie-v2.4", },
+ { .compatible = "fsl,qoriq-pcie-v3.0", },
/*
* The following entries are for compatibility with older device
diff --git a/arch/powerpc/sysdev/fsl_pci.h b/arch/powerpc/sysdev/fsl_pci.h
index c495c00..c81bf44 100644
--- a/arch/powerpc/sysdev/fsl_pci.h
+++ b/arch/powerpc/sysdev/fsl_pci.h
@@ -17,6 +17,7 @@
#define PCIE_LTSSM 0x0404 /* PCIE Link Training and Status */
#define PCIE_LTSSM_L0 0x16/* L0 state */
#define PCIE_IP_REV_2_20x02080202 /* PCIE IP block version
Rev2.2 */
+#define PCIE_IP_REV_3_00x02080300 /* PCIE IP block version
Rev3.0 */
#define PIWAR_EN 0x8000 /* Enable */
#define PIWAR_PF 0x2000 /* prefetch */
#define PIWAR_TGI_LOCAL0x00f0 /* target - local
memory */
@@ -89,6 +90,16 @@ struct ccsr_pci {
__be32 pex_err_cap_r1; /* 0x.e2c - PCIE error capture register
0 */
__be32 pex_err_cap_r2; /* 0x.e30 - PCIE error capture register
0 */
__be32 pex_err_cap_r3; /* 0x.e34 - PCIE error capture register
0 */
+ u8 res_e38[200];
+ __be32 pdb_stat; /* 0x.f00 - PCIE Debug Status */
+ u8 res_f04[16];
+ __be32 pex_csr0; /* 0x.f14 - PEX Control/Status register
0*/
+#define PEX_CSR0_LTSSM_MASK0xFC
+#define PEX_CSR0_LTSSM_SHIFT 2
+#define PEX_CSR0_LTSSM_L0 0x11
+ __be32 pex_csr1; /* 0x.f18 - PEX Control/Status reg
[PATCH 4/8] powerpc/85xx: Add AltiVec support for e6500
The e6500 core adds support for AltiVec on a Book-E class processor.
Connect up all the various exception handling code and build config
mechanisms to allow user spaces apps to utilize AltiVec.
Signed-off-by: Kumar Gala
---
arch/powerpc/include/asm/cputable.h |2 +-
arch/powerpc/include/asm/kvm_asm.h|4 +++
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 14 +
arch/powerpc/kernel/cputable.c|9 --
arch/powerpc/kernel/exceptions-64e.S | 47 +
arch/powerpc/platforms/Kconfig.cputype|2 +-
6 files changed, 73 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index fb3245e..f326444 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -374,7 +374,7 @@ extern const char *powerpc_base_platform;
#define CPU_FTRS_E6500 (CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN | \
CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
CPU_FTR_DBELL | CPU_FTR_POPCNTB | CPU_FTR_POPCNTD | \
- CPU_FTR_DEBUG_LVL_EXC | CPU_FTR_EMB_HV)
+ CPU_FTR_DEBUG_LVL_EXC | CPU_FTR_EMB_HV | CPU_FTR_ALTIVEC_COMP)
#define CPU_FTRS_GENERIC_32(CPU_FTR_COMMON | CPU_FTR_NODSISRALIGN)
/* 64-bit CPUs */
diff --git a/arch/powerpc/include/asm/kvm_asm.h
b/arch/powerpc/include/asm/kvm_asm.h
index aabcdba..b9dd382 100644
--- a/arch/powerpc/include/asm/kvm_asm.h
+++ b/arch/powerpc/include/asm/kvm_asm.h
@@ -67,6 +67,10 @@
#define BOOKE_INTERRUPT_HV_SYSCALL 40
#define BOOKE_INTERRUPT_HV_PRIV 41
+/* altivec */
+#define BOOKE_INTERRUPT_ALTIVEC_UNAVAIL 42
+#define BOOKE_INTERRUPT_ALTIVEC_ASSIST 43
+
/* book3s */
#define BOOK3S_INTERRUPT_SYSTEM_RESET 0x100
diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index dcd8819..c16729b 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -53,6 +53,13 @@ _GLOBAL(__e500_dcache_setup)
isync
blr
+_GLOBAL(__setup_cpu_e6500)
+ mflrr6
+ bl .setup_altivec_ivors
+ bl __setup_cpu_e5500
+ mtlrr6
+ blr
+
#ifdef CONFIG_PPC32
_GLOBAL(__setup_cpu_e200)
/* enable dedicated debug exception handling resources (Debug APU) */
@@ -107,6 +114,13 @@ _GLOBAL(__setup_cpu_e5500)
#endif
#ifdef CONFIG_PPC_BOOK3E_64
+_GLOBAL(__restore_cpu_e6500)
+ mflrr5
+ bl .setup_altivec_ivors
+ bl __restore_cpu_e5500
+ mtlrr5
+ blr
+
_GLOBAL(__restore_cpu_e5500)
mflrr4
bl __e500_icache_setup
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 75a3d71..cc39139 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -74,7 +74,9 @@ extern void __restore_cpu_a2(void);
#endif /* CONFIG_PPC64 */
#if defined(CONFIG_E500)
extern void __setup_cpu_e5500(unsigned long offset, struct cpu_spec* spec);
+extern void __setup_cpu_e6500(unsigned long offset, struct cpu_spec* spec);
extern void __restore_cpu_e5500(void);
+extern void __restore_cpu_e6500(void);
#endif /* CONFIG_E500 */
/* This table only contains "desktop" CPUs, it need to be filled with embedded
@@ -2065,7 +2067,8 @@ static struct cpu_spec __initdata cpu_specs[] = {
.pvr_value = 0x8040,
.cpu_name = "e6500",
.cpu_features = CPU_FTRS_E6500,
- .cpu_user_features = COMMON_USER_BOOKE |
PPC_FEATURE_HAS_FPU,
+ .cpu_user_features = COMMON_USER_BOOKE |
PPC_FEATURE_HAS_FPU |
+ PPC_FEATURE_HAS_ALTIVEC_COMP,
.mmu_features = MMU_FTR_TYPE_FSL_E | MMU_FTR_BIG_PHYS
|
MMU_FTR_USE_TLBILX,
.icache_bsize = 64,
@@ -2073,9 +2076,9 @@ static struct cpu_spec __initdata cpu_specs[] = {
.num_pmcs = 4,
.oprofile_cpu_type = "ppc/e6500",
.oprofile_type = PPC_OPROFILE_FSL_EMB,
- .cpu_setup = __setup_cpu_e5500,
+ .cpu_setup = __setup_cpu_e6500,
#ifndef CONFIG_PPC32
- .cpu_restore= __restore_cpu_e5500,
+ .cpu_restore= __restore_cpu_e6500,
#endif
.machine_check = machine_check_e500mc,
.platform = "ppce6500",
diff --git a/arch/powerpc/kernel/exceptions-64e.S
b/arch/powerpc/kernel/exceptions-64e.S
index ae54553..42a756e 100644
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S
@@ -299,6 +299,8 @@ interrupt_base_book3e:
/* fake trap */
EXCEPTION_STUB(0x1a0, watchdog) /* 0x09f0 */
[PATCH 1/8] powerpc/85xx: Added SEC-5.0 device tree.
From: Vakul Garg
Add device tree for SEC (crypto engine) version 5.0 used on T4240.
Signed-off-by: Vakul Garg
Signed-off-by: Andy Fleming
Signed-off-by: Kumar Gala
---
arch/powerpc/boot/dts/fsl/qoriq-sec5.0-0.dtsi | 109 +
1 file changed, 109 insertions(+)
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-sec5.0-0.dtsi
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-sec5.0-0.dtsi
b/arch/powerpc/boot/dts/fsl/qoriq-sec5.0-0.dtsi
new file mode 100644
index 000..ffd458f
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/qoriq-sec5.0-0.dtsi
@@ -0,0 +1,109 @@
+/*
+ * QorIQ Sec/Crypto 5.0 device tree stub [ controller @ offset 0x30 ]
+ *
+ * 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.
+ */
+
+crypto: crypto@30 {
+ compatible = "fsl,sec-v5.0", "fsl,sec-v4.0";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x30 0x1>;
+ ranges = <0 0x30 0x1>;
+ interrupts = <92 2 0 0>;
+
+ sec_jr0: jr@1000 {
+ compatible = "fsl,sec-v5.0-job-ring",
+"fsl,sec-v4.0-job-ring";
+ reg = <0x1000 0x1000>;
+ interrupts = <88 2 0 0>;
+ };
+
+ sec_jr1: jr@2000 {
+ compatible = "fsl,sec-v5.0-job-ring",
+"fsl,sec-v4.0-job-ring";
+ reg = <0x2000 0x1000>;
+ interrupts = <89 2 0 0>;
+ };
+
+ sec_jr2: jr@3000 {
+ compatible = "fsl,sec-v5.0-job-ring",
+"fsl,sec-v4.0-job-ring";
+ reg = <0x3000 0x1000>;
+ interrupts = <90 2 0 0>;
+ };
+
+ sec_jr3: jr@4000 {
+ compatible = "fsl,sec-v5.0-job-ring",
+"fsl,sec-v4.0-job-ring";
+ reg = <0x4000 0x1000>;
+ interrupts = <91 2 0 0>;
+ };
+
+ rtic@6000 {
+ compatible = "fsl,sec-v5.0-rtic",
+"fsl,sec-v4.0-rtic";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x6000 0x100>;
+ ranges = <0x0 0x6100 0xe00>;
+
+ rtic_a: rtic-a@0 {
+ compatible = "fsl,sec-v5.0-rtic-memory",
+"fsl,sec-v4.0-rtic-memory";
+ reg = <0x00 0x20 0x100 0x80>;
+ };
+
+ rtic_b: rtic-b@20 {
+ compatible = "fsl,sec-v5.0-rtic-memory",
+"fsl,sec-v4.0-rtic-memory";
+ reg = <0x20 0x20 0x200 0x80>;
+ };
+
+ rtic_c: rtic-c@40 {
+ compatible = "fsl,sec-v5.0-rtic-memory",
+"fsl,sec-v4.0-rtic-memory";
+ reg = <0x40 0x20 0x300 0x80>;
+
[PATCH 5/8] powerpc/fsl-booke: Add initial silicon device tree for
Enable a baseline T4240 SoC to boot. There are several things missing
from the device trees for T4240:
* Thread support on e6500
* Proper PAMU topology information
* DPAA related nodes (Qman, Bman, Fman, Rman, DCE)
* Prefetch Manager
* Thermal monitor unit
* Interlaken
Signed-off-by: Roy Zang
Signed-off-by: Minghuan Lian
Signed-off-by: Haiying Wang
Signed-off-by: Andy Fleming
Signed-off-by: Prabhakar Kushwaha
Signed-off-by: York Sun
Signed-off-by: Vakul Garg
Signed-off-by: Tang Yuantian
Signed-off-by: Zhao Chenhui
Signed-off-by: Li Yang
Signed-off-by: Ramneek Mehresh
Signed-off-by: Haiying Wang
Signed-off-by: Laurentiu Tudor
Signed-off-by: Kumar Gala
---
arch/powerpc/boot/dts/fsl/qoriq-gpio-1.dtsi | 41
arch/powerpc/boot/dts/fsl/qoriq-gpio-2.dtsi | 41
arch/powerpc/boot/dts/fsl/qoriq-gpio-3.dtsi | 41
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 311 +++
arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi | 129 +++
5 files changed, 563 insertions(+)
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-gpio-1.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-gpio-2.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/qoriq-gpio-3.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-gpio-1.dtsi
b/arch/powerpc/boot/dts/fsl/qoriq-gpio-1.dtsi
new file mode 100644
index 000..c2f9cda
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/qoriq-gpio-1.dtsi
@@ -0,0 +1,41 @@
+/*
+ * QorIQ GPIO device tree stub [ controller @ offset 0x131000 ]
+ *
+ * Copyright 2013 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.
+ */
+
+gpio1: gpio@131000 {
+ compatible = "fsl,qoriq-gpio";
+ reg = <0x131000 0x1000>;
+ interrupts = <54 2 0 0>;
+ #gpio-cells = <2>;
+ gpio-controller;
+};
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-gpio-2.dtsi
b/arch/powerpc/boot/dts/fsl/qoriq-gpio-2.dtsi
new file mode 100644
index 000..33f3ccb
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/qoriq-gpio-2.dtsi
@@ -0,0 +1,41 @@
+/*
+ * QorIQ GPIO device tree stub [ controller @ offset 0x132000 ]
+ *
+ * Copyright 2013 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
+ * Found
[PATCH 6/8] powerpc/fsl-booke: Add initial T4240QDS board device
Signed-off-by: Minghuan Lian
Signed-off-by: Roy Zang
Signed-off-by: Prabhakar Kushwaha
Signed-off-by: Andy Fleming
Signed-off-by: Shaohui Xie
Signed-off-by: Prabhakar Kushwaha
Signed-off-by: Scott Wood
Signed-off-by: Kumar Gala
---
arch/powerpc/boot/dts/t4240qds.dts | 220
1 file changed, 220 insertions(+)
create mode 100644 arch/powerpc/boot/dts/t4240qds.dts
diff --git a/arch/powerpc/boot/dts/t4240qds.dts
b/arch/powerpc/boot/dts/t4240qds.dts
new file mode 100644
index 000..83b479f
--- /dev/null
+++ b/arch/powerpc/boot/dts/t4240qds.dts
@@ -0,0 +1,220 @@
+/*
+ * T4240QDS Device Tree Source
+ *
+ * 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/t4240si-pre.dtsi"
+
+/ {
+ model = "fsl,T4240QDS";
+ compatible = "fsl,T4240QDS";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&mpic>;
+
+ ifc: localbus@ffe124000 {
+ reg = <0xf 0xfe124000 0 0x2000>;
+ ranges = <0 0 0xf 0xe800 0x0800
+ 2 0 0xf 0xff80 0x0001
+ 3 0 0xf 0xffdf 0x8000>;
+
+ nor@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x800>;
+
+ bank-width = <2>;
+ device-width = <1>;
+ };
+
+ nand@2,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,ifc-nand";
+ reg = <0x2 0x0 0x1>;
+
+ partition@0 {
+ /* This location must not be altered */
+ /* 1MB for u-boot Bootloader Image */
+ reg = <0x0 0x0010>;
+ label = "NAND U-Boot Image";
+ read-only;
+ };
+
+ partition@10 {
+ /* 1MB for DTB Image */
+ reg = <0x0010 0x0010>;
+ label = "NAND DTB Image";
+ };
+
+ partition@20 {
+ /* 10MB for Linux Kernel Image */
+ reg = <0x0020 0x00A0>;
+ label = "NAND Linux Kernel Image";
+ };
+
+ partition@C0 {
+ /* 500MB for Root file System Image */
+ reg = <0x00c0 0x1F40>;
+ label = "NAND RFS Image";
+ };
+ };
+
+ board-control@3,0 {
+ compatible = "fsl,t4240qds-fpga", "fsl,fpga-qi
[PATCH 7/8] powerpc/fsl-booke: Add initial T4240QDS board support
Some minor changes to the common corenet_ds.c code are needed to support
the T4240QDS:
* Add support for "fsl,qoriq-pcie-v3.0" controller
* Bump max # of IRQs to 512 (T4240 supports more interrupts than
previous SoCs).
Signed-off-by: Kumar Gala
---
arch/powerpc/platforms/85xx/Kconfig | 17 ++
arch/powerpc/platforms/85xx/Makefile |1 +
arch/powerpc/platforms/85xx/corenet_ds.c |5 +-
arch/powerpc/platforms/85xx/t4240_qds.c | 98 ++
4 files changed, 120 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/platforms/85xx/t4240_qds.c
diff --git a/arch/powerpc/platforms/85xx/Kconfig
b/arch/powerpc/platforms/85xx/Kconfig
index a0dcd57..31dc066 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -305,6 +305,23 @@ config PPC_QEMU_E500
unset based on the emulated CPU (or actual host CPU in the case
of KVM).
+if PPC64
+
+config T4240_QDS
+ bool "Freescale T4240 QDS"
+ select DEFAULT_UIMAGE
+ select E500
+ select PPC_E500MC
+ select PHYS_64BIT
+ select SWIOTLB
+ select ARCH_REQUIRE_GPIOLIB
+ select GPIO_MPC8XXX
+ select HAS_RAPIDIO
+ select PPC_EPAPR_HV_PIC
+ help
+ This option enables support for the T4240 QDS board
+
+endif
endif # FSL_SOC_BOOKE
config TQM85xx
diff --git a/arch/powerpc/platforms/85xx/Makefile
b/arch/powerpc/platforms/85xx/Makefile
index 07d0dbb..712e233 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_P3041_DS)+= p3041_ds.o corenet_ds.o
obj-$(CONFIG_P4080_DS)+= p4080_ds.o corenet_ds.o
obj-$(CONFIG_P5020_DS)+= p5020_ds.o corenet_ds.o
obj-$(CONFIG_P5040_DS)+= p5040_ds.o corenet_ds.o
+obj-$(CONFIG_T4240_QDS) += t4240_qds.o corenet_ds.o
obj-$(CONFIG_STX_GP3)+= stx_gp3.o
obj-$(CONFIG_TQM85xx)+= tqm85xx.o
obj-$(CONFIG_SBC8548) += sbc8548.o
diff --git a/arch/powerpc/platforms/85xx/corenet_ds.c
b/arch/powerpc/platforms/85xx/corenet_ds.c
index 6f355d8..c59c617 100644
--- a/arch/powerpc/platforms/85xx/corenet_ds.c
+++ b/arch/powerpc/platforms/85xx/corenet_ds.c
@@ -40,7 +40,7 @@ void __init corenet_ds_pic_init(void)
if (ppc_md.get_irq == mpic_get_coreint_irq)
flags |= MPIC_ENABLE_COREINT;
- mpic = mpic_alloc(NULL, 0, flags, 0, 256, " OpenPIC ");
+ mpic = mpic_alloc(NULL, 0, flags, 0, 512, " OpenPIC ");
BUG_ON(mpic == NULL);
mpic_init(mpic);
@@ -83,6 +83,9 @@ static const struct of_device_id of_device_ids[] = {
{
.compatible = "fsl,qoriq-pcie-v2.4",
},
+ {
+ .compatible = "fsl,qoriq-pcie-v3.0",
+ },
/* The following two are for the Freescale hypervisor */
{
.name = "hypervisor",
diff --git a/arch/powerpc/platforms/85xx/t4240_qds.c
b/arch/powerpc/platforms/85xx/t4240_qds.c
new file mode 100644
index 000..5998e9f
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/t4240_qds.c
@@ -0,0 +1,98 @@
+/*
+ * T4240 QDS Setup
+ *
+ * Maintained by Kumar Gala (see MAINTAINERS for contact information)
+ *
+ * Copyright 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
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include "corenet_ds.h"
+
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+static int __init t4240_qds_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+#ifdef CONFIG_SMP
+ extern struct smp_ops_t smp_85xx_ops;
+#endif
+
+ if (of_flat_dt_is_compatible(root, "fsl,T4240QDS"))
+ return 1;
+
+ /* Check if we're running under the Freescale hypervisor */
+ if (of_flat_dt_is_compatible(root, "fsl,T4240QDS-hv")) {
+ ppc_md.init_IRQ = ehv_pic_init;
+ ppc_md.get_irq = ehv_pic_get_irq;
+ ppc_md.restart = fsl_hv_restart;
+ ppc_md.power_off = fsl_hv_halt;
+ ppc_md.halt = fsl_hv_halt;
+#ifdef CONFIG_SMP
+ /*
+* Disable the timebase sync operations because we can't write
+* to the timebase registers under the hypervisor.
+ */
+ smp_85xx_ops.give_timebase = NULL;
+ smp_85xx_ops.take_timebase = NULL;
+#endif
+ return 1;
+ }
+
+ return 0;
+}
+
+define_machine(t4240_qds) {
+
[PATCH 8/8] powerpc/85xx: Update corenet64_smp_defconfig for T4240
* Add support for up to 24 cores on T4240 (includes threads) * Enable AltiVec support (on T4240) * Add T4240QDS board into build * Other changes are due to general kernel update of defconfig Signed-off-by: Kumar Gala --- arch/powerpc/configs/corenet64_smp_defconfig |9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig index 3d139fa..c3da860 100644 --- a/arch/powerpc/configs/corenet64_smp_defconfig +++ b/arch/powerpc/configs/corenet64_smp_defconfig @@ -1,14 +1,13 @@ CONFIG_PPC64=y CONFIG_PPC_BOOK3E_64=y -# CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is not set +CONFIG_ALTIVEC=y CONFIG_SMP=y -CONFIG_NR_CPUS=2 -CONFIG_EXPERIMENTAL=y +CONFIG_NR_CPUS=24 CONFIG_SYSVIPC=y -CONFIG_BSD_PROCESS_ACCT=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y +CONFIG_BSD_PROCESS_ACCT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=14 @@ -24,6 +23,7 @@ CONFIG_PARTITION_ADVANCED=y CONFIG_MAC_PARTITION=y CONFIG_P5020_DS=y CONFIG_P5040_DS=y +CONFIG_T4240_QDS=y # CONFIG_PPC_OF_BOOT_TRAMPOLINE is not set CONFIG_BINFMT_MISC=m CONFIG_PCIEPORTBUS=y @@ -140,6 +140,5 @@ CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_MD4=y CONFIG_CRYPTO_SHA256=y CONFIG_CRYPTO_SHA512=y -CONFIG_CRYPTO_AES=y # CONFIG_CRYPTO_ANSI_CPRNG is not set CONFIG_CRYPTO_DEV_FSL_CAAM=y -- 1.7.9.7 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][V2] powerpc: remove the PPC_CLOCK dependency
On Mar 6, 2013, at 3:16 AM, wrote: > From: Tang Yuantian > > config FSL_SOC and CPM do not really depend on PPC_CLOCK. So remove it. > PPC_CLOCK also keeps powerpc archtecture from supporting COMMON_CLK. > > Signed-off-by: Tang Yuantian > --- > v2: correct the title > > arch/powerpc/Kconfig |1 - > arch/powerpc/platforms/Kconfig |1 - > 2 files changed, 0 insertions(+), 2 deletions(-) Does the Flexcan driver use this? - k > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index 352f416..383485b 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -655,7 +655,6 @@ config SBUS > config FSL_SOC > bool > select HAVE_CAN_FLEXCAN if NET && CAN > - select PPC_CLOCK > > config FSL_PCI > bool > diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig > index e7a896a..aba81cd 100644 > --- a/arch/powerpc/platforms/Kconfig > +++ b/arch/powerpc/platforms/Kconfig > @@ -343,7 +343,6 @@ config FSL_ULI1575 > > config CPM > bool > - select PPC_CLOCK > > config OF_RTC > bool > -- > 1.7.0.4 > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/8] powerpc/fsl-booke: Add initial silicon device tree for
On Mar 5, 2013, at 6:15 PM, Scott Wood wrote:
> On 03/05/2013 05:15:57 PM, Kumar Gala wrote:
>> Enable a baseline T4240 SoC to boot. There are several things missing
>> from the device trees for T4240:
>> * Thread support on e6500
>
> Why did threads get removed from the device tree? It's supposed to describe
> hardware, not what Linux currently supports.
will fix, was concerned if we'd be able to boot if they exited
>
>> * Proper PAMU topology information
>> * DPAA related nodes (Qman, Bman, Fman, Rman, DCE)
>> * Prefetch Manager
>> * Thermal monitor unit
>> * Interlaken
>
> The dts should be marked preliminary somehow -- we really should get out of
> the habit of letting device nodes trickle in as drivers get added.
agreed but forward progress always gets in the way
>
>> +/* controller at 0x24 */
>> +&pci0 {
>> +compatible = "fsl,t4240-pcie", "fsl,qoriq-pcie-v3.0";
>
> We have a version register -- do we really need to keep sticking the version
> number in the compatible? Note that we've had device trees that specified
> the version incorrectly in the past.
>
>> +device_type = "pci";
>> +#size-cells = <2>;
>> +#address-cells = <3>;
>> +bus-range = <0x0 0xff>;
>> +clock-frequency = <>;
>
> This clock-frequency is not correct (I doubt it's needed at all).
I can zero the field, but its spec'd by pci binding
>
>> +PowerPC,e6500@1 {
>> +device_type = "cpu";
>> +reg = <2>;
>> +next-level-cache = <&L2_1>;
>> +};
>> +PowerPC,e6500@2 {
>> +device_type = "cpu";
>> +reg = <4>;
>> +next-level-cache = <&L2_1>;
>> +};
>> +PowerPC,e6500@3 {
>> +device_type = "cpu";
>> +reg = <6>;
>> +next-level-cache = <&L2_1>;
>> +};
>> +
>> +PowerPC,e6500@4 {
>> +device_type = "cpu";
>> +reg = <8>;
>> +next-level-cache = <&L2_2>;
>> +};
>
> Inconsistent whitespace.
will kill the whitespace.
> As usual, the pre/post split is unnecessary. Everything in it can go in post.
>
> -Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/8] powerpc/fsl-booke: Add initial silicon device tree for
On Mar 7, 2013, at 11:47 AM, Scott Wood wrote: > On 03/07/2013 11:09:50 AM, Kumar Gala wrote: >> On Mar 5, 2013, at 6:15 PM, Scott Wood wrote: >> > On 03/05/2013 05:15:57 PM, Kumar Gala wrote: >> >> Enable a baseline T4240 SoC to boot. There are several things missing >> >> from the device trees for T4240: >> >> * Thread support on e6500 >> > >> > Why did threads get removed from the device tree? It's supposed to >> > describe hardware, not what Linux currently supports. >> will fix, was concerned if we'd be able to boot if they exited > > I don't think it'd be a problem (and if it is, then fix Linux). looks fine, so I'll add them in v2 patch. > >> >> + device_type = "pci"; >> >> + #size-cells = <2>; >> >> + #address-cells = <3>; >> >> + bus-range = <0x0 0xff>; >> >> + clock-frequency = <>; >> > >> > This clock-frequency is not correct (I doubt it's needed at all). >> I can zero the field, but its spec'd by pci binding > > If we aren't going to put a correct value in, is zero better than omitting it > entirely? > > There are other properties in the PCI binding that we don't have, such as > slot-names. I don't see any language in the PCI binding that says one is > required but the other isn't. > > And shouldn't we be using the PCI express binding (device_type = "pciex", or > just get rid of it since this isn't real OF)? I'll drop clock-frequency since we dont use it. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
