Hi,
Although full speed gadget mode isn't really broken on my boards,
we are not strictly following the dwc3 manual with regards to
the DCFG.DEVSPD configuration. This series fixes that.
cheers,
-roger
Roger Quadros (2):
usb: dwc3: gadget: Fix full speed mode
usb: dwc3: gadget: Clean up DCFG/DSTS FULLSPEED macro
drivers/usb/dwc3/core.h | 8 ++++----
drivers/usb/dwc3/gadget.c | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
--
2.7.4
DCFG.DEVSPD == 0x3 is not valid and we need to set
DCFG.DEVSPD to 0x1 for full speed mode.
Signed-off-by: Roger Quadros <[email protected]>
---
drivers/usb/dwc3/gadget.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 1dfa56a5f..797e013 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1597,7 +1597,7 @@ static int __dwc3_gadget_start(struct dwc3 *dwc)
reg |= DWC3_DCFG_LOWSPEED;
break;
case USB_SPEED_FULL:
- reg |= DWC3_DCFG_FULLSPEED1;
+ reg |= DWC3_DCFG_FULLSPEED2;
break;
case USB_SPEED_HIGH:
reg |= DWC3_DCFG_HIGHSPEED;
--
2.7.4
DCFG/DSTS.FULLSPEED can be either 0x1 or 0x3.
Let's call 0x1 as DCFG/DSTS_FULLSPEED1 and 0x3 as DCFG/DSTS_FULLSPEED3.
Signed-off-by: Roger Quadros <[email protected]>
---
drivers/usb/dwc3/core.h | 8 ++++----
drivers/usb/dwc3/gadget.c | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 6b60e42..e2cd6c0 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -303,9 +303,9 @@
#define DWC3_DCFG_SUPERSPEED_PLUS (5 << 0) /* DWC_usb31 only */
#define DWC3_DCFG_SUPERSPEED (4 << 0)
#define DWC3_DCFG_HIGHSPEED (0 << 0)
-#define DWC3_DCFG_FULLSPEED2 (1 << 0)
+#define DWC3_DCFG_FULLSPEED1 (1 << 0)
#define DWC3_DCFG_LOWSPEED (2 << 0)
-#define DWC3_DCFG_FULLSPEED1 (3 << 0)
+#define DWC3_DCFG_FULLSPEED3 (3 << 0)
#define DWC3_DCFG_NUMP_SHIFT 17
#define DWC3_DCFG_NUMP(n) (((n) >> DWC3_DCFG_NUMP_SHIFT) & 0x1f)
@@ -397,9 +397,9 @@
#define DWC3_DSTS_SUPERSPEED_PLUS (5 << 0) /* DWC_usb31 only */
#define DWC3_DSTS_SUPERSPEED (4 << 0)
#define DWC3_DSTS_HIGHSPEED (0 << 0)
-#define DWC3_DSTS_FULLSPEED2 (1 << 0)
+#define DWC3_DSTS_FULLSPEED1 (1 << 0)
#define DWC3_DSTS_LOWSPEED (2 << 0)
-#define DWC3_DSTS_FULLSPEED1 (3 << 0)
+#define DWC3_DSTS_FULLSPEED3 (3 << 0)
/* Device Generic Command Register */
#define DWC3_DGCMD_SET_LMP 0x01
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 797e013..3256abb 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1597,7 +1597,7 @@ static int __dwc3_gadget_start(struct dwc3 *dwc)
reg |= DWC3_DCFG_LOWSPEED;
break;
case USB_SPEED_FULL:
- reg |= DWC3_DCFG_FULLSPEED2;
+ reg |= DWC3_DCFG_FULLSPEED1;
break;
case USB_SPEED_HIGH:
reg |= DWC3_DCFG_HIGHSPEED;
@@ -2456,7 +2456,7 @@ static void dwc3_gadget_conndone_interrupt(struct dwc3 *dwc)
dwc->gadget.ep0->maxpacket = 64;
dwc->gadget.speed = USB_SPEED_HIGH;
break;
- case DWC3_DSTS_FULLSPEED2:
+ case DWC3_DSTS_FULLSPEED3:
case DWC3_DSTS_FULLSPEED1:
dwc3_gadget_ep0_desc.wMaxPacketSize = cpu_to_le16(64);
dwc->gadget.ep0->maxpacket = 64;
--
2.7.4
Hi,
Roger Quadros <[email protected]> writes:
> DCFG.DEVSPD == 0x3 is not valid and we need to set
> DCFG.DEVSPD to 0x1 for full speed mode.
seems like it has been made invalid somewhere between 1.73a and
2.60a. Can you figure it out from Documentation why and when it was made
invalid? We might need revision checks here.
--
balbi
Hi,
On 29/11/16 13:51, Felipe Balbi wrote:
>
> Hi,
>
> Roger Quadros <[email protected]> writes:
>> DCFG.DEVSPD == 0x3 is not valid and we need to set
>> DCFG.DEVSPD to 0x1 for full speed mode.
>
> seems like it has been made invalid somewhere between 1.73a and
> 2.60a. Can you figure it out from Documentation why and when it was made
> invalid? We might need revision checks here.
>
I'll try to dig out more.
For now from TI DRA7 TRM, 0x3 seems to be FS for serial PHY. (see below)
Do you know if any platform uses that mode?
If we need to support both Full speed modes, how do we specify which
mode we want to set? Some DT parameter?
"0x0: High Speed (HS): 480 Mbit/s - Supported from all
USB controllers
0x1: Full Speed (FS): 12 Mbit/s - Supported from all USB
controllers
0x3: Full Speed (FS): 12 Mbit/s on serial PHY: NOT
SUPPORTED
0x4: Super Speed (SS): 5 Gbit/s - Supported only from
USB1 controller
0x2: Low Speed (LS): 1.5 Mbit/s on serial PHY: NOT
SUPPORTED"
cheers,
-roger
Hi,
On 29/11/16 14:28, Roger Quadros wrote:
> Hi,
>
> On 29/11/16 13:51, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Roger Quadros <[email protected]> writes:
>>> DCFG.DEVSPD == 0x3 is not valid and we need to set
>>> DCFG.DEVSPD to 0x1 for full speed mode.
>>
>> seems like it has been made invalid somewhere between 1.73a and
>> 2.60a. Can you figure it out from Documentation why and when it was made
>> invalid? We might need revision checks here.
>>
>
> I'll try to dig out more.
I couldn't figure out more information on this. The changelogs in the TRMs
don't capture this change and I don't have access to all TRM versions
so I can't say which version it got changed and why.
Can we please involve someone from Synopsis to provide this information?
Thanks.
cheers,
-roger
Hi,
Roger Quadros <[email protected]> writes:
>>> Roger Quadros <[email protected]> writes:
>>>> DCFG.DEVSPD == 0x3 is not valid and we need to set
>>>> DCFG.DEVSPD to 0x1 for full speed mode.
>>>
>>> seems like it has been made invalid somewhere between 1.73a and
>>> 2.60a. Can you figure it out from Documentation why and when it was made
>>> invalid? We might need revision checks here.
>>>
>>
>> I'll try to dig out more.
>
> I couldn't figure out more information on this. The changelogs in the TRMs
> don't capture this change and I don't have access to all TRM versions
> so I can't say which version it got changed and why.
>
> Can we please involve someone from Synopsis to provide this information?
> Thanks.
John, could you help us with this query? We'd like to understand why one
of the FULLSPEED modes got removed. Do we need a revision check or can
we assume that the other mode was never supposed to be used?
thanks
--
balbi
On 12/7/2016 4:44 AM, Felipe Balbi wrote:
>
> Hi,
>
> Roger Quadros <[email protected]> writes:
>>>> Roger Quadros <[email protected]> writes:
>>>>> DCFG.DEVSPD == 0x3 is not valid and we need to set
>>>>> DCFG.DEVSPD to 0x1 for full speed mode.
>>>>
>>>> seems like it has been made invalid somewhere between 1.73a and
>>>> 2.60a. Can you figure it out from Documentation why and when it was made
>>>> invalid? We might need revision checks here.
>>>>
>>>
>>> I'll try to dig out more.
>>
>> I couldn't figure out more information on this. The changelogs in the TRMs
>> don't capture this change and I don't have access to all TRM versions
>> so I can't say which version it got changed and why.
>>
>> Can we please involve someone from Synopsis to provide this information?
>> Thanks.
>
> John, could you help us with this query? We'd like to understand why one
> of the FULLSPEED modes got removed. Do we need a revision check or can
> we assume that the other mode was never supposed to be used?
>
Full speed is 0x1. 0x3 may still work due to how the bits are
checked. But it definitely should be 0x1.
I'm not sure if it was 0x3 before. I still need to confirm whether
that was the case or not and if so why.
Regards,
John
On 12/7/2016 7:06 PM, John Youn wrote:
> On 12/7/2016 4:44 AM, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Roger Quadros <[email protected]> writes:
>>>>> Roger Quadros <[email protected]> writes:
>>>>>> DCFG.DEVSPD == 0x3 is not valid and we need to set
>>>>>> DCFG.DEVSPD to 0x1 for full speed mode.
>>>>>
>>>>> seems like it has been made invalid somewhere between 1.73a and
>>>>> 2.60a. Can you figure it out from Documentation why and when it was made
>>>>> invalid? We might need revision checks here.
>>>>>
>>>>
>>>> I'll try to dig out more.
>>>
>>> I couldn't figure out more information on this. The changelogs in the TRMs
>>> don't capture this change and I don't have access to all TRM versions
>>> so I can't say which version it got changed and why.
>>>
>>> Can we please involve someone from Synopsis to provide this information?
>>> Thanks.
>>
>> John, could you help us with this query? We'd like to understand why one
>> of the FULLSPEED modes got removed. Do we need a revision check or can
>> we assume that the other mode was never supposed to be used?
>>
>
> Full speed is 0x1. 0x3 may still work due to how the bits are
> checked. But it definitely should be 0x1.
>
> I'm not sure if it was 0x3 before. I still need to confirm whether
> that was the case or not and if so why.
>
Hi Felipe,
According to the old databook, 0x3 was for FS in 48MHz mode for 1.1
transceiver, which was never supported. UTMI FS was still specified as
0x1 in those old databooks.
Regards,
John
Hi,
John Youn <[email protected]> writes:
> On 12/7/2016 7:06 PM, John Youn wrote:
>> On 12/7/2016 4:44 AM, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> Roger Quadros <[email protected]> writes:
>>>>>> Roger Quadros <[email protected]> writes:
>>>>>>> DCFG.DEVSPD == 0x3 is not valid and we need to set
>>>>>>> DCFG.DEVSPD to 0x1 for full speed mode.
>>>>>>
>>>>>> seems like it has been made invalid somewhere between 1.73a and
>>>>>> 2.60a. Can you figure it out from Documentation why and when it was made
>>>>>> invalid? We might need revision checks here.
>>>>>>
>>>>>
>>>>> I'll try to dig out more.
>>>>
>>>> I couldn't figure out more information on this. The changelogs in the TRMs
>>>> don't capture this change and I don't have access to all TRM versions
>>>> so I can't say which version it got changed and why.
>>>>
>>>> Can we please involve someone from Synopsis to provide this information?
>>>> Thanks.
>>>
>>> John, could you help us with this query? We'd like to understand why one
>>> of the FULLSPEED modes got removed. Do we need a revision check or can
>>> we assume that the other mode was never supposed to be used?
>>>
>>
>> Full speed is 0x1. 0x3 may still work due to how the bits are
>> checked. But it definitely should be 0x1.
>>
>> I'm not sure if it was 0x3 before. I still need to confirm whether
>> that was the case or not and if so why.
>>
>
> Hi Felipe,
>
> According to the old databook, 0x3 was for FS in 48MHz mode for 1.1
> transceiver, which was never supported. UTMI FS was still specified as
> 0x1 in those old databooks.
Thank you, so Roger we should actually completely remove FULLSPEED
setting of 0x3. Can you update the patch accordingly?
--
balbi