Re: gdb with powerpc
On 08/11/2015 12:50 PM, Ran Shalit wrote: Hello, I would like to ask if anyone tried remote debugging with gdb/gdbserver on powerpc. [snip] ^ As an alternative, Is anyone familiar with binary package with gdb/gdbserver for powerpc used with x86 host ? I use the powerpc toolchain built using the Yocto Project recipes, and this includes gdb and gdbserver (if you include the gdb recipe ). I can run gdb remotely and on my target ( both 32-bit and 64-bit targets ). They also have pre-built toolchains that might include gdb, but I don't use them. Best Regards, Ran ___ 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/rcpm: add RCPM driver
On 06/16/2015 05:26 AM, yuantian.t...@freescale.com wrote:
From: Tang Yuantian
There is a RCPM (Run Control/Power Management) in Freescale QorIQ
series processors. The device performs tasks associated with device
run control and power management.
The driver implements some features: mask/unmask irq, enter/exit low
power states, freeze time base, etc.
Signed-off-by: Chenhui Zhao
Signed-off-by: Tang Yuantian
---
v3:
- added static and __init modifier to fsl_rcpm_init
v2:
- fix code style issues
- refine compatible string match part
Documentation/devicetree/bindings/soc/fsl/rcpm.txt | 22 ++
arch/powerpc/include/asm/fsl_guts.h| 105 +++
arch/powerpc/include/asm/fsl_pm.h | 48 +++
arch/powerpc/platforms/85xx/Kconfig| 1 +
arch/powerpc/sysdev/Kconfig| 5 +
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/fsl_rcpm.c | 338 +
7 files changed, 520 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/fsl/rcpm.txt
create mode 100644 arch/powerpc/include/asm/fsl_pm.h
create mode 100644 arch/powerpc/sysdev/fsl_rcpm.c
diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
new file mode 100644
index 000..5318999
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
@@ -0,0 +1,22 @@
+* Run Control and Power Management
+
+The RCPM performs all device-level tasks associated with device run control
+and power management.
+
+Required properites:
+ - reg : Offset and length of the register set of RCPM block.
+ - compatible : Specifies the compatibility list for the RCPM. The type
+should be string, such as "fsl,qoriq-rcpm-1.0", "fsl,qoriq-rcpm-2.0".
I just checked both my T1040 RM and datasheet, and I didn't see mention
of the RCPM version that's used ( I assume it's 2.0 ). Is there a
general rule for which SoCs have which version? If so, perhaps you'll
want to include it here along with your examples.
+
+Example:
+The RCPM node for T4240:
+ rcpm: global-utilities@e2000 {
+ compatible = "fsl,t4240-rcpm", "fsl,qoriq-rcpm-2.0";
+ reg = <0xe2000 0x1000>;
+ };
+
+The RCPM node for P4080:
+ rcpm: global-utilities@e2000 {
+ compatible = "fsl,qoriq-rcpm-1.0";
+ reg = <0xe2000 0x1000>;
+ };
-- cut ---
diff --git a/arch/powerpc/include/asm/fsl_pm.h
b/arch/powerpc/include/asm/fsl_pm.h
new file mode 100644
index 000..4b09f09
--- /dev/null
+++ b/arch/powerpc/include/asm/fsl_pm.h
@@ -0,0 +1,48 @@
+/*
+ * Support Power Management
+ *
+ * Copyright 2014-2015 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.
+ */
+#ifndef __PPC_FSL_PM_H
+#define __PPC_FSL_PM_H
+#ifdef __KERNEL__
+
+#define E500_PM_PH10 1
+#define E500_PM_PH15 2
+#define E500_PM_PH20 3
+#define E500_PM_PH30 4
+#define E500_PM_DOZE E500_PM_PH10
+#define E500_PM_NAPE500_PM_PH15
Are you using "E500" in your labels for historical reasons? I can use
this driver with E5500 and E6500 cores, right? However, maybe I'm
mistaken since some of your states don't seem to map to my E5500 / T1040
(e.g., my RCPM doesn't seem to support PH20 or PH30, but I do have LPM10
and LPM35, which I don't think your driver supports). My RM states that
LPM35 is a newer PM state, so maybe this is future work to be done?
+
+#define PLAT_PM_SLEEP 20
+#define PLAT_PM_LPM20 30
+
+#define FSL_PM_SLEEP (1 << 0)
+#define FSL_PM_DEEP_SLEEP (1 << 1)
I don't see where you use FSL_PM_DEEP_SLEEP, and I'm wondering if this
was provisioned for LPM35, which is documented to be a deep sleep mode.
+
+struct fsl_pm_ops {
+ /* mask pending interrupts to the RCPM from MPIC */
+ void (*irq_mask)(int cpu);
+
+ /* unmask pending interrupts to the RCPM from MPIC */
+ void (*irq_unmask)(int cpu);
+ void (*cpu_enter_state)(int cpu, int state);
+ void (*cpu_exit_state)(int cpu, int state);
+ int (*plat_enter_sleep)(void);
+ void (*freeze_time_base)(bool freeze);
+
+ /* keep the power of IP blocks during sleep/deep sleep */
+ void (*set_ip_power)(bool enable, u32 *mask);
+
+ /* get platform supported power management modes */
+ unsigned int (*get_pm_modes)(void);
+};
+
+extern const struct fsl_pm_ops *qoriq_pm_ops;
+#endif /* __KERNEL__ */
+#endif /* __PPC_FSL_PM_H */
-- cut ---
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 08/12] fsl/fman: Add Frame Manager support
On 06/10/2015 11:21 AM, Madalin Bucur wrote:
From: Igal Liberman
Add Frame Manger Driver support.
This patch adds The FMan configuration, initialization and
runtime control routines.
Signed-off-by: Igal Liberman
---
drivers/net/ethernet/freescale/fman/Kconfig| 37 +
drivers/net/ethernet/freescale/fman/Makefile |2 +-
drivers/net/ethernet/freescale/fman/fm.c | 1478
drivers/net/ethernet/freescale/fman/fm.h | 404 ++
drivers/net/ethernet/freescale/fman/fm_common.h| 367 +
drivers/net/ethernet/freescale/fman/fm_drv.c | 827 +++
drivers/net/ethernet/freescale/fman/fm_drv.h | 123 ++
drivers/net/ethernet/freescale/fman/inc/enet_ext.h | 199 +++
drivers/net/ethernet/freescale/fman/inc/fm_ext.h | 453 ++
.../net/ethernet/freescale/fman/inc/fsl_fman_drv.h | 94 ++
drivers/net/ethernet/freescale/fman/inc/net_ext.h | 534 +++
drivers/net/ethernet/freescale/fman/inc/service.h | 90 ++
12 files changed, 4607 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/ethernet/freescale/fman/fm.c
create mode 100644 drivers/net/ethernet/freescale/fman/fm.h
create mode 100644 drivers/net/ethernet/freescale/fman/fm_common.h
create mode 100644 drivers/net/ethernet/freescale/fman/fm_drv.c
create mode 100644 drivers/net/ethernet/freescale/fman/fm_drv.h
create mode 100644 drivers/net/ethernet/freescale/fman/inc/enet_ext.h
create mode 100644 drivers/net/ethernet/freescale/fman/inc/fm_ext.h
create mode 100644 drivers/net/ethernet/freescale/fman/inc/fsl_fman_drv.h
create mode 100644 drivers/net/ethernet/freescale/fman/inc/net_ext.h
create mode 100644 drivers/net/ethernet/freescale/fman/inc/service.h
-- cut ---
+
+#endif /* __FM_H */
diff --git a/drivers/net/ethernet/freescale/fman/fm_common.h
b/drivers/net/ethernet/freescale/fman/fm_common.h
new file mode 100644
index 000..125c057
--- /dev/null
+++ b/drivers/net/ethernet/freescale/fman/fm_common.h
@@ -0,0 +1,367 @@
+/*
+ * 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.
+ */
+
+/* File fm_common.h
+ * Description FM internal structures and definitions.
+ */
+#ifndef __FM_COMMON_H
+#define __FM_COMMON_H
+
+#include "service.h"
+#include "fm_ext.h"
+
+/* Uniqe defines */
Unique instead of Uniqe?
+#define FM_QMI_NO_ECC_EXCEPTIONS /* P1 */
+#define FM_CSI_CFED_LIMIT /* P1 */
+#define FM_PEDANTIC_DMA/* P1 */
+#define FM_QMI_NO_DEQ_OPTIONS_SUPPORT /* P1 */
+#define FM_HAS_TOTAL_DMAS /* P1-P5 */
+#define FM_DEQ_PIPELINE_PARAMS_FOR_OP /* P1, T/B */
+#define FM_NO_DISPATCH_RAM_ECC /* P2-P5 */
+#define FM_NO_WATCHDOG /* P4 */
+#define FM_NO_TNUM_AGING /* P2-P5 */
+#define FM_NO_BACKUP_POOLS /* P2-P5 */
+#define FM_NO_OP_OBSERVED_POOLS/* P2-P5, T/B */
+#define FM_NO_ADVANCED_RATE_LIMITER/* P2-P5 */
+#define FM_OP_OPEN_DMA_MIN_LIMIT /* T/B */
+#define FM_NO_RESTRICT_ON_ACCESS_RSRC /* T/B */
+#define FM_FRAME_END_PARAMS_FOR_OP
mainline vs. QorIQ SDK for production with FSL SoCs...
Hi, Please correct me if I'm mistaken and / or provide your own insight on the following: I'm under the impression that it's better to develop with the mainline (eventually freezing for production on a stable release / branch ) than use the QorIQ SDK if the needed code (e.g., DPAA drivers) has been upstreamed and is included in the mainline. It's my perception that it is preferable to develop with the mainline because there are more active open-source developers working with this code and actively reviewing / testing it than with the SDK and backported or stale drivers (e.g., WiFi) I'm sure that there are at least dozens of FSL developers working with the SDK on a daily basis, but this is behind the FSL firewall, and open source developers, such as myself, don't have access to FSL patches except for every six months when a new SDK is released. It seems to me that there will be a much better chance of hearing about new bugs from others and getting help debugging problems if we're using the mainline. But again, the caveat is that the necessary kernel technology for the product is included in the mainline ( SDK contains some source for drivers and libraries only available under an FSL EULA ). FYI - at this point, we're testing & developing with both the SDK 3.12 kernel and the mainline kernel, but it would be nice to drop the former. Lastly, for something like the p1010, we have found it to stable with the mainline for quite some time. Thank you, Bob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On 04/16/2015 12:44 AM, Bob Cochran wrote: On 04/09/2015 06:31 PM, Scott Wood wrote: On Thu, 2015-04-09 at 16:52 -0500, Pan Lijun-B44306 wrote: Hi Maintainers, We have a proposal for writing the defconfigs for freescale's powperpc platforms in a new way. Can you take a look and provide some feedback? You know currently we have mpc85xx_defconfig, corenet32_defconfig, bsc913x_defconfig, *fman*_defconfig, etc. We are going to extract some common parts from the existing defconfigs, and name it, say, fsl_basic_defconfig. Then, we could create some defconfigs targeting specific features or specific platforms. Say, features specific: kvm_defconfig, fman_defconfig, etc. Platforms specific: p1_defconfig, p2_defcongfig, p4_defconfig, t1_defconfig, t2_defconfig, t2_defconfig, b4_defconfig, etc When we want to make a kernel image for p1 platform, Using the following steps: make ./scripts/kconfig/merge_config.sh arch/powerpc/configs/fsl_basic_config p1_defconfig make What do you think of this new approach? Will you accept this approach? I'm OK with a merge_config approach. I'm not OK with having separate builds for p1/p2/p4/t1/t2/b4. -Scott As you probably know, Freescale makes use of the Yocto Project build system for its SDK and submits patches to the SDK at a public meta-fsl-ppc repo at http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/ I have seen some kernel related patches in the past come across the Yocto Project site that made use of the Yocto Project kernel tools, which includes a process for maintaining kernel configuration fragments. Here is a link to a patch from a Freescale developer introducing Yocto kernel tool support (description files & configuration fragments) to the meta-fsl-ppc repo (FSL QorIQ SDK on Yocto). https://lists.yoctoproject.org/pipermail/meta-freescale/2014-October/010890.html It sounds like the requirements you have could be met with Yocto's existing process. I was hoping to see Freescale continue to move in the direction of using the Yocto kernel tools rather than roll its own solution. The Yocto kernel tools make use of description files (*.scc) and configuration fragments (*.cfg). Here is a link to the latest stable Yocto kernel development manual: http://www.yoctoproject.org/docs/1.7.1/kernel-dev/kernel-dev.html Bob ___ 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On 04/09/2015 06:31 PM, Scott Wood wrote: On Thu, 2015-04-09 at 16:52 -0500, Pan Lijun-B44306 wrote: Hi Maintainers, We have a proposal for writing the defconfigs for freescale's powperpc platforms in a new way. Can you take a look and provide some feedback? You know currently we have mpc85xx_defconfig, corenet32_defconfig, bsc913x_defconfig, *fman*_defconfig, etc. We are going to extract some common parts from the existing defconfigs, and name it, say, fsl_basic_defconfig. Then, we could create some defconfigs targeting specific features or specific platforms. Say, features specific: kvm_defconfig, fman_defconfig, etc. Platforms specific: p1_defconfig, p2_defcongfig, p4_defconfig, t1_defconfig, t2_defconfig, t2_defconfig, b4_defconfig, etc When we want to make a kernel image for p1 platform, Using the following steps: make ./scripts/kconfig/merge_config.sh arch/powerpc/configs/fsl_basic_config p1_defconfig make What do you think of this new approach? Will you accept this approach? I'm OK with a merge_config approach. I'm not OK with having separate builds for p1/p2/p4/t1/t2/b4. -Scott As you probably know, Freescale makes use of the Yocto Project build system for its SDK and submits patches to the SDK at a public meta-fsl-ppc repo at http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/ I have seen some kernel related patches in the past come across the Yocto Project site that made use of the Yocto Project kernel tools, which includes a process for maintaining kernel configuration fragments. It sounds like the requirements you have could be met with Yocto's existing process. I was hoping to see Freescale continue to move in the direction of using the Yocto kernel tools rather than roll its own solution. The Yocto kernel tools make use of description files (*.scc) and configuration fragments (*.cfg). Here is a link to the latest stable Yocto kernel development manual: http://www.yoctoproject.org/docs/1.7.1/kernel-dev/kernel-dev.html Bob ___ 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,v2,02/12] soc/fman: Add the FMan FLIB
On 04/01/2015 07:36 AM, Igal.Liberman wrote: From: Igal Liberman The FMan FLib provides the basic API used by the FMan drivers to configure and control the FMan hardware. Signed-off-by: Igal Liberman --- drivers/soc/fsl/Kconfig |2 + drivers/soc/fsl/Makefile |2 + drivers/soc/fsl/fman/Kconfig |7 + drivers/soc/fsl/fman/Makefile |5 + drivers/soc/fsl/fman/fman.c | 978 + 5 files changed, 994 insertions(+) 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/fsl/Kconfig b/drivers/soc/fsl/Kconfig index 291123a..2981306 100644 --- a/drivers/soc/fsl/Kconfig +++ b/drivers/soc/fsl/Kconfig I need some help putting together the DPAA patches. On 3/11, there was a patch with the subject "[v2,02/11] soc/fman: Add the FMan FLIB", which is basically the same subject as this one. In the 3/11 patch, you create /drivers/soc/fsl/Kconfig and Makefile. In this patch, Kconfig and Makefile already exist. So, please tell me the patch that should be applied before this one to pick up both Kconfig and Makefile. Should this patch have been called v3? There was a v1 on 3/5 and a v2 on 3/11 that had the subject "soc/fman Add the FMan FLIB". Excluding device tree patches, I think there are currently three non-superseded patch sets submitted for the DPAA: 1) 4/1/15: [PATCH RFC 00/10] introduce DPAA Ethernet driver, madalin.bu...@freescale.com [SHOULD HAVE BEEN TITLED V2?] 2) 4/1/15: [RFC,v2,00/12] Freescale DPAA FMan, igal.liber...@freescale.com [SHOULD HAVE BEEN TITLED V3?] 3) 3/9/15: [RFC v3 00/10] Freescale DPAA B/QMan drivers, emilian.me...@freescale.com I'm looking forward to putting together all the patches and trying to build it and eventually test it. Thank you, Bob @@ -189,4 +189,6 @@ config FSL_QMAN_INIT_TIMEOUT endif # FSL_QMAN +source "drivers/soc/fsl/fman/Kconfig" + endif # FSL_DPA diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile index cce1f70..b2f76e9 100644 --- a/drivers/soc/fsl/Makefile +++ b/drivers/soc/fsl/Makefile @@ -18,3 +18,5 @@ qman-test-y= qman_test.o qman-test-$(CONFIG_FSL_QMAN_TEST_API) += qman_test_api.o qman-test-$(CONFIG_FSL_QMAN_TEST_STASH) += qman_test_stash.o obj-$(CONFIG_FSL_QMAN_DEBUGFS)+= qman-debugfs.o + +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..8aeae29 --- /dev/null +++ b/drivers/soc/fsl/fman/Kconfig @@ -0,0 +1,7 @@ +config FSL_FMAN + bool "FMan support" + depends on FSL_SOC || COMPILE_TEST + default n + help + Freescale Data-Path Acceleration Architecture Frame Manager + (FMan) support [snip] ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC 00/10] Freescale DPAA B/QMan drivers
On 02/05/2015 10:52 AM, Emil Medve wrote: Hello Bob, On 02/05/2015 09:48 AM, Bob Cochran wrote: On 02/04/2015 09:48 AM, Emil Medve wrote: Hello, This is the first attempt to publish the Freescale DPAA B/QMan drivers. They are not to be applied yet. 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 Hi Emil, I had thought to try to apply these patches and build it, but I won't get very far using it without FMAN (on my t1040). I searched through the mail archives and didn't find FMAN patches other than for the device tree. I also don't see it in the mainline tree. If FMAN patches have already been submitted, please point me to it. If not, then please let me know when we will see code to support FMAN. Let me inquire with the FMan guy here. I'll get back to you on this, however, don't hold your breath. There might be some weeks before the FMan driver will hit the e-mail lists Hi Emil, Were you able to obtain information on when we'll see the FMAN driver patches submitted? I would like to be able to work with FSL DPAA on mainline. Thanks, Bob Also, is it your intention for the same QMAN/BMAN drivers to be used with both FMAN and the LS AIOP? These drivers (with some upcoming updates) are expected to be use on all QorIQ and LS1 devices. The programming model for LS2 (which includes the AIOP and friends) seems to have a different programming model and these drivers will not be usable there Cheers, Thank you, Bob 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 arch/powerpc/Kconfig| 33 +- arch/powerpc/platforms/85xx/Kconfig | 11 +- arch/powerpc/platforms/85xx/corenet_generic.c | 26 +- arch/powerpc/platforms/85xx/p1023_rdb.c | 26 +- drivers/staging/Kconfig |4 +- drivers/staging/Makefile|1 + drivers/staging/fsl_qbman/Kconfig | 188 ++ drivers/staging/fsl_qbman/Makefile | 23 + drivers/staging/fsl_qbman/bman_config.c | 611 ++ drivers/staging/fsl_qbman/bman_debugfs.c| 119 + drivers/staging/fsl_qbman/bman_driver.c | 373 drivers/staging/fsl_qbman/bman_high.c | 1055 + drivers/staging/fsl_qbman/bman_low.h| 524 + drivers/staging/fsl_qbman/bman_private.h| 149 ++ drivers/staging/fsl_qbman/bman_test.c | 56 + drivers/staging/fsl_qbman/bman_test.h | 44 + drivers/staging/fsl_qbman/bman_test_high.c | 181 ++ drivers/staging/fsl_qbman/bman_test_thresh.c| 196 ++ drivers/staging/fsl_qbman/dpa_alloc.c | 573 + drivers/staging/fsl_qbman/dpa_sys.h | 294 +++ drivers/staging/fsl_qbman/qbman_driver.c| 85 + drivers/staging/fsl_qbman/qman_config.c | 991 + drivers/staging/fsl_qbman/qman_debugfs.c| 1326 drivers/staging/fsl_qbman/qman_driver.c | 548 + drivers/staging/fsl_qbman/qman_high.c | 2624 +++ drivers/staging/fsl_qbman/qman_low.h| 1302 +++ drivers/staging/fsl_qbman/qman_private.h| 283 +++ drivers/staging/fsl_qbman/qman_test.c | 57 + drivers/staging/fsl_qbman/qman_test.h | 43 + drivers/staging/fsl_qbman/qman_test_high.c | 213 ++ drivers/staging/fsl_qbman/qman_test_hotpotato.c | 497 + drivers/staging/fsl_qbman/qman_utility.c| 129 ++ include/linux/fsl_bman.h| 517 + include/linux/fsl_qman.h| 1955 + 34 files changed, 15032 insertions(+), 25 deletions(-) create mode 100644 drivers/staging/fsl_qbman/Kconfig create mode 100644 drivers/staging/fsl_qbman/Makefile create mode 100644 drivers/staging/fsl_qbman/bman_config.c create mode 100644 drivers/staging/fsl_qbman/bman_debugfs.c create mode 100644 drivers/staging/fsl_qbman/bman_driver.c create mode 100644 drivers/staging/fsl_qbman/bman_high.c create mode 100644 drivers/staging/fsl_qbman/bman_low.h create mode 100644 drivers/staging/fsl_qbman/bman_private.h create mode 100644 drivers/staging/fsl_qbman/bman_test.c create mode 10
Re: [RFC 00/10] Freescale DPAA B/QMan drivers
On 02/04/2015 09:48 AM, Emil Medve wrote: Hello, This is the first attempt to publish the Freescale DPAA B/QMan drivers. They are not to be applied yet. 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 Hi Emil, I had thought to try to apply these patches and build it, but I won't get very far using it without FMAN (on my t1040). I searched through the mail archives and didn't find FMAN patches other than for the device tree. I also don't see it in the mainline tree. If FMAN patches have already been submitted, please point me to it. If not, then please let me know when we will see code to support FMAN. Also, is it your intention for the same QMAN/BMAN drivers to be used with both FMAN and the LS AIOP? Thank you, Bob 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 arch/powerpc/Kconfig| 33 +- arch/powerpc/platforms/85xx/Kconfig | 11 +- arch/powerpc/platforms/85xx/corenet_generic.c | 26 +- arch/powerpc/platforms/85xx/p1023_rdb.c | 26 +- drivers/staging/Kconfig |4 +- drivers/staging/Makefile|1 + drivers/staging/fsl_qbman/Kconfig | 188 ++ drivers/staging/fsl_qbman/Makefile | 23 + drivers/staging/fsl_qbman/bman_config.c | 611 ++ drivers/staging/fsl_qbman/bman_debugfs.c| 119 + drivers/staging/fsl_qbman/bman_driver.c | 373 drivers/staging/fsl_qbman/bman_high.c | 1055 + drivers/staging/fsl_qbman/bman_low.h| 524 + drivers/staging/fsl_qbman/bman_private.h| 149 ++ drivers/staging/fsl_qbman/bman_test.c | 56 + drivers/staging/fsl_qbman/bman_test.h | 44 + drivers/staging/fsl_qbman/bman_test_high.c | 181 ++ drivers/staging/fsl_qbman/bman_test_thresh.c| 196 ++ drivers/staging/fsl_qbman/dpa_alloc.c | 573 + drivers/staging/fsl_qbman/dpa_sys.h | 294 +++ drivers/staging/fsl_qbman/qbman_driver.c| 85 + drivers/staging/fsl_qbman/qman_config.c | 991 + drivers/staging/fsl_qbman/qman_debugfs.c| 1326 drivers/staging/fsl_qbman/qman_driver.c | 548 + drivers/staging/fsl_qbman/qman_high.c | 2624 +++ drivers/staging/fsl_qbman/qman_low.h| 1302 +++ drivers/staging/fsl_qbman/qman_private.h| 283 +++ drivers/staging/fsl_qbman/qman_test.c | 57 + drivers/staging/fsl_qbman/qman_test.h | 43 + drivers/staging/fsl_qbman/qman_test_high.c | 213 ++ drivers/staging/fsl_qbman/qman_test_hotpotato.c | 497 + drivers/staging/fsl_qbman/qman_utility.c| 129 ++ include/linux/fsl_bman.h| 517 + include/linux/fsl_qman.h| 1955 + 34 files changed, 15032 insertions(+), 25 deletions(-) create mode 100644 drivers/staging/fsl_qbman/Kconfig create mode 100644 drivers/staging/fsl_qbman/Makefile create mode 100644 drivers/staging/fsl_qbman/bman_config.c create mode 100644 drivers/staging/fsl_qbman/bman_debugfs.c create mode 100644 drivers/staging/fsl_qbman/bman_driver.c create mode 100644 drivers/staging/fsl_qbman/bman_high.c create mode 100644 drivers/staging/fsl_qbman/bman_low.h create mode 100644 drivers/staging/fsl_qbman/bman_private.h create mode 100644 drivers/staging/fsl_qbman/bman_test.c create mode 100644 drivers/staging/fsl_qbman/bman_test.h create mode 100644 drivers/staging/fsl_qbman/bman_test_high.c create mode 100644 drivers/staging/fsl_qbman/bman_test_thresh.c create mode 100644 drivers/staging/fsl_qbman/dpa_alloc.c create mode 100644 drivers/staging/fsl_qbman/dpa_sys.h create mode 100644 drivers/staging/fsl_qbman/qbman_driver.c create mode 100644 drivers/staging/fsl_qbman/qman_config.c create mode 100644 drivers/staging/fsl_qbman/qman_debugfs.c create mode 100644 drivers/staging/fsl_qbman/qman_driver.c create mode 100644 drivers/staging/fsl_qbman/qman_high.c create mode 100644 drivers/staging/fsl_qbman/qman_low.h create mode 100644 drivers/staging/fsl_qbman/qman_private.h create mode 100644 drivers/staging/fsl_qbman/qman_test.c create mode 100644 drivers/staging/fsl_q
Re: [PATCH][V2] Freescale Frame Manager Device Tree binding document
On 09/17/2014 07:08 AM, Igal.Liberman wrote: From: Igal Liberman The Frame Manager (FMan) combines the Ethernet network interfaces with packet distribution logic to provide intelligent distribution and queuing decisions for incoming traffic at line rate. This binding document describes Freescale's Frame Manager hardware attributes that are used by the Frame Manager driver for its basic initialization and configuration. Difference between [V1] and [V2]: Addressed all comments recieved from Scott in [V1] Signed-off-by: Igal Liberman Is there a reference (FMAN) dts file I can compare this against? I was reviewing this against my (combined) dts file for my t1040rdb built with either FSL's SDK1.6 or Yocto Project meta-fsl-ppc master branch, and I'm not finding a good match between the nodes / properties in my dts file and what you have here. For example, I don't find the required "clocks" or "fsl,qman-channel-range" properties under my node. I'm wondering if this document is trailing or leading the source in the latest published FSL SDK (1.6). And a minor nit pick: twice you write "bellow" where you should have "below" Thanks Bob --- .../devicetree/bindings/powerpc/fsl/fman.txt | 529 1 file changed, 529 insertions(+) create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/fman.txt diff --git a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt new file mode 100644 index 000..da8e5f2 --- /dev/null +++ b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt @@ -0,0 +1,529 @@ += +Freescale Frame Manager Device Bindings + +CONTENTS + - FMan Node + - FMan Port Node + - FMan MURAM Node + - FMan dTSEC/XGEC/mEMAC Node + - FMan IEEE 1588 Node + - Example + += +FMan Node + +DESCRIPTION + +Due to the fact that the FMan is an aggregation of sub-engines (ports, MACs, +etc.) the FMan node will have child nodes for each of them. + +PROPERTIES + +- compatible + Usage: required + Value type: + Definition: Must include "fsl,fman" + FMan version can be determined via FM_IP_REV_1 register in the + FMan block. The offset is 0xc4 from the beginning of the + Frame Processing Manager memory map (0xc3000 from the + beginning of the FMan node). + +- cell-index + Usage: required + Value type: + Definition: Specifies the index of the FMan unit. + + The cell-index value may be used by the SoC, to identify the + FMan unit in the SoC memory map. In the table bellow, + there's a description of the cell-index use in each SoC: + + - P1023: + register[bit] FMan unit cell-index + + DEVDISR[1] 1 0 + + - P2041, P3041, P4080 P5020, P5040: + register[bit] FMan unit cell-index + + DCFG_DEVDISR2[6]1 0 + DCFG_DEVDISR2[14] 2 1 + (Second FM available only in P4080 and P5040) + + - B4860, T1040, T2080, T4240: + register[bit] FMan unit cell-index + + DCFG_CCSR_DEVDISR2[24] 1 0 + DCFG_CCSR_DEVDISR2[25] 2 1 + (Second FM available only in T4240) + + DEVDISR, DCFG_DEVDISR2 and DCFG_CCSR_DEVDISR2 are located in + the specific SoC "Device Configuration/Pin Control" Memory + Map. + +- reg + Usage: required + Value type: + Definition: A standard property. Specifies the offset of the + following configuration registers: + - BMI configuration registers. + - QMI configuration registers. + - DMA configuration registers. + - FPM configuration registers. + - FMan controller configuration registers. + +- ranges + Usage: required + Value type: + Definition: A standard property. + +- clocks + Usage: required + Value type: + Definition: phandle for fman clock. + +- clock-names + usage: optional + Value type: + Definition: A standard property + +- interrupts + Us
Re: Pull request: scottwood/linux.git next
On 09/23/2014 01:45 AM, Scott Wood wrote: On Mon, 2014-09-22 at 23:52 -0400, Bob Cochran wrote: On 09/22/2014 06:21 PM, Scott Wood wrote: Highlights include DMA32 zone support (SATA, USB, etc now works on 64-bit FSL kernels), MSI changes, 8xx optimizations and cleanup, t104x board support, and PrPMC PCI enumeration. The following changes since commit 78eb9094ca08a40b8f9d3e113a2b88e0b7dbad1d: powerpc/t2080rdb: Add T2080RDB board support (2014-07-31 00:11:10 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next for you to fetch changes up to cb0446c1b625326682ec4f9d1dd10779433646bc: Revert "powerpc/fsl_msi: spread msi ints across different MSIRs" (2014-09-19 15:20:42 -0500) Aaron Sierra (2): fsl_ifc: Fix csor_ext position in fsl_ifc_regs powerpc: fsl_pci: Add forced PCI Agent enumeration LEROY Christophe (7): powerpc/8xx: Declare SPRG2 as a SCRATCH register powerpc/8xx: Use SCRATCH0 and SCRATCH1 also for TLB handlers powerpc/8xx: Remove loading of r10 at end of FixupDAR powerpc/8xx: Fix comment about DIRTY update powerpc/8xx: No need to save r10 and r3 when not calling FixupDAR powerpc/8xx: Optimize verification in FixupDAR powerpc/8xx: Duplicate two insns instead of branching Nikhil Badola (3): powerpc: configs: Add VFAT file-system configs powerpc: dts: t4240: Change T4240 USB controller version powerpc: dts: t208x: Change T208x USB controller version Priyanka Jain (2): powerpc/fsl-booke: Add initial T1040/T1042 RDB board support Hi Scott, I would like to try your next branch with my t1040rdb along with DPAA support / drivers. I don't see DPAA support in your repo. Can you point me to a DPAA patch set somewhere, or am I on my own to merge what I need from sdk or yocto? Unfortunately DPAA support has not yet been upstreamed, though it is being worked on. It's great to see you confirm this. Thank you. Can you share a time frame on when we'll see DPAA patches start showing up? I assume it will have FSL_USDPAA support stripped out? For now if you need DPAA with the latest kernel, you'll need to merge it yourself based on the SDK code. It also wouldn't hurt to let any sales/support contact you may have at Freescale know that this is important to you. -Scott ___ 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: Pull request: scottwood/linux.git next
On 09/22/2014 06:21 PM, Scott Wood wrote: Highlights include DMA32 zone support (SATA, USB, etc now works on 64-bit FSL kernels), MSI changes, 8xx optimizations and cleanup, t104x board support, and PrPMC PCI enumeration. The following changes since commit 78eb9094ca08a40b8f9d3e113a2b88e0b7dbad1d: powerpc/t2080rdb: Add T2080RDB board support (2014-07-31 00:11:10 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git next for you to fetch changes up to cb0446c1b625326682ec4f9d1dd10779433646bc: Revert "powerpc/fsl_msi: spread msi ints across different MSIRs" (2014-09-19 15:20:42 -0500) Aaron Sierra (2): fsl_ifc: Fix csor_ext position in fsl_ifc_regs powerpc: fsl_pci: Add forced PCI Agent enumeration LEROY Christophe (7): powerpc/8xx: Declare SPRG2 as a SCRATCH register powerpc/8xx: Use SCRATCH0 and SCRATCH1 also for TLB handlers powerpc/8xx: Remove loading of r10 at end of FixupDAR powerpc/8xx: Fix comment about DIRTY update powerpc/8xx: No need to save r10 and r3 when not calling FixupDAR powerpc/8xx: Optimize verification in FixupDAR powerpc/8xx: Duplicate two insns instead of branching Nikhil Badola (3): powerpc: configs: Add VFAT file-system configs powerpc: dts: t4240: Change T4240 USB controller version powerpc: dts: t208x: Change T208x USB controller version Priyanka Jain (2): powerpc/fsl-booke: Add initial T1040/T1042 RDB board support Hi Scott, I would like to try your next branch with my t1040rdb along with DPAA support / drivers. I don't see DPAA support in your repo. Can you point me to a DPAA patch set somewhere, or am I on my own to merge what I need from sdk or yocto? Thanks, Bob powerpc/fsl-booke: Add initial T1042RDB_PI board support Scott Wood (7): powerpc: Dynamic DMA zone limits powerpc/64: Honor swiotlb limit in coherent allocations powerpc/64: Limit ZONE_DMA32 to 4GiB in swiotlb_detect_4g() powerpc/fsl-pci: Limit ZONE_DMA32 to 2GiB on 64-bit platforms powerpc/85xx/defconfig: Remove duplicate CONFIG_RTC_DRV_DS1307 powerpc/mm: Use common paging_init() for NUMA Revert "powerpc/fsl_msi: spread msi ints across different MSIRs" Tudor Laurentiu (6): powerpc/fsl_msi: support vmpic msi with mpic 4.3 powerpc/fsl_msi: reorganize structs to improve clarity and flexibility powerpc/fsl_msi: change the irq handler from chained to normal powerpc/fsl_msi: show more meaningful names in /proc/interrupts powerpc/fsl_msi: spread msi ints across different MSIRs powerpc/fsl-booke64: add missing virtualization options in defconfig Documentation/devicetree/bindings/pci/fsl,pci.txt | 27 arch/powerpc/Kconfig | 4 + arch/powerpc/boot/dts/fsl/t2081si-post.dtsi | 4 +- arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 4 +- arch/powerpc/boot/dts/t1040rdb.dts| 48 +++ arch/powerpc/boot/dts/t1042rdb.dts| 48 +++ arch/powerpc/boot/dts/t1042rdb_pi.dts | 57 arch/powerpc/boot/dts/t104xrdb.dtsi | 156 ++ arch/powerpc/configs/corenet32_smp_defconfig | 2 + arch/powerpc/configs/corenet64_smp_defconfig | 46 ++- arch/powerpc/configs/mpc85xx_defconfig| 4 +- arch/powerpc/configs/mpc85xx_smp_defconfig| 4 +- arch/powerpc/configs/mpc86xx_defconfig| 3 + arch/powerpc/include/asm/pgtable.h| 3 + arch/powerpc/include/asm/reg.h| 3 +- arch/powerpc/kernel/dma-swiotlb.c | 8 +- arch/powerpc/kernel/dma.c | 33 + arch/powerpc/kernel/head_8xx.S| 150 - arch/powerpc/mm/mem.c | 68 +- arch/powerpc/mm/numa.c| 8 -- arch/powerpc/platforms/85xx/Kconfig | 2 +- arch/powerpc/platforms/85xx/corenet_generic.c | 14 ++ arch/powerpc/platforms/85xx/qemu_e500.c | 10 ++ arch/powerpc/sysdev/fsl_msi.c | 95 ++--- arch/powerpc/sysdev/fsl_msi.h | 4 +- arch/powerpc/sysdev/fsl_pci.c | 3 +- include/linux/fsl_ifc.h | 6 +- 27 files changed, 610 insertions(+), 204 deletions(-) create mode 100644 Documentation/devicetree/bindings/pci/fsl,pci.txt create mode 100644 arch/powerpc/boot/dts/t1040rdb.dts create mode 100644 arch/powerpc/boot/dts/t1042rdb.dts create mode 100644 arch/powerpc/boot/dts/t1042rdb_pi.dts create mode 100644 arch/powerpc/boot/dts/t104xrdb.dtsi ___ Linuxppc-dev mailing list Linuxppc-dev@lis
Re: [RFC] [PATCH] powerpc: Add MSR_DE to MSR_KERNEL
On 05/30/2012 03:43 AM, Joakim Tjernlund wrote: Emulators such as BDI2000 and CodeWarrior needs to have MSR_DE set in order to support break points. This adds MSR_DE for kernel space only. --- I have tested this briefly with BDI2000 on P2010(e500) and it works for me. I don't know if there are any bad side effects, therfore this RFC. arch/powerpc/include/asm/reg.h |2 +- arch/powerpc/include/asm/reg_booke.h |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) snip I believe that additional patches are required for CodeWarrior to work properly (e.g., assembly start up). I think the patches should come from Freescale. For whatever reason, they include them in their SDK, but haven't submitted them for inclusion in the mainline. As a developer on Freescale Power products, I would like to see Freescale offer up a CodeWarrior patch set, so I don't have to manage the patches myself when working outside the SDK (i.e., on a more recent kernel). ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MSR loses DE bit in 3.3, BDI2000 cant handle breakpoints?
On 05/29/2012 08:00 AM, Joakim Tjernlund wrote: I cannot make simple break points using BDI2000 work in 3.3, abatro suggests that it depends on MSR[DE] is cleared by the kernel. With the emulator I can see that MSR[DE] is off quite often by just stopping at random times and looking at MSR so it seems like the kernel is turning MSR[DE] off most of the time. Anyone else having success debugging 3.3 with BDI2000? This is on a P2010(E500/BOOKE) CPU. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev I debug using Freescale CodeWarrior and a USB tap, which also rely on MSR[DE] being set. I develop from the mainline & have a patch set that I just recently re-tweaked to support kernel debugging. If you want, I'll send you my set of patches for the kernel. They might be useful (not sure since I don't use BDI). ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2 V3] powerpc/85xx: Add P1024rdb dts support
On 02/10/2012 03:00 AM, b29...@freescale.com wrote:
From: Tang Yuantian
Signed-off-by: Jin Qing
Signed-off-by: Li Yang
Signed-off-by: Tang Yuantian
---
v3:
I'm curious how fsl_pq_mdio_probe returns successfully when probing the
phys on the first pass (mdio@24000). I don't have a P1024 to test with,
but I believe it has the same ETSEC configuration as the P1010 that I
work with.
Inside the fsl_pq_mdio_probe routine (fsl_pq_mdio.c), a successful
search of a tbi child node is required with a tbi->type of "tby-phy".
If it doesn't find this node, the probe routine will return an error of
EBUSY. The logic from the routine is provided below:
for_each_child_of_node(np, tbi) {
if (!strncmp(tbi->type, "tbi-phy", 8))
break;
}
if (tbi) {
const u32 *prop = of_get_property(tbi, "reg", NULL);
if (prop)
tbiaddr = *prop;
}
if (tbiaddr == -1) {
err = -EBUSY;
goto err_free_irqs;
} else {
out_be32(tbipa, tbiaddr);
}
If I look at the p1010rdb.dtsi file, I see that a tbi-phy child node was
added inside mdio@24000; however, I don't see this inside your
p1024rdb.dtsi.
On top of this, the current p1010rdb mdio@24000 node in p1024rdb.dtsi
doesn't yield a successful probe (as I reported on this mail list on
2/7/12).
So, it seems to me that a tbi child node needs to be added to your
mdio@24000 node similar to what was done with the p1010rdb,
but it also requires some additional tweaking or perhaps a fix inside
the fsl_pq_mdio_probe routine or of library (It's not clear to me how to
best produce a successful probe given the circumstances).
+
+ mdio@24000 {
+ phy0: ethernet-phy@0 {
+ interrupts =<3 1 0 0>;
+ reg =<0x0>;
+ };
+ phy1: ethernet-phy@1 {
+ interrupts =<2 1 0 0>;
+ reg =<0x1>;
+ };
+ phy2: ethernet-phy@2 {
+ interrupts =<1 1 0 0>;
+ reg =<0x2>;
+ };
+ };
+
+ mdio@25000 {
+ tbi0: tbi-phy@11 {
+ reg =<0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+
+ mdio@26000 {
+ tbi1: tbi-phy@11 {
+ reg =<0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+
+ ethernet@b {
+ phy-handle =<&phy2>;
+ phy-connection-type = "rgmii-id";
+ };
+
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Question about fsl_pq_mdio_probe and dts file for p1010rdb...
Hello,
Using the mainline kernel & p1010rdb.dts, fsl_pq_mdio_probe returns busy
on my P1010RDB when first probing the MDIO during kernel boot. On the
console, the error is reported as:
"fsl-pq_mdio: probe of ffe24000.mdio failed with error -16"
I have determined that the failure occurs in the
for_each_child_of_node() loop shown below, which is part of the
fsl_pq_mdio_probe routine. It turns out that tbi->type is always
although tbi->name will be "tbi-phy" when scanning the last child node (
I have also attached the relevant portion of the p1010rdb.dtsi file
below). Since tbi-type is never "tbi-phy", the "if (tbi)" statement is
always false, and err is subsequently set to EBUSY below.
Can someone please tell me whether this is an issue with the dts file,
the of library, or the probe function? Any direction on the right way
to patch this would be appreciated.
// from fsl_pq_mdio.c:
for_each_child_of_node(np, tbi) {
if (!strncmp(tbi->type, "tbi-phy", 8))
break;
}
if (tbi) {
const u32 *prop = of_get_property(tbi, "reg", NULL);
if (prop)
tbiaddr = *prop;
}
if (tbiaddr == -1) {
err = -EBUSY;
goto err_free_irqs;
} else {
out_be32(tbipa, tbiaddr);
}
// from p1010rdb.dtsi:
mdio@24000 {
phy0: ethernet-phy@0 {
interrupts = <3 1 0 0>;
reg = <0x1>;
};
phy1: ethernet-phy@1 {
interrupts = <2 1 0 0>;
reg = <0x0>;
};
phy2: ethernet-phy@2 {
interrupts = <2 1 0 0>;
reg = <0x2>;
};
tbi-phy@3 {
device-type = "tbi-phy";
reg = <0x3>;
};
};
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
