* [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement @ 2016-03-06 19:53 Andreas Färber 2016-03-06 19:53 ` [PATCH v3 3/8] arm64: dts: rockchip: Add GeekBox config Andreas Färber ` (4 more replies) 0 siblings, 5 replies; 52+ messages in thread From: Andreas Färber @ 2016-03-06 19:53 UTC (permalink / raw) To: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r Cc: Julien Chauveau, Andreas Färber, devicetree-u79uwXL29TY76Z2rM5mHXA Hello, This series adds initial support for the RK3368 based GeekBox. Since v2 almost a month has passed with none of the first patches getting queued despite Heiko offering to squash them himself, so here's a full update. There were no more replies on the compatible string discussion for Landingship; I have now adopted Heiko's proposal of using "geekbuying,geekbox-landingship". v3 does minor cleanups and starts squashing undisputed patches. The power button is still left separate, inserting cleanups to align all RK3368 boards at least. On next-20160304 the GMAC seems to have regressed, it no longer finds the PHY: libphy: PHY stmmac-0:ffffffff not found eth0: Could not attach to PHY stmmac_open: Cannot attach to PHY (error: -19) For v2 I may have screwed up testing the Landingship FDT; I now ran into this: rk3x-i2c ff140000.i2c: using default SCL frequency: 100000 INFO: rcu_preempt detected stalls on CPUs/tasks: 1-...: (1 GPs behind) idle=481/140000000000000/0 softirq=130/131 fqs=5250 (detected by 7, t=5254 jiffies, g=-239, c=-240, q=90) Task dump for CPU 1: swapper/0 R running task 0 1 0 0x00000002 Call trace: [<ffffff8008085c5c>] __switch_to+0xc4/0xd0 [<ffffff8008bc1000>] nonblocking_pool_data+0x20/0x80 Keeping i2c1 disabled avoids that; i2c2 does not run into such problems. A quick git-grep shows that I'm the first actual user of i2c1 (and i2c2), so maybe something's wrong with clocks or pinctrl? Regards, Andreas Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Andreas Färber (8): Documentation: devicetree: Add vendor prefix for GeekBuying.com Documentation: devicetree: rockchip: Document GeekBox arm64: dts: rockchip: Add GeekBox config Documentation: devicetree: Clean up gpio-keys example arm64: dts: rockchip: Clean up gpio-keys nodes arm64: dts: rockchip: Add power key to GeekBox Documentation: devicetree: rockchip: Document Landingship arm64: dts: rockchip: Add Landingship config Documentation/devicetree/bindings/arm/rockchip.txt | 9 + .../devicetree/bindings/input/gpio-keys.txt | 2 - .../devicetree/bindings/vendor-prefixes.txt | 1 + arch/arm64/boot/dts/rockchip/Makefile | 2 + arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi | 5 +- .../dts/rockchip/rk3368-geekbox-landingship.dts | 57 ++++ arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts | 319 +++++++++++++++++++++ arch/arm64/boot/dts/rockchip/rk3368-r88.dts | 5 +- 8 files changed, 392 insertions(+), 8 deletions(-) create mode 100644 arch/arm64/boot/dts/rockchip/rk3368-geekbox-landingship.dts create mode 100644 arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH v3 3/8] arm64: dts: rockchip: Add GeekBox config 2016-03-06 19:53 [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement Andreas Färber @ 2016-03-06 19:53 ` Andreas Färber 2016-03-06 19:53 ` [PATCH v3 6/8] arm64: dts: rockchip: Add power key to GeekBox Andreas Färber ` (3 subsequent siblings) 4 siblings, 0 replies; 52+ messages in thread From: Andreas Färber @ 2016-03-06 19:53 UTC (permalink / raw) To: linux-rockchip Cc: Julien Chauveau, Andreas Färber, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Catalin Marinas, Will Deacon, Heiko Stuebner, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, moderated list:ARM64 PORT, open list The GeekBox contains an MXM3 module with a Rockchip RK3368 SoC. Some connectors are available directly on the module. This adds initial support, namely serial, USB, GMAC, eMMC, IR and TSADC. Signed-off-by: Andreas Färber <afaerber@suse.de> --- v2 -> v3: * Squashed GMAC, eMMC, IR, TSADC (Heiko) * Fixed IR pinctrl pull setting (Julien) * Changed TSADC polarity (rebooted immediately due to fixed otp-out pin) v1 -> v2: * Dropped rk3368-geekbox.dtsi. rk3368-geekbox-landingship.dts can #include "rk3368-geekbox.dts" just fine, when leaving out /dts-v1/;. * Revisited always-on / boot-on for PMIC regulator nodes. (Heiko) * Switched pmic-sleep from RK_FUNC_GPIO to RK_FUNC_2. (schematics) arch/arm64/boot/dts/rockchip/Makefile | 1 + arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts | 299 ++++++++++++++++++++++++ 2 files changed, 300 insertions(+) create mode 100644 arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile index e3f0b5f4ba4e..df37865e8ced 100644 --- a/arch/arm64/boot/dts/rockchip/Makefile +++ b/arch/arm64/boot/dts/rockchip/Makefile @@ -1,4 +1,5 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-evb-act8846.dtb +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb always := $(dtb-y) diff --git a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts new file mode 100644 index 000000000000..098be3700a6f --- /dev/null +++ b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts @@ -0,0 +1,299 @@ +/* + * Copyright (c) 2016 Andreas Färber + * + * This file is dual-licensed: you can use it either under the terms + * of the GPL or the X11 license, at your option. Note that this dual + * licensing only applies to this file, and not this project as a + * whole. + * + * a) This file 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. + * + * This file is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * Or, alternatively, + * + * b) Permission is hereby granted, free of charge, to any person + * obtaining a copy of this software and associated documentation + * files (the "Software"), to deal in the Software without + * restriction, including without limitation the rights to use, + * copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following + * conditions: + * + * The above copyright notice and this permission notice shall be + * included in all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR + * OTHER DEALINGS IN THE SOFTWARE. + */ + +/dts-v1/; +#include "rk3368.dtsi" + +/ { + model = "GeekBox"; + compatible = "geekbuying,geekbox", "rockchip,rk3368"; + + chosen { + stdout-path = "serial2:115200n8"; + }; + + memory { + device_type = "memory"; + reg = <0x0 0x0 0x0 0x80000000>; + }; + + ext_gmac: gmac-clk { + compatible = "fixed-clock"; + clock-frequency = <125000000>; + clock-output-names = "ext_gmac"; + #clock-cells = <0>; + }; + + ir: ir-receiver { + compatible = "gpio-ir-receiver"; + gpios = <&gpio3 30 GPIO_ACTIVE_LOW>; + pinctrl-names = "default"; + pinctrl-0 = <&ir_int>; + }; + + leds: gpio-leds { + compatible = "gpio-leds"; + + blue { + gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>; + label = "geekbox:blue:led"; + default-state = "on"; + }; + + red { + gpios = <&gpio2 3 GPIO_ACTIVE_HIGH>; + label = "geekbox:red:led"; + default-state = "off"; + }; + }; + + vcc_sys: vcc-sys-regulator { + compatible = "regulator-fixed"; + regulator-name = "vcc_sys"; + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <5000000>; + regulator-always-on; + regulator-boot-on; + }; +}; + +&emmc { + status = "okay"; + bus-width = <8>; + cap-mmc-highspeed; + clock-frequency = <150000000>; + disable-wp; + keep-power-in-suspend; + non-removable; + num-slots = <1>; + vmmc-supply = <&vcc_io>; + vqmmc-supply = <&vcc18_flash>; + pinctrl-names = "default"; + pinctrl-0 = <&emmc_clk>, <&emmc_cmd>, <&emmc_bus8>; +}; + +&gmac { + status = "okay"; + phy-supply = <&vcc_lan>; + phy-mode = "rgmii"; + clock_in_out = "input"; + assigned-clocks = <&cru SCLK_MAC>; + assigned-clock-parents = <&ext_gmac>; + pinctrl-names = "default"; + pinctrl-0 = <&rgmii_pins>; + tx_delay = <0x30>; + rx_delay = <0x10>; +}; + +&i2c0 { + status = "okay"; + + rk808: pmic@1b { + compatible = "rockchip,rk808"; + reg = <0x1b>; + pinctrl-names = "default"; + pinctrl-0 = <&pmic_int>, <&pmic_sleep>; + interrupt-parent = <&gpio0>; + interrupts = <5 IRQ_TYPE_LEVEL_LOW>; + rockchip,system-power-controller; + vcc1-supply = <&vcc_sys>; + vcc2-supply = <&vcc_sys>; + vcc3-supply = <&vcc_sys>; + vcc4-supply = <&vcc_sys>; + vcc6-supply = <&vcc_sys>; + vcc7-supply = <&vcc_sys>; + vcc8-supply = <&vcc_io>; + vcc9-supply = <&vcc_sys>; + vcc10-supply = <&vcc_sys>; + vcc11-supply = <&vcc_sys>; + vcc12-supply = <&vcc_io>; + clock-output-names = "xin32k", "rk808-clkout2"; + #clock-cells = <1>; + + regulators { + vdd_cpu: DCDC_REG1 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <700000>; + regulator-max-microvolt = <1500000>; + regulator-name = "vdd_cpu"; + }; + + vdd_log: DCDC_REG2 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <700000>; + regulator-max-microvolt = <1500000>; + regulator-name = "vdd_log"; + }; + + vcc_ddr: DCDC_REG3 { + regulator-always-on; + regulator-boot-on; + regulator-name = "vcc_ddr"; + }; + + vcc_io: DCDC_REG4 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-name = "vcc_io"; + }; + + vcc18_flash: LDO_REG1 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-name = "vcc18_flash"; + }; + + vcc33_lcd: LDO_REG2 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-name = "vcc33_lcd"; + }; + + vdd_10: LDO_REG3 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1000000>; + regulator-name = "vdd_10"; + }; + + vcca_18: LDO_REG4 { + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-name = "vcca_18"; + }; + + vccio_sd: LDO_REG5 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + regulator-name = "vccio_sd"; + }; + + vdd10_lcd: LDO_REG6 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1000000>; + regulator-name = "vdd10_lcd"; + }; + + vcc_18: LDO_REG7 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-name = "vcc_18"; + }; + + vcc18_lcd: LDO_REG8 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-name = "vcc18_lcd"; + }; + + vcc_sd: SWITCH_REG1 { + regulator-always-on; + regulator-boot-on; + regulator-name = "vcc_sd"; + }; + + vcc_lan: SWITCH_REG2 { + regulator-always-on; + regulator-boot-on; + regulator-name = "vcc_lan"; + }; + }; + }; +}; + +&pinctrl { + ir { + ir_int: ir-int { + rockchip,pins = <3 30 RK_FUNC_GPIO &pcfg_pull_none>; + }; + }; + + pmic { + pmic_sleep: pmic-sleep { + rockchip,pins = <0 0 RK_FUNC_2 &pcfg_pull_none>; + }; + + pmic_int: pmic-int { + rockchip,pins = <0 5 RK_FUNC_GPIO &pcfg_pull_up>; + }; + }; +}; + +&tsadc { + status = "okay"; + rockchip,hw-tshut-mode = <0>; /* CRU */ + rockchip,hw-tshut-polarity = <1>; /* high */ +}; + +&uart2 { + status = "okay"; +}; + +&usb_host0_ehci { + status = "okay"; +}; + +&usb_otg { + status = "okay"; +}; + +&wdt { + status = "okay"; +}; -- 2.6.2 ^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH v3 6/8] arm64: dts: rockchip: Add power key to GeekBox 2016-03-06 19:53 [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement Andreas Färber 2016-03-06 19:53 ` [PATCH v3 3/8] arm64: dts: rockchip: Add GeekBox config Andreas Färber @ 2016-03-06 19:53 ` Andreas Färber [not found] ` <1457294038-14243-7-git-send-email-afaerber-l3A5Bk7waGM@public.gmane.org> 2016-03-10 23:09 ` Julien Chauveau 2016-03-06 19:53 ` [PATCH v3 7/8] Documentation: devicetree: rockchip: Document Landingship Andreas Färber ` (2 subsequent siblings) 4 siblings, 2 replies; 52+ messages in thread From: Andreas Färber @ 2016-03-06 19:53 UTC (permalink / raw) To: linux-rockchip Cc: Mark Rutland, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, Catalin Marinas, Heiko Stuebner, Pawel Moll, Ian Campbell, Julien Chauveau, Will Deacon, open list, Rob Herring, Kumar Gala, Andreas Färber, moderated list:ARM64 PORT Signed-off-by: Andreas Färber <afaerber@suse.de> --- v2 -> v3: * Adopted wakeup-source instead of gpio-key,wakeup (Julien) * Dropped gpio-keys #address-cells and #size-cells properties (Julien) * Dropped power button reg property (Julien) * Adopted KEY_POWER (Julien) * Fixed power button pinctrl pull setting (Julien) v2: New arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts index 098be3700a6f..7036b49c9206 100644 --- a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts +++ b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts @@ -42,6 +42,7 @@ /dts-v1/; #include "rk3368.dtsi" +#include <dt-bindings/input/input.h> / { model = "GeekBox"; @@ -70,6 +71,19 @@ pinctrl-0 = <&ir_int>; }; + keys: gpio-keys { + compatible = "gpio-keys"; + pinctrl-names = "default"; + pinctrl-0 = <&pwr_key>; + + button@0 { + gpios = <&gpio0 2 GPIO_ACTIVE_LOW>; + label = "GPIO Power"; + linux,code = <KEY_POWER>; + wakeup-source; + }; + }; + leds: gpio-leds { compatible = "gpio-leds"; @@ -265,6 +279,12 @@ }; }; + keys { + pwr_key: pwr-key { + rockchip,pins = <0 2 RK_FUNC_GPIO &pcfg_pull_none>; + }; + }; + pmic { pmic_sleep: pmic-sleep { rockchip,pins = <0 0 RK_FUNC_2 &pcfg_pull_none>; -- 2.6.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 52+ messages in thread
[parent not found: <1457294038-14243-7-git-send-email-afaerber-l3A5Bk7waGM@public.gmane.org>]
* Re: [PATCH v3 6/8] arm64: dts: rockchip: Add power key to GeekBox [not found] ` <1457294038-14243-7-git-send-email-afaerber-l3A5Bk7waGM@public.gmane.org> @ 2016-03-10 23:04 ` Julien Chauveau 2016-03-16 10:58 ` Andreas Färber 0 siblings, 1 reply; 52+ messages in thread From: Julien Chauveau @ 2016-03-10 23:04 UTC (permalink / raw) To: Andreas Färber Cc: open list:ARM/Rockchip SoC..., Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Catalin Marinas, Will Deacon, Heiko Stuebner, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, moderated list:ARM64 PORT, open list > Le 6 mars 2016 à 20:53, Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org> a écrit : > > Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org> > --- > v2 -> v3: > * Adopted wakeup-source instead of gpio-key,wakeup (Julien) > * Dropped gpio-keys #address-cells and #size-cells properties (Julien) > * Dropped power button reg property (Julien) > * Adopted KEY_POWER (Julien) > * Fixed power button pinctrl pull setting (Julien) > > v2: New > > arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts > index 098be3700a6f..7036b49c9206 100644 > --- a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts > +++ b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts > @@ -42,6 +42,7 @@ > > /dts-v1/; > #include "rk3368.dtsi" > +#include <dt-bindings/input/input.h> > > / { > model = "GeekBox"; > @@ -70,6 +71,19 @@ > pinctrl-0 = <&ir_int>; > }; > > + keys: gpio-keys { I think you don't need the "keys" label, because there’s no phandle that refers to this. > + compatible = "gpio-keys"; > + pinctrl-names = "default"; > + pinctrl-0 = <&pwr_key>; > + > + button@0 { Here you should use "power" instead of "button@0". > + gpios = <&gpio0 2 GPIO_ACTIVE_LOW>; > + label = "GPIO Power"; > + linux,code = <KEY_POWER>; According to Documentation/input/event-codes.txt, there’s a special event type for the power button. Should we use it here for that purpose? linux,input-type = <EV_PWR> > + wakeup-source; > + }; > + }; > + > leds: gpio-leds { > compatible = "gpio-leds"; > > @@ -265,6 +279,12 @@ > }; > }; > > + keys { > + pwr_key: pwr-key { > + rockchip,pins = <0 2 RK_FUNC_GPIO &pcfg_pull_none>; > + }; > + }; > + > pmic { > pmic_sleep: pmic-sleep { > rockchip,pins = <0 0 RK_FUNC_2 &pcfg_pull_none>; > -- > 2.6.2 > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v3 6/8] arm64: dts: rockchip: Add power key to GeekBox 2016-03-10 23:04 ` Julien Chauveau @ 2016-03-16 10:58 ` Andreas Färber [not found] ` <56E93C43.1060500-l3A5Bk7waGM@public.gmane.org> 0 siblings, 1 reply; 52+ messages in thread From: Andreas Färber @ 2016-03-16 10:58 UTC (permalink / raw) To: Julien Chauveau Cc: Mark Rutland, devicetree, Heiko Stuebner, Pawel Moll, Ian Campbell, Catalin Marinas, Will Deacon, LKML, linux-rockchip, Rob Herring, Kumar Gala, LAKML Am 11.03.2016 um 00:04 schrieb Julien Chauveau: >> Le 6 mars 2016 à 20:53, Andreas Färber <afaerber@suse.de> a écrit : >> >> Signed-off-by: Andreas Färber <afaerber@suse.de> >> --- >> v2 -> v3: >> * Adopted wakeup-source instead of gpio-key,wakeup (Julien) >> * Dropped gpio-keys #address-cells and #size-cells properties (Julien) >> * Dropped power button reg property (Julien) >> * Adopted KEY_POWER (Julien) >> * Fixed power button pinctrl pull setting (Julien) >> >> v2: New >> >> arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts | 20 ++++++++++++++++++++ >> 1 file changed, 20 insertions(+) >> >> diff --git a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts >> index 098be3700a6f..7036b49c9206 100644 >> --- a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts >> +++ b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts >> @@ -42,6 +42,7 @@ >> >> /dts-v1/; >> #include "rk3368.dtsi" >> +#include <dt-bindings/input/input.h> >> >> / { >> model = "GeekBox"; >> @@ -70,6 +71,19 @@ >> pinctrl-0 = <&ir_int>; >> }; >> >> + keys: gpio-keys { > > I think you don't need the "keys" label, because there’s no phandle that refers to this. As discussed elsewhere, there are four additional keys on the Landingship (you proposed as sub-node names key1-key4). I prefer preparing the label now over adding it in a later patch. >> + compatible = "gpio-keys"; >> + pinctrl-names = "default"; >> + pinctrl-0 = <&pwr_key>; >> + >> + button@0 { > > Here you should use "power" instead of "button@0". Done. >> + gpios = <&gpio0 2 GPIO_ACTIVE_LOW>; >> + label = "GPIO Power"; >> + linux,code = <KEY_POWER>; > > According to Documentation/input/event-codes.txt, there’s a special event type for the power button. > Should we use it here for that purpose? > > linux,input-type = <EV_PWR> The other RK3368 boards don't, so unless you can give a justification to convert all boards yet again and test how this makes a difference, I'd rather not do experiments here but leave that to someone who knows what they're doing and then do it consistently... Thanks for the detailed review, Andreas >> + wakeup-source; >> + }; >> + }; >> + >> leds: gpio-leds { >> compatible = "gpio-leds"; >> >> @@ -265,6 +279,12 @@ >> }; >> }; >> >> + keys { >> + pwr_key: pwr-key { >> + rockchip,pins = <0 2 RK_FUNC_GPIO &pcfg_pull_none>; >> + }; >> + }; >> + >> pmic { >> pmic_sleep: pmic-sleep { >> rockchip,pins = <0 0 RK_FUNC_2 &pcfg_pull_none>; -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <56E93C43.1060500-l3A5Bk7waGM@public.gmane.org>]
* Re: [PATCH v3 6/8] arm64: dts: rockchip: Add power key to GeekBox [not found] ` <56E93C43.1060500-l3A5Bk7waGM@public.gmane.org> @ 2016-03-16 13:52 ` Andreas Färber 0 siblings, 0 replies; 52+ messages in thread From: Andreas Färber @ 2016-03-16 13:52 UTC (permalink / raw) To: Julien Chauveau Cc: Mark Rutland, devicetree, Heiko Stuebner, Pawel Moll, Ian Campbell, Catalin Marinas, Will Deacon, LKML, linux-rockchip, Rob Herring, Kumar Gala, LAKML Am 16.03.2016 um 11:58 schrieb Andreas Färber: > Am 11.03.2016 um 00:04 schrieb Julien Chauveau: >>> @@ -70,6 +71,19 @@ >>> pinctrl-0 = <&ir_int>; >>> }; >>> >>> + keys: gpio-keys { [...] >>> + compatible = "gpio-keys"; >>> + pinctrl-names = "default"; >>> + pinctrl-0 = <&pwr_key>; >>> + >>> + button@0 { [...] >>> + gpios = <&gpio0 2 GPIO_ACTIVE_LOW>; >>> + label = "GPIO Power"; >>> + linux,code = <KEY_POWER>; >> >> According to Documentation/input/event-codes.txt, there’s a special event type for the power button. >> Should we use it here for that purpose? >> >> linux,input-type = <EV_PWR> > > The other RK3368 boards don't, so unless you can give a justification to > convert all boards yet again and test how this makes a difference, I'd > rather not do experiments here but leave that to someone who knows what > they're doing and then do it consistently... For the record here's an evtest log: geekbox:~ # evtest No device specified, trying to scan all of /dev/input/event* Available devices: /dev/input/event0: gpio_ir_recv /dev/input/event1: MCE IR Keyboard/Mouse (gpio-rc-recv) /dev/input/event2: gpio-keys Select the device event number [0-2]: 2 Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "gpio-keys" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 116 (KEY_POWER) Properties: Testing ... (interrupt to exit) Event: time 1458136008.850429, type 1 (EV_KEY), code 116 (KEY_POWER), value 1 Event: time 1458136008.850429, -------------- SYN_REPORT ------------ systemd then goes on to shut down the system cleanly. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v3 6/8] arm64: dts: rockchip: Add power key to GeekBox 2016-03-06 19:53 ` [PATCH v3 6/8] arm64: dts: rockchip: Add power key to GeekBox Andreas Färber [not found] ` <1457294038-14243-7-git-send-email-afaerber-l3A5Bk7waGM@public.gmane.org> @ 2016-03-10 23:09 ` Julien Chauveau 1 sibling, 0 replies; 52+ messages in thread From: Julien Chauveau @ 2016-03-10 23:09 UTC (permalink / raw) To: Andreas Färber Cc: open list:ARM/Rockchip SoC..., Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Catalin Marinas, Will Deacon, Heiko Stuebner, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, moderated list:ARM64 PORT, open list > Le 6 mars 2016 à 20:53, Andreas Färber <afaerber@suse.de> a écrit : > > Signed-off-by: Andreas Färber <afaerber@suse.de> > --- > v2 -> v3: > * Adopted wakeup-source instead of gpio-key,wakeup (Julien) > * Dropped gpio-keys #address-cells and #size-cells properties (Julien) > * Dropped power button reg property (Julien) > * Adopted KEY_POWER (Julien) > * Fixed power button pinctrl pull setting (Julien) > > v2: New > > arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts > index 098be3700a6f..7036b49c9206 100644 > --- a/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts > +++ b/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts > @@ -42,6 +42,7 @@ > > /dts-v1/; > #include "rk3368.dtsi" > +#include <dt-bindings/input/input.h> > > / { > model = "GeekBox"; > @@ -70,6 +71,19 @@ > pinctrl-0 = <&ir_int>; > }; > > + keys: gpio-keys { I think you don't need the "keys" label, because there’s no phandle that refers to this. > + compatible = "gpio-keys"; > + pinctrl-names = "default"; > + pinctrl-0 = <&pwr_key>; > + > + button@0 { Here you should use "power" instead of "button@0". > + gpios = <&gpio0 2 GPIO_ACTIVE_LOW>; > + label = "GPIO Power"; > + linux,code = <KEY_POWER>; According to Documentation/input/event-codes.txt, there’s a special event type for the power button. Should we use it here for that purpose? linux,input-type = <EV_PWR> > + wakeup-source; > + }; > + }; > + > leds: gpio-leds { > compatible = "gpio-leds"; > > @@ -265,6 +279,12 @@ > }; > }; > > + keys { > + pwr_key: pwr-key { > + rockchip,pins = <0 2 RK_FUNC_GPIO &pcfg_pull_none>; > + }; > + }; > + > pmic { > pmic_sleep: pmic-sleep { > rockchip,pins = <0 0 RK_FUNC_2 &pcfg_pull_none>; > -- > 2.6.2 > ^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH v3 7/8] Documentation: devicetree: rockchip: Document Landingship 2016-03-06 19:53 [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement Andreas Färber 2016-03-06 19:53 ` [PATCH v3 3/8] arm64: dts: rockchip: Add GeekBox config Andreas Färber 2016-03-06 19:53 ` [PATCH v3 6/8] arm64: dts: rockchip: Add power key to GeekBox Andreas Färber @ 2016-03-06 19:53 ` Andreas Färber 2016-03-17 14:46 ` Rob Herring [not found] ` <1457294038-14243-1-git-send-email-afaerber-l3A5Bk7waGM@public.gmane.org> 2016-03-07 12:17 ` [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement Andreas Färber 4 siblings, 1 reply; 52+ messages in thread From: Andreas Färber @ 2016-03-06 19:53 UTC (permalink / raw) To: linux-rockchip Cc: Mark Rutland, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, Heiko Stuebner, Pawel Moll, Ian Campbell, Julien Chauveau, open list, Rob Herring, Kumar Gala, Andreas Färber, moderated list:ARM/Rockchip SoC support Use "geekbuying,geekbox-landingship" compatible string, plus those of the GeekBox module. Signed-off-by: Andreas Färber <afaerber@suse.de> --- v2 -> v3: * Changed compatible string to include geekbox- (Heiko) and clarify that this is for GeekBox module v2: New Documentation/devicetree/bindings/arm/rockchip.txt | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt index f633595b196c..ae84f4e1d83b 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.txt +++ b/Documentation/devicetree/bindings/arm/rockchip.txt @@ -91,6 +91,11 @@ Rockchip platforms device tree bindings Required root node properties: - compatible = "geekbuying,geekbox", "rockchip,rk3368"; +- GeekBuying Landingship with GeekBox module: + Required root node properties: + - compatible = "geekbuying,geekbox-landingship", + "geekbuying,geekbox", "rockchip,rk3368"; + - Rockchip RK3368 evb: Required root node properties: - compatible = "rockchip,rk3368-evb-act8846", "rockchip,rk3368"; -- 2.6.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: [PATCH v3 7/8] Documentation: devicetree: rockchip: Document Landingship 2016-03-06 19:53 ` [PATCH v3 7/8] Documentation: devicetree: rockchip: Document Landingship Andreas Färber @ 2016-03-17 14:46 ` Rob Herring 0 siblings, 0 replies; 52+ messages in thread From: Rob Herring @ 2016-03-17 14:46 UTC (permalink / raw) To: Andreas Färber Cc: linux-rockchip, Julien Chauveau, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Heiko Stuebner, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, moderated list:ARM/Rockchip SoC support, open list On Sun, Mar 06, 2016 at 08:53:56PM +0100, Andreas Färber wrote: > Use "geekbuying,geekbox-landingship" compatible string, plus those of > the GeekBox module. > > Signed-off-by: Andreas Färber <afaerber@suse.de> > --- > v2 -> v3: > * Changed compatible string to include geekbox- (Heiko) > and clarify that this is for GeekBox module > > v2: New > > Documentation/devicetree/bindings/arm/rockchip.txt | 5 +++++ > 1 file changed, 5 insertions(+) Acked-by: Rob Herring <robh@kernel.org> ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <1457294038-14243-1-git-send-email-afaerber-l3A5Bk7waGM@public.gmane.org>]
* [PATCH v3 1/8] Documentation: devicetree: Add vendor prefix for GeekBuying.com [not found] ` <1457294038-14243-1-git-send-email-afaerber-l3A5Bk7waGM@public.gmane.org> @ 2016-03-06 19:53 ` Andreas Färber 2016-03-06 19:53 ` [PATCH v3 2/8] Documentation: devicetree: rockchip: Document GeekBox Andreas Färber ` (3 subsequent siblings) 4 siblings, 0 replies; 52+ messages in thread From: Andreas Färber @ 2016-03-06 19:53 UTC (permalink / raw) To: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r Cc: Julien Chauveau, Andreas Färber, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, open list Use "geekbuying". Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org> --- v2 -> v3: * Rebased (ge vs. geekbuying) v2: New (Heiko) Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index a0e9f13fe9e3..390ae4536ca9 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -90,6 +90,7 @@ firefly Firefly focaltech FocalTech Systems Co.,Ltd fsl Freescale Semiconductor ge General Electric Company +geekbuying GeekBuying GEFanuc GE Fanuc Intelligent Platforms Embedded Systems, Inc. gef GE Fanuc Intelligent Platforms Embedded Systems, Inc. geniatech Geniatech, Inc. -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH v3 2/8] Documentation: devicetree: rockchip: Document GeekBox [not found] ` <1457294038-14243-1-git-send-email-afaerber-l3A5Bk7waGM@public.gmane.org> 2016-03-06 19:53 ` [PATCH v3 1/8] Documentation: devicetree: Add vendor prefix for GeekBuying.com Andreas Färber @ 2016-03-06 19:53 ` Andreas Färber 2016-03-06 19:53 ` [PATCH v3 4/8] Documentation: devicetree: Clean up gpio-keys example Andreas Färber ` (2 subsequent siblings) 4 siblings, 0 replies; 52+ messages in thread From: Andreas Färber @ 2016-03-06 19:53 UTC (permalink / raw) To: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r Cc: Julien Chauveau, Andreas Färber, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Heiko Stuebner, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, moderated list:ARM/Rockchip SoC support, open list Use "geekbuying,geekbox" compatible string. Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org> --- v2 -> v3: Unchanged v2: New (Heiko) Documentation/devicetree/bindings/arm/rockchip.txt | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt index 078c14fcdaaa..f633595b196c 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.txt +++ b/Documentation/devicetree/bindings/arm/rockchip.txt @@ -87,6 +87,10 @@ Rockchip platforms device tree bindings "google,veyron-speedy-rev3", "google,veyron-speedy-rev2", "google,veyron-speedy", "google,veyron", "rockchip,rk3288"; +- GeekBuying GeekBox: + Required root node properties: + - compatible = "geekbuying,geekbox", "rockchip,rk3368"; + - Rockchip RK3368 evb: Required root node properties: - compatible = "rockchip,rk3368-evb-act8846", "rockchip,rk3368"; -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH v3 4/8] Documentation: devicetree: Clean up gpio-keys example [not found] ` <1457294038-14243-1-git-send-email-afaerber-l3A5Bk7waGM@public.gmane.org> 2016-03-06 19:53 ` [PATCH v3 1/8] Documentation: devicetree: Add vendor prefix for GeekBuying.com Andreas Färber 2016-03-06 19:53 ` [PATCH v3 2/8] Documentation: devicetree: rockchip: Document GeekBox Andreas Färber @ 2016-03-06 19:53 ` Andreas Färber 2016-03-07 18:05 ` Heiko Stübner 2016-03-06 19:53 ` [PATCH v3 5/8] arm64: dts: rockchip: Clean up gpio-keys nodes Andreas Färber 2016-03-06 19:53 ` [PATCH v3 8/8] arm64: dts: rockchip: Add Landingship config Andreas Färber 4 siblings, 1 reply; 52+ messages in thread From: Andreas Färber @ 2016-03-06 19:53 UTC (permalink / raw) To: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r Cc: Julien Chauveau, Andreas Färber, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, open list Drop #address-cells and #size-cells, which are not required by the gpio-keys binding documentation, as button sub-nodes are not devices. Reported-by: Julien Chauveau <chauveau.julien-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org> --- v3: New (Julien) Documentation/devicetree/bindings/input/gpio-keys.txt | 2 -- 1 file changed, 2 deletions(-) diff --git a/Documentation/devicetree/bindings/input/gpio-keys.txt b/Documentation/devicetree/bindings/input/gpio-keys.txt index 21641236c095..1552a11f6786 100644 --- a/Documentation/devicetree/bindings/input/gpio-keys.txt +++ b/Documentation/devicetree/bindings/input/gpio-keys.txt @@ -34,8 +34,6 @@ Example nodes: gpio_keys { compatible = "gpio-keys"; - #address-cells = <1>; - #size-cells = <0>; autorepeat; button@21 { label = "GPIO Key UP"; -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: [PATCH v3 4/8] Documentation: devicetree: Clean up gpio-keys example 2016-03-06 19:53 ` [PATCH v3 4/8] Documentation: devicetree: Clean up gpio-keys example Andreas Färber @ 2016-03-07 18:05 ` Heiko Stübner 2016-03-07 18:27 ` Andreas Färber 0 siblings, 1 reply; 52+ messages in thread From: Heiko Stübner @ 2016-03-07 18:05 UTC (permalink / raw) To: linux-rockchip Cc: Andreas Färber, Mark Rutland, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, Pawel Moll, Ian Campbell, Julien Chauveau, open list, Rob Herring, Kumar Gala Am Sonntag, 6. März 2016, 20:53:53 schrieb Andreas Färber: > Drop #address-cells and #size-cells, which are not required by the > gpio-keys binding documentation, as button sub-nodes are not devices. > > Reported-by: Julien Chauveau <chauveau.julien@gmail.com> > Signed-off-by: Andreas Färber <afaerber@suse.de> > --- changes to input-device bindings should go through the input tree, and thus include Dmitry Thorokhov and the linux-input lists. Heiko > v3: New (Julien) > > Documentation/devicetree/bindings/input/gpio-keys.txt | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/input/gpio-keys.txt > b/Documentation/devicetree/bindings/input/gpio-keys.txt index > 21641236c095..1552a11f6786 100644 > --- a/Documentation/devicetree/bindings/input/gpio-keys.txt > +++ b/Documentation/devicetree/bindings/input/gpio-keys.txt > @@ -34,8 +34,6 @@ Example nodes: > > gpio_keys { > compatible = "gpio-keys"; > - #address-cells = <1>; > - #size-cells = <0>; > autorepeat; > button@21 { > label = "GPIO Key UP"; ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v3 4/8] Documentation: devicetree: Clean up gpio-keys example 2016-03-07 18:05 ` Heiko Stübner @ 2016-03-07 18:27 ` Andreas Färber 0 siblings, 0 replies; 52+ messages in thread From: Andreas Färber @ 2016-03-07 18:27 UTC (permalink / raw) To: Heiko Stübner Cc: Mark Rutland, devicetree, Pawel Moll, Ian Campbell, Julien Chauveau, LKML, linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring, Kumar Gala Am 07.03.2016 um 19:05 schrieb Heiko Stübner: > Am Sonntag, 6. März 2016, 20:53:53 schrieb Andreas Färber: >> Drop #address-cells and #size-cells, which are not required by the >> gpio-keys binding documentation, as button sub-nodes are not devices. >> >> Reported-by: Julien Chauveau <chauveau.julien-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> >> Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org> >> --- > > changes to input-device bindings should go through the input tree, and thus > include Dmitry Thorokhov and the linux-input lists. Thanks for noticing, MAINTAINERS update proposed and resent this patch using it. Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) ^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCH v3 5/8] arm64: dts: rockchip: Clean up gpio-keys nodes [not found] ` <1457294038-14243-1-git-send-email-afaerber-l3A5Bk7waGM@public.gmane.org> ` (2 preceding siblings ...) 2016-03-06 19:53 ` [PATCH v3 4/8] Documentation: devicetree: Clean up gpio-keys example Andreas Färber @ 2016-03-06 19:53 ` Andreas Färber 2016-03-06 19:53 ` [PATCH v3 8/8] arm64: dts: rockchip: Add Landingship config Andreas Färber 4 siblings, 0 replies; 52+ messages in thread From: Andreas Färber @ 2016-03-06 19:53 UTC (permalink / raw) To: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r Cc: Julien Chauveau, Andreas Färber, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Catalin Marinas, Will Deacon, Heiko Stuebner, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, moderated list:ARM64 PORT, open list Drop superfluous #address-cells and #size-cells. Use KEY_POWER define for 116. Reported-by: Julien Chauveau <chauveau.julien-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org> --- v3: New (Julien) arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi | 5 ++--- arch/arm64/boot/dts/rockchip/rk3368-r88.dts | 5 ++--- 2 files changed, 4 insertions(+), 6 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi b/arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi index 06bbe421db37..b62035436d38 100644 --- a/arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3368-evb.dtsi @@ -40,6 +40,7 @@ * OTHER DEALINGS IN THE SOFTWARE. */ +#include <dt-bindings/input/input.h> #include <dt-bindings/pwm/pwm.h> #include "rk3368.dtsi" @@ -105,8 +106,6 @@ keys: gpio-keys { compatible = "gpio-keys"; - #address-cells = <1>; - #size-cells = <0>; pinctrl-names = "default"; pinctrl-0 = <&pwr_key>; @@ -114,7 +113,7 @@ wakeup-source; gpios = <&gpio0 2 GPIO_ACTIVE_LOW>; label = "GPIO Power"; - linux,code = <116>; + linux,code = <KEY_POWER>; }; }; diff --git a/arch/arm64/boot/dts/rockchip/rk3368-r88.dts b/arch/arm64/boot/dts/rockchip/rk3368-r88.dts index a1d1aa9c16fe..efb5fa32ecac 100644 --- a/arch/arm64/boot/dts/rockchip/rk3368-r88.dts +++ b/arch/arm64/boot/dts/rockchip/rk3368-r88.dts @@ -42,6 +42,7 @@ /dts-v1/; #include "rk3368.dtsi" +#include <dt-bindings/input/input.h> / { model = "Rockchip R88"; @@ -65,8 +66,6 @@ keys: gpio-keys { compatible = "gpio-keys"; - #address-cells = <1>; - #size-cells = <0>; pinctrl-names = "default"; pinctrl-0 = <&pwr_key>; @@ -74,7 +73,7 @@ wakeup-source; gpios = <&gpio0 2 GPIO_ACTIVE_LOW>; label = "GPIO Power"; - linux,code = <116>; + linux,code = <KEY_POWER>; }; }; -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCH v3 8/8] arm64: dts: rockchip: Add Landingship config [not found] ` <1457294038-14243-1-git-send-email-afaerber-l3A5Bk7waGM@public.gmane.org> ` (3 preceding siblings ...) 2016-03-06 19:53 ` [PATCH v3 5/8] arm64: dts: rockchip: Clean up gpio-keys nodes Andreas Färber @ 2016-03-06 19:53 ` Andreas Färber 4 siblings, 0 replies; 52+ messages in thread From: Andreas Färber @ 2016-03-06 19:53 UTC (permalink / raw) To: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r Cc: Julien Chauveau, Andreas Färber, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Catalin Marinas, Will Deacon, Heiko Stuebner, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, moderated list:ARM64 PORT, open list Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org> --- v2 -> v3: * Changed compatible string to include geekbox- (Heiko) * Rebroke compatible strings line * Disabled i2c1 to avoid hang (next-20160304) v2: New - showcases inclusion of GeekBox module config arch/arm64/boot/dts/rockchip/Makefile | 1 + .../dts/rockchip/rk3368-geekbox-landingship.dts | 57 ++++++++++++++++++++++ 2 files changed, 58 insertions(+) create mode 100644 arch/arm64/boot/dts/rockchip/rk3368-geekbox-landingship.dts diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile index df37865e8ced..201bcd9863ce 100644 --- a/arch/arm64/boot/dts/rockchip/Makefile +++ b/arch/arm64/boot/dts/rockchip/Makefile @@ -1,5 +1,6 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-evb-act8846.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox.dtb +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox-landingship.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb always := $(dtb-y) diff --git a/arch/arm64/boot/dts/rockchip/rk3368-geekbox-landingship.dts b/arch/arm64/boot/dts/rockchip/rk3368-geekbox-landingship.dts new file mode 100644 index 000000000000..a28ace9512bb --- /dev/null +++ b/arch/arm64/boot/dts/rockchip/rk3368-geekbox-landingship.dts @@ -0,0 +1,57 @@ +/* + * Copyright (c) 2016 Andreas Färber + * + * This file is dual-licensed: you can use it either under the terms + * of the GPL or the X11 license, at your option. Note that this dual + * licensing only applies to this file, and not this project as a + * whole. + * + * a) This file 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. + * + * This file is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * Or, alternatively, + * + * b) Permission is hereby granted, free of charge, to any person + * obtaining a copy of this software and associated documentation + * files (the "Software"), to deal in the Software without + * restriction, including without limitation the rights to use, + * copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following + * conditions: + * + * The above copyright notice and this permission notice shall be + * included in all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR + * OTHER DEALINGS IN THE SOFTWARE. + */ + +#include "rk3368-geekbox.dts" + +/ { + model = "GeekBox on Landingship"; + compatible = "geekbuying,geekbox-landingship", + "geekbuying,geekbox", "rockchip,rk3368"; +}; + +&i2c1 { + status = "disabled"; +}; + +&i2c2 { + status = "okay"; +}; -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement 2016-03-06 19:53 [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement Andreas Färber ` (3 preceding siblings ...) [not found] ` <1457294038-14243-1-git-send-email-afaerber-l3A5Bk7waGM@public.gmane.org> @ 2016-03-07 12:17 ` Andreas Färber 2016-03-07 12:24 ` Heiko Stübner 2016-03-11 12:12 ` Michael Trimarchi 4 siblings, 2 replies; 52+ messages in thread From: Andreas Färber @ 2016-03-07 12:17 UTC (permalink / raw) To: linux-rockchip, netdev Cc: devicetree, Giuseppe Cavallaro, Heiko Stuebner, LAKML Am 06.03.2016 um 20:53 schrieb Andreas Färber: > On next-20160304 the GMAC seems to have regressed, it no longer finds the PHY: > > libphy: PHY stmmac-0:ffffffff not found > eth0: Could not attach to PHY > stmmac_open: Cannot attach to PHY (error: -19) Still with us in next-20160307. CC'ing stmmac maintainers. http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/drivers/net/ethernet/stmicro Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement 2016-03-07 12:17 ` [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement Andreas Färber @ 2016-03-07 12:24 ` Heiko Stübner 2016-03-07 12:35 ` Andreas Färber 2016-03-11 12:12 ` Michael Trimarchi 1 sibling, 1 reply; 52+ messages in thread From: Heiko Stübner @ 2016-03-07 12:24 UTC (permalink / raw) To: Andreas Färber Cc: linux-rockchip, netdev, devicetree, Giuseppe Cavallaro, LAKML Hi Andreas, Am Montag, 7. März 2016, 13:17:54 schrieb Andreas Färber: > Am 06.03.2016 um 20:53 schrieb Andreas Färber: > > On next-20160304 the GMAC seems to have regressed, it no longer finds the > > PHY: > > > > libphy: PHY stmmac-0:ffffffff not found > > eth0: Could not attach to PHY > > stmmac_open: Cannot attach to PHY (error: -19) > > Still with us in next-20160307. CC'ing stmmac maintainers. do you remember from what revision you rebased away from, when it was still working (as a known-good state)? Heiko > > http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/drivers/ > net/ethernet/stmicro > > Regards, > Andreas ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement 2016-03-07 12:24 ` Heiko Stübner @ 2016-03-07 12:35 ` Andreas Färber 2016-03-07 13:26 ` Giuseppe CAVALLARO 0 siblings, 1 reply; 52+ messages in thread From: Andreas Färber @ 2016-03-07 12:35 UTC (permalink / raw) To: Heiko Stübner Cc: linux-rockchip, netdev, devicetree, Giuseppe Cavallaro, LAKML Hi Heiko, Am 07.03.2016 um 13:24 schrieb Heiko Stübner: > Am Montag, 7. März 2016, 13:17:54 schrieb Andreas Färber: >> Am 06.03.2016 um 20:53 schrieb Andreas Färber: >>> On next-20160304 the GMAC seems to have regressed, it no longer finds the >>> PHY: >>> >>> libphy: PHY stmmac-0:ffffffff not found >>> eth0: Could not attach to PHY >>> stmmac_open: Cannot attach to PHY (error: -19) >> >> Still with us in next-20160307. CC'ing stmmac maintainers. > > do you remember from what revision you rebased away from, when it was still > working (as a known-good state)? Hm, next-20160111 possibly... leaving all the 5 days and 4 days ago changes as candidates ("stmmac: share reset function between dwmac100 and dwmac1000" .. "stmmac: Fix 'eth0: No PHY found' regression"). Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement 2016-03-07 12:35 ` Andreas Färber @ 2016-03-07 13:26 ` Giuseppe CAVALLARO 2016-03-07 14:27 ` Andreas Färber 0 siblings, 1 reply; 52+ messages in thread From: Giuseppe CAVALLARO @ 2016-03-07 13:26 UTC (permalink / raw) To: Andreas Färber, Heiko Stübner Cc: linux-rockchip, netdev, devicetree, LAKML, Gabriel Fernandez Hello Andreas, Heiko, On 3/7/2016 1:35 PM, Andreas Färber wrote: > Hi Heiko, > > Am 07.03.2016 um 13:24 schrieb Heiko Stübner: >> Am Montag, 7. März 2016, 13:17:54 schrieb Andreas Färber: >>> Am 06.03.2016 um 20:53 schrieb Andreas Färber: >>>> On next-20160304 the GMAC seems to have regressed, it no longer finds the >>>> PHY: >>>> >>>> libphy: PHY stmmac-0:ffffffff not found snps,phy-addr is not correct. Can you check it? In the stmmac_mdio if this is not passed as parameter the bus should be scanned and the first IDs found should select the right address. I suppose in your box there is a real transceiver, so maybe the patch from Gabriel is not actually necessary. >>>> eth0: Could not attach to PHY >>>> stmmac_open: Cannot attach to PHY (error: -19) >>> >>> Still with us in next-20160307. CC'ing stmmac maintainers. peppe >> >> do you remember from what revision you rebased away from, when it was still >> working (as a known-good state)? > > Hm, next-20160111 possibly... leaving all the 5 days and 4 days ago > changes as candidates ("stmmac: share reset function between dwmac100 > and dwmac1000" .. "stmmac: Fix 'eth0: No PHY found' regression"). > > Regards, > Andreas > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement 2016-03-07 13:26 ` Giuseppe CAVALLARO @ 2016-03-07 14:27 ` Andreas Färber [not found] ` <56DD8FBE.9010200-l3A5Bk7waGM@public.gmane.org> 0 siblings, 1 reply; 52+ messages in thread From: Andreas Färber @ 2016-03-07 14:27 UTC (permalink / raw) To: Giuseppe CAVALLARO Cc: Heiko Stübner, linux-rockchip, netdev, devicetree, LAKML, Gabriel Fernandez Hello Giuseppe, Am 07.03.2016 um 14:26 schrieb Giuseppe CAVALLARO: > On 3/7/2016 1:35 PM, Andreas Färber wrote: >> Am 07.03.2016 um 13:24 schrieb Heiko Stübner: >>> Am Montag, 7. März 2016, 13:17:54 schrieb Andreas Färber: >>>> Am 06.03.2016 um 20:53 schrieb Andreas Färber: >>>>> On next-20160304 the GMAC seems to have regressed, it no longer >>>>> finds the >>>>> PHY: >>>>> >>>>> libphy: PHY stmmac-0:ffffffff not found > > snps,phy-addr is not correct. Can you check it? It was never set: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/rockchip/rk3368.dtsi#n436 https://github.com/afaerber/linux/blob/96c5b5fd395fee5713755e93e677fb011cb9ddc0/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts#L114 > In the stmmac_mdio if this is not passed as parameter the bus should > be scanned and the first IDs found should select the right address. > I suppose in your box there is a real transceiver, so maybe the patch > from Gabriel is not actually necessary. On the GeekBox module there's an RTL8211E phy. Indeed, reverting Gabriel's commit fixes the observed error messages: rk_gmac-dwmac ff290000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/net/ethernet/stmicro?id=88f8b1bb41c6208f81b6a480244533ded7b59493 However, I am unable to ping any hosts on the network now. Regards, Andreas >>>>> eth0: Could not attach to PHY >>>>> stmmac_open: Cannot attach to PHY (error: -19) >>>> >>>> Still with us in next-20160307. CC'ing stmmac maintainers. > > peppe > >>> >>> do you remember from what revision you rebased away from, when it was >>> still >>> working (as a known-good state)? >> >> Hm, next-20160111 possibly... leaving all the 5 days and 4 days ago >> changes as candidates ("stmmac: share reset function between dwmac100 >> and dwmac1000" .. "stmmac: Fix 'eth0: No PHY found' regression"). -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <56DD8FBE.9010200-l3A5Bk7waGM@public.gmane.org>]
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement [not found] ` <56DD8FBE.9010200-l3A5Bk7waGM@public.gmane.org> @ 2016-03-07 15:09 ` Giuseppe CAVALLARO 2016-03-07 15:46 ` Andreas Färber 0 siblings, 1 reply; 52+ messages in thread From: Giuseppe CAVALLARO @ 2016-03-07 15:09 UTC (permalink / raw) To: Andreas Färber, Gabriel Fernandez Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Alexandre TORGUE, netdev-u79uwXL29TY76Z2rM5mHXA, linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, LAKML, Heiko Stübner Hi Andreas On 3/7/2016 3:27 PM, Andreas Färber wrote: > Hello Giuseppe, > > Am 07.03.2016 um 14:26 schrieb Giuseppe CAVALLARO: >> On 3/7/2016 1:35 PM, Andreas Färber wrote: >>> Am 07.03.2016 um 13:24 schrieb Heiko Stübner: >>>> Am Montag, 7. März 2016, 13:17:54 schrieb Andreas Färber: >>>>> Am 06.03.2016 um 20:53 schrieb Andreas Färber: >>>>>> On next-20160304 the GMAC seems to have regressed, it no longer >>>>>> finds the >>>>>> PHY: >>>>>> >>>>>> libphy: PHY stmmac-0:ffffffff not found >> >> snps,phy-addr is not correct. Can you check it? > > It was never set: > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/rockchip/rk3368.dtsi#n436 > > https://github.com/afaerber/linux/blob/96c5b5fd395fee5713755e93e677fb011cb9ddc0/arch/arm64/boot/dts/rockchip/rk3368-geekbox.dts#L114 > >> In the stmmac_mdio if this is not passed as parameter the bus should >> be scanned and the first IDs found should select the right address. >> I suppose in your box there is a real transceiver, so maybe the patch >> from Gabriel is not actually necessary. > > On the GeekBox module there's an RTL8211E phy. > > Indeed, reverting Gabriel's commit fixes the observed error messages: > > rk_gmac-dwmac ff290000.ethernet eth0: Link is Up - 1Gbps/Full - flow > control rx/tx so this means that the phy is found and the link auto-negotiated. Gabriel, it sounds that the patch solved a regression you found on a configuration where the MAC dialogs with a switch but it breaks the setup with use a std transceiver. > http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/net/ethernet/stmicro?id=88f8b1bb41c6208f81b6a480244533ded7b59493 > > However, I am unable to ping any hosts on the network now. hmm, this could be another problem. I wonder if you can check which recent patch is introducing the problem on ARM64. For example if this depends on Oct_2015 update. If you share some logs to me I can take a look at them. Then we can try to check if the problem in on rx or tx path. I also ask you yo check the axi settings. Let me know Regards peppe > > Regards, > Andreas > >>>>>> eth0: Could not attach to PHY >>>>>> stmmac_open: Cannot attach to PHY (error: -19) >>>>> >>>>> Still with us in next-20160307. CC'ing stmmac maintainers. >> >> peppe >> >>>> >>>> do you remember from what revision you rebased away from, when it was >>>> still >>>> working (as a known-good state)? >>> >>> Hm, next-20160111 possibly... leaving all the 5 days and 4 days ago >>> changes as candidates ("stmmac: share reset function between dwmac100 >>> and dwmac1000" .. "stmmac: Fix 'eth0: No PHY found' regression"). > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement 2016-03-07 15:09 ` Giuseppe CAVALLARO @ 2016-03-07 15:46 ` Andreas Färber [not found] ` <56DDA26C.3050301-l3A5Bk7waGM@public.gmane.org> 0 siblings, 1 reply; 52+ messages in thread From: Andreas Färber @ 2016-03-07 15:46 UTC (permalink / raw) To: Giuseppe CAVALLARO Cc: Gabriel Fernandez, Heiko Stübner, linux-rockchip, netdev, devicetree, LAKML, Alexandre TORGUE Hi Peppe, Am 07.03.2016 um 16:09 schrieb Giuseppe CAVALLARO: > On 3/7/2016 3:27 PM, Andreas Färber wrote: >> Indeed, reverting Gabriel's commit fixes the observed error messages [...] >> However, I am unable to ping any hosts on the network now. > > hmm, this could be another problem. I wonder if you can > check which recent patch is introducing the problem on ARM64. > For example if this depends on Oct_2015 update. I've had success reverting drivers/net/ethernet/stmicro/ up to and including "stmmac: first frame prep at the end of xmit routine", i.e. top 7 commits. http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/net/ethernet/stmicro?id=0e80bdc9a72df3b31a9fc2012102a6cc8d664e93 > If you share some logs to me I can take a look at them. > Then we can try to check if the problem in on rx or tx path. > I also ask you yo check the axi settings. On the reverted (good) branch I see in dmesg: [ +0.001100] rk_gmac-dwmac ff290000.ethernet: Looking up phy-supply from device tree [ +0.000030] rk808 0-001b: Looking up vcc12-supply from device tree [ +0.000013] vcc_lan: supplied by vcc_io [ +0.000120] rk_gmac-dwmac ff290000.ethernet: clock input or output? (input). [ +0.000010] rk_gmac-dwmac ff290000.ethernet: TX delay(0x30). [ +0.000007] rk_gmac-dwmac ff290000.ethernet: RX delay(0x10). [ +0.000014] rk_gmac-dwmac ff290000.ethernet: init for RGMII [ +0.000104] rk_gmac-dwmac ff290000.ethernet: clock input from PHY [ +0.005099] rk_gmac-dwmac ff290000.ethernet: no reset control found [ +0.000007] stmmac - user ID: 0x10, Synopsys ID: 0x35 [ +0.000002] Ring mode enabled [ +0.000006] DMA HW capability register supported [ +0.000000] Normal descriptors [ +0.000004] RX Checksum Offload Engine supported (type 2) [ +0.000002] TX Checksum insertion supported [ +0.000002] Wake-Up On Lan supported [ +0.000052] Enable RX Mitigation via HW Watchdog Timer [ +0.000683] rk_gmac-dwmac ff290000.ethernet eth0: No MDIO subnode found [ +0.000124] of_get_named_gpiod_flags: can't parse 'snps,reset-gpio' property of node '/ethernet@ff290000[0]' [ +0.004219] libphy: stmmac: probed [ +0.000010] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active [ +0.000005] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01) [ +0.881011] eth0: device MAC address 4a:78:dd:10:b3:17 [ +4.003065] rk_gmac-dwmac ff290000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx The MAC address is random, changing each time. Otherwise there's no log difference I spot to the pre-Gabriel broken state. If you need more info, let me know where to find it. Thanks, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <56DDA26C.3050301-l3A5Bk7waGM@public.gmane.org>]
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement [not found] ` <56DDA26C.3050301-l3A5Bk7waGM@public.gmane.org> @ 2016-03-07 15:52 ` Giuseppe CAVALLARO 2016-03-07 17:15 ` Andreas Färber 0 siblings, 1 reply; 52+ messages in thread From: Giuseppe CAVALLARO @ 2016-03-07 15:52 UTC (permalink / raw) To: Andreas Färber Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Heiko Stübner, netdev-u79uwXL29TY76Z2rM5mHXA, linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Gabriel Fernandez, Fabrice GASNIER, LAKML, Alexandre TORGUE On 3/7/2016 4:46 PM, Andreas Färber wrote: > Hi Peppe, > > Am 07.03.2016 um 16:09 schrieb Giuseppe CAVALLARO: >> On 3/7/2016 3:27 PM, Andreas Färber wrote: >>> Indeed, reverting Gabriel's commit fixes the observed error messages > [...] >>> However, I am unable to ping any hosts on the network now. >> >> hmm, this could be another problem. I wonder if you can >> check which recent patch is introducing the problem on ARM64. >> For example if this depends on Oct_2015 update. > > I've had success reverting drivers/net/ethernet/stmicro/ up to and > including "stmmac: first frame prep at the end of xmit routine", i.e. > top 7 commits. Andreas, I will check it and let you know asap. > > http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/net/ethernet/stmicro?id=0e80bdc9a72df3b31a9fc2012102a6cc8d664e93 > >> If you share some logs to me I can take a look at them. >> Then we can try to check if the problem in on rx or tx path. >> I also ask you yo check the axi settings. > > On the reverted (good) branch I see in dmesg: > > [ +0.001100] rk_gmac-dwmac ff290000.ethernet: Looking up phy-supply > from device tree > [ +0.000030] rk808 0-001b: Looking up vcc12-supply from device tree > [ +0.000013] vcc_lan: supplied by vcc_io > [ +0.000120] rk_gmac-dwmac ff290000.ethernet: clock input or output? > (input). > [ +0.000010] rk_gmac-dwmac ff290000.ethernet: TX delay(0x30). > [ +0.000007] rk_gmac-dwmac ff290000.ethernet: RX delay(0x10). > [ +0.000014] rk_gmac-dwmac ff290000.ethernet: init for RGMII > [ +0.000104] rk_gmac-dwmac ff290000.ethernet: clock input from PHY > [ +0.005099] rk_gmac-dwmac ff290000.ethernet: no reset control found > [ +0.000007] stmmac - user ID: 0x10, Synopsys ID: 0x35 > [ +0.000002] Ring mode enabled > [ +0.000006] DMA HW capability register supported > [ +0.000000] Normal descriptors > [ +0.000004] RX Checksum Offload Engine supported (type 2) > [ +0.000002] TX Checksum insertion supported > [ +0.000002] Wake-Up On Lan supported > [ +0.000052] Enable RX Mitigation via HW Watchdog Timer > [ +0.000683] rk_gmac-dwmac ff290000.ethernet eth0: No MDIO subnode found > [ +0.000124] of_get_named_gpiod_flags: can't parse 'snps,reset-gpio' > property of node '/ethernet@ff290000[0]' > [ +0.004219] libphy: stmmac: probed > [ +0.000010] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active > [ +0.000005] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01) > > [ +0.881011] eth0: device MAC address 4a:78:dd:10:b3:17 > [ +4.003065] rk_gmac-dwmac ff290000.ethernet eth0: Link is Up - > 1Gbps/Full - flow control rx/tx > > The MAC address is random, changing each time. Otherwise there's no log > difference I spot to the pre-Gabriel broken state. ok > > If you need more info, let me know where to find it. no it's ok at this stage. > > Thanks, welcome > Andreas Regards peppe ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement 2016-03-07 15:52 ` Giuseppe CAVALLARO @ 2016-03-07 17:15 ` Andreas Färber [not found] ` <56DDB749.1020808-l3A5Bk7waGM@public.gmane.org> 0 siblings, 1 reply; 52+ messages in thread From: Andreas Färber @ 2016-03-07 17:15 UTC (permalink / raw) To: Giuseppe CAVALLARO Cc: Gabriel Fernandez, Heiko Stübner, linux-rockchip, netdev, devicetree, LAKML, Alexandre TORGUE, Fabrice GASNIER Am 07.03.2016 um 16:52 schrieb Giuseppe CAVALLARO: > On 3/7/2016 4:46 PM, Andreas Färber wrote: >> Am 07.03.2016 um 16:09 schrieb Giuseppe CAVALLARO: >>> On 3/7/2016 3:27 PM, Andreas Färber wrote: >>>> Indeed, reverting Gabriel's commit fixes the observed error messages >> [...] >>>> However, I am unable to ping any hosts on the network now. >>> >>> hmm, this could be another problem. I wonder if you can >>> check which recent patch is introducing the problem on ARM64. >>> For example if this depends on Oct_2015 update. >> >> I've had success reverting drivers/net/ethernet/stmicro/ up to and >> including "stmmac: first frame prep at the end of xmit routine", i.e. >> top 7 commits. > > Andreas, I will check it and let you know asap. I verified that it's just these two commits that I need to revert: "stmmac: Fix 'eth0: No PHY found' regression" "stmmac: first frame prep at the end of xmit routine" Those in between don't cause conflicts and seem to work okay. Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <56DDB749.1020808-l3A5Bk7waGM@public.gmane.org>]
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement [not found] ` <56DDB749.1020808-l3A5Bk7waGM@public.gmane.org> @ 2016-03-07 23:22 ` Dinh Nguyen [not found] ` <CADhT+wfO8x4En78g5ixnnwbpaeXJGDo+Q1sOABYsbXzNZy0CPw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 52+ messages in thread From: Dinh Nguyen @ 2016-03-07 23:22 UTC (permalink / raw) To: Andreas Färber Cc: Giuseppe CAVALLARO, Gabriel Fernandez, Heiko Stübner, open list:ARM/Rockchip SoC..., netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA, LAKML, Alexandre TORGUE, Fabrice GASNIER On Mon, Mar 7, 2016 at 11:15 AM, Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org> wrote: > Am 07.03.2016 um 16:52 schrieb Giuseppe CAVALLARO: >> On 3/7/2016 4:46 PM, Andreas Färber wrote: >>> Am 07.03.2016 um 16:09 schrieb Giuseppe CAVALLARO: >>>> On 3/7/2016 3:27 PM, Andreas Färber wrote: >>>>> Indeed, reverting Gabriel's commit fixes the observed error messages >>> [...] >>>>> However, I am unable to ping any hosts on the network now. >>>> >>>> hmm, this could be another problem. I wonder if you can >>>> check which recent patch is introducing the problem on ARM64. >>>> For example if this depends on Oct_2015 update. >>> >>> I've had success reverting drivers/net/ethernet/stmicro/ up to and >>> including "stmmac: first frame prep at the end of xmit routine", i.e. >>> top 7 commits. >> >> Andreas, I will check it and let you know asap. > > I verified that it's just these two commits that I need to revert: > > "stmmac: Fix 'eth0: No PHY found' regression" > "stmmac: first frame prep at the end of xmit routine" > > Those in between don't cause conflicts and seem to work okay. > I'm seeing the same issue on the SoCFPGA platform: libphy: PHY stmmac-0:ffffffff not found eth0: Could not attach to PHY stmmac_open: Cannot attach to PHY (error: -19) If I just revert: "stmmac: Fix 'eth0: No PHY found' regression" then the issue goes away. Thanks, Dinh -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <CADhT+wfO8x4En78g5ixnnwbpaeXJGDo+Q1sOABYsbXzNZy0CPw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement [not found] ` <CADhT+wfO8x4En78g5ixnnwbpaeXJGDo+Q1sOABYsbXzNZy0CPw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2016-03-08 7:24 ` Giuseppe CAVALLARO 2016-03-08 15:45 ` Dinh Nguyen 2016-03-08 10:03 ` Gabriel Fernandez 1 sibling, 1 reply; 52+ messages in thread From: Giuseppe CAVALLARO @ 2016-03-08 7:24 UTC (permalink / raw) To: Dinh Nguyen, Andreas Färber Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Heiko Stübner, netdev-u79uwXL29TY76Z2rM5mHXA, open list:ARM/Rockchip SoC..., Gabriel Fernandez, Fabrice GASNIER, LAKML, Alexandre TORGUE Hi Dinh, On 3/8/2016 12:22 AM, Dinh Nguyen wrote: [snip] > > I'm seeing the same issue on the SoCFPGA platform: > > libphy: PHY stmmac-0:ffffffff not found > eth0: Could not attach to PHY > stmmac_open: Cannot attach to PHY (error: -19) > > If I just revert: > > "stmmac: Fix 'eth0: No PHY found' regression" > > then the issue goes away. do you have this patch "stmmac: first frame prep at the end of xmit routine" ? Or you just reverted "stmmac: Fix 'eth0: No PHY found' regression" maybe we can sum: "stmmac: Fix 'eth0: No PHY found' regression" that is introducing a problem when a box has a transceiver "stmmac: first frame prep at the end of xmit routine" That is breaking the tx path on arm64 I will check both patches on my side and let you know peppe > > Thanks, > Dinh > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement 2016-03-08 7:24 ` Giuseppe CAVALLARO @ 2016-03-08 15:45 ` Dinh Nguyen 2016-03-09 7:24 ` Giuseppe CAVALLARO 2016-03-09 8:35 ` Tomeu Vizoso 0 siblings, 2 replies; 52+ messages in thread From: Dinh Nguyen @ 2016-03-08 15:45 UTC (permalink / raw) To: Giuseppe CAVALLARO Cc: Andreas Färber, Gabriel Fernandez, Heiko Stübner, open list:ARM/Rockchip SoC..., netdev, devicetree, LAKML, Alexandre TORGUE, Fabrice GASNIER On Tue, Mar 8, 2016 at 1:24 AM, Giuseppe CAVALLARO <peppe.cavallaro@st.com> wrote: > Hi Dinh, > > On 3/8/2016 12:22 AM, Dinh Nguyen wrote: > [snip] >> >> >> I'm seeing the same issue on the SoCFPGA platform: >> >> libphy: PHY stmmac-0:ffffffff not found >> eth0: Could not attach to PHY >> stmmac_open: Cannot attach to PHY (error: -19) >> >> If I just revert: >> >> "stmmac: Fix 'eth0: No PHY found' regression" >> >> then the issue goes away. > > > do you have this patch "stmmac: first frame prep at the end of xmit routine" > ? Or you just reverted > "stmmac: Fix 'eth0: No PHY found' regression" I only reverted "stmmac: Fix 'eth0: No PHY found' regression". I do have the patch "stmmac: first frame prep at the end of the xmit routine", but I did not need to revert that patch. Dinh ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement 2016-03-08 15:45 ` Dinh Nguyen @ 2016-03-09 7:24 ` Giuseppe CAVALLARO 2016-03-09 8:35 ` Tomeu Vizoso 1 sibling, 0 replies; 52+ messages in thread From: Giuseppe CAVALLARO @ 2016-03-09 7:24 UTC (permalink / raw) To: Dinh Nguyen Cc: Andreas Färber, Gabriel Fernandez, Heiko Stübner, open list:ARM/Rockchip SoC..., netdev, devicetree, LAKML, Alexandre TORGUE, Fabrice GASNIER Hi Dinh On 3/8/2016 4:45 PM, Dinh Nguyen wrote: > On Tue, Mar 8, 2016 at 1:24 AM, Giuseppe CAVALLARO > <peppe.cavallaro@st.com> wrote: >> Hi Dinh, >> >> On 3/8/2016 12:22 AM, Dinh Nguyen wrote: >> [snip] >>> >>> >>> I'm seeing the same issue on the SoCFPGA platform: >>> >>> libphy: PHY stmmac-0:ffffffff not found >>> eth0: Could not attach to PHY >>> stmmac_open: Cannot attach to PHY (error: -19) >>> >>> If I just revert: >>> >>> "stmmac: Fix 'eth0: No PHY found' regression" >>> >>> then the issue goes away. >> >> >> do you have this patch "stmmac: first frame prep at the end of xmit routine" >> ? Or you just reverted >> "stmmac: Fix 'eth0: No PHY found' regression" > > I only reverted "stmmac: Fix 'eth0: No PHY found' regression". I do have the > patch "stmmac: first frame prep at the end of the xmit routine", but I did not > need to revert that patch. thx for this input. FYI, I am reworking the code to manage the mdio inside the driver so a patch will come soon. peppe > > Dinh > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement 2016-03-08 15:45 ` Dinh Nguyen 2016-03-09 7:24 ` Giuseppe CAVALLARO @ 2016-03-09 8:35 ` Tomeu Vizoso [not found] ` <CAAObsKD9HoEbtV_JMz_R=bcrQseDmhncRAWP9k8djksL-LMQqw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 1 sibling, 1 reply; 52+ messages in thread From: Tomeu Vizoso @ 2016-03-09 8:35 UTC (permalink / raw) To: Dinh Nguyen Cc: Giuseppe CAVALLARO, devicetree, Heiko Stübner, netdev, open list:ARM/Rockchip SoC..., LAKML, Fabrice GASNIER, Andreas Färber, Gabriel Fernandez, Alexandre TORGUE [-- Attachment #1: Type: text/plain, Size: 1684 bytes --] On 8 March 2016 at 16:45, Dinh Nguyen <dinh.linux@gmail.com> wrote: > On Tue, Mar 8, 2016 at 1:24 AM, Giuseppe CAVALLARO > <peppe.cavallaro@st.com> wrote: >> Hi Dinh, >> >> On 3/8/2016 12:22 AM, Dinh Nguyen wrote: >> [snip] >>> >>> >>> I'm seeing the same issue on the SoCFPGA platform: >>> >>> libphy: PHY stmmac-0:ffffffff not found >>> eth0: Could not attach to PHY >>> stmmac_open: Cannot attach to PHY (error: -19) >>> >>> If I just revert: >>> >>> "stmmac: Fix 'eth0: No PHY found' regression" >>> >>> then the issue goes away. >> >> >> do you have this patch "stmmac: first frame prep at the end of xmit routine" >> ? Or you just reverted >> "stmmac: Fix 'eth0: No PHY found' regression" > > I only reverted "stmmac: Fix 'eth0: No PHY found' regression". I do have the > patch "stmmac: first frame prep at the end of the xmit routine", but I did not > need to revert that patch. Hi, in order to get the onboard network on the Radxa Rock2 to work at all on today's linux-next, I had to revert both commits: * "stmmac: Fix 'eth0: No PHY found' regression" for the drivers to probe and the link to come up, and * "stmmac: first frame prep at the end of the xmit routine" for the network interface to work at all. But a few seconds into the nfsroot boot I start getting: [ 9.136701] systemd[1]: Started Load Kernel Modules. [ 18.116321] nfs: server 10.42.0.1 not responding, still trying [ 18.516224] ------------[ cut here ]------------ [ 18.521024] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:303 dev_watchdog+0x284/0x288 [ 18.529456] NETDEV WATCHDOG: eth0 (rk_gmac-dwmac): transmit queue 0 timed out I'm attaching the full boot log. Regards, Tomeu [-- Attachment #2: rock2.log --] [-- Type: text/x-log, Size: 37321 bytes --] [ 0.000000] Booting Linux on physical CPU 0x500 [ 0.000000] Linux version 4.5.0-rc7-next-20160309-00002-g1a605aab9b29 (tomeu@cizrna) (gcc version 5.3.1 20160212 (Red Hat Cross 5.3.1-2) (GCC) ) #3678 SMP Wed Mar 9 09:09:58 CET 2016 [ 0.000000] CPU: ARMv7 Processor [410fc0d1] revision 1 (ARMv7), cr=10c5387d [ 0.000000] CPU: div instructions available: patching division code [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Machine model: Radxa Rock 2 Square [ 0.000000] debug: ignoring loglevel setting. [ 0.000000] cma: Reserved 64 MiB at 0x7c000000 [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] On node 0 totalpages: 524288 [ 0.000000] free_area_init_node: node 0, pgdat c140c780, node_mem_map eeff9000 [ 0.000000] DMA zone: 1536 pages used for memmap [ 0.000000] DMA zone: 0 pages reserved [ 0.000000] DMA zone: 196608 pages, LIFO batch:31 [ 0.000000] HighMem zone: 327680 pages, LIFO batch:31 [ 0.000000] percpu: Embedded 13 pages/cpu @eef9f000 s23692 r8192 d21364 u53248 [ 0.000000] pcpu-alloc: s23692 r8192 d21364 u53248 alloc=13*4096 [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 522752 [ 0.000000] Kernel command line: console=ttyS2,115200 console=tty0 rw rootwait root=/dev/nfs nfsroot=10.42.0.1:/home/tomeu/nfsroot,vers=3 ip=dhcp ignore_loglevel log_buf_len=16M drm.debug =0x00 no_console_suspend [ 0.000000] log_buf_len: 16777216 bytes [ 0.000000] early log buf free: 129528(98%) [ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes) [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] Memory: 1979820K/2097152K available (9464K kernel code, 1081K rwdata, 4212K rodata, 2048K init, 339K bss, 51796K reserved, 65536K cma-reserved, 1245184K highmem) [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB) [ 0.000000] vmalloc : 0xf0800000 - 0xff800000 ( 240 MB) [ 0.000000] lowmem : 0xc0000000 - 0xf0000000 ( 768 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0xc0208000 - 0xc105b15c (14669 kB) [ 0.000000] .init : 0xc1100000 - 0xc1300000 (2048 kB) [ 0.000000] .data : 0xc1300000 - 0xc140e7c0 (1082 kB) [ 0.000000] .bss : 0xc1410000 - 0xc1464db8 ( 340 kB) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] Build-time adjustment of leaf fanout to 32. [ 0.000000] RCU restricting CPUs from NR_CPUS=16 to nr_cpu_ids=4. [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=4 [ 0.000000] NR_IRQS:16 nr_irqs:16 16 [ 0.000000] Architected cp15 timer(s) running at 24.00MHz (phys). [ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns [ 0.000006] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns [ 0.000022] Switching to timer-based delay loop, resolution 41ns [ 0.003799] Console: colour dummy device 80x30 [ 0.004605] console [tty0] enabled [ 0.004650] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=120000) [ 0.004699] pid_max: default: 32768 minimum: 301 [ 0.004846] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) [ 0.004880] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) [ 0.005536] CPU: Testing write buffer coherency: ok [ 0.005782] CPU0: thread -1, cpu 0, socket 5, mpidr 80000500 [ 0.006023] Setting up static identity map for 0x300000 - 0x300098 [ 0.011363] CPU1: thread -1, cpu 1, socket 5, mpidr 80000501 [ 0.013026] CPU2: thread -1, cpu 2, socket 5, mpidr 80000502 [ 0.014663] CPU3: thread -1, cpu 3, socket 5, mpidr 80000503 [ 0.014759] Brought up 4 CPUs [ 0.014877] SMP: Total of 4 processors activated (192.00 BogoMIPS). [ 0.014904] CPU: All CPU(s) started in SVC mode. [ 0.016208] devtmpfs: initialized [ 0.026190] VFP support v0.3: implementor 41 architecture 3 part 30 variant d rev 0 [ 0.026947] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 9556302231375000 ns [ 0.029040] pinctrl core: initialized pinctrl subsystem [ 0.031024] NET: Registered protocol family 16 [ 0.033357] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 0.050016] cpuidle: using governor menu [ 0.072445] No ATAGs? [ 0.072489] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers. [ 0.072546] hw-breakpoint: maximum watchpoint size is 4 bytes. [ 0.077716] Serial: AMBA PL011 UART driver [ 0.105113] vcc_sys: Failed to create debugfs directory [ 0.108851] iommu: Adding device ff930000.vop to group 0 [ 0.108952] iommu: Adding device ff940000.vop to group 1 [ 0.109175] rk_iommu ff930300.iommu: invalid resource [ 0.109307] rk_iommu ff940300.iommu: invalid resource [ 0.109741] vgaarb: loaded [ 0.110838] SCSI subsystem initialized [ 0.111057] libata version 3.00 loaded. [ 0.111396] usbcore: registered new interface driver usbfs [ 0.111485] usbcore: registered new interface driver hub [ 0.111572] usbcore: registered new device driver usb [ 0.113143] pps_core: LinuxPPS API ver. 1 registered [ 0.113173] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> [ 0.113240] PTP clock support registered [ 0.113476] EDAC MC: Ver: 3.0.0 [ 0.116173] clocksource: Switched to clocksource arch_sys_counter [ 0.128116] NET: Registered protocol family 2 [ 0.128729] TCP established hash table entries: 8192 (order: 3, 32768 bytes) [ 0.128860] TCP bind hash table entries: 8192 (order: 4, 65536 bytes) [ 0.129068] TCP: Hash tables configured (established 8192 bind 8192) [ 0.129146] UDP hash table entries: 512 (order: 2, 16384 bytes) [ 0.129211] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes) [ 0.129423] NET: Registered protocol family 1 [ 0.129708] RPC: Registered named UNIX socket transport module. [ 0.129740] RPC: Registered udp transport module. [ 0.129765] RPC: Registered tcp transport module. [ 0.129789] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 0.129828] PCI: CLS 0 bytes, default 64 [ 0.130714] hw perfevents: enabled with armv7_cortex_a12 PMU driver, 7 counters available [ 0.132628] futex hash table entries: 1024 (order: 4, 65536 bytes) [ 0.133523] workingset: timestamp_bits=28 max_order=19 bucket_order=0 [ 0.145220] squashfs: version 4.0 (2009/01/31) Phillip Lougher [ 0.146260] NFS: Registering the id_resolver key type [ 0.146312] Key type id_resolver registered [ 0.146338] Key type id_legacy registered [ 0.146448] ntfs: driver 2.1.32 [Flags: R/O]. [ 0.147904] bounce: pool size: 64 pages [ 0.148147] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 248) [ 0.148199] io scheduler noop registered [ 0.148229] io scheduler deadline registered [ 0.148285] io scheduler cfq registered (default) [ 0.165943] dma-pl330 ff250000.dma-controller: Loaded driver for PL330 DMAC-241330 [ 0.165996] dma-pl330 ff250000.dma-controller: DBUFF-128x8bytes Num_Chans-8 Num_Peri-20 Num_Events-16 [ 0.166907] dma-pl330 ffb20000.dma-controller: Loaded driver for PL330 DMAC-241330 [ 0.166960] dma-pl330 ffb20000.dma-controller: DBUFF-64x8bytes Num_Chans-5 Num_Peri-6 Num_Events-10 [ 0.233974] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [ 0.236402] console [ttyS2] disabled [ 0.236459] ff690000.serial: ttyS2 at MMIO 0xff690000 (irq = 33, base_baud = 1500000) is a 16550A [ 0.950690] console [ttyS2] enabled [ 0.955745] SuperH (H)SCI(F) driver initialized [ 0.961396] msm_serial: driver initialized [ 0.965727] STMicroelectronics ASC driver initialized [ 0.972715] [drm] Initialized drm 1.1.0 20060810 [ 0.992956] brd: module loaded [ 1.002486] loop: module loaded [ 1.014437] libphy: Fixed MDIO Bus: probed [ 1.019318] CAN device driver interface [ 1.025220] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.3.0-k [ 1.032219] igb: Copyright (c) 2007-2014 Intel Corporation. [ 1.040261] rk_gmac-dwmac ff290000.ethernet: phy regulator is not available yet, deferred probing [ 1.051056] pegasus: v0.9.3 (2013/04/25), Pegasus/Pegasus II USB Ethernet driver [ 1.058568] usbcore: registered new interface driver pegasus [ 1.064341] usbcore: registered new interface driver asix [ 1.069838] usbcore: registered new interface driver ax88179_178a [ 1.076034] usbcore: registered new interface driver cdc_ether [ 1.081978] usbcore: registered new interface driver smsc75xx [ 1.087839] usbcore: registered new interface driver smsc95xx [ 1.093682] usbcore: registered new interface driver net1080 [ 1.099440] usbcore: registered new interface driver cdc_subset [ 1.105455] usbcore: registered new interface driver zaurus [ 1.111195] usbcore: registered new interface driver cdc_ncm [ 1.118756] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 1.125334] ehci-pci: EHCI PCI platform driver [ 1.129878] ehci-platform: EHCI generic platform driver [ 1.135469] ehci-omap: OMAP-EHCI Host Controller driver [ 1.140900] ehci-orion: EHCI orion driver [ 1.145108] SPEAr-ehci: EHCI SPEAr driver [ 1.149318] ehci-st: EHCI STMicroelectronics driver [ 1.154397] ehci-exynos: EHCI EXYNOS driver [ 1.158801] ehci-atmel: EHCI Atmel driver [ 1.163007] tegra-ehci: Tegra EHCI driver [ 1.167241] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 1.173478] ohci-pci: OHCI PCI platform driver [ 1.178027] ohci-platform: OHCI generic platform driver [ 1.183480] ohci-omap3: OHCI OMAP3 driver [ 1.187692] SPEAr-ohci: OHCI SPEAr driver [ 1.191906] ohci-st: OHCI STMicroelectronics driver [ 1.196983] ohci-atmel: OHCI Atmel driver [ 1.201859] usbcore: registered new interface driver usb-storage [ 1.209737] mousedev: PS/2 mouse device common for all mice [ 1.219227] i2c /dev entries driver [ 1.224151] rk3x-i2c ff170000.i2c: using default SCL frequency: 100000 [ 1.231239] rk3x-i2c ff170000.i2c: Initialized RK3xxx I2C bus at f0952000 [ 1.238196] rk3x-i2c ff650000.i2c: using default SCL frequency: 100000 [ 1.270761] fan53555-regulator 0-0040: FAN53555 Option[8] Rev[1] Detected! [ 1.281994] fan53555-regulator 0-0041: FAN53555 Option[8] Rev[1] Detected! [ 1.292149] rk3x-i2c ff650000.i2c: Initialized RK3xxx I2C bus at f0954000 [ 1.301340] VCC_IO: supplied by vcc_sys [ 1.306860] VCC_20: supplied by vcc_sys [ 1.311259] VCC_18: supplied by VCC_20 [ 1.317150] vcc_sys: supplied by VCC_IO [ 1.321628] VCCIO_PMU: supplied by vcc_sys [ 1.330514] VCCIO_SD: supplied by VCC_IO [ 1.342480] watchdog: Invalid min and max timeout values, resetting to 0! [ 1.351933] vdd_cpu: supplied by vcc_sys [ 1.358469] cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 500000 KHz [ 1.366084] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed to: 600000 KHz [ 1.376024] sdhci: Secure Digital Host Controller Interface driver [ 1.382238] sdhci: Copyright(c) Pierre Ossman [ 1.387964] Synopsys Designware Multimedia Card Interface Driver [ 1.394681] dwmmc_rockchip ff0c0000.dwmmc: IDMAC supports 32-bit address mode. [ 1.401938] dwmmc_rockchip ff0c0000.dwmmc: Using internal DMA controller. [ 1.408727] dwmmc_rockchip ff0c0000.dwmmc: Version ID is 270a [ 1.414488] dwmmc_rockchip ff0c0000.dwmmc: DW MMC controller at irq 29,32 bit host data width,256 deep fifo [ 1.424247] vcc_sd: supplied by VCC_IO [ 1.441185] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0) [ 1.461172] dwmmc_rockchip ff0c0000.dwmmc: 1 slots initialized [ 1.467178] dwmmc_rockchip ff0d0000.dwmmc: IDMAC supports 32-bit address mode. [ 1.475567] dwmmc_rockchip ff0d0000.dwmmc: Using internal DMA controller. [ 1.482366] dwmmc_rockchip ff0d0000.dwmmc: Version ID is 270a [ 1.488136] dwmmc_rockchip ff0d0000.dwmmc: DW MMC controller at irq 30,32 bit host data width,256 deep fifo [ 1.499701] dwmmc_rockchip ff0f0000.dwmmc: IDMAC supports 32-bit address mode. [ 1.506965] dwmmc_rockchip ff0f0000.dwmmc: Using internal DMA controller. [ 1.513763] dwmmc_rockchip ff0f0000.dwmmc: Version ID is 270a [ 1.519532] dwmmc_rockchip ff0f0000.dwmmc: DW MMC controller at irq 31,32 bit host data width,256 deep fifo [ 1.529894] dwmmc_rockchip ff0f0000.dwmmc: allocated mmc-pwrseq [ 1.551407] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0) [ 1.571179] dwmmc_rockchip ff0f0000.dwmmc: 1 slots initialized [ 1.577309] sdhci-pltfm: SDHCI platform and OF driver helper [ 1.584113] ledtrig-cpu: registered to indicate activity on CPUs [ 1.590355] usbcore: registered new interface driver usbhid [ 1.595932] usbhid: USB HID core driver [ 1.602165] NET: Registered protocol family 10 [ 1.606982] sit: IPv6 over IPv4 tunneling driver [ 1.611927] NET: Registered protocol family 17 [ 1.616390] can: controller area network core (rev 20120528 abi 9) [ 1.622603] NET: Registered protocol family 29 [ 1.627057] can: raw protocol (rev 20120528) [ 1.631335] can: broadcast manager protocol (rev 20120528 t) [ 1.637002] can: netlink gateway (rev 20130117) max_hops=1 [ 1.642681] Key type dns_resolver registered [ 1.647095] ThumbEE CPU extension supported. [ 1.651382] Registering SWP/SWPB emulation handler [ 1.658144] rk_gmac-dwmac ff290000.ethernet: clock input or output? (input). [ 1.665208] rk_gmac-dwmac ff290000.ethernet: TX delay(0x30). [ 1.670872] rk_gmac-dwmac ff290000.ethernet: RX delay(0x10). [ 1.676539] rk_gmac-dwmac ff290000.ethernet: init for RGMII [ 1.682151] rk_gmac-dwmac ff290000.ethernet: clock input from PHY [ 1.693266] stmmac - user ID: 0x10, Synopsys ID: 0x35 [ 1.698316] Ring mode enabled [ 1.701370] DMA HW capability register supported [ 1.705890] Normal descriptors [ 1.709219] RX Checksum Offload Engine supported (type 2) [ 1.714700] TX Checksum insertion supported [ 1.714967] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0) [ 1.715267] mmc1: new high speed MMC card at address 0001 [ 1.715445] mmcblk0: mmc1:0001 032GE4 29.1 GiB [ 1.715511] mmcblk0boot0: mmc1:0001 032GE4 partition 1 4.00 MiB [ 1.715576] mmcblk0boot1: mmc1:0001 032GE4 partition 2 4.00 MiB [ 1.750450] Wake-Up On Lan supported [ 1.754130] Enable RX Mitigation via HW Watchdog Timer [ 1.759625] rk_gmac-dwmac ff290000.ethernet eth0: No MDIO subnode found [ 1.819914] libphy: stmmac: probed [ 1.823323] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active [ 1.829676] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01) [ 1.836618] dwmmc_rockchip ff0d0000.dwmmc: IDMAC supports 32-bit address mode. [ 1.843887] dwmmc_rockchip ff0d0000.dwmmc: Using internal DMA controller. [ 1.850676] dwmmc_rockchip ff0d0000.dwmmc: Version ID is 270a [ 1.856431] dwmmc_rockchip ff0d0000.dwmmc: DW MMC controller at irq 30,32 bit host data width,256 deep fifo [ 1.867572] hctosys: unable to open rtc device (rtc0) [ 1.888555] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 7.876704] rk_gmac-dwmac ff290000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx [ 7.886213] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 7.901274] Sending DHCP requests ., OK [ 7.966192] IP-Config: Got DHCP answer from 10.42.0.1, my address is 10.42.0.251 [ 7.973961] IP-Config: Complete: [ 7.977274] device=eth0, hwaddr=1a:75:6b:5e:1d:a7, ipaddr=10.42.0.251, mask=255.255.255.0, gw=10.42.0.1 [ 7.987186] host=10.42.0.251, domain=, nis-domain=(none) [ 7.992985] bootserver=10.42.0.1, rootserver=10.42.0.1, rootpath= nameserver0=10.42.0.1 [ 8.001942] vcc_sd: disabling [ 8.018553] VFS: Mounted root (nfs filesystem) on device 0:13. [ 8.024999] devtmpfs: mounted [ 8.030012] Freeing unused kernel memory: 2048K (c1100000 - c1300000) [ 8.266343] random: systemd urandom read with 15 bits of entropy available [ 8.278232] systemd[1]: systemd 228 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUT ILS +KMOD -IDN) [ 8.297174] systemd[1]: Detected architecture arm. [ 8.307442] systemd[1]: Set hostname to <singularity>. [ 8.378108] ttyS2 - failed to request DMA [ 8.883579] systemd[1]: fstrim.timer: Cannot add dependency job, ignoring: Unit fstrim.timer failed to load: No such file or directory. [ 8.896133] systemd[1]: display-manager.service: Cannot add dependency job, ignoring: Unit display-manager.service failed to load: No such file or directory. [ 8.913610] systemd[1]: Started Forward Password Requests to Wall Directory Watch. [ 8.921687] systemd[1]: Created slice User and Session Slice. [ 8.927780] systemd[1]: Listening on Device-mapper event daemon FIFOs. [ 8.935216] systemd[1]: Listening on LVM2 poll daemon socket. [ 8.941202] systemd[1]: Reached target Swap. [ 8.946324] systemd[1]: Listening on Journal Socket (/dev/log). [ 8.952580] systemd[1]: Listening on Journal Socket. [ 8.958406] systemd[1]: Listening on udev Control Socket. [ 8.964147] systemd[1]: Created slice System Slice. [ 8.991361] systemd[1]: Starting Load Kernel Modules... [ 8.996894] systemd[1]: Created slice system-serial\x2dgetty.slice. [ 9.003311] systemd[1]: Reached target Slices. [ 9.008537] systemd[1]: Mounting Debug File System... [ 9.013868] systemd[1]: Created slice system-getty.slice. [ 9.019451] systemd[1]: Reached target Encrypted Volumes. [ 9.025087] systemd[1]: Listening on LVM2 metadata daemon socket. [ 9.031357] systemd[1]: Listening on udev Kernel Socket. [ 9.071378] systemd[1]: Starting Journal Service... [ 9.076459] systemd[1]: Reached target Remote File Systems (Pre). [ 9.082744] systemd[1]: Reached target Remote File Systems. [ 9.089950] systemd[1]: Starting Create list of required static device nodes for the current kernel... [ 9.099935] systemd[1]: Listening on /dev/initctl Compatibility Named Pipe. [ 9.107971] systemd[1]: Starting Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling... [ 9.123541] systemd[1]: Starting LSB: Set console font and keymap... [ 9.131313] systemd[1]: Mounted Debug File System. [ 9.136701] systemd[1]: Started Load Kernel Modules. [ 18.116321] nfs: server 10.42.0.1 not responding, still trying [ 18.516224] ------------[ cut here ]------------ [ 18.521024] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:303 dev_watchdog+0x284/0x288 [ 18.529456] NETDEV WATCHDOG: eth0 (rk_gmac-dwmac): transmit queue 0 timed out [ 18.536690] Modules linked in: [ 18.539889] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.5.0-rc7-next-20160309-00002-g1a605aab9b29 #3678 [ 18.549431] Hardware name: Rockchip (Device Tree) [ 18.554289] [<c0310390>] (unwind_backtrace) from [<c030ba88>] (show_stack+0x10/0x14) [ 18.562221] [<c030ba88>] (show_stack) from [<c05904a8>] (dump_stack+0x90/0xa4) [ 18.569634] [<c05904a8>] (dump_stack) from [<c0341c6c>] (__warn+0xe8/0x100) [ 18.576732] [<c0341c6c>] (__warn) from [<c0341cbc>] (warn_slowpath_fmt+0x38/0x48) [ 18.584406] [<c0341cbc>] (warn_slowpath_fmt) from [<c0a7b598>] (dev_watchdog+0x284/0x288) [ 18.592781] [<c0a7b598>] (dev_watchdog) from [<c0394528>] (call_timer_fn+0x24/0x98) [ 18.600628] [<c0394528>] (call_timer_fn) from [<c0394738>] (run_timer_softirq+0x19c/0x214) [ 18.609086] [<c0394738>] (run_timer_softirq) from [<c0346098>] (__do_softirq+0xfc/0x214) [ 18.617358] [<c0346098>] (__do_softirq) from [<c0346450>] (irq_exit+0xb0/0x118) [ 18.624839] [<c0346450>] (irq_exit) from [<c0385120>] (__handle_domain_irq+0x60/0xb4) [ 18.632845] [<c0385120>] (__handle_domain_irq) from [<c030177c>] (gic_handle_irq+0x54/0x94) [ 18.641369] [<c030177c>] (gic_handle_irq) from [<c030c5d4>] (__irq_svc+0x54/0x70) [ 18.648997] Exception stack(0xed0abf88 to 0xed0abfd0) [ 18.654164] bf80: 00000001 00000000 00000000 c031b220 ed0aa000 c13024a4 [ 18.662516] bfa0: 00000000 00000000 c1208580 c1302504 c130250c c140e568 00000000 ed0abfd8 [ 18.670850] bfc0: c030888c c0308890 600f0013 ffffffff [ 18.676031] [<c030c5d4>] (__irq_svc) from [<c0308890>] (arch_cpu_idle+0x38/0x3c) [ 18.683615] [<c0308890>] (arch_cpu_idle) from [<c0379124>] (cpu_startup_entry+0x1b8/0x21c) [ 18.692055] [<c0379124>] (cpu_startup_entry) from [<00301c6c>] (0x301c6c) [ 18.698948] ---[ end trace 9f6653e6701f8dc4 ]--- [ 22.536324] nfs: server 10.42.0.1 not responding, still trying [ 26.956295] nfs: server 10.42.0.1 not responding, still trying [ 31.376321] nfs: server 10.42.0.1 not responding, still trying [ 40.196354] nfs: server 10.42.0.1 not responding, still trying [ 42.401464] nfs: server 10.42.0.1 not responding, still trying [ 44.606505] nfs: server 10.42.0.1 not responding, still trying [ 46.816350] nfs: server 10.42.0.1 not responding, still trying [ 55.636399] nfs: server 10.42.0.1 not responding, still trying [ 64.456407] nfs: server 10.42.0.1 not responding, still trying [ 73.276374] nfs: server 10.42.0.1 not responding, still trying [ 240.096350] INFO: task systemd-journal:121 blocked for more than 120 seconds. [ 240.103715] Tainted: G W 4.5.0-rc7-next-20160309-00002-g1a605aab9b29 #3678 [ 240.112466] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.120501] systemd-journal D c0b5285c 0 121 1 0x00000000 [ 240.127183] [<c0b5285c>] (__schedule) from [<c0b52c3c>] (schedule+0x44/0x9c) [ 240.134437] [<c0b52c3c>] (schedule) from [<c0b5565c>] (schedule_timeout+0x16c/0x1b4) [ 240.142432] [<c0b5565c>] (schedule_timeout) from [<c0b5264c>] (io_schedule_timeout+0x7c/0xb4) [ 240.151244] [<c0b5264c>] (io_schedule_timeout) from [<c0b53500>] (bit_wait_io+0x10/0x5c) [ 240.159568] [<c0b53500>] (bit_wait_io) from [<c0b530a8>] (__wait_on_bit+0x84/0xb8) [ 240.167394] [<c0b530a8>] (__wait_on_bit) from [<c03c9ac4>] (wait_on_page_bit+0xd0/0xd8) [ 240.175659] [<c03c9ac4>] (wait_on_page_bit) from [<c03c9b94>] (__filemap_fdatawait_range+0xc8/0x110) [ 240.185055] [<c03c9b94>] (__filemap_fdatawait_range) from [<c03c9bf4>] (filemap_fdatawait_range+0x18/0x34) [ 240.194964] [<c03c9bf4>] (filemap_fdatawait_range) from [<c03cbf2c>] (filemap_write_and_wait_range+0x54/0x74) [ 240.205129] [<c03cbf2c>] (filemap_write_and_wait_range) from [<c04d6344>] (nfs_file_fsync+0x84/0x9c) [ 240.214514] [<c04d6344>] (nfs_file_fsync) from [<c043d410>] (do_fsync+0x3c/0x64) [ 240.222177] [<c043d410>] (do_fsync) from [<c0307dc0>] (ret_fast_syscall+0x0/0x3c) [ 360.226438] INFO: task systemd-journal:121 blocked for more than 120 seconds. [ 360.233769] Tainted: G W 4.5.0-rc7-next-20160309-00002-g1a605aab9b29 #3678 [ 360.242505] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 360.250529] systemd-journal D c0b5285c 0 121 1 0x00000000 [ 360.257198] [<c0b5285c>] (__schedule) from [<c0b52c3c>] (schedule+0x44/0x9c) [ 360.264440] [<c0b52c3c>] (schedule) from [<c0b5565c>] (schedule_timeout+0x16c/0x1b4) [ 360.272426] [<c0b5565c>] (schedule_timeout) from [<c0b5264c>] (io_schedule_timeout+0x7c/0xb4) [ 360.281188] [<c0b5264c>] (io_schedule_timeout) from [<c0b53500>] (bit_wait_io+0x10/0x5c) [ 360.289552] [<c0b53500>] (bit_wait_io) from [<c0b530a8>] (__wait_on_bit+0x84/0xb8) [ 360.297366] [<c0b530a8>] (__wait_on_bit) from [<c03c9ac4>] (wait_on_page_bit+0xd0/0xd8) [ 360.305629] [<c03c9ac4>] (wait_on_page_bit) from [<c03c9b94>] (__filemap_fdatawait_range+0xc8/0x110) [ 360.315017] [<c03c9b94>] (__filemap_fdatawait_range) from [<c03c9bf4>] (filemap_fdatawait_range+0x18/0x34) [ 360.324953] [<c03c9bf4>] (filemap_fdatawait_range) from [<c03cbf2c>] (filemap_write_and_wait_range+0x54/0x74) [ 360.335124] [<c03cbf2c>] (filemap_write_and_wait_range) from [<c04d6344>] (nfs_file_fsync+0x84/0x9c) [ 360.344510] [<c04d6344>] (nfs_file_fsync) from [<c043d410>] (do_fsync+0x3c/0x64) [ 360.352158] [<c043d410>] (do_fsync) from [<c0307dc0>] (ret_fast_syscall+0x0/0x3c) [ 480.356357] INFO: task systemd-journal:121 blocked for more than 120 seconds. [ 480.363682] Tainted: G W 4.5.0-rc7-next-20160309-00002-g1a605aab9b29 #3678 [ 480.372422] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 480.380487] systemd-journal D c0b5285c 0 121 1 0x00000000 [ 480.387172] [<c0b5285c>] (__schedule) from [<c0b52c3c>] (schedule+0x44/0x9c) [ 480.394423] [<c0b52c3c>] (schedule) from [<c0b5565c>] (schedule_timeout+0x16c/0x1b4) [ 480.402415] [<c0b5565c>] (schedule_timeout) from [<c0b5264c>] (io_schedule_timeout+0x7c/0xb4) [ 480.411180] [<c0b5264c>] (io_schedule_timeout) from [<c0b53500>] (bit_wait_io+0x10/0x5c) [ 480.419553] [<c0b53500>] (bit_wait_io) from [<c0b530a8>] (__wait_on_bit+0x84/0xb8) [ 480.427372] [<c0b530a8>] (__wait_on_bit) from [<c03c9ac4>] (wait_on_page_bit+0xd0/0xd8) [ 480.435632] [<c03c9ac4>] (wait_on_page_bit) from [<c03c9b94>] (__filemap_fdatawait_range+0xc8/0x110) [ 480.445029] [<c03c9b94>] (__filemap_fdatawait_range) from [<c03c9bf4>] (filemap_fdatawait_range+0x18/0x34) [ 480.454937] [<c03c9bf4>] (filemap_fdatawait_range) from [<c03cbf2c>] (filemap_write_and_wait_range+0x54/0x74) [ 480.465101] [<c03cbf2c>] (filemap_write_and_wait_range) from [<c04d6344>] (nfs_file_fsync+0x84/0x9c) [ 480.474480] [<c04d6344>] (nfs_file_fsync) from [<c043d410>] (do_fsync+0x3c/0x64) [ 480.482141] [<c043d410>] (do_fsync) from [<c0307dc0>] (ret_fast_syscall+0x0/0x3c) [ 600.486439] INFO: task systemd-journal:121 blocked for more than 120 seconds. [ 600.493768] Tainted: G W 4.5.0-rc7-next-20160309-00002-g1a605aab9b29 #3678 [ 600.502506] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 600.510535] systemd-journal D c0b5285c 0 121 1 0x00000000 [ 600.517203] [<c0b5285c>] (__schedule) from [<c0b52c3c>] (schedule+0x44/0x9c) [ 600.524447] [<c0b52c3c>] (schedule) from [<c0b5565c>] (schedule_timeout+0x16c/0x1b4) [ 600.532433] [<c0b5565c>] (schedule_timeout) from [<c0b5264c>] (io_schedule_timeout+0x7c/0xb4) [ 600.541236] [<c0b5264c>] (io_schedule_timeout) from [<c0b53500>] (bit_wait_io+0x10/0x5c) [ 600.549549] [<c0b53500>] (bit_wait_io) from [<c0b530a8>] (__wait_on_bit+0x84/0xb8) [ 600.557363] [<c0b530a8>] (__wait_on_bit) from [<c03c9ac4>] (wait_on_page_bit+0xd0/0xd8) [ 600.565619] [<c03c9ac4>] (wait_on_page_bit) from [<c03c9b94>] (__filemap_fdatawait_range+0xc8/0x110) [ 600.575009] [<c03c9b94>] (__filemap_fdatawait_range) from [<c03c9bf4>] (filemap_fdatawait_range+0x18/0x34) [ 600.584947] [<c03c9bf4>] (filemap_fdatawait_range) from [<c03cbf2c>] (filemap_write_and_wait_range+0x54/0x74) [ 600.595121] [<c03cbf2c>] (filemap_write_and_wait_range) from [<c04d6344>] (nfs_file_fsync+0x84/0x9c) [ 600.604509] [<c04d6344>] (nfs_file_fsync) from [<c043d410>] (do_fsync+0x3c/0x64) [ 600.612157] [<c043d410>] (do_fsync) from [<c0307dc0>] (ret_fast_syscall+0x0/0x3c) [ 720.616374] INFO: task systemd-journal:121 blocked for more than 120 seconds. [ 720.623707] Tainted: G W 4.5.0-rc7-next-20160309-00002-g1a605aab9b29 #3678 [ 720.632449] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 720.640480] systemd-journal D c0b5285c 0 121 1 0x00000000 [ 720.647155] [<c0b5285c>] (__schedule) from [<c0b52c3c>] (schedule+0x44/0x9c) [ 720.654404] [<c0b52c3c>] (schedule) from [<c0b5565c>] (schedule_timeout+0x16c/0x1b4) [ 720.662399] [<c0b5565c>] (schedule_timeout) from [<c0b5264c>] (io_schedule_timeout+0x7c/0xb4) [ 720.671162] [<c0b5264c>] (io_schedule_timeout) from [<c0b53500>] (bit_wait_io+0x10/0x5c) [ 720.679536] [<c0b53500>] (bit_wait_io) from [<c0b530a8>] (__wait_on_bit+0x84/0xb8) [ 720.687348] [<c0b530a8>] (__wait_on_bit) from [<c03c9ac4>] (wait_on_page_bit+0xd0/0xd8) [ 720.695611] [<c03c9ac4>] (wait_on_page_bit) from [<c03c9b94>] (__filemap_fdatawait_range+0xc8/0x110) [ 720.705004] [<c03c9b94>] (__filemap_fdatawait_range) from [<c03c9bf4>] (filemap_fdatawait_range+0x18/0x34) [ 720.714908] [<c03c9bf4>] (filemap_fdatawait_range) from [<c03cbf2c>] (filemap_write_and_wait_range+0x54/0x74) [ 720.725067] [<c03cbf2c>] (filemap_write_and_wait_range) from [<c04d6344>] (nfs_file_fsync+0x84/0x9c) [ 720.734446] [<c04d6344>] (nfs_file_fsync) from [<c043d410>] (do_fsync+0x3c/0x64) [ 720.742095] [<c043d410>] (do_fsync) from [<c0307dc0>] (ret_fast_syscall+0x0/0x3c) [ 840.746440] INFO: task systemd-journal:121 blocked for more than 120 seconds. [ 840.753769] Tainted: G W 4.5.0-rc7-next-20160309-00002-g1a605aab9b29 #3678 [ 840.762507] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 840.770537] systemd-journal D c0b5285c 0 121 1 0x00000000 [ 840.777199] [<c0b5285c>] (__schedule) from [<c0b52c3c>] (schedule+0x44/0x9c) [ 840.784440] [<c0b52c3c>] (schedule) from [<c0b5565c>] (schedule_timeout+0x16c/0x1b4) [ 840.792423] [<c0b5565c>] (schedule_timeout) from [<c0b5264c>] (io_schedule_timeout+0x7c/0xb4) [ 840.801184] [<c0b5264c>] (io_schedule_timeout) from [<c0b53500>] (bit_wait_io+0x10/0x5c) [ 840.809535] [<c0b53500>] (bit_wait_io) from [<c0b530a8>] (__wait_on_bit+0x84/0xb8) [ 840.817349] [<c0b530a8>] (__wait_on_bit) from [<c03c9ac4>] (wait_on_page_bit+0xd0/0xd8) [ 840.825605] [<c03c9ac4>] (wait_on_page_bit) from [<c03c9b94>] (__filemap_fdatawait_range+0xc8/0x110) [ 840.834994] [<c03c9b94>] (__filemap_fdatawait_range) from [<c03c9bf4>] (filemap_fdatawait_range+0x18/0x34) [ 840.844930] [<c03c9bf4>] (filemap_fdatawait_range) from [<c03cbf2c>] (filemap_write_and_wait_range+0x54/0x74) [ 840.855104] [<c03cbf2c>] (filemap_write_and_wait_range) from [<c04d6344>] (nfs_file_fsync+0x84/0x9c) [ 840.864476] [<c04d6344>] (nfs_file_fsync) from [<c043d410>] (do_fsync+0x3c/0x64) [ 840.872125] [<c043d410>] (do_fsync) from [<c0307dc0>] (ret_fast_syscall+0x0/0x3c) [ 951.083911] nfs: server 10.42.0.1 OK [ 951.088284] nfs: server 10.42.0.1 OK [ 951.092713] nfs: server 10.42.0.1 OK [ 951.096824] nfs: server 10.42.0.1 OK [ 951.100826] nfs: server 10.42.0.1 OK [ 951.105120] nfs: server 10.42.0.1 OK [ 951.109072] nfs: server 10.42.0.1 OK [ 951.109343] nfs: server 10.42.0.1 OK [ 951.109398] nfs: server 10.42.0.1 OK [ 951.109772] nfs: server 10.42.0.1 OK [ 960.876393] INFO: task systemd-journal:121 blocked for more than 120 seconds. [ 960.883733] Tainted: G W 4.5.0-rc7-next-20160309-00002-g1a605aab9b29 #3678 [ 960.892474] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 960.900507] systemd-journal D c0b5285c 0 121 1 0x00000000 [ 960.907187] [<c0b5285c>] (__schedule) from [<c0b52c3c>] (schedule+0x44/0x9c) [ 960.914433] [<c0b52c3c>] (schedule) from [<c0b5565c>] (schedule_timeout+0x16c/0x1b4) [ 960.922428] [<c0b5565c>] (schedule_timeout) from [<c0b5264c>] (io_schedule_timeout+0x7c/0xb4) [ 960.931240] [<c0b5264c>] (io_schedule_timeout) from [<c0b53500>] (bit_wait_io+0x10/0x5c) [ 960.939562] [<c0b53500>] (bit_wait_io) from [<c0b530a8>] (__wait_on_bit+0x84/0xb8) [ 960.947385] [<c0b530a8>] (__wait_on_bit) from [<c03c9ac4>] (wait_on_page_bit+0xd0/0xd8) [ 960.955649] [<c03c9ac4>] (wait_on_page_bit) from [<c03c9b94>] (__filemap_fdatawait_range+0xc8/0x110) [ 960.965048] [<c03c9b94>] (__filemap_fdatawait_range) from [<c03c9bf4>] (filemap_fdatawait_range+0x18/0x34) [ 960.974957] [<c03c9bf4>] (filemap_fdatawait_range) from [<c03cbf2c>] (filemap_write_and_wait_range+0x54/0x74) [ 960.985121] [<c03cbf2c>] (filemap_write_and_wait_range) from [<c04d6344>] (nfs_file_fsync+0x84/0x9c) [ 960.994519] [<c04d6344>] (nfs_file_fsync) from [<c043d410>] (do_fsync+0x3c/0x64) [ 961.002173] [<c043d410>] (do_fsync) from [<c0307dc0>] (ret_fast_syscall+0x0/0x3c) [ 1011.196416] nfs: server 10.42.0.1 not responding, still trying [ 1011.202460] nfs: server 10.42.0.1 not responding, still trying [ 1011.208482] nfs: server 10.42.0.1 not responding, still trying [ 1011.214514] nfs: server 10.42.0.1 not responding, still trying [ 1081.006782] INFO: task systemd-journal:121 blocked for more than 120 seconds. [ 1081.014104] Tainted: G W 4.5.0-rc7-next-20160309-00002-g1a605aab9b29 #3678 [ 1081.022843] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1081.030871] systemd-journal D c0b5285c 0 121 1 0x00000000 [ 1081.037530] [<c0b5285c>] (__schedule) from [<c0b52c3c>] (schedule+0x44/0x9c) [ 1081.044773] [<c0b52c3c>] (schedule) from [<c0b5565c>] (schedule_timeout+0x16c/0x1b4) [ 1081.052758] [<c0b5565c>] (schedule_timeout) from [<c0b5264c>] (io_schedule_timeout+0x7c/0xb4) [ 1081.061522] [<c0b5264c>] (io_schedule_timeout) from [<c0b53500>] (bit_wait_io+0x10/0x5c) [ 1081.069845] [<c0b53500>] (bit_wait_io) from [<c0b530a8>] (__wait_on_bit+0x84/0xb8) [ 1081.077660] [<c0b530a8>] (__wait_on_bit) from [<c03c9ac4>] (wait_on_page_bit+0xd0/0xd8) [ 1081.085920] [<c03c9ac4>] (wait_on_page_bit) from [<c03c9b94>] (__filemap_fdatawait_range+0xc8/0x110) [ 1081.095299] [<c03c9b94>] (__filemap_fdatawait_range) from [<c03c9bf4>] (filemap_fdatawait_range+0x18/0x34) [ 1081.105241] [<c03c9bf4>] (filemap_fdatawait_range) from [<c03cbf2c>] (filemap_write_and_wait_range+0x54/0x74) [ 1081.115415] [<c03cbf2c>] (filemap_write_and_wait_range) from [<c04d6344>] (nfs_file_fsync+0x84/0x9c) [ 1081.124800] [<c04d6344>] (nfs_file_fsync) from [<c043d410>] (do_fsync+0x3c/0x64) [ 1081.132450] [<c043d410>] (do_fsync) from [<c0307dc0>] (ret_fast_syscall+0x0/0x3c) [ 1201.136378] INFO: task systemd-journal:121 blocked for more than 120 seconds. [ 1201.143722] Tainted: G W 4.5.0-rc7-next-20160309-00002-g1a605aab9b29 #3678 [ 1201.152471] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1201.160502] systemd-journal D c0b5285c 0 121 1 0x00000000 [ 1201.167176] [<c0b5285c>] (__schedule) from [<c0b52c3c>] (schedule+0x44/0x9c) [ 1201.174429] [<c0b52c3c>] (schedule) from [<c0b5565c>] (schedule_timeout+0x16c/0x1b4) [ 1201.182421] [<c0b5565c>] (schedule_timeout) from [<c0b5264c>] (io_schedule_timeout+0x7c/0xb4) [ 1201.191187] [<c0b5264c>] (io_schedule_timeout) from [<c0b53500>] (bit_wait_io+0x10/0x5c) [ 1201.199555] [<c0b53500>] (bit_wait_io) from [<c0b530a8>] (__wait_on_bit+0x84/0xb8) [ 1201.207374] [<c0b530a8>] (__wait_on_bit) from [<c03c9ac4>] (wait_on_page_bit+0xd0/0xd8) [ 1201.215639] [<c03c9ac4>] (wait_on_page_bit) from [<c03c9b94>] (__filemap_fdatawait_range+0xc8/0x110) [ 1201.225034] [<c03c9b94>] (__filemap_fdatawait_range) from [<c03c9bf4>] (filemap_fdatawait_range+0x18/0x34) [ 1201.234944] [<c03c9bf4>] (filemap_fdatawait_range) from [<c03cbf2c>] (filemap_write_and_wait_range+0x54/0x74) [ 1201.245106] [<c03cbf2c>] (filemap_write_and_wait_range) from [<c04d6344>] (nfs_file_fsync+0x84/0x9c) [ 1201.254490] [<c04d6344>] (nfs_file_fsync) from [<c043d410>] (do_fsync+0x3c/0x64) [ 1201.262151] [<c043d410>] (do_fsync) from [<c0307dc0>] (ret_fast_syscall+0x0/0x3c) [ 1321.266429] INFO: task systemd-journal:121 blocked for more than 120 seconds. [ 1321.273764] Tainted: G W 4.5.0-rc7-next-20160309-00002-g1a605aab9b29 #3678 [ 1321.282505] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1321.290534] systemd-journal D c0b5285c 0 121 1 0x00000000 [ 1321.297198] [<c0b5285c>] (__schedule) from [<c0b52c3c>] (schedule+0x44/0x9c) [ 1321.304443] [<c0b52c3c>] (schedule) from [<c0b5565c>] (schedule_timeout+0x16c/0x1b4) [ 1321.312427] [<c0b5565c>] (schedule_timeout) from [<c0b5264c>] (io_schedule_timeout+0x7c/0xb4) [ 1321.321231] [<c0b5264c>] (io_schedule_timeout) from [<c0b53500>] (bit_wait_io+0x10/0x5c) [ 1321.329549] [<c0b53500>] (bit_wait_io) from [<c0b530a8>] (__wait_on_bit+0x84/0xb8) [ 1321.337364] [<c0b530a8>] (__wait_on_bit) from [<c03c9ac4>] (wait_on_page_bit+0xd0/0xd8) [ 1321.345622] [<c03c9ac4>] (wait_on_page_bit) from [<c03c9b94>] (__filemap_fdatawait_range+0xc8/0x110) [ 1321.355010] [<c03c9b94>] (__filemap_fdatawait_range) from [<c03c9bf4>] (filemap_fdatawait_range+0x18/0x34) [ 1321.364947] [<c03c9bf4>] (filemap_fdatawait_range) from [<c03cbf2c>] (filemap_write_and_wait_range+0x54/0x74) [ 1321.375120] [<c03cbf2c>] (filemap_write_and_wait_range) from [<c04d6344>] (nfs_file_fsync+0x84/0x9c) [ 1321.384505] [<c04d6344>] (nfs_file_fsync) from [<c043d410>] (do_fsync+0x3c/0x64) [ 1321.392150] [<c043d410>] (do_fsync) from [<c0307dc0>] (ret_fast_syscall+0x0/0x3c) ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <CAAObsKD9HoEbtV_JMz_R=bcrQseDmhncRAWP9k8djksL-LMQqw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement [not found] ` <CAAObsKD9HoEbtV_JMz_R=bcrQseDmhncRAWP9k8djksL-LMQqw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2016-03-09 8:56 ` Giuseppe CAVALLARO [not found] ` <56DFE55B.2090806-qxv4g6HH51o@public.gmane.org> 0 siblings, 1 reply; 52+ messages in thread From: Giuseppe CAVALLARO @ 2016-03-09 8:56 UTC (permalink / raw) To: Tomeu Vizoso, Dinh Nguyen Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Heiko Stübner, netdev-u79uwXL29TY76Z2rM5mHXA, Frank Schäfer, open list:ARM/Rockchip SoC..., Gabriel Fernandez, Fabrice GASNIER, Andreas Färber, LAKML, Alexandre TORGUE Hello On 3/9/2016 9:35 AM, Tomeu Vizoso wrote: > > in order to get the onboard network on the Radxa Rock2 to work at all > on today's linux-next, I had to revert both commits: > > * "stmmac: Fix 'eth0: No PHY found' regression" for the drivers to > probe and the link to come up, and I've just sent two patches (on top of net.git) to fix this problem pls let me know if these help on your side too. > > * "stmmac: first frame prep at the end of the xmit routine" for the > network interface to work at all. I cannot reproduce it right now but I am looking at this again and let you know. I will check your output file too Regards peppe > But a few seconds into the nfsroot boot I start getting: > > [ 9.136701] systemd[1]: Started Load Kernel Modules. > [ 18.116321] nfs: server 10.42.0.1 not responding, still trying > [ 18.516224] ------------[ cut here ]------------ > [ 18.521024] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:303 > dev_watchdog+0x284/0x288 > [ 18.529456] NETDEV WATCHDOG: eth0 (rk_gmac-dwmac): transmit queue 0 timed out > > I'm attaching the full boot log. > > Regards, > > Tomeu > ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <56DFE55B.2090806-qxv4g6HH51o@public.gmane.org>]
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement [not found] ` <56DFE55B.2090806-qxv4g6HH51o@public.gmane.org> @ 2016-03-09 9:00 ` Giuseppe CAVALLARO [not found] ` <56DFE64B.8060606-qxv4g6HH51o@public.gmane.org> 0 siblings, 1 reply; 52+ messages in thread From: Giuseppe CAVALLARO @ 2016-03-09 9:00 UTC (permalink / raw) To: Tomeu Vizoso, Dinh Nguyen Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Heiko Stübner, netdev-u79uwXL29TY76Z2rM5mHXA, Frank Schäfer, open list:ARM/Rockchip SoC..., Gabriel Fernandez, Fabrice GASNIER, Andreas Färber, LAKML, Alexandre TORGUE On 3/9/2016 9:56 AM, Giuseppe CAVALLARO wrote: > Hello > > On 3/9/2016 9:35 AM, Tomeu Vizoso wrote: >> >> in order to get the onboard network on the Radxa Rock2 to work at all >> on today's linux-next, I had to revert both commits: >> >> * "stmmac: Fix 'eth0: No PHY found' regression" for the drivers to >> probe and the link to come up, and > > I've just sent two patches (on top of net.git) to fix this problem > pls let me know if these help on your side too. > >> >> * "stmmac: first frame prep at the end of the xmit routine" for the >> network interface to work at all. > > I cannot reproduce it right now but I am looking at this again and let > you know. > I will check your output file too hmm, I think that the problem is around the "normal descriptor" management that is configured on the boxes where the driver is failing now. Using enhanced descriptors the network is ok. I will keep you up-to-date. peppe > > Regards > peppe > > >> But a few seconds into the nfsroot boot I start getting: >> >> [ 9.136701] systemd[1]: Started Load Kernel Modules. >> [ 18.116321] nfs: server 10.42.0.1 not responding, still trying >> [ 18.516224] ------------[ cut here ]------------ >> [ 18.521024] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:303 >> dev_watchdog+0x284/0x288 >> [ 18.529456] NETDEV WATCHDOG: eth0 (rk_gmac-dwmac): transmit queue 0 >> timed out >> >> I'm attaching the full boot log. >> >> Regards, >> >> Tomeu >> > > ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <56DFE64B.8060606-qxv4g6HH51o@public.gmane.org>]
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement [not found] ` <56DFE64B.8060606-qxv4g6HH51o@public.gmane.org> @ 2016-03-09 9:42 ` Tomeu Vizoso [not found] ` <CAAObsKBr9SXg1-wr9O-ypR8JozdGpeAwfDLMeUKi8ozxkKyTXg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 52+ messages in thread From: Tomeu Vizoso @ 2016-03-09 9:42 UTC (permalink / raw) To: Giuseppe CAVALLARO Cc: Dinh Nguyen, devicetree-u79uwXL29TY76Z2rM5mHXA, Heiko Stübner, netdev-u79uwXL29TY76Z2rM5mHXA, open list:ARM/Rockchip SoC..., LAKML, Fabrice GASNIER, Andreas Färber, Gabriel Fernandez, Alexandre TORGUE, Frank Schäfer On 9 March 2016 at 10:00, Giuseppe CAVALLARO <peppe.cavallaro-qxv4g6HH51o@public.gmane.org> wrote: > On 3/9/2016 9:56 AM, Giuseppe CAVALLARO wrote: >> >> Hello >> >> On 3/9/2016 9:35 AM, Tomeu Vizoso wrote: >>> >>> >>> in order to get the onboard network on the Radxa Rock2 to work at all >>> on today's linux-next, I had to revert both commits: >>> >>> * "stmmac: Fix 'eth0: No PHY found' regression" for the drivers to >>> probe and the link to come up, and >> >> >> I've just sent two patches (on top of net.git) to fix this problem >> pls let me know if these help on your side too. >> >>> >>> * "stmmac: first frame prep at the end of the xmit routine" for the >>> network interface to work at all. >> >> >> I cannot reproduce it right now but I am looking at this again and let >> you know. >> I will check your output file too > > > hmm, I think that the problem is around the "normal descriptor" > management that is configured on the boxes where the driver is > failing now. Using enhanced descriptors the network is ok. > I will keep you up-to-date. Hi, I have done some tests and these are the results: * net.git (133800d1f028): probe failed * net.git (133800d1f028) + revert: everything fine * net.git (133800d1f028) + revert + "stmmac: fix MDIO settings": everything fine * today's linux-next: probe failed * today's linux-next + revert of 88f8b1bb41c6 stmmac: Fix 'eth0: No PHY found' regression: probe succeeded but no network at all * today's linux-next + revert of 88f8b1bb41c6 (stmmac: Fix 'eth0: No PHY found' regression) + revert of 0e80bdc9a72d (stmmac: first frame prep at the end of xmit routine): probe succeeded, dhcp succeeds and nfsroot works for a few seconds before timing out Btw, could you CC LKML on future patches that need testing? Thanks, Tomeu > peppe > > >> >> Regards >> peppe >> >> >>> But a few seconds into the nfsroot boot I start getting: >>> >>> [ 9.136701] systemd[1]: Started Load Kernel Modules. >>> [ 18.116321] nfs: server 10.42.0.1 not responding, still trying >>> [ 18.516224] ------------[ cut here ]------------ >>> [ 18.521024] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:303 >>> dev_watchdog+0x284/0x288 >>> [ 18.529456] NETDEV WATCHDOG: eth0 (rk_gmac-dwmac): transmit queue 0 >>> timed out >>> >>> I'm attaching the full boot log. >>> >>> Regards, >>> >>> Tomeu >>> >> >> > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <CAAObsKBr9SXg1-wr9O-ypR8JozdGpeAwfDLMeUKi8ozxkKyTXg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement [not found] ` <CAAObsKBr9SXg1-wr9O-ypR8JozdGpeAwfDLMeUKi8ozxkKyTXg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2016-03-09 9:52 ` Giuseppe CAVALLARO 2016-03-09 10:27 ` Giuseppe CAVALLARO 0 siblings, 1 reply; 52+ messages in thread From: Giuseppe CAVALLARO @ 2016-03-09 9:52 UTC (permalink / raw) To: Tomeu Vizoso, Fabrice GASNIER Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Dinh Nguyen, Heiko Stübner, netdev-u79uwXL29TY76Z2rM5mHXA, Frank Schäfer, open list:ARM/Rockchip SoC..., Gabriel Fernandez, Andreas Färber, LAKML, Alexandre TORGUE On 3/9/2016 10:42 AM, Tomeu Vizoso wrote: > On 9 March 2016 at 10:00, Giuseppe CAVALLARO <peppe.cavallaro-qxv4g6HH51o@public.gmane.org> wrote: >> On 3/9/2016 9:56 AM, Giuseppe CAVALLARO wrote: >>> >>> Hello >>> >>> On 3/9/2016 9:35 AM, Tomeu Vizoso wrote: >>>> >>>> >>>> in order to get the onboard network on the Radxa Rock2 to work at all >>>> on today's linux-next, I had to revert both commits: >>>> >>>> * "stmmac: Fix 'eth0: No PHY found' regression" for the drivers to >>>> probe and the link to come up, and >>> >>> >>> I've just sent two patches (on top of net.git) to fix this problem >>> pls let me know if these help on your side too. >>> >>>> >>>> * "stmmac: first frame prep at the end of the xmit routine" for the >>>> network interface to work at all. >>> >>> >>> I cannot reproduce it right now but I am looking at this again and let >>> you know. >>> I will check your output file too >> >> >> hmm, I think that the problem is around the "normal descriptor" >> management that is configured on the boxes where the driver is >> failing now. Using enhanced descriptors the network is ok. >> I will keep you up-to-date. > > Hi, > > I have done some tests and these are the results: > > * net.git (133800d1f028): probe failed ok, failure due to the "stmmac: Fix 'eth0: No PHY found' regression" > > * net.git (133800d1f028) + revert: everything fine ok that is expected but the fixed-link will be NOK > > * net.git (133800d1f028) + revert + "stmmac: fix MDIO settings": everything fine thx for having tested it. So it works on real transceiver (tested by you) and with the fixed-link (tested by me). > > * today's linux-next: probe failed > > * today's linux-next + revert of 88f8b1bb41c6 stmmac: Fix 'eth0: No > PHY found' regression: probe succeeded but no network at all > > * today's linux-next + revert of 88f8b1bb41c6 (stmmac: Fix 'eth0: No > PHY found' regression) + revert of 0e80bdc9a72d (stmmac: first frame > prep at the end of xmit routine): probe succeeded, dhcp succeeds and > nfsroot works for a few seconds before timing out ok, I was looking at this problem now that seems to related the "stmmac: first frame prep at the end of xmit routine" that, at first glance, is breaking the gmac 3.50 with normal descriptor. > Btw, could you CC LKML on future patches that need testing? sure peppe > > Thanks, > > Tomeu > >> peppe >> >> >>> >>> Regards >>> peppe >>> >>> >>>> But a few seconds into the nfsroot boot I start getting: >>>> >>>> [ 9.136701] systemd[1]: Started Load Kernel Modules. >>>> [ 18.116321] nfs: server 10.42.0.1 not responding, still trying >>>> [ 18.516224] ------------[ cut here ]------------ >>>> [ 18.521024] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:303 >>>> dev_watchdog+0x284/0x288 >>>> [ 18.529456] NETDEV WATCHDOG: eth0 (rk_gmac-dwmac): transmit queue 0 >>>> timed out >>>> >>>> I'm attaching the full boot log. >>>> >>>> Regards, >>>> >>>> Tomeu >>>> >>> >>> >> > > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement 2016-03-09 9:52 ` Giuseppe CAVALLARO @ 2016-03-09 10:27 ` Giuseppe CAVALLARO 2016-03-09 10:53 ` Tomeu Vizoso 0 siblings, 1 reply; 52+ messages in thread From: Giuseppe CAVALLARO @ 2016-03-09 10:27 UTC (permalink / raw) To: Tomeu Vizoso, Fabrice GASNIER Cc: Dinh Nguyen, devicetree, Heiko Stübner, netdev, open list:ARM/Rockchip SoC..., LAKML, Andreas Färber, Gabriel Fernandez, Alexandre TORGUE, Frank Schäfer, LKML [-- Attachment #1: Type: text/plain, Size: 1226 bytes --] Hello Tomeu, Andreas, On 3/9/2016 10:52 AM, Giuseppe CAVALLARO wrote: >> * today's linux-next: probe failed >> >> * today's linux-next + revert of 88f8b1bb41c6 stmmac: Fix 'eth0: No >> PHY found' regression: probe succeeded but no network at all >> >> * today's linux-next + revert of 88f8b1bb41c6 (stmmac: Fix 'eth0: No >> PHY found' regression) + revert of 0e80bdc9a72d (stmmac: first frame >> prep at the end of xmit routine): probe succeeded, dhcp succeeds and >> nfsroot works for a few seconds before timing out > > ok, I was looking at this problem now that seems to related > the "stmmac: first frame prep at the end of xmit routine" > that, at first glance, is breaking the gmac 3.50 with normal descriptor. I have no Hw where to test this use case. So, I wonder if may I ask you to test some patch. This first patch adds a missing barrier to the normal routine that inits the descriptor. Barrier was needed to well manage the OWN descriptor and it was not added in case of normal desc case after the xmit rework. Then I will check the algo behind the new xmit and in case of problems, if you agree, we will decide to revert it because it aimed to add an optimization. Let me know if you agree. Regards Peppe [-- Attachment #2: normal_tmp.patch --] [-- Type: text/x-patch, Size: 950 bytes --] diff --git a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c index e13228f..4392610 100644 --- a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c +++ b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c @@ -210,7 +210,7 @@ static void ndesc_prepare_tx_desc(struct dma_desc *p, int is_fs, int len, tdes1 &= ~TDES1_FIRST_SEGMENT; if (likely(csum_flag)) - tdes1 |= (TX_CIC_FULL) << TDES1_CHECKSUM_INSERTION_SHIFT; + tdes1 |= (TX_CIC_FULL << TDES1_CHECKSUM_INSERTION_SHIFT); else tdes1 &= ~(TX_CIC_FULL << TDES1_CHECKSUM_INSERTION_SHIFT); @@ -220,6 +220,13 @@ static void ndesc_prepare_tx_desc(struct dma_desc *p, int is_fs, int len, if (tx_own) tdes1 |= TDES0_OWN; + if (is_fs & tx_own) + /* When the own bit, for the first frame, has to be set, all + * descriptors for the same frame has to be set before, to + * avoid race condition. + */ + wmb(); + p->des1 = tdes1; } ^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement 2016-03-09 10:27 ` Giuseppe CAVALLARO @ 2016-03-09 10:53 ` Tomeu Vizoso 2016-03-09 14:31 ` Giuseppe CAVALLARO [not found] ` <56E033C8.40506@st.c om> 0 siblings, 2 replies; 52+ messages in thread From: Tomeu Vizoso @ 2016-03-09 10:53 UTC (permalink / raw) To: Giuseppe CAVALLARO Cc: Fabrice GASNIER, Dinh Nguyen, devicetree, Heiko Stübner, netdev, open list:ARM/Rockchip SoC..., LAKML, Andreas Färber, Gabriel Fernandez, Alexandre TORGUE, Frank Schäfer, LKML On 9 March 2016 at 11:27, Giuseppe CAVALLARO <peppe.cavallaro@st.com> wrote: > Hello Tomeu, Andreas, > > On 3/9/2016 10:52 AM, Giuseppe CAVALLARO wrote: >>> >>> * today's linux-next: probe failed >>> >>> * today's linux-next + revert of 88f8b1bb41c6 stmmac: Fix 'eth0: No >>> PHY found' regression: probe succeeded but no network at all >>> >>> * today's linux-next + revert of 88f8b1bb41c6 (stmmac: Fix 'eth0: No >>> PHY found' regression) + revert of 0e80bdc9a72d (stmmac: first frame >>> prep at the end of xmit routine): probe succeeded, dhcp succeeds and >>> nfsroot works for a few seconds before timing out >> >> >> ok, I was looking at this problem now that seems to related >> the "stmmac: first frame prep at the end of xmit routine" >> that, at first glance, is breaking the gmac 3.50 with normal descriptor. > > > I have no Hw where to test this use case. So, I wonder if may I ask you to > test some patch. > > This first patch adds a missing barrier to the normal routine that inits the > descriptor. Barrier was needed to well manage the OWN > descriptor and it was not added in case of normal desc case after > the xmit rework. > > Then I will check the algo behind the new xmit and in case of problems, > if you agree, we will decide to revert it because it aimed to add an > optimization. > > Let me know if you agree. I'm not sure what you would like to be tested, but just in case, I have just tried your patch on top of these commits and the result is the "transmit queue 0 timed out" error during boot: 6542b30d0a67 Revert "stmmac: first frame prep at the end of xmit routine" eb5274cbc0f7 Revert "stmmac: do not poll phy handler when attach a switch" e88e625a68d9 Revert "stmmac: fix phy init when attached to a phy" ef5dd3777876 stmmac: fix MDIO settings 77634ba1f25c Revert "stmmac: Fix 'eth0: No PHY found' regression" 7811b4ffc312 Add linux-next specific files for 20160309 Regards, Tomeu > Regards > Peppe ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement 2016-03-09 10:53 ` Tomeu Vizoso @ 2016-03-09 14:31 ` Giuseppe CAVALLARO [not found] ` <56E033C8.40506@st.c om> 1 sibling, 0 replies; 52+ messages in thread From: Giuseppe CAVALLARO @ 2016-03-09 14:31 UTC (permalink / raw) To: Tomeu Vizoso Cc: devicetree, Dinh Nguyen, Heiko Stübner, netdev, LKML, Frank Schäfer, open list:ARM/Rockchip SoC..., Gabriel Fernandez, Fabrice GASNIER, Andreas Färber, LAKML, Alexandre TORGUE Hi Tomeu On 3/9/2016 11:53 AM, Tomeu Vizoso wrote: > On 9 March 2016 at 11:27, Giuseppe CAVALLARO <peppe.cavallaro@st.com> wrote: >> Hello Tomeu, Andreas, >> >> On 3/9/2016 10:52 AM, Giuseppe CAVALLARO wrote: >>>> >>>> * today's linux-next: probe failed >>>> >>>> * today's linux-next + revert of 88f8b1bb41c6 stmmac: Fix 'eth0: No >>>> PHY found' regression: probe succeeded but no network at all >>>> >>>> * today's linux-next + revert of 88f8b1bb41c6 (stmmac: Fix 'eth0: No >>>> PHY found' regression) + revert of 0e80bdc9a72d (stmmac: first frame >>>> prep at the end of xmit routine): probe succeeded, dhcp succeeds and >>>> nfsroot works for a few seconds before timing out >>> >>> >>> ok, I was looking at this problem now that seems to related >>> the "stmmac: first frame prep at the end of xmit routine" >>> that, at first glance, is breaking the gmac 3.50 with normal descriptor. >> >> >> I have no Hw where to test this use case. So, I wonder if may I ask you to >> test some patch. >> >> This first patch adds a missing barrier to the normal routine that inits the >> descriptor. Barrier was needed to well manage the OWN >> descriptor and it was not added in case of normal desc case after >> the xmit rework. >> >> Then I will check the algo behind the new xmit and in case of problems, >> if you agree, we will decide to revert it because it aimed to add an >> optimization. >> >> Let me know if you agree. > > I'm not sure what you would like to be tested, but just in case, I > have just tried your patch on top of these commits and the result is > the "transmit queue 0 timed out" error during boot: > > 6542b30d0a67 Revert "stmmac: first frame prep at the end of xmit routine" > eb5274cbc0f7 Revert "stmmac: do not poll phy handler when attach a switch" > e88e625a68d9 Revert "stmmac: fix phy init when attached to a phy" > ef5dd3777876 stmmac: fix MDIO settings > 77634ba1f25c Revert "stmmac: Fix 'eth0: No PHY found' regression" > 7811b4ffc312 Add linux-next specific files for 20160309 I missed that the issue is not only related the "stmmac: first frame prep at the end of xmit routine" I have to try to test on 3.50 with normal descriptor. When using enhanced descriptors all works fine on my side. I keep you informed. peppe > Regards, > > Tomeu > >> Regards >> Peppe > > ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <56E033C8.40506@st.c om>]
[parent not found: <56E033C8.40506-qxv4g6HH51o@public.gmane.org>]
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement [not found] ` <56E033C8.40506-qxv4g6HH51o@public.gmane.org> @ 2016-03-09 14:53 ` Giuseppe CAVALLARO [not found] ` <56E038CE.606-qxv4g6HH51o@public.gmane.org> 0 siblings, 1 reply; 52+ messages in thread From: Giuseppe CAVALLARO @ 2016-03-09 14:53 UTC (permalink / raw) To: Tomeu Vizoso, Dinh Nguyen, Andreas Färber Cc: Fabrice GASNIER, devicetree-u79uwXL29TY76Z2rM5mHXA, Heiko Stübner, netdev-u79uwXL29TY76Z2rM5mHXA, open list:ARM/Rockchip SoC..., LAKML, Gabriel Fernandez, Alexandre TORGUE, Frank Schäfer, LKML Hi Tomeu, Dinh, Andreas I need a sum and help from you to go ahead on the tx timeout. The "stmmac: MDIO fixes" seems to be the candidate to fix the phy connection and I will send the V2 asap (Andreas' comment). So, supposing the probe is ok and phy is connected, I need your input ... Tomeu: after revering the 0e80bdc9a72d (stmmac: first frame prep at the end of xmit routine) the network is not stable and there is a timeout after a while. The box has 3.50 with normal desc settings. Dinh: the network is ok, I wonder if you can share a boot log just to understand if the normal or enhanced descriptors are used. Andreas: you are also using 3.50 with normal desc but I have not clear if just reverting 0e80bdc9a72d commit the network is ok or you see timeout issues. In the meantime I am trying to find a box where try normal setup and I can confirm that enhanced descriptors are ok on my side Regards Peppe On 3/9/2016 3:31 PM, Giuseppe CAVALLARO wrote: > Hi Tomeu > > On 3/9/2016 11:53 AM, Tomeu Vizoso wrote: >> On 9 March 2016 at 11:27, Giuseppe CAVALLARO <peppe.cavallaro-qxv4g6HH51o@public.gmane.org> >> wrote: >>> Hello Tomeu, Andreas, >>> >>> On 3/9/2016 10:52 AM, Giuseppe CAVALLARO wrote: >>>>> >>>>> * today's linux-next: probe failed >>>>> >>>>> * today's linux-next + revert of 88f8b1bb41c6 stmmac: Fix 'eth0: No >>>>> PHY found' regression: probe succeeded but no network at all >>>>> >>>>> * today's linux-next + revert of 88f8b1bb41c6 (stmmac: Fix 'eth0: No >>>>> PHY found' regression) + revert of 0e80bdc9a72d (stmmac: first frame >>>>> prep at the end of xmit routine): probe succeeded, dhcp succeeds and >>>>> nfsroot works for a few seconds before timing out >>>> >>>> >>>> ok, I was looking at this problem now that seems to related >>>> the "stmmac: first frame prep at the end of xmit routine" >>>> that, at first glance, is breaking the gmac 3.50 with normal >>>> descriptor. >>> >>> >>> I have no Hw where to test this use case. So, I wonder if may I ask >>> you to >>> test some patch. >>> >>> This first patch adds a missing barrier to the normal routine that >>> inits the >>> descriptor. Barrier was needed to well manage the OWN >>> descriptor and it was not added in case of normal desc case after >>> the xmit rework. >>> >>> Then I will check the algo behind the new xmit and in case of problems, >>> if you agree, we will decide to revert it because it aimed to add an >>> optimization. >>> >>> Let me know if you agree. >> >> I'm not sure what you would like to be tested, but just in case, I >> have just tried your patch on top of these commits and the result is >> the "transmit queue 0 timed out" error during boot: >> >> 6542b30d0a67 Revert "stmmac: first frame prep at the end of xmit routine" >> eb5274cbc0f7 Revert "stmmac: do not poll phy handler when attach a >> switch" >> e88e625a68d9 Revert "stmmac: fix phy init when attached to a phy" >> ef5dd3777876 stmmac: fix MDIO settings >> 77634ba1f25c Revert "stmmac: Fix 'eth0: No PHY found' regression" >> 7811b4ffc312 Add linux-next specific files for 20160309 > > I missed that the issue is not only related the > "stmmac: first frame prep at the end of xmit routine" > I have to try to test on 3.50 with normal descriptor. > When using enhanced descriptors all works fine on my > side. > > I keep you informed. > > peppe > > >> Regards, >> >> Tomeu >> >>> Regards >>> Peppe >> >> > > > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <56E038CE.606-qxv4g6HH51o@public.gmane.org>]
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement [not found] ` <56E038CE.606-qxv4g6HH51o@public.gmane.org> @ 2016-03-09 16:31 ` Dinh Nguyen [not found] ` <CADhT+wcMpzA_Coj8Z5OQZsc3bF3a7yOmsbazQMPtcdUWkJSuCA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 52+ messages in thread From: Dinh Nguyen @ 2016-03-09 16:31 UTC (permalink / raw) To: Giuseppe CAVALLARO Cc: Tomeu Vizoso, Andreas Färber, Fabrice GASNIER, devicetree-u79uwXL29TY76Z2rM5mHXA, Heiko Stübner, netdev-u79uwXL29TY76Z2rM5mHXA, open list:ARM/Rockchip SoC..., LAKML, Gabriel Fernandez, Alexandre TORGUE, Frank Schäfer, LKML On Wed, Mar 9, 2016 at 8:53 AM, Giuseppe CAVALLARO <peppe.cavallaro-qxv4g6HH51o@public.gmane.org> wrote: > Hi Tomeu, Dinh, Andreas > > I need a sum and help from you to go ahead on the > tx timeout. > > The "stmmac: MDIO fixes" seems to be the candidate to > fix the phy connection and I will send the V2 asap (Andreas' comment). > > So, supposing the probe is ok and phy is connected, > I need your input ... > > Tomeu: after revering the 0e80bdc9a72d (stmmac: first frame > prep at the end of xmit routine) the network is > not stable and there is a timeout after a while. > The box has 3.50 with normal desc settings. > > Dinh: the network is ok, I wonder if you can share a boot > log just to understand if the normal or enhanced > descriptors are used. > Here it is: [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.5.0-rc6-next-20160304-00001-g092eb23 (dinguyen@linux-builds1) (gcc version 4.7.3 2013022 6 (prerelease) (crosstool-NG linaro-1.13.1-4.7-2013.03-20130313 - Linaro GCC 2013.03) ) #1 SMP Wed Mar 9 10:22:14 CST 2 016 [ 0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Machine model: Altera SOCFPGA Cyclone V SoC Development Kit [ 0.000000] cma: Reserved 64 MiB at 0x3c000000 [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] PERCPU: Embedded 13 pages/cpu @ef7cc000 s23808 r8192 d21248 u53248 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260608 [ 0.000000] Kernel command line: console=ttyS0,115200 root=/dev/mmcblk0p2 rw rootwait ip=dhcp [ 0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes) [ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] Memory: 955932K/1048576K available (9522K kernel code, 1142K rwdata, 4124K rodata, 2048K init, 342K bss, 27108K reserved, 65536K cma-reserved, 196608K highmem) [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB) [ 0.000000] vmalloc : 0xf0800000 - 0xff800000 ( 240 MB) [ 0.000000] lowmem : 0xc0000000 - 0xf0000000 ( 768 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0xc0208000 - 0xc1053830 (14639 kB) [ 0.000000] .init : 0xc1100000 - 0xc1300000 (2048 kB) [ 0.000000] .data : 0xc1300000 - 0xc141da80 (1143 kB) [ 0.000000] .bss : 0xc141f000 - 0xc1474920 ( 343 kB) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] Build-time adjustment of leaf fanout to 32. [ 0.000000] RCU restricting CPUs from NR_CPUS=16 to nr_cpu_ids=2. [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=2 [ 0.000000] NR_IRQS:16 nr_irqs:16 16 [ 0.000000] L2C-310 erratum 769419 enabled [ 0.000000] L2C-310 enabling early BRESP for Cortex-A9 [ 0.000000] L2C-310 full line of zeros enabled for Cortex-A9 [ 0.000000] L2C-310 ID prefetch enabled, offset 1 lines [ 0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled [ 0.000000] L2C-310 cache controller enabled, 8 ways, 512 kB [ 0.000000] L2C-310: CACHE_ID 0x410030c9, AUX_CTRL 0x76060001 [ 0.000000] clocksource: timer1: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604467 ns [ 0.000005] sched_clock: 32 bits at 100MHz, resolution 10ns, wraps every 21474836475ns [ 0.000015] Switching to timer-based delay loop, resolution 10ns [ 0.000268] Console: colour dummy device 80x30 [ 0.000290] Calibrating delay loop (skipped), value calculated using timer frequency.. 200.00 BogoMIPS (lpj=500000) [ 0.000301] pid_max: default: 32768 minimum: 301 [ 0.000374] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) [ 0.000382] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) [ 0.000879] CPU: Testing write buffer coherency: ok [ 0.001062] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.001207] Setting up static identity map for 0x300000 - 0x300098 [ 0.003872] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001 [ 0.003946] Brought up 2 CPUs [ 0.003959] SMP: Total of 2 processors activated (400.00 BogoMIPS). [ 0.003965] CPU: All CPU(s) started in SVC mode. [ 0.004672] devtmpfs: initialized [ 0.008193] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4 [ 0.008609] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 9556302231375000 ns [ 0.011733] pinctrl core: initialized pinctrl subsystem [ 0.013149] NET: Registered protocol family 16 [ 0.014993] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 0.029850] cpuidle: using governor menu [ 0.035166] No ATAGs? [ 0.035199] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers. [ 0.035207] hw-breakpoint: maximum watchpoint size is 4 bytes. [ 0.037795] Serial: AMBA PL011 UART driver [ 0.064193] vgaarb: loaded [ 0.064994] SCSI subsystem initialized [ 0.065377] usbcore: registered new interface driver usbfs [ 0.065427] usbcore: registered new interface driver hub [ 0.065471] usbcore: registered new device driver usb [ 0.065637] soc:usbphy@0 supply vcc not found, using dummy regulator [ 0.066917] pps_core: LinuxPPS API ver. 1 registered [ 0.066925] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti-k2GhghHVRtY@public.gmane.org> [ 0.066948] PTP clock support registered [ 0.067075] EDAC MC: Ver: 3.0.0 [ 0.068905] clocksource: Switched to clocksource timer1 [ 0.077130] NET: Registered protocol family 2 [ 0.077598] TCP established hash table entries: 8192 (order: 3, 32768 bytes) [ 0.077675] TCP bind hash table entries: 8192 (order: 4, 65536 bytes) [ 0.077789] TCP: Hash tables configured (established 8192 bind 8192) [ 0.077850] UDP hash table entries: 512 (order: 2, 16384 bytes) [ 0.077892] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes) [ 0.078045] NET: Registered protocol family 1 [ 0.078313] RPC: Registered named UNIX socket transport module. [ 0.078322] RPC: Registered udp transport module. [ 0.078327] RPC: Registered tcp transport module. [ 0.078332] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 0.079971] futex hash table entries: 512 (order: 3, 32768 bytes) [ 0.080491] workingset: timestamp_bits=28 max_order=18 bucket_order=0 [ 0.088552] squashfs: version 4.0 (2009/01/31) Phillip Lougher [ 0.089257] NFS: Registering the id_resolver key type [ 0.089295] Key type id_resolver registered [ 0.089302] Key type id_legacy registered [ 0.089357] ntfs: driver 2.1.32 [Flags: R/O]. [ 0.090460] bounce: pool size: 64 pages [ 0.090644] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 248) [ 0.090659] io scheduler noop registered [ 0.090670] io scheduler deadline registered [ 0.090702] io scheduler cfq registered (default) [ 0.101187] dma-pl330 ffe01000.pdma: Loaded driver for PL330 DMAC-341330 [ 0.101202] dma-pl330 ffe01000.pdma: DBUFF-512x8bytes Num_Chans-8 Num_Peri-32 Num_Events-8 [ 0.148800] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [ 0.150717] console [ttyS0] disabled [ 0.150752] ffc02000.serial0: ttyS0 at MMIO 0xffc02000 (irq = 35, base_baud = 6250000) is a 16550A [ 0.760760] console [ttyS0] enabled [ 0.764930] ffc03000.serial1: ttyS1 at MMIO 0xffc03000 (irq = 36, base_baud = 6250000) is a 16550A [ 0.774702] SuperH (H)SCI(F) driver initialized [ 0.779746] msm_serial: driver initialized [ 0.783950] STMicroelectronics ASC driver initialized [ 0.789977] [drm] Initialized drm 1.1.0 20060810 [ 0.804439] brd: module loaded [ 0.812215] loop: module loaded [ 0.815664] at24 0-0051: 4096 byte 24c32 EEPROM, writable, 32 bytes/write [ 0.827372] libphy: Fixed MDIO Bus: probed [ 0.832015] CAN device driver interface [ 0.836848] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.3.0-k [ 0.843792] igb: Copyright (c) 2007-2014 Intel Corporation. [ 0.850523] stmmac - user ID: 0x10, Synopsys ID: 0x37 [ 0.855570] Ring mode enabled [ 0.858611] DMA HW capability register supported [ 0.863128] Enhanced/Alternate descriptors [ 0.867482] Enabled extended descriptors [ 0.871482] RX Checksum Offload Engine supported (type 2) [ 0.876948] TX Checksum insertion supported [ 0.881204] Enable RX Mitigation via HW Watchdog Timer [ 0.886863] socfpga-dwmac ff702000.ethernet eth0: No MDIO subnode found [ 0.899090] libphy: stmmac: probed [ 0.902484] eth0: PHY ID 00221611 at 4 IRQ POLL (stmmac-0:04) active [ 0.909742] pegasus: v0.9.3 (2013/04/25), Pegasus/Pegasus II USB Ethernet driver [ 0.917175] usbcore: registered new interface driver pegasus [ 0.922873] usbcore: registered new interface driver asix [ 0.928300] usbcore: registered new interface driver ax88179_178a [ 0.934422] usbcore: registered new interface driver cdc_ether [ 0.940294] usbcore: registered new interface driver smsc75xx [ 0.946078] usbcore: registered new interface driver smsc95xx [ 0.951848] usbcore: registered new interface driver net1080 [ 0.957529] usbcore: registered new interface driver cdc_subset [ 0.963470] usbcore: registered new interface driver zaurus [ 0.969098] usbcore: registered new interface driver cdc_ncm [ 0.975810] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 0.982335] ehci-pci: EHCI PCI platform driver [ 0.986814] ehci-platform: EHCI generic platform driver [ 0.992147] ehci-omap: OMAP-EHCI Host Controller driver [ 0.997446] ehci-orion: EHCI orion driver [ 1.001534] SPEAr-ehci: EHCI SPEAr driver [ 1.005623] ehci-st: EHCI STMicroelectronics driver [ 1.010577] ehci-exynos: EHCI EXYNOS driver [ 1.014845] ehci-atmel: EHCI Atmel driver [ 1.018930] tegra-ehci: Tegra EHCI driver [ 1.023017] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 1.029198] ohci-pci: OHCI PCI platform driver [ 1.033671] ohci-platform: OHCI generic platform driver [ 1.038999] ohci-omap3: OHCI OMAP3 driver [ 1.043076] SPEAr-ohci: OHCI SPEAr driver [ 1.047166] ohci-st: OHCI STMicroelectronics driver [ 1.052119] ohci-atmel: OHCI Atmel driver [ 1.056540] usbcore: registered new interface driver usb-storage [ 1.063604] mousedev: PS/2 mouse device common for all mice [ 1.071372] rtc-ds1307 0-0068: rtc core: registered ds1339 as rtc0 [ 1.078720] i2c /dev entries driver [ 1.088558] sdhci: Secure Digital Host Controller Interface driver [ 1.094733] sdhci: Copyright(c) Pierre Ossman [ 1.099926] Synopsys Designware Multimedia Card Interface Driver [ 1.106160] dw_mmc ff704000.dwmmc0: IDMAC supports 32-bit address mode. [ 1.112832] dw_mmc ff704000.dwmmc0: Using internal DMA controller. [ 1.119003] dw_mmc ff704000.dwmmc0: Version ID is 240a [ 1.124161] dw_mmc ff704000.dwmmc0: DW MMC controller at irq 30,32 bit host data width,1024 deep fifo [ 1.133484] dw_mmc ff704000.dwmmc0: Got CD GPIO [ 1.163951] dw_mmc ff704000.dwmmc0: 1 slots initialized [ 1.169801] sdhci-pltfm: SDHCI platform and OF driver helper [ 1.176752] ledtrig-cpu: registered to indicate activity on CPUs [ 1.183123] usbcore: registered new interface driver usbhid [ 1.188689] usbhid: USB HID core driver [ 1.196305] NET: Registered protocol family 10 [ 1.201510] sit: IPv6 over IPv4 tunneling driver [ 1.206748] NET: Registered protocol family 17 [ 1.211203] can: controller area network core (rev 20120528 abi 9) [ 1.217420] NET: Registered protocol family 29 [ 1.221867] can: raw protocol (rev 20120528) [ 1.226139] can: broadcast manager protocol (rev 20120528 t) [ 1.231793] can: netlink gateway (rev 20130117) max_hops=1 [ 1.237633] Key type dns_resolver registered [ 1.242056] ThumbEE CPU extension supported. [ 1.246339] Registering SWP/SWPB emulation handler [ 1.252996] rtc-ds1307 0-0068: setting system clock to 2000-01-01 10:28:48 UTC (946722528) [ 1.283660] mmc_host mmc0: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0) [ 1.293419] mmc0: new high speed SDHC card at address 0007 [ 1.299260] mmcblk0: mmc0:0007 SD4GB 3.71 GiB [ 1.305075] mmcblk0: p1 p2 p3 p4 [ 1.336767] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 5.324487] socfpga-dwmac ff702000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx [ 5.333591] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 5.343917] Sending DHCP requests ., OK -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <CADhT+wcMpzA_Coj8Z5OQZsc3bF3a7yOmsbazQMPtcdUWkJSuCA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement [not found] ` <CADhT+wcMpzA_Coj8Z5OQZsc3bF3a7yOmsbazQMPtcdUWkJSuCA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2016-03-10 9:13 ` Giuseppe CAVALLARO [not found] ` <56E13AAB.2080900-qxv4g6HH51o@public.gmane.org> 0 siblings, 1 reply; 52+ messages in thread From: Giuseppe CAVALLARO @ 2016-03-10 9:13 UTC (permalink / raw) To: Dinh Nguyen Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Heiko Stübner, netdev-u79uwXL29TY76Z2rM5mHXA, Gabriel Fernandez, LKML, Frank Schäfer, open list:ARM/Rockchip SoC..., LAKML, Fabrice GASNIER, Andreas Färber, Tomeu Vizoso, Alexandre TORGUE On 3/9/2016 5:31 PM, Dinh Nguyen wrote: > On Wed, Mar 9, 2016 at 8:53 AM, Giuseppe CAVALLARO > <peppe.cavallaro-qxv4g6HH51o@public.gmane.org> wrote: >> Hi Tomeu, Dinh, Andreas >> >> I need a sum and help from you to go ahead on the >> tx timeout. >> >> The "stmmac: MDIO fixes" seems to be the candidate to >> fix the phy connection and I will send the V2 asap (Andreas' comment). >> >> So, supposing the probe is ok and phy is connected, >> I need your input ... >> >> Tomeu: after revering the 0e80bdc9a72d (stmmac: first frame >> prep at the end of xmit routine) the network is >> not stable and there is a timeout after a while. >> The box has 3.50 with normal desc settings. >> >> Dinh: the network is ok, I wonder if you can share a boot >> log just to understand if the normal or enhanced >> descriptors are used. >> > > Here it is: ... > [ 0.850523] stmmac - user ID: 0x10, Synopsys ID: 0x37 > [ 0.855570] Ring mode enabled > [ 0.858611] DMA HW capability register supported > [ 0.863128] Enhanced/Alternate descriptors > [ 0.867482] Enabled extended descriptors > [ 0.871482] RX Checksum Offload Engine supported (type 2) > [ 0.876948] TX Checksum insertion supported > [ 0.881204] Enable RX Mitigation via HW Watchdog Timer > [ 0.886863] socfpga-dwmac ff702000.ethernet eth0: No MDIO subnode found > [ 0.899090] libphy: stmmac: probed > [ 0.902484] eth0: PHY ID 00221611 at 4 IRQ POLL (stmmac-0:04) active Thx Dinh, so you are using the Enhanced/Alternate descriptors I am debugging on my side on a setup with normal descriptors, I let you know peppe ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <56E13AAB.2080900-qxv4g6HH51o@public.gmane.org>]
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement [not found] ` <56E13AAB.2080900-qxv4g6HH51o@public.gmane.org> @ 2016-03-10 16:47 ` Dinh Nguyen [not found] ` <CADhT+wd=vcph2y_OxkGNO5EwHvN=kBy-BrfZHmNjZHww4LxmTg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 52+ messages in thread From: Dinh Nguyen @ 2016-03-10 16:47 UTC (permalink / raw) To: Giuseppe CAVALLARO Cc: Tomeu Vizoso, Andreas Färber, Fabrice GASNIER, devicetree-u79uwXL29TY76Z2rM5mHXA, Heiko Stübner, netdev-u79uwXL29TY76Z2rM5mHXA, open list:ARM/Rockchip SoC..., LAKML, Gabriel Fernandez, Alexandre TORGUE, Frank Schäfer, LKML On Thu, Mar 10, 2016 at 3:13 AM, Giuseppe CAVALLARO <peppe.cavallaro-qxv4g6HH51o@public.gmane.org> wrote: > On 3/9/2016 5:31 PM, Dinh Nguyen wrote: >> >> On Wed, Mar 9, 2016 at 8:53 AM, Giuseppe CAVALLARO >> <peppe.cavallaro-qxv4g6HH51o@public.gmane.org> wrote: >>> >>> Hi Tomeu, Dinh, Andreas >>> >>> I need a sum and help from you to go ahead on the >>> tx timeout. >>> >>> The "stmmac: MDIO fixes" seems to be the candidate to >>> fix the phy connection and I will send the V2 asap (Andreas' comment). >>> >>> So, supposing the probe is ok and phy is connected, >>> I need your input ... >>> >>> Tomeu: after revering the 0e80bdc9a72d (stmmac: first frame >>> prep at the end of xmit routine) the network is >>> not stable and there is a timeout after a while. >>> The box has 3.50 with normal desc settings. >>> >>> Dinh: the network is ok, I wonder if you can share a boot >>> log just to understand if the normal or enhanced >>> descriptors are used. >>> >> >> Here it is: > > ... >> >> [ 0.850523] stmmac - user ID: 0x10, Synopsys ID: 0x37 >> [ 0.855570] Ring mode enabled >> [ 0.858611] DMA HW capability register supported >> [ 0.863128] Enhanced/Alternate descriptors >> [ 0.867482] Enabled extended descriptors >> [ 0.871482] RX Checksum Offload Engine supported (type 2) >> [ 0.876948] TX Checksum insertion supported >> [ 0.881204] Enable RX Mitigation via HW Watchdog Timer >> [ 0.886863] socfpga-dwmac ff702000.ethernet eth0: No MDIO subnode found >> [ 0.899090] libphy: stmmac: probed >> [ 0.902484] eth0: PHY ID 00221611 at 4 IRQ POLL (stmmac-0:04) active > > > Thx Dinh, so you are using the Enhanced/Alternate descriptors > I am debugging on my side on a setup with normal descriptors, I let you > know > Doesn't the printout "Enhanced/Alternate descriptors" mean that I'm using Enhanced/Alternate descriptors? Dinh -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <CADhT+wd=vcph2y_OxkGNO5EwHvN=kBy-BrfZHmNjZHww4LxmTg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement [not found] ` <CADhT+wd=vcph2y_OxkGNO5EwHvN=kBy-BrfZHmNjZHww4LxmTg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2016-03-11 9:09 ` Giuseppe CAVALLARO 2016-03-14 11:43 ` Tomeu Vizoso 0 siblings, 1 reply; 52+ messages in thread From: Giuseppe CAVALLARO @ 2016-03-11 9:09 UTC (permalink / raw) To: Dinh Nguyen, Tomeu Vizoso Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Heiko Stübner, netdev-u79uwXL29TY76Z2rM5mHXA, LKML, Frank Schäfer, open list:ARM/Rockchip SoC..., Gabriel Fernandez, Fabrice GASNIER, Andreas Färber, LAKML, Alexandre TORGUE [-- Attachment #1: Type: text/plain, Size: 2790 bytes --] On 3/10/2016 5:47 PM, Dinh Nguyen wrote: > On Thu, Mar 10, 2016 at 3:13 AM, Giuseppe CAVALLARO > <peppe.cavallaro-qxv4g6HH51o@public.gmane.org> wrote: >> On 3/9/2016 5:31 PM, Dinh Nguyen wrote: >>> >>> On Wed, Mar 9, 2016 at 8:53 AM, Giuseppe CAVALLARO >>> <peppe.cavallaro-qxv4g6HH51o@public.gmane.org> wrote: >>>> >>>> Hi Tomeu, Dinh, Andreas >>>> >>>> I need a sum and help from you to go ahead on the >>>> tx timeout. >>>> >>>> The "stmmac: MDIO fixes" seems to be the candidate to >>>> fix the phy connection and I will send the V2 asap (Andreas' comment). >>>> >>>> So, supposing the probe is ok and phy is connected, >>>> I need your input ... >>>> >>>> Tomeu: after revering the 0e80bdc9a72d (stmmac: first frame >>>> prep at the end of xmit routine) the network is >>>> not stable and there is a timeout after a while. >>>> The box has 3.50 with normal desc settings. >>>> >>>> Dinh: the network is ok, I wonder if you can share a boot >>>> log just to understand if the normal or enhanced >>>> descriptors are used. >>>> >>> >>> Here it is: >> >> ... >>> >>> [ 0.850523] stmmac - user ID: 0x10, Synopsys ID: 0x37 >>> [ 0.855570] Ring mode enabled >>> [ 0.858611] DMA HW capability register supported >>> [ 0.863128] Enhanced/Alternate descriptors >>> [ 0.867482] Enabled extended descriptors >>> [ 0.871482] RX Checksum Offload Engine supported (type 2) >>> [ 0.876948] TX Checksum insertion supported >>> [ 0.881204] Enable RX Mitigation via HW Watchdog Timer >>> [ 0.886863] socfpga-dwmac ff702000.ethernet eth0: No MDIO subnode found >>> [ 0.899090] libphy: stmmac: probed >>> [ 0.902484] eth0: PHY ID 00221611 at 4 IRQ POLL (stmmac-0:04) active >> >> >> Thx Dinh, so you are using the Enhanced/Alternate descriptors >> I am debugging on my side on a setup with normal descriptors, I let you >> know >> > > Doesn't the printout "Enhanced/Alternate descriptors" mean that I'm using > Enhanced/Alternate descriptors? yes this means that you have the Databook 3.70a and, from the HW capability register, the driver will use the Enhanced/Alternate descriptors. This is the same HW I am using on my side where the stmmac is working fine. In the case where it is failing on net-next, although on Databook 3.50a, the HW capability register says that there is no enhanced descriptors and the driver uses the normal ones. Tomeu, I kindly ask you to try the patch attached. I found a bug on Tx path for normal descriptors. Please let me know if this help. Also let me know if we actually need to revert the 0e80bdc9a72d. I am trying to find some HW where test the normal descriptors to speed-up the tests on my side directly. Let me know and thx in advance. Regards, Peppe > > Dinh > [-- Attachment #2: 0001-stmmac-fix-tx-prepare-for-normal-desc.patch --] [-- Type: text/x-patch, Size: 1265 bytes --] >From ed3e38befc5500e05f46e1d52ea20a0b8d3829f3 Mon Sep 17 00:00:00 2001 From: Giuseppe Cavallaro <peppe.cavallaro-qxv4g6HH51o@public.gmane.org> Date: Thu, 10 Mar 2016 14:57:48 +0100 Subject: [PATCH (linux-sti-4.1)] stmmac: fix tx prepare for normal desc This patch fixes a bug inside when use the normal descriptors. While preparing the tx descriptor the frame size was not properly set. Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro-qxv4g6HH51o@public.gmane.org> --- drivers/net/ethernet/stmicro/stmmac/norm_desc.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c index e13228f..432b3f1 100644 --- a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c +++ b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c @@ -197,13 +197,15 @@ static void ndesc_prepare_tx_desc(struct dma_desc *p, int is_fs, int len, bool csum_flag, int mode, bool tx_own, bool ls) { - unsigned int tdes1 = p->des1; + unsigned int tdes1; if (mode == STMMAC_CHAIN_MODE) norm_set_tx_desc_len_on_chain(p, len); else norm_set_tx_desc_len_on_ring(p, len); + tdes1 = p->des1; + if (is_fs) tdes1 |= TDES1_FIRST_SEGMENT; else -- 1.7.4.4 [-- Attachment #3: Type: text/plain, Size: 200 bytes --] _______________________________________________ Linux-rockchip mailing list Linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement 2016-03-11 9:09 ` Giuseppe CAVALLARO @ 2016-03-14 11:43 ` Tomeu Vizoso [not found] ` <CAAObsKB-tSCu5KMYk2Zi-oX9zMKEOwwT93sMkiZKiYvtexmHaQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 52+ messages in thread From: Tomeu Vizoso @ 2016-03-14 11:43 UTC (permalink / raw) To: Giuseppe CAVALLARO Cc: Dinh Nguyen, Andreas Färber, Fabrice GASNIER, devicetree, Heiko Stübner, netdev, open list:ARM/Rockchip SoC..., LAKML, Gabriel Fernandez, Alexandre TORGUE, Frank Schäfer, LKML On 11 March 2016 at 10:09, Giuseppe CAVALLARO <peppe.cavallaro@st.com> wrote: > On 3/10/2016 5:47 PM, Dinh Nguyen wrote: >> >> On Thu, Mar 10, 2016 at 3:13 AM, Giuseppe CAVALLARO >> <peppe.cavallaro@st.com> wrote: >>> >>> On 3/9/2016 5:31 PM, Dinh Nguyen wrote: >>>> >>>> >>>> On Wed, Mar 9, 2016 at 8:53 AM, Giuseppe CAVALLARO >>>> <peppe.cavallaro@st.com> wrote: >>>>> >>>>> >>>>> Hi Tomeu, Dinh, Andreas >>>>> >>>>> I need a sum and help from you to go ahead on the >>>>> tx timeout. >>>>> >>>>> The "stmmac: MDIO fixes" seems to be the candidate to >>>>> fix the phy connection and I will send the V2 asap (Andreas' comment). >>>>> >>>>> So, supposing the probe is ok and phy is connected, >>>>> I need your input ... >>>>> >>>>> Tomeu: after revering the 0e80bdc9a72d (stmmac: first frame >>>>> prep at the end of xmit routine) the network is >>>>> not stable and there is a timeout after a while. >>>>> The box has 3.50 with normal desc settings. >>>>> >>>>> Dinh: the network is ok, I wonder if you can share a boot >>>>> log just to understand if the normal or enhanced >>>>> descriptors are used. >>>>> >>>> >>>> Here it is: >>> >>> >>> ... >>>> >>>> >>>> [ 0.850523] stmmac - user ID: 0x10, Synopsys ID: 0x37 >>>> [ 0.855570] Ring mode enabled >>>> [ 0.858611] DMA HW capability register supported >>>> [ 0.863128] Enhanced/Alternate descriptors >>>> [ 0.867482] Enabled extended descriptors >>>> [ 0.871482] RX Checksum Offload Engine supported (type 2) >>>> [ 0.876948] TX Checksum insertion supported >>>> [ 0.881204] Enable RX Mitigation via HW Watchdog Timer >>>> [ 0.886863] socfpga-dwmac ff702000.ethernet eth0: No MDIO subnode >>>> found >>>> [ 0.899090] libphy: stmmac: probed >>>> [ 0.902484] eth0: PHY ID 00221611 at 4 IRQ POLL (stmmac-0:04) active >>> >>> >>> >>> Thx Dinh, so you are using the Enhanced/Alternate descriptors >>> I am debugging on my side on a setup with normal descriptors, I let you >>> know >>> >> >> Doesn't the printout "Enhanced/Alternate descriptors" mean that I'm using >> Enhanced/Alternate descriptors? > > > yes this means that you have the Databook 3.70a and, from the HW > capability register, the driver will use the Enhanced/Alternate > descriptors. This is the same HW I am using on my side where the > stmmac is working fine. > > In the case where it is failing on net-next, although on Databook 3.50a, > the HW capability register says that there is no enhanced descriptors > and the driver uses the normal ones. > > Tomeu, I kindly ask you to try the patch attached. I found a bug on Tx > path for normal descriptors. Please let me know if this help. > Also let me know if we actually need to revert the 0e80bdc9a72d. Hi Peppe, with that patch I don't see any difference at all in my setup. So to be clear, with these commits on top of next-20160314, I still get the hang during boot: 209afef6f0cd ARM: dts: rockchip: Add mdio node to ethernet node 2315acc6cf7f Revert "stmmac: first frame prep at the end of xmit routine" b5e08e810c63 stmmac: fix tx prepare for normal desc 37c15a31d850 i2c: immediately mark ourselves as registered 4342eec3c5a2 Add linux-next specific files for 20160314 [ 27.521026] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:303 dev_watchdog+0x284/0x288 [ 27.529460] NETDEV WATCHDOG: eth0 (rk_gmac-dwmac): transmit queue 0 timed out https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=broken-eth-on-rock2 > I am trying to find some HW where test the normal descriptors to > speed-up the tests on my side directly. Maybe get your tree in kernelci.org? I'm not sure if it's currently doing any nfsroot boots, though. Regards, Tomeu > Let me know and thx in advance. > > Regards, > Peppe > >> >> Dinh >> > ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <CAAObsKB-tSCu5KMYk2Zi-oX9zMKEOwwT93sMkiZKiYvtexmHaQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement [not found] ` <CAAObsKB-tSCu5KMYk2Zi-oX9zMKEOwwT93sMkiZKiYvtexmHaQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2016-03-14 16:20 ` Giuseppe CAVALLARO [not found] ` <56E6E4B0.8060408-qxv4g6HH51o@public.gmane.org> 0 siblings, 1 reply; 52+ messages in thread From: Giuseppe CAVALLARO @ 2016-03-14 16:20 UTC (permalink / raw) To: Tomeu Vizoso Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Dinh Nguyen, Heiko Stübner, netdev-u79uwXL29TY76Z2rM5mHXA, LKML, Frank Schäfer, open list:ARM/Rockchip SoC..., Gabriel Fernandez, Fabrice GASNIER, Andreas Färber, LAKML, Alexandre TORGUE Hi Tomeu On 3/14/2016 12:43 PM, Tomeu Vizoso wrote: > Hi Peppe, > > with that patch I don't see any difference at all in my setup. > > So to be clear, with these commits on top of next-20160314, I still > get the hang during boot: > > 209afef6f0cd ARM: dts: rockchip: Add mdio node to ethernet node > 2315acc6cf7f Revert "stmmac: first frame prep at the end of xmit routine" > b5e08e810c63 stmmac: fix tx prepare for normal desc > 37c15a31d850 i2c: immediately mark ourselves as registered > 4342eec3c5a2 Add linux-next specific files for 20160314 > > [ 27.521026] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:303 > dev_watchdog+0x284/0x288 > [ 27.529460] NETDEV WATCHDOG: eth0 (rk_gmac-dwmac): transmit queue 0 timed out I do not reproduce the WATCHDOG but i am continuing to look at the code to understand if normal descriptor management is ok or not. I keep you informed. Just an info, did you test with 2315acc6cf7f included? Just to understand if it is introducing a problem. It works in case of enhanced descriptors are used instead of. > > https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=broken-eth-on-rock2 thx I will take a look at this Regards Peppe ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <56E6E4B0.8060408-qxv4g6HH51o@public.gmane.org>]
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement [not found] ` <56E6E4B0.8060408-qxv4g6HH51o@public.gmane.org> @ 2016-03-15 7:23 ` Tomeu Vizoso [not found] ` <CAAObsKCdk+6HdzFYxRKZbPiaKcfMCLjbpngurat47YvyvSgH-w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 52+ messages in thread From: Tomeu Vizoso @ 2016-03-15 7:23 UTC (permalink / raw) To: Giuseppe CAVALLARO Cc: Dinh Nguyen, Andreas Färber, Fabrice GASNIER, devicetree-u79uwXL29TY76Z2rM5mHXA, Heiko Stübner, netdev-u79uwXL29TY76Z2rM5mHXA, open list:ARM/Rockchip SoC..., LAKML, Gabriel Fernandez, Alexandre TORGUE, Frank Schäfer, LKML On 14 March 2016 at 17:20, Giuseppe CAVALLARO <peppe.cavallaro-qxv4g6HH51o@public.gmane.org> wrote: > Hi Tomeu > > On 3/14/2016 12:43 PM, Tomeu Vizoso wrote: >> >> Hi Peppe, >> >> with that patch I don't see any difference at all in my setup. >> >> So to be clear, with these commits on top of next-20160314, I still >> get the hang during boot: >> >> 209afef6f0cd ARM: dts: rockchip: Add mdio node to ethernet node >> 2315acc6cf7f Revert "stmmac: first frame prep at the end of xmit routine" >> b5e08e810c63 stmmac: fix tx prepare for normal desc >> 37c15a31d850 i2c: immediately mark ourselves as registered >> 4342eec3c5a2 Add linux-next specific files for 20160314 >> >> [ 27.521026] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:303 >> dev_watchdog+0x284/0x288 >> [ 27.529460] NETDEV WATCHDOG: eth0 (rk_gmac-dwmac): transmit queue 0 >> timed out > > > I do not reproduce the WATCHDOG but i am continuing to look at the code > to understand if normal descriptor management is ok or not. I keep you > informed. > > Just an info, did you test with 2315acc6cf7f included? Just to > understand if it is introducing a problem. It works in case of > enhanced descriptors are used instead of. > >> >> >> https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=broken-eth-on-rock2 > > > thx I will take a look at this Thanks. Btw, I have rebased on top of 4.5 this morning and I have noticed that 88f8b1bb41c6 ("stmmac: Fix 'eth0: No PHY found' regression") got in there, so I guess we have now a bunch of boards with broken network on that release :( Regards, Tomeu > Regards > Peppe > > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <CAAObsKCdk+6HdzFYxRKZbPiaKcfMCLjbpngurat47YvyvSgH-w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement [not found] ` <CAAObsKCdk+6HdzFYxRKZbPiaKcfMCLjbpngurat47YvyvSgH-w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2016-03-15 12:36 ` Giuseppe CAVALLARO [not found] ` <56E801EB.6030107-qxv4g6HH51o@public.gmane.org> 0 siblings, 1 reply; 52+ messages in thread From: Giuseppe CAVALLARO @ 2016-03-15 12:36 UTC (permalink / raw) To: Tomeu Vizoso Cc: Dinh Nguyen, Andreas Färber, Fabrice GASNIER, devicetree-u79uwXL29TY76Z2rM5mHXA, Heiko Stübner, netdev-u79uwXL29TY76Z2rM5mHXA, open list:ARM/Rockchip SoC..., LAKML, Gabriel Fernandez, Alexandre TORGUE, Frank Schäfer, LKML [-- Attachment #1: Type: text/plain, Size: 1324 bytes --] Hello Tomeu On 3/15/2016 8:23 AM, Tomeu Vizoso wrote: > Thanks. > > Btw, I have rebased on top of 4.5 this morning and I have noticed that > 88f8b1bb41c6 ("stmmac: Fix 'eth0: No PHY found' regression") got in > there, so I guess we have now a bunch of boards with broken network on > that release:( This is the status on my side: I am testing on an HW that has the Enhanced descriptors and all works fine. On this HW, if I force the driver to use the normal descriptor layout, I meet problems but using both net.git and net-next. So I suspect I cannot ply with this HW forcing the normal descriptors. But! That is helping me to check if, on net-next, the stmmac is actually programming fine the normal desc case. I have just found another fix so I kindly ask you to apply the temp patch attached and let me know. In details, I have noticed that the OWN bit was not set in the right TDES0. I also ask you to give me a log of the kernel where the stmmac was running fine. I would like to see which configuration it is selected at runtime by the driver on your box. From your previous logs (where the stmmac failed), it seems that the problem is on normal desc but, to be honest, this is the first case I see a 3.50a with HW capability register and w/o Enhanced descriptors. Best Regards Peppe > Regards, > > Tomeu [-- Attachment #2: tmp.patch --] [-- Type: text/x-patch, Size: 542 bytes --] diff --git a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c index e13228f..44c052f 100644 --- a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c +++ b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c @@ -217,10 +217,10 @@ static void ndesc_prepare_tx_desc(struct dma_desc *p, int is_fs, int len, if (ls) tdes1 |= TDES1_LAST_SEGMENT; - if (tx_own) - tdes1 |= TDES0_OWN; - p->des1 = tdes1; + + if (tx_own) + p->des0 |= TDES0_OWN; } static void ndesc_set_tx_ic(struct dma_desc *p) ^ permalink raw reply related [flat|nested] 52+ messages in thread
[parent not found: <56E801EB.6030107-qxv4g6HH51o@public.gmane.org>]
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement [not found] ` <56E801EB.6030107-qxv4g6HH51o@public.gmane.org> @ 2016-03-30 16:44 ` Dinh Nguyen [not found] ` <CADhT+wdXXp322vmgFmWTUiiRZTsCWeJSSdU=BMEEbSyb_bnrUw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 52+ messages in thread From: Dinh Nguyen @ 2016-03-30 16:44 UTC (permalink / raw) To: Giuseppe CAVALLARO Cc: Tomeu Vizoso, Andreas Färber, Fabrice GASNIER, devicetree-u79uwXL29TY76Z2rM5mHXA, Heiko Stübner, netdev-u79uwXL29TY76Z2rM5mHXA, open list:ARM/Rockchip SoC..., LAKML, Gabriel Fernandez, Alexandre TORGUE, Frank Schäfer, LKML On Tue, Mar 15, 2016 at 7:36 AM, Giuseppe CAVALLARO <peppe.cavallaro-qxv4g6HH51o@public.gmane.org> wrote: > Hello Tomeu > > On 3/15/2016 8:23 AM, Tomeu Vizoso wrote: >> >> Thanks. >> >> Btw, I have rebased on top of 4.5 this morning and I have noticed that >> 88f8b1bb41c6 ("stmmac: Fix 'eth0: No PHY found' regression") got in >> there, so I guess we have now a bunch of boards with broken network on >> that release:( > > > > This is the status on my side: I am testing on an HW that has the > Enhanced descriptors and all works fine. > > On this HW, if I force the driver to use the normal descriptor > layout, I meet problems but using both net.git and net-next. > So I suspect I cannot ply with this HW forcing the normal descriptors. > But! That is helping me to check if, on net-next, the stmmac is > actually programming fine the normal desc case. > I have just found another fix so I kindly ask you to apply the temp > patch attached and let me know. > In details, I have noticed that the OWN bit was not set in the right > TDES0. > > I also ask you to give me a log of the kernel where the stmmac was > running fine. I would like to see which configuration it is selected > at runtime by the driver on your box. > From your previous logs (where the stmmac failed), it seems that > the problem is on normal desc but, to be honest, this is the first > case I see a 3.50a with HW capability register and w/o Enhanced > descriptors. > Are you still working on a fix for: [ 1.196110] libphy: PHY stmmac-0:ffffffff not found [ 1.200972] eth0: Could not attach to PHY [ 1.204991] stmmac_open: Cannot attach to PHY (error: -19) I see the error still there as of linux-next 20160330. Dinh -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <CADhT+wdXXp322vmgFmWTUiiRZTsCWeJSSdU=BMEEbSyb_bnrUw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement [not found] ` <CADhT+wdXXp322vmgFmWTUiiRZTsCWeJSSdU=BMEEbSyb_bnrUw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2016-03-31 7:53 ` Giuseppe CAVALLARO 0 siblings, 0 replies; 52+ messages in thread From: Giuseppe CAVALLARO @ 2016-03-31 7:53 UTC (permalink / raw) To: Dinh Nguyen Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Heiko Stübner, netdev-u79uwXL29TY76Z2rM5mHXA, Gabriel Fernandez, LKML, Frank Schäfer, open list:ARM/Rockchip SoC..., LAKML, Fabrice GASNIER, Andreas Färber, Tomeu Vizoso, Alexandre TORGUE On 3/30/2016 6:44 PM, Dinh Nguyen wrote: > On Tue, Mar 15, 2016 at 7:36 AM, Giuseppe CAVALLARO > <peppe.cavallaro-qxv4g6HH51o@public.gmane.org> wrote: >> Hello Tomeu >> >> On 3/15/2016 8:23 AM, Tomeu Vizoso wrote: >>> >>> Thanks. >>> >>> Btw, I have rebased on top of 4.5 this morning and I have noticed that >>> 88f8b1bb41c6 ("stmmac: Fix 'eth0: No PHY found' regression") got in >>> there, so I guess we have now a bunch of boards with broken network on >>> that release:( >> >> >> >> This is the status on my side: I am testing on an HW that has the >> Enhanced descriptors and all works fine. >> >> On this HW, if I force the driver to use the normal descriptor >> layout, I meet problems but using both net.git and net-next. >> So I suspect I cannot ply with this HW forcing the normal descriptors. >> But! That is helping me to check if, on net-next, the stmmac is >> actually programming fine the normal desc case. >> I have just found another fix so I kindly ask you to apply the temp >> patch attached and let me know. >> In details, I have noticed that the OWN bit was not set in the right >> TDES0. >> >> I also ask you to give me a log of the kernel where the stmmac was >> running fine. I would like to see which configuration it is selected >> at runtime by the driver on your box. >> From your previous logs (where the stmmac failed), it seems that >> the problem is on normal desc but, to be honest, this is the first >> case I see a 3.50a with HW capability register and w/o Enhanced >> descriptors. >> > > Are you still working on a fix for: > > [ 1.196110] libphy: PHY stmmac-0:ffffffff not found > [ 1.200972] eth0: Could not attach to PHY > [ 1.204991] stmmac_open: Cannot attach to PHY (error: -19) > > I see the error still there as of linux-next 20160330. this could be because the fixes have been not applied on net-next I will check and resend all asap peppe > > Dinh > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement [not found] ` <CADhT+wfO8x4En78g5ixnnwbpaeXJGDo+Q1sOABYsbXzNZy0CPw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-03-08 7:24 ` Giuseppe CAVALLARO @ 2016-03-08 10:03 ` Gabriel Fernandez [not found] ` <CAG374jBLD5YuBT=r3V98OqdUTXMepvQ_tLz4XMJdQMzzGYi22A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 1 sibling, 1 reply; 52+ messages in thread From: Gabriel Fernandez @ 2016-03-08 10:03 UTC (permalink / raw) To: Dinh Nguyen Cc: Andreas Färber, Giuseppe CAVALLARO, Heiko Stübner, open list:ARM/Rockchip SoC..., netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA, LAKML, Alexandre TORGUE, Fabrice GASNIER Hi Andreas and Dinh Thanks for your feedback i will check it. Best regards Gabriel On 8 March 2016 at 00:22, Dinh Nguyen <dinh.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > On Mon, Mar 7, 2016 at 11:15 AM, Andreas Färber <afaerber@suse.de> wrote: >> Am 07.03.2016 um 16:52 schrieb Giuseppe CAVALLARO: >>> On 3/7/2016 4:46 PM, Andreas Färber wrote: >>>> Am 07.03.2016 um 16:09 schrieb Giuseppe CAVALLARO: >>>>> On 3/7/2016 3:27 PM, Andreas Färber wrote: >>>>>> Indeed, reverting Gabriel's commit fixes the observed error messages >>>> [...] >>>>>> However, I am unable to ping any hosts on the network now. >>>>> >>>>> hmm, this could be another problem. I wonder if you can >>>>> check which recent patch is introducing the problem on ARM64. >>>>> For example if this depends on Oct_2015 update. >>>> >>>> I've had success reverting drivers/net/ethernet/stmicro/ up to and >>>> including "stmmac: first frame prep at the end of xmit routine", i.e. >>>> top 7 commits. >>> >>> Andreas, I will check it and let you know asap. >> >> I verified that it's just these two commits that I need to revert: >> >> "stmmac: Fix 'eth0: No PHY found' regression" >> "stmmac: first frame prep at the end of xmit routine" >> >> Those in between don't cause conflicts and seem to work okay. >> > > I'm seeing the same issue on the SoCFPGA platform: > > libphy: PHY stmmac-0:ffffffff not found > eth0: Could not attach to PHY > stmmac_open: Cannot attach to PHY (error: -19) > > If I just revert: > > "stmmac: Fix 'eth0: No PHY found' regression" > > then the issue goes away. > > Thanks, > Dinh -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <CAG374jBLD5YuBT=r3V98OqdUTXMepvQ_tLz4XMJdQMzzGYi22A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement [not found] ` <CAG374jBLD5YuBT=r3V98OqdUTXMepvQ_tLz4XMJdQMzzGYi22A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2016-03-08 10:24 ` Giuseppe CAVALLARO [not found] ` <56DEA840.1050305-qxv4g6HH51o@public.gmane.org> 0 siblings, 1 reply; 52+ messages in thread From: Giuseppe CAVALLARO @ 2016-03-08 10:24 UTC (permalink / raw) To: Gabriel Fernandez, Dinh Nguyen Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Heiko Stübner, netdev-u79uwXL29TY76Z2rM5mHXA, open list:ARM/Rockchip SoC..., Fabrice GASNIER, Andreas Färber, LAKML, Alexandre TORGUE On 3/8/2016 11:03 AM, Gabriel Fernandez wrote: > Hi Andreas and Dinh Thanks for your feedback i will check it. hmm, I was looking at the code and indeed I have some doubt on mdio_bus_data management that the patch changes explaining why the Andreas's box fails and phy_add is not detected. Keep the sync peppe > Best regards > > Gabriel > > On 8 March 2016 at 00:22, Dinh Nguyen <dinh.linux@gmail.com> wrote: >> On Mon, Mar 7, 2016 at 11:15 AM, Andreas Färber <afaerber@suse.de> wrote: >>> Am 07.03.2016 um 16:52 schrieb Giuseppe CAVALLARO: >>>> On 3/7/2016 4:46 PM, Andreas Färber wrote: >>>>> Am 07.03.2016 um 16:09 schrieb Giuseppe CAVALLARO: >>>>>> On 3/7/2016 3:27 PM, Andreas Färber wrote: >>>>>>> Indeed, reverting Gabriel's commit fixes the observed error messages >>>>> [...] >>>>>>> However, I am unable to ping any hosts on the network now. >>>>>> >>>>>> hmm, this could be another problem. I wonder if you can >>>>>> check which recent patch is introducing the problem on ARM64. >>>>>> For example if this depends on Oct_2015 update. >>>>> >>>>> I've had success reverting drivers/net/ethernet/stmicro/ up to and >>>>> including "stmmac: first frame prep at the end of xmit routine", i.e. >>>>> top 7 commits. >>>> >>>> Andreas, I will check it and let you know asap. >>> >>> I verified that it's just these two commits that I need to revert: >>> >>> "stmmac: Fix 'eth0: No PHY found' regression" >>> "stmmac: first frame prep at the end of xmit routine" >>> >>> Those in between don't cause conflicts and seem to work okay. >>> >> >> I'm seeing the same issue on the SoCFPGA platform: >> >> libphy: PHY stmmac-0:ffffffff not found >> eth0: Could not attach to PHY >> stmmac_open: Cannot attach to PHY (error: -19) >> >> If I just revert: >> >> "stmmac: Fix 'eth0: No PHY found' regression" >> >> then the issue goes away. >> >> Thanks, >> Dinh > > _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <56DEA840.1050305-qxv4g6HH51o@public.gmane.org>]
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement [not found] ` <56DEA840.1050305-qxv4g6HH51o@public.gmane.org> @ 2016-03-08 10:33 ` Gabriel Fernandez 0 siblings, 0 replies; 52+ messages in thread From: Gabriel Fernandez @ 2016-03-08 10:33 UTC (permalink / raw) To: Giuseppe CAVALLARO Cc: Dinh Nguyen, Andreas Färber, Heiko Stübner, open list:ARM/Rockchip SoC..., netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA, LAKML, Alexandre TORGUE, Fabrice GASNIER On 8 March 2016 at 11:24, Giuseppe CAVALLARO <peppe.cavallaro-qxv4g6HH51o@public.gmane.org> wrote: > On 3/8/2016 11:03 AM, Gabriel Fernandez wrote: >> >> Hi Andreas and Dinh Thanks for your feedback i will check it. > > > hmm, I was looking at the code and indeed I have some doubt on > mdio_bus_data management that the patch changes explaining > why the Andreas's box fails and phy_add is not detected. > > Keep the sync > > peppe > Okay Thanks Peppe Gabriel > > >> Best regards >> >> Gabriel >> >> On 8 March 2016 at 00:22, Dinh Nguyen <dinh.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >>> >>> On Mon, Mar 7, 2016 at 11:15 AM, Andreas Färber <afaerber@suse.de> wrote: >>>> >>>> Am 07.03.2016 um 16:52 schrieb Giuseppe CAVALLARO: >>>>> >>>>> On 3/7/2016 4:46 PM, Andreas Färber wrote: >>>>>> >>>>>> Am 07.03.2016 um 16:09 schrieb Giuseppe CAVALLARO: >>>>>>> >>>>>>> On 3/7/2016 3:27 PM, Andreas Färber wrote: >>>>>>>> >>>>>>>> Indeed, reverting Gabriel's commit fixes the observed error messages >>>>>> >>>>>> [...] >>>>>>>> >>>>>>>> However, I am unable to ping any hosts on the network now. >>>>>>> >>>>>>> >>>>>>> hmm, this could be another problem. I wonder if you can >>>>>>> check which recent patch is introducing the problem on ARM64. >>>>>>> For example if this depends on Oct_2015 update. >>>>>> >>>>>> >>>>>> I've had success reverting drivers/net/ethernet/stmicro/ up to and >>>>>> including "stmmac: first frame prep at the end of xmit routine", i.e. >>>>>> top 7 commits. >>>>> >>>>> >>>>> Andreas, I will check it and let you know asap. >>>> >>>> >>>> I verified that it's just these two commits that I need to revert: >>>> >>>> "stmmac: Fix 'eth0: No PHY found' regression" >>>> "stmmac: first frame prep at the end of xmit routine" >>>> >>>> Those in between don't cause conflicts and seem to work okay. >>>> >>> >>> I'm seeing the same issue on the SoCFPGA platform: >>> >>> libphy: PHY stmmac-0:ffffffff not found >>> eth0: Could not attach to PHY >>> stmmac_open: Cannot attach to PHY (error: -19) >>> >>> If I just revert: >>> >>> "stmmac: Fix 'eth0: No PHY found' regression" >>> >>> then the issue goes away. >>> >>> Thanks, >>> Dinh >> >> >> > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement 2016-03-07 12:17 ` [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement Andreas Färber 2016-03-07 12:24 ` Heiko Stübner @ 2016-03-11 12:12 ` Michael Trimarchi 1 sibling, 0 replies; 52+ messages in thread From: Michael Trimarchi @ 2016-03-11 12:12 UTC (permalink / raw) To: Andreas Färber Cc: open list:ARM/Rockchip SoC..., netdev, devicetree, Heiko Stuebner, LAKML, Giuseppe Cavallaro Hi On Mon, Mar 7, 2016 at 1:17 PM, Andreas Färber <afaerber@suse.de> wrote: > Am 06.03.2016 um 20:53 schrieb Andreas Färber: >> On next-20160304 the GMAC seems to have regressed, it no longer finds the PHY: >> >> libphy: PHY stmmac-0:ffffffff not found >> eth0: Could not attach to PHY >> stmmac_open: Cannot attach to PHY (error: -19) > > Still with us in next-20160307. CC'ing stmmac maintainers. > tx_delay = <0x30>; rx_delay = <0x10>; status = "ok"; + mdio0 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "snps,dwmac-mdio"; + ethphy0: ethernet-phy@0 { + }; + }; This is sufficient to get it in the rk3288 firefly git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git for-next Michael > http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/drivers/net/ethernet/stmicro > > Regards, > Andreas > > -- > SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) > > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | ^ permalink raw reply [flat|nested] 52+ messages in thread
end of thread, other threads:[~2016-03-31 7:53 UTC | newest] Thread overview: 52+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-03-06 19:53 [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement Andreas Färber 2016-03-06 19:53 ` [PATCH v3 3/8] arm64: dts: rockchip: Add GeekBox config Andreas Färber 2016-03-06 19:53 ` [PATCH v3 6/8] arm64: dts: rockchip: Add power key to GeekBox Andreas Färber [not found] ` <1457294038-14243-7-git-send-email-afaerber-l3A5Bk7waGM@public.gmane.org> 2016-03-10 23:04 ` Julien Chauveau 2016-03-16 10:58 ` Andreas Färber [not found] ` <56E93C43.1060500-l3A5Bk7waGM@public.gmane.org> 2016-03-16 13:52 ` Andreas Färber 2016-03-10 23:09 ` Julien Chauveau 2016-03-06 19:53 ` [PATCH v3 7/8] Documentation: devicetree: rockchip: Document Landingship Andreas Färber 2016-03-17 14:46 ` Rob Herring [not found] ` <1457294038-14243-1-git-send-email-afaerber-l3A5Bk7waGM@public.gmane.org> 2016-03-06 19:53 ` [PATCH v3 1/8] Documentation: devicetree: Add vendor prefix for GeekBuying.com Andreas Färber 2016-03-06 19:53 ` [PATCH v3 2/8] Documentation: devicetree: rockchip: Document GeekBox Andreas Färber 2016-03-06 19:53 ` [PATCH v3 4/8] Documentation: devicetree: Clean up gpio-keys example Andreas Färber 2016-03-07 18:05 ` Heiko Stübner 2016-03-07 18:27 ` Andreas Färber 2016-03-06 19:53 ` [PATCH v3 5/8] arm64: dts: rockchip: Clean up gpio-keys nodes Andreas Färber 2016-03-06 19:53 ` [PATCH v3 8/8] arm64: dts: rockchip: Add Landingship config Andreas Färber 2016-03-07 12:17 ` [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement Andreas Färber 2016-03-07 12:24 ` Heiko Stübner 2016-03-07 12:35 ` Andreas Färber 2016-03-07 13:26 ` Giuseppe CAVALLARO 2016-03-07 14:27 ` Andreas Färber [not found] ` <56DD8FBE.9010200-l3A5Bk7waGM@public.gmane.org> 2016-03-07 15:09 ` Giuseppe CAVALLARO 2016-03-07 15:46 ` Andreas Färber [not found] ` <56DDA26C.3050301-l3A5Bk7waGM@public.gmane.org> 2016-03-07 15:52 ` Giuseppe CAVALLARO 2016-03-07 17:15 ` Andreas Färber [not found] ` <56DDB749.1020808-l3A5Bk7waGM@public.gmane.org> 2016-03-07 23:22 ` Dinh Nguyen [not found] ` <CADhT+wfO8x4En78g5ixnnwbpaeXJGDo+Q1sOABYsbXzNZy0CPw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-03-08 7:24 ` Giuseppe CAVALLARO 2016-03-08 15:45 ` Dinh Nguyen 2016-03-09 7:24 ` Giuseppe CAVALLARO 2016-03-09 8:35 ` Tomeu Vizoso [not found] ` <CAAObsKD9HoEbtV_JMz_R=bcrQseDmhncRAWP9k8djksL-LMQqw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-03-09 8:56 ` Giuseppe CAVALLARO [not found] ` <56DFE55B.2090806-qxv4g6HH51o@public.gmane.org> 2016-03-09 9:00 ` Giuseppe CAVALLARO [not found] ` <56DFE64B.8060606-qxv4g6HH51o@public.gmane.org> 2016-03-09 9:42 ` Tomeu Vizoso [not found] ` <CAAObsKBr9SXg1-wr9O-ypR8JozdGpeAwfDLMeUKi8ozxkKyTXg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-03-09 9:52 ` Giuseppe CAVALLARO 2016-03-09 10:27 ` Giuseppe CAVALLARO 2016-03-09 10:53 ` Tomeu Vizoso 2016-03-09 14:31 ` Giuseppe CAVALLARO [not found] ` <56E033C8.40506@st.c om> [not found] ` <56E033C8.40506-qxv4g6HH51o@public.gmane.org> 2016-03-09 14:53 ` Giuseppe CAVALLARO [not found] ` <56E038CE.606-qxv4g6HH51o@public.gmane.org> 2016-03-09 16:31 ` Dinh Nguyen [not found] ` <CADhT+wcMpzA_Coj8Z5OQZsc3bF3a7yOmsbazQMPtcdUWkJSuCA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-03-10 9:13 ` Giuseppe CAVALLARO [not found] ` <56E13AAB.2080900-qxv4g6HH51o@public.gmane.org> 2016-03-10 16:47 ` Dinh Nguyen [not found] ` <CADhT+wd=vcph2y_OxkGNO5EwHvN=kBy-BrfZHmNjZHww4LxmTg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-03-11 9:09 ` Giuseppe CAVALLARO 2016-03-14 11:43 ` Tomeu Vizoso [not found] ` <CAAObsKB-tSCu5KMYk2Zi-oX9zMKEOwwT93sMkiZKiYvtexmHaQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-03-14 16:20 ` Giuseppe CAVALLARO [not found] ` <56E6E4B0.8060408-qxv4g6HH51o@public.gmane.org> 2016-03-15 7:23 ` Tomeu Vizoso [not found] ` <CAAObsKCdk+6HdzFYxRKZbPiaKcfMCLjbpngurat47YvyvSgH-w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-03-15 12:36 ` Giuseppe CAVALLARO [not found] ` <56E801EB.6030107-qxv4g6HH51o@public.gmane.org> 2016-03-30 16:44 ` Dinh Nguyen [not found] ` <CADhT+wdXXp322vmgFmWTUiiRZTsCWeJSSdU=BMEEbSyb_bnrUw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-03-31 7:53 ` Giuseppe CAVALLARO 2016-03-08 10:03 ` Gabriel Fernandez [not found] ` <CAG374jBLD5YuBT=r3V98OqdUTXMepvQ_tLz4XMJdQMzzGYi22A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-03-08 10:24 ` Giuseppe CAVALLARO [not found] ` <56DEA840.1050305-qxv4g6HH51o@public.gmane.org> 2016-03-08 10:33 ` Gabriel Fernandez 2016-03-11 12:12 ` Michael Trimarchi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).