Re: [PATCH v3] powerpc: Use PFN_PHYS() to avoid truncating the physical address
Why no commit message with what issue this change was trying to fix? - k On Mar 25, 2015, at 8:49 AM, Emil Medve emilian.me...@freescale.com wrote: Signed-off-by: Emil Medve emilian.me...@freescale.com --- v3: Rebased and updated due to upstream changes since v2 v2: Rebased and updated due to upstream changes since v1 arch/powerpc/include/asm/io.h | 2 +- arch/powerpc/include/asm/page.h| 2 +- arch/powerpc/include/asm/pgalloc-32.h | 2 +- arch/powerpc/include/asm/rtas.h| 3 ++- arch/powerpc/kernel/crash_dump.c | 2 +- arch/powerpc/kernel/eeh.c | 4 +--- arch/powerpc/kernel/io-workarounds.c | 2 +- arch/powerpc/kernel/pci-common.c | 2 +- arch/powerpc/kernel/vdso.c | 6 +++--- arch/powerpc/kvm/book3s_64_mmu_host.c | 2 +- arch/powerpc/kvm/book3s_64_mmu_hv.c| 2 +- arch/powerpc/kvm/book3s_hv_rm_mmu.c| 4 ++-- arch/powerpc/kvm/e500_mmu_host.c | 5 ++--- arch/powerpc/mm/hugepage-hash64.c | 2 +- arch/powerpc/mm/hugetlbpage-book3e.c | 2 +- arch/powerpc/mm/hugetlbpage-hash64.c | 2 +- arch/powerpc/mm/mem.c | 9 - arch/powerpc/mm/numa.c | 5 ++--- arch/powerpc/platforms/powernv/opal.c | 2 +- arch/powerpc/platforms/pseries/iommu.c | 8 20 files changed, 32 insertions(+), 36 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC 02/11] dpaa_eth: add support for DPAA Ethernet
On Mar 17, 2015, at 1:58 PM, Madalin Bucur madalin.bu...@freescale.com wrote: This introduces the Freescale Data Path Acceleration Architecture (DPAA) Ethernet driver (dpaa_eth) that builds upon the DPAA QMan, BMan, PAMU and FMan drivers to deliver Ethernet connectivity on the Freescale DPAA QorIQ platforms. Signed-off-by: Madalin Bucur madalin.bu...@freescale.com --- drivers/net/ethernet/freescale/Kconfig |2 + drivers/net/ethernet/freescale/Makefile|1 + drivers/net/ethernet/freescale/dpaa/Kconfig| 49 + drivers/net/ethernet/freescale/dpaa/Makefile | 14 + drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 837 + drivers/net/ethernet/freescale/dpaa/dpaa_eth.h | 446 +++ .../net/ethernet/freescale/dpaa/dpaa_eth_common.c | 1288 .../net/ethernet/freescale/dpaa/dpaa_eth_common.h | 119 ++ drivers/net/ethernet/freescale/dpaa/dpaa_eth_sg.c | 428 +++ 9 files changed, 3184 insertions(+) create mode 100644 drivers/net/ethernet/freescale/dpaa/Kconfig create mode 100644 drivers/net/ethernet/freescale/dpaa/Makefile create mode 100644 drivers/net/ethernet/freescale/dpaa/dpaa_eth.c create mode 100644 drivers/net/ethernet/freescale/dpaa/dpaa_eth.h create mode 100644 drivers/net/ethernet/freescale/dpaa/dpaa_eth_common.c create mode 100644 drivers/net/ethernet/freescale/dpaa/dpaa_eth_common.h create mode 100644 drivers/net/ethernet/freescale/dpaa/dpaa_eth_sg.c diff --git a/drivers/net/ethernet/freescale/Kconfig b/drivers/net/ethernet/freescale/Kconfig index ba84c4a..dd485f1 100644 --- a/drivers/net/ethernet/freescale/Kconfig +++ b/drivers/net/ethernet/freescale/Kconfig @@ -95,4 +95,6 @@ config GIANFAR This driver supports the Gigabit TSEC on the MPC83xx, MPC85xx, and MPC86xx family of chips, and the FEC on the 8540. +source drivers/net/ethernet/freescale/dpaa/Kconfig + endif # NET_VENDOR_FREESCALE diff --git a/drivers/net/ethernet/freescale/Makefile b/drivers/net/ethernet/freescale/Makefile index 71debd1..b6c10ab 100644 --- a/drivers/net/ethernet/freescale/Makefile +++ b/drivers/net/ethernet/freescale/Makefile @@ -12,6 +12,7 @@ obj-$(CONFIG_FS_ENET) += fs_enet/ obj-$(CONFIG_FSL_PQ_MDIO) += fsl_pq_mdio.o obj-$(CONFIG_FSL_XGMAC_MDIO) += xgmac_mdio.o obj-$(CONFIG_GIANFAR) += gianfar_driver.o +obj-$(if $(CONFIG_FSL_DPAA_ETH),y) += dpaa/ Why isn’t obj-$(CONFIG_FSL_DPAA_ETH) += dpaa/ enough? obj-$(CONFIG_PTP_1588_CLOCK_GIANFAR) += gianfar_ptp.o gianfar_driver-objs := gianfar.o \ gianfar_ethtool.o diff --git a/drivers/net/ethernet/freescale/dpaa/Kconfig b/drivers/net/ethernet/freescale/dpaa/Kconfig new file mode 100644 index 000..7ef703c --- /dev/null +++ b/drivers/net/ethernet/freescale/dpaa/Kconfig @@ -0,0 +1,49 @@ +menuconfig FSL_DPAA_ETH + tristate DPAA Ethernet + depends on FSL_SOC FSL_BMAN FSL_QMAN FSL_FMAN + select PHYLIB + select FSL_FMAN_MAC + ---help--- + Data Path Acceleration Architecture Ethernet driver, + supporting the Freescale QorIQ chips. + Depends on Freescale Buffer Manager and Queue Manager + driver and Frame Manager Driver. + +if FSL_DPAA_ETH + +config FSL_DPAA_CS_THRESHOLD_1G + hex Egress congestion threshold on 1G ports + depends on FSL_DPAA_ETH + range 0x1000 0x1000 + default 0x0600 + ---help--- + The size in bytes of the egress Congestion State notification threshold on 1G ports. + The 1G dTSECs can quite easily be flooded by cores doing Tx in a tight loop + (e.g. by sending UDP datagrams at while(1) speed), + and the larger the frame size, the more acute the problem. + So we have to find a balance between these factors: +- avoiding the device staying congested for a prolonged time (risking + the netdev watchdog to fire - see also the tx_timeout module param); + - affecting performance of protocols such as TCP, which otherwise + behave well under the congestion notification mechanism; +- preventing the Tx cores from tightly-looping (as if the congestion + threshold was too low to be effective); +- running out of memory if the CS threshold is set too high. + +config FSL_DPAA_CS_THRESHOLD_10G + hex Egress congestion threshold on 10G ports + depends on FSL_DPAA_ETH + range 0x1000 0x2000 + default 0x1000 + ---help --- + The size in bytes of the egress Congestion State notification threshold on 10G ports. + +config FSL_DPAA_INGRESS_CS_THRESHOLD + hex Ingress congestion threshold on FMan ports + depends on FSL_DPAA_ETH + default 0x1000 + ---help--- + The size in bytes of the ingress tail-drop threshold on FMan ports. + Traffic piling up above this value will be rejected by QMan and
Re: [v2,00/11] Freescale DPAA FMan FLIB(s)
On Mar 11, 2015, at 12:03 AM, Igal.Liberman igal.liber...@freescale.com wrote: From: Igal Liberman igal.liber...@freescale.com The Freescale Data Path Acceleration Architecture (DPAA) is a set of hardware components on specific QorIQ multicore processors. This architecture provides the infrastructure to support simplified sharing of networking interfaces and accelerators by multiple CPU cores and the accelerators. One of the DPAA accelerators is the Frame Manager (FMan) which enables the Ethernet network interfaces. This patch presents the FMan Foundation Libraries (FLIB) headers. The FMan FLIB adds basic support for the DPAA FMan hardware register access. Igal Liberman (7): soc/fman: Add the FMan FLIB headers soc/fman: Add the FMan FLIB soc/fman: Add the FMan port FLIB soc/fman: Add the FMan MAC FLIB soc/fman: Add the FMan parser and KeyGen FLIB(s) soc/fman: Add the FMan RTC FLIB soc/fman: Add the FMan SP FLIB Madalin Bucur (4): soc/fman: Add the FMan port FLIB headers soc/fman: Add the FMan MAC FLIB headers soc/fman: Add the FMan parser and KeyGen FLIB headers soc/fman: Add the FMan RTC FLIB header drivers/soc/Kconfig|1 + drivers/soc/Makefile |1 + drivers/soc/fsl/Kconfig|1 + drivers/soc/fsl/Makefile |1 + drivers/soc/fsl/fman/Kconfig | 35 + drivers/soc/fsl/fman/Makefile | 11 + drivers/soc/fsl/fman/flib/common/general.h | 41 + drivers/soc/fsl/fman/flib/fman_common.h| 73 + drivers/soc/fsl/fman/flib/fsl_enet.h | 275 drivers/soc/fsl/fman/flib/fsl_fman.h | 802 ++ drivers/soc/fsl/fman/flib/fsl_fman_dtsec.h | 1016 + drivers/soc/fsl/fman/flib/fsl_fman_dtsec_mii_acc.h | 103 ++ drivers/soc/fsl/fman/flib/fsl_fman_kg.h| 505 +++ drivers/soc/fsl/fman/flib/fsl_fman_memac.h | 494 +++ drivers/soc/fsl/fman/flib/fsl_fman_memac_mii_acc.h | 76 + drivers/soc/fsl/fman/flib/fsl_fman_port.h | 601 drivers/soc/fsl/fman/flib/fsl_fman_prs.h | 106 ++ drivers/soc/fsl/fman/flib/fsl_fman_rtc.h | 414 ++ drivers/soc/fsl/fman/flib/fsl_fman_sp.h| 132 ++ drivers/soc/fsl/fman/flib/fsl_fman_tgec.h | 483 ++ drivers/soc/fsl/fman/fman.c| 1355 + drivers/soc/fsl/fman/mac/Makefile |5 + drivers/soc/fsl/fman/mac/fman_crc32.c | 116 ++ drivers/soc/fsl/fman/mac/fman_crc32.h | 39 + drivers/soc/fsl/fman/mac/fman_dtsec.c | 838 +++ drivers/soc/fsl/fman/mac/fman_dtsec_mii_acc.c | 168 +++ drivers/soc/fsl/fman/mac/fman_memac.c | 510 +++ drivers/soc/fsl/fman/mac/fman_memac_mii_acc.c | 217 +++ drivers/soc/fsl/fman/mac/fman_tgec.c | 371 + drivers/soc/fsl/fman/pcd/Makefile |3 + drivers/soc/fsl/fman/pcd/fman_kg.c | 849 +++ drivers/soc/fsl/fman/pcd/fman_prs.c| 126 ++ drivers/soc/fsl/fman/port/Makefile |3 + drivers/soc/fsl/fman/port/fman_port.c | 1535 drivers/soc/fsl/fman/rtc/Makefile |3 + drivers/soc/fsl/fman/rtc/fman_rtc.c| 353 + drivers/soc/fsl/fman/sp/Makefile |3 + drivers/soc/fsl/fman/sp/fman_sp.c | 203 +++ 38 files changed, 11868 insertions(+) create mode 100644 drivers/soc/fsl/Kconfig create mode 100644 drivers/soc/fsl/Makefile create mode 100644 drivers/soc/fsl/fman/Kconfig create mode 100644 drivers/soc/fsl/fman/Makefile create mode 100644 drivers/soc/fsl/fman/flib/common/general.h create mode 100644 drivers/soc/fsl/fman/flib/fman_common.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_enet.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_dtsec.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_dtsec_mii_acc.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_kg.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_memac.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_memac_mii_acc.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_port.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_prs.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_rtc.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_sp.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_tgec.h create mode 100644 drivers/soc/fsl/fman/fman.c create mode 100644 drivers/soc/fsl/fman/mac/Makefile create mode 100644 drivers/soc/fsl/fman/mac/fman_crc32.c create mode 100644 drivers/soc/fsl/fman/mac/fman_crc32.h create mode 100644 drivers/soc/fsl/fman/mac/fman_dtsec.c
Re: [v2,04/11] soc/fman: Add the FMan port FLIB
On Mar 11, 2015, at 12:04 AM, Igal.Liberman igal.liber...@freescale.com wrote:
From: Igal Liberman igal.liber...@freescale.com
commit message?
Signed-off-by: Igal Liberman igal.liber...@freescale.com
---
drivers/soc/fsl/fman/Kconfig | 10 +
drivers/soc/fsl/fman/Makefile |2 +
drivers/soc/fsl/fman/port/Makefile|3 +
drivers/soc/fsl/fman/port/fman_port.c | 1535 +
4 files changed, 1550 insertions(+)
create mode 100644 drivers/soc/fsl/fman/port/Makefile
create mode 100644 drivers/soc/fsl/fman/port/fman_port.c
Should merge this with the header patch 3/11.
Docs for the “public” functions would be good.
- k
diff --git a/drivers/soc/fsl/fman/Kconfig b/drivers/soc/fsl/fman/Kconfig
index 6e8b0a6..b4c98ef 100644
--- a/drivers/soc/fsl/fman/Kconfig
+++ b/drivers/soc/fsl/fman/Kconfig
@@ -5,3 +5,13 @@ menuconfig FSL_FMAN
help
Freescale Data-Path Acceleration Architecture Frame Manager
(FMan) support
+
+if FSL_FMAN
+
+config FSL_FMAN_PORT
+ bool FMan port
+ default n
+ help
+ Freescale DPAA FMan port support
+
+endif# FSL_FMAN
diff --git a/drivers/soc/fsl/fman/Makefile b/drivers/soc/fsl/fman/Makefile
index e7a0575..437a325 100644
--- a/drivers/soc/fsl/fman/Makefile
+++ b/drivers/soc/fsl/fman/Makefile
@@ -3,3 +3,5 @@ subdir-ccflags-$(CONFIG_FSL_FMAN) +=
-I$(srctree)/drivers/soc/fsl/fman/flib
obj-$(CONFIG_FSL_FMAN)+= fsl_fman.o
fsl_fman-objs := fman.o
+
+obj-$(CONFIG_FSL_FMAN_PORT) += port/
diff --git a/drivers/soc/fsl/fman/port/Makefile
b/drivers/soc/fsl/fman/port/Makefile
new file mode 100644
index 000..0062fed
--- /dev/null
+++ b/drivers/soc/fsl/fman/port/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_FSL_FMAN_PORT) += fsl_fman_port.o
+
+fsl_fman_port-objs := fman_port.o
diff --git a/drivers/soc/fsl/fman/port/fman_port.c
b/drivers/soc/fsl/fman/port/fman_port.c
new file mode 100644
index 000..cc05dc0
--- /dev/null
+++ b/drivers/soc/fsl/fman/port/fman_port.c
@@ -0,0 +1,1535 @@
+/*
+ * Copyright 2008 - 2015 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 common/general.h
+
+#include fman_common.h
+#include fsl_fman_port.h
+
+/* problem Eyal: the following should not be here*/
??? Eyal ???
+#define NIA_FM_CTL_AC_NO_IPACC_PRE_BMI_ENQ_FRAME 0x0028
+
+static uint32_t get_no_pcd_nia_bmi_ac_enc_frame(struct fman_port_cfg *cfg)
+{
+ if (cfg-errata_A006675)
+ return NIA_ENG_FM_CTL |
+ NIA_FM_CTL_AC_NO_IPACC_PRE_BMI_ENQ_FRAME;
+ else
+ return NIA_ENG_BMI | NIA_BMI_AC_ENQ_FRAME;
+}
+
[snip]
+int fman_port_add_congestion_grps(struct fman_port *port,
+ uint32_t grps_map[FMAN_PORT_CG_MAP_NUM])
Passing an array this way is usually bad form.
+{
+ int i;
+ uint32_t __iomem *grp_map_reg;
+ uint32_t tmp;
+ uint8_t max_grp_map_num;
+
+ switch (port-type) {
+ case E_FMAN_PORT_TYPE_RX:
+ case E_FMAN_PORT_TYPE_RX_10G:
+ if (port-fm_rev_maj == 4)
+ max_grp_map_num = 1;
Re: [RFC,1/8] soc/fman: Add FMan MURAM support
On Mar 11, 2015, at 12:07 AM, Igal.Liberman igal.liber...@freescale.com wrote: From: Igal Liberman igal.liber...@freescale.com Add Frame Manager Multi-User RAM support. Signed-off-by: Igal Liberman igal.liber...@freescale.com --- drivers/soc/fsl/fman/Kconfig|1 + drivers/soc/fsl/fman/Makefile |5 +- drivers/soc/fsl/fman/fm_muram.c | 174 +++ drivers/soc/fsl/fman/inc/fm_muram_ext.h | 98 + 4 files changed, 276 insertions(+), 2 deletions(-) create mode 100644 drivers/soc/fsl/fman/fm_muram.c create mode 100644 drivers/soc/fsl/fman/inc/fm_muram_ext.h use lib/genalloc instead of rheap - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v2,02/11] soc/fman: Add the FMan FLIB
On Mar 11, 2015, at 12:04 AM, Igal.Liberman igal.liber...@freescale.com wrote: From: Igal Liberman igal.liber...@freescale.com Signed-off-by: Igal Liberman igal.liber...@freescale.com --- drivers/soc/Kconfig |1 + drivers/soc/Makefile |1 + drivers/soc/fsl/Kconfig |1 + drivers/soc/fsl/Makefile |1 + drivers/soc/fsl/fman/Kconfig |7 + drivers/soc/fsl/fman/Makefile |5 + drivers/soc/fsl/fman/fman.c | 1355 + 7 files changed, 1371 insertions(+) create mode 100644 drivers/soc/fsl/Kconfig create mode 100644 drivers/soc/fsl/Makefile create mode 100644 drivers/soc/fsl/fman/Kconfig create mode 100644 drivers/soc/fsl/fman/Makefile create mode 100644 drivers/soc/fsl/fman/fman.c diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig index 76d6bd4..674a6e6 100644 --- a/drivers/soc/Kconfig +++ b/drivers/soc/Kconfig @@ -1,5 +1,6 @@ menu SOC (System On Chip) specific Drivers +source drivers/soc/fsl/Kconfig source drivers/soc/qcom/Kconfig source drivers/soc/ti/Kconfig source drivers/soc/versatile/Kconfig diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile index 063113d..42836ee 100644 --- a/drivers/soc/Makefile +++ b/drivers/soc/Makefile @@ -2,6 +2,7 @@ # Makefile for the Linux Kernel SOC specific device drivers. # +obj-$(CONFIG_FSL_SOC)+= fsl/ obj-$(CONFIG_ARCH_QCOM) += qcom/ obj-$(CONFIG_ARCH_TEGRA) += tegra/ obj-$(CONFIG_SOC_TI) += ti/ diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig new file mode 100644 index 000..38c08ae --- /dev/null +++ b/drivers/soc/fsl/Kconfig @@ -0,0 +1 @@ Should probably just wrap this with an if FSL_SOC +source drivers/soc/fsl/fman/Kconfig” endif #FSL_SOC Than you can drop all downstream options always needing to depend on FSL_SOC diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile new file mode 100644 index 000..20ab5d0 --- /dev/null +++ b/drivers/soc/fsl/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_FSL_FMAN) += fman/ diff --git a/drivers/soc/fsl/fman/Kconfig b/drivers/soc/fsl/fman/Kconfig new file mode 100644 index 000..6e8b0a6 --- /dev/null +++ b/drivers/soc/fsl/fman/Kconfig @@ -0,0 +1,7 @@ +menuconfig FSL_FMAN + bool Freescale DPAA Frame Manager + depends on FSL_SOC || COMPILE_TEST + default n + help + Freescale Data-Path Acceleration Architecture Frame Manager + (FMan) support diff --git a/drivers/soc/fsl/fman/Makefile b/drivers/soc/fsl/fman/Makefile new file mode 100644 index 000..e7a0575 --- /dev/null +++ b/drivers/soc/fsl/fman/Makefile @@ -0,0 +1,5 @@ +subdir-ccflags-$(CONFIG_FSL_FMAN) += -I$(srctree)/drivers/soc/fsl/fman/flib + +obj-$(CONFIG_FSL_FMAN) += fsl_fman.o + +fsl_fman-objs:= fman.o diff --git a/drivers/soc/fsl/fman/fman.c b/drivers/soc/fsl/fman/fman.c new file mode 100644 index 000..138b2da --- /dev/null +++ b/drivers/soc/fsl/fman/fman.c @@ -0,0 +1,1355 @@ +/* + * Copyright 2008 - 2015 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_fman.h Any docs on all
Re: [PATCH 1/7] soc/fman: Add the FMan FLIB headers
On Mar 4, 2015, at 11:45 PM, Emil Medve emilian.me...@freescale.com wrote: From: Igal Liberman igal.liber...@freescale.com The Freescale Data Path Acceleration Architecture (DPAA) is a set of hardware components on specific QorIQ P and T series multicore processors. This architecture provides the infrastructure to support simplified sharing of networking interfaces and accelerators by multiple CPU cores, and the accelerators themselves. One of the DPAA accelerators is the Frame Manager (FMan), which combines the Ethernet network interfaces with packet distribution logic to provide intelligent distribution and queuing decisions for incoming traffic at line rate. This patch presents the FMan Foundation Libraries (FLIB) headers. The FMan FLIB suite adds basic support for the DPAA FMan hardware register access. The FMan FLIB suite is used in Freescale's SDK Releases. Signed-off-by: Igal Liberman igal.liber...@freescale.com --- drivers/soc/fsl/fman/flib/common/general.h | 45 + drivers/soc/fsl/fman/flib/fman_common.h| 74 ++ drivers/soc/fsl/fman/flib/fsl_enet.h | 276 ++ drivers/soc/fsl/fman/flib/fsl_fman.h | 801 +++ drivers/soc/fsl/fman/flib/fsl_fman_dtsec.h | 1017 drivers/soc/fsl/fman/flib/fsl_fman_dtsec_mii_acc.h | 104 ++ drivers/soc/fsl/fman/flib/fsl_fman_kg.h| 506 ++ drivers/soc/fsl/fman/flib/fsl_fman_memac.h | 492 ++ drivers/soc/fsl/fman/flib/fsl_fman_memac_mii_acc.h | 77 ++ drivers/soc/fsl/fman/flib/fsl_fman_port.h | 602 drivers/soc/fsl/fman/flib/fsl_fman_prs.h | 106 ++ drivers/soc/fsl/fman/flib/fsl_fman_rtc.h | 415 drivers/soc/fsl/fman/flib/fsl_fman_sp.h| 133 +++ drivers/soc/fsl/fman/flib/fsl_fman_tgec.h | 484 ++ 14 files changed, 5132 insertions(+) create mode 100644 drivers/soc/fsl/fman/flib/common/general.h create mode 100644 drivers/soc/fsl/fman/flib/fman_common.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_enet.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_dtsec.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_dtsec_mii_acc.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_kg.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_memac.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_memac_mii_acc.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_port.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_prs.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_rtc.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_sp.h create mode 100644 drivers/soc/fsl/fman/flib/fsl_fman_tgec.h 1. this is way to big of patch to reasonable review 2. can some of these headers be associated with the code patches that use them instead diff --git a/drivers/soc/fsl/fman/flib/common/general.h b/drivers/soc/fsl/fman/flib/common/general.h new file mode 100644 index 000..e5f56af --- /dev/null +++ b/drivers/soc/fsl/fman/flib/common/general.h @@ -0,0 +1,45 @@ +/* + * Copyright 2008-2015 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
Re: [PATCH] clk: ppc-corenet: Add support for the FMD clock
On Jan 20, 2015, at 6:03 AM, Igal.Liberman igal.liber...@freescale.com wrote:
From: Igal Liberman igal.liber...@freescale.com
Really should have some commit text
Signed-off-by: Igal Liberman igal.liber...@freescale.com
This patch is based on https://patchwork.ozlabs.org/patch/430966/
This belongs below the ---
---
drivers/clk/clk-ppc-corenet.c | 250 +
1 file changed, 250 insertions(+)
Any reason clk maintainers aren’t CC’d?
diff --git a/drivers/clk/clk-ppc-corenet.c b/drivers/clk/clk-ppc-corenet.c
index ff425e1..dcde0e6 100644
--- a/drivers/clk/clk-ppc-corenet.c
+++ b/drivers/clk/clk-ppc-corenet.c
@@ -18,6 +18,7 @@
#include linux/of_platform.h
#include linux/of.h
#include linux/slab.h
+#include asm/fsl_guts.h
struct cmux_clk {
struct clk_hw hw;
@@ -144,6 +145,254 @@ err_name:
kfree(parent_names);
}
+/* Table for matching compatible strings, for device tree
+ * guts node, for QorIQ SOCs.
+ * fsl,qoriq-device-config-2.0 corresponds to T4 B4
+ * SOCs. For the older SOCs fsl,qoriq-device-config-1.0
+ * string would be used.
+ */
+
+static const struct of_device_id guts_device_ids[] = {
+ { .compatible = fsl,qoriq-device-config-1.0, },
+ { .compatible = fsl,qoriq-device-config-2.0, },
+};
+
+/* P2, P3, P4, P5 */
+#define FM1_CLK_SEL_SHIFT30
+#define FM1_CLK_SEL BIT(FM1_CLK_SEL_SHIFT)
+#define FM2_CLK_SEL_SHIFT29
+#define FM2_CLK_SEL BIT(FM2_CLK_SEL_SHIFT)
+#define HWA_ASYNC_DIV_SHIFT 26
+#define HWA_ASYNC_DIVBIT(HWA_ASYNC_DIV_SHIFT)
+
+/* B4, T2 */
+#define HWA_CGA_M1_CLK_SEL_SHIFT 29
+#define HWA_CGA_M1_CLK_SEL (BIT(HWA_CGA_M1_CLK_SEL_SHIFT + 2) |\
+ BIT(HWA_CGA_M1_CLK_SEL_SHIFT + 1) |\
+ BIT(HWA_CGA_M1_CLK_SEL_SHIFT))
+
+/* T4240 */
+#define HWA_CGB_M1_CLK_SEL_SHIFT 26
+#define HWA_CGB_M1_CLK_SEL (BIT(HWA_CGB_M1_CLK_SEL_SHIFT + 2) |\
+ BIT(HWA_CGB_M1_CLK_SEL_SHIFT + 1) |\
+ BIT(HWA_CGB_M1_CLK_SEL_SHIFT))
+#define HWA_CGB_M2_CLK_SEL_SHIFT 3
+#define HWA_CGB_M2_CLK_SEL (BIT(HWA_CGB_M2_CLK_SEL_SHIFT + 2) |\
+ BIT(HWA_CGB_M2_CLK_SEL_SHIFT + 1) |\
+ BIT(HWA_CGB_M2_CLK_SEL_SHIFT))
+
+static u8 get_fm_clk_parent(struct clk_hw *hw)
+{
+ struct ccsr_guts __iomem *guts_regs = NULL;
+ struct device_node *guts;
+ uint32_t reg = 0;
+ int clk_src = 0;
+ int fm_clk_select = -EINVAL;
+ int fm_id = 0;
+
+ guts = of_find_matching_node(NULL, guts_device_ids);
+ if (!guts) {
+ pr_err(could not find GUTS node\n);
+ return -EINVAL;
+ }
+
+ guts_regs = of_iomap(guts, 0);
+ of_node_put(guts);
+ if (!guts_regs) {
+ pr_err(ioremap of GUTS node failed\n);
+ return -EINVAL;
+ }
Have you guys looked at using drivers/mfd/syscon.c for GUTS access.
+
+ if (!strcmp(__clk_get_name(hw-clk), fm1-clk))
+ fm_id = 1;
+
+ /* The FM clock provider is SoC dependent and it's determened by the
+ * reset configuration word (RCW). We need to map the RCW options to
+ * the order of the providers in the device tree.
+ * This code makes assumptions about the clock provider order:
+ * In the P family:
+ * 0 - platform clock/2
+ * 1 - PLLx /2
+ * 2 - PLLx /4 (if possible).
+ * In B/T family:
+ * The same order in which the clock providers are described in
+ * the Reference Manual, starting from 0.
+ *
+ * In a case of only one possible provider, the index is 0.
+ */
Does it make sense to do all this parsing every time get_fm_clk_parent, why not
do it during the init function once?
+
+ if (of_device_is_compatible(guts, fsl,p1023-guts) ||
+ of_device_is_compatible(guts, fsl,t1040-device-config))
+ /* P1023 and T1040 have only one optional clock source */
+ fm_clk_select = 0;
+ else if (of_device_is_compatible(guts, fsl,p2041-device-config) ||
+ of_device_is_compatible(guts, fsl,p3041-device-config) ||
+ of_device_is_compatible(guts, fsl,p4080-device-config)) {
+ /* Read RCW*/
+ reg = in_be32(guts_regs-rcwsr[7]);
+
+ /* Check bit 225 or bit 226 (FM2, P4080)
+ * 0 - The clock source is Platform PLL /2
+ * 1 - The clock source is PLL2 /2 (P2, P3) or PLL3 /2 (P4)
+ *
+ * Bit 225 represents FM1, Bit 226 represents FM2
+ */
+ if (fm_id == 0)
+ fm_clk_select = (reg FM1_CLK_SEL)
+
Re: [RFC v2 01/10] fsl_bman: Add drivers for the Freescale DPAA BMan
On Feb 16, 2015, at 9:46 AM, Emil Medve emilian.me...@freescale.com wrote: From: Geoff Thorpe geoff.tho...@freescale.com Change-Id: I075944acf740dbaae861104c17a9ff7247dec1be Signed-off-by: Geoff Thorpe geoff.tho...@freescale.com --- drivers/soc/Kconfig |1 + drivers/soc/Makefile |1 + drivers/soc/freescale/Kconfig| 51 ++ drivers/soc/freescale/Makefile |7 + drivers/soc/freescale/bman.c | 611 drivers/soc/freescale/bman.h | 524 + drivers/soc/freescale/bman_api.c | 1033 ++ drivers/soc/freescale/bman_portal.c | 330 +++ drivers/soc/freescale/bman_priv.h| 149 + drivers/soc/freescale/dpaa_alloc.c | 404 + drivers/soc/freescale/dpaa_sys.h | 235 drivers/soc/freescale/qbman_driver.c | 41 ++ include/linux/fsl_bman.h | 511 + If you are using drivers/soc than the include should probably be include/soc/freescale/ Also, any reason you guys aren’t using drivers/soc/fsl ? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC v2 00/10] Freescale DPAA B/QMan drivers
On Feb 16, 2015, at 9:46 AM, Emil Medve emilian.me...@freescale.com wrote: v2: Moved out of staging into soc/freescale Hello, This is the se attempt to publish the . They are not to be applied yet. These are the Freescale DPAA B/QMan drivers. At this stage, this is more or less the drivers from the Freescale PowerPC SDK roughly squashed and split in a sequence of component patches. They still needs some work and cleanup before we expect to have them applied, but we appreciate early feedback To do:Add a maintainer(s) entry Add module(s) support Some important clean-ups Cheers, Geoff Thorpe (8): fsl_bman: Add drivers for the Freescale DPAA BMan fsl_qman: Add drivers for the Freescale DPAA QMan powerpc/mpc85xx: Add platform support for the Freescale DPAA BMan powerpc/mpc85xx: Add platform support for the Freescale DPAA QMan fsl_bman: Add self-tester fsl_qman: Add self-tester fsl_bman: Add debugfs support fsl_qman: Add debugfs support Hai-Ying Wang (2): fsl_bman: Add HOTPLUG_CPU support fsl_qman: Add HOTPLUG_CPU support Really should look at using CMA for memory reservations used by q/bman backing store. - 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 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 b45...@freescale.com 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 b45...@freescale.com
---
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
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 b45...@freescale.com wrote:
qe need to use the rheap, so move it to public directory.
Signed-off-by: Zhao Qiang b45...@freescale.com
---
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 b45...@freescale.com 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 b45...@freescale.com
---
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 to pinmux and put in drivers/pinctrl
4. Some of the clock could should
Re: [PATCH 1/4] dt/bindings: Introduce the FSL QorIQ DPAA BMan
On Oct 22, 2014, at 9:09 AM, Emil Medve emilian.me...@freescale.com 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 emilian.me...@freescale.com
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: stringlist
+ Definition: Must include fsl,bman
+ May include fsl,SoC-bman
+
+- reg
+ Usage: Required
+ Value type: prop-encoded-array
+ Definition: Registers region within the CCSR address space
+
+- fsl,liodn
+ Usage: See pamu.txt
+ Value type: prop-encoded-array
+ Definition: PAMU property used for static LIODN assignment
+
+- fsl,iommu-parent
+ Usage: See pamu.txt
+ Value type: phandle
+ 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: stringlist
+ 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 emilian.me...@freescale.com 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 emilian.me...@freescale.com
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: stringlist
+ Definition: Must include fsl,bman
+ May include fsl,SoC-bman
+
+- reg
+ Usage: Required
+ Value type: prop-encoded-array
+ Definition: Registers region within the CCSR address space
+
+- interrupts
+ Usage: Required
+ Value type: prop-encoded-array
+ Definition: Standard property. The error interrupt
+
+- fsl,liodn
+ Usage: See pamu.txt
+ Value type: prop-encoded-array
+ Definition: PAMU property used for static LIODN assignment
+
+- fsl,iommu-parent
+ Usage: See pamu.txt
+ Value type: phandle
+ 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: stringlist
+ 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 emilian.me...@freescale.com 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 emilian.me...@freescale.com
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: stringlist
+ Definition: Must include fsl,bman-portal-hardware revision
+ May include fsl,SoC-bman-portal or fsl,bman-portal
+
+- reg
+ Usage: Required
+ Value type: prop-encoded-array
+ 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: prop-encoded-array
+ 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 3/3] rheap: move rheap.c from arch/powerpc/lib/ to lib/
On Sep 25, 2014, at 4:47 AM, Zhao Qiang b45...@freescale.com wrote:
qe need to use the rheap, so move it to public directory.
Signed-off-by: Zhao Qiang b45...@freescale.com
---
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 yuantian.t...@freescale.com
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 yuantian.t...@freescale.com
---
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 linux/of.h
#include linux/slab.h
#include linux/smp.h
-#include sysdev/fsl_soc.h
/**
* 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_PPC, but do we need this at
Re: [RFC PATCH] dt:numa: adding numa node mapping for memory nodes.
On Sep 17, 2014, at 1:56 AM, Ganapatrao Kulkarni
ganapatrao.kulka...@caviumnetworks.com wrote:
From: Ganapatrao Kulkarni ganapatrao.kulka...@cavium.com
This patch adds property nid to memory node to provide the memory range to
numa node id mapping.
Signed-off-by: Ganapatrao Kulkarni ganapatrao.kulka...@cavium.com
—
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|u32 | 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: [2/2] powerpc/corenet64_smp_defconfig: enable RTC support
On May 25, 2014, at 10:08 PM, shengzhou@freescale.com wrote: -Original Message- From: Wood Scott-B07421 Sent: Saturday, May 24, 2014 1:06 AM To: Liu Shengzhou-B36685 Cc: linuxppc-dev@lists.ozlabs.org Subject: Re: [2/2] powerpc/corenet64_smp_defconfig: enable RTC support On Fri, 2014-05-23 at 03:03 -0500, Liu Shengzhou-B36685 wrote: -Original Message- From: Wood Scott-B07421 Sent: Friday, May 23, 2014 6:52 AM To: Liu Shengzhou-B36685 Cc: linuxppc-dev@lists.ozlabs.org Subject: Re: [2/2] powerpc/corenet64_smp_defconfig: enable RTC support +++ b/arch/powerpc/configs/corenet64_smp_defconfig @@ -125,6 +125,11 @@ CONFIG_USB_EHCI_FSL=y CONFIG_USB_STORAGE=y CONFIG_MMC=y CONFIG_MMC_SDHCI=y +CONFIG_RTC_CLASS=y +CONFIG_RTC_DRV_CMOS=y +CONFIG_RTC_DRV_DS1307=y +CONFIG_RTC_DRV_DS1374=y +CONFIG_RTC_DRV_DS3232=y CONFIG_EDAC=y CONFIG_EDAC_MM_EDAC=y CONFIG_DMADEVICES=y Why only corenet64 and not corenet32? -Scott [Shengzhou] There is already RTC support in corenet32, only missing in corenet64. Only DS3232, not DS1307 or DS1374. Which boards use the latter two? Why do we need CONFIG_RTC_DRV_CMOS? -Scott [Shengzhou] so far DS1307 and DS1374 occur only on those boards with corenet64. CONFIG_RTC_DRV_CMOS is enabled in mpc85xx_defconfig, mpc85xx_smp_defconfig, corenet32_smp_defconfig, etc, here keeps consistent in corenet64. It seems CONFIG_RTC_DRV_CMOS is not needed on 85xx platform, do we need to remove CONFIG_RTC_DRV_CMOS from all 85xx/corenet defconfig? If so, I will post a new patch to do it. The CDS board uses an RTC over ISA if I remember correctly, not sure what driver deals with that (if its CONFIG_RTC_DRV_CMOS) or something else. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/fsl: Added binding for Freescale CoreNet coherency fabric (CCF)
On Apr 18, 2014, at 8:11 AM, Diana Craciun diana.crac...@freescale.com wrote:
From: Diana Craciun diana.crac...@freescale.com
The CoreNet coherency fabric is a fabric-oriented, conectivity
infrastructure that enables the implementation of coherent, multicore
systems. The CCF acts as a central interconnect for cores,
platform-level caches, memory subsystem, peripheral devices and I/O host
bridges in the system.
Signed-off-by: Diana Craciun diana.crac...@freescale.com
---
.../devicetree/bindings/powerpc/fsl/ccf.txt| 36 ++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/ccf.txt
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/ccf.txt
b/Documentation/devicetree/bindings/powerpc/fsl/ccf.txt
new file mode 100644
index 000..f0b7143
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/ccf.txt
@@ -0,0 +1,36 @@
+Freescale CoreNet Coherency Fabric(CCF) Device Tree Binding
+
+DESCRIPTION
+
+The CoreNet coherency fabric is a fabric-oriented, connectivity
infrastructure
+that enables the implementation of coherent, multicore systems.
+
+Required properties:
+
+- compatible : string
+ Must include fsl,corenetX-cf, fsl,corenet-cf - CoreNet
coherency
+ fabric version X
Can we make this ‘fsl,corenet-vX-cf’.
corenet-v1-cf/corenet-v2-cf looks nicer than corenet1-cf/corenet2-cf
+
+- reg : prop-encoded-array
+ A standard property. Represents the CCF registers.
+
+- interrupts : prop-encoded-array
+ Interrupt mapping for CCF error interrupt.
+
+- fsl,ccf-num-csdids: u32
+ Specifies the number of Coherency Subdomain ID Port Mapping
+ Registers that are supported by the CCF.
+
+- fsl,ccf-num-snoopids: u32
+ Specifies the number of Snoop ID Port Mapping Registers that
+ are supported by CCF.
+
+Example:
+
+ corenet-cf@18000 {
+ compatible = fsl,corenet2-cf, fsl,corenet-cf;
+ reg = 0x18000 0x1000;
+ interrupts = 16 2 1 31;
+ fsl,ccf-num-csdids = 32;
+ fsl,ccf-num-snoopids = 32;
+ };
--
1.7.11.7
___
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 v3] powerpc/fsl: Added binding for Freescale CoreNet coherency fabric (CCF)
On May 5, 2014, at 10:58 AM, Diana Craciun diana.crac...@freescale.com wrote: From: Diana Craciun diana.crac...@freescale.com The CoreNet coherency fabric is a fabric-oriented, conectivity infrastructure that enables the implementation of coherent, multicore systems. The CCF acts as a central interconnect for cores, platform-level caches, memory subsystem, peripheral devices and I/O host bridges in the system. Signed-off-by: Diana Craciun diana.crac...@freescale.com --- v3: - added port ID mapping - removed fsl,corenetx-cf .../devicetree/bindings/powerpc/fsl/ccf.txt| 42 ++ .../devicetree/bindings/powerpc/fsl/cpus.txt | 8 + .../devicetree/bindings/powerpc/fsl/pamu.txt | 8 + 3 files changed, 58 insertions(+) create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/ccf.txt [snip] --- a/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt @@ -20,3 +20,11 @@ PROPERTIES a property named fsl,eref-[CAT], where [CAT] is the abbreviated category name with all uppercase letters converted to lowercase, indicates that the category is supported by the implementation. + + - fsl,portid-mapping : u32 + The Coherency Subdomain ID Port Mapping Registers and Snoop ID Port Mapping + registers which are part of the CoreNet Coherency fabric (CCF) provide a + CoreNet Coherency Subdomain ID/CoreNet Snoop ID to cpu mapping functions. + Certain bits from these registers should be set if the coresponding CPU + should be snooped. This property defines a bitmask which selects the bit that + should be set if this cpu should be snooped. Under what cases can software not figure out how to set this based on the PAMUs in the DT? diff --git a/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt b/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt index 1f5e329..827c637 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt @@ -26,6 +26,13 @@ Required properties: A standard property. - #size-cells : u32 A standard property. +- fsl,portid-mapping : u32 + The Coherency Subdomain ID Port Mapping Registers and Snoop ID Port Mapping + registers which are part of the CoreNet Coherency fabric (CCF) provide a + CoreNet Coherency Subdomain ID/CoreNet Snoop ID to pamu mapping functions. + Certain bits from these registers should be set if PAMUs should be snooped. + This property defines a bitmask which selects the bits that should be set + if PAMUs should be snooped. Optional properties: - reg : prop-encoded-array @@ -88,6 +95,7 @@ Example: compatible = fsl,pamu-v1.0, fsl,pamu; reg = 0x2 0x5000; ranges = 0 0x2 0x5000; + fsl,portid-mapping = 0xf8; #address-cells = 1; #size-cells = 1; interrupts = -- 1.7.11.7 ___ 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] net/phy: Add Cortina CS43xx PHY support
On Mar 5, 2014, at 2:16 AM, Shengzhou Liu shengzhou@freescale.com wrote: Add support for Cortina CS4315/CS4340 10G PHY. (Tested with CS4315 on T2080RDB and CS4340 on T4240RDB). Signed-off-by: YongHua Cao b43...@freescale.com Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- drivers/net/phy/Kconfig | 5 +++ drivers/net/phy/Makefile | 1 + drivers/net/phy/cortina.c | 92 +++ 3 files changed, 98 insertions(+) create mode 100644 drivers/net/phy/cortina.c This patch really needs to be posted to the netdev list - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCh v2 2/2] Corenet: Add QE platform support for Corenet
On Mar 5, 2014, at 1:21 AM, Zhao Qiang b45...@freescale.com wrote:
There is QE on platform T104x, add support.
Call funcs qe_ic_init and qe_init if CONFIG_QUICC_ENGINE is defined.
Signed-off-by: Zhao Qiang b45...@freescale.com
---
Changes for v2:
- use mpc85xx_qe_init() instead
arch/powerpc/platforms/85xx/corenet_generic.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c
b/arch/powerpc/platforms/85xx/corenet_generic.c
index fbd871e..f1f4575 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -26,11 +26,14 @@
#include asm/udbg.h
#include asm/mpic.h
#include asm/ehv_pic.h
+#include asm/qe.h
+#include asm/qe_ic.h
#include linux/of_platform.h
#include sysdev/fsl_soc.h
#include sysdev/fsl_pci.h
#include smp.h
+#include mpc85xx.h
void __init corenet_gen_pic_init(void)
{
@@ -38,6 +41,10 @@ void __init corenet_gen_pic_init(void)
unsigned int flags = MPIC_BIG_ENDIAN | MPIC_SINGLE_DEST_CPU |
MPIC_NO_RESET;
+#ifdef CONFIG_QUICC_ENGINE
+ struct device_node *np;
+#endif
+
if (ppc_md.get_irq == mpic_get_coreint_irq)
flags |= MPIC_ENABLE_COREINT;
@@ -45,6 +52,16 @@ void __init corenet_gen_pic_init(void)
BUG_ON(mpic == NULL);
mpic_init(mpic);
+
+#ifdef CONFIG_QUICC_ENGINE
+ np = of_find_compatible_node(NULL, NULL, fsl,qe-ic);
+ if (np) {
+ qe_ic_init(np, 0, qe_ic_cascade_low_mpic,
+ qe_ic_cascade_high_mpic);
+ of_node_put(np);
+ }
+#endif
+
remove the #ifdef, they aren’t really needed.
}
/*
@@ -57,6 +74,11 @@ void __init corenet_gen_setup_arch(void)
swiotlb_detect_4g();
pr_info(%s board from Freescale Semiconductor\n, ppc_md.name);
+
+#ifdef CONFIG_QUICC_ENGINE
+ mpc85xx_qe_init();
+#endif
ifdef not needed
+
}
static const struct of_device_id of_device_ids[] = {
@@ -81,6 +103,9 @@ static const struct of_device_id of_device_ids[] = {
{
.compatible = fsl,qoriq-pcie-v3.0,
},
+ {
+ .compatible = fsl,qe,
+ },
/* The following two are for the Freescale hypervisor */
{
.name = hypervisor,
--
1.8.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Corenet: Add QE platform support for Corenet
On Feb 28, 2014, at 2:48 AM, Zhao Qiang b45...@freescale.com wrote:
There is QE on platform T104x, add support.
Call funcs qe_ic_init and qe_init if CONFIG_QUICC_ENGINE is defined.
Signed-off-by: Zhao Qiang b45...@freescale.com
---
arch/powerpc/platforms/85xx/corenet_generic.c | 32 +++
1 file changed, 32 insertions(+)
Can you use mpc85xx_qe_init() instead?
diff --git a/arch/powerpc/platforms/85xx/corenet_generic.c
b/arch/powerpc/platforms/85xx/corenet_generic.c
index fbd871e..f8c8e0c 100644
--- a/arch/powerpc/platforms/85xx/corenet_generic.c
+++ b/arch/powerpc/platforms/85xx/corenet_generic.c
@@ -26,6 +26,8 @@
#include asm/udbg.h
#include asm/mpic.h
#include asm/ehv_pic.h
+#include asm/qe.h
+#include asm/qe_ic.h
#include linux/of_platform.h
#include sysdev/fsl_soc.h
@@ -38,6 +40,10 @@ void __init corenet_gen_pic_init(void)
unsigned int flags = MPIC_BIG_ENDIAN | MPIC_SINGLE_DEST_CPU |
MPIC_NO_RESET;
+#ifdef CONFIG_QUICC_ENGINE
+ struct device_node *np;
+#endif
+
if (ppc_md.get_irq == mpic_get_coreint_irq)
flags |= MPIC_ENABLE_COREINT;
@@ -45,6 +51,16 @@ void __init corenet_gen_pic_init(void)
BUG_ON(mpic == NULL);
mpic_init(mpic);
+
+#ifdef CONFIG_QUICC_ENGINE
+ np = of_find_compatible_node(NULL, NULL, fsl,qe-ic);
+ if (np) {
+ qe_ic_init(np, 0, qe_ic_cascade_low_mpic,
+ qe_ic_cascade_high_mpic);
+ of_node_put(np);
+ }
+#endif
+
}
/*
@@ -52,11 +68,24 @@ void __init corenet_gen_pic_init(void)
*/
void __init corenet_gen_setup_arch(void)
{
+#ifdef CONFIG_QUICC_ENGINE
+ struct device_node *np;
+#endif
mpc85xx_smp_init();
swiotlb_detect_4g();
pr_info(%s board from Freescale Semiconductor\n, ppc_md.name);
+
+#ifdef CONFIG_QUICC_ENGINE
+ np = of_find_compatible_node(NULL, NULL, fsl,qe);
+ if (!np) {
+ pr_err(%s: Could not find Quicc Engine node\n, __func__);
+ return;
This doesn’t seem like an reasonable error message for common corenet platform.
It seems reasonable to build QE support but boot on a chip w/o QE.
+ }
+ qe_reset();
+ of_node_put(np);
+#endif
}
static const struct of_device_id of_device_ids[] = {
@@ -81,6 +110,9 @@ static const struct of_device_id of_device_ids[] = {
{
.compatible = fsl,qoriq-pcie-v3.0,
},
+ {
+ .compatible = fsl,qe,
+ },
/* The following two are for the Freescale hypervisor */
{
.name = hypervisor,
--
1.8.5
___
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 2/2] of: search the best compatible match first in __of_match_node()
On Feb 14, 2014, at 9:53 AM, Rob Herring robherri...@gmail.com wrote:
On Thu, Feb 13, 2014 at 11:22 PM, Kevin Hao haoke...@gmail.com wrote:
Currently, of_match_node compares each given match against all node's
compatible strings with of_device_is_compatible.
To achieve multiple compatible strings per node with ordering from
specific to generic, this requires given matches to be ordered from
specific to generic. For most of the drivers this is not true and also
an alphabetical ordering is more sane there.
Therefore, this patch introduces a function to match each of the node's
compatible strings against all given compatible matches without type and
name first, before checking the next compatible string. This implies
that node's compatibles are ordered from specific to generic while
given matches can be in any order. If we fail to find such a match
entry, then fall-back to the old method in order to keep compatibility.
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Signed-off-by: Kevin Hao haoke...@gmail.com
Looks good to me. I'll put this in next for a few days. I'd really
like to see some acks and tested-by's before sending to Linus.
We could be a bit more strict here and fallback to the old matching if
the match table has any entries with name or type. I don't think that
should be necessary though.
Rob
Can you push the revert to Linus sooner, since currently a ton of boards
wouldn’t be working on the PPC side, so at least -rc3 has the possibility of
working for them.
- k
---
drivers/of/base.c | 43 ++-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index ba195fbce4c6..10b51106c854 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -730,13 +730,49 @@ out:
}
EXPORT_SYMBOL(of_find_node_with_property);
+static const struct of_device_id *
+of_match_compatible(const struct of_device_id *matches,
+ const struct device_node *node)
+{
+ const char *cp;
+ int cplen, l;
+ const struct of_device_id *m;
+
+ cp = __of_get_property(node, compatible, cplen);
+ while (cp (cplen 0)) {
+ m = matches;
+ while (m-name[0] || m-type[0] || m-compatible[0]) {
+ /* Only match for the entries without type and name
*/
+ if (m-name[0] || m-type[0] ||
+ of_compat_cmp(m-compatible, cp,
+strlen(m-compatible)))
+ m++;
+ else
+ return m;
+ }
+
+ /* Get node's next compatible string */
+ l = strlen(cp) + 1;
+ cp += l;
+ cplen -= l;
+ }
+
+ return NULL;
+}
+
static
const struct of_device_id *__of_match_node(const struct of_device_id
*matches,
const struct device_node *node)
{
+ const struct of_device_id *m;
+
if (!matches)
return NULL;
+ m = of_match_compatible(matches, node);
+ if (m)
+ return m;
+
while (matches-name[0] || matches-type[0] ||
matches-compatible[0]) {
int match = 1;
if (matches-name[0])
@@ -760,7 +796,12 @@ const struct of_device_id *__of_match_node(const struct
of_device_id *matches,
* @matches: array of of device match structures to search in
* @node: the of device structure to match against
*
- * Low level utility function used by device matching.
+ * Low level utility function used by device matching. We have two ways
+ * of matching:
+ * - Try to find the best compatible match by comparing each compatible
+ * string of device node with all the given matches respectively.
+ * - If the above method failed, then try to match the compatible by
using
+ * __of_device_is_compatible() besides the match in type and name.
*/
const struct of_device_id *of_match_node(const struct of_device_id *matches,
const struct device_node *node)
--
1.8.5.3
--
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 2/2] of: search the best compatible match first in __of_match_node()
On Feb 14, 2014, at 9:53 AM, Rob Herring robherri...@gmail.com wrote: On Thu, Feb 13, 2014 at 11:22 PM, Kevin Hao haoke...@gmail.com wrote: Currently, of_match_node compares each given match against all node's compatible strings with of_device_is_compatible. To achieve multiple compatible strings per node with ordering from specific to generic, this requires given matches to be ordered from specific to generic. For most of the drivers this is not true and also an alphabetical ordering is more sane there. Therefore, this patch introduces a function to match each of the node's compatible strings against all given compatible matches without type and name first, before checking the next compatible string. This implies that node's compatibles are ordered from specific to generic while given matches can be in any order. If we fail to find such a match entry, then fall-back to the old method in order to keep compatibility. Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com Signed-off-by: Kevin Hao haoke...@gmail.com Looks good to me. I'll put this in next for a few days. I'd really like to see some acks and tested-by's before sending to Linus. We could be a bit more strict here and fallback to the old matching if the match table has any entries with name or type. I don't think that should be necessary though. Rob Can you push the revert to Linus sooner, since currently a ton of boards wouldn’t be working on the PPC side, so at least -rc3 has the possibility of working for them. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Linux-3.14-rc2: Order of serial node compatibles in DTS files.
On Feb 11, 2014, at 2:57 PM, Stephen N Chivers schiv...@csc.com.au wrote:
I have been trial booting a 3.14-rc2 kernel for a 85xx platform
(dtbImage).
After mounting the root filesystem there are no messages from the init
scripts
and the serial console is not available for login.
In the kernel log messages there is:
of_serial f1004500.serial: Unknown serial port found, ignored.
The serial nodes in boards dts file are specified as:
serial0: serial@4500 {
cell-index = 0;
device_type = serial;
compatible = fsl,ns16550, ns16550;
reg = 0x4500 0x100;
clock-frequency = 0;
interrupts = 0x2a 0x2;
interrupt-parent = mpic;
};
Reversing the order of the compatible:
compatible = ns16550, fsl,ns16550;
restores the serial console.
Linux-3.13 does not have this behaviour.
There are 49 dts files in Linux-3.14-rc2 that have the fsl,ns16550
compatible first.
Hmm,
Wondering if this caused the issue:
commit 105353145eafb3ea919f5cdeb652a9d8f270228e
Author: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Date: Tue Dec 3 14:52:00 2013 +0100
OF: base: match each node compatible against all given matches first
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Convert powerpc simple spinlocks into ticket locks
On Feb 7, 2014, at 3:02 AM, Torsten Duwe d...@lst.de wrote: On Thu, Feb 06, 2014 at 02:19:52PM -0600, Scott Wood wrote: On Thu, 2014-02-06 at 18:37 +0100, Torsten Duwe wrote: On Thu, Feb 06, 2014 at 05:38:37PM +0100, Peter Zijlstra wrote: Can you pair lwarx with sthcx ? I couldn't immediately find the answer in the PowerISA doc. If so I think you can do better by being able to atomically load both tickets but only storing the head without affecting the tail. Can I simply write the half word, without a reservation, or will the HW caches mess up the other half? Will it ruin the cache coherency on some (sub)architectures? The coherency should be fine, I just can’t remember if you’ll lose the reservation by doing this. Plus, sthcx doesn't exist on all PPC chips. Which ones are lacking it? Do all have at least a simple 16-bit store? Everything implements a simple 16-bit store, just not everything implements the store conditional of 16-bit data. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add cpu family documentation
On Jan 29, 2014, at 8:38 PM, Michael Ellerman m...@ellerman.id.au wrote: This patch adds some documentation on the different cpu families supported by arch/powerpc. Signed-off-by: Michael Ellerman m...@ellerman.id.au --- Documentation/powerpc/cpu_families.txt | 76 ++ 1 file changed, 76 insertions(+) create mode 100644 Documentation/powerpc/cpu_families.txt diff --git a/Documentation/powerpc/cpu_families.txt b/Documentation/powerpc/cpu_families.txt new file mode 100644 index 000..df72657 --- /dev/null +++ b/Documentation/powerpc/cpu_families.txt @@ -0,0 +1,76 @@ +CPU Families + + +This doco tries to summarise some of the different cpu families that exist and +are supported by arch/powerpc. + +Book3S (aka sPAPR) +-- + + - Hash MMU + - Mix of 32 64 bit + + Old + POWER --- 601 --- 603 + || | + || *- 740 + || | + || *- 750 (G3) --- 750CX --- 750CL --- 750FX + || | + || | + | 604 *--- 7400 --- 7410 --- 7450 --- 7455 --- 7447 --- 7448 + || + || + |* [620] --- POWER3/630 --- POWER3+ --- POWER4 --- POWER4+ --- POWER5 --- POWER5+ --- POWER5++ --- POWER6 --- POWER7 --- POWER7+ --- POWER8 + | (64bit) |. + | |. + | |*--- Cell + | | + | *--- 970 --- 970FX --- 970MP + | + *--- RS64 (threads) + + + PA6T (64bit) ... + + +IBM BookE +- + + - Software loaded TLB. + - All 32 bit + + 401 --- 403 --- 405 --- 440 --- 450 --- 460 --- 476 + | + *--- BG/P + + +Motorola/Freescale 8xx +-- + + - Software loaded with hardware assist. + - All 32 bit + + 8xx --- 850 + + +Freescale BookE +--- + + - Software loaded TLB. + - e6500 adds HW loaded indirect TLB entries. + - Mix of 32 64 bit + + e200 --- e500 --- e500v2 --- e500mc --- e5500 --- e6500 + (Book3E) (HW TLB) + (64bit) + e200 is its own core family that doesn’t have any relation to e500 line other than being book-e might want to add multithreaded to e6500. +IBM A2 core +--- + + - Book3E, software loaded TLB + HW loaded indirect TLB entries. + - 64 bit + + A2 core --- BG/Q + | + *--- WSP -- 1.8.3.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 1/2][v6] driver/memory:Move Freescale IFC driver to a common driver
On Jan 25, 2014, at 6:06 AM, Prabhakar Kushwaha prabha...@freescale.com wrote:
Freescale IFC controller has been used for mpc8xxx. It will be used
for ARM-based SoC as well. This patch moves the driver to driver/memory
and fix the header file includes.
Also remove module_platform_driver() and instead call
platform_driver_register() from subsys_initcall() to make sure this module
has been loaded before MTD partition parsing starts.
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
Acked-by: Arnd Bergmann a...@arndb.de
---
Based upon git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
Branch next
Changes for v2:
- Move fsl_ifc in driver/memory
Changes for v3:
- move device tree bindings to memory
Changes for v4: Rebased to
git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git
Changes for v5:
- Moved powerpc/Kconfig option to driver/memory
Changes for v6:
- Update Kconfig details
.../{powerpc = memory-controllers}/fsl/ifc.txt|0
arch/powerpc/Kconfig |4
arch/powerpc/sysdev/Makefile |1 -
drivers/memory/Kconfig |9 +
drivers/memory/Makefile|1 +
{arch/powerpc/sysdev = drivers/memory}/fsl_ifc.c |8 ++--
drivers/mtd/nand/fsl_ifc_nand.c|2 +-
.../include/asm = include/linux}/fsl_ifc.h|0
8 files changed, 17 insertions(+), 8 deletions(-)
rename Documentation/devicetree/bindings/{powerpc =
memory-controllers}/fsl/ifc.txt (100%)
rename {arch/powerpc/sysdev = drivers/memory}/fsl_ifc.c (98%)
rename {arch/powerpc/include/asm = include/linux}/fsl_ifc.h (100%)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/ifc.txt
b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
similarity index 100%
rename from Documentation/devicetree/bindings/powerpc/fsl/ifc.txt
rename to Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index fa39517..91dc43c 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -727,10 +727,6 @@ config FSL_LBC
controller. Also contains some common code used by
drivers for specific local bus peripherals.
-config FSL_IFC
- bool
-depends on FSL_SOC
-
config FSL_GTM
bool
depends on PPC_83xx || QUICC_ENGINE || CPM2
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index f67ac90..afbcc37 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -21,7 +21,6 @@ obj-$(CONFIG_FSL_SOC) += fsl_soc.o
fsl_mpic_err.o
obj-$(CONFIG_FSL_PCI) += fsl_pci.o $(fsl-msi-obj-y)
obj-$(CONFIG_FSL_PMC) += fsl_pmc.o
obj-$(CONFIG_FSL_LBC) += fsl_lbc.o
-obj-$(CONFIG_FSL_IFC)+= fsl_ifc.o
obj-$(CONFIG_FSL_GTM) += fsl_gtm.o
obj-$(CONFIG_FSL_85XX_CACHE_SRAM) += fsl_85xx_l2ctlr.o
fsl_85xx_cache_sram.o
obj-$(CONFIG_SIMPLE_GPIO) += simple_gpio.o
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 29a11db..555d26f 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -50,4 +50,13 @@ config TEGRA30_MC
analysis, especially for IOMMU/SMMU(System Memory Management
Unit) module.
+config FSL_IFC
+ bool Freescale Integrated Flash Controller
+ default y
+depends on FSL_SOC
minor white space nit (spaces instead of tab)
+ help
+ This driver is for the Integrated Flash Controller Controller(IFC)
+ module available in Freescale SoCs. This controller allows to handle
flash
+ devices such as NOR, NAND, FPGA and ASIC etc
+
endif
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2][v5] driver/memory:Move Freescale IFC driver to a common driver
On Jan 18, 2014, at 12:21 AM, Prabhakar Kushwaha prabha...@freescale.com
wrote:
Freescale IFC controller has been used for mpc8xxx. It will be used
for ARM-based SoC as well. This patch moves the driver to driver/memory
and fix the header file includes.
Also remove module_platform_driver() and instead call
platform_driver_register() from subsys_initcall() to make sure this module
has been loaded before MTD partition parsing starts.
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
Acked-by: Arnd Bergmann a...@arndb.de
---
Changes for v2:
- Move fsl_ifc in driver/memory
Changes for v3:
- move device tree bindings to memory
Changes for v4: Rebased to
git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git
Changes for v5:
- Moved powerpc/Kconfig option to driver/memory
.../{powerpc = memory-controllers}/fsl/ifc.txt|0
arch/powerpc/Kconfig |4
arch/powerpc/sysdev/Makefile |1 -
drivers/memory/Kconfig |4
drivers/memory/Makefile|1 +
{arch/powerpc/sysdev = drivers/memory}/fsl_ifc.c |8 ++--
drivers/mtd/nand/fsl_ifc_nand.c|2 +-
.../include/asm = include/linux}/fsl_ifc.h|0
8 files changed, 12 insertions(+), 8 deletions(-)
rename Documentation/devicetree/bindings/{powerpc =
memory-controllers}/fsl/ifc.txt (100%)
rename {arch/powerpc/sysdev = drivers/memory}/fsl_ifc.c (98%)
rename {arch/powerpc/include/asm = include/linux}/fsl_ifc.h (100%)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/ifc.txt
b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
similarity index 100%
rename from Documentation/devicetree/bindings/powerpc/fsl/ifc.txt
rename to Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index b44b52c..83fb8b3 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -725,10 +725,6 @@ config FSL_LBC
controller. Also contains some common code used by
drivers for specific local bus peripherals.
-config FSL_IFC
- bool
-depends on FSL_SOC
-
config FSL_GTM
bool
depends on PPC_83xx || QUICC_ENGINE || CPM2
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index f67ac90..afbcc37 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -21,7 +21,6 @@ obj-$(CONFIG_FSL_SOC) += fsl_soc.o
fsl_mpic_err.o
obj-$(CONFIG_FSL_PCI) += fsl_pci.o $(fsl-msi-obj-y)
obj-$(CONFIG_FSL_PMC) += fsl_pmc.o
obj-$(CONFIG_FSL_LBC) += fsl_lbc.o
-obj-$(CONFIG_FSL_IFC)+= fsl_ifc.o
obj-$(CONFIG_FSL_GTM) += fsl_gtm.o
obj-$(CONFIG_FSL_85XX_CACHE_SRAM) += fsl_85xx_l2ctlr.o
fsl_85xx_cache_sram.o
obj-$(CONFIG_SIMPLE_GPIO) += simple_gpio.o
diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
index 29a11db..b33bb0e 100644
--- a/drivers/memory/Kconfig
+++ b/drivers/memory/Kconfig
@@ -50,4 +50,8 @@ config TEGRA30_MC
analysis, especially for IOMMU/SMMU(System Memory Management
Unit) module.
+config FSL_IFC
+ bool
+depends on FSL_SOC
+
I think this should be user selectable like all the other Kconfig options in
drivers/memory
Also add a help description.
endif
[ snip ]
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/configs: Enbale Freescale IFC controller
On Jan 17, 2014, at 12:09 AM, Prabhakar Kushwaha prabha...@freescale.com wrote: Currently IFC NAND driver is enabled in corenet32smp_defconfig. But IFC controller is not enabled So, Enable IFC controller in corenet32smp_defconfig. Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- Based upon git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git branch master arch/powerpc/configs/corenet32_smp_defconfig |1 + 1 file changed, 1 insertion(+) Shouldn’t the NAND driver get the IFC controller enabled by Kconfig dependancies? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/pci: Fix IMMRBAR address
On Jan 16, 2014, at 2:14 AM, Minghuan Lian minghuan.l...@freescale.com wrote: For PEXCSRBAR, bit 3-0 indicate prefetchable and address type. So when getting base address, these bits should be masked, otherwise we may get incorrect base address. Signed-off-by: Minghuan Lian minghuan.l...@freescale.com --- arch/powerpc/sysdev/fsl_pci.c | 8 1 file changed, 8 insertions(+) diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c index 4dfd61d..44eae39 100644 --- a/arch/powerpc/sysdev/fsl_pci.c +++ b/arch/powerpc/sysdev/fsl_pci.c @@ -868,6 +868,14 @@ u64 fsl_pci_immrbar_base(struct pci_controller *hose) pci_bus_read_config_dword(hose-bus, PCI_DEVFN(0, 0), PCI_BASE_ADDRESS_0, base); + + /* + * For PEXCSRBAR, bit 3-0 indicate prefetchable and + * address type. So when getting base address, these + * bits should be masked + */ + base = 0xfff0; + base PCI_BASE_ADDRESS_MEM_MASK return base; } #endif -- 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 1/2][v3] driver/memory:Move Freescale IFC driver to a common driver
On Jan 15, 2014, at 11:42 PM, Prabhakar Kushwaha prabha...@freescale.com
wrote:
Freescale IFC controller has been used for mpc8xxx. It will be used
for ARM-based SoC as well. This patch moves the driver to driver/memory
and fix the header file includes.
Also remove module_platform_driver() and instead call
platform_driver_register() from subsys_initcall() to make sure this module
has been loaded before MTD partition parsing starts.
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
Acked-by: Arnd Bergmann a...@arndb.de
---
Changes for v2:
- Move fsl_ifc in driver/memory
Changes for v3:
- move device tree bindings to memory
.../{powerpc = memory-controllers}/fsl/ifc.txt|0
arch/powerpc/sysdev/Makefile |1 -
drivers/memory/Makefile|1 +
{arch/powerpc/sysdev = drivers/memory}/fsl_ifc.c |8 ++--
drivers/mtd/nand/fsl_ifc_nand.c|2 +-
.../include/asm = include/linux}/fsl_ifc.h|0
6 files changed, 8 insertions(+), 4 deletions(-)
rename Documentation/devicetree/bindings/{powerpc =
memory-controllers}/fsl/ifc.txt (100%)
rename {arch/powerpc/sysdev = drivers/memory}/fsl_ifc.c (98%)
rename {arch/powerpc/include/asm = include/linux}/fsl_ifc.h (100%)
The Kconfig option for FSL_IFC should move into drivers/memory/Kconfig
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/ifc.txt
b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
similarity index 100%
rename from Documentation/devicetree/bindings/powerpc/fsl/ifc.txt
rename to Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index f67ac90..afbcc37 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -21,7 +21,6 @@ obj-$(CONFIG_FSL_SOC) += fsl_soc.o
fsl_mpic_err.o
obj-$(CONFIG_FSL_PCI) += fsl_pci.o $(fsl-msi-obj-y)
obj-$(CONFIG_FSL_PMC) += fsl_pmc.o
obj-$(CONFIG_FSL_LBC) += fsl_lbc.o
-obj-$(CONFIG_FSL_IFC)+= fsl_ifc.o
obj-$(CONFIG_FSL_GTM) += fsl_gtm.o
obj-$(CONFIG_FSL_85XX_CACHE_SRAM) += fsl_85xx_l2ctlr.o
fsl_85xx_cache_sram.o
obj-$(CONFIG_SIMPLE_GPIO) += simple_gpio.o
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index 969d923..f2bf25c 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -6,6 +6,7 @@ ifeq ($(CONFIG_DDR),y)
obj-$(CONFIG_OF) += of_memory.o
endif
obj-$(CONFIG_TI_EMIF) += emif.o
+obj-$(CONFIG_FSL_IFC)+= fsl_ifc.o
obj-$(CONFIG_MVEBU_DEVBUS)+= mvebu-devbus.o
obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o
obj-$(CONFIG_TEGRA30_MC) += tegra30-mc.o
diff --git a/arch/powerpc/sysdev/fsl_ifc.c b/drivers/memory/fsl_ifc.c
similarity index 98%
rename from arch/powerpc/sysdev/fsl_ifc.c
rename to drivers/memory/fsl_ifc.c
index d7fc722..135a950 100644
--- a/arch/powerpc/sysdev/fsl_ifc.c
+++ b/drivers/memory/fsl_ifc.c
@@ -30,8 +30,8 @@
#include linux/of.h
#include linux/of_device.h
#include linux/platform_device.h
+#include linux/fsl_ifc.h
#include asm/prom.h
-#include asm/fsl_ifc.h
struct fsl_ifc_ctrl *fsl_ifc_ctrl_dev;
EXPORT_SYMBOL(fsl_ifc_ctrl_dev);
@@ -299,7 +299,11 @@ static struct platform_driver fsl_ifc_ctrl_driver = {
.remove = fsl_ifc_ctrl_remove,
};
-module_platform_driver(fsl_ifc_ctrl_driver);
+static int __init fsl_ifc_init(void)
+{
+ return platform_driver_register(fsl_ifc_ctrl_driver);
+}
+subsys_initcall(fsl_ifc_init);
MODULE_LICENSE(GPL);
MODULE_AUTHOR(Freescale Semiconductor);
diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
index 4335577..865b323 100644
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -30,7 +30,7 @@
#include linux/mtd/nand.h
#include linux/mtd/partitions.h
#include linux/mtd/nand_ecc.h
-#include asm/fsl_ifc.h
+#include linux/fsl_ifc.h
#define FSL_IFC_V1_1_00x0101
#define ERR_BYTE 0xFF /* Value returned for read
diff --git a/arch/powerpc/include/asm/fsl_ifc.h b/include/linux/fsl_ifc.h
similarity index 100%
rename from arch/powerpc/include/asm/fsl_ifc.h
rename to include/linux/fsl_ifc.h
--
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: Where to post problems with linux-ppc for Freescale processors such as the p1020?
On Dec 31, 2013, at 2:35 PM, jeclark2006 jeclark2...@aim.com wrote: As the subject says... where to post problems with ppc linux that does not involve 'apple' implementations. The 'embedded' list appears to be pretty much dead. This is now the list for any ppc linux issues for embedded, server, etc. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/gpio: Fix the wrong GPIO input data on MPC8572/MPC8536
On Nov 22, 2013, at 2:12 AM, Liu Gang gang@freescale.com wrote: For MPC8572/MPC8536, the status of GPIOs defined as output cannot be determined by reading GPDAT register, so the code use shadow data register instead. But the code may give the wrong status of GPIOs defined as input under some scenarios: 1. If some pins were configured as inputs and were asserted high before booting the kernel, the shadow data has been initialized with those pin values. 2. Some pins have been configured as output first and have been set to the high value, then reconfigured as input. The above cases will make the shadow data for those input pins to be set to high. Then reading the pin status will always return high even if the actual pin status is low. The code should eliminate the effects of the shadow data to the input pins, and the status of those pins should be read directly from GPDAT. Signed-off-by: Liu Gang gang@freescale.com --- changes in v2: - Added more description of the problem. - Reduced one in_be32() call. - Do not modify the shadow data. drivers/gpio/gpio-mpc8xxx.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c index 914e859..d7d6d72 100644 --- a/drivers/gpio/gpio-mpc8xxx.c +++ b/drivers/gpio/gpio-mpc8xxx.c @@ -70,10 +70,14 @@ static int mpc8572_gpio_get(struct gpio_chip *gc, unsigned int gpio) u32 val; struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc); struct mpc8xxx_gpio_chip *mpc8xxx_gc = to_mpc8xxx_gpio_chip(mm); + u32 out_mask, out_shadow; - val = in_be32(mm-regs + GPIO_DAT) ~in_be32(mm-regs + GPIO_DIR); + out_mask = in_be32(mm-regs + GPIO_DIR); - return (val | mpc8xxx_gc-data) mpc8xxx_gpio2mask(gpio); + val = in_be32(mm-regs + GPIO_DAT) ~out_mask; + out_shadow = mpc8xxx_gc-data out_mask; + + return (val | out_shadow) mpc8xxx_gpio2mask(gpio); } I really think a comment is worth adding here about why we do this. - k static int mpc8xxx_gpio_get(struct gpio_chip *gc, unsigned int gpio) -- 1.8.4.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: [RFC][PATCH] powerpc/CoreNet64: compile with CONFIG_E{5, 6}500_CPU well
On Nov 20, 2013, at 10:41 AM, Scott Wood scottw...@freescale.com wrote:
On Wed, 2013-11-20 at 16:35 +0800, Tiejun Chen wrote:
CONFIG_ALTIVEC is always enabled for CoreNet64.
In the defconfig perhaps, but this isn't a generally true statement.
And if we select CONFIG_E{5,6}500_CPU this may introduce -mcpu=e500mc64
into $CFLAGS. But Altivec and Spe options not allowed with
e500mc64, so :
Sigh.
CC arch/powerpc/lib/xor_vmx.o
arch/powerpc/lib/xor_vmx.c:1:0: error: AltiVec not supported in this target
make[1]: *** [arch/powerpc/lib/xor_vmx.o] Error 1
make: *** [arch/powerpc/lib] Error 2
Signed-off-by: Tiejun Chen tiejun.c...@windriver.com
---
arch/powerpc/lib/Makefile |3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 95a20e1..641a77d 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -40,5 +40,8 @@ obj-y += code-patching.o
obj-y+= feature-fixups.o
obj-$(CONFIG_FTR_FIXUP_SELFTEST) += feature-fixups-test.o
+# Altivec and Spe options not allowed with e500mc64 in GCC.
+ifeq ($(call cc-option-yn,-mcpu=e500mc64),n)
obj-$(CONFIG_ALTIVEC)+= xor_vmx.o
CFLAGS_xor_vmx.o += -maltivec -mabi=altivec
+endif
This does not seem like the right fix. What if GCC supports both
-mcpu=e500mc64 and -mcpu=e6500, and we're using the latter? Or for that
matter, if we're using -mcpu=whatever-ibm-chip-has-this?
Plus, wouldn't you need to do something to prevent code in that file
from being called?
-Scott
Why does -mcpu=e500mc64 get you spe enabled? It shouldn’t as no e500mc or
greater part has spe. Can you try using -mno-spe -maltivec?
- k
___
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 lijun@freescale.com 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 lijun@freescale.com --- 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 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 b42...@freescale.com --- 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 ga...@codeaurora.org - 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] [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] [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 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 minghuan.l...@freescale.com
---
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 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 w...@denx.de
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Scott Wood scottw...@freescale.com
---
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] 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] 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 x@freescale.com --- 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 moved you should address the PPC specific issues in the code. Use of
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 x@freescale.com
---
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 x@freescale.com --- 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 moved you should
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 aida.mynzhas...@skitlab.ru --- 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 ga...@codeaurora.org - 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 scottw...@freescale.com
---
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 scottw...@freescale.com
---
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 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 aida.mynzhas...@skitlab.ru
---
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 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 dongsheng.w...@freescale.com E6500 PVR and SPRN_PWRMGTCR0 will be used in subsequent pw20/altivec idle patches. Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com --- *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 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] 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 poonam.aggr...@freescale.com
Signed-off-by: Priyanka Jain priyanka.j...@freescale.com
Signed-off-by: Varun Sethi varun.se...@freescale.com
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
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 {
+reg = 0 0 0 0 0;
+#interrupt-cells = 1;
+#size-cells = 2;
+#address-cells = 3;
+device_type = pci;
+
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 shengzhou@freescale.com Signed-off-by: Zhao Qiang b45...@freescale.com --- 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/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 shengzhou@freescale.com Signed-off-by: Zhao Qiang b45...@freescale.com --- 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 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 hongtao@freescale.com
---
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,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
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 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 soniccat@gmail.com
Signed-off-by: Li Yang le...@freescale.com
Signed-off-by: Jia Hongtao hongtao@freescale.com
---
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 hongtao@freescale.com
---
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 {
+ compatible = philips,pca9547;
+ reg = 0x77;
+ #address-cells = 1;
+
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 wangyij...@huawei.com Cc: Gavin Shan sha...@linux.vnet.ibm.com Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Paul Mackerras pau...@samba.org 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 ga...@kernel.crashing.org (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 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 dongsheng.w...@freescale.com 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 dongsheng.w...@freescale.com 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: [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 | 137 +++---
arch/powerpc/sysdev/fsl_msi.h | 10 +-
arch/powerpc/sysdev/fsl_pci.c | 184 --
arch/powerpc/sysdev/fsl_pci.h
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 haijun.zh...@freescale.com --- 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: [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 schiv...@csc.com --- 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: [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: [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 shav...@freescale.com --- .../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] Add device file bindings for MAPLE
On Aug 1, 2013, at 6:02 AM, Shaveta Leekha wrote:
Signed-off-by: Shaveta Leekha shav...@freescale.com
---
.../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
+ : phandle
+ 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 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 catalin.u...@freescale.com --- 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 aflem...@freescale.com 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 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 haijun.zh...@freescale.com
---
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 haoke...@gmail.com --- 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 haijun.zh...@freescale.com
Signed-off-by: Anton Vorontsov cbouatmai...@gmail.com
--- 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 1/2] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
On Jul 5, 2013, at 1:27 AM, hongbo.zh...@freescale.com
hongbo.zh...@freescale.com wrote:
From: Hongbo Zhang hongbo.zh...@freescale.com
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 hongbo.zh...@freescale.com
---
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 DMA device tree stub [ controller @ offset 0x101000 ]
+ *
+ * Copyright 2011-2013 Freescale
Re: [PATCH V2 1/2] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
On Jul 5, 2013, at 1:27 AM, hongbo.zh...@freescale.com hongbo.zh...@freescale.com wrote: From: Hongbo Zhang hongbo.zh...@freescale.com 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 hongbo.zh...@freescale.com --- 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: 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: 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: [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 yuantian.t...@freescale.com The compatible string of clock is changed from *-2 to *-2.0 on chassis 2. So updated it accordingly. Signed-off-by: Tang Yuantian yuantian.t...@freescale.com 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: [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 CE,EE,ME 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 haoke...@gmail.com --- 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 haoke...@gmail.com --- 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 b32...@freescale.com --- 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/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi
Re: [PATCH] powerpc/fsl-pci:fix incorrect iounmap pci hose-private_data
On Apr 23, 2013, at 12:44 AM, Zang Roy-R61911 wrote: -Original Message- From: Zang Roy-R61911 Sent: Tuesday, April 23, 2013 2:36 AM To: linuxppc-dev@lists.ozlabs.org Cc: ga...@kernel.crashing.org; Zang Roy-R61911; Chen Yuanquan-B41889 Subject: [PATCH] powerpc/fsl-pci:fix incorrect iounmap pci hose- private_data pci hose-private_data will be used by other function, for example, fsl_pcie_check_link(), so do not iounmap it. fix the kerenl crash on T4240: Unable to handle kernel paging request for data at address 0x880080060f14 Faulting instruction address: 0xc0032554 Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=24 T4240 QDS Modules linked in: NIP: c0032554 LR: c003254c CTR: c001e5c0 REGS: c00179143440 TRAP: 0300 Not tainted (3.8.8-rt2-00754-g951f064-dirt) MSR: 80029000 CE,EE,ME CR: 24adbe22 XER: SOFTE: 0 DEAR: 880080060f14, ESR: TASK = c0017913d2c0[1] 'swapper/0' THREAD: c0017914 CPU: 2 GPR00: c003254c c001791436c0 c0ae2998 0027 GPR04: 05a5 0002 GPR08: 3030303038303038 c0a2d4d0 c0aebeb8 c0af2998 GPR12: 24adbe22 cfffa800 c0001be0 GPR16: GPR20: c09ddf70 GPR24: c09e8d40 c0af2998 c0b1529c c00179143b40 GPR28: c001799b4000 c00179143c00 88008006 c0727ec8 NIP [c0032554] .fsl_pcie_check_link+0x104/0x150 LR [c003254c] .fsl_pcie_check_link+0xfc/0x150 Call Trace: [c001791436c0] [c003254c] .fsl_pcie_check_link+0xfc/0x150 (unreliab) [c00179143a30] [c00325d4] .fsl_indirect_read_config+0x34/0xb0 [c00179143ad0] [c02c7ee8] .pci_bus_read_config_byte+0x88/0xd0 [c00179143b90] [c09c0528] .pci_apply_final_quirks+0x9c/0x18c [c00179143c40] [c000142c] .do_one_initcall+0x5c/0x1f0 [c00179143cf0] [c09a0bb4] .kernel_init_freeable+0x180/0x264 [c00179143db0] [c0001bfc] .kernel_init+0x1c/0x420 [c00179143e30] [c8b4] .ret_from_kernel_thread+0x64/0xb0 Instruction dump: 6000 4ba0 ebc301d0 3fe2ffc4 3c62ffe0 3bff5530 38638a78 7fe4fb78 7fc5f378 486ea77d 6000 7c0004ac 801e0f14 0c00 4c00012c 3c62ffe0 ---[ end trace f841fbc03c9d2e1b ]--- Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b Rebooting in 180 seconds.. Signed-off-by: Yuanquan Chen yuanquan.c...@freescale.com Signed-off-by: Roy Zang tie-fei.z...@freescale.com --- based on Kumar's next branch. tested on P3041 and T4240. Please ignore this patch, I will send a v2 version. Thanks. Roy Ok, did you see this patch: http://patchwork.ozlabs.org/patch/236293/ - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/2] enable the coreint for the mpc85xx 64bit boards
On Apr 10, 2013, at 8:32 PM, Kevin Hao wrote: Hi, With the rework of the lazy EE, it seems that 64bit kernel works pretty well on mpc85xx 64bit boards with lazy EE enabled. So this patch series tries to enable the coreint for these boards by default. This passed the ltp test on a t4240qds board and is based on Kumar's next branch. --- Kevin Hao (2): powerpc/irq: remove the unneeded flag PACA_IRQ_EE_EDGE powerpc/85xx: enable coreint for all the 64bit boards arch/powerpc/include/asm/hw_irq.h | 1 - arch/powerpc/kernel/exceptions-64e.S| 1 - arch/powerpc/kernel/irq.c | 8 arch/powerpc/platforms/85xx/p5020_ds.c | 5 - arch/powerpc/platforms/85xx/p5040_ds.c | 5 - arch/powerpc/platforms/85xx/t4240_qds.c | 5 - 6 files changed, 25 deletions(-) Scott, I'd appreciate your review and ack on this change. thanks - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/crypto: removed qoriq-sec4.1-0.dtsi.
On Apr 10, 2013, at 10:43 PM, Vakul Garg wrote: Removing qoriq-sec4.1-0.dtsi as it is not used by any soc anymore. Signed-off-by: Vakul Garg va...@freescale.com --- arch/powerpc/boot/dts/fsl/qoriq-sec4.1-0.dtsi | 109 - 1 files changed, 0 insertions(+), 109 deletions(-) delete mode 100644 arch/powerpc/boot/dts/fsl/qoriq-sec4.1-0.dtsi applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv2] powerpc/crypto: Add property for 'era' in SEC dts crypto node
On Apr 10, 2013, at 10:45 PM, Vakul Garg wrote: The crypto node now contains a new property 'fsl,sec-era'. This is required so that applications can retrieve era info without having to be able to read SEC's register space. Signed-off-by: Vakul Garg va...@freescale.com --- Changelog: v2: Added era in p1023si-post.dtsi as per Kim's comments. arch/powerpc/boot/dts/fsl/p1023si-post.dtsi |1 + arch/powerpc/boot/dts/fsl/pq3-sec4.4-0.dtsi |1 + arch/powerpc/boot/dts/fsl/qoriq-sec4.0-0.dtsi |1 + arch/powerpc/boot/dts/fsl/qoriq-sec4.2-0.dtsi |1 + arch/powerpc/boot/dts/fsl/qoriq-sec5.0-0.dtsi |1 + arch/powerpc/boot/dts/fsl/qoriq-sec5.2-0.dtsi |1 + arch/powerpc/boot/dts/fsl/qoriq-sec5.3-0.dtsi |1 + 7 files changed, 7 insertions(+), 0 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: enable Silicon image 3132 PCIe to SATA controller
On Apr 10, 2013, at 5:40 PM, Scott Wood wrote: From: Roy ZANG tie-fei.z...@freescale.com Some 85xx board, for example, P1020RDB-PC has on board silicon image PCIe to SATA controller and when booting up, the filesystem will auto mount to the SATA disk. So enable silicon image 3132 pcie to sata controller by default Signed-off-by: Roy Zang tie-fei.z...@freescale.com Signed-off-by: Scott Wood scottw...@freescale.com --- arch/powerpc/configs/mpc85xx_defconfig |1 + arch/powerpc/configs/mpc85xx_smp_defconfig |1 + 2 files changed, 2 insertions(+) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: Fix MPC8536DS 36-bit device tree
On Apr 10, 2013, at 4:58 PM, Kim Phillips wrote: From: Kumar Gala ga...@kernel.crashing.org The localbus node should be in at 0xfffe05000 not 0xffe05000. Also fixed the names of the localbus and pci nodes to reflect the addresses they are actually at. Signed-off-by: Kumar Gala ga...@kernel.crashing.org Signed-off-by: Kim Phillips kim.phill...@freescale.com --- note: this upstream submission extended to fix pci1. arch/powerpc/boot/dts/mpc8536ds_36b.dts | 6 +++--- 1 file changed, 3 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 V6] powerpc/85xx: Add machine check handler to fix PCIe erratum on mpc85xx
On Apr 11, 2013, at 3:36 AM, Jia Hongtao wrote:
A PCIe erratum of mpc85xx may causes a core hang when a link of PCIe
goes down. when the link goes down, Non-posted transactions issued
via the ATMU requiring completion result in an instruction stall.
At the same time a machine-check exception is generated to the core
to allow further processing by the handler. We implements the handler
which skips the instruction caused the stall.
This patch depends on patch:
powerpc/85xx: Add platform_device declaration to fsl_pci.h
Signed-off-by: Zhao Chenhui b35...@freescale.com
Signed-off-by: Li Yang le...@freescale.com
Signed-off-by: Liu Shuo soniccat@gmail.com
Signed-off-by: Jia Hongtao hongtao@freescale.com
---
V5:
* Move OP and XOP defines to a new header file: asm/ppc-disassemble.h
* Add X UX BRX variant of load instruction emulation
* Remove A variant of load instruction emulation
V4:
* Fill rd with all-Fs if the skipped instruction is load and emulate the
instruction.
* Let KVM/QEMU deal with the exception if the machine check comes from KVM.
arch/powerpc/include/asm/ppc-disassemble.h | 31 +++
arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
arch/powerpc/kernel/traps.c| 3 +
arch/powerpc/sysdev/fsl_pci.c | 140 +
arch/powerpc/sysdev/fsl_pci.h | 6 ++
5 files changed, 181 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/include/asm/ppc-disassemble.h
diff --git a/arch/powerpc/include/asm/ppc-disassemble.h
b/arch/powerpc/include/asm/ppc-disassemble.h
new file mode 100644
index 000..f9782b8
--- /dev/null
+++ b/arch/powerpc/include/asm/ppc-disassemble.h
@@ -0,0 +1,31 @@
+/*
+ * Copyright 2012-2013 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.
+ *
+ * provides opcode and xopcode images for use by emulating
+ * instructions
+ */
+#ifndef _ASM_POWERPC_PPC_DISASSEMBLE_H
+#define _ASM_POWERPC_PPC_DISASSEMBLE_H
+
This should really just be in asm/ppc-opcode.h
+#define OP_LWZ 32
+#define OP_LWZU 33
+#define OP_LBZ 34
+#define OP_LBZU 35
+#define OP_LHZ 40
+#define OP_LHZU 41
+
+#define OP_31_XOP_LWZX 23
+#define OP_31_XOP_LWZUX 55
+#define OP_31_XOP_LBZX 87
+#define OP_31_XOP_LBZUX 119
+#define OP_31_XOP_LHZX 279
+#define OP_31_XOP_LHZUX 311
+#define OP_31_XOP_LWBRX 534
+#define OP_31_XOP_LHBRX 790
+
Also, submit a patch to extract these from existing code so we stop duplicating
them everywhere.
+#endif
diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index dcd8819..f1bde90 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -66,7 +66,7 @@ _GLOBAL(__setup_cpu_e500v2)
bl __e500_icache_setup
bl __e500_dcache_setup
bl __setup_e500_ivors
-#ifdef CONFIG_FSL_RIO
+#if defined(CONFIG_FSL_RIO) || defined(CONFIG_FSL_PCI)
/* Ensure that RFXE is set */
mfspr r3,SPRN_HID1
orisr3,r3,HID1_RFXE@h
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index a008cf5..dd275a4 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -59,6 +59,7 @@
#include asm/fadump.h
#include asm/switch_to.h
#include asm/debug.h
+#include sysdev/fsl_pci.h
#if defined(CONFIG_DEBUGGER) || defined(CONFIG_KEXEC)
int (*__debugger)(struct pt_regs *regs) __read_mostly;
@@ -556,6 +557,8 @@ int machine_check_e500(struct pt_regs *regs)
if (reason MCSR_BUS_RBERR) {
if (fsl_rio_mcheck_exception(regs))
return 1;
+ if (fsl_pci_mcheck_exception(regs))
+ return 1;
}
printk(Machine check in kernel mode.\n);
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 682084d..aaa54c5 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -26,11 +26,15 @@
#include linux/memblock.h
#include linux/log2.h
#include linux/slab.h
+#include linux/uaccess.h
#include asm/io.h
#include asm/prom.h
#include asm/pci-bridge.h
+#include asm/ppc-pci.h
what are you pulling in from ppc-pci.h?
#include asm/machdep.h
+#include asm/disassemble.h
+#include asm/ppc-disassemble.h
#include sysdev/fsl_soc.h
#include sysdev/fsl_pci.h
@@ -826,6 +830,142 @@ u64 fsl_pci_immrbar_base(struct pci_controller *hose)
return 0;
}
+#ifdef CONFIG_E500
+static int mcheck_handle_load(struct pt_regs *regs, u32 inst)
+{
+ unsigned int rd, ra, rb, d;
+
+ rd = get_rt(inst);
+ ra = get_ra(inst);
+ rb = get_rb(inst);
+ d = get_d(inst);
Re: recommended method of netbooting kernel/dtb in u-boot?
On Apr 11, 2013, at 10:44 AM, Chris Friesen wrote: Hi all, We've got a powerpc system that uses u-boot. In our environment on bootup u-boot does a DHCP to get networking info, then uses TFTP to get the kernel, which then does DHCP again and NFS-mounts the initial root filesystem. What's the standard practice for this sort of thing when using device tree blobs? Do most people use multi-file images or do they TFTP scripts to load and execute separate kernel/dtb files? For multi-part images is there an in-kernel way of generating a file containing a kernel and dtb combined? I saw a patch proposed in 2008 to add a uImage.dt build target but it was shot down because it used the legacy multi-file format. Is there an equivalent build target that uses the FIT format? We've normally just done multiple tftp fetches and one grabs dtb and one grabs kernel. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/5 v11] powerpc: Add iommu domain pointer to device archdata
On Mar 28, 2013, at 2:53 PM, Varun Sethi wrote: Add an iommu domain pointer to device (powerpc) archdata. Devices are attached to iommu domains and this pointer provides a mechanism to correlate between a device and the associated iommu domain. This field is set when a device is attached to a domain. Signed-off-by: Varun Sethi varun.se...@freescale.com --- - no change in v11. - no change in v10. - Added CONFIG_IOMMU_API in v9. arch/powerpc/include/asm/device.h |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) Acked-by: Kumar Gala ga...@kernel.crashing.org - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
