| Message ID | 1438697169-32359-1-git-send-email-kishon@ti.com |
|---|---|
| State | Under Review, archived |
| Headers | show |
Hi, On Tue, Aug 04, 2015 at 07:36:09PM +0530, Kishon Vijay Abraham I wrote: > Deprecate using phy-omap-control driver to write to the mailbox register > and start using *syscon* framework to do the same. > > Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> > --- > Documentation/devicetree/bindings/usb/omap-usb.txt | 7 +- > drivers/usb/musb/omap2430.c | 115 ++++++++++++++++---- > 2 files changed, 99 insertions(+), 23 deletions(-) > > diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt > index 38d9bb8..c001306 100644 > --- a/Documentation/devicetree/bindings/usb/omap-usb.txt > +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt > @@ -20,10 +20,15 @@ OMAP MUSB GLUE > - phy-names : the names of the PHY corresponding to the PHYs present in the > *phy* phandle. > > -Optional properties: > +Optional Properties: > +Deprecated properties: > - ctrl-module : phandle of the control module this glue uses to write to > mailbox > > +Recommended properies: > + - syscon-otghs : phandle/offset pair. Phandle to the system control module and the > + register offset of the mailbox. > + > SOC specific device node entry > usb_otg_hs: usb_otg_hs@4a0ab000 { > compatible = "ti,omap4-musb"; > diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c > index 70f2b8a..a03cf1e 100644 > --- a/drivers/usb/musb/omap2430.c > +++ b/drivers/usb/musb/omap2430.c > @@ -39,16 +39,27 @@ > #include <linux/usb/musb-omap.h> > #include <linux/phy/omap_control_phy.h> > #include <linux/of_platform.h> > +#include <linux/regmap.h> > +#include <linux/mfd/syscon.h> > > #include "musb_core.h" > #include "omap2430.h" > > +#define OMAP2430_MUSB_MODE_MASK 0x1f > +#define OMAP2430_MUSB_AVALID BIT(0) > +#define OMAP2430_MUSB_BVALID BIT(1) > +#define OMAP2430_MUSB_VBUSVALID BIT(2) > +#define OMAP2430_MUSB_SESSEND BIT(3) > +#define OMAP2430_MUSB_IDDIG BIT(4) > + > struct omap2430_glue { > struct device *dev; > struct platform_device *musb; > enum omap_musb_vbus_id_status status; > struct work_struct omap_musb_mailbox_work; > struct device *control_otghs; > + struct regmap *syscon_otghs; /* ctrl. reg. acces */ > + unsigned int otghs_reg; /* otghs reg. index within syscon */ > }; > #define glue_to_musb(g) platform_get_drvdata(g->musb) > > @@ -253,6 +264,44 @@ void omap_musb_mailbox(enum omap_musb_vbus_id_status status) > } > EXPORT_SYMBOL_GPL(omap_musb_mailbox); > > +static void omap2430_musb_set_usbmode(struct omap2430_glue *glue, > + enum omap_control_usb_mode mode) > +{ > + u32 val; > + int ret; > + if (!glue->syscon_otghs) { omap_control_usb_set_mode(glue->control_otghs, mode); return; } switch (mode) { case USB_MODE_HOST: val = OMAP2430_MUSB_AVALID | OMAP2430_MUSB_VBUSVALID; break; case USB_MODE_DEVICE: val = OMAP2430_MUSB_IDDIG | OMAP2430_MUSB_AVALID | OMAP2430_MUSB_VBUSVALID; break; case USB_MODE_DISCONNECT: val = OMAP2430_MUSB_IDDIG | OMAP2430_MUSB_SESSEND; break; default: dev_dbg(glue->dev, "Invalid mode\n"); dev_err(glue->dev, "Failed to set mode to %d\n", mode); } ret = regmap_update_bits(glue->syscon_otghs, glue->otghs_reg, OMAP2430_MUSB_MODE_MASK, val); if (ret < 0) dev_err(glue->dev, "Failed to update regmap\n"); other than that, looks fine.
* Kishon Vijay Abraham I <kishon@ti.com> [150804 07:11]: > Deprecate using phy-omap-control driver to write to the mailbox register > and start using *syscon* framework to do the same. .. > @@ -512,6 +558,40 @@ static const struct musb_platform_ops omap2430_ops = { > > static u64 omap2430_dmamask = DMA_BIT_MASK(32); > > +static int omap2430_get_sys_ctrl(struct omap2430_glue *glue, > + struct device_node *np) > +{ > + struct device_node *control_node; > + struct platform_device *control_pdev; > + > + glue->syscon_otghs = syscon_regmap_lookup_by_phandle(np, > + "syscon-otghs"); > + if (IS_ERR(glue->syscon_otghs)) { > + dev_dbg(glue->dev, "can't get syscon, using control device\n"); > + glue->syscon_otghs = NULL; > + > + control_node = of_parse_phandle(np, "ctrl-module", 0); > + if (control_node) { > + control_pdev = of_find_device_by_node(control_node); > + if (!control_pdev) { > + dev_err(glue->dev, > + "Failed to get control device\n"); > + return -EINVAL; > + } > + glue->control_otghs = &control_pdev->dev; > + } > + } else { > + if (of_property_read_u32_index(np, "syscon-otghs", 1, > + &glue->otghs_reg)) { > + dev_err(glue->dev, > + "couldn't get otghs reg. offset\n"); > + return -EINVAL; > + } > + } > + > + return 0; > +} We don't have syscon-otghs and to me it seems we need a PHY driver as I pointed out at: https://lkml.org/lkml/2015/6/24/231 So let's sort that issue first. It also seems this just completely breaks the MUSB support? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Tuesday 04 August 2015 09:28 PM, Felipe Balbi wrote: > Hi, > > On Tue, Aug 04, 2015 at 07:36:09PM +0530, Kishon Vijay Abraham I wrote: >> Deprecate using phy-omap-control driver to write to the mailbox register >> and start using *syscon* framework to do the same. >> >> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> >> --- >> Documentation/devicetree/bindings/usb/omap-usb.txt | 7 +- >> drivers/usb/musb/omap2430.c | 115 ++++++++++++++++---- >> 2 files changed, 99 insertions(+), 23 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt >> index 38d9bb8..c001306 100644 >> --- a/Documentation/devicetree/bindings/usb/omap-usb.txt >> +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt >> @@ -20,10 +20,15 @@ OMAP MUSB GLUE >> - phy-names : the names of the PHY corresponding to the PHYs present in the >> *phy* phandle. >> >> -Optional properties: >> +Optional Properties: >> +Deprecated properties: >> - ctrl-module : phandle of the control module this glue uses to write to >> mailbox >> >> +Recommended properies: >> + - syscon-otghs : phandle/offset pair. Phandle to the system control module and the >> + register offset of the mailbox. >> + >> SOC specific device node entry >> usb_otg_hs: usb_otg_hs@4a0ab000 { >> compatible = "ti,omap4-musb"; >> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c >> index 70f2b8a..a03cf1e 100644 >> --- a/drivers/usb/musb/omap2430.c >> +++ b/drivers/usb/musb/omap2430.c >> @@ -39,16 +39,27 @@ >> #include <linux/usb/musb-omap.h> >> #include <linux/phy/omap_control_phy.h> >> #include <linux/of_platform.h> >> +#include <linux/regmap.h> >> +#include <linux/mfd/syscon.h> >> >> #include "musb_core.h" >> #include "omap2430.h" >> >> +#define OMAP2430_MUSB_MODE_MASK 0x1f >> +#define OMAP2430_MUSB_AVALID BIT(0) >> +#define OMAP2430_MUSB_BVALID BIT(1) >> +#define OMAP2430_MUSB_VBUSVALID BIT(2) >> +#define OMAP2430_MUSB_SESSEND BIT(3) >> +#define OMAP2430_MUSB_IDDIG BIT(4) >> + >> struct omap2430_glue { >> struct device *dev; >> struct platform_device *musb; >> enum omap_musb_vbus_id_status status; >> struct work_struct omap_musb_mailbox_work; >> struct device *control_otghs; >> + struct regmap *syscon_otghs; /* ctrl. reg. acces */ >> + unsigned int otghs_reg; /* otghs reg. index within syscon */ >> }; >> #define glue_to_musb(g) platform_get_drvdata(g->musb) >> >> @@ -253,6 +264,44 @@ void omap_musb_mailbox(enum omap_musb_vbus_id_status status) >> } >> EXPORT_SYMBOL_GPL(omap_musb_mailbox); >> >> +static void omap2430_musb_set_usbmode(struct omap2430_glue *glue, >> + enum omap_control_usb_mode mode) >> +{ >> + u32 val; >> + int ret; >> + > > if (!glue->syscon_otghs) { > omap_control_usb_set_mode(glue->control_otghs, mode); > return; > } > > switch (mode) { > case USB_MODE_HOST: > val = OMAP2430_MUSB_AVALID | OMAP2430_MUSB_VBUSVALID; > break; > case USB_MODE_DEVICE: > val = OMAP2430_MUSB_IDDIG | OMAP2430_MUSB_AVALID | > OMAP2430_MUSB_VBUSVALID; > break; > case USB_MODE_DISCONNECT: > val = OMAP2430_MUSB_IDDIG | OMAP2430_MUSB_SESSEND; > break; > default: > dev_dbg(glue->dev, "Invalid mode\n"); > dev_err(glue->dev, "Failed to set mode to %d\n", mode); Don't we have to return here? Maybe we should set IDDIG and SESSEND (the same value as USB_MODE_DISCONNECT). That seems to be the reset value as well. > } > > ret = regmap_update_bits(glue->syscon_otghs, > glue->otghs_reg, > OMAP2430_MUSB_MODE_MASK, val); > if (ret < 0) > dev_err(glue->dev, "Failed to update regmap\n"); Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Tony, On Wednesday 05 August 2015 01:31 PM, Tony Lindgren wrote: > * Kishon Vijay Abraham I <kishon@ti.com> [150804 07:11]: >> Deprecate using phy-omap-control driver to write to the mailbox register >> and start using *syscon* framework to do the same. > .. >> @@ -512,6 +558,40 @@ static const struct musb_platform_ops omap2430_ops = { >> >> static u64 omap2430_dmamask = DMA_BIT_MASK(32); >> >> +static int omap2430_get_sys_ctrl(struct omap2430_glue *glue, >> + struct device_node *np) >> +{ >> + struct device_node *control_node; >> + struct platform_device *control_pdev; >> + >> + glue->syscon_otghs = syscon_regmap_lookup_by_phandle(np, >> + "syscon-otghs"); >> + if (IS_ERR(glue->syscon_otghs)) { >> + dev_dbg(glue->dev, "can't get syscon, using control device\n"); >> + glue->syscon_otghs = NULL; >> + >> + control_node = of_parse_phandle(np, "ctrl-module", 0); >> + if (control_node) { >> + control_pdev = of_find_device_by_node(control_node); >> + if (!control_pdev) { >> + dev_err(glue->dev, >> + "Failed to get control device\n"); >> + return -EINVAL; >> + } >> + glue->control_otghs = &control_pdev->dev; >> + } >> + } else { >> + if (of_property_read_u32_index(np, "syscon-otghs", 1, >> + &glue->otghs_reg)) { >> + dev_err(glue->dev, >> + "couldn't get otghs reg. offset\n"); >> + return -EINVAL; >> + } >> + } >> + >> + return 0; >> +} > > We don't have syscon-otghs and to me it seems we need a PHY driver > as I pointed out at: If *syscon-otghs* is not present, then it'll fall-back to using the *ctrl-module*. > > https://lkml.org/lkml/2015/6/24/231 Maybe I should have explained this in the previous thread. The *otghs* register that we are trying to access here does _not_ belong to the PHY. It acts as mailbox register from MUSB glue (TI integration layer) to MUSB core. That's why it's programmed in the TI glue layer (omap2430.c). Even when we were using the older API [omap_control_usb_set_mode()], we first call omap_musb_mailbox from the PHY drivers (phy-twl4030-usb.c, phy-twl6030-usb.c) and then omap_musb_mailbox in the TI glue writes to the control module instead of PHY drivers directly calling omap_control_usb_set_mode(). > > So let's sort that issue first. It also seems this just completely > breaks the MUSB support? Why do you think so? If *syscon-otghs* is not present in dt, then it'll fall-back to using the *ctrl-module* and everything should work seamlessly. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Kishon Vijay Abraham I <kishon@ti.com> [150805 07:10]: > On Wednesday 05 August 2015 01:31 PM, Tony Lindgren wrote: > > > > We don't have syscon-otghs and to me it seems we need a PHY driver > > as I pointed out at: > > If *syscon-otghs* is not present, then it'll fall-back to using the *ctrl-module*. OK great. > > > > https://lkml.org/lkml/2015/6/24/231 > > Maybe I should have explained this in the previous thread. The *otghs* register > that we are trying to access here does _not_ belong to the PHY. It acts as > mailbox register from MUSB glue (TI integration layer) to MUSB core. That's why > it's programmed in the TI glue layer (omap2430.c). > > Even when we were using the older API [omap_control_usb_set_mode()], we first > call omap_musb_mailbox from the PHY drivers (phy-twl4030-usb.c, > phy-twl6030-usb.c) and then omap_musb_mailbox in the TI glue writes to the > control module instead of PHY drivers directly calling omap_control_usb_set_mode(). Hmm looking at "Table 18-204. CONTROL_USBOTGHS_CONTROL" it seems to mention "transceiver" for quite a few bitfields :) Probably what that register does is control a PHY over ULPI. So from Linux kernel point of view we're best off treating it as a PHY. It seems it should have a minimal PHY driver similar to what we have for dm816x control module in drivers/phy/phy-dm816x-usb.c. For reference, here is the register bitfields pasted from 4460 TRM: Table 18-204. CONTROL_USBOTGHS_CONTROL, p3972 Physical Address 0x4A00 233C BIT NAME DESCIPTION 8 DISCHRGVBUS ... OTG transceiver does (not) discharge VBUS ... 7 CHRGVBUS ... OTG transceiver does (not) charge VBUS ... 6 IDPULLUP ... OTG transceiver does (not) drive VBUS ... 4 IDDIG ... OTG transceiver does (not) apply a pullup to ID ... 3 SESSEND ... VBUS voltage is above/below VB_SESS_END ... 2 VBUSVALID ... VBUS is above the threshold ... 1 BVALID ... VBUS voltage is above/below VB_SESS_VLD ... 0 AVALID ... BUS voltage is above/below VA_SESS_VLD ... So how about just adding ONTROL_USBOTGHS_CONTROL support to the existing drivers/phy/phy-omap-usb2.c instead? It seems that it should allow us to completely get rid of the custom mailbox stuff for MUSB 2430 support? > > So let's sort that issue first. It also seems this just completely > > breaks the MUSB support? > > Why do you think so? If *syscon-otghs* is not present in dt, then it'll > fall-back to using the *ctrl-module* and everything should work seamlessly. OK that's good to hear. IMO drivers/phy/phy-omap4.c or similar should manage the syscon-otghs syscon register, not MUSB driver. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Thursday 06 August 2015 02:17 PM, Tony Lindgren wrote: > * Kishon Vijay Abraham I <kishon@ti.com> [150805 07:10]: >> On Wednesday 05 August 2015 01:31 PM, Tony Lindgren wrote: >>> >>> We don't have syscon-otghs and to me it seems we need a PHY driver >>> as I pointed out at: >> >> If *syscon-otghs* is not present, then it'll fall-back to using the *ctrl-module*. > > OK great. > >>> >>> https://lkml.org/lkml/2015/6/24/231 >> >> Maybe I should have explained this in the previous thread. The *otghs* register >> that we are trying to access here does _not_ belong to the PHY. It acts as >> mailbox register from MUSB glue (TI integration layer) to MUSB core. That's why >> it's programmed in the TI glue layer (omap2430.c). >> >> Even when we were using the older API [omap_control_usb_set_mode()], we first >> call omap_musb_mailbox from the PHY drivers (phy-twl4030-usb.c, >> phy-twl6030-usb.c) and then omap_musb_mailbox in the TI glue writes to the >> control module instead of PHY drivers directly calling omap_control_usb_set_mode(). > > Hmm looking at "Table 18-204. CONTROL_USBOTGHS_CONTROL" it seems to mention > "transceiver" for quite a few bitfields :) Probably what that register does > is control a PHY over ULPI. OMAP4 uses UTMI PHY and it uses CONTROL_USBOTGHS_CONTROL too. > > So from Linux kernel point of view we're best off treating it as a PHY. > It seems it should have a minimal PHY driver similar to what we have for > dm816x control module in drivers/phy/phy-dm816x-usb.c. hmm.. IMHO CONTROL_USBOTGHS_CONTROL register belongs to the TI MUSB glue and should be programmed in omap2430.c. It's better to get the opinion of Felipe here. Felipe? > > For reference, here is the register bitfields pasted from 4460 TRM: > > Table 18-204. CONTROL_USBOTGHS_CONTROL, p3972 > Physical Address 0x4A00 233C > > BIT NAME DESCIPTION > 8 DISCHRGVBUS ... OTG transceiver does (not) discharge VBUS ... > 7 CHRGVBUS ... OTG transceiver does (not) charge VBUS ... > 6 IDPULLUP ... OTG transceiver does (not) drive VBUS ... > 4 IDDIG ... OTG transceiver does (not) apply a pullup to ID ... > 3 SESSEND ... VBUS voltage is above/below VB_SESS_END ... > 2 VBUSVALID ... VBUS is above the threshold ... > 1 BVALID ... VBUS voltage is above/below VB_SESS_VLD ... > 0 AVALID ... BUS voltage is above/below VA_SESS_VLD ... > > So how about just adding ONTROL_USBOTGHS_CONTROL support to the existing > drivers/phy/phy-omap-usb2.c instead? It seems that it should allow us > to completely get rid of the custom mailbox stuff for MUSB 2430 support? Not in phy-omap-usb2.c. It's the UTMI PHY driver and is not used by OMAP3 based boards (uses twl4030 ULPI PHY). CONTROL_USBOTGHS_CONTROL has to be programmed for OMAP3 also. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Kishon Vijay Abraham I <kishon@ti.com> [150819 23:38]: > Hi, > > On Thursday 06 August 2015 02:17 PM, Tony Lindgren wrote: > > * Kishon Vijay Abraham I <kishon@ti.com> [150805 07:10]: > >> On Wednesday 05 August 2015 01:31 PM, Tony Lindgren wrote: > >>> > >>> We don't have syscon-otghs and to me it seems we need a PHY driver > >>> as I pointed out at: > >> > >> If *syscon-otghs* is not present, then it'll fall-back to using the *ctrl-module*. > > > > OK great. > > > >>> > >>> https://lkml.org/lkml/2015/6/24/231 > >> > >> Maybe I should have explained this in the previous thread. The *otghs* register > >> that we are trying to access here does _not_ belong to the PHY. It acts as > >> mailbox register from MUSB glue (TI integration layer) to MUSB core. That's why > >> it's programmed in the TI glue layer (omap2430.c). > >> > >> Even when we were using the older API [omap_control_usb_set_mode()], we first > >> call omap_musb_mailbox from the PHY drivers (phy-twl4030-usb.c, > >> phy-twl6030-usb.c) and then omap_musb_mailbox in the TI glue writes to the > >> control module instead of PHY drivers directly calling omap_control_usb_set_mode(). > > > > Hmm looking at "Table 18-204. CONTROL_USBOTGHS_CONTROL" it seems to mention > > "transceiver" for quite a few bitfields :) Probably what that register does > > is control a PHY over ULPI. > > OMAP4 uses UTMI PHY and it uses CONTROL_USBOTGHS_CONTROL too. So can't we make the phy-omap-usb2.c driver the onlly user of this register then and get rid of the mailbox stuff? I think the phy framework can handle everything now? > > So from Linux kernel point of view we're best off treating it as a PHY. > > It seems it should have a minimal PHY driver similar to what we have for > > dm816x control module in drivers/phy/phy-dm816x-usb.c. > > hmm.. IMHO CONTROL_USBOTGHS_CONTROL register belongs to the TI MUSB glue and > should be programmed in omap2430.c. It's better to get the opinion of Felipe > here. Felipe? > > > > For reference, here is the register bitfields pasted from 4460 TRM: > > > > Table 18-204. CONTROL_USBOTGHS_CONTROL, p3972 > > Physical Address 0x4A00 233C > > > > BIT NAME DESCIPTION > > 8 DISCHRGVBUS ... OTG transceiver does (not) discharge VBUS ... > > 7 CHRGVBUS ... OTG transceiver does (not) charge VBUS ... > > 6 IDPULLUP ... OTG transceiver does (not) drive VBUS ... > > 4 IDDIG ... OTG transceiver does (not) apply a pullup to ID ... > > 3 SESSEND ... VBUS voltage is above/below VB_SESS_END ... > > 2 VBUSVALID ... VBUS is above the threshold ... > > 1 BVALID ... VBUS voltage is above/below VB_SESS_VLD ... > > 0 AVALID ... BUS voltage is above/below VA_SESS_VLD ... > > > > So how about just adding ONTROL_USBOTGHS_CONTROL support to the existing > > drivers/phy/phy-omap-usb2.c instead? It seems that it should allow us > > to completely get rid of the custom mailbox stuff for MUSB 2430 support? > > Not in phy-omap-usb2.c. It's the UTMI PHY driver and is not used by OMAP3 based > boards (uses twl4030 ULPI PHY). CONTROL_USBOTGHS_CONTROL has to be programmed > for OMAP3 also. Hmm I don't think omap3 uses that register? There's no ti,control-phy anything in the omap3 dts files? And no USBOTGHS_CONTROL in the TRM? Or am I missing something here? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt index 38d9bb8..c001306 100644 --- a/Documentation/devicetree/bindings/usb/omap-usb.txt +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt @@ -20,10 +20,15 @@ OMAP MUSB GLUE - phy-names : the names of the PHY corresponding to the PHYs present in the *phy* phandle. -Optional properties: +Optional Properties: +Deprecated properties: - ctrl-module : phandle of the control module this glue uses to write to mailbox +Recommended properies: + - syscon-otghs : phandle/offset pair. Phandle to the system control module and the + register offset of the mailbox. + SOC specific device node entry usb_otg_hs: usb_otg_hs@4a0ab000 { compatible = "ti,omap4-musb"; diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index 70f2b8a..a03cf1e 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -39,16 +39,27 @@ #include <linux/usb/musb-omap.h> #include <linux/phy/omap_control_phy.h> #include <linux/of_platform.h> +#include <linux/regmap.h> +#include <linux/mfd/syscon.h> #include "musb_core.h" #include "omap2430.h" +#define OMAP2430_MUSB_MODE_MASK 0x1f +#define OMAP2430_MUSB_AVALID BIT(0) +#define OMAP2430_MUSB_BVALID BIT(1) +#define OMAP2430_MUSB_VBUSVALID BIT(2) +#define OMAP2430_MUSB_SESSEND BIT(3) +#define OMAP2430_MUSB_IDDIG BIT(4) + struct omap2430_glue { struct device *dev; struct platform_device *musb; enum omap_musb_vbus_id_status status; struct work_struct omap_musb_mailbox_work; struct device *control_otghs; + struct regmap *syscon_otghs; /* ctrl. reg. acces */ + unsigned int otghs_reg; /* otghs reg. index within syscon */ }; #define glue_to_musb(g) platform_get_drvdata(g->musb) @@ -253,6 +264,44 @@ void omap_musb_mailbox(enum omap_musb_vbus_id_status status) } EXPORT_SYMBOL_GPL(omap_musb_mailbox); +static void omap2430_musb_set_usbmode(struct omap2430_glue *glue, + enum omap_control_usb_mode mode) +{ + u32 val; + int ret; + + if (glue->syscon_otghs) { + switch (mode) { + case USB_MODE_HOST: + val = OMAP2430_MUSB_AVALID | OMAP2430_MUSB_VBUSVALID; + break; + case USB_MODE_DEVICE: + val = OMAP2430_MUSB_IDDIG | OMAP2430_MUSB_AVALID | + OMAP2430_MUSB_VBUSVALID; + break; + case USB_MODE_DISCONNECT: + val = OMAP2430_MUSB_IDDIG | OMAP2430_MUSB_SESSEND; + break; + default: + dev_dbg(glue->dev, "Invalid mode\n"); + goto err_regmap_update; + } + + ret = regmap_update_bits(glue->syscon_otghs, + glue->otghs_reg, + OMAP2430_MUSB_MODE_MASK, val); + if (ret < 0) + goto err_regmap_update; + } else { + omap_control_usb_set_mode(glue->control_otghs, mode); + } + + return; + +err_regmap_update: + dev_err(glue->dev, "Failed to set mode to %d\n", mode); +} + static void omap_musb_set_mailbox(struct omap2430_glue *glue) { struct musb *musb = glue_to_musb(glue); @@ -270,8 +319,7 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue) musb->xceiv->last_event = USB_EVENT_ID; if (musb->gadget_driver) { pm_runtime_get_sync(dev); - omap_control_usb_set_mode(glue->control_otghs, - USB_MODE_HOST); + omap2430_musb_set_usbmode(glue, USB_MODE_HOST); omap2430_musb_set_vbus(musb, 1); } break; @@ -284,7 +332,7 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue) musb->xceiv->last_event = USB_EVENT_VBUS; if (musb->gadget_driver) pm_runtime_get_sync(dev); - omap_control_usb_set_mode(glue->control_otghs, USB_MODE_DEVICE); + omap2430_musb_set_usbmode(glue, USB_MODE_DEVICE); break; case OMAP_MUSB_ID_FLOAT: @@ -301,8 +349,7 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue) if (data->interface_type == MUSB_INTERFACE_UTMI) otg_set_vbus(musb->xceiv->otg, 0); - omap_control_usb_set_mode(glue->control_otghs, - USB_MODE_DISCONNECT); + omap2430_musb_set_usbmode(glue, USB_MODE_DISCONNECT); break; default: dev_dbg(dev, "ID float\n"); @@ -444,7 +491,7 @@ static void omap2430_musb_enable(struct musb *musb) switch (glue->status) { case OMAP_MUSB_ID_GROUND: - omap_control_usb_set_mode(glue->control_otghs, USB_MODE_HOST); + omap2430_musb_set_usbmode(glue, USB_MODE_HOST); if (data->interface_type != MUSB_INTERFACE_UTMI) break; devctl = musb_readb(musb->mregs, MUSB_DEVCTL); @@ -463,7 +510,7 @@ static void omap2430_musb_enable(struct musb *musb) break; case OMAP_MUSB_VBUS_VALID: - omap_control_usb_set_mode(glue->control_otghs, USB_MODE_DEVICE); + omap2430_musb_set_usbmode(glue, USB_MODE_DEVICE); break; default: @@ -477,8 +524,7 @@ static void omap2430_musb_disable(struct musb *musb) struct omap2430_glue *glue = dev_get_drvdata(dev->parent); if (glue->status != OMAP_MUSB_UNKNOWN) - omap_control_usb_set_mode(glue->control_otghs, - USB_MODE_DISCONNECT); + omap2430_musb_set_usbmode(glue, USB_MODE_DISCONNECT); } static int omap2430_musb_exit(struct musb *musb) @@ -512,6 +558,40 @@ static const struct musb_platform_ops omap2430_ops = { static u64 omap2430_dmamask = DMA_BIT_MASK(32); +static int omap2430_get_sys_ctrl(struct omap2430_glue *glue, + struct device_node *np) +{ + struct device_node *control_node; + struct platform_device *control_pdev; + + glue->syscon_otghs = syscon_regmap_lookup_by_phandle(np, + "syscon-otghs"); + if (IS_ERR(glue->syscon_otghs)) { + dev_dbg(glue->dev, "can't get syscon, using control device\n"); + glue->syscon_otghs = NULL; + + control_node = of_parse_phandle(np, "ctrl-module", 0); + if (control_node) { + control_pdev = of_find_device_by_node(control_node); + if (!control_pdev) { + dev_err(glue->dev, + "Failed to get control device\n"); + return -EINVAL; + } + glue->control_otghs = &control_pdev->dev; + } + } else { + if (of_property_read_u32_index(np, "syscon-otghs", 1, + &glue->otghs_reg)) { + dev_err(glue->dev, + "couldn't get otghs reg. offset\n"); + return -EINVAL; + } + } + + return 0; +} + static int omap2430_probe(struct platform_device *pdev) { struct resource musb_resources[3]; @@ -543,9 +623,6 @@ static int omap2430_probe(struct platform_device *pdev) glue->control_otghs = ERR_PTR(-ENODEV); if (np) { - struct device_node *control_node; - struct platform_device *control_pdev; - pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL); if (!pdata) goto err2; @@ -572,16 +649,10 @@ static int omap2430_probe(struct platform_device *pdev) pdata->board_data = data; pdata->config = config; - control_node = of_parse_phandle(np, "ctrl-module", 0); - if (control_node) { - control_pdev = of_find_device_by_node(control_node); - if (!control_pdev) { - dev_err(&pdev->dev, "Failed to get control device\n"); - ret = -EINVAL; - goto err2; - } - glue->control_otghs = &control_pdev->dev; - } + ret = omap2430_get_sys_ctrl(glue, np); + if (ret) + goto err2; + } pdata->platform_ops = &omap2430_ops;
Deprecate using phy-omap-control driver to write to the mailbox register and start using *syscon* framework to do the same. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> --- Documentation/devicetree/bindings/usb/omap-usb.txt | 7 +- drivers/usb/musb/omap2430.c | 115 ++++++++++++++++---- 2 files changed, 99 insertions(+), 23 deletions(-)