Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1397937 > unrolled thread
| Started by | Felipe Balbi <balbi@kernel.org> |
|---|---|
| First post | 2016-05-10 12:00 +0200 |
| Last post | 2016-05-10 12:10 +0200 |
| Articles | 6 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH v7 3/5] usb: dwc3: omap: Don't set POWERPRESENT Felipe Balbi <balbi@kernel.org> - 2016-05-10 12:00 +0200
Re: [PATCH v7 3/5] usb: dwc3: omap: Don't set POWERPRESENT Felipe Balbi <balbi@kernel.org> - 2016-05-10 12:10 +0200
Re: [PATCH v7 3/5] usb: dwc3: omap: Don't set POWERPRESENT Roger Quadros <rogerq@ti.com> - 2016-05-10 12:30 +0200
Re: [PATCH v7 3/5] usb: dwc3: omap: Don't set POWERPRESENT Felipe Balbi <balbi@kernel.org> - 2016-05-10 12:40 +0200
Re: [PATCH v7 3/5] usb: dwc3: omap: Don't set POWERPRESENT Roger Quadros <rogerq@ti.com> - 2016-05-10 12:30 +0200
Re: [PATCH v7 3/5] usb: dwc3: omap: Don't set POWERPRESENT Roger Quadros <rogerq@ti.com> - 2016-05-10 12:10 +0200
| From | Felipe Balbi <balbi@kernel.org> |
|---|---|
| Date | 2016-05-10 12:00 +0200 |
| Subject | Re: [PATCH v7 3/5] usb: dwc3: omap: Don't set POWERPRESENT |
| Message-ID | <rxcCq-8kL-87@gated-at.bofh.it> |
[Multipart message — attachments visible in raw view] — view raw
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 ? -- balbi
[toc] | [next] | [standalone]
| From | Felipe Balbi <balbi@kernel.org> |
|---|---|
| Date | 2016-05-10 12:10 +0200 |
| Message-ID | <rxcM2-qT-21@gated-at.bofh.it> |
| In reply to | #1397937 |
[Multipart message — attachments visible in raw view] — view raw
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 :-) -- balbi
[toc] | [prev] | [next] | [standalone]
| From | Roger Quadros <rogerq@ti.com> |
|---|---|
| Date | 2016-05-10 12:30 +0200 |
| Message-ID | <rxd5o-FH-15@gated-at.bofh.it> |
| In reply to | #1397949 |
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
[toc] | [prev] | [next] | [standalone]
| From | Felipe Balbi <balbi@kernel.org> |
|---|---|
| Date | 2016-05-10 12:40 +0200 |
| Message-ID | <rxdf4-KB-19@gated-at.bofh.it> |
| In reply to | #1397964 |
[Multipart message — attachments visible in raw view] — view raw
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) -- balbi
[toc] | [prev] | [next] | [standalone]
| From | Roger Quadros <rogerq@ti.com> |
|---|---|
| Date | 2016-05-10 12:30 +0200 |
| Message-ID | <rxd5p-FH-29@gated-at.bofh.it> |
| In reply to | #1397949 |
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
[toc] | [prev] | [next] | [standalone]
| From | Roger Quadros <rogerq@ti.com> |
|---|---|
| Date | 2016-05-10 12:10 +0200 |
| Message-ID | <rxcM2-qT-23@gated-at.bofh.it> |
| In reply to | #1397937 |
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
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web