Re: [PATCH v3] ARM: zynq: DT: Add USB to device tree
+ 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,81] 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,12] usb_phy_generic phy0: using device tree for GPIO lookup
[ +0,15] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios'
property
of node '/phy0[0]'
[ +0,13] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio'
property
of node '/phy0[0]'
[ +0,10] usb_phy_generic phy0: using lookup tables for GPIO lookup
[ +0,000153] usb_phy_generic phy0: lookup for GPIO reset-gpios failed
[ +0,12] 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,12] usb_phy_generic phy1: using device tree for GPIO lookup
[ +0,13] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios'
property
of node '/phy1[0]'
[ +0,13] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio'
property of node '/phy1[0]'
[ +0,10] usb_phy_generic phy1: using lookup tables for GPIO lookup
[ +0,12] usb_phy_generic phy1: lookup for GPIO reset-gpios failed
[ +0,11] 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,18] usb_phy_generic phy0: Looking up vcc-supply property in
node /phy0 failed
[ +0,11] phy0 supply vcc not found, using dummy regulator
[ +0,004844] usb_phy_generic phy1: Looking up vcc-supply from device tree
[ +0,17] usb_phy_generic phy1: Looking up vcc-supply property in
node /phy1 failed
[ +0,08] phy1 supply vcc not found,
Re: [PATCH v3] ARM: zynq: DT: Add USB to device tree
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,81] 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,12] usb_phy_generic phy0: using device tree for GPIO lookup
[ +0,15] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios'
property
of node '/phy0[0]'
[ +0,13] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio'
property
of node '/phy0[0]'
[ +0,10] usb_phy_generic phy0: using lookup tables for GPIO lookup
[ +0,000153] usb_phy_generic phy0: lookup for GPIO reset-gpios failed
[ +0,12] 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,12] usb_phy_generic phy1: using device tree for GPIO lookup
[ +0,13] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpios'
property
of node '/phy1[0]'
[ +0,13] of_get_named_gpiod_flags: can't parse 'reset-gpios-gpio'
property of node '/phy1[0]'
[ +0,10] usb_phy_generic phy1: using lookup tables for GPIO lookup
[ +0,12] usb_phy_generic phy1: lookup for GPIO reset-gpios failed
[ +0,11] 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,18] usb_phy_generic phy0: Looking up vcc-supply property in
node /phy0 failed
[ +0,11] phy0 supply vcc not found, using dummy regulator
[ +0,004844]
