* [PATCH v3] ARM: zynq: DT: Add USB to device tree @ 2014-12-02 16:07 ` Soren Brinkmann 0 siblings, 0 replies; 34+ messages in thread From: Soren Brinkmann @ 2014-12-02 16:07 UTC (permalink / raw) To: Michal Simek Cc: Sören Brinkmann, devicetree, linux-kernel, linux-arm-kernel, Peter Crosthwaite, Andreas Färber, Arnd Bergmann Add USB nodes to zc702, zc706 and zed device trees. Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com> --- v3: - rename phy nodes: usb_phy -> phy0 - rebased onto zynq/dt v2: - remove '@0' from phy node name - don't add bogus space --- arch/arm/boot/dts/zynq-7000.dtsi | 20 ++++++++++++++++++++ arch/arm/boot/dts/zynq-zc702.dts | 11 +++++++++++ arch/arm/boot/dts/zynq-zc706.dts | 10 ++++++++++ arch/arm/boot/dts/zynq-zed.dts | 10 ++++++++++ 4 files changed, 51 insertions(+) diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi index f8e4a28adfc0..21aae01a3fe9 100644 --- a/arch/arm/boot/dts/zynq-7000.dtsi +++ b/arch/arm/boot/dts/zynq-7000.dtsi @@ -314,5 +314,25 @@ reg = <0xf8f00600 0x20>; clocks = <&clkc 4>; }; + + usb0: usb@e0002000 { + compatible = "xlnx,zynq-usb-2.20a", "chipidea,usb2"; + status = "disabled"; + clocks = <&clkc 28>; + interrupt-parent = <&intc>; + interrupts = <0 21 4>; + reg = <0xe0002000 0x1000>; + phy_type = "ulpi"; + }; + + usb1: usb@e0003000 { + compatible = "xlnx,zynq-usb-2.20a", "chipidea,usb2"; + status = "disabled"; + clocks = <&clkc 29>; + interrupt-parent = <&intc>; + interrupts = <0 44 4>; + reg = <0xe0003000 0x1000>; + phy_type = "ulpi"; + }; }; }; diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts index 280f02dd4ddc..399fed4d9c19 100644 --- a/arch/arm/boot/dts/zynq-zc702.dts +++ b/arch/arm/boot/dts/zynq-zc702.dts @@ -36,6 +36,11 @@ linux,default-trigger = "heartbeat"; }; }; + + usb_phy0: phy0 { + compatible = "usb-nop-xceiv"; + #phy-cells = <0>; + }; }; &can0 { @@ -139,3 +144,9 @@ &uart1 { status = "okay"; }; + +&usb0 { + status = "okay"; + dr_mode = "host"; + usb-phy = <&usb_phy0>; +}; diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts index 34f7812d2ee8..89cc9adc569d 100644 --- a/arch/arm/boot/dts/zynq-zc706.dts +++ b/arch/arm/boot/dts/zynq-zc706.dts @@ -27,6 +27,10 @@ bootargs = "console=ttyPS0,115200 earlyprintk"; }; + usb_phy0: phy0 { + compatible = "usb-nop-xceiv"; + #phy-cells = <0>; + }; }; &clkc { @@ -118,3 +122,9 @@ &uart1 { status = "okay"; }; + +&usb0 { + status = "okay"; + dr_mode = "host"; + usb-phy = <&usb_phy0>; +}; diff --git a/arch/arm/boot/dts/zynq-zed.dts b/arch/arm/boot/dts/zynq-zed.dts index 1c7cc990b47a..e20956e5e720 100644 --- a/arch/arm/boot/dts/zynq-zed.dts +++ b/arch/arm/boot/dts/zynq-zed.dts @@ -27,6 +27,10 @@ bootargs = "console=ttyPS0,115200 earlyprintk"; }; + usb_phy0: phy0 { + compatible = "usb-nop-xceiv"; + #phy-cells = <0>; + }; }; &clkc { @@ -50,3 +54,9 @@ &uart1 { status = "okay"; }; + +&usb0 { + status = "okay"; + dr_mode = "host"; + usb-phy = <&usb_phy0>; +}; -- 2.2.0.1.g9ee0458 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v3] ARM: zynq: DT: Add USB to device tree @ 2014-12-02 16:07 ` Soren Brinkmann 0 siblings, 0 replies; 34+ messages in thread From: Soren Brinkmann @ 2014-12-02 16:07 UTC (permalink / raw) To: linux-arm-kernel Add USB nodes to zc702, zc706 and zed device trees. Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com> --- v3: - rename phy nodes: usb_phy -> phy0 - rebased onto zynq/dt v2: - remove '@0' from phy node name - don't add bogus space --- arch/arm/boot/dts/zynq-7000.dtsi | 20 ++++++++++++++++++++ arch/arm/boot/dts/zynq-zc702.dts | 11 +++++++++++ arch/arm/boot/dts/zynq-zc706.dts | 10 ++++++++++ arch/arm/boot/dts/zynq-zed.dts | 10 ++++++++++ 4 files changed, 51 insertions(+) diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi index f8e4a28adfc0..21aae01a3fe9 100644 --- a/arch/arm/boot/dts/zynq-7000.dtsi +++ b/arch/arm/boot/dts/zynq-7000.dtsi @@ -314,5 +314,25 @@ reg = <0xf8f00600 0x20>; clocks = <&clkc 4>; }; + + usb0: usb at e0002000 { + compatible = "xlnx,zynq-usb-2.20a", "chipidea,usb2"; + status = "disabled"; + clocks = <&clkc 28>; + interrupt-parent = <&intc>; + interrupts = <0 21 4>; + reg = <0xe0002000 0x1000>; + phy_type = "ulpi"; + }; + + usb1: usb at e0003000 { + compatible = "xlnx,zynq-usb-2.20a", "chipidea,usb2"; + status = "disabled"; + clocks = <&clkc 29>; + interrupt-parent = <&intc>; + interrupts = <0 44 4>; + reg = <0xe0003000 0x1000>; + phy_type = "ulpi"; + }; }; }; diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts index 280f02dd4ddc..399fed4d9c19 100644 --- a/arch/arm/boot/dts/zynq-zc702.dts +++ b/arch/arm/boot/dts/zynq-zc702.dts @@ -36,6 +36,11 @@ linux,default-trigger = "heartbeat"; }; }; + + usb_phy0: phy0 { + compatible = "usb-nop-xceiv"; + #phy-cells = <0>; + }; }; &can0 { @@ -139,3 +144,9 @@ &uart1 { status = "okay"; }; + +&usb0 { + status = "okay"; + dr_mode = "host"; + usb-phy = <&usb_phy0>; +}; diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts index 34f7812d2ee8..89cc9adc569d 100644 --- a/arch/arm/boot/dts/zynq-zc706.dts +++ b/arch/arm/boot/dts/zynq-zc706.dts @@ -27,6 +27,10 @@ bootargs = "console=ttyPS0,115200 earlyprintk"; }; + usb_phy0: phy0 { + compatible = "usb-nop-xceiv"; + #phy-cells = <0>; + }; }; &clkc { @@ -118,3 +122,9 @@ &uart1 { status = "okay"; }; + +&usb0 { + status = "okay"; + dr_mode = "host"; + usb-phy = <&usb_phy0>; +}; diff --git a/arch/arm/boot/dts/zynq-zed.dts b/arch/arm/boot/dts/zynq-zed.dts index 1c7cc990b47a..e20956e5e720 100644 --- a/arch/arm/boot/dts/zynq-zed.dts +++ b/arch/arm/boot/dts/zynq-zed.dts @@ -27,6 +27,10 @@ bootargs = "console=ttyPS0,115200 earlyprintk"; }; + usb_phy0: phy0 { + compatible = "usb-nop-xceiv"; + #phy-cells = <0>; + }; }; &clkc { @@ -50,3 +54,9 @@ &uart1 { status = "okay"; }; + +&usb0 { + status = "okay"; + dr_mode = "host"; + usb-phy = <&usb_phy0>; +}; -- 2.2.0.1.g9ee0458 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v3] ARM: zynq: DT: Add USB to device tree @ 2014-12-02 16:07 ` Soren Brinkmann 0 siblings, 0 replies; 34+ messages in thread From: Soren Brinkmann @ 2014-12-02 16:07 UTC (permalink / raw) To: Michal Simek Cc: Sören Brinkmann, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Peter Crosthwaite, Andreas Färber, Arnd Bergmann Add USB nodes to zc702, zc706 and zed device trees. Signed-off-by: Soren Brinkmann <soren.brinkmann-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> --- v3: - rename phy nodes: usb_phy -> phy0 - rebased onto zynq/dt v2: - remove '@0' from phy node name - don't add bogus space --- arch/arm/boot/dts/zynq-7000.dtsi | 20 ++++++++++++++++++++ arch/arm/boot/dts/zynq-zc702.dts | 11 +++++++++++ arch/arm/boot/dts/zynq-zc706.dts | 10 ++++++++++ arch/arm/boot/dts/zynq-zed.dts | 10 ++++++++++ 4 files changed, 51 insertions(+) diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi index f8e4a28adfc0..21aae01a3fe9 100644 --- a/arch/arm/boot/dts/zynq-7000.dtsi +++ b/arch/arm/boot/dts/zynq-7000.dtsi @@ -314,5 +314,25 @@ reg = <0xf8f00600 0x20>; clocks = <&clkc 4>; }; + + usb0: usb@e0002000 { + compatible = "xlnx,zynq-usb-2.20a", "chipidea,usb2"; + status = "disabled"; + clocks = <&clkc 28>; + interrupt-parent = <&intc>; + interrupts = <0 21 4>; + reg = <0xe0002000 0x1000>; + phy_type = "ulpi"; + }; + + usb1: usb@e0003000 { + compatible = "xlnx,zynq-usb-2.20a", "chipidea,usb2"; + status = "disabled"; + clocks = <&clkc 29>; + interrupt-parent = <&intc>; + interrupts = <0 44 4>; + reg = <0xe0003000 0x1000>; + phy_type = "ulpi"; + }; }; }; diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts index 280f02dd4ddc..399fed4d9c19 100644 --- a/arch/arm/boot/dts/zynq-zc702.dts +++ b/arch/arm/boot/dts/zynq-zc702.dts @@ -36,6 +36,11 @@ linux,default-trigger = "heartbeat"; }; }; + + usb_phy0: phy0 { + compatible = "usb-nop-xceiv"; + #phy-cells = <0>; + }; }; &can0 { @@ -139,3 +144,9 @@ &uart1 { status = "okay"; }; + +&usb0 { + status = "okay"; + dr_mode = "host"; + usb-phy = <&usb_phy0>; +}; diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts index 34f7812d2ee8..89cc9adc569d 100644 --- a/arch/arm/boot/dts/zynq-zc706.dts +++ b/arch/arm/boot/dts/zynq-zc706.dts @@ -27,6 +27,10 @@ bootargs = "console=ttyPS0,115200 earlyprintk"; }; + usb_phy0: phy0 { + compatible = "usb-nop-xceiv"; + #phy-cells = <0>; + }; }; &clkc { @@ -118,3 +122,9 @@ &uart1 { status = "okay"; }; + +&usb0 { + status = "okay"; + dr_mode = "host"; + usb-phy = <&usb_phy0>; +}; diff --git a/arch/arm/boot/dts/zynq-zed.dts b/arch/arm/boot/dts/zynq-zed.dts index 1c7cc990b47a..e20956e5e720 100644 --- a/arch/arm/boot/dts/zynq-zed.dts +++ b/arch/arm/boot/dts/zynq-zed.dts @@ -27,6 +27,10 @@ bootargs = "console=ttyPS0,115200 earlyprintk"; }; + usb_phy0: phy0 { + compatible = "usb-nop-xceiv"; + #phy-cells = <0>; + }; }; &clkc { @@ -50,3 +54,9 @@ &uart1 { status = "okay"; }; + +&usb0 { + status = "okay"; + dr_mode = "host"; + usb-phy = <&usb_phy0>; +}; -- 2.2.0.1.g9ee0458 -- 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] 34+ messages in thread
* Re: [PATCH v3] ARM: zynq: DT: Add USB to device tree 2014-12-02 16:07 ` Soren Brinkmann @ 2014-12-03 8:39 ` Michal Simek -1 siblings, 0 replies; 34+ messages in thread From: Michal Simek @ 2014-12-03 8:39 UTC (permalink / raw) To: Soren Brinkmann, Michal Simek Cc: devicetree, linux-kernel, linux-arm-kernel, Peter Crosthwaite, Andreas Färber, Arnd Bergmann On 12/02/2014 05:07 PM, Soren Brinkmann wrote: > Add USB nodes to zc702, zc706 and zed device trees. > > Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com> > --- > v3: > - rename phy nodes: usb_phy -> phy0 > - rebased onto zynq/dt > v2: > - remove '@0' from phy node name > - don't add bogus space > --- > arch/arm/boot/dts/zynq-7000.dtsi | 20 ++++++++++++++++++++ > arch/arm/boot/dts/zynq-zc702.dts | 11 +++++++++++ > arch/arm/boot/dts/zynq-zc706.dts | 10 ++++++++++ > arch/arm/boot/dts/zynq-zed.dts | 10 ++++++++++ > 4 files changed, 51 insertions(+) > > diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi > index f8e4a28adfc0..21aae01a3fe9 100644 > --- a/arch/arm/boot/dts/zynq-7000.dtsi > +++ b/arch/arm/boot/dts/zynq-7000.dtsi > @@ -314,5 +314,25 @@ > reg = <0xf8f00600 0x20>; > clocks = <&clkc 4>; > }; > + > + usb0: usb@e0002000 { > + compatible = "xlnx,zynq-usb-2.20a", "chipidea,usb2"; > + status = "disabled"; > + clocks = <&clkc 28>; > + interrupt-parent = <&intc>; > + interrupts = <0 21 4>; > + reg = <0xe0002000 0x1000>; > + phy_type = "ulpi"; > + }; > + > + usb1: usb@e0003000 { > + compatible = "xlnx,zynq-usb-2.20a", "chipidea,usb2"; > + status = "disabled"; > + clocks = <&clkc 29>; > + interrupt-parent = <&intc>; > + interrupts = <0 44 4>; > + reg = <0xe0003000 0x1000>; > + phy_type = "ulpi"; > + }; > }; > }; > diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts > index 280f02dd4ddc..399fed4d9c19 100644 > --- a/arch/arm/boot/dts/zynq-zc702.dts > +++ b/arch/arm/boot/dts/zynq-zc702.dts > @@ -36,6 +36,11 @@ > linux,default-trigger = "heartbeat"; > }; > }; > + > + usb_phy0: phy0 { > + compatible = "usb-nop-xceiv"; > + #phy-cells = <0>; > + }; > }; > > &can0 { > @@ -139,3 +144,9 @@ > &uart1 { > status = "okay"; > }; > + > +&usb0 { > + status = "okay"; > + dr_mode = "host"; > + usb-phy = <&usb_phy0>; > +}; > diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts > index 34f7812d2ee8..89cc9adc569d 100644 > --- a/arch/arm/boot/dts/zynq-zc706.dts > +++ b/arch/arm/boot/dts/zynq-zc706.dts > @@ -27,6 +27,10 @@ > bootargs = "console=ttyPS0,115200 earlyprintk"; > }; > > + usb_phy0: phy0 { > + compatible = "usb-nop-xceiv"; > + #phy-cells = <0>; > + }; > }; > > &clkc { > @@ -118,3 +122,9 @@ > &uart1 { > status = "okay"; > }; > + > +&usb0 { > + status = "okay"; > + dr_mode = "host"; > + usb-phy = <&usb_phy0>; > +}; > diff --git a/arch/arm/boot/dts/zynq-zed.dts b/arch/arm/boot/dts/zynq-zed.dts > index 1c7cc990b47a..e20956e5e720 100644 > --- a/arch/arm/boot/dts/zynq-zed.dts > +++ b/arch/arm/boot/dts/zynq-zed.dts > @@ -27,6 +27,10 @@ > bootargs = "console=ttyPS0,115200 earlyprintk"; > }; > > + usb_phy0: phy0 { > + compatible = "usb-nop-xceiv"; > + #phy-cells = <0>; > + }; > }; > > &clkc { > @@ -50,3 +54,9 @@ > &uart1 { > status = "okay"; > }; > + > +&usb0 { > + status = "okay"; > + dr_mode = "host"; > + usb-phy = <&usb_phy0>; > +}; > Applied to zynq/dt. Thanks, Michal ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v3] ARM: zynq: DT: Add USB to device tree @ 2014-12-03 8:39 ` Michal Simek 0 siblings, 0 replies; 34+ messages in thread From: Michal Simek @ 2014-12-03 8:39 UTC (permalink / raw) To: linux-arm-kernel On 12/02/2014 05:07 PM, Soren Brinkmann wrote: > Add USB nodes to zc702, zc706 and zed device trees. > > Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com> > --- > v3: > - rename phy nodes: usb_phy -> phy0 > - rebased onto zynq/dt > v2: > - remove '@0' from phy node name > - don't add bogus space > --- > arch/arm/boot/dts/zynq-7000.dtsi | 20 ++++++++++++++++++++ > arch/arm/boot/dts/zynq-zc702.dts | 11 +++++++++++ > arch/arm/boot/dts/zynq-zc706.dts | 10 ++++++++++ > arch/arm/boot/dts/zynq-zed.dts | 10 ++++++++++ > 4 files changed, 51 insertions(+) > > diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi > index f8e4a28adfc0..21aae01a3fe9 100644 > --- a/arch/arm/boot/dts/zynq-7000.dtsi > +++ b/arch/arm/boot/dts/zynq-7000.dtsi > @@ -314,5 +314,25 @@ > reg = <0xf8f00600 0x20>; > clocks = <&clkc 4>; > }; > + > + usb0: usb at e0002000 { > + compatible = "xlnx,zynq-usb-2.20a", "chipidea,usb2"; > + status = "disabled"; > + clocks = <&clkc 28>; > + interrupt-parent = <&intc>; > + interrupts = <0 21 4>; > + reg = <0xe0002000 0x1000>; > + phy_type = "ulpi"; > + }; > + > + usb1: usb at e0003000 { > + compatible = "xlnx,zynq-usb-2.20a", "chipidea,usb2"; > + status = "disabled"; > + clocks = <&clkc 29>; > + interrupt-parent = <&intc>; > + interrupts = <0 44 4>; > + reg = <0xe0003000 0x1000>; > + phy_type = "ulpi"; > + }; > }; > }; > diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts > index 280f02dd4ddc..399fed4d9c19 100644 > --- a/arch/arm/boot/dts/zynq-zc702.dts > +++ b/arch/arm/boot/dts/zynq-zc702.dts > @@ -36,6 +36,11 @@ > linux,default-trigger = "heartbeat"; > }; > }; > + > + usb_phy0: phy0 { > + compatible = "usb-nop-xceiv"; > + #phy-cells = <0>; > + }; > }; > > &can0 { > @@ -139,3 +144,9 @@ > &uart1 { > status = "okay"; > }; > + > +&usb0 { > + status = "okay"; > + dr_mode = "host"; > + usb-phy = <&usb_phy0>; > +}; > diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts > index 34f7812d2ee8..89cc9adc569d 100644 > --- a/arch/arm/boot/dts/zynq-zc706.dts > +++ b/arch/arm/boot/dts/zynq-zc706.dts > @@ -27,6 +27,10 @@ > bootargs = "console=ttyPS0,115200 earlyprintk"; > }; > > + usb_phy0: phy0 { > + compatible = "usb-nop-xceiv"; > + #phy-cells = <0>; > + }; > }; > > &clkc { > @@ -118,3 +122,9 @@ > &uart1 { > status = "okay"; > }; > + > +&usb0 { > + status = "okay"; > + dr_mode = "host"; > + usb-phy = <&usb_phy0>; > +}; > diff --git a/arch/arm/boot/dts/zynq-zed.dts b/arch/arm/boot/dts/zynq-zed.dts > index 1c7cc990b47a..e20956e5e720 100644 > --- a/arch/arm/boot/dts/zynq-zed.dts > +++ b/arch/arm/boot/dts/zynq-zed.dts > @@ -27,6 +27,10 @@ > bootargs = "console=ttyPS0,115200 earlyprintk"; > }; > > + usb_phy0: phy0 { > + compatible = "usb-nop-xceiv"; > + #phy-cells = <0>; > + }; > }; > > &clkc { > @@ -50,3 +54,9 @@ > &uart1 { > status = "okay"; > }; > + > +&usb0 { > + status = "okay"; > + dr_mode = "host"; > + usb-phy = <&usb_phy0>; > +}; > Applied to zynq/dt. Thanks, Michal ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3] ARM: zynq: DT: Add USB to device tree @ 2015-01-26 8:19 ` Andreas Färber 0 siblings, 0 replies; 34+ messages in thread From: Andreas Färber @ 2015-01-26 8:19 UTC (permalink / raw) To: Michal Simek, Soren Brinkmann Cc: devicetree, Peter Crosthwaite, Arnd Bergmann, linux-kernel, linux-arm-kernel, Ola Jeppson Hi Michal, Am 03.12.2014 um 09:39 schrieb Michal Simek: > On 12/02/2014 05:07 PM, Soren Brinkmann wrote: >> Add USB nodes to zc702, zc706 and zed device trees. >> >> Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com> >> --- >> v3: >> - rename phy nodes: usb_phy -> phy0 >> - rebased onto zynq/dt >> v2: >> - remove '@0' from phy node name >> - don't add bogus space >> --- >> arch/arm/boot/dts/zynq-7000.dtsi | 20 ++++++++++++++++++++ >> arch/arm/boot/dts/zynq-zc702.dts | 11 +++++++++++ >> arch/arm/boot/dts/zynq-zc706.dts | 10 ++++++++++ >> arch/arm/boot/dts/zynq-zed.dts | 10 ++++++++++ >> 4 files changed, 51 insertions(+) [...] > > Applied to zynq/dt. Hm, I don't see this patch in linux-next next-20150123... And if I apply it to my -next based tree, adding corresponding nodes to zynq-parallella.dts, I get repeatedly: [ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT [ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: f090e100 op: f090e140 [ +0,000081] platform ci_hdrc.0: Driver ci_hdrc requests probe deferral [ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT [ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: f0910100 op: f0910140 [ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe deferral Am I missing any other patches or config options? (I do notice that the pinctrl v3 patch that got merged has a trivial bug for usb0, for which I'll send a patch later on.) Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg) ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v3] ARM: zynq: DT: Add USB to device tree @ 2015-01-26 8:19 ` Andreas Färber 0 siblings, 0 replies; 34+ messages in thread From: Andreas Färber @ 2015-01-26 8:19 UTC (permalink / raw) To: linux-arm-kernel Hi Michal, Am 03.12.2014 um 09:39 schrieb Michal Simek: > On 12/02/2014 05:07 PM, Soren Brinkmann wrote: >> Add USB nodes to zc702, zc706 and zed device trees. >> >> Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com> >> --- >> v3: >> - rename phy nodes: usb_phy -> phy0 >> - rebased onto zynq/dt >> v2: >> - remove '@0' from phy node name >> - don't add bogus space >> --- >> arch/arm/boot/dts/zynq-7000.dtsi | 20 ++++++++++++++++++++ >> arch/arm/boot/dts/zynq-zc702.dts | 11 +++++++++++ >> arch/arm/boot/dts/zynq-zc706.dts | 10 ++++++++++ >> arch/arm/boot/dts/zynq-zed.dts | 10 ++++++++++ >> 4 files changed, 51 insertions(+) [...] > > Applied to zynq/dt. Hm, I don't see this patch in linux-next next-20150123... And if I apply it to my -next based tree, adding corresponding nodes to zynq-parallella.dts, I get repeatedly: [ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT [ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: f090e100 op: f090e140 [ +0,000081] platform ci_hdrc.0: Driver ci_hdrc requests probe deferral [ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT [ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: f0910100 op: f0910140 [ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe deferral Am I missing any other patches or config options? (I do notice that the pinctrl v3 patch that got merged has a trivial bug for usb0, for which I'll send a patch later on.) Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany GF: Felix Imend?rffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG N?rnberg) ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3] ARM: zynq: DT: Add USB to device tree @ 2015-01-26 8:19 ` Andreas Färber 0 siblings, 0 replies; 34+ messages in thread From: Andreas Färber @ 2015-01-26 8:19 UTC (permalink / raw) To: Michal Simek, Soren Brinkmann Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Peter Crosthwaite, Arnd Bergmann, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Ola Jeppson Hi Michal, Am 03.12.2014 um 09:39 schrieb Michal Simek: > On 12/02/2014 05:07 PM, Soren Brinkmann wrote: >> Add USB nodes to zc702, zc706 and zed device trees. >> >> Signed-off-by: Soren Brinkmann <soren.brinkmann-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> >> --- >> v3: >> - rename phy nodes: usb_phy -> phy0 >> - rebased onto zynq/dt >> v2: >> - remove '@0' from phy node name >> - don't add bogus space >> --- >> arch/arm/boot/dts/zynq-7000.dtsi | 20 ++++++++++++++++++++ >> arch/arm/boot/dts/zynq-zc702.dts | 11 +++++++++++ >> arch/arm/boot/dts/zynq-zc706.dts | 10 ++++++++++ >> arch/arm/boot/dts/zynq-zed.dts | 10 ++++++++++ >> 4 files changed, 51 insertions(+) [...] > > Applied to zynq/dt. Hm, I don't see this patch in linux-next next-20150123... And if I apply it to my -next based tree, adding corresponding nodes to zynq-parallella.dts, I get repeatedly: [ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT [ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: f090e100 op: f090e140 [ +0,000081] platform ci_hdrc.0: Driver ci_hdrc requests probe deferral [ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT [ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: f0910100 op: f0910140 [ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe deferral Am I missing any other patches or config options? (I do notice that the pinctrl v3 patch that got merged has a trivial bug for usb0, for which I'll send a patch later on.) Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, 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] 34+ messages in thread
* Re: [PATCH v3] ARM: zynq: DT: Add USB to device tree 2015-01-26 8:19 ` Andreas Färber @ 2015-01-26 8:23 ` Michal Simek -1 siblings, 0 replies; 34+ messages in thread From: Michal Simek @ 2015-01-26 8:23 UTC (permalink / raw) To: Andreas Färber, Michal Simek, Soren Brinkmann Cc: devicetree, Peter Crosthwaite, Arnd Bergmann, linux-kernel, linux-arm-kernel, Ola Jeppson [-- Attachment #1: Type: text/plain, Size: 2020 bytes --] On 01/26/2015 09:19 AM, Andreas Färber wrote: > Hi Michal, > > Am 03.12.2014 um 09:39 schrieb Michal Simek: >> On 12/02/2014 05:07 PM, Soren Brinkmann wrote: >>> Add USB nodes to zc702, zc706 and zed device trees. >>> >>> Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com> >>> --- >>> v3: >>> - rename phy nodes: usb_phy -> phy0 >>> - rebased onto zynq/dt >>> v2: >>> - remove '@0' from phy node name >>> - don't add bogus space >>> --- >>> arch/arm/boot/dts/zynq-7000.dtsi | 20 ++++++++++++++++++++ >>> arch/arm/boot/dts/zynq-zc702.dts | 11 +++++++++++ >>> arch/arm/boot/dts/zynq-zc706.dts | 10 ++++++++++ >>> arch/arm/boot/dts/zynq-zed.dts | 10 ++++++++++ >>> 4 files changed, 51 insertions(+) > [...] >> >> Applied to zynq/dt. > > Hm, I don't see this patch in linux-next next-20150123... > > And if I apply it to my -next based tree, adding corresponding nodes to > zynq-parallella.dts, I get repeatedly: > > [ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT > [ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: > f090e100 op: f090e140 > [ +0,000081] platform ci_hdrc.0: Driver ci_hdrc requests probe deferral > [ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT > [ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: > f0910100 op: f0910140 > [ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe deferral > > Am I missing any other patches or config options? > (I do notice that the pinctrl v3 patch that got merged has a trivial bug > for usb0, for which I'll send a patch later on.) Why is it deferred? Is it because of pinmuxing stuff? Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v3] ARM: zynq: DT: Add USB to device tree @ 2015-01-26 8:23 ` Michal Simek 0 siblings, 0 replies; 34+ messages in thread From: Michal Simek @ 2015-01-26 8:23 UTC (permalink / raw) To: linux-arm-kernel On 01/26/2015 09:19 AM, Andreas F?rber wrote: > Hi Michal, > > Am 03.12.2014 um 09:39 schrieb Michal Simek: >> On 12/02/2014 05:07 PM, Soren Brinkmann wrote: >>> Add USB nodes to zc702, zc706 and zed device trees. >>> >>> Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com> >>> --- >>> v3: >>> - rename phy nodes: usb_phy -> phy0 >>> - rebased onto zynq/dt >>> v2: >>> - remove '@0' from phy node name >>> - don't add bogus space >>> --- >>> arch/arm/boot/dts/zynq-7000.dtsi | 20 ++++++++++++++++++++ >>> arch/arm/boot/dts/zynq-zc702.dts | 11 +++++++++++ >>> arch/arm/boot/dts/zynq-zc706.dts | 10 ++++++++++ >>> arch/arm/boot/dts/zynq-zed.dts | 10 ++++++++++ >>> 4 files changed, 51 insertions(+) > [...] >> >> Applied to zynq/dt. > > Hm, I don't see this patch in linux-next next-20150123... > > And if I apply it to my -next based tree, adding corresponding nodes to > zynq-parallella.dts, I get repeatedly: > > [ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT > [ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: > f090e100 op: f090e140 > [ +0,000081] platform ci_hdrc.0: Driver ci_hdrc requests probe deferral > [ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT > [ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: > f0910100 op: f0910140 > [ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe deferral > > Am I missing any other patches or config options? > (I do notice that the pinctrl v3 patch that got merged has a trivial bug > for usb0, for which I'll send a patch later on.) Why is it deferred? Is it because of pinmuxing stuff? Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150126/404bb118/attachment.sig> ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3] ARM: zynq: DT: Add USB to device tree @ 2015-01-26 8:33 ` Andreas Färber 0 siblings, 0 replies; 34+ messages in thread From: Andreas Färber @ 2015-01-26 8:33 UTC (permalink / raw) To: monstr, Michal Simek, Soren Brinkmann Cc: devicetree, Peter Crosthwaite, Arnd Bergmann, linux-kernel, linux-arm-kernel, Ola Jeppson [-- Attachment #1: Type: text/plain, Size: 3500 bytes --] Am 26.01.2015 um 09:23 schrieb Michal Simek: > On 01/26/2015 09:19 AM, Andreas Färber wrote: >> Am 03.12.2014 um 09:39 schrieb Michal Simek: >>> On 12/02/2014 05:07 PM, Soren Brinkmann wrote: >>>> Add USB nodes to zc702, zc706 and zed device trees. >>>> >>>> Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com> >>>> --- >>>> v3: >>>> - rename phy nodes: usb_phy -> phy0 >>>> - rebased onto zynq/dt >>>> v2: >>>> - remove '@0' from phy node name >>>> - don't add bogus space >>>> --- >>>> arch/arm/boot/dts/zynq-7000.dtsi | 20 ++++++++++++++++++++ >>>> arch/arm/boot/dts/zynq-zc702.dts | 11 +++++++++++ >>>> arch/arm/boot/dts/zynq-zc706.dts | 10 ++++++++++ >>>> arch/arm/boot/dts/zynq-zed.dts | 10 ++++++++++ >>>> 4 files changed, 51 insertions(+) >> [...] >>> >>> Applied to zynq/dt. >> >> Hm, I don't see this patch in linux-next next-20150123... >> >> And if I apply it to my -next based tree, adding corresponding nodes to >> zynq-parallella.dts, I get repeatedly: >> >> [ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT >> [ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: >> f090e100 op: f090e140 >> [ +0,000081] platform ci_hdrc.0: Driver ci_hdrc requests probe deferral >> [ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT >> [ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: >> f0910100 op: f0910140 >> [ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe deferral >> >> Am I missing any other patches or config options? >> (I do notice that the pinctrl v3 patch that got merged has a trivial bug >> for usb0, for which I'll send a patch later on.) > > Why is it deferred? Is it because of pinmuxing stuff? No, happened without as well. Looking at a different place in dmesg, I spot this: [ +0,003988] usb_phy_generic phy0: GPIO lookup for consumer reset-gpios [ +0,000012] usb_phy_generic phy0: using device tree for GPIO lookup [ +0,000015] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' property of node '/phy0[0]' [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' property of node '/phy0[0]' [ +0,000010] usb_phy_generic phy0: using lookup tables for GPIO lookup [ +0,000153] usb_phy_generic phy0: lookup for GPIO reset-gpios failed [ +0,000012] usb_phy_generic phy0: Error requesting RESET GPIO [ +0,004360] usb_phy_generic: probe of phy0 failed with error -2 [ +0,004991] usb_phy_generic phy1: GPIO lookup for consumer reset-gpios [ +0,000012] usb_phy_generic phy1: using device tree for GPIO lookup [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' property of node '/phy1[0]' [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' property of node '/phy1[0]' [ +0,000010] usb_phy_generic phy1: using lookup tables for GPIO lookup [ +0,000012] usb_phy_generic phy1: lookup for GPIO reset-gpios failed [ +0,000011] usb_phy_generic phy1: Error requesting RESET GPIO [ +0,004337] usb_phy_generic: probe of phy1 failed with error -2 So, I guess the chipidea driver is deferring because the phys want a property that neither me nor you are specifying? Would that be the two MDIO pins 52 and 53 that would need to be specified? Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg) [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v3] ARM: zynq: DT: Add USB to device tree @ 2015-01-26 8:33 ` Andreas Färber 0 siblings, 0 replies; 34+ messages in thread From: Andreas Färber @ 2015-01-26 8:33 UTC (permalink / raw) To: linux-arm-kernel Am 26.01.2015 um 09:23 schrieb Michal Simek: > On 01/26/2015 09:19 AM, Andreas F?rber wrote: >> Am 03.12.2014 um 09:39 schrieb Michal Simek: >>> On 12/02/2014 05:07 PM, Soren Brinkmann wrote: >>>> Add USB nodes to zc702, zc706 and zed device trees. >>>> >>>> Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com> >>>> --- >>>> v3: >>>> - rename phy nodes: usb_phy -> phy0 >>>> - rebased onto zynq/dt >>>> v2: >>>> - remove '@0' from phy node name >>>> - don't add bogus space >>>> --- >>>> arch/arm/boot/dts/zynq-7000.dtsi | 20 ++++++++++++++++++++ >>>> arch/arm/boot/dts/zynq-zc702.dts | 11 +++++++++++ >>>> arch/arm/boot/dts/zynq-zc706.dts | 10 ++++++++++ >>>> arch/arm/boot/dts/zynq-zed.dts | 10 ++++++++++ >>>> 4 files changed, 51 insertions(+) >> [...] >>> >>> Applied to zynq/dt. >> >> Hm, I don't see this patch in linux-next next-20150123... >> >> And if I apply it to my -next based tree, adding corresponding nodes to >> zynq-parallella.dts, I get repeatedly: >> >> [ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT >> [ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: >> f090e100 op: f090e140 >> [ +0,000081] platform ci_hdrc.0: Driver ci_hdrc requests probe deferral >> [ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT >> [ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: >> f0910100 op: f0910140 >> [ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe deferral >> >> Am I missing any other patches or config options? >> (I do notice that the pinctrl v3 patch that got merged has a trivial bug >> for usb0, for which I'll send a patch later on.) > > Why is it deferred? Is it because of pinmuxing stuff? No, happened without as well. Looking at a different place in dmesg, I spot this: [ +0,003988] usb_phy_generic phy0: GPIO lookup for consumer reset-gpios [ +0,000012] usb_phy_generic phy0: using device tree for GPIO lookup [ +0,000015] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' property of node '/phy0[0]' [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' property of node '/phy0[0]' [ +0,000010] usb_phy_generic phy0: using lookup tables for GPIO lookup [ +0,000153] usb_phy_generic phy0: lookup for GPIO reset-gpios failed [ +0,000012] usb_phy_generic phy0: Error requesting RESET GPIO [ +0,004360] usb_phy_generic: probe of phy0 failed with error -2 [ +0,004991] usb_phy_generic phy1: GPIO lookup for consumer reset-gpios [ +0,000012] usb_phy_generic phy1: using device tree for GPIO lookup [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' property of node '/phy1[0]' [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' property of node '/phy1[0]' [ +0,000010] usb_phy_generic phy1: using lookup tables for GPIO lookup [ +0,000012] usb_phy_generic phy1: lookup for GPIO reset-gpios failed [ +0,000011] usb_phy_generic phy1: Error requesting RESET GPIO [ +0,004337] usb_phy_generic: probe of phy1 failed with error -2 So, I guess the chipidea driver is deferring because the phys want a property that neither me nor you are specifying? Would that be the two MDIO pins 52 and 53 that would need to be specified? Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany GF: Felix Imend?rffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG N?rnberg) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150126/b985530f/attachment.sig> ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3] ARM: zynq: DT: Add USB to device tree @ 2015-01-26 8:33 ` Andreas Färber 0 siblings, 0 replies; 34+ messages in thread From: Andreas Färber @ 2015-01-26 8:33 UTC (permalink / raw) To: monstr-pSz03upnqPeHXe+LvDLADg, Michal Simek, Soren Brinkmann Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Peter Crosthwaite, Arnd Bergmann, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Ola Jeppson [-- Attachment #1: Type: text/plain, Size: 3529 bytes --] Am 26.01.2015 um 09:23 schrieb Michal Simek: > On 01/26/2015 09:19 AM, Andreas Färber wrote: >> Am 03.12.2014 um 09:39 schrieb Michal Simek: >>> On 12/02/2014 05:07 PM, Soren Brinkmann wrote: >>>> Add USB nodes to zc702, zc706 and zed device trees. >>>> >>>> Signed-off-by: Soren Brinkmann <soren.brinkmann-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> >>>> --- >>>> v3: >>>> - rename phy nodes: usb_phy -> phy0 >>>> - rebased onto zynq/dt >>>> v2: >>>> - remove '@0' from phy node name >>>> - don't add bogus space >>>> --- >>>> arch/arm/boot/dts/zynq-7000.dtsi | 20 ++++++++++++++++++++ >>>> arch/arm/boot/dts/zynq-zc702.dts | 11 +++++++++++ >>>> arch/arm/boot/dts/zynq-zc706.dts | 10 ++++++++++ >>>> arch/arm/boot/dts/zynq-zed.dts | 10 ++++++++++ >>>> 4 files changed, 51 insertions(+) >> [...] >>> >>> Applied to zynq/dt. >> >> Hm, I don't see this patch in linux-next next-20150123... >> >> And if I apply it to my -next based tree, adding corresponding nodes to >> zynq-parallella.dts, I get repeatedly: >> >> [ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT >> [ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: >> f090e100 op: f090e140 >> [ +0,000081] platform ci_hdrc.0: Driver ci_hdrc requests probe deferral >> [ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT >> [ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: >> f0910100 op: f0910140 >> [ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe deferral >> >> Am I missing any other patches or config options? >> (I do notice that the pinctrl v3 patch that got merged has a trivial bug >> for usb0, for which I'll send a patch later on.) > > Why is it deferred? Is it because of pinmuxing stuff? No, happened without as well. Looking at a different place in dmesg, I spot this: [ +0,003988] usb_phy_generic phy0: GPIO lookup for consumer reset-gpios [ +0,000012] usb_phy_generic phy0: using device tree for GPIO lookup [ +0,000015] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' property of node '/phy0[0]' [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' property of node '/phy0[0]' [ +0,000010] usb_phy_generic phy0: using lookup tables for GPIO lookup [ +0,000153] usb_phy_generic phy0: lookup for GPIO reset-gpios failed [ +0,000012] usb_phy_generic phy0: Error requesting RESET GPIO [ +0,004360] usb_phy_generic: probe of phy0 failed with error -2 [ +0,004991] usb_phy_generic phy1: GPIO lookup for consumer reset-gpios [ +0,000012] usb_phy_generic phy1: using device tree for GPIO lookup [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' property of node '/phy1[0]' [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' property of node '/phy1[0]' [ +0,000010] usb_phy_generic phy1: using lookup tables for GPIO lookup [ +0,000012] usb_phy_generic phy1: lookup for GPIO reset-gpios failed [ +0,000011] usb_phy_generic phy1: Error requesting RESET GPIO [ +0,004337] usb_phy_generic: probe of phy1 failed with error -2 So, I guess the chipidea driver is deferring because the phys want a property that neither me nor you are specifying? Would that be the two MDIO pins 52 and 53 that would need to be specified? Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg) [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3] ARM: zynq: DT: Add USB to device tree @ 2015-01-26 9:35 ` Andreas Färber 0 siblings, 0 replies; 34+ messages in thread From: Andreas Färber @ 2015-01-26 9:35 UTC (permalink / raw) To: monstr, Michal Simek, Soren Brinkmann Cc: devicetree, Peter Crosthwaite, Arnd Bergmann, linux-kernel, linux-arm-kernel, Ola Jeppson [-- Attachment #1: Type: text/plain, Size: 3432 bytes --] Am 26.01.2015 um 09:33 schrieb Andreas Färber: > Am 26.01.2015 um 09:23 schrieb Michal Simek: >> On 01/26/2015 09:19 AM, Andreas Färber wrote: >>> And if I apply it to my -next based tree, adding corresponding nodes to >>> zynq-parallella.dts, I get repeatedly: >>> >>> [ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT >>> [ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: >>> f090e100 op: f090e140 >>> [ +0,000081] platform ci_hdrc.0: Driver ci_hdrc requests probe deferral >>> [ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT >>> [ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: >>> f0910100 op: f0910140 >>> [ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe deferral >>> >>> Am I missing any other patches or config options? >>> (I do notice that the pinctrl v3 patch that got merged has a trivial bug >>> for usb0, for which I'll send a patch later on.) >> >> Why is it deferred? Is it because of pinmuxing stuff? > > No, happened without as well. > > Looking at a different place in dmesg, I spot this: > > [ +0,003988] usb_phy_generic phy0: GPIO lookup for consumer reset-gpios > [ +0,000012] usb_phy_generic phy0: using device tree for GPIO lookup > [ +0,000015] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' > property > of node '/phy0[0]' > [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' > property > of node '/phy0[0]' > [ +0,000010] usb_phy_generic phy0: using lookup tables for GPIO lookup > [ +0,000153] usb_phy_generic phy0: lookup for GPIO reset-gpios failed > [ +0,000012] usb_phy_generic phy0: Error requesting RESET GPIO > [ +0,004360] usb_phy_generic: probe of phy0 failed with error -2 > [ +0,004991] usb_phy_generic phy1: GPIO lookup for consumer reset-gpios > [ +0,000012] usb_phy_generic phy1: using device tree for GPIO lookup > [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' > property > of node '/phy1[0]' > [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' > property of node '/phy1[0]' > [ +0,000010] usb_phy_generic phy1: using lookup tables for GPIO lookup > [ +0,000012] usb_phy_generic phy1: lookup for GPIO reset-gpios failed > [ +0,000011] usb_phy_generic phy1: Error requesting RESET GPIO > [ +0,004337] usb_phy_generic: probe of phy1 failed with error -2 > > So, I guess the chipidea driver is deferring because the phys want a > property that neither me nor you are specifying? Would that be the two > MDIO pins 52 and 53 that would need to be specified? Erm, scratch that last question - wrong PHY. Trying it resolved the above phy errors but not the original problem. And so does an empty one: @@ -99,11 +100,13 @@ usb_phy0: phy0 { compatible = "usb-nop-xceiv"; + reset-gpios = <>; #phy-cells = <0>; }; usb_phy1: phy1 { compatible = "usb-nop-xceiv"; + reset-gpios = <>; #phy-cells = <0>; }; }; In my manuals and notes I can't find any GPIO being used as reset for the USB PHYs. Any thoughts appreciated. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg) [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v3] ARM: zynq: DT: Add USB to device tree @ 2015-01-26 9:35 ` Andreas Färber 0 siblings, 0 replies; 34+ messages in thread From: Andreas Färber @ 2015-01-26 9:35 UTC (permalink / raw) To: linux-arm-kernel Am 26.01.2015 um 09:33 schrieb Andreas F?rber: > Am 26.01.2015 um 09:23 schrieb Michal Simek: >> On 01/26/2015 09:19 AM, Andreas F?rber wrote: >>> And if I apply it to my -next based tree, adding corresponding nodes to >>> zynq-parallella.dts, I get repeatedly: >>> >>> [ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT >>> [ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: >>> f090e100 op: f090e140 >>> [ +0,000081] platform ci_hdrc.0: Driver ci_hdrc requests probe deferral >>> [ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT >>> [ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: >>> f0910100 op: f0910140 >>> [ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe deferral >>> >>> Am I missing any other patches or config options? >>> (I do notice that the pinctrl v3 patch that got merged has a trivial bug >>> for usb0, for which I'll send a patch later on.) >> >> Why is it deferred? Is it because of pinmuxing stuff? > > No, happened without as well. > > Looking at a different place in dmesg, I spot this: > > [ +0,003988] usb_phy_generic phy0: GPIO lookup for consumer reset-gpios > [ +0,000012] usb_phy_generic phy0: using device tree for GPIO lookup > [ +0,000015] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' > property > of node '/phy0[0]' > [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' > property > of node '/phy0[0]' > [ +0,000010] usb_phy_generic phy0: using lookup tables for GPIO lookup > [ +0,000153] usb_phy_generic phy0: lookup for GPIO reset-gpios failed > [ +0,000012] usb_phy_generic phy0: Error requesting RESET GPIO > [ +0,004360] usb_phy_generic: probe of phy0 failed with error -2 > [ +0,004991] usb_phy_generic phy1: GPIO lookup for consumer reset-gpios > [ +0,000012] usb_phy_generic phy1: using device tree for GPIO lookup > [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' > property > of node '/phy1[0]' > [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' > property of node '/phy1[0]' > [ +0,000010] usb_phy_generic phy1: using lookup tables for GPIO lookup > [ +0,000012] usb_phy_generic phy1: lookup for GPIO reset-gpios failed > [ +0,000011] usb_phy_generic phy1: Error requesting RESET GPIO > [ +0,004337] usb_phy_generic: probe of phy1 failed with error -2 > > So, I guess the chipidea driver is deferring because the phys want a > property that neither me nor you are specifying? Would that be the two > MDIO pins 52 and 53 that would need to be specified? Erm, scratch that last question - wrong PHY. Trying it resolved the above phy errors but not the original problem. And so does an empty one: @@ -99,11 +100,13 @@ usb_phy0: phy0 { compatible = "usb-nop-xceiv"; + reset-gpios = <>; #phy-cells = <0>; }; usb_phy1: phy1 { compatible = "usb-nop-xceiv"; + reset-gpios = <>; #phy-cells = <0>; }; }; In my manuals and notes I can't find any GPIO being used as reset for the USB PHYs. Any thoughts appreciated. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany GF: Felix Imend?rffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG N?rnberg) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150126/fb9bb454/attachment.sig> ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3] ARM: zynq: DT: Add USB to device tree @ 2015-01-26 9:35 ` Andreas Färber 0 siblings, 0 replies; 34+ messages in thread From: Andreas Färber @ 2015-01-26 9:35 UTC (permalink / raw) To: monstr-pSz03upnqPeHXe+LvDLADg, Michal Simek, Soren Brinkmann Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Peter Crosthwaite, Arnd Bergmann, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Ola Jeppson [-- Attachment #1: Type: text/plain, Size: 3432 bytes --] Am 26.01.2015 um 09:33 schrieb Andreas Färber: > Am 26.01.2015 um 09:23 schrieb Michal Simek: >> On 01/26/2015 09:19 AM, Andreas Färber wrote: >>> And if I apply it to my -next based tree, adding corresponding nodes to >>> zynq-parallella.dts, I get repeatedly: >>> >>> [ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT >>> [ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: >>> f090e100 op: f090e140 >>> [ +0,000081] platform ci_hdrc.0: Driver ci_hdrc requests probe deferral >>> [ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT >>> [ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: >>> f0910100 op: f0910140 >>> [ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe deferral >>> >>> Am I missing any other patches or config options? >>> (I do notice that the pinctrl v3 patch that got merged has a trivial bug >>> for usb0, for which I'll send a patch later on.) >> >> Why is it deferred? Is it because of pinmuxing stuff? > > No, happened without as well. > > Looking at a different place in dmesg, I spot this: > > [ +0,003988] usb_phy_generic phy0: GPIO lookup for consumer reset-gpios > [ +0,000012] usb_phy_generic phy0: using device tree for GPIO lookup > [ +0,000015] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' > property > of node '/phy0[0]' > [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' > property > of node '/phy0[0]' > [ +0,000010] usb_phy_generic phy0: using lookup tables for GPIO lookup > [ +0,000153] usb_phy_generic phy0: lookup for GPIO reset-gpios failed > [ +0,000012] usb_phy_generic phy0: Error requesting RESET GPIO > [ +0,004360] usb_phy_generic: probe of phy0 failed with error -2 > [ +0,004991] usb_phy_generic phy1: GPIO lookup for consumer reset-gpios > [ +0,000012] usb_phy_generic phy1: using device tree for GPIO lookup > [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' > property > of node '/phy1[0]' > [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' > property of node '/phy1[0]' > [ +0,000010] usb_phy_generic phy1: using lookup tables for GPIO lookup > [ +0,000012] usb_phy_generic phy1: lookup for GPIO reset-gpios failed > [ +0,000011] usb_phy_generic phy1: Error requesting RESET GPIO > [ +0,004337] usb_phy_generic: probe of phy1 failed with error -2 > > So, I guess the chipidea driver is deferring because the phys want a > property that neither me nor you are specifying? Would that be the two > MDIO pins 52 and 53 that would need to be specified? Erm, scratch that last question - wrong PHY. Trying it resolved the above phy errors but not the original problem. And so does an empty one: @@ -99,11 +100,13 @@ usb_phy0: phy0 { compatible = "usb-nop-xceiv"; + reset-gpios = <>; #phy-cells = <0>; }; usb_phy1: phy1 { compatible = "usb-nop-xceiv"; + reset-gpios = <>; #phy-cells = <0>; }; }; In my manuals and notes I can't find any GPIO being used as reset for the USB PHYs. Any thoughts appreciated. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg) [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3] ARM: zynq: DT: Add USB to device tree @ 2015-01-26 15:50 ` Sören Brinkmann 0 siblings, 0 replies; 34+ messages in thread From: Sören Brinkmann @ 2015-01-26 15:50 UTC (permalink / raw) To: Andreas Färber Cc: monstr, Michal Simek, devicetree, Peter Crosthwaite, Arnd Bergmann, linux-kernel, linux-arm-kernel, Ola Jeppson On Mon, 2015-01-26 at 10:35AM +0100, Andreas Färber wrote: > Am 26.01.2015 um 09:33 schrieb Andreas Färber: > > Am 26.01.2015 um 09:23 schrieb Michal Simek: > >> On 01/26/2015 09:19 AM, Andreas Färber wrote: > >>> And if I apply it to my -next based tree, adding corresponding nodes to > >>> zynq-parallella.dts, I get repeatedly: > >>> > >>> [ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT > >>> [ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: > >>> f090e100 op: f090e140 > >>> [ +0,000081] platform ci_hdrc.0: Driver ci_hdrc requests probe deferral > >>> [ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT > >>> [ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: > >>> f0910100 op: f0910140 > >>> [ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe deferral > >>> > >>> Am I missing any other patches or config options? > >>> (I do notice that the pinctrl v3 patch that got merged has a trivial bug > >>> for usb0, for which I'll send a patch later on.) > >> > >> Why is it deferred? Is it because of pinmuxing stuff? > > > > No, happened without as well. > > > > Looking at a different place in dmesg, I spot this: > > > > [ +0,003988] usb_phy_generic phy0: GPIO lookup for consumer reset-gpios > > [ +0,000012] usb_phy_generic phy0: using device tree for GPIO lookup > > [ +0,000015] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' > > property > > of node '/phy0[0]' > > [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' > > property > > of node '/phy0[0]' > > [ +0,000010] usb_phy_generic phy0: using lookup tables for GPIO lookup > > [ +0,000153] usb_phy_generic phy0: lookup for GPIO reset-gpios failed > > [ +0,000012] usb_phy_generic phy0: Error requesting RESET GPIO > > [ +0,004360] usb_phy_generic: probe of phy0 failed with error -2 > > [ +0,004991] usb_phy_generic phy1: GPIO lookup for consumer reset-gpios > > [ +0,000012] usb_phy_generic phy1: using device tree for GPIO lookup > > [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' > > property > > of node '/phy1[0]' > > [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' > > property of node '/phy1[0]' > > [ +0,000010] usb_phy_generic phy1: using lookup tables for GPIO lookup > > [ +0,000012] usb_phy_generic phy1: lookup for GPIO reset-gpios failed > > [ +0,000011] usb_phy_generic phy1: Error requesting RESET GPIO > > [ +0,004337] usb_phy_generic: probe of phy1 failed with error -2 > > > > So, I guess the chipidea driver is deferring because the phys want a > > property that neither me nor you are specifying? Would that be the two > > MDIO pins 52 and 53 that would need to be specified? > > Erm, scratch that last question - wrong PHY. Trying it resolved the > above phy errors but not the original problem. And so does an empty one: > > @@ -99,11 +100,13 @@ > > usb_phy0: phy0 { > compatible = "usb-nop-xceiv"; > + reset-gpios = <>; > #phy-cells = <0>; > }; > > usb_phy1: phy1 { > compatible = "usb-nop-xceiv"; > + reset-gpios = <>; > #phy-cells = <0>; > }; > }; > > In my manuals and notes I can't find any GPIO being used as reset for > the USB PHYs. Any thoughts appreciated. Such a connection is optional. The platform might rely on its reset circuit, though it might not work for warm reboots. I haven't looked at parallela docs, but if there is a schematic available, that should tell you if/what is connected to the PHY reset pin. Soren ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v3] ARM: zynq: DT: Add USB to device tree @ 2015-01-26 15:50 ` Sören Brinkmann 0 siblings, 0 replies; 34+ messages in thread From: Sören Brinkmann @ 2015-01-26 15:50 UTC (permalink / raw) To: linux-arm-kernel On Mon, 2015-01-26 at 10:35AM +0100, Andreas F?rber wrote: > Am 26.01.2015 um 09:33 schrieb Andreas F?rber: > > Am 26.01.2015 um 09:23 schrieb Michal Simek: > >> On 01/26/2015 09:19 AM, Andreas F?rber wrote: > >>> And if I apply it to my -next based tree, adding corresponding nodes to > >>> zynq-parallella.dts, I get repeatedly: > >>> > >>> [ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT > >>> [ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: > >>> f090e100 op: f090e140 > >>> [ +0,000081] platform ci_hdrc.0: Driver ci_hdrc requests probe deferral > >>> [ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT > >>> [ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: > >>> f0910100 op: f0910140 > >>> [ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe deferral > >>> > >>> Am I missing any other patches or config options? > >>> (I do notice that the pinctrl v3 patch that got merged has a trivial bug > >>> for usb0, for which I'll send a patch later on.) > >> > >> Why is it deferred? Is it because of pinmuxing stuff? > > > > No, happened without as well. > > > > Looking at a different place in dmesg, I spot this: > > > > [ +0,003988] usb_phy_generic phy0: GPIO lookup for consumer reset-gpios > > [ +0,000012] usb_phy_generic phy0: using device tree for GPIO lookup > > [ +0,000015] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' > > property > > of node '/phy0[0]' > > [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' > > property > > of node '/phy0[0]' > > [ +0,000010] usb_phy_generic phy0: using lookup tables for GPIO lookup > > [ +0,000153] usb_phy_generic phy0: lookup for GPIO reset-gpios failed > > [ +0,000012] usb_phy_generic phy0: Error requesting RESET GPIO > > [ +0,004360] usb_phy_generic: probe of phy0 failed with error -2 > > [ +0,004991] usb_phy_generic phy1: GPIO lookup for consumer reset-gpios > > [ +0,000012] usb_phy_generic phy1: using device tree for GPIO lookup > > [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' > > property > > of node '/phy1[0]' > > [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' > > property of node '/phy1[0]' > > [ +0,000010] usb_phy_generic phy1: using lookup tables for GPIO lookup > > [ +0,000012] usb_phy_generic phy1: lookup for GPIO reset-gpios failed > > [ +0,000011] usb_phy_generic phy1: Error requesting RESET GPIO > > [ +0,004337] usb_phy_generic: probe of phy1 failed with error -2 > > > > So, I guess the chipidea driver is deferring because the phys want a > > property that neither me nor you are specifying? Would that be the two > > MDIO pins 52 and 53 that would need to be specified? > > Erm, scratch that last question - wrong PHY. Trying it resolved the > above phy errors but not the original problem. And so does an empty one: > > @@ -99,11 +100,13 @@ > > usb_phy0: phy0 { > compatible = "usb-nop-xceiv"; > + reset-gpios = <>; > #phy-cells = <0>; > }; > > usb_phy1: phy1 { > compatible = "usb-nop-xceiv"; > + reset-gpios = <>; > #phy-cells = <0>; > }; > }; > > In my manuals and notes I can't find any GPIO being used as reset for > the USB PHYs. Any thoughts appreciated. Such a connection is optional. The platform might rely on its reset circuit, though it might not work for warm reboots. I haven't looked at parallela docs, but if there is a schematic available, that should tell you if/what is connected to the PHY reset pin. Soren ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3] ARM: zynq: DT: Add USB to device tree @ 2015-01-26 15:50 ` Sören Brinkmann 0 siblings, 0 replies; 34+ messages in thread From: Sören Brinkmann @ 2015-01-26 15:50 UTC (permalink / raw) To: Andreas Färber Cc: monstr-pSz03upnqPeHXe+LvDLADg, Michal Simek, devicetree-u79uwXL29TY76Z2rM5mHXA, Peter Crosthwaite, Arnd Bergmann, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Ola Jeppson On Mon, 2015-01-26 at 10:35AM +0100, Andreas Färber wrote: > Am 26.01.2015 um 09:33 schrieb Andreas Färber: > > Am 26.01.2015 um 09:23 schrieb Michal Simek: > >> On 01/26/2015 09:19 AM, Andreas Färber wrote: > >>> And if I apply it to my -next based tree, adding corresponding nodes to > >>> zynq-parallella.dts, I get repeatedly: > >>> > >>> [ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT > >>> [ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: > >>> f090e100 op: f090e140 > >>> [ +0,000081] platform ci_hdrc.0: Driver ci_hdrc requests probe deferral > >>> [ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT > >>> [ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: > >>> f0910100 op: f0910140 > >>> [ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe deferral > >>> > >>> Am I missing any other patches or config options? > >>> (I do notice that the pinctrl v3 patch that got merged has a trivial bug > >>> for usb0, for which I'll send a patch later on.) > >> > >> Why is it deferred? Is it because of pinmuxing stuff? > > > > No, happened without as well. > > > > Looking at a different place in dmesg, I spot this: > > > > [ +0,003988] usb_phy_generic phy0: GPIO lookup for consumer reset-gpios > > [ +0,000012] usb_phy_generic phy0: using device tree for GPIO lookup > > [ +0,000015] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' > > property > > of node '/phy0[0]' > > [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' > > property > > of node '/phy0[0]' > > [ +0,000010] usb_phy_generic phy0: using lookup tables for GPIO lookup > > [ +0,000153] usb_phy_generic phy0: lookup for GPIO reset-gpios failed > > [ +0,000012] usb_phy_generic phy0: Error requesting RESET GPIO > > [ +0,004360] usb_phy_generic: probe of phy0 failed with error -2 > > [ +0,004991] usb_phy_generic phy1: GPIO lookup for consumer reset-gpios > > [ +0,000012] usb_phy_generic phy1: using device tree for GPIO lookup > > [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' > > property > > of node '/phy1[0]' > > [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' > > property of node '/phy1[0]' > > [ +0,000010] usb_phy_generic phy1: using lookup tables for GPIO lookup > > [ +0,000012] usb_phy_generic phy1: lookup for GPIO reset-gpios failed > > [ +0,000011] usb_phy_generic phy1: Error requesting RESET GPIO > > [ +0,004337] usb_phy_generic: probe of phy1 failed with error -2 > > > > So, I guess the chipidea driver is deferring because the phys want a > > property that neither me nor you are specifying? Would that be the two > > MDIO pins 52 and 53 that would need to be specified? > > Erm, scratch that last question - wrong PHY. Trying it resolved the > above phy errors but not the original problem. And so does an empty one: > > @@ -99,11 +100,13 @@ > > usb_phy0: phy0 { > compatible = "usb-nop-xceiv"; > + reset-gpios = <>; > #phy-cells = <0>; > }; > > usb_phy1: phy1 { > compatible = "usb-nop-xceiv"; > + reset-gpios = <>; > #phy-cells = <0>; > }; > }; > > In my manuals and notes I can't find any GPIO being used as reset for > the USB PHYs. Any thoughts appreciated. Such a connection is optional. The platform might rely on its reset circuit, though it might not work for warm reboots. I haven't looked at parallela docs, but if there is a schematic available, that should tell you if/what is connected to the PHY reset pin. Soren -- 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] 34+ messages in thread
* Re: [PATCH v3] ARM: zynq: DT: Add USB to device tree @ 2015-01-26 16:21 ` Andreas Färber 0 siblings, 0 replies; 34+ messages in thread From: Andreas Färber @ 2015-01-26 16:21 UTC (permalink / raw) To: Sören Brinkmann Cc: monstr, Michal Simek, devicetree, Peter Crosthwaite, Arnd Bergmann, linux-kernel, linux-arm-kernel, Ola Jeppson [-- Attachment #1: Type: text/plain, Size: 4411 bytes --] Am 26.01.2015 um 16:50 schrieb Sören Brinkmann: > On Mon, 2015-01-26 at 10:35AM +0100, Andreas Färber wrote: >> Am 26.01.2015 um 09:33 schrieb Andreas Färber: >>> Am 26.01.2015 um 09:23 schrieb Michal Simek: >>>> On 01/26/2015 09:19 AM, Andreas Färber wrote: >>>>> And if I apply it to my -next based tree, adding corresponding nodes to >>>>> zynq-parallella.dts, I get repeatedly: >>>>> >>>>> [ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT >>>>> [ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: >>>>> f090e100 op: f090e140 >>>>> [ +0,000081] platform ci_hdrc.0: Driver ci_hdrc requests probe deferral >>>>> [ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT >>>>> [ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: >>>>> f0910100 op: f0910140 >>>>> [ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe deferral >>>>> >>>>> Am I missing any other patches or config options? >>>>> (I do notice that the pinctrl v3 patch that got merged has a trivial bug >>>>> for usb0, for which I'll send a patch later on.) >>>> >>>> Why is it deferred? Is it because of pinmuxing stuff? >>> >>> No, happened without as well. >>> >>> Looking at a different place in dmesg, I spot this: >>> >>> [ +0,003988] usb_phy_generic phy0: GPIO lookup for consumer reset-gpios >>> [ +0,000012] usb_phy_generic phy0: using device tree for GPIO lookup >>> [ +0,000015] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' >>> property >>> of node '/phy0[0]' >>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' >>> property >>> of node '/phy0[0]' >>> [ +0,000010] usb_phy_generic phy0: using lookup tables for GPIO lookup >>> [ +0,000153] usb_phy_generic phy0: lookup for GPIO reset-gpios failed >>> [ +0,000012] usb_phy_generic phy0: Error requesting RESET GPIO >>> [ +0,004360] usb_phy_generic: probe of phy0 failed with error -2 >>> [ +0,004991] usb_phy_generic phy1: GPIO lookup for consumer reset-gpios >>> [ +0,000012] usb_phy_generic phy1: using device tree for GPIO lookup >>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' >>> property >>> of node '/phy1[0]' >>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' >>> property of node '/phy1[0]' >>> [ +0,000010] usb_phy_generic phy1: using lookup tables for GPIO lookup >>> [ +0,000012] usb_phy_generic phy1: lookup for GPIO reset-gpios failed >>> [ +0,000011] usb_phy_generic phy1: Error requesting RESET GPIO >>> [ +0,004337] usb_phy_generic: probe of phy1 failed with error -2 >>> >>> So, I guess the chipidea driver is deferring because the phys want a >>> property that neither me nor you are specifying? Would that be the two >>> MDIO pins 52 and 53 that would need to be specified? >> >> Erm, scratch that last question - wrong PHY. Trying it resolved the >> above phy errors but not the original problem. And so does an empty one: >> >> @@ -99,11 +100,13 @@ >> >> usb_phy0: phy0 { >> compatible = "usb-nop-xceiv"; >> + reset-gpios = <>; >> #phy-cells = <0>; >> }; >> >> usb_phy1: phy1 { >> compatible = "usb-nop-xceiv"; >> + reset-gpios = <>; >> #phy-cells = <0>; >> }; >> }; >> >> In my manuals and notes I can't find any GPIO being used as reset for >> the USB PHYs. Any thoughts appreciated. > > Such a connection is optional. The platform might rely on its reset > circuit, though it might not work for warm reboots. > I haven't looked at parallela docs, but if there is a schematic > available, that should tell you if/what is connected to the PHY reset > pin. I do have the schematic, and the way I read it, only the on-board reset button resets the PHYs. Yet it looks as if usb-nop-xceiv insists on a reset-gpios above, no? Does it work on your boards with linux-next? And regarding my previous reporting, I was mistaken: I had to increase the log buffer size due to enabled pinctrl debugging, which made the phy errors sometimes appear, depending on timing. They're still there. Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg) [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v3] ARM: zynq: DT: Add USB to device tree @ 2015-01-26 16:21 ` Andreas Färber 0 siblings, 0 replies; 34+ messages in thread From: Andreas Färber @ 2015-01-26 16:21 UTC (permalink / raw) To: linux-arm-kernel Am 26.01.2015 um 16:50 schrieb S?ren Brinkmann: > On Mon, 2015-01-26 at 10:35AM +0100, Andreas F?rber wrote: >> Am 26.01.2015 um 09:33 schrieb Andreas F?rber: >>> Am 26.01.2015 um 09:23 schrieb Michal Simek: >>>> On 01/26/2015 09:19 AM, Andreas F?rber wrote: >>>>> And if I apply it to my -next based tree, adding corresponding nodes to >>>>> zynq-parallella.dts, I get repeatedly: >>>>> >>>>> [ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT >>>>> [ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: >>>>> f090e100 op: f090e140 >>>>> [ +0,000081] platform ci_hdrc.0: Driver ci_hdrc requests probe deferral >>>>> [ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT >>>>> [ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: >>>>> f0910100 op: f0910140 >>>>> [ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe deferral >>>>> >>>>> Am I missing any other patches or config options? >>>>> (I do notice that the pinctrl v3 patch that got merged has a trivial bug >>>>> for usb0, for which I'll send a patch later on.) >>>> >>>> Why is it deferred? Is it because of pinmuxing stuff? >>> >>> No, happened without as well. >>> >>> Looking at a different place in dmesg, I spot this: >>> >>> [ +0,003988] usb_phy_generic phy0: GPIO lookup for consumer reset-gpios >>> [ +0,000012] usb_phy_generic phy0: using device tree for GPIO lookup >>> [ +0,000015] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' >>> property >>> of node '/phy0[0]' >>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' >>> property >>> of node '/phy0[0]' >>> [ +0,000010] usb_phy_generic phy0: using lookup tables for GPIO lookup >>> [ +0,000153] usb_phy_generic phy0: lookup for GPIO reset-gpios failed >>> [ +0,000012] usb_phy_generic phy0: Error requesting RESET GPIO >>> [ +0,004360] usb_phy_generic: probe of phy0 failed with error -2 >>> [ +0,004991] usb_phy_generic phy1: GPIO lookup for consumer reset-gpios >>> [ +0,000012] usb_phy_generic phy1: using device tree for GPIO lookup >>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' >>> property >>> of node '/phy1[0]' >>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' >>> property of node '/phy1[0]' >>> [ +0,000010] usb_phy_generic phy1: using lookup tables for GPIO lookup >>> [ +0,000012] usb_phy_generic phy1: lookup for GPIO reset-gpios failed >>> [ +0,000011] usb_phy_generic phy1: Error requesting RESET GPIO >>> [ +0,004337] usb_phy_generic: probe of phy1 failed with error -2 >>> >>> So, I guess the chipidea driver is deferring because the phys want a >>> property that neither me nor you are specifying? Would that be the two >>> MDIO pins 52 and 53 that would need to be specified? >> >> Erm, scratch that last question - wrong PHY. Trying it resolved the >> above phy errors but not the original problem. And so does an empty one: >> >> @@ -99,11 +100,13 @@ >> >> usb_phy0: phy0 { >> compatible = "usb-nop-xceiv"; >> + reset-gpios = <>; >> #phy-cells = <0>; >> }; >> >> usb_phy1: phy1 { >> compatible = "usb-nop-xceiv"; >> + reset-gpios = <>; >> #phy-cells = <0>; >> }; >> }; >> >> In my manuals and notes I can't find any GPIO being used as reset for >> the USB PHYs. Any thoughts appreciated. > > Such a connection is optional. The platform might rely on its reset > circuit, though it might not work for warm reboots. > I haven't looked at parallela docs, but if there is a schematic > available, that should tell you if/what is connected to the PHY reset > pin. I do have the schematic, and the way I read it, only the on-board reset button resets the PHYs. Yet it looks as if usb-nop-xceiv insists on a reset-gpios above, no? Does it work on your boards with linux-next? And regarding my previous reporting, I was mistaken: I had to increase the log buffer size due to enabled pinctrl debugging, which made the phy errors sometimes appear, depending on timing. They're still there. Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany GF: Felix Imend?rffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG N?rnberg) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150126/c8aeb779/attachment.sig> ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3] ARM: zynq: DT: Add USB to device tree @ 2015-01-26 16:21 ` Andreas Färber 0 siblings, 0 replies; 34+ messages in thread From: Andreas Färber @ 2015-01-26 16:21 UTC (permalink / raw) To: Sören Brinkmann Cc: monstr-pSz03upnqPeHXe+LvDLADg, Michal Simek, devicetree-u79uwXL29TY76Z2rM5mHXA, Peter Crosthwaite, Arnd Bergmann, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Ola Jeppson [-- Attachment #1: Type: text/plain, Size: 4411 bytes --] Am 26.01.2015 um 16:50 schrieb Sören Brinkmann: > On Mon, 2015-01-26 at 10:35AM +0100, Andreas Färber wrote: >> Am 26.01.2015 um 09:33 schrieb Andreas Färber: >>> Am 26.01.2015 um 09:23 schrieb Michal Simek: >>>> On 01/26/2015 09:19 AM, Andreas Färber wrote: >>>>> And if I apply it to my -next based tree, adding corresponding nodes to >>>>> zynq-parallella.dts, I get repeatedly: >>>>> >>>>> [ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT >>>>> [ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: >>>>> f090e100 op: f090e140 >>>>> [ +0,000081] platform ci_hdrc.0: Driver ci_hdrc requests probe deferral >>>>> [ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT >>>>> [ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: >>>>> f0910100 op: f0910140 >>>>> [ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe deferral >>>>> >>>>> Am I missing any other patches or config options? >>>>> (I do notice that the pinctrl v3 patch that got merged has a trivial bug >>>>> for usb0, for which I'll send a patch later on.) >>>> >>>> Why is it deferred? Is it because of pinmuxing stuff? >>> >>> No, happened without as well. >>> >>> Looking at a different place in dmesg, I spot this: >>> >>> [ +0,003988] usb_phy_generic phy0: GPIO lookup for consumer reset-gpios >>> [ +0,000012] usb_phy_generic phy0: using device tree for GPIO lookup >>> [ +0,000015] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' >>> property >>> of node '/phy0[0]' >>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' >>> property >>> of node '/phy0[0]' >>> [ +0,000010] usb_phy_generic phy0: using lookup tables for GPIO lookup >>> [ +0,000153] usb_phy_generic phy0: lookup for GPIO reset-gpios failed >>> [ +0,000012] usb_phy_generic phy0: Error requesting RESET GPIO >>> [ +0,004360] usb_phy_generic: probe of phy0 failed with error -2 >>> [ +0,004991] usb_phy_generic phy1: GPIO lookup for consumer reset-gpios >>> [ +0,000012] usb_phy_generic phy1: using device tree for GPIO lookup >>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' >>> property >>> of node '/phy1[0]' >>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' >>> property of node '/phy1[0]' >>> [ +0,000010] usb_phy_generic phy1: using lookup tables for GPIO lookup >>> [ +0,000012] usb_phy_generic phy1: lookup for GPIO reset-gpios failed >>> [ +0,000011] usb_phy_generic phy1: Error requesting RESET GPIO >>> [ +0,004337] usb_phy_generic: probe of phy1 failed with error -2 >>> >>> So, I guess the chipidea driver is deferring because the phys want a >>> property that neither me nor you are specifying? Would that be the two >>> MDIO pins 52 and 53 that would need to be specified? >> >> Erm, scratch that last question - wrong PHY. Trying it resolved the >> above phy errors but not the original problem. And so does an empty one: >> >> @@ -99,11 +100,13 @@ >> >> usb_phy0: phy0 { >> compatible = "usb-nop-xceiv"; >> + reset-gpios = <>; >> #phy-cells = <0>; >> }; >> >> usb_phy1: phy1 { >> compatible = "usb-nop-xceiv"; >> + reset-gpios = <>; >> #phy-cells = <0>; >> }; >> }; >> >> In my manuals and notes I can't find any GPIO being used as reset for >> the USB PHYs. Any thoughts appreciated. > > Such a connection is optional. The platform might rely on its reset > circuit, though it might not work for warm reboots. > I haven't looked at parallela docs, but if there is a schematic > available, that should tell you if/what is connected to the PHY reset > pin. I do have the schematic, and the way I read it, only the on-board reset button resets the PHYs. Yet it looks as if usb-nop-xceiv insists on a reset-gpios above, no? Does it work on your boards with linux-next? And regarding my previous reporting, I was mistaken: I had to increase the log buffer size due to enabled pinctrl debugging, which made the phy errors sometimes appear, depending on timing. They're still there. Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg) [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3] ARM: zynq: DT: Add USB to device tree 2015-01-26 16:21 ` Andreas Färber (?) @ 2015-01-26 16:23 ` Sören Brinkmann -1 siblings, 0 replies; 34+ messages in thread From: Sören Brinkmann @ 2015-01-26 16:23 UTC (permalink / raw) To: Andreas Färber Cc: monstr, Michal Simek, devicetree, Peter Crosthwaite, Arnd Bergmann, linux-kernel, linux-arm-kernel, Ola Jeppson On Mon, 2015-01-26 at 05:21PM +0100, Andreas Färber wrote: > Am 26.01.2015 um 16:50 schrieb Sören Brinkmann: > > On Mon, 2015-01-26 at 10:35AM +0100, Andreas Färber wrote: > >> Am 26.01.2015 um 09:33 schrieb Andreas Färber: > >>> Am 26.01.2015 um 09:23 schrieb Michal Simek: > >>>> On 01/26/2015 09:19 AM, Andreas Färber wrote: > >>>>> And if I apply it to my -next based tree, adding corresponding nodes to > >>>>> zynq-parallella.dts, I get repeatedly: > >>>>> > >>>>> [ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT > >>>>> [ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: > >>>>> f090e100 op: f090e140 > >>>>> [ +0,000081] platform ci_hdrc.0: Driver ci_hdrc requests probe deferral > >>>>> [ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT > >>>>> [ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: > >>>>> f0910100 op: f0910140 > >>>>> [ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe deferral > >>>>> > >>>>> Am I missing any other patches or config options? > >>>>> (I do notice that the pinctrl v3 patch that got merged has a trivial bug > >>>>> for usb0, for which I'll send a patch later on.) > >>>> > >>>> Why is it deferred? Is it because of pinmuxing stuff? > >>> > >>> No, happened without as well. > >>> > >>> Looking at a different place in dmesg, I spot this: > >>> > >>> [ +0,003988] usb_phy_generic phy0: GPIO lookup for consumer reset-gpios > >>> [ +0,000012] usb_phy_generic phy0: using device tree for GPIO lookup > >>> [ +0,000015] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' > >>> property > >>> of node '/phy0[0]' > >>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' > >>> property > >>> of node '/phy0[0]' > >>> [ +0,000010] usb_phy_generic phy0: using lookup tables for GPIO lookup > >>> [ +0,000153] usb_phy_generic phy0: lookup for GPIO reset-gpios failed > >>> [ +0,000012] usb_phy_generic phy0: Error requesting RESET GPIO > >>> [ +0,004360] usb_phy_generic: probe of phy0 failed with error -2 > >>> [ +0,004991] usb_phy_generic phy1: GPIO lookup for consumer reset-gpios > >>> [ +0,000012] usb_phy_generic phy1: using device tree for GPIO lookup > >>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' > >>> property > >>> of node '/phy1[0]' > >>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' > >>> property of node '/phy1[0]' > >>> [ +0,000010] usb_phy_generic phy1: using lookup tables for GPIO lookup > >>> [ +0,000012] usb_phy_generic phy1: lookup for GPIO reset-gpios failed > >>> [ +0,000011] usb_phy_generic phy1: Error requesting RESET GPIO > >>> [ +0,004337] usb_phy_generic: probe of phy1 failed with error -2 > >>> > >>> So, I guess the chipidea driver is deferring because the phys want a > >>> property that neither me nor you are specifying? Would that be the two > >>> MDIO pins 52 and 53 that would need to be specified? > >> > >> Erm, scratch that last question - wrong PHY. Trying it resolved the > >> above phy errors but not the original problem. And so does an empty one: > >> > >> @@ -99,11 +100,13 @@ > >> > >> usb_phy0: phy0 { > >> compatible = "usb-nop-xceiv"; > >> + reset-gpios = <>; > >> #phy-cells = <0>; > >> }; > >> > >> usb_phy1: phy1 { > >> compatible = "usb-nop-xceiv"; > >> + reset-gpios = <>; > >> #phy-cells = <0>; > >> }; > >> }; > >> > >> In my manuals and notes I can't find any GPIO being used as reset for > >> the USB PHYs. Any thoughts appreciated. > > > > Such a connection is optional. The platform might rely on its reset > > circuit, though it might not work for warm reboots. > > I haven't looked at parallela docs, but if there is a schematic > > available, that should tell you if/what is connected to the PHY reset > > pin. > > I do have the schematic, and the way I read it, only the on-board reset > button resets the PHYs. > > Yet it looks as if usb-nop-xceiv insists on a reset-gpios above, no? > Does it work on your boards with linux-next? I haven't re-tested it since I submitted the patches, but at that time it worked. But I also didn't test USB with the pinctrl patches together. I'll do some testing later today. Soren ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v3] ARM: zynq: DT: Add USB to device tree @ 2015-01-26 16:23 ` Sören Brinkmann 0 siblings, 0 replies; 34+ messages in thread From: Sören Brinkmann @ 2015-01-26 16:23 UTC (permalink / raw) To: linux-arm-kernel On Mon, 2015-01-26 at 05:21PM +0100, Andreas F?rber wrote: > Am 26.01.2015 um 16:50 schrieb S?ren Brinkmann: > > On Mon, 2015-01-26 at 10:35AM +0100, Andreas F?rber wrote: > >> Am 26.01.2015 um 09:33 schrieb Andreas F?rber: > >>> Am 26.01.2015 um 09:23 schrieb Michal Simek: > >>>> On 01/26/2015 09:19 AM, Andreas F?rber wrote: > >>>>> And if I apply it to my -next based tree, adding corresponding nodes to > >>>>> zynq-parallella.dts, I get repeatedly: > >>>>> > >>>>> [ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT > >>>>> [ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: > >>>>> f090e100 op: f090e140 > >>>>> [ +0,000081] platform ci_hdrc.0: Driver ci_hdrc requests probe deferral > >>>>> [ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT > >>>>> [ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: > >>>>> f0910100 op: f0910140 > >>>>> [ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe deferral > >>>>> > >>>>> Am I missing any other patches or config options? > >>>>> (I do notice that the pinctrl v3 patch that got merged has a trivial bug > >>>>> for usb0, for which I'll send a patch later on.) > >>>> > >>>> Why is it deferred? Is it because of pinmuxing stuff? > >>> > >>> No, happened without as well. > >>> > >>> Looking at a different place in dmesg, I spot this: > >>> > >>> [ +0,003988] usb_phy_generic phy0: GPIO lookup for consumer reset-gpios > >>> [ +0,000012] usb_phy_generic phy0: using device tree for GPIO lookup > >>> [ +0,000015] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' > >>> property > >>> of node '/phy0[0]' > >>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' > >>> property > >>> of node '/phy0[0]' > >>> [ +0,000010] usb_phy_generic phy0: using lookup tables for GPIO lookup > >>> [ +0,000153] usb_phy_generic phy0: lookup for GPIO reset-gpios failed > >>> [ +0,000012] usb_phy_generic phy0: Error requesting RESET GPIO > >>> [ +0,004360] usb_phy_generic: probe of phy0 failed with error -2 > >>> [ +0,004991] usb_phy_generic phy1: GPIO lookup for consumer reset-gpios > >>> [ +0,000012] usb_phy_generic phy1: using device tree for GPIO lookup > >>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' > >>> property > >>> of node '/phy1[0]' > >>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' > >>> property of node '/phy1[0]' > >>> [ +0,000010] usb_phy_generic phy1: using lookup tables for GPIO lookup > >>> [ +0,000012] usb_phy_generic phy1: lookup for GPIO reset-gpios failed > >>> [ +0,000011] usb_phy_generic phy1: Error requesting RESET GPIO > >>> [ +0,004337] usb_phy_generic: probe of phy1 failed with error -2 > >>> > >>> So, I guess the chipidea driver is deferring because the phys want a > >>> property that neither me nor you are specifying? Would that be the two > >>> MDIO pins 52 and 53 that would need to be specified? > >> > >> Erm, scratch that last question - wrong PHY. Trying it resolved the > >> above phy errors but not the original problem. And so does an empty one: > >> > >> @@ -99,11 +100,13 @@ > >> > >> usb_phy0: phy0 { > >> compatible = "usb-nop-xceiv"; > >> + reset-gpios = <>; > >> #phy-cells = <0>; > >> }; > >> > >> usb_phy1: phy1 { > >> compatible = "usb-nop-xceiv"; > >> + reset-gpios = <>; > >> #phy-cells = <0>; > >> }; > >> }; > >> > >> In my manuals and notes I can't find any GPIO being used as reset for > >> the USB PHYs. Any thoughts appreciated. > > > > Such a connection is optional. The platform might rely on its reset > > circuit, though it might not work for warm reboots. > > I haven't looked at parallela docs, but if there is a schematic > > available, that should tell you if/what is connected to the PHY reset > > pin. > > I do have the schematic, and the way I read it, only the on-board reset > button resets the PHYs. > > Yet it looks as if usb-nop-xceiv insists on a reset-gpios above, no? > Does it work on your boards with linux-next? I haven't re-tested it since I submitted the patches, but at that time it worked. But I also didn't test USB with the pinctrl patches together. I'll do some testing later today. Soren ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3] ARM: zynq: DT: Add USB to device tree @ 2015-01-26 16:23 ` Sören Brinkmann 0 siblings, 0 replies; 34+ messages in thread From: Sören Brinkmann @ 2015-01-26 16:23 UTC (permalink / raw) To: Andreas Färber Cc: monstr, Michal Simek, devicetree, Peter Crosthwaite, Arnd Bergmann, linux-kernel, linux-arm-kernel, Ola Jeppson On Mon, 2015-01-26 at 05:21PM +0100, Andreas Färber wrote: > Am 26.01.2015 um 16:50 schrieb Sören Brinkmann: > > On Mon, 2015-01-26 at 10:35AM +0100, Andreas Färber wrote: > >> Am 26.01.2015 um 09:33 schrieb Andreas Färber: > >>> Am 26.01.2015 um 09:23 schrieb Michal Simek: > >>>> On 01/26/2015 09:19 AM, Andreas Färber wrote: > >>>>> And if I apply it to my -next based tree, adding corresponding nodes to > >>>>> zynq-parallella.dts, I get repeatedly: > >>>>> > >>>>> [ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT > >>>>> [ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: > >>>>> f090e100 op: f090e140 > >>>>> [ +0,000081] platform ci_hdrc.0: Driver ci_hdrc requests probe deferral > >>>>> [ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT > >>>>> [ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: > >>>>> f0910100 op: f0910140 > >>>>> [ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe deferral > >>>>> > >>>>> Am I missing any other patches or config options? > >>>>> (I do notice that the pinctrl v3 patch that got merged has a trivial bug > >>>>> for usb0, for which I'll send a patch later on.) > >>>> > >>>> Why is it deferred? Is it because of pinmuxing stuff? > >>> > >>> No, happened without as well. > >>> > >>> Looking at a different place in dmesg, I spot this: > >>> > >>> [ +0,003988] usb_phy_generic phy0: GPIO lookup for consumer reset-gpios > >>> [ +0,000012] usb_phy_generic phy0: using device tree for GPIO lookup > >>> [ +0,000015] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' > >>> property > >>> of node '/phy0[0]' > >>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' > >>> property > >>> of node '/phy0[0]' > >>> [ +0,000010] usb_phy_generic phy0: using lookup tables for GPIO lookup > >>> [ +0,000153] usb_phy_generic phy0: lookup for GPIO reset-gpios failed > >>> [ +0,000012] usb_phy_generic phy0: Error requesting RESET GPIO > >>> [ +0,004360] usb_phy_generic: probe of phy0 failed with error -2 > >>> [ +0,004991] usb_phy_generic phy1: GPIO lookup for consumer reset-gpios > >>> [ +0,000012] usb_phy_generic phy1: using device tree for GPIO lookup > >>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' > >>> property > >>> of node '/phy1[0]' > >>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' > >>> property of node '/phy1[0]' > >>> [ +0,000010] usb_phy_generic phy1: using lookup tables for GPIO lookup > >>> [ +0,000012] usb_phy_generic phy1: lookup for GPIO reset-gpios failed > >>> [ +0,000011] usb_phy_generic phy1: Error requesting RESET GPIO > >>> [ +0,004337] usb_phy_generic: probe of phy1 failed with error -2 > >>> > >>> So, I guess the chipidea driver is deferring because the phys want a > >>> property that neither me nor you are specifying? Would that be the two > >>> MDIO pins 52 and 53 that would need to be specified? > >> > >> Erm, scratch that last question - wrong PHY. Trying it resolved the > >> above phy errors but not the original problem. And so does an empty one: > >> > >> @@ -99,11 +100,13 @@ > >> > >> usb_phy0: phy0 { > >> compatible = "usb-nop-xceiv"; > >> + reset-gpios = <>; > >> #phy-cells = <0>; > >> }; > >> > >> usb_phy1: phy1 { > >> compatible = "usb-nop-xceiv"; > >> + reset-gpios = <>; > >> #phy-cells = <0>; > >> }; > >> }; > >> > >> In my manuals and notes I can't find any GPIO being used as reset for > >> the USB PHYs. Any thoughts appreciated. > > > > Such a connection is optional. The platform might rely on its reset > > circuit, though it might not work for warm reboots. > > I haven't looked at parallela docs, but if there is a schematic > > available, that should tell you if/what is connected to the PHY reset > > pin. > > I do have the schematic, and the way I read it, only the on-board reset > button resets the PHYs. > > Yet it looks as if usb-nop-xceiv insists on a reset-gpios above, no? > Does it work on your boards with linux-next? I haven't re-tested it since I submitted the patches, but at that time it worked. But I also didn't test USB with the pinctrl patches together. I'll do some testing later today. Soren ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3] ARM: zynq: DT: Add USB to device tree @ 2015-01-26 18:44 ` Sören Brinkmann 0 siblings, 0 replies; 34+ messages in thread From: Sören Brinkmann @ 2015-01-26 18:44 UTC (permalink / raw) To: Andreas Färber Cc: monstr, Michal Simek, devicetree, Peter Crosthwaite, Arnd Bergmann, linux-kernel, linux-arm-kernel, Ola Jeppson On Mon, 2015-01-26 at 08:23AM -0800, Sören Brinkmann wrote: > On Mon, 2015-01-26 at 05:21PM +0100, Andreas Färber wrote: > > Am 26.01.2015 um 16:50 schrieb Sören Brinkmann: > > > On Mon, 2015-01-26 at 10:35AM +0100, Andreas Färber wrote: > > >> Am 26.01.2015 um 09:33 schrieb Andreas Färber: > > >>> Am 26.01.2015 um 09:23 schrieb Michal Simek: > > >>>> On 01/26/2015 09:19 AM, Andreas Färber wrote: > > >>>>> And if I apply it to my -next based tree, adding corresponding nodes to > > >>>>> zynq-parallella.dts, I get repeatedly: > > >>>>> > > >>>>> [ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT > > >>>>> [ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: > > >>>>> f090e100 op: f090e140 > > >>>>> [ +0,000081] platform ci_hdrc.0: Driver ci_hdrc requests probe deferral > > >>>>> [ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT > > >>>>> [ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: > > >>>>> f0910100 op: f0910140 > > >>>>> [ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe deferral > > >>>>> > > >>>>> Am I missing any other patches or config options? > > >>>>> (I do notice that the pinctrl v3 patch that got merged has a trivial bug > > >>>>> for usb0, for which I'll send a patch later on.) > > >>>> > > >>>> Why is it deferred? Is it because of pinmuxing stuff? > > >>> > > >>> No, happened without as well. > > >>> > > >>> Looking at a different place in dmesg, I spot this: > > >>> > > >>> [ +0,003988] usb_phy_generic phy0: GPIO lookup for consumer reset-gpios > > >>> [ +0,000012] usb_phy_generic phy0: using device tree for GPIO lookup > > >>> [ +0,000015] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' > > >>> property > > >>> of node '/phy0[0]' > > >>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' > > >>> property > > >>> of node '/phy0[0]' > > >>> [ +0,000010] usb_phy_generic phy0: using lookup tables for GPIO lookup > > >>> [ +0,000153] usb_phy_generic phy0: lookup for GPIO reset-gpios failed > > >>> [ +0,000012] usb_phy_generic phy0: Error requesting RESET GPIO > > >>> [ +0,004360] usb_phy_generic: probe of phy0 failed with error -2 > > >>> [ +0,004991] usb_phy_generic phy1: GPIO lookup for consumer reset-gpios > > >>> [ +0,000012] usb_phy_generic phy1: using device tree for GPIO lookup > > >>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' > > >>> property > > >>> of node '/phy1[0]' > > >>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' > > >>> property of node '/phy1[0]' > > >>> [ +0,000010] usb_phy_generic phy1: using lookup tables for GPIO lookup > > >>> [ +0,000012] usb_phy_generic phy1: lookup for GPIO reset-gpios failed > > >>> [ +0,000011] usb_phy_generic phy1: Error requesting RESET GPIO > > >>> [ +0,004337] usb_phy_generic: probe of phy1 failed with error -2 > > >>> > > >>> So, I guess the chipidea driver is deferring because the phys want a > > >>> property that neither me nor you are specifying? Would that be the two > > >>> MDIO pins 52 and 53 that would need to be specified? > > >> > > >> Erm, scratch that last question - wrong PHY. Trying it resolved the > > >> above phy errors but not the original problem. And so does an empty one: > > >> > > >> @@ -99,11 +100,13 @@ > > >> > > >> usb_phy0: phy0 { > > >> compatible = "usb-nop-xceiv"; > > >> + reset-gpios = <>; > > >> #phy-cells = <0>; > > >> }; > > >> > > >> usb_phy1: phy1 { > > >> compatible = "usb-nop-xceiv"; > > >> + reset-gpios = <>; > > >> #phy-cells = <0>; > > >> }; > > >> }; > > >> > > >> In my manuals and notes I can't find any GPIO being used as reset for > > >> the USB PHYs. Any thoughts appreciated. > > > > > > Such a connection is optional. The platform might rely on its reset > > > circuit, though it might not work for warm reboots. > > > I haven't looked at parallela docs, but if there is a schematic > > > available, that should tell you if/what is connected to the PHY reset > > > pin. > > > > I do have the schematic, and the way I read it, only the on-board reset > > button resets the PHYs. > > > > Yet it looks as if usb-nop-xceiv insists on a reset-gpios above, no? > > Does it work on your boards with linux-next? > > I haven't re-tested it since I submitted the patches, but at that time > it worked. But I also didn't test USB with the pinctrl patches together. > I'll do some testing later today. So, just did a test. I took all the pinctrl stuff and this patch and ran it on a zc702. I plugged in a thumb drive and that worked just fine. So, basically this patch could go in, despite missing pinctrl properties. Michal: How do you wanna handle this? Could you create a branch that has all the DT updates I can base stuff on, please? We could either take the pinctrl patches and this patch and add another one adding the pinctrl properties to the USB nodes. Or leave this patch out for now and revise it on top of the pinctrl patches. Thanks, Sören ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v3] ARM: zynq: DT: Add USB to device tree @ 2015-01-26 18:44 ` Sören Brinkmann 0 siblings, 0 replies; 34+ messages in thread From: Sören Brinkmann @ 2015-01-26 18:44 UTC (permalink / raw) To: linux-arm-kernel On Mon, 2015-01-26 at 08:23AM -0800, S?ren Brinkmann wrote: > On Mon, 2015-01-26 at 05:21PM +0100, Andreas F?rber wrote: > > Am 26.01.2015 um 16:50 schrieb S?ren Brinkmann: > > > On Mon, 2015-01-26 at 10:35AM +0100, Andreas F?rber wrote: > > >> Am 26.01.2015 um 09:33 schrieb Andreas F?rber: > > >>> Am 26.01.2015 um 09:23 schrieb Michal Simek: > > >>>> On 01/26/2015 09:19 AM, Andreas F?rber wrote: > > >>>>> And if I apply it to my -next based tree, adding corresponding nodes to > > >>>>> zynq-parallella.dts, I get repeatedly: > > >>>>> > > >>>>> [ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT > > >>>>> [ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: > > >>>>> f090e100 op: f090e140 > > >>>>> [ +0,000081] platform ci_hdrc.0: Driver ci_hdrc requests probe deferral > > >>>>> [ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT > > >>>>> [ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: > > >>>>> f0910100 op: f0910140 > > >>>>> [ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe deferral > > >>>>> > > >>>>> Am I missing any other patches or config options? > > >>>>> (I do notice that the pinctrl v3 patch that got merged has a trivial bug > > >>>>> for usb0, for which I'll send a patch later on.) > > >>>> > > >>>> Why is it deferred? Is it because of pinmuxing stuff? > > >>> > > >>> No, happened without as well. > > >>> > > >>> Looking at a different place in dmesg, I spot this: > > >>> > > >>> [ +0,003988] usb_phy_generic phy0: GPIO lookup for consumer reset-gpios > > >>> [ +0,000012] usb_phy_generic phy0: using device tree for GPIO lookup > > >>> [ +0,000015] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' > > >>> property > > >>> of node '/phy0[0]' > > >>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' > > >>> property > > >>> of node '/phy0[0]' > > >>> [ +0,000010] usb_phy_generic phy0: using lookup tables for GPIO lookup > > >>> [ +0,000153] usb_phy_generic phy0: lookup for GPIO reset-gpios failed > > >>> [ +0,000012] usb_phy_generic phy0: Error requesting RESET GPIO > > >>> [ +0,004360] usb_phy_generic: probe of phy0 failed with error -2 > > >>> [ +0,004991] usb_phy_generic phy1: GPIO lookup for consumer reset-gpios > > >>> [ +0,000012] usb_phy_generic phy1: using device tree for GPIO lookup > > >>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' > > >>> property > > >>> of node '/phy1[0]' > > >>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' > > >>> property of node '/phy1[0]' > > >>> [ +0,000010] usb_phy_generic phy1: using lookup tables for GPIO lookup > > >>> [ +0,000012] usb_phy_generic phy1: lookup for GPIO reset-gpios failed > > >>> [ +0,000011] usb_phy_generic phy1: Error requesting RESET GPIO > > >>> [ +0,004337] usb_phy_generic: probe of phy1 failed with error -2 > > >>> > > >>> So, I guess the chipidea driver is deferring because the phys want a > > >>> property that neither me nor you are specifying? Would that be the two > > >>> MDIO pins 52 and 53 that would need to be specified? > > >> > > >> Erm, scratch that last question - wrong PHY. Trying it resolved the > > >> above phy errors but not the original problem. And so does an empty one: > > >> > > >> @@ -99,11 +100,13 @@ > > >> > > >> usb_phy0: phy0 { > > >> compatible = "usb-nop-xceiv"; > > >> + reset-gpios = <>; > > >> #phy-cells = <0>; > > >> }; > > >> > > >> usb_phy1: phy1 { > > >> compatible = "usb-nop-xceiv"; > > >> + reset-gpios = <>; > > >> #phy-cells = <0>; > > >> }; > > >> }; > > >> > > >> In my manuals and notes I can't find any GPIO being used as reset for > > >> the USB PHYs. Any thoughts appreciated. > > > > > > Such a connection is optional. The platform might rely on its reset > > > circuit, though it might not work for warm reboots. > > > I haven't looked at parallela docs, but if there is a schematic > > > available, that should tell you if/what is connected to the PHY reset > > > pin. > > > > I do have the schematic, and the way I read it, only the on-board reset > > button resets the PHYs. > > > > Yet it looks as if usb-nop-xceiv insists on a reset-gpios above, no? > > Does it work on your boards with linux-next? > > I haven't re-tested it since I submitted the patches, but at that time > it worked. But I also didn't test USB with the pinctrl patches together. > I'll do some testing later today. So, just did a test. I took all the pinctrl stuff and this patch and ran it on a zc702. I plugged in a thumb drive and that worked just fine. So, basically this patch could go in, despite missing pinctrl properties. Michal: How do you wanna handle this? Could you create a branch that has all the DT updates I can base stuff on, please? We could either take the pinctrl patches and this patch and add another one adding the pinctrl properties to the USB nodes. Or leave this patch out for now and revise it on top of the pinctrl patches. Thanks, S?ren ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3] ARM: zynq: DT: Add USB to device tree @ 2015-01-26 18:44 ` Sören Brinkmann 0 siblings, 0 replies; 34+ messages in thread From: Sören Brinkmann @ 2015-01-26 18:44 UTC (permalink / raw) To: Andreas Färber Cc: monstr-pSz03upnqPeHXe+LvDLADg, Michal Simek, devicetree-u79uwXL29TY76Z2rM5mHXA, Peter Crosthwaite, Arnd Bergmann, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Ola Jeppson On Mon, 2015-01-26 at 08:23AM -0800, Sören Brinkmann wrote: > On Mon, 2015-01-26 at 05:21PM +0100, Andreas Färber wrote: > > Am 26.01.2015 um 16:50 schrieb Sören Brinkmann: > > > On Mon, 2015-01-26 at 10:35AM +0100, Andreas Färber wrote: > > >> Am 26.01.2015 um 09:33 schrieb Andreas Färber: > > >>> Am 26.01.2015 um 09:23 schrieb Michal Simek: > > >>>> On 01/26/2015 09:19 AM, Andreas Färber wrote: > > >>>>> And if I apply it to my -next based tree, adding corresponding nodes to > > >>>>> zynq-parallella.dts, I get repeatedly: > > >>>>> > > >>>>> [ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT > > >>>>> [ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: > > >>>>> f090e100 op: f090e140 > > >>>>> [ +0,000081] platform ci_hdrc.0: Driver ci_hdrc requests probe deferral > > >>>>> [ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT > > >>>>> [ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: > > >>>>> f0910100 op: f0910140 > > >>>>> [ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe deferral > > >>>>> > > >>>>> Am I missing any other patches or config options? > > >>>>> (I do notice that the pinctrl v3 patch that got merged has a trivial bug > > >>>>> for usb0, for which I'll send a patch later on.) > > >>>> > > >>>> Why is it deferred? Is it because of pinmuxing stuff? > > >>> > > >>> No, happened without as well. > > >>> > > >>> Looking at a different place in dmesg, I spot this: > > >>> > > >>> [ +0,003988] usb_phy_generic phy0: GPIO lookup for consumer reset-gpios > > >>> [ +0,000012] usb_phy_generic phy0: using device tree for GPIO lookup > > >>> [ +0,000015] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' > > >>> property > > >>> of node '/phy0[0]' > > >>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' > > >>> property > > >>> of node '/phy0[0]' > > >>> [ +0,000010] usb_phy_generic phy0: using lookup tables for GPIO lookup > > >>> [ +0,000153] usb_phy_generic phy0: lookup for GPIO reset-gpios failed > > >>> [ +0,000012] usb_phy_generic phy0: Error requesting RESET GPIO > > >>> [ +0,004360] usb_phy_generic: probe of phy0 failed with error -2 > > >>> [ +0,004991] usb_phy_generic phy1: GPIO lookup for consumer reset-gpios > > >>> [ +0,000012] usb_phy_generic phy1: using device tree for GPIO lookup > > >>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' > > >>> property > > >>> of node '/phy1[0]' > > >>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' > > >>> property of node '/phy1[0]' > > >>> [ +0,000010] usb_phy_generic phy1: using lookup tables for GPIO lookup > > >>> [ +0,000012] usb_phy_generic phy1: lookup for GPIO reset-gpios failed > > >>> [ +0,000011] usb_phy_generic phy1: Error requesting RESET GPIO > > >>> [ +0,004337] usb_phy_generic: probe of phy1 failed with error -2 > > >>> > > >>> So, I guess the chipidea driver is deferring because the phys want a > > >>> property that neither me nor you are specifying? Would that be the two > > >>> MDIO pins 52 and 53 that would need to be specified? > > >> > > >> Erm, scratch that last question - wrong PHY. Trying it resolved the > > >> above phy errors but not the original problem. And so does an empty one: > > >> > > >> @@ -99,11 +100,13 @@ > > >> > > >> usb_phy0: phy0 { > > >> compatible = "usb-nop-xceiv"; > > >> + reset-gpios = <>; > > >> #phy-cells = <0>; > > >> }; > > >> > > >> usb_phy1: phy1 { > > >> compatible = "usb-nop-xceiv"; > > >> + reset-gpios = <>; > > >> #phy-cells = <0>; > > >> }; > > >> }; > > >> > > >> In my manuals and notes I can't find any GPIO being used as reset for > > >> the USB PHYs. Any thoughts appreciated. > > > > > > Such a connection is optional. The platform might rely on its reset > > > circuit, though it might not work for warm reboots. > > > I haven't looked at parallela docs, but if there is a schematic > > > available, that should tell you if/what is connected to the PHY reset > > > pin. > > > > I do have the schematic, and the way I read it, only the on-board reset > > button resets the PHYs. > > > > Yet it looks as if usb-nop-xceiv insists on a reset-gpios above, no? > > Does it work on your boards with linux-next? > > I haven't re-tested it since I submitted the patches, but at that time > it worked. But I also didn't test USB with the pinctrl patches together. > I'll do some testing later today. So, just did a test. I took all the pinctrl stuff and this patch and ran it on a zc702. I plugged in a thumb drive and that worked just fine. So, basically this patch could go in, despite missing pinctrl properties. Michal: How do you wanna handle this? Could you create a branch that has all the DT updates I can base stuff on, please? We could either take the pinctrl patches and this patch and add another one adding the pinctrl properties to the USB nodes. Or leave this patch out for now and revise it on top of the pinctrl patches. Thanks, Sören -- 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] 34+ messages in thread
[parent not found: <bb50396a16ab4042bdb554f72bde0bf7-xjCwUguQ55/bHPOQ8RbMe2YJ4DzVTqeXkX/xN29GLwg@public.gmane.org>]
* Re: [PATCH v3] ARM: zynq: DT: Add USB to device tree 2015-01-26 18:44 ` Sören Brinkmann (?) @ 2015-01-27 1:14 ` Andreas Färber -1 siblings, 0 replies; 34+ messages in thread From: Andreas Färber @ 2015-01-27 1:14 UTC (permalink / raw) To: Sören Brinkmann Cc: monstr-pSz03upnqPeHXe+LvDLADg, Michal Simek, devicetree-u79uwXL29TY76Z2rM5mHXA, Peter Crosthwaite, Arnd Bergmann, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Ola Jeppson, linux-gpio-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA, Felipe Balbi [-- Attachment #1: Type: text/plain, Size: 6643 bytes --] + linux-gpio, linux-usb, Felipe Balbi Am 26.01.2015 um 19:44 schrieb Sören Brinkmann: > On Mon, 2015-01-26 at 08:23AM -0800, Sören Brinkmann wrote: >> On Mon, 2015-01-26 at 05:21PM +0100, Andreas Färber wrote: >>> Am 26.01.2015 um 16:50 schrieb Sören Brinkmann: >>>> On Mon, 2015-01-26 at 10:35AM +0100, Andreas Färber wrote: >>>>> Am 26.01.2015 um 09:33 schrieb Andreas Färber: >>>>>> Am 26.01.2015 um 09:23 schrieb Michal Simek: >>>>>>> On 01/26/2015 09:19 AM, Andreas Färber wrote: >>>>>>>> And if I apply it to my -next based tree, adding corresponding nodes to >>>>>>>> zynq-parallella.dts, I get repeatedly: >>>>>>>> >>>>>>>> [ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT >>>>>>>> [ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: >>>>>>>> f090e100 op: f090e140 >>>>>>>> [ +0,000081] platform ci_hdrc.0: Driver ci_hdrc requests probe deferral >>>>>>>> [ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT >>>>>>>> [ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: >>>>>>>> f0910100 op: f0910140 >>>>>>>> [ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe deferral >>>>>>>> >>>>>>>> Am I missing any other patches or config options? [...] >>>>>>> Why is it deferred? Is it because of pinmuxing stuff? >>>>>> >>>>>> No, happened without as well. >>>>>> >>>>>> Looking at a different place in dmesg, I spot this: >>>>>> >>>>>> [ +0,003988] usb_phy_generic phy0: GPIO lookup for consumer reset-gpios >>>>>> [ +0,000012] usb_phy_generic phy0: using device tree for GPIO lookup >>>>>> [ +0,000015] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' >>>>>> property >>>>>> of node '/phy0[0]' >>>>>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' >>>>>> property >>>>>> of node '/phy0[0]' >>>>>> [ +0,000010] usb_phy_generic phy0: using lookup tables for GPIO lookup >>>>>> [ +0,000153] usb_phy_generic phy0: lookup for GPIO reset-gpios failed >>>>>> [ +0,000012] usb_phy_generic phy0: Error requesting RESET GPIO >>>>>> [ +0,004360] usb_phy_generic: probe of phy0 failed with error -2 >>>>>> [ +0,004991] usb_phy_generic phy1: GPIO lookup for consumer reset-gpios >>>>>> [ +0,000012] usb_phy_generic phy1: using device tree for GPIO lookup >>>>>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' >>>>>> property >>>>>> of node '/phy1[0]' >>>>>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' >>>>>> property of node '/phy1[0]' >>>>>> [ +0,000010] usb_phy_generic phy1: using lookup tables for GPIO lookup >>>>>> [ +0,000012] usb_phy_generic phy1: lookup for GPIO reset-gpios failed >>>>>> [ +0,000011] usb_phy_generic phy1: Error requesting RESET GPIO >>>>>> [ +0,004337] usb_phy_generic: probe of phy1 failed with error -2 >>>>>> >>>>>> So, I guess the chipidea driver is deferring because the phys want a >>>>>> property that neither me nor you are specifying? [...] [...] >>>>> In my manuals and notes I can't find any GPIO being used as reset for >>>>> the USB PHYs. Any thoughts appreciated. >>>> >>>> Such a connection is optional. The platform might rely on its reset >>>> circuit, though it might not work for warm reboots. >>>> I haven't looked at parallela docs, but if there is a schematic >>>> available, that should tell you if/what is connected to the PHY reset >>>> pin. >>> >>> I do have the schematic, and the way I read it, only the on-board reset >>> button resets the PHYs. >>> >>> Yet it looks as if usb-nop-xceiv insists on a reset-gpios above, no? >>> Does it work on your boards with linux-next? >> >> I haven't re-tested it since I submitted the patches, but at that time >> it worked. But I also didn't test USB with the pinctrl patches together. >> I'll do some testing later today. > > So, just did a test. I took all the pinctrl stuff and this patch and ran > it on a zc702. I plugged in a thumb drive and that worked just fine. So, > basically this patch could go in, despite missing pinctrl properties. For my board I needed the following workaround: diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c index dd05254241fb..96c7c36e22a6 100644 --- a/drivers/usb/phy/phy-generic.c +++ b/drivers/usb/phy/phy-generic.c @@ -218,13 +218,13 @@ int usb_phy_gen_create_phy(struct device *dev, struct usb_phy_generic *nop, clk_rate = 0; needs_vcc = of_property_read_bool(node, "vcc-supply"); - nop->gpiod_reset = devm_gpiod_get(dev, "reset-gpios"); + /*nop->gpiod_reset = devm_gpiod_get(dev, "reset-gpios"); err = PTR_ERR(nop->gpiod_reset); if (!err) { nop->gpiod_vbus = devm_gpiod_get(dev, "vbus-detect-gpio"); err = PTR_ERR(nop->gpiod_vbus); - } + }*/ } else if (pdata) { type = pdata->type; clk_rate = pdata->clk_rate; [ +0,004738] usb_phy_generic phy0: Looking up vcc-supply from device tree [ +0,000018] usb_phy_generic phy0: Looking up vcc-supply property in node /phy0 failed [ +0,000011] phy0 supply vcc not found, using dummy regulator [ +0,004844] usb_phy_generic phy1: Looking up vcc-supply from device tree [ +0,000017] usb_phy_generic phy1: Looking up vcc-supply property in node /phy1 failed [ +0,000008] phy1 supply vcc not found, using dummy regulator Basically, usb-nop-xceiv fails to probe when reset-gpios property is absent (and probably also when vbus-detect-gpio property is absent). So I don't understand why it would work for your boards without such properties on today's linux-next... sounds like you tested a different tree? Take a look at __gpiod_get_index() called from devm_gpiod_get(): http://lxr.free-electrons.com/source/drivers/gpio/gpiolib.c#L1648 !desc || desc == ERR_PTR(-ENOENT) results in the above "using lookup tables for GPIO lookup", then IS_ERR(desc) in "lookup for GPIO %s failed". My interpretation is that this gpiolib code is probably okay but that the generic usb phy code fails to check for specific error codes such as absent property (as opposed to deferred resolution of a phandle, where we do want to return -EDEFER early). My work tree: https://github.com/afaerber/linux/commits/parallella-next Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg) [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v3] ARM: zynq: DT: Add USB to device tree @ 2015-01-27 1:14 ` Andreas Färber 0 siblings, 0 replies; 34+ messages in thread From: Andreas Färber @ 2015-01-27 1:14 UTC (permalink / raw) To: linux-arm-kernel + linux-gpio, linux-usb, Felipe Balbi Am 26.01.2015 um 19:44 schrieb S?ren Brinkmann: > On Mon, 2015-01-26 at 08:23AM -0800, S?ren Brinkmann wrote: >> On Mon, 2015-01-26 at 05:21PM +0100, Andreas F?rber wrote: >>> Am 26.01.2015 um 16:50 schrieb S?ren Brinkmann: >>>> On Mon, 2015-01-26 at 10:35AM +0100, Andreas F?rber wrote: >>>>> Am 26.01.2015 um 09:33 schrieb Andreas F?rber: >>>>>> Am 26.01.2015 um 09:23 schrieb Michal Simek: >>>>>>> On 01/26/2015 09:19 AM, Andreas F?rber wrote: >>>>>>>> And if I apply it to my -next based tree, adding corresponding nodes to >>>>>>>> zynq-parallella.dts, I get repeatedly: >>>>>>>> >>>>>>>> [ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT >>>>>>>> [ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: >>>>>>>> f090e100 op: f090e140 >>>>>>>> [ +0,000081] platform ci_hdrc.0: Driver ci_hdrc requests probe deferral >>>>>>>> [ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT >>>>>>>> [ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: >>>>>>>> f0910100 op: f0910140 >>>>>>>> [ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe deferral >>>>>>>> >>>>>>>> Am I missing any other patches or config options? [...] >>>>>>> Why is it deferred? Is it because of pinmuxing stuff? >>>>>> >>>>>> No, happened without as well. >>>>>> >>>>>> Looking at a different place in dmesg, I spot this: >>>>>> >>>>>> [ +0,003988] usb_phy_generic phy0: GPIO lookup for consumer reset-gpios >>>>>> [ +0,000012] usb_phy_generic phy0: using device tree for GPIO lookup >>>>>> [ +0,000015] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' >>>>>> property >>>>>> of node '/phy0[0]' >>>>>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' >>>>>> property >>>>>> of node '/phy0[0]' >>>>>> [ +0,000010] usb_phy_generic phy0: using lookup tables for GPIO lookup >>>>>> [ +0,000153] usb_phy_generic phy0: lookup for GPIO reset-gpios failed >>>>>> [ +0,000012] usb_phy_generic phy0: Error requesting RESET GPIO >>>>>> [ +0,004360] usb_phy_generic: probe of phy0 failed with error -2 >>>>>> [ +0,004991] usb_phy_generic phy1: GPIO lookup for consumer reset-gpios >>>>>> [ +0,000012] usb_phy_generic phy1: using device tree for GPIO lookup >>>>>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' >>>>>> property >>>>>> of node '/phy1[0]' >>>>>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' >>>>>> property of node '/phy1[0]' >>>>>> [ +0,000010] usb_phy_generic phy1: using lookup tables for GPIO lookup >>>>>> [ +0,000012] usb_phy_generic phy1: lookup for GPIO reset-gpios failed >>>>>> [ +0,000011] usb_phy_generic phy1: Error requesting RESET GPIO >>>>>> [ +0,004337] usb_phy_generic: probe of phy1 failed with error -2 >>>>>> >>>>>> So, I guess the chipidea driver is deferring because the phys want a >>>>>> property that neither me nor you are specifying? [...] [...] >>>>> In my manuals and notes I can't find any GPIO being used as reset for >>>>> the USB PHYs. Any thoughts appreciated. >>>> >>>> Such a connection is optional. The platform might rely on its reset >>>> circuit, though it might not work for warm reboots. >>>> I haven't looked at parallela docs, but if there is a schematic >>>> available, that should tell you if/what is connected to the PHY reset >>>> pin. >>> >>> I do have the schematic, and the way I read it, only the on-board reset >>> button resets the PHYs. >>> >>> Yet it looks as if usb-nop-xceiv insists on a reset-gpios above, no? >>> Does it work on your boards with linux-next? >> >> I haven't re-tested it since I submitted the patches, but at that time >> it worked. But I also didn't test USB with the pinctrl patches together. >> I'll do some testing later today. > > So, just did a test. I took all the pinctrl stuff and this patch and ran > it on a zc702. I plugged in a thumb drive and that worked just fine. So, > basically this patch could go in, despite missing pinctrl properties. For my board I needed the following workaround: diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c index dd05254241fb..96c7c36e22a6 100644 --- a/drivers/usb/phy/phy-generic.c +++ b/drivers/usb/phy/phy-generic.c @@ -218,13 +218,13 @@ int usb_phy_gen_create_phy(struct device *dev, struct usb_phy_generic *nop, clk_rate = 0; needs_vcc = of_property_read_bool(node, "vcc-supply"); - nop->gpiod_reset = devm_gpiod_get(dev, "reset-gpios"); + /*nop->gpiod_reset = devm_gpiod_get(dev, "reset-gpios"); err = PTR_ERR(nop->gpiod_reset); if (!err) { nop->gpiod_vbus = devm_gpiod_get(dev, "vbus-detect-gpio"); err = PTR_ERR(nop->gpiod_vbus); - } + }*/ } else if (pdata) { type = pdata->type; clk_rate = pdata->clk_rate; [ +0,004738] usb_phy_generic phy0: Looking up vcc-supply from device tree [ +0,000018] usb_phy_generic phy0: Looking up vcc-supply property in node /phy0 failed [ +0,000011] phy0 supply vcc not found, using dummy regulator [ +0,004844] usb_phy_generic phy1: Looking up vcc-supply from device tree [ +0,000017] usb_phy_generic phy1: Looking up vcc-supply property in node /phy1 failed [ +0,000008] phy1 supply vcc not found, using dummy regulator Basically, usb-nop-xceiv fails to probe when reset-gpios property is absent (and probably also when vbus-detect-gpio property is absent). So I don't understand why it would work for your boards without such properties on today's linux-next... sounds like you tested a different tree? Take a look at __gpiod_get_index() called from devm_gpiod_get(): http://lxr.free-electrons.com/source/drivers/gpio/gpiolib.c#L1648 !desc || desc == ERR_PTR(-ENOENT) results in the above "using lookup tables for GPIO lookup", then IS_ERR(desc) in "lookup for GPIO %s failed". My interpretation is that this gpiolib code is probably okay but that the generic usb phy code fails to check for specific error codes such as absent property (as opposed to deferred resolution of a phandle, where we do want to return -EDEFER early). My work tree: https://github.com/afaerber/linux/commits/parallella-next Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany GF: Felix Imend?rffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG N?rnberg) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150127/cc356bd0/attachment.sig> ^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH v3] ARM: zynq: DT: Add USB to device tree @ 2015-01-27 1:14 ` Andreas Färber 0 siblings, 0 replies; 34+ messages in thread From: Andreas Färber @ 2015-01-27 1:14 UTC (permalink / raw) To: Sören Brinkmann Cc: monstr, Michal Simek, devicetree, Peter Crosthwaite, Arnd Bergmann, linux-kernel, linux-arm-kernel, Ola Jeppson, linux-gpio, linux-usb, Felipe Balbi [-- Attachment #1: Type: text/plain, Size: 6643 bytes --] + linux-gpio, linux-usb, Felipe Balbi Am 26.01.2015 um 19:44 schrieb Sören Brinkmann: > On Mon, 2015-01-26 at 08:23AM -0800, Sören Brinkmann wrote: >> On Mon, 2015-01-26 at 05:21PM +0100, Andreas Färber wrote: >>> Am 26.01.2015 um 16:50 schrieb Sören Brinkmann: >>>> On Mon, 2015-01-26 at 10:35AM +0100, Andreas Färber wrote: >>>>> Am 26.01.2015 um 09:33 schrieb Andreas Färber: >>>>>> Am 26.01.2015 um 09:23 schrieb Michal Simek: >>>>>>> On 01/26/2015 09:19 AM, Andreas Färber wrote: >>>>>>>> And if I apply it to my -next based tree, adding corresponding nodes to >>>>>>>> zynq-parallella.dts, I get repeatedly: >>>>>>>> >>>>>>>> [ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT >>>>>>>> [ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: >>>>>>>> f090e100 op: f090e140 >>>>>>>> [ +0,000081] platform ci_hdrc.0: Driver ci_hdrc requests probe deferral >>>>>>>> [ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT >>>>>>>> [ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: >>>>>>>> f0910100 op: f0910140 >>>>>>>> [ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe deferral >>>>>>>> >>>>>>>> Am I missing any other patches or config options? [...] >>>>>>> Why is it deferred? Is it because of pinmuxing stuff? >>>>>> >>>>>> No, happened without as well. >>>>>> >>>>>> Looking at a different place in dmesg, I spot this: >>>>>> >>>>>> [ +0,003988] usb_phy_generic phy0: GPIO lookup for consumer reset-gpios >>>>>> [ +0,000012] usb_phy_generic phy0: using device tree for GPIO lookup >>>>>> [ +0,000015] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' >>>>>> property >>>>>> of node '/phy0[0]' >>>>>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' >>>>>> property >>>>>> of node '/phy0[0]' >>>>>> [ +0,000010] usb_phy_generic phy0: using lookup tables for GPIO lookup >>>>>> [ +0,000153] usb_phy_generic phy0: lookup for GPIO reset-gpios failed >>>>>> [ +0,000012] usb_phy_generic phy0: Error requesting RESET GPIO >>>>>> [ +0,004360] usb_phy_generic: probe of phy0 failed with error -2 >>>>>> [ +0,004991] usb_phy_generic phy1: GPIO lookup for consumer reset-gpios >>>>>> [ +0,000012] usb_phy_generic phy1: using device tree for GPIO lookup >>>>>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' >>>>>> property >>>>>> of node '/phy1[0]' >>>>>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' >>>>>> property of node '/phy1[0]' >>>>>> [ +0,000010] usb_phy_generic phy1: using lookup tables for GPIO lookup >>>>>> [ +0,000012] usb_phy_generic phy1: lookup for GPIO reset-gpios failed >>>>>> [ +0,000011] usb_phy_generic phy1: Error requesting RESET GPIO >>>>>> [ +0,004337] usb_phy_generic: probe of phy1 failed with error -2 >>>>>> >>>>>> So, I guess the chipidea driver is deferring because the phys want a >>>>>> property that neither me nor you are specifying? [...] [...] >>>>> In my manuals and notes I can't find any GPIO being used as reset for >>>>> the USB PHYs. Any thoughts appreciated. >>>> >>>> Such a connection is optional. The platform might rely on its reset >>>> circuit, though it might not work for warm reboots. >>>> I haven't looked at parallela docs, but if there is a schematic >>>> available, that should tell you if/what is connected to the PHY reset >>>> pin. >>> >>> I do have the schematic, and the way I read it, only the on-board reset >>> button resets the PHYs. >>> >>> Yet it looks as if usb-nop-xceiv insists on a reset-gpios above, no? >>> Does it work on your boards with linux-next? >> >> I haven't re-tested it since I submitted the patches, but at that time >> it worked. But I also didn't test USB with the pinctrl patches together. >> I'll do some testing later today. > > So, just did a test. I took all the pinctrl stuff and this patch and ran > it on a zc702. I plugged in a thumb drive and that worked just fine. So, > basically this patch could go in, despite missing pinctrl properties. For my board I needed the following workaround: diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c index dd05254241fb..96c7c36e22a6 100644 --- a/drivers/usb/phy/phy-generic.c +++ b/drivers/usb/phy/phy-generic.c @@ -218,13 +218,13 @@ int usb_phy_gen_create_phy(struct device *dev, struct usb_phy_generic *nop, clk_rate = 0; needs_vcc = of_property_read_bool(node, "vcc-supply"); - nop->gpiod_reset = devm_gpiod_get(dev, "reset-gpios"); + /*nop->gpiod_reset = devm_gpiod_get(dev, "reset-gpios"); err = PTR_ERR(nop->gpiod_reset); if (!err) { nop->gpiod_vbus = devm_gpiod_get(dev, "vbus-detect-gpio"); err = PTR_ERR(nop->gpiod_vbus); - } + }*/ } else if (pdata) { type = pdata->type; clk_rate = pdata->clk_rate; [ +0,004738] usb_phy_generic phy0: Looking up vcc-supply from device tree [ +0,000018] usb_phy_generic phy0: Looking up vcc-supply property in node /phy0 failed [ +0,000011] phy0 supply vcc not found, using dummy regulator [ +0,004844] usb_phy_generic phy1: Looking up vcc-supply from device tree [ +0,000017] usb_phy_generic phy1: Looking up vcc-supply property in node /phy1 failed [ +0,000008] phy1 supply vcc not found, using dummy regulator Basically, usb-nop-xceiv fails to probe when reset-gpios property is absent (and probably also when vbus-detect-gpio property is absent). So I don't understand why it would work for your boards without such properties on today's linux-next... sounds like you tested a different tree? Take a look at __gpiod_get_index() called from devm_gpiod_get(): http://lxr.free-electrons.com/source/drivers/gpio/gpiolib.c#L1648 !desc || desc == ERR_PTR(-ENOENT) results in the above "using lookup tables for GPIO lookup", then IS_ERR(desc) in "lookup for GPIO %s failed". My interpretation is that this gpiolib code is probably okay but that the generic usb phy code fails to check for specific error codes such as absent property (as opposed to deferred resolution of a phandle, where we do want to return -EDEFER early). My work tree: https://github.com/afaerber/linux/commits/parallella-next Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg) [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH v3] ARM: zynq: DT: Add USB to device tree 2015-01-27 1:14 ` Andreas Färber (?) @ 2015-01-27 1:20 ` Sören Brinkmann -1 siblings, 0 replies; 34+ messages in thread From: Sören Brinkmann @ 2015-01-27 1:20 UTC (permalink / raw) To: Andreas Färber Cc: monstr, Michal Simek, devicetree, Peter Crosthwaite, Arnd Bergmann, linux-kernel, linux-arm-kernel, Ola Jeppson, linux-gpio, linux-usb, Felipe Balbi On Tue, 2015-01-27 at 02:14AM +0100, Andreas Färber wrote: > + linux-gpio, linux-usb, Felipe Balbi > > Am 26.01.2015 um 19:44 schrieb Sören Brinkmann: > > On Mon, 2015-01-26 at 08:23AM -0800, Sören Brinkmann wrote: > >> On Mon, 2015-01-26 at 05:21PM +0100, Andreas Färber wrote: > >>> Am 26.01.2015 um 16:50 schrieb Sören Brinkmann: > >>>> On Mon, 2015-01-26 at 10:35AM +0100, Andreas Färber wrote: > >>>>> Am 26.01.2015 um 09:33 schrieb Andreas Färber: > >>>>>> Am 26.01.2015 um 09:23 schrieb Michal Simek: > >>>>>>> On 01/26/2015 09:19 AM, Andreas Färber wrote: > >>>>>>>> And if I apply it to my -next based tree, adding corresponding nodes to > >>>>>>>> zynq-parallella.dts, I get repeatedly: > >>>>>>>> > >>>>>>>> [ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT > >>>>>>>> [ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: > >>>>>>>> f090e100 op: f090e140 > >>>>>>>> [ +0,000081] platform ci_hdrc.0: Driver ci_hdrc requests probe deferral > >>>>>>>> [ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT > >>>>>>>> [ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: > >>>>>>>> f0910100 op: f0910140 > >>>>>>>> [ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe deferral > >>>>>>>> > >>>>>>>> Am I missing any other patches or config options? > [...] > >>>>>>> Why is it deferred? Is it because of pinmuxing stuff? > >>>>>> > >>>>>> No, happened without as well. > >>>>>> > >>>>>> Looking at a different place in dmesg, I spot this: > >>>>>> > >>>>>> [ +0,003988] usb_phy_generic phy0: GPIO lookup for consumer reset-gpios > >>>>>> [ +0,000012] usb_phy_generic phy0: using device tree for GPIO lookup > >>>>>> [ +0,000015] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' > >>>>>> property > >>>>>> of node '/phy0[0]' > >>>>>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' > >>>>>> property > >>>>>> of node '/phy0[0]' > >>>>>> [ +0,000010] usb_phy_generic phy0: using lookup tables for GPIO lookup > >>>>>> [ +0,000153] usb_phy_generic phy0: lookup for GPIO reset-gpios failed > >>>>>> [ +0,000012] usb_phy_generic phy0: Error requesting RESET GPIO > >>>>>> [ +0,004360] usb_phy_generic: probe of phy0 failed with error -2 > >>>>>> [ +0,004991] usb_phy_generic phy1: GPIO lookup for consumer reset-gpios > >>>>>> [ +0,000012] usb_phy_generic phy1: using device tree for GPIO lookup > >>>>>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' > >>>>>> property > >>>>>> of node '/phy1[0]' > >>>>>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' > >>>>>> property of node '/phy1[0]' > >>>>>> [ +0,000010] usb_phy_generic phy1: using lookup tables for GPIO lookup > >>>>>> [ +0,000012] usb_phy_generic phy1: lookup for GPIO reset-gpios failed > >>>>>> [ +0,000011] usb_phy_generic phy1: Error requesting RESET GPIO > >>>>>> [ +0,004337] usb_phy_generic: probe of phy1 failed with error -2 > >>>>>> > >>>>>> So, I guess the chipidea driver is deferring because the phys want a > >>>>>> property that neither me nor you are specifying? [...] > [...] > >>>>> In my manuals and notes I can't find any GPIO being used as reset for > >>>>> the USB PHYs. Any thoughts appreciated. > >>>> > >>>> Such a connection is optional. The platform might rely on its reset > >>>> circuit, though it might not work for warm reboots. > >>>> I haven't looked at parallela docs, but if there is a schematic > >>>> available, that should tell you if/what is connected to the PHY reset > >>>> pin. > >>> > >>> I do have the schematic, and the way I read it, only the on-board reset > >>> button resets the PHYs. > >>> > >>> Yet it looks as if usb-nop-xceiv insists on a reset-gpios above, no? > >>> Does it work on your boards with linux-next? > >> > >> I haven't re-tested it since I submitted the patches, but at that time > >> it worked. But I also didn't test USB with the pinctrl patches together. > >> I'll do some testing later today. > > > > So, just did a test. I took all the pinctrl stuff and this patch and ran > > it on a zc702. I plugged in a thumb drive and that worked just fine. So, > > basically this patch could go in, despite missing pinctrl properties. > > For my board I needed the following workaround: > > diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c > index dd05254241fb..96c7c36e22a6 100644 > --- a/drivers/usb/phy/phy-generic.c > +++ b/drivers/usb/phy/phy-generic.c > @@ -218,13 +218,13 @@ int usb_phy_gen_create_phy(struct device *dev, > struct usb_phy_generic *nop, > clk_rate = 0; > > needs_vcc = of_property_read_bool(node, "vcc-supply"); > - nop->gpiod_reset = devm_gpiod_get(dev, "reset-gpios"); > + /*nop->gpiod_reset = devm_gpiod_get(dev, "reset-gpios"); > err = PTR_ERR(nop->gpiod_reset); > if (!err) { > nop->gpiod_vbus = devm_gpiod_get(dev, > > "vbus-detect-gpio"); > err = PTR_ERR(nop->gpiod_vbus); > - } > + }*/ > } else if (pdata) { > type = pdata->type; > clk_rate = pdata->clk_rate; > > [ +0,004738] usb_phy_generic phy0: Looking up vcc-supply from device tree > [ +0,000018] usb_phy_generic phy0: Looking up vcc-supply property in > node /phy0 failed > [ +0,000011] phy0 supply vcc not found, using dummy regulator > [ +0,004844] usb_phy_generic phy1: Looking up vcc-supply from device tree > [ +0,000017] usb_phy_generic phy1: Looking up vcc-supply property in > node /phy1 failed > [ +0,000008] phy1 supply vcc not found, using dummy regulator > > Basically, usb-nop-xceiv fails to probe when reset-gpios property is > absent (and probably also when vbus-detect-gpio property is absent). > So I don't understand why it would work for your boards without such > properties on today's linux-next... sounds like you tested a different tree? I tested on the 3.19 tip, not on next. I see the problems you see on next though. Haven't really dug deeper yet. > > Take a look at __gpiod_get_index() called from devm_gpiod_get(): > http://lxr.free-electrons.com/source/drivers/gpio/gpiolib.c#L1648 > > !desc || desc == ERR_PTR(-ENOENT) results in the above "using lookup > tables for GPIO lookup", then IS_ERR(desc) in "lookup for GPIO %s failed". > > My interpretation is that this gpiolib code is probably okay but that > the generic usb phy code fails to check for specific error codes such as > absent property (as opposed to deferred resolution of a phandle, where > we do want to return -EDEFER early). Sounds like you're already close. Sören ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v3] ARM: zynq: DT: Add USB to device tree @ 2015-01-27 1:20 ` Sören Brinkmann 0 siblings, 0 replies; 34+ messages in thread From: Sören Brinkmann @ 2015-01-27 1:20 UTC (permalink / raw) To: linux-arm-kernel On Tue, 2015-01-27 at 02:14AM +0100, Andreas F?rber wrote: > + linux-gpio, linux-usb, Felipe Balbi > > Am 26.01.2015 um 19:44 schrieb S?ren Brinkmann: > > On Mon, 2015-01-26 at 08:23AM -0800, S?ren Brinkmann wrote: > >> On Mon, 2015-01-26 at 05:21PM +0100, Andreas F?rber wrote: > >>> Am 26.01.2015 um 16:50 schrieb S?ren Brinkmann: > >>>> On Mon, 2015-01-26 at 10:35AM +0100, Andreas F?rber wrote: > >>>>> Am 26.01.2015 um 09:33 schrieb Andreas F?rber: > >>>>>> Am 26.01.2015 um 09:23 schrieb Michal Simek: > >>>>>>> On 01/26/2015 09:19 AM, Andreas F?rber wrote: > >>>>>>>> And if I apply it to my -next based tree, adding corresponding nodes to > >>>>>>>> zynq-parallella.dts, I get repeatedly: > >>>>>>>> > >>>>>>>> [ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT > >>>>>>>> [ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: > >>>>>>>> f090e100 op: f090e140 > >>>>>>>> [ +0,000081] platform ci_hdrc.0: Driver ci_hdrc requests probe deferral > >>>>>>>> [ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT > >>>>>>>> [ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: > >>>>>>>> f0910100 op: f0910140 > >>>>>>>> [ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe deferral > >>>>>>>> > >>>>>>>> Am I missing any other patches or config options? > [...] > >>>>>>> Why is it deferred? Is it because of pinmuxing stuff? > >>>>>> > >>>>>> No, happened without as well. > >>>>>> > >>>>>> Looking at a different place in dmesg, I spot this: > >>>>>> > >>>>>> [ +0,003988] usb_phy_generic phy0: GPIO lookup for consumer reset-gpios > >>>>>> [ +0,000012] usb_phy_generic phy0: using device tree for GPIO lookup > >>>>>> [ +0,000015] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' > >>>>>> property > >>>>>> of node '/phy0[0]' > >>>>>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' > >>>>>> property > >>>>>> of node '/phy0[0]' > >>>>>> [ +0,000010] usb_phy_generic phy0: using lookup tables for GPIO lookup > >>>>>> [ +0,000153] usb_phy_generic phy0: lookup for GPIO reset-gpios failed > >>>>>> [ +0,000012] usb_phy_generic phy0: Error requesting RESET GPIO > >>>>>> [ +0,004360] usb_phy_generic: probe of phy0 failed with error -2 > >>>>>> [ +0,004991] usb_phy_generic phy1: GPIO lookup for consumer reset-gpios > >>>>>> [ +0,000012] usb_phy_generic phy1: using device tree for GPIO lookup > >>>>>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' > >>>>>> property > >>>>>> of node '/phy1[0]' > >>>>>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' > >>>>>> property of node '/phy1[0]' > >>>>>> [ +0,000010] usb_phy_generic phy1: using lookup tables for GPIO lookup > >>>>>> [ +0,000012] usb_phy_generic phy1: lookup for GPIO reset-gpios failed > >>>>>> [ +0,000011] usb_phy_generic phy1: Error requesting RESET GPIO > >>>>>> [ +0,004337] usb_phy_generic: probe of phy1 failed with error -2 > >>>>>> > >>>>>> So, I guess the chipidea driver is deferring because the phys want a > >>>>>> property that neither me nor you are specifying? [...] > [...] > >>>>> In my manuals and notes I can't find any GPIO being used as reset for > >>>>> the USB PHYs. Any thoughts appreciated. > >>>> > >>>> Such a connection is optional. The platform might rely on its reset > >>>> circuit, though it might not work for warm reboots. > >>>> I haven't looked at parallela docs, but if there is a schematic > >>>> available, that should tell you if/what is connected to the PHY reset > >>>> pin. > >>> > >>> I do have the schematic, and the way I read it, only the on-board reset > >>> button resets the PHYs. > >>> > >>> Yet it looks as if usb-nop-xceiv insists on a reset-gpios above, no? > >>> Does it work on your boards with linux-next? > >> > >> I haven't re-tested it since I submitted the patches, but at that time > >> it worked. But I also didn't test USB with the pinctrl patches together. > >> I'll do some testing later today. > > > > So, just did a test. I took all the pinctrl stuff and this patch and ran > > it on a zc702. I plugged in a thumb drive and that worked just fine. So, > > basically this patch could go in, despite missing pinctrl properties. > > For my board I needed the following workaround: > > diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c > index dd05254241fb..96c7c36e22a6 100644 > --- a/drivers/usb/phy/phy-generic.c > +++ b/drivers/usb/phy/phy-generic.c > @@ -218,13 +218,13 @@ int usb_phy_gen_create_phy(struct device *dev, > struct usb_phy_generic *nop, > clk_rate = 0; > > needs_vcc = of_property_read_bool(node, "vcc-supply"); > - nop->gpiod_reset = devm_gpiod_get(dev, "reset-gpios"); > + /*nop->gpiod_reset = devm_gpiod_get(dev, "reset-gpios"); > err = PTR_ERR(nop->gpiod_reset); > if (!err) { > nop->gpiod_vbus = devm_gpiod_get(dev, > > "vbus-detect-gpio"); > err = PTR_ERR(nop->gpiod_vbus); > - } > + }*/ > } else if (pdata) { > type = pdata->type; > clk_rate = pdata->clk_rate; > > [ +0,004738] usb_phy_generic phy0: Looking up vcc-supply from device tree > [ +0,000018] usb_phy_generic phy0: Looking up vcc-supply property in > node /phy0 failed > [ +0,000011] phy0 supply vcc not found, using dummy regulator > [ +0,004844] usb_phy_generic phy1: Looking up vcc-supply from device tree > [ +0,000017] usb_phy_generic phy1: Looking up vcc-supply property in > node /phy1 failed > [ +0,000008] phy1 supply vcc not found, using dummy regulator > > Basically, usb-nop-xceiv fails to probe when reset-gpios property is > absent (and probably also when vbus-detect-gpio property is absent). > So I don't understand why it would work for your boards without such > properties on today's linux-next... sounds like you tested a different tree? I tested on the 3.19 tip, not on next. I see the problems you see on next though. Haven't really dug deeper yet. > > Take a look at __gpiod_get_index() called from devm_gpiod_get(): > http://lxr.free-electrons.com/source/drivers/gpio/gpiolib.c#L1648 > > !desc || desc == ERR_PTR(-ENOENT) results in the above "using lookup > tables for GPIO lookup", then IS_ERR(desc) in "lookup for GPIO %s failed". > > My interpretation is that this gpiolib code is probably okay but that > the generic usb phy code fails to check for specific error codes such as > absent property (as opposed to deferred resolution of a phandle, where > we do want to return -EDEFER early). Sounds like you're already close. S?ren ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v3] ARM: zynq: DT: Add USB to device tree @ 2015-01-27 1:20 ` Sören Brinkmann 0 siblings, 0 replies; 34+ messages in thread From: Sören Brinkmann @ 2015-01-27 1:20 UTC (permalink / raw) To: Andreas Färber Cc: monstr, Michal Simek, devicetree, Peter Crosthwaite, Arnd Bergmann, linux-kernel, linux-arm-kernel, Ola Jeppson, linux-gpio, linux-usb, Felipe Balbi On Tue, 2015-01-27 at 02:14AM +0100, Andreas Färber wrote: > + linux-gpio, linux-usb, Felipe Balbi > > Am 26.01.2015 um 19:44 schrieb Sören Brinkmann: > > On Mon, 2015-01-26 at 08:23AM -0800, Sören Brinkmann wrote: > >> On Mon, 2015-01-26 at 05:21PM +0100, Andreas Färber wrote: > >>> Am 26.01.2015 um 16:50 schrieb Sören Brinkmann: > >>>> On Mon, 2015-01-26 at 10:35AM +0100, Andreas Färber wrote: > >>>>> Am 26.01.2015 um 09:33 schrieb Andreas Färber: > >>>>>> Am 26.01.2015 um 09:23 schrieb Michal Simek: > >>>>>>> On 01/26/2015 09:19 AM, Andreas Färber wrote: > >>>>>>>> And if I apply it to my -next based tree, adding corresponding nodes to > >>>>>>>> zynq-parallella.dts, I get repeatedly: > >>>>>>>> > >>>>>>>> [ +0,012242] ci_hdrc ci_hdrc.0: no of_node; not parsing pinctrl DT > >>>>>>>> [ +0,000157] ci_hdrc ci_hdrc.0: ChipIdea HDRC found, lpm: 0; cap: > >>>>>>>> f090e100 op: f090e140 > >>>>>>>> [ +0,000081] platform ci_hdrc.0: Driver ci_hdrc requests probe deferral > >>>>>>>> [ +0,005360] ci_hdrc ci_hdrc.1: no of_node; not parsing pinctrl DT > >>>>>>>> [ +0,000120] ci_hdrc ci_hdrc.1: ChipIdea HDRC found, lpm: 0; cap: > >>>>>>>> f0910100 op: f0910140 > >>>>>>>> [ +0,001810] platform ci_hdrc.1: Driver ci_hdrc requests probe deferral > >>>>>>>> > >>>>>>>> Am I missing any other patches or config options? > [...] > >>>>>>> Why is it deferred? Is it because of pinmuxing stuff? > >>>>>> > >>>>>> No, happened without as well. > >>>>>> > >>>>>> Looking at a different place in dmesg, I spot this: > >>>>>> > >>>>>> [ +0,003988] usb_phy_generic phy0: GPIO lookup for consumer reset-gpios > >>>>>> [ +0,000012] usb_phy_generic phy0: using device tree for GPIO lookup > >>>>>> [ +0,000015] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' > >>>>>> property > >>>>>> of node '/phy0[0]' > >>>>>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' > >>>>>> property > >>>>>> of node '/phy0[0]' > >>>>>> [ +0,000010] usb_phy_generic phy0: using lookup tables for GPIO lookup > >>>>>> [ +0,000153] usb_phy_generic phy0: lookup for GPIO reset-gpios failed > >>>>>> [ +0,000012] usb_phy_generic phy0: Error requesting RESET GPIO > >>>>>> [ +0,004360] usb_phy_generic: probe of phy0 failed with error -2 > >>>>>> [ +0,004991] usb_phy_generic phy1: GPIO lookup for consumer reset-gpios > >>>>>> [ +0,000012] usb_phy_generic phy1: using device tree for GPIO lookup > >>>>>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios' > >>>>>> property > >>>>>> of node '/phy1[0]' > >>>>>> [ +0,000013] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio' > >>>>>> property of node '/phy1[0]' > >>>>>> [ +0,000010] usb_phy_generic phy1: using lookup tables for GPIO lookup > >>>>>> [ +0,000012] usb_phy_generic phy1: lookup for GPIO reset-gpios failed > >>>>>> [ +0,000011] usb_phy_generic phy1: Error requesting RESET GPIO > >>>>>> [ +0,004337] usb_phy_generic: probe of phy1 failed with error -2 > >>>>>> > >>>>>> So, I guess the chipidea driver is deferring because the phys want a > >>>>>> property that neither me nor you are specifying? [...] > [...] > >>>>> In my manuals and notes I can't find any GPIO being used as reset for > >>>>> the USB PHYs. Any thoughts appreciated. > >>>> > >>>> Such a connection is optional. The platform might rely on its reset > >>>> circuit, though it might not work for warm reboots. > >>>> I haven't looked at parallela docs, but if there is a schematic > >>>> available, that should tell you if/what is connected to the PHY reset > >>>> pin. > >>> > >>> I do have the schematic, and the way I read it, only the on-board reset > >>> button resets the PHYs. > >>> > >>> Yet it looks as if usb-nop-xceiv insists on a reset-gpios above, no? > >>> Does it work on your boards with linux-next? > >> > >> I haven't re-tested it since I submitted the patches, but at that time > >> it worked. But I also didn't test USB with the pinctrl patches together. > >> I'll do some testing later today. > > > > So, just did a test. I took all the pinctrl stuff and this patch and ran > > it on a zc702. I plugged in a thumb drive and that worked just fine. So, > > basically this patch could go in, despite missing pinctrl properties. > > For my board I needed the following workaround: > > diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c > index dd05254241fb..96c7c36e22a6 100644 > --- a/drivers/usb/phy/phy-generic.c > +++ b/drivers/usb/phy/phy-generic.c > @@ -218,13 +218,13 @@ int usb_phy_gen_create_phy(struct device *dev, > struct usb_phy_generic *nop, > clk_rate = 0; > > needs_vcc = of_property_read_bool(node, "vcc-supply"); > - nop->gpiod_reset = devm_gpiod_get(dev, "reset-gpios"); > + /*nop->gpiod_reset = devm_gpiod_get(dev, "reset-gpios"); > err = PTR_ERR(nop->gpiod_reset); > if (!err) { > nop->gpiod_vbus = devm_gpiod_get(dev, > > "vbus-detect-gpio"); > err = PTR_ERR(nop->gpiod_vbus); > - } > + }*/ > } else if (pdata) { > type = pdata->type; > clk_rate = pdata->clk_rate; > > [ +0,004738] usb_phy_generic phy0: Looking up vcc-supply from device tree > [ +0,000018] usb_phy_generic phy0: Looking up vcc-supply property in > node /phy0 failed > [ +0,000011] phy0 supply vcc not found, using dummy regulator > [ +0,004844] usb_phy_generic phy1: Looking up vcc-supply from device tree > [ +0,000017] usb_phy_generic phy1: Looking up vcc-supply property in > node /phy1 failed > [ +0,000008] phy1 supply vcc not found, using dummy regulator > > Basically, usb-nop-xceiv fails to probe when reset-gpios property is > absent (and probably also when vbus-detect-gpio property is absent). > So I don't understand why it would work for your boards without such > properties on today's linux-next... sounds like you tested a different tree? I tested on the 3.19 tip, not on next. I see the problems you see on next though. Haven't really dug deeper yet. > > Take a look at __gpiod_get_index() called from devm_gpiod_get(): > http://lxr.free-electrons.com/source/drivers/gpio/gpiolib.c#L1648 > > !desc || desc == ERR_PTR(-ENOENT) results in the above "using lookup > tables for GPIO lookup", then IS_ERR(desc) in "lookup for GPIO %s failed". > > My interpretation is that this gpiolib code is probably okay but that > the generic usb phy code fails to check for specific error codes such as > absent property (as opposed to deferred resolution of a phandle, where > we do want to return -EDEFER early). Sounds like you're already close. Sören ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2015-01-27 1:20 UTC | newest]
Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-12-02 16:07 [PATCH v3] ARM: zynq: DT: Add USB to device tree Soren Brinkmann
2014-12-02 16:07 ` Soren Brinkmann
2014-12-02 16:07 ` Soren Brinkmann
2014-12-03 8:39 ` Michal Simek
2014-12-03 8:39 ` Michal Simek
2015-01-26 8:19 ` Andreas Färber
2015-01-26 8:19 ` Andreas Färber
2015-01-26 8:19 ` Andreas Färber
2015-01-26 8:23 ` Michal Simek
2015-01-26 8:23 ` Michal Simek
2015-01-26 8:33 ` Andreas Färber
2015-01-26 8:33 ` Andreas Färber
2015-01-26 8:33 ` Andreas Färber
2015-01-26 9:35 ` Andreas Färber
2015-01-26 9:35 ` Andreas Färber
2015-01-26 9:35 ` Andreas Färber
2015-01-26 15:50 ` Sören Brinkmann
2015-01-26 15:50 ` Sören Brinkmann
2015-01-26 15:50 ` Sören Brinkmann
2015-01-26 16:21 ` Andreas Färber
2015-01-26 16:21 ` Andreas Färber
2015-01-26 16:21 ` Andreas Färber
2015-01-26 16:23 ` Sören Brinkmann
2015-01-26 16:23 ` Sören Brinkmann
2015-01-26 16:23 ` Sören Brinkmann
2015-01-26 18:44 ` Sören Brinkmann
2015-01-26 18:44 ` Sören Brinkmann
2015-01-26 18:44 ` Sören Brinkmann
[not found] ` <bb50396a16ab4042bdb554f72bde0bf7-xjCwUguQ55/bHPOQ8RbMe2YJ4DzVTqeXkX/xN29GLwg@public.gmane.org>
2015-01-27 1:14 ` Andreas Färber
2015-01-27 1:14 ` Andreas Färber
2015-01-27 1:14 ` Andreas Färber
2015-01-27 1:20 ` Sören Brinkmann
2015-01-27 1:20 ` Sören Brinkmann
2015-01-27 1:20 ` Sören Brinkmann
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.