USB: phy: phy-nop: Manage RESET GPIO in the driver
Subsystems (6)
v2 cover USB: phy: phy-nop: Manage RESET GPIO in the driver
Hi,
Modelling the RESET line as a regulator supply wasn't a good idea as it abuses the regulator framework and makes adaptation code/data more complex.
Instead, manage the RESET gpio line directly in the driver.
This also makes us easy to migrate to a dedicated GPIO RESET controller whenever it becomes available. As of now, it doesn't seem to be making it into 3.12.
*NOTE:* As there are changes to platform data, Patch 1 needs to be shared between the arm-soc tree and usb tree.
Patch 1 is available at repo
git://github.com/rogerq/linux.git
in branch
phy-reset-common
Patch 2 contains the phy-nop driver changes
Patches 3 and 4 adapt legacy boot code to the phy-nop driver changes. Patches 5, 6 and 7 adapt DT data to the binding changes. Patch 8 is cleanup of omap3-beagle DT.
Patch 9 adds USB host support to omap3-beagle-xm using the new binding.
Patches are based on v3.11-rc5.
Tested leacy boot on omap3-beagle and omap3-beagle-xm Tested DT boot on omap3-beagle, omap3-beagle-xm and omap4-panda-es
v2:
- Added RESET GPIO polarity feature
- Changed to gpio_set_value_cansleep()
cheers,
-roger
---
Roger Quadros (9):
usb: phy: nop: Add gpio_reset to platform data
usb: phy: nop: Don't use regulator framework for RESET line
ARM: OMAP2+: omap-usb-host: Get rid of platform_data from struct
usbhs_phy_data
ARM: OMAP2+: usb-host: Adapt to USB phy-nop RESET line changes
ARM: dts: omap3-beagle: Use reset-gpios for hsusb2_reset
ARM: dts: omap4-panda: Use reset-gpios for hsusb1_reset
ARM: dts: omap5-uevm: Use reset-gpios for hsusb2_reset
ARM: dts: omap3-beagle: Make USB host pin naming consistent
ARM: dts: omap3-beagle-xm: Add USB Host support
.../devicetree/bindings/usb/usb-nop-xceiv.txt | 7 +- arch/arm/boot/dts/omap3-beagle-xm.dts | 65 +++++++++++++++--- arch/arm/boot/dts/omap3-beagle.dts | 37 ++++------- arch/arm/boot/dts/omap4-panda-common.dtsi | 18 +----- arch/arm/boot/dts/omap5-uevm.dts | 13 +--- arch/arm/mach-omap2/board-omap3beagle.c | 6 -- arch/arm/mach-omap2/usb-host.c | 18 +++--- arch/arm/mach-omap2/usb.h | 1 - drivers/usb/phy/phy-nop.c | 71 ++++++++++++++----- include/linux/usb/nop-usb-xceiv.h | 4 +- 10 files changed, 138 insertions(+), 102 deletions(-)
Signature · 1 line
1.7.4.1
PATCH v2 1/9 usb: phy: nop: Add gpio_reset to platform data
The GPIO number of the RESET line can be passed to the driver using the gpio_reset member.
--- include/linux/usb/nop-usb-xceiv.h | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-)
include/linux/usb/nop-usb-xceiv.h +3 -1
@@ -9,7 +9,9 @@ struct nop_usb_xceiv_platform_data {/* if set fails with -EPROBE_DEFER if can't get regulator */ unsigned int needs_vcc:1; - unsigned int needs_reset:1; + unsigned int needs_reset:1; /* Deprecated */ + +int gpio_reset; };#if defined(CONFIG_NOP_USB_XCEIV ) || (defined(CONFIG_NOP_USB_XCEIV_MODULE ) && defined(MODULE ))
Signature · 1 line
1.7.4.1
PATCH v2 2/9 usb: phy: nop: Don't use regulator framework for RESET line
In reply to Roger QuadrosModelling the RESET line as a regulator supply wasn't a good idea as it kind of abuses the regulator framework and also makes adaptation code more complex.
Instead, manage the RESET gpio line directly in the driver. Update the device tree binding information.
This also makes us easy to migrate to a dedicated GPIO RESET controller whenever it becomes available.
--- .../devicetree/bindings/usb/usb-nop-xceiv.txt | 7 +- drivers/usb/phy/phy-nop.c | 71 ++++++++++++++----- 2 files changed, 55 insertions(+), 23 deletions(-)
Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt +3 -4
@@ -15,7 +15,7 @@ Optional properties: - vcc-supply: phandle to the regulator that provides RESET to the PHY. -- reset-supply: phandle to the regulator that provides power to the PHY. +- reset-gpios: Should specify the GPIO for reset. Example:
@@ -25,10 +25,9 @@ Example: clocks = <&osc 0>; clock-names = "main_clk"; vcc-supply = <&hsusb1_vcc_regulator>; - reset-supply = <&hsusb1_reset_regulator>; + reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>; }; hsusb1_phy is a NOP USB PHY device that gets its clock from an oscillator and expects that clock to be configured to 19.2MHz by the NOP PHY driver. -hsusb1_vcc_regulator provides power to the PHY and hsusb1_reset_regulator -controls RESET. +hsusb1_vcc_regulator provides power to the PHY and GPIO 7 controls RESET.
drivers/usb/phy/phy-nop.c +52 -19
131 lines not on this page · raw message
Signature · 1 line
1.7.4.1
PATCH v2 2/9 usb: phy: nop: Don't use regulator framework for RESET line
Hi Felipe,
There is an issue with this patch and is shown below. I will send a v3 for this.
Quoted 164 lines · Roger Quadros
Modelling the RESET line as a regulator supply wasn't a good idea as it kind of abuses the regulator framework and also makes adaptation code more complex.
Instead, manage the RESET gpio line directly in the driver. Update the device tree binding information.
This also makes us easy to migrate to a dedicated GPIO RESET controller whenever it becomes available.
Signed-off-by Roger Quadros <[email protected]>--- .../devicetree/bindings/usb/usb-nop-xceiv.txt | 7 +- drivers/usb/phy/phy-nop.c | 71 ++++++++++++++----- 2 files changed, 55 insertions(+), 23 deletions(-)Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt +3
-4@@ -15,7 +15,7 @@ Optional properties: - vcc-supply: phandle to the regulator that provides RESET to the PHY. -- reset-supply: phandle to the regulator that provides power to the PHY. +- reset-gpios: Should specify the GPIO for reset. Example:@@ -25,10 +25,9 @@ Example: clocks = <&osc 0>; clock-names = "main_clk"; vcc-supply = <&hsusb1_vcc_regulator>; - reset-supply = <&hsusb1_reset_regulator>; + reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>; }; hsusb1_phy is a NOP USB PHY device that gets its clock from an oscillator and expects that clock to be configured to 19.2MHz by the NOP PHY driver. -hsusb1_vcc_regulator provides power to the PHY and hsusb1_reset_regulator -controls RESET. +hsusb1_vcc_regulator provides power to the PHY and GPIO 7 controls RESET.drivers/usb/phy/phy-nop.c +36
-17@@ -35,6 +35,9 @@#include <linux/clk.h> #include <linux/regulator/consumer.h> #include <linux/of.h> +#include <linux/of_gpio.h> +#include <linux/gpio.h> +#include <linux/delay.h> struct nop_usb_xceiv {struct usb_phy phy;@@ -42,6 +45,8 @@ struct nop_usb_xceiv {struct clk *clk;struct regulator *vcc;struct regulator *reset; +int gpio_reset; +bool reset_active_low; };static struct platform_device *pd;@@ -70,6 +75,23 @@ static int nop_set_suspend(struct usb_phy *x, int suspend)return 0 ; } +static void nop_reset_set (struct nop_usb_xceiv *nop,int asserted) +{ +int value; + +if (!gpio_is_valid (nop->gpio_reset)) +return ; + + value = asserted; +if (nop->reset_active_low) + value = !value; + +gpio_set_value_cansleep (nop->gpio_reset, value); + +if (!asserted) +usleep_range (10000 ,20000 ); +} +static int nop_init (struct usb_phy *phy) {struct nop_usb_xceiv *nop =dev_get_drvdata (phy->dev);@@ -82,11 +104,8 @@ static int nop_init(struct usb_phy *phy)if (!IS_ERR (nop->clk))clk_enable (nop->clk); -if (!IS_ERR (nop->reset)) { -/* De-assert RESET */ -if (regulator_enable (nop->reset)) -dev_err (phy->dev,"Failed to de-assert reset\n" ); - } +/* De-assert RESET */ +nop_reset_set (nop,0 );return 0 ; }@@ -95,11 +114,8 @@ static void nop_shutdown(struct usb_phy *phy) {struct nop_usb_xceiv *nop =dev_get_drvdata (phy->dev); -if (!IS_ERR (nop->reset)) { -/* Assert RESET */ -if (regulator_disable (nop->reset)) -dev_err (phy->dev,"Failed to assert reset\n" ); - } +/* Assert RESET */ +nop_reset_set (nop,1 );if (!IS_ERR (nop->clk))clk_disable (nop->clk);@@ -148,7 +164,6 @@ static int nop_usb_xceiv_probe(struct platform_device *pdev)int err;u32 clk_rate =0 ;bool needs_vcc = false; -bool needs_reset = false; nop =devm_kzalloc (&pdev->dev,sizeof (*nop),GFP_KERNEL );if (!nop)@@ -159,20 +174,28 @@ static int nop_usb_xceiv_probe(struct platform_device *pdev)if (!nop->phy.otg)return -ENOMEM ; + nop->reset_active_low = true;/* default behaviour */ +if (dev->of_node) {struct device_node *node = dev->of_node; +enum of_gpio_flags flags;if (of_property_read_u32 (node,"clock-frequency" , &clk_rate)) clk_rate =0 ; needs_vcc =of_property_read_bool (node,"vcc-supply" ); - needs_reset =of_property_read_bool (node,"reset-supply" ); + nop->gpio_reset =of_get_named_gpio_flags (node,"reset-gpios" , +0 , &flags); +if (nop->gpio_reset == -EPROBE_DEFER ) +return -EPROBE_DEFER ; + + nop->reset_active_low = flags &OF_GPIO_ACTIVE_LOW ; }else if (pdata) { type = pdata->type; clk_rate = pdata->clk_rate; needs_vcc = pdata->needs_vcc; - needs_reset = pdata->needs_reset; + nop->gpio_reset = pdata->gpio_reset; } nop->clk =devm_clk_get (&pdev->dev,"main_clk" );@@ -205,12 +228,22 @@ static int nop_usb_xceiv_probe(struct platform_device *pdev)return -EPROBE_DEFER ; } - nop->reset =devm_regulator_get (&pdev->dev,"reset" ); -if (IS_ERR (nop->reset)) { -dev_dbg (&pdev->dev,"Error getting reset regulator: %ld\n" , -PTR_ERR (nop->reset));
drivers/usb/phy/phy-nop.c static int nop_usb_xceiv_probe(struct platform_device *pdev) · line 238
Quoted 10 lines
drivers/usb/phy/phy-nop.c +8
-2-if (needs_reset) -return -EPROBE_DEFER ; +if (gpio_is_valid (nop->gpio_reset)) { +unsigned long gpio_flags; + +/* Assert RESET */ +if (nop->reset_active_low) + gpio_flags =GPIOF_OUT_INIT_HIGH ; +else + gpio_flags =GPIOF_OUT_INIT_LOW ;
The operations inside if/else need to be reversed.
drivers/usb/phy/phy-nop.c static int nop_usb_xceiv_probe(struct platform_device *pdev) · line 249
Quoted 12 lines
drivers/usb/phy/phy-nop.c +8
-0+ + err =devm_gpio_request_one (dev, nop->gpio_reset, + gpio_flags,dev_name (dev)); +if (err) { +dev_err (dev,"Error requesting RESET GPIO %d\n" , + nop->gpio_reset); +return err; + } } nop->dev = &pdev->dev;
cheers,
-roger
PATCH v2 3/9 ARM: OMAP2+: omap-usb-host: Get rid of platform_data from struct usbhs_phy_data
In reply to Roger QuadrosThe platform data bits can be inferred from the other members of struct usbhs_phy_data. So get rid of the platform_data member.
Build the platform data for the PHY device in usbhs_init_phys() instead.
--- arch/arm/mach-omap2/board-omap3beagle.c | 6 ------ arch/arm/mach-omap2/usb-host.c | 11 ++++++++++- arch/arm/mach-omap2/usb.h | 1 - 3 files changed, 10 insertions(+), 8 deletions(-)
arch/arm/mach-omap2/board-omap3beagle.c +0 -6
@@ -278,18 +278,12 @@ static struct regulator_consumer_supply beagle_vsim_supply[] = {static struct gpio_led gpio_leds[]; -/* PHY's VCC regulator might be added later, so flag that we need it */ -static struct nop_usb_xceiv_platform_data hsusb2_phy_data = { - .needs_vcc = true, -}; -static struct usbhs_phy_data phy_data[] = { { .port =2 , .reset_gpio =147 , .vcc_gpio =-1 ,/* updated in beagle_twl_gpio_setup */ .vcc_polarity =1 ,/* updated in beagle_twl_gpio_setup */ - .platform_data = &hsusb2_phy_data, }, };
arch/arm/mach-omap2/usb-host.c +10 -1
@@ -435,6 +435,7 @@ int usbhs_init_phys(struct usbhs_phy_data *phy, int num_phys)struct platform_device *pdev;char *phy_id;struct platform_device_info pdevinfo; +struct nop_usb_xceiv_platform_data nop_pdata;for (i =0 ; i < num_phys; i++) {
@@ -455,11 +456,19 @@ int usbhs_init_phys(struct usbhs_phy_data *phy, int num_phys)return -ENOMEM ; } +/* set platform data */ +memset (&nop_pdata,0 ,sizeof (nop_pdata)); +if (gpio_is_valid (phy->vcc_gpio)) + nop_pdata.needs_vcc = true; +if (gpio_is_valid (phy->reset_gpio)) + nop_pdata.needs_reset = true; + nop_pdata.type =USB_PHY_TYPE_USB2 ; +/* create a NOP PHY device */ memset (&pdevinfo,0 ,sizeof (pdevinfo)); pdevinfo.name = nop_name; pdevinfo.id = phy->port; - pdevinfo.data = phy->platform_data; + pdevinfo.data = &nop_pdata; pdevinfo.size_data =sizeof (struct nop_usb_xceiv_platform_data ); scnprintf(phy_id, MAX_STR, "nop_usb_xceiv.%d",
arch/arm/mach-omap2/usb.h +0 -1
@@ -58,7 +58,6 @@ struct usbhs_phy_data {int reset_gpio;int vcc_gpio;bool vcc_polarity;/* 1 active high, 0 active low */ -void *platform_data; };extern void usb_musb_init (struct omap_musb_board_data *board_data);
Signature · 1 line
1.7.4.1
PATCH v2 3/9 ARM: OMAP2+: omap-usb-host: Get rid of platform_data from struct usbhs_phy_data
Hi,
Quoted 6 lines · Roger Quadros
The platform data bits can be inferred from the other members of struct
usbhs_phy_data. So get rid of theplatform_datamember.Build the platform data for the PHY device in
usbhs_init_phys()instead.Signed-off-by Roger Quadros <[email protected]>
Tony, do I get your Acked-by here and all following arch/arm/mach-omap2* patches in this series ?
Signature · 8 lines
balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130920/5c0baadd/attachment.sig>
Tony Lindgren
maintainerPATCH v2 3/9 ARM: OMAP2+: omap-usb-host: Get rid of platform_data from struct usbhs_phy_data
Quoted 6 lines · Felipe Balbi
Hi,
Quoted 3 lines · Roger Quadros
The platform data bits can be inferred from the other members of struct
usbhs_phy_data. So get rid of theplatform_datamember.
Quoted 6 lines
Quoted 3 lines
Build the platform data for the PHY device in
usbhs_init_phys()instead.Signed-off-by Roger Quadros <[email protected]>Tony, do I get your Acked-by here and all following
arch/arm/mach-omap2*patches in this series ?
If you can merge just this series without the .dts changes into an immutable topic branch against let's say v3.12-rc2 when it comes out, then yes I can ack them:
That way I can also pull in the topic branch as needed to avoid self inflicted merge conflicts ;) And Benoit can set up a separate .dts branch based on your branch to make sure the dependencies are in place before merging that one upstream.
Regards,
Tony
PATCH v2 3/9 ARM: OMAP2+: omap-usb-host: Get rid of platform_data from struct usbhs_phy_data
Quoted 18 lines · Tony Lindgren
Quoted 6 lines · Felipe Balbi
Hi,
Quoted 3 lines · Roger Quadros
The platform data bits can be inferred from the other members of struct
usbhs_phy_data. So get rid of theplatform_datamember.Quoted 6 lines
Quoted 3 lines
Build the platform data for the PHY device in
usbhs_init_phys()instead.Signed-off-by Roger Quadros <[email protected]>Tony, do I get your Acked-by here and all following
arch/arm/mach-omap2*patches in this series ?If you can merge just this series without the .dts changes into an immutable topic branch against let's say v3.12-rc2 when it comes out, then yes I can ack them:
Quoted 7 lines
Acked-by Tony Lindgren <[email protected]>That way I can also pull in the topic branch as needed to avoid self inflicted merge conflicts ;) And Benoit can set up a separate .dts branch based on your branch to make sure the dependencies are in place before merging that one upstream.
Alright, i'll put this in my todo for next week.
Signature · 8 lines
balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130920/aac5c4d4/attachment.sig>
PATCH v2 4/9 ARM: OMAP2+: usb-host: Adapt to USB phy-nop RESET line changes
In reply to Roger QuadrosThe USB phy-nop nop driver expects the RESET line information to be sent as a GPIO number via platform data. Adapt to that.
--- arch/arm/mach-omap2/usb-host.c | 11 +---------- 1 files changed, 1 insertions(+), 10 deletions(-)
arch/arm/mach-omap2/usb-host.c +1 -10
@@ -460,8 +460,7 @@ int usbhs_init_phys(struct usbhs_phy_data *phy, int num_phys)memset (&nop_pdata,0 ,sizeof (nop_pdata));if (gpio_is_valid (phy->vcc_gpio)) nop_pdata.needs_vcc = true; -if (gpio_is_valid (phy->reset_gpio)) - nop_pdata.needs_reset = true; + nop_pdata.gpio_reset = phy->reset_gpio; nop_pdata.type =USB_PHY_TYPE_USB2 ;/* create a NOP PHY device */
@@ -483,14 +482,6 @@ int usbhs_init_phys(struct usbhs_phy_data *phy, int num_phys)usb_bind_phy ("ehci-omap.0" , phy->port -1 , phy_id); -/* Do we need RESET regulator ? */ -if (gpio_is_valid (phy->reset_gpio)) { -scnprintf (rail_name,MAX_STR , -"hsusb%d_reset" , phy->port); -usbhs_add_regulator (rail_name, phy_id,"reset" , - phy->reset_gpio,1 ); - } -/* Do we need VCC regulator ? */ if (gpio_is_valid (phy->vcc_gpio)) {scnprintf (rail_name,MAX_STR ,"hsusb%d_vcc" , phy->port);
Signature · 1 line
1.7.4.1
PATCH v2 5/9 ARM: dts: omap3-beagle: Use reset-gpios for hsusb2_reset
In reply to Roger QuadrosWe no longer need to model the RESET line as a regulator since the USB phy-nop driver accepts "reset-gpios" property.
--- arch/arm/boot/dts/omap3-beagle.dts | 13 +------------ 1 files changed, 1 insertions(+), 12 deletions(-)
arch/arm/boot/dts/omap3-beagle.dts +1 -12
@@ -44,17 +44,6 @@ }; }; - /* HS USB Port 2 RESET */ - hsusb2_reset: hsusb2_reset_reg { - compatible = "regulator-fixed"; - regulator-name = "hsusb2_reset"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - gpio = <&gpio5 19 0>; /* gpio_147 */ - startup-delay-us = <70000>; - enable-active-high; - }; - /* HS USB Port 2 Power */ hsusb2_power: hsusb2_power_reg { compatible = "regulator-fixed";
@@ -68,7 +57,7 @@ /* HS USB Host PHY on PORT 2 */ hsusb2_phy: hsusb2_phy { compatible = "usb-nop-xceiv"; - reset-supply = <&hsusb2_reset>; + reset-gpios = <&gpio5 19 GPIO_ACTIVE_LOW>; /* gpio_147 */ vcc-supply = <&hsusb2_power>; };
Signature · 1 line
1.7.4.1
PATCH v2 6/9 ARM: dts: omap4-panda: Use reset-gpios for hsusb1_reset
In reply to Roger QuadrosWe no longer need to model the RESET line as a regulator since the USB phy-nop driver accepts "reset-gpios" property.
--- arch/arm/boot/dts/omap4-panda-common.dtsi | 18 +----------------- 1 files changed, 1 insertions(+), 17 deletions(-)
arch/arm/boot/dts/omap4-panda-common.dtsi +1 -17
@@ -60,22 +60,6 @@ "AFMR", "Line In"; }; - /* - * Temp hack: Need to be replaced with the proper gpio-controlled - * reset driver as soon it will be merged. - * http://thread.gmane.org/gmane.linux.drivers.devicetree/36830 - */ - /* HS USB Port 1 RESET */ - hsusb1_reset: hsusb1_reset_reg { - compatible = "regulator-fixed"; - regulator-name = "hsusb1_reset"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - gpio = <&gpio2 30 0>; /* gpio_62 */ - startup-delay-us = <70000>; - enable-active-high; - }; - /* HS USB Port 1 Power */ hsusb1_power: hsusb1_power_reg { compatible = "regulator-fixed";
@@ -97,7 +81,7 @@ /* HS USB Host PHY on PORT 1 */ hsusb1_phy: hsusb1_phy { compatible = "usb-nop-xceiv"; - reset-supply = <&hsusb1_reset>; + reset-gpios = <&gpio2 30 GPIO_ACTIVE_LOW>; /* gpio_62 */ vcc-supply = <&hsusb1_power>; /** * FIXME:
Signature · 1 line
1.7.4.1
PATCH v2 7/9 ARM: dts: omap5-uevm: Use reset-gpios for hsusb2_reset
In reply to Roger QuadrosWe no longer need to model the RESET line as a regulator since the USB phy-nop driver accepts "reset-gpios" property.
--- arch/arm/boot/dts/omap5-uevm.dts | 13 +------------ 1 files changed, 1 insertions(+), 12 deletions(-)
arch/arm/boot/dts/omap5-uevm.dts +1 -12
@@ -27,21 +27,10 @@ regulator-max-microvolt = <3000000>; }; - /* HS USB Port 2 RESET */ - hsusb2_reset: hsusb2_reset_reg { - compatible = "regulator-fixed"; - regulator-name = "hsusb2_reset"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - gpio = <&gpio3 16 GPIO_ACTIVE_HIGH>; /* gpio3_80 HUB_NRESET */ - startup-delay-us = <70000>; - enable-active-high; - }; - /* HS USB Host PHY on PORT 2 */ hsusb2_phy: hsusb2_phy { compatible = "usb-nop-xceiv"; - reset-supply = <&hsusb2_reset>; + reset-gpios = <&gpio3 16 GPIO_ACTIVE_LOW>; /* gpio3_80 HUB_NRESET */ /** * FIXME * Put the right clock phandle here when available
Signature · 1 line
1.7.4.1
PATCH v2 8/9 ARM: dts: omap3-beagle: Make USB host pin naming consistent
In reply to Roger QuadrosUse a common naming scheme "mode0name.modename flags" for the USB host pins to be consistent.
--- arch/arm/boot/dts/omap3-beagle.dts | 24 ++++++++++++------------ 1 files changed, 12 insertions(+), 12 deletions(-)
arch/arm/boot/dts/omap3-beagle.dts +12 -12
@@ -90,18 +90,18 @@ hsusbb2_pins: pinmux_hsusbb2_pins { pinctrl-single,pins = < - 0x5c0 (PIN_OUTPUT | MUX_MODE3) /* usbb2_ulpitll_clk.usbb1_ulpiphy_clk */ - 0x5c2 (PIN_OUTPUT | MUX_MODE3) /* usbb2_ulpitll_clk.usbb1_ulpiphy_stp */ - 0x5c4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /* usbb2_ulpitll_clk.usbb1_ulpiphy_dir */ - 0x5c6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /* usbb2_ulpitll_clk.usbb1_ulpiphy_nxt */ - 0x5c8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /* usbb2_ulpitll_clk.usbb1_ulpiphy_dat0 */ - 0x5cA (PIN_INPUT_PULLDOWN | MUX_MODE3) /* usbb2_ulpitll_clk.usbb1_ulpiphy_dat1 */ - 0x1a4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /* usbb2_ulpitll_clk.usbb1_ulpiphy_dat2 */ - 0x1a6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /* usbb2_ulpitll_clk.usbb1_ulpiphy_dat3 */ - 0x1a8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /* usbb2_ulpitll_clk.usbb1_ulpiphy_dat4 */ - 0x1aa (PIN_INPUT_PULLDOWN | MUX_MODE3) /* usbb2_ulpitll_clk.usbb1_ulpiphy_dat5 */ - 0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE3) /* usbb2_ulpitll_clk.usbb1_ulpiphy_dat6 */ - 0x1ae (PIN_INPUT_PULLDOWN | MUX_MODE3) /* usbb2_ulpitll_clk.usbb1_ulpiphy_dat7 */ + 0x5c0 (PIN_OUTPUT | MUX_MODE3) /* etk_d10.hsusb2_clk */ + 0x5c2 (PIN_OUTPUT | MUX_MODE3) /* etk_d11.hsusb2_stp */ + 0x5c4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /* etk_d12.hsusb2_dir */ + 0x5c6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /* etk_d13.hsusb2_nxt */ + 0x5c8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /* etk_d14.hsusb2_data0 */ + 0x5cA (PIN_INPUT_PULLDOWN | MUX_MODE3) /* etk_d15.hsusb2_data1 */ + 0x1a4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /* mcspi1_cs3.hsusb2_data2 */ + 0x1a6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /* mcspi2_clk.hsusb2_data7 */ + 0x1a8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /* mcspi2_simo.hsusb2_data4 */ + 0x1aa (PIN_INPUT_PULLDOWN | MUX_MODE3) /* mcspi2_somi.hsusb2_data5 */ + 0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE3) /* mcspi2_cs0.hsusb2_data6 */ + 0x1ae (PIN_INPUT_PULLDOWN | MUX_MODE3) /* mcspi2_cs1.hsusb2_data3 */ >; };
Signature · 1 line
1.7.4.1
PATCH v2 9/9 ARM: dts: omap3-beagle-xm: Add USB Host support
In reply to Roger QuadrosProvide RESET GPIO and Power regulator for the USB PHY, the USB Host port mode and the PHY device for the controller. Also provide pin multiplexer information for USB host pins.
We also relocate omap3_pmx_core pin definations so that they are close to omap3_pmx_wkup pin definations.
--- arch/arm/boot/dts/omap3-beagle-xm.dts | 65 ++++++++++++++++++++++++++++----- 1 files changed, 56 insertions(+), 9 deletions(-)
arch/arm/boot/dts/omap3-beagle-xm.dts +56 -9
@@ -69,6 +69,23 @@ }; }; + + /* HS USB Port 2 Power */ + hsusb2_power: hsusb2_power_reg { + compatible = "regulator-fixed"; + regulator-name = "hsusb2_vbus"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + gpio = <&twl_gpio 18 0>; /* GPIO LEDA */ + startup-delay-us = <70000>; + }; + + /* HS USB Host PHY on PORT 2 */ + hsusb2_phy: hsusb2_phy { + compatible = "usb-nop-xceiv"; + reset-gpios = <&gpio5 19 GPIO_ACTIVE_LOW>; /* gpio_147 */ + vcc-supply = <&hsusb2_power>; + }; }; &omap3_pmx_wkup {
@@ -79,6 +96,37 @@ }; }; +&omap3_pmx_core { + pinctrl-names = "default"; + pinctrl-0 = < + &hsusbb2_pins + >; + + uart3_pins: pinmux_uart3_pins { + pinctrl-single,pins = < + 0x16e (PIN_INPUT | PIN_OFF_WAKEUPENABLE | MUX_MODE0) /* uart3_rx_irrx.uart3_rx_irrx */ + 0x170 (PIN_OUTPUT | MUX_MODE0) /* uart3_tx_irtx.uart3_tx_irtx OUTPUT | MODE0 */ + >; + }; + + hsusbb2_pins: pinmux_hsusbb2_pins { + pinctrl-single,pins = < + 0x5c0 (PIN_OUTPUT | MUX_MODE3) /* etk_d10.hsusb2_clk */ + 0x5c2 (PIN_OUTPUT | MUX_MODE3) /* etk_d11.hsusb2_stp */ + 0x5c4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /* etk_d12.hsusb2_dir */ + 0x5c6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /* etk_d13.hsusb2_nxt */ + 0x5c8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /* etk_d14.hsusb2_data0 */ + 0x5cA (PIN_INPUT_PULLDOWN | MUX_MODE3) /* etk_d15.hsusb2_data1 */ + 0x1a4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /* mcspi1_cs3.hsusb2_data2 */ + 0x1a6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /* mcspi2_clk.hsusb2_data7 */ + 0x1a8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /* mcspi2_simo.hsusb2_data4 */ + 0x1aa (PIN_INPUT_PULLDOWN | MUX_MODE3) /* mcspi2_somi.hsusb2_data5 */ + 0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE3) /* mcspi2_cs0.hsusb2_data6 */ + 0x1ae (PIN_INPUT_PULLDOWN | MUX_MODE3) /* mcspi2_cs1.hsusb2_data3 */ + >; + }; +}; + &i2c1 { clock-frequency = <2600000>;
@@ -148,15 +196,6 @@ power = <50>; }; -&omap3_pmx_core { - uart3_pins: pinmux_uart3_pins { - pinctrl-single,pins = < - 0x16e (PIN_INPUT | PIN_OFF_WAKEUPENABLE | MUX_MODE0) /* uart3_rx_irrx.uart3_rx_irrx */ - 0x170 (PIN_OUTPUT | MUX_MODE0) /* uart3_tx_irtx.uart3_tx_irtx OUTPUT | MODE0 */ - >; - }; -}; - &uart3 { pinctrl-names = "default"; pinctrl-0 = <&uart3_pins>;
@@ -166,3 +205,11 @@ pinctrl-names = "default"; pinctrl-0 = <&gpio1_pins>; }; + +&usbhshost { + port2-mode = "ehci-phy"; +}; + +&usbhsehci { + phys = <0 &hsusb2_phy>; +};
Signature · 1 line
1.7.4.1
v2 cover USB: phy: phy-nop: Manage RESET GPIO in the driver
In reply to Roger QuadrosHi Roger,
Quoted 37 lines · Roger Quadros
Hi,
Modelling the RESET line as a regulator supply wasn't a good idea as it abuses the regulator framework and makes adaptation code/data more complex.
Instead, manage the RESET gpio line directly in the driver.
This also makes us easy to migrate to a dedicated GPIO RESET controller whenever it becomes available. As of now, it doesn't seem to be making it into 3.12.
*NOTE:* As there are changes to platform data, Patch 1 needs to be shared between the arm-soc tree and usb tree.
Patch 1 is available at repo
git://github.com/rogerq/linux.git
in branch
phy-reset-commonPatch 2 contains the phy-nop driver changes
Patches 3 and 4 adapt legacy boot code to the phy-nop driver changes. Patches 5, 6 and 7 adapt DT data to the binding changes. Patch 8 is cleanup of omap3-beagle DT.
Patch 9 adds USB host support to omap3-beagle-xm using the new binding.Patches are based on v3.11-rc5.
Tested leacy boot on omap3-beagle and omap3-beagle-xm Tested DT boot on omap3-beagle, omap3-beagle-xm and omap4-panda-esv2:
- Added RESET GPIO polarity feature
- Changed togpio_set_value_cansleep()cheers,
-roger
Quoted 12 lines
---
Roger Quadros (9):
usb: phy: nop: Addgpio_resetto platform data
usb: phy: nop: Don't use regulator framework for RESET line
ARM: OMAP2+: omap-usb-host: Get rid ofplatform_datafrom struct
usbhs_phy_data
ARM: OMAP2+: usb-host: Adapt to USB phy-nop RESET line changes
ARM: dts: omap3-beagle: Use reset-gpios forhsusb2_reset
ARM: dts: omap4-panda: Use reset-gpios forhsusb1_reset
ARM: dts: omap5-uevm: Use reset-gpios forhsusb2_reset
ARM: dts: omap3-beagle: Make USB host pin naming consistent
ARM: dts: omap3-beagle-xm: Add USB Host support
The 5 DTS patches looks good to me, and I can apply them, but you need to be sure that the driver will be merged for 3.12 as well.
Regards,
Benoit
v2 cover USB: phy: phy-nop: Manage RESET GPIO in the driver
Hi Felipe,
Quoted 53 lines · Benoit Cousson
Hi Roger,
Quoted 37 lines · Roger Quadros
Hi,
Modelling the RESET line as a regulator supply wasn't a good idea as it abuses the regulator framework and makes adaptation code/data more complex.
Instead, manage the RESET gpio line directly in the driver.
This also makes us easy to migrate to a dedicated GPIO RESET controller whenever it becomes available. As of now, it doesn't seem to be making it into 3.12.
*NOTE:* As there are changes to platform data, Patch 1 needs to be shared between the arm-soc tree and usb tree.
Patch 1 is available at repo
git://github.com/rogerq/linux.git
in branch
phy-reset-commonPatch 2 contains the phy-nop driver changes
Patches 3 and 4 adapt legacy boot code to the phy-nop driver changes. Patches 5, 6 and 7 adapt DT data to the binding changes. Patch 8 is cleanup of omap3-beagle DT.
Patch 9 adds USB host support to omap3-beagle-xm using the new binding.Patches are based on v3.11-rc5.
Tested leacy boot on omap3-beagle and omap3-beagle-xm Tested DT boot on omap3-beagle, omap3-beagle-xm and omap4-panda-esv2:
- Added RESET GPIO polarity feature
- Changed togpio_set_value_cansleep()cheers,
-rogerQuoted 12 lines
---
Roger Quadros (9):
usb: phy: nop: Addgpio_resetto platform data
usb: phy: nop: Don't use regulator framework for RESET line
ARM: OMAP2+: omap-usb-host: Get rid ofplatform_datafrom struct
usbhs_phy_data
ARM: OMAP2+: usb-host: Adapt to USB phy-nop RESET line changes
ARM: dts: omap3-beagle: Use reset-gpios forhsusb2_reset
ARM: dts: omap4-panda: Use reset-gpios forhsusb1_reset
ARM: dts: omap5-uevm: Use reset-gpios forhsusb2_reset
ARM: dts: omap3-beagle: Make USB host pin naming consistent
ARM: dts: omap3-beagle-xm: Add USB Host support
Quoted 1 line
The 5 DTS patches looks good to me, and I can apply them, but you need to be sure that the driver will be merged for 3.12 as well.
Could you please let us know if this series can make it to 3.12? Thanks.
cheers,
-roger