| Message ID | 1462873919-20532-4-git-send-email-rogerq@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi, Roger Quadros <rogerq@ti.com> writes: > TRM [1] recommends that POWERPRESENT bit must not be > set and left at it's default value of 0. > > [1] OMAP542x TRM - http://www.ti.com/lit/pdf/swpu249 > Section 23.11.4.5.1 Mailbox VBUS/ID Management > > "Because PIPE powerpresent has a different meaning in host and in device mode, > and because of the redundancy with the UTMI signals, the controller ORes > together the appropriate PIPE and UTMI inputs to create its internal > VBUS status. For that reason, it is recommended to leave field > USBOTGSS_UTMI_OTG_STATUS[9] POWERPRESENT at its default value (=0), and only to > fill in the USB2 VBUS status fields in the same register." > > Signed-off-by: Roger Quadros <rogerq@ti.com> to make sure we avoid regressions, do you mind sharing on which platforms you tested this patch ?
On 10/05/16 12:54, Felipe Balbi wrote: > > Hi, > > Roger Quadros <rogerq@ti.com> writes: >> TRM [1] recommends that POWERPRESENT bit must not be >> set and left at it's default value of 0. >> >> [1] OMAP542x TRM - http://www.ti.com/lit/pdf/swpu249 >> Section 23.11.4.5.1 Mailbox VBUS/ID Management >> >> "Because PIPE powerpresent has a different meaning in host and in device mode, >> and because of the redundancy with the UTMI signals, the controller ORes >> together the appropriate PIPE and UTMI inputs to create its internal >> VBUS status. For that reason, it is recommended to leave field >> USBOTGSS_UTMI_OTG_STATUS[9] POWERPRESENT at its default value (=0), and only to >> fill in the USB2 VBUS status fields in the same register." >> >> Signed-off-by: Roger Quadros <rogerq@ti.com> > > to make sure we avoid regressions, do you mind sharing on which > platforms you tested this patch ? > I tested this on omap5-uevm and dra7-evm. My am437x board stopped working so couldn't test on that one. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, Roger Quadros <rogerq@ti.com> writes: > On 10/05/16 12:54, Felipe Balbi wrote: >> >> Hi, >> >> Roger Quadros <rogerq@ti.com> writes: >>> TRM [1] recommends that POWERPRESENT bit must not be >>> set and left at it's default value of 0. >>> >>> [1] OMAP542x TRM - http://www.ti.com/lit/pdf/swpu249 >>> Section 23.11.4.5.1 Mailbox VBUS/ID Management >>> >>> "Because PIPE powerpresent has a different meaning in host and in device mode, >>> and because of the redundancy with the UTMI signals, the controller ORes >>> together the appropriate PIPE and UTMI inputs to create its internal >>> VBUS status. For that reason, it is recommended to leave field >>> USBOTGSS_UTMI_OTG_STATUS[9] POWERPRESENT at its default value (=0), and only to >>> fill in the USB2 VBUS status fields in the same register." >>> >>> Signed-off-by: Roger Quadros <rogerq@ti.com> >> >> to make sure we avoid regressions, do you mind sharing on which >> platforms you tested this patch ? >> > I tested this on omap5-uevm and dra7-evm. > My am437x board stopped working so couldn't test on that one. would you have a colleague or perhaps an automated test-farm which could run the test for you ? :-) I can take the patch, no problem, but if there are any regressions don't blame me :-)
On 10/05/16 13:04, Felipe Balbi wrote: > > Hi, > > Roger Quadros <rogerq@ti.com> writes: >> On 10/05/16 12:54, Felipe Balbi wrote: >>> >>> Hi, >>> >>> Roger Quadros <rogerq@ti.com> writes: >>>> TRM [1] recommends that POWERPRESENT bit must not be >>>> set and left at it's default value of 0. >>>> >>>> [1] OMAP542x TRM - http://www.ti.com/lit/pdf/swpu249 >>>> Section 23.11.4.5.1 Mailbox VBUS/ID Management >>>> >>>> "Because PIPE powerpresent has a different meaning in host and in device mode, >>>> and because of the redundancy with the UTMI signals, the controller ORes >>>> together the appropriate PIPE and UTMI inputs to create its internal >>>> VBUS status. For that reason, it is recommended to leave field >>>> USBOTGSS_UTMI_OTG_STATUS[9] POWERPRESENT at its default value (=0), and only to >>>> fill in the USB2 VBUS status fields in the same register." >>>> >>>> Signed-off-by: Roger Quadros <rogerq@ti.com> >>> >>> to make sure we avoid regressions, do you mind sharing on which >>> platforms you tested this patch ? >>> >> I tested this on omap5-uevm and dra7-evm. >> My am437x board stopped working so couldn't test on that one. > > would you have a colleague or perhaps an automated test-farm which could > run the test for you ? :-) > > I can take the patch, no problem, but if there are any regressions don't > blame me :-) > Don't worry, blame is on the TRM then :). cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10/05/16 13:04, Felipe Balbi wrote: > > Hi, > > Roger Quadros <rogerq@ti.com> writes: >> On 10/05/16 12:54, Felipe Balbi wrote: >>> >>> Hi, >>> >>> Roger Quadros <rogerq@ti.com> writes: >>>> TRM [1] recommends that POWERPRESENT bit must not be >>>> set and left at it's default value of 0. >>>> >>>> [1] OMAP542x TRM - http://www.ti.com/lit/pdf/swpu249 >>>> Section 23.11.4.5.1 Mailbox VBUS/ID Management >>>> >>>> "Because PIPE powerpresent has a different meaning in host and in device mode, >>>> and because of the redundancy with the UTMI signals, the controller ORes >>>> together the appropriate PIPE and UTMI inputs to create its internal >>>> VBUS status. For that reason, it is recommended to leave field >>>> USBOTGSS_UTMI_OTG_STATUS[9] POWERPRESENT at its default value (=0), and only to >>>> fill in the USB2 VBUS status fields in the same register." >>>> >>>> Signed-off-by: Roger Quadros <rogerq@ti.com> >>> >>> to make sure we avoid regressions, do you mind sharing on which >>> platforms you tested this patch ? >>> >> I tested this on omap5-uevm and dra7-evm. >> My am437x board stopped working so couldn't test on that one. > > would you have a colleague or perhaps an automated test-farm which could > run the test for you ? :-) Bin, do you mind testing this and giving your blessings please? cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, Roger Quadros <rogerq@ti.com> writes: > On 10/05/16 13:04, Felipe Balbi wrote: >> >> Hi, >> >> Roger Quadros <rogerq@ti.com> writes: >>> On 10/05/16 12:54, Felipe Balbi wrote: >>>> >>>> Hi, >>>> >>>> Roger Quadros <rogerq@ti.com> writes: >>>>> TRM [1] recommends that POWERPRESENT bit must not be >>>>> set and left at it's default value of 0. >>>>> >>>>> [1] OMAP542x TRM - http://www.ti.com/lit/pdf/swpu249 >>>>> Section 23.11.4.5.1 Mailbox VBUS/ID Management >>>>> >>>>> "Because PIPE powerpresent has a different meaning in host and in device mode, >>>>> and because of the redundancy with the UTMI signals, the controller ORes >>>>> together the appropriate PIPE and UTMI inputs to create its internal >>>>> VBUS status. For that reason, it is recommended to leave field >>>>> USBOTGSS_UTMI_OTG_STATUS[9] POWERPRESENT at its default value (=0), and only to >>>>> fill in the USB2 VBUS status fields in the same register." >>>>> >>>>> Signed-off-by: Roger Quadros <rogerq@ti.com> >>>> >>>> to make sure we avoid regressions, do you mind sharing on which >>>> platforms you tested this patch ? >>>> >>> I tested this on omap5-uevm and dra7-evm. >>> My am437x board stopped working so couldn't test on that one. >> >> would you have a colleague or perhaps an automated test-farm which could >> run the test for you ? :-) >> >> I can take the patch, no problem, but if there are any regressions don't >> blame me :-) >> > Don't worry, blame is on the TRM then :). alright then, so seems like v8 will be queued. Just remember we're pretty close to opening the merge window and I have already sent a pull request to Greg. On the bright side, your patches will sit in linux-next for quite some time :-) (well, until -rc1 is tagged)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c index a30944d..1f7259d 100644 --- a/drivers/usb/dwc3/dwc3-omap.c +++ b/drivers/usb/dwc3/dwc3-omap.c @@ -234,8 +234,7 @@ static void dwc3_omap_set_mailbox(struct dwc3_omap *omap, val &= ~(USBOTGSS_UTMI_OTG_CTRL_IDDIG | USBOTGSS_UTMI_OTG_CTRL_VBUSVALID | USBOTGSS_UTMI_OTG_CTRL_SESSEND); - val |= USBOTGSS_UTMI_OTG_CTRL_SESSVALID - | USBOTGSS_UTMI_OTG_CTRL_POWERPRESENT; + val |= USBOTGSS_UTMI_OTG_CTRL_SESSVALID; dwc3_omap_write_utmi_ctrl(omap, val); break; @@ -244,8 +243,7 @@ static void dwc3_omap_set_mailbox(struct dwc3_omap *omap, val &= ~USBOTGSS_UTMI_OTG_CTRL_SESSEND; val |= USBOTGSS_UTMI_OTG_CTRL_IDDIG | USBOTGSS_UTMI_OTG_CTRL_VBUSVALID - | USBOTGSS_UTMI_OTG_CTRL_SESSVALID - | USBOTGSS_UTMI_OTG_CTRL_POWERPRESENT; + | USBOTGSS_UTMI_OTG_CTRL_SESSVALID; dwc3_omap_write_utmi_ctrl(omap, val); break; @@ -256,8 +254,7 @@ static void dwc3_omap_set_mailbox(struct dwc3_omap *omap, case OMAP_DWC3_VBUS_OFF: val = dwc3_omap_read_utmi_ctrl(omap); val &= ~(USBOTGSS_UTMI_OTG_CTRL_SESSVALID - | USBOTGSS_UTMI_OTG_CTRL_VBUSVALID - | USBOTGSS_UTMI_OTG_CTRL_POWERPRESENT); + | USBOTGSS_UTMI_OTG_CTRL_VBUSVALID); val |= USBOTGSS_UTMI_OTG_CTRL_SESSEND | USBOTGSS_UTMI_OTG_CTRL_IDDIG; dwc3_omap_write_utmi_ctrl(omap, val);
TRM [1] recommends that POWERPRESENT bit must not be set and left at it's default value of 0. [1] OMAP542x TRM - http://www.ti.com/lit/pdf/swpu249 Section 23.11.4.5.1 Mailbox VBUS/ID Management "Because PIPE powerpresent has a different meaning in host and in device mode, and because of the redundancy with the UTMI signals, the controller ORes together the appropriate PIPE and UTMI inputs to create its internal VBUS status. For that reason, it is recommended to leave field USBOTGSS_UTMI_OTG_STATUS[9] POWERPRESENT at its default value (=0), and only to fill in the USB2 VBUS status fields in the same register." Signed-off-by: Roger Quadros <rogerq@ti.com> --- drivers/usb/dwc3/dwc3-omap.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-)