ARM: mvebu: Enable XHCI on the Armada 385 AP
Subsystems (3)
v2 cover ARM: mvebu: Enable XHCI on the Armada 385 AP
Hi all,
This serie enables the Armada 385 AP XHCI controller.
Since the controller uses a GPIO-controlled VBUS, we used the phy-generic driver, and made the needed additions to the xhci-plat driver to retrieve a USB phy.
Unfortunately, some glitches were also found along the way, mostly because of the probe deferring that was introduced by this phy retrieval.
Since the introduction of the Armada 38x support in 3.16, the driver was attempting to write into registers while the clock wasn't enabled yet. This was working because the bootloader left it enabled, but in the case of a deferred probing, the clock would have been disabled by the error path of our driver, and this would fail. This should go in 3.19, and any stable kernel for 3.16+.
The two patches remaining are "regular" patches, and are aimed at 3.20. The last patch depend on my previous serie to introduce support for the the A385 AP board.
Thanks,
Maxime
Changes from v1:
- Removed the patch 1 that fixes the deferred probing that was merged
- Fixed the error path of the mvebu quirks code to avoid leaking a clock reference and the main HCD.
- Removed the extra PHY field private to the struct xhci, and used the usb_phy field in the main HCD instead
- Fixed the error path of the phy retrieval code in order to avoid leaving the phy up if an error was to happen, or the remove callback to be called.
Maxime Ripard (3):
usb: XHCI: platform: Move the Marvell quirks after the enabling the
clocks
usb: xhci: plat: Add USB phy support
ARM: mvebu: armada-385-ap: Enable USB3 port
arch/arm/boot/dts/armada-385-db-ap.dts | 28 +++++++++++++++++++++++++ drivers/usb/host/xhci-plat.c | 38 ++++++++++++++++++++++++---------- 2 files changed, 55 insertions(+), 11 deletions(-)
Signature · 1 line
2.2.2
PATCH v2 1/3 usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks
The commit 973747928514 ("usb: host: xhci-plat: add support for the Armada 375/38x XHCI controllers") extended the xhci-plat driver to support the Armada 375/38x SoCs, mostly by adding a quirk configuring the MBUS window.
However, that quirk was run before the clock the controllers needs has been enabled. This usually worked because the clock was first enabled by the bootloader, and left as such until the driver is probe, where it tries to access the MBUS configuration registers before enabling the clock.
Things get messy when EPROBE_DEFER is involved during the probe, since as part of its error path, the driver will rightfully disable the clock. When the driver will be reprobed, it will retry to access the MBUS registers, but this time with the clock disabled, which hangs forever.
Fix this by running the quirks after the clock has been enabled by the driver.
--- drivers/usb/host/xhci-plat.c | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-)
drivers/usb/host/xhci-plat.c +9 -10
@@ -83,16 +83,6 @@ static int xhci_plat_probe(struct platform_device *pdev)if (irq <0 )return -ENODEV ; - -if (of_device_is_compatible (pdev->dev.of_node, -"marvell,armada-375-xhci" ) || -of_device_is_compatible (pdev->dev.of_node, -"marvell,armada-380-xhci" )) { - ret =xhci_mvebu_mbus_init_quirk (pdev); -if (ret) -return ret; - } -/* Initialize dma_mask and coherent_dma_mask to 32-bits */ ret =dma_set_coherent_mask (&pdev->dev,DMA_BIT_MASK (32 ));if (ret)
@@ -127,6 +117,15 @@ static int xhci_plat_probe(struct platform_device *pdev) goto put_hcd; } +if (of_device_is_compatible (pdev->dev.of_node, +"marvell,armada-375-xhci" ) || +of_device_is_compatible (pdev->dev.of_node, +"marvell,armada-380-xhci" )) { + ret =xhci_mvebu_mbus_init_quirk (pdev); +if (ret) + goto disable_clk; + } + ret =usb_add_hcd (hcd, irq,IRQF_SHARED );if (ret) goto disable_clk;
Signature · 1 line
2.2.2
PATCH v2 1/3 usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks
Hi Mathias, Greg,
Quoted 14 lines · Maxime Ripard
The commit 973747928514 ("usb: host: xhci-plat: add support for the Armada 375/38x XHCI controllers") extended the xhci-plat driver to support the Armada 375/38x SoCs, mostly by adding a quirk configuring the MBUS window.
However, that quirk was run before the clock the controllers needs has been enabled. This usually worked because the clock was first enabled by the bootloader, and left as such until the driver is probe, where it tries to access the MBUS configuration registers before enabling the clock.
Things get messy when
EPROBE_DEFERis involved during the probe, since as part of its error path, the driver will rightfully disable the clock. When the driver will be reprobed, it will retry to access the MBUS registers, but this time with the clock disabled, which hangs forever.
Quoted 4 lines
Fix this by running the quirks after the clock has been enabled by the driver.
Signed-off-by Maxime Ripard <[email protected]>Cc <[email protected]> # v3.16+
Any chance for this to go in 3.19?
Maxime
Signature · 10 lines
Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150204/6c6f3cf9/attachment.sig>
Greg Kroah-Hartman
maintainerPATCH v2 1/3 usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks
Quoted 17 lines · Maxime Ripard
Hi Mathias, Greg,
Quoted 14 lines · Maxime Ripard
The commit 973747928514 ("usb: host: xhci-plat: add support for the Armada 375/38x XHCI controllers") extended the xhci-plat driver to support the Armada 375/38x SoCs, mostly by adding a quirk configuring the MBUS window.
However, that quirk was run before the clock the controllers needs has been enabled. This usually worked because the clock was first enabled by the bootloader, and left as such until the driver is probe, where it tries to access the MBUS configuration registers before enabling the clock.
Things get messy when
EPROBE_DEFERis involved during the probe, since as part of its error path, the driver will rightfully disable the clock. When the driver will be reprobed, it will retry to access the MBUS registers, but this time with the clock disabled, which hangs forever.
Quoted 6 lines
Quoted 4 lines
Fix this by running the quirks after the clock has been enabled by the driver.
Signed-off-by Maxime Ripard <[email protected]>Cc <[email protected]> # v3.16+Any chance for this to go in 3.19?
For 3.19? It's too late, I'm not sending anything else to Linus as 3.19 will be out in a few days.
thanks,
greg k-h
PATCH v2 1/3 usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks
Quoted 20 lines · Greg Kroah-Hartman
Quoted 19 lines · Maxime Ripard
Hi Mathias, Greg,
Quoted 16 lines · Maxime Ripard
The commit 973747928514 ("usb: host: xhci-plat: add support for the Armada 375/38x XHCI controllers") extended the xhci-plat driver to support the Armada 375/38x SoCs, mostly by adding a quirk configuring the MBUS window.
However, that quirk was run before the clock the controllers needs has been enabled. This usually worked because the clock was first enabled by the bootloader, and left as such until the driver is probe, where it tries to access the MBUS configuration registers before enabling the clock.
Things get messy when
EPROBE_DEFERis involved during the probe, since as part of its error path, the driver will rightfully disable the clock. When the driver will be reprobed, it will retry to access the MBUS registers, but this time with the clock disabled, which hangs forever.Fix this by running the quirks after the clock has been enabled by the driver.
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
Signed-off-by Maxime Ripard <[email protected]>Cc <[email protected]> # v3.16+Any chance for this to go in 3.19?
For 3.19? It's too late, I'm not sending anything else to Linus as 3.19 will be out in a few days.
Ok. I'll resend it when 3.20-rc1 is out then.
Thanks!
Maxime
Signature · 10 lines
Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150209/73f78b6d/attachment.sig>
Greg Kroah-Hartman
maintainerPATCH v2 1/3 usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks
Quoted 24 lines · Maxime Ripard
Quoted 23 lines · Greg Kroah-Hartman
Quoted 22 lines · Maxime Ripard
Hi Mathias, Greg,
Quoted 18 lines · Maxime Ripard
The commit 973747928514 ("usb: host: xhci-plat: add support for the Armada 375/38x XHCI controllers") extended the xhci-plat driver to support the Armada 375/38x SoCs, mostly by adding a quirk configuring the MBUS window.
However, that quirk was run before the clock the controllers needs has been enabled. This usually worked because the clock was first enabled by the bootloader, and left as such until the driver is probe, where it tries to access the MBUS configuration registers before enabling the clock.
Things get messy when
EPROBE_DEFERis involved during the probe, since as part of its error path, the driver will rightfully disable the clock. When the driver will be reprobed, it will retry to access the MBUS registers, but this time with the clock disabled, which hangs forever.Fix this by running the quirks after the clock has been enabled by the driver.
Signed-off-by Maxime Ripard <[email protected]>Cc <[email protected]> # v3.16+
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
Any chance for this to go in 3.19?
For 3.19? It's too late, I'm not sending anything else to Linus as 3.19 will be out in a few days.
Ok. I'll resend it when 3.20-rc1 is out then.
Why resend? Mathias should be queueing this up properly. Mathias?
PATCH v2 1/3 usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks
Quoted 25 lines · Greg Kroah-Hartman
Quoted 24 lines · Maxime Ripard
Quoted 23 lines · Greg Kroah-Hartman
Quoted 22 lines · Maxime Ripard
Hi Mathias, Greg,
Quoted 18 lines · Maxime Ripard
The commit 973747928514 ("usb: host: xhci-plat: add support for the Armada 375/38x XHCI controllers") extended the xhci-plat driver to support the Armada 375/38x SoCs, mostly by adding a quirk configuring the MBUS window.
However, that quirk was run before the clock the controllers needs has been enabled. This usually worked because the clock was first enabled by the bootloader, and left as such until the driver is probe, where it tries to access the MBUS configuration registers before enabling the clock.
Things get messy when
EPROBE_DEFERis involved during the probe, since as part of its error path, the driver will rightfully disable the clock. When the driver will be reprobed, it will retry to access the MBUS registers, but this time with the clock disabled, which hangs forever.Fix this by running the quirks after the clock has been enabled by the driver.
Signed-off-by Maxime Ripard <[email protected]>Cc <[email protected]> # v3.16+
Quoted 9 lines
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
Any chance for this to go in 3.19?
For 3.19? It's too late, I'm not sending anything else to Linus as 3.19 will be out in a few days.
Ok. I'll resend it when 3.20-rc1 is out then.
Why resend? Mathias should be queueing this up properly. Mathias?
Yep, I'll send it forward to Greg once 3.20-rc1 is tagged
-Mathias
PATCH v2 2/3 usb: xhci: plat: Add USB phy support
In reply to Maxime RipardThe Marvell Armada 385 AP needs a dumb phy in order to enable the USB3 VBUS.
Add a call to retrieve a USB PHY to XHCI plat in order to support this.
--- drivers/usb/host/xhci-plat.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-)
drivers/usb/host/xhci-plat.c +18 -1
@@ -16,6 +16,7 @@#include <linux/module.h> #include <linux/of.h> #include <linux/platform_device.h> +#include <linux/usb/phy.h> #include <linux/slab.h> #include <linux/usb/xhci_pdriver.h>
@@ -155,12 +156,27 @@ static int xhci_plat_probe(struct platform_device *pdev)if (HCC_MAX_PSA (xhci->hcc_params) >=4 ) xhci->shared_hcd->can_do_streams =1 ; + hcd->usb_phy =devm_usb_get_phy_by_phandle (&pdev->dev,"usb-phy" ,0 ); +if (IS_ERR (hcd->usb_phy)) { + ret =PTR_ERR (hcd->usb_phy); +if (ret == -EPROBE_DEFER ) + goto put_usb3_hcd; + hcd->usb_phy =NULL ; + }else { + ret =usb_phy_init (hcd->usb_phy); +if (ret) + goto put_usb3_hcd; + } + ret =usb_add_hcd (xhci->shared_hcd, irq,IRQF_SHARED );if (ret) - goto put_usb3_hcd; + goto disable_usb_phy;return 0 ; +disable_usb_phy: +usb_phy_shutdown (hcd->usb_phy); + put_usb3_hcd:usb_put_hcd (xhci->shared_hcd);
@@ -184,6 +200,7 @@ static int xhci_plat_remove(struct platform_device *dev)struct clk *clk = xhci->clk;usb_remove_hcd (xhci->shared_hcd); +usb_phy_shutdown (hcd->usb_phy);usb_put_hcd (xhci->shared_hcd);usb_remove_hcd (hcd);
Signature · 1 line
2.2.2
PATCH v2 3/3 ARM: mvebu: armada-385-ap: Enable USB3 port
In reply to Maxime RipardThe Armada 385 AP board has a USB3 port exposed that uses a GPIO to drive the VBUS line. Enable the needed drivers to support this.
--- arch/arm/boot/dts/armada-385-db-ap.dts | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)
arch/arm/boot/dts/armada-385-db-ap.dts +28 -0
@@ -98,6 +98,13 @@ status = "okay"; }; + pinctrl at 18000 { + xhci0_vbus_pins: xhci0-vbus-pins { + marvell,pins = "mpp44"; + marvell,function = "gpio"; + }; + }; + ethernet at 30000 { status = "okay"; phy = <&phy2>;
@@ -122,6 +129,11 @@ phy = <&phy0>; phy-mode = "rgmii-id"; }; + + usb3 at f0000 { + status = "okay"; + usb-phy = <&usb3_phy>; + }; }; pcie-controller {
@@ -147,4 +159,20 @@ }; }; }; + + usb3_phy: usb3_phy { + compatible = "usb-nop-xceiv"; + vcc-supply = <®_xhci0_vbus>; + }; + + reg_xhci0_vbus: xhci0-vbus { + compatible = "regulator-fixed"; + pinctrl-names = "default"; + pinctrl-0 = <&xhci0_vbus_pins>; + regulator-name = "xhci0-vbus"; + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <5000000>; + enable-active-high; + gpio = <&gpio1 12 GPIO_ACTIVE_HIGH>; + }; };
Signature · 1 line
2.2.2
PATCH v2 3/3 ARM: mvebu: armada-385-ap: Enable USB3 port
Hi Maxime,
Quoted 3 lines · Maxime Ripard
The Armada 385 AP board has a USB3 port exposed that uses a GPIO to drive the VBUS line. Enable the needed drivers to support this.
it seems that this patch was not applied yet. Patch 1 is now in linux-next and should be part of 4.0-rc. But what about patch 2?
Thanks,
Gregory
Quoted 57 lines
Signed-off-by Maxime Ripard <[email protected]>--- arch/arm/boot/dts/armada-385-db-ap.dts | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)arch/arm/boot/dts/armada-385-db-ap.dts +28
-0@@ -98,6 +98,13 @@ status = "okay"; }; + pinctrl at 18000 { + xhci0_vbus_pins: xhci0-vbus-pins { + marvell,pins = "mpp44"; + marvell,function = "gpio"; + }; + }; + ethernet at 30000 { status = "okay"; phy = <&phy2>;@@ -122,6 +129,11 @@ phy = <&phy0>; phy-mode = "rgmii-id"; }; + + usb3 at f0000 { + status = "okay"; + usb-phy = <&usb3_phy>; + }; }; pcie-controller {@@ -147,4 +159,20 @@ }; }; }; + + usb3_phy: usb3_phy { + compatible = "usb-nop-xceiv"; + vcc-supply = <®_xhci0_vbus>; + }; + + reg_xhci0_vbus: xhci0-vbus { + compatible = "regulator-fixed"; + pinctrl-names = "default"; + pinctrl-0 = <&xhci0_vbus_pins>; + regulator-name = "xhci0-vbus"; + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <5000000>; + enable-active-high; + gpio = <&gpio1 12 GPIO_ACTIVE_HIGH>; + }; };
Signature · 4 lines
Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH v2 3/3 ARM: mvebu: armada-385-ap: Enable USB3 port
Quoted 9 lines · Gregory CLEMENT
Hi Maxime,
Quoted 3 lines · Maxime Ripard
The Armada 385 AP board has a USB3 port exposed that uses a GPIO to drive the VBUS line. Enable the needed drivers to support this.
it seems that this patch was not applied yet. Patch 1 is now in linux-next and should be part of 4.0-rc. But what about patch 2?
IIRC, Greg or Matthias said that Matthias would look into these patches after the merge window.
It still didn't happen though.
Maxime
Signature · 10 lines
Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150303/662951ce/attachment.sig>
PATCH v2 3/3 ARM: mvebu: armada-385-ap: Enable USB3 port
Quoted 11 lines · Maxime Ripard
Quoted 9 lines · Gregory CLEMENT
Hi Maxime,
Quoted 3 lines · Maxime Ripard
The Armada 385 AP board has a USB3 port exposed that uses a GPIO to drive the VBUS line. Enable the needed drivers to support this.
it seems that this patch was not applied yet. Patch 1 is now in linux-next and should be part of 4.0-rc. But what about patch 2?
Quoted 7 lines
IIRC, Greg or Matthias said that Matthias would look into these patches after the merge window.
It still didn't happen though.
Maxime
Hi
I understood that you wanted the first fix patch in as soon as possible so I sent it forward to Greg, and it's now in his usb-linus branch.
The other two patches, 2/3 and 3/3 you said were "regual" patches (for usb-next?), Andrew said he can take 3/3 and wondered if 2/3 and 3/3 need to go together?
It doesn't matter for me, I can take 2/3 if you like, but I'd prefer if someone with more USB PHY insight could ack it first.
-Mathias
PATCH v2 3/3 ARM: mvebu: armada-385-ap: Enable USB3 port
Hi Matthias,
Quoted 17 lines · Mathias Nyman
Quoted 16 lines · Maxime Ripard
Quoted 9 lines · Gregory CLEMENT
Hi Maxime,
Quoted 3 lines · Maxime Ripard
The Armada 385 AP board has a USB3 port exposed that uses a GPIO to drive the VBUS line. Enable the needed drivers to support this.
it seems that this patch was not applied yet. Patch 1 is now in linux-next and should be part of 4.0-rc. But what about patch 2?
IIRC, Greg or Matthias said that Matthias would look into these patches after the merge window.
It still didn't happen though.
Quoted 7 lines
Quoted 2 lines
Maxime
Hi
I understood that you wanted the first fix patch in as soon as possible so I sent it forward to Greg, and it's now in his usb-linus branch.
Ah, so you were talking only about the first patch. My bad.
Quoted 2 lines
The other two patches, 2/3 and 3/3 you said were "regual" patches (for usb-next?),
Indeed, at least for patch 2.
Quoted 2 lines
Andrew said he can take 3/3 and wondered if 2/3 and 3/3 need to go together?
Patch 3 doesn't need to be merged through the same tree, so I guess it's totally fine if 2 goes through USB and 3 through arm-soc.
Quoted 2 lines
It doesn't matter for me, I can take 2/3 if you like, but I'd prefer if someone with more USB PHY insight could ack it first.
ACK.
Thanks!
Maxime
Signature · 10 lines
Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150304/13faaa7f/attachment.sig>
PATCH v2 3/3 ARM: mvebu: armada-385-ap: Enable USB3 port
In reply to Mathias NymanQuoted 22 lines · Mathias Nyman
Quoted 11 lines · Maxime Ripard
Quoted 9 lines · Gregory CLEMENT
Hi Maxime,
Quoted 3 lines · Maxime Ripard
The Armada 385 AP board has a USB3 port exposed that uses a GPIO to drive the VBUS line. Enable the needed drivers to support this.
it seems that this patch was not applied yet. Patch 1 is now in linux-next and should be part of 4.0-rc. But what about patch 2?
Quoted 7 lines
IIRC, Greg or Matthias said that Matthias would look into these patches after the merge window.
It still didn't happen though.
Maxime
Hi
Quoted 8 lines
I understood that you wanted the first fix patch in as soon as possible so I sent it forward to Greg, and it's now in his usb-linus branch.
The other two patches, 2/3 and 3/3 you said were "regual" patches (for usb-next?), Andrew said he can take 3/3 and wondered if 2/3 and 3/3 need to go together?
It doesn't matter for me, I can take 2/3 if you like, but I'd prefer if someone with more USB PHY insight could ack it first.
There's been around two weeks, and we didn't have any additional reviews. How can we move forward on this?
Thanks!
Maxime
Signature · 10 lines
Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150317/aec4873c/attachment-0001.sig>
PATCH v2 3/3 ARM: mvebu: armada-385-ap: Enable USB3 port
Quoted 26 lines · Maxime Ripard
Quoted 25 lines · Mathias Nyman
Quoted 11 lines · Maxime Ripard
Quoted 9 lines · Gregory CLEMENT
Hi Maxime,
Quoted 3 lines · Maxime Ripard
The Armada 385 AP board has a USB3 port exposed that uses a GPIO to drive the VBUS line. Enable the needed drivers to support this.
it seems that this patch was not applied yet. Patch 1 is now in linux-next and should be part of 4.0-rc. But what about patch 2?
Quoted 7 lines
IIRC, Greg or Matthias said that Matthias would look into these patches after the merge window.
It still didn't happen though.
Maxime
Hi
I understood that you wanted the first fix patch in as soon as possible so I sent it forward to Greg, and it's now in his usb-linus branch.
Quoted 9 lines
Quoted 5 lines
The other two patches, 2/3 and 3/3 you said were "regual" patches (for usb-next?), Andrew said he can take 3/3 and wondered if 2/3 and 3/3 need to go together?
It doesn't matter for me, I can take 2/3 if you like, but I'd prefer if someone with more USB PHY insight could ack it first.
There's been around two weeks, and we didn't have any additional reviews. How can we move forward on this?
Added to my for-usb-next branch and sent forward to Greg (a second a go)
-Mathias
PATCH v2 3/3 ARM: mvebu: armada-385-ap: Enable USB3 port
Quoted 30 lines · Mathias Nyman
Quoted 29 lines · Maxime Ripard
Quoted 28 lines · Mathias Nyman
Quoted 11 lines · Maxime Ripard
Quoted 9 lines · Gregory CLEMENT
Hi Maxime,
Quoted 3 lines · Maxime Ripard
The Armada 385 AP board has a USB3 port exposed that uses a GPIO to drive the VBUS line. Enable the needed drivers to support this.
it seems that this patch was not applied yet. Patch 1 is now in linux-next and should be part of 4.0-rc. But what about patch 2?
Quoted 7 lines
IIRC, Greg or Matthias said that Matthias would look into these patches after the merge window.
It still didn't happen though.
Maxime
Hi
I understood that you wanted the first fix patch in as soon as possible so I sent it forward to Greg, and it's now in his usb-linus branch.
The other two patches, 2/3 and 3/3 you said were "regual" patches (for usb-next?), Andrew said he can take 3/3 and wondered if 2/3 and 3/3 need to go together?
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
It doesn't matter for me, I can take 2/3 if you like, but I'd prefer if someone with more USB PHY insight could ack it first.
There's been around two weeks, and we didn't have any additional reviews. How can we move forward on this?
Added to my for-usb-next branch and sent forward to Greg (a second a go)
Great, thanks!
Maxime
Signature · 10 lines
Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150317/59c3bd41/attachment.sig>
PATCH v2 3/3 ARM: mvebu: armada-385-ap: Enable USB3 port
In reply to Maxime RipardHi Maxime, Jason, Andrew, Sebastian, Greg, Felipe, Mathias,
Quoted 4 lines · Maxime Ripard
The Armada 385 AP board has a USB3 port exposed that uses a GPIO to drive the VBUS line. Enable the needed drivers to support this.
Signed-off-by Maxime Ripard <[email protected]>
applied on mvebu/dt
Thanks,
Gregory
Quoted 56 lines
--- arch/arm/boot/dts/armada-385-db-ap.dts | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)arch/arm/boot/dts/armada-385-db-ap.dts +28
-0@@ -98,6 +98,13 @@ status = "okay"; }; + pinctrl at 18000 { + xhci0_vbus_pins: xhci0-vbus-pins { + marvell,pins = "mpp44"; + marvell,function = "gpio"; + }; + }; + ethernet at 30000 { status = "okay"; phy = <&phy2>;@@ -122,6 +129,11 @@ phy = <&phy0>; phy-mode = "rgmii-id"; }; + + usb3 at f0000 { + status = "okay"; + usb-phy = <&usb3_phy>; + }; }; pcie-controller {@@ -147,4 +159,20 @@ }; }; }; + + usb3_phy: usb3_phy { + compatible = "usb-nop-xceiv"; + vcc-supply = <®_xhci0_vbus>; + }; + + reg_xhci0_vbus: xhci0-vbus { + compatible = "regulator-fixed"; + pinctrl-names = "default"; + pinctrl-0 = <&xhci0_vbus_pins>; + regulator-name = "xhci0-vbus"; + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <5000000>; + enable-active-high; + gpio = <&gpio1 12 GPIO_ACTIVE_HIGH>; + }; };
Signature · 4 lines
Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
v2 cover ARM: mvebu: Enable XHCI on the Armada 385 AP
In reply to Maxime RipardQuoted 19 lines · Maxime Ripard
Hi all,
This serie enables the Armada 385 AP XHCI controller.
Since the controller uses a GPIO-controlled VBUS, we used the phy-generic driver, and made the needed additions to the xhci-plat driver to retrieve a USB phy.
Unfortunately, some glitches were also found along the way, mostly because of the probe deferring that was introduced by this phy retrieval.
Since the introduction of the Armada 38x support in 3.16, the driver was attempting to write into registers while the clock wasn't enabled yet. This was working because the bootloader left it enabled, but in the case of a deferred probing, the clock would have been disabled by the error path of our driver, and this would fail. This should go in 3.19, and any stable kernel for 3.16+.
Quoted 3 lines
The two patches remaining are "regular" patches, and are aimed at 3.20. The last patch depend on my previous serie to introduce support for the the A385 AP board.
Hi Maxime
I assume you want me to take 3/3? Any other route is not simple, since this file only exists in mvebu/dt and maybe a staging branch of arm-soc.
What route do you think the other patches will take?
Thanks
Andrew
v2 cover ARM: mvebu: Enable XHCI on the Armada 385 AP
Hi Andrew,
Quoted 24 lines · Andrew Lunn
Quoted 19 lines · Maxime Ripard
Hi all,
This serie enables the Armada 385 AP XHCI controller.
Since the controller uses a GPIO-controlled VBUS, we used the phy-generic driver, and made the needed additions to the xhci-plat driver to retrieve a USB phy.
Unfortunately, some glitches were also found along the way, mostly because of the probe deferring that was introduced by this phy retrieval.
Since the introduction of the Armada 38x support in 3.16, the driver was attempting to write into registers while the clock wasn't enabled yet. This was working because the bootloader left it enabled, but in the case of a deferred probing, the clock would have been disabled by the error path of our driver, and this would fail. This should go in 3.19, and any stable kernel for 3.16+.
Quoted 3 lines
The two patches remaining are "regular" patches, and are aimed at 3.20. The last patch depend on my previous serie to introduce support for the the A385 AP board.
Quoted 7 lines
Hi Maxime
I assume you want me to take 3/3? Any other route is not simple, since this file only exists in mvebu/dt and maybe a staging branch of arm-soc.
What route do you think the other patches will take?
There should be no merge dependency, but merging the third patch alone will probably result on a boot breakage. I don't think it really matters though, since this is a new board, so I guess it can go through the USB-PHY tree.
Maxime
Signature · 10 lines
Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150120/8943f235/attachment.sig>
v2 cover ARM: mvebu: Enable XHCI on the Armada 385 AP
Quoted 33 lines · Maxime Ripard
Hi Andrew,
Quoted 30 lines · Andrew Lunn
Quoted 19 lines · Maxime Ripard
Hi all,
This serie enables the Armada 385 AP XHCI controller.
Since the controller uses a GPIO-controlled VBUS, we used the phy-generic driver, and made the needed additions to the xhci-plat driver to retrieve a USB phy.
Unfortunately, some glitches were also found along the way, mostly because of the probe deferring that was introduced by this phy retrieval.
Since the introduction of the Armada 38x support in 3.16, the driver was attempting to write into registers while the clock wasn't enabled yet. This was working because the bootloader left it enabled, but in the case of a deferred probing, the clock would have been disabled by the error path of our driver, and this would fail. This should go in 3.19, and any stable kernel for 3.16+.
Quoted 3 lines
The two patches remaining are "regular" patches, and are aimed at 3.20. The last patch depend on my previous serie to introduce support for the the A385 AP board.
Hi Maxime
I assume you want me to take 3/3? Any other route is not simple, since this file only exists in mvebu/dt and maybe a staging branch of arm-soc.
Quoted 6 lines
Quoted 1 line
What route do you think the other patches will take?
There should be no merge dependency, but merging the third patch alone will probably result on a boot breakage. I don't think it really matters though, since this is a new board, so I guess it can go through the USB-PHY tree.
Hi Maxime
Humm, maybe i'm wrong, but i think
arch/arm/boot/dts/armada-385-db-ap.dts
only exists in the mvebu tree?
At least, i don't see it here:
https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/tree/arch/arm/boot/dts?h=next
Andrew
v2 cover ARM: mvebu: Enable XHCI on the Armada 385 AP
Quoted 45 lines · Andrew Lunn
Quoted 33 lines · Maxime Ripard
Hi Andrew,
Quoted 30 lines · Andrew Lunn
Quoted 19 lines · Maxime Ripard
Hi all,
This serie enables the Armada 385 AP XHCI controller.
Since the controller uses a GPIO-controlled VBUS, we used the phy-generic driver, and made the needed additions to the xhci-plat driver to retrieve a USB phy.
Unfortunately, some glitches were also found along the way, mostly because of the probe deferring that was introduced by this phy retrieval.
Since the introduction of the Armada 38x support in 3.16, the driver was attempting to write into registers while the clock wasn't enabled yet. This was working because the bootloader left it enabled, but in the case of a deferred probing, the clock would have been disabled by the error path of our driver, and this would fail. This should go in 3.19, and any stable kernel for 3.16+.
Quoted 3 lines
The two patches remaining are "regular" patches, and are aimed at 3.20. The last patch depend on my previous serie to introduce support for the the A385 AP board.
Hi Maxime
I assume you want me to take 3/3? Any other route is not simple, since this file only exists in mvebu/dt and maybe a staging branch of arm-soc.
Quoted 6 lines
Quoted 1 line
What route do you think the other patches will take?
There should be no merge dependency, but merging the third patch alone will probably result on a boot breakage. I don't think it really matters though, since this is a new board, so I guess it can go through the USB-PHY tree.
Hi Maxime
Humm, maybe i'm wrong, but i think
Quoted 7 lines
arch/arm/boot/dts/armada-385-db-ap.dtsonly exists in the mvebu tree?
At least, i don't see it here:
https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/tree/arch/arm/boot/dts?h=next
Yeah, but my point was that if you merge the DT bits, without having the PHY driver quirks fix in your tree, you'll result in a kernel that doesn't boot at all on that board.
But again, since this is a new board, I don't really see why you would want to bisect that.
Maxime
Signature · 10 lines
Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150121/f049a3da/attachment.sig>