On 09/15/2016 08:31 AM, Sriram Dash wrote:
From: Marek Vasut [mailto:marex@denx.de] On 09/14/2016 07:15 AM, Sriram Dash wrote:
Currently the controller by default enables the Receive Detect feature in P3 mode in USB 3.0 PHY. However, USB 3.0 PHY does not reliably support receive detection in P3 mode. Enabling the USB3 controller to configure USB in P2 mode whenever the Receive Detect feature is required.
Signed-off-by: Sriram Dash sriram.dash@nxp.com Signed-off-by: Rajesh Bhagat rajesh.bhagat@nxp.com
Changes in v3:
- Fixing conflicts and repost
Changelog of this verbosity is completely useless.
I will take care the next time.
Changes in v2:
- Do Soc ver checking for applying erratum
drivers/usb/common/fsl-errata.c | 26 ++++++++++++++++++++++++++ drivers/usb/host/xhci-dwc3.c | 5 +++++ drivers/usb/host/xhci-fsl.c | 8 ++++++++ include/fsl_usb.h | 1 + include/linux/usb/dwc3.h | 2 ++ 5 files changed, 42 insertions(+)
diff --git a/drivers/usb/common/fsl-errata.c b/drivers/usb/common/fsl-errata.c index 183bf2b..f2bffba 100644 --- a/drivers/usb/common/fsl-errata.c +++ b/drivers/usb/common/fsl-errata.c @@ -190,4 +190,30 @@ bool has_erratum_a008751(void) return false; }
+bool has_erratum_a010151(void) +{
- u32 svr = get_svr();
- u32 soc = SVR_SOC_VER(svr);
- switch (soc) {
+#ifdef CONFIG_ARM64
- case SVR_LS2080A:
- case SVR_LS2085A:
- case SVR_LS1046A:
- case SVR_LS1012A:
return IS_SVR_REV(svr, 1, 0);- case SVR_LS1043A:
return IS_SVR_REV(svr, 1, 0) || IS_SVR_REV(svr, 1, 1); #endif+#ifdef CONFIG_LS102XA
- case SOC_VER_LS1020:
- case SOC_VER_LS1021:
- case SOC_VER_LS1022:
- case SOC_VER_SLS1020:
return IS_SVR_REV(svr, 2, 0);+#endif
- }
- return false;
+}
#endif diff --git a/drivers/usb/host/xhci-dwc3.c b/drivers/usb/host/xhci-dwc3.c index 33961cd..adbd9b5 100644 --- a/drivers/usb/host/xhci-dwc3.c +++ b/drivers/usb/host/xhci-dwc3.c @@ -97,3 +97,8 @@ void dwc3_set_fladj(struct dwc3 *dwc3_reg, u32 val) setbits_le32(&dwc3_reg->g_fladj, GFLADJ_30MHZ_REG_SEL | GFLADJ_30MHZ(val)); }
+void dwc3_set_rxdetect_power_mode(struct dwc3 *dwc3_reg, u32 val) {
- setbits_le32(&dwc3_reg->g_usb3pipectl[0], val);
So what would happen if I wanted to clean some bits instead ?
Setting the Rx detect in P2 mode is a one time job, and it does not change. Hence, IMO, the clear bit functionality is not required.
Until an SoC comes which has some bits set there and someone wants to clear them . At which point, this code will serve as a trap .
Why do you even need a dedicated function to write a single register?
The dwc3 phy for the specific controller version
This should be explicitly documented with a comment here.
does not reliably support Rx Detect in P3 mode(P3 is the default setting). So, this setting can be used by any other Soc, apart from freescale. IMO, this function is required.
So why won't such a system call single register write directly ?
+} diff --git a/drivers/usb/host/xhci-fsl.c b/drivers/usb/host/xhci-fsl.c index 0e3e056..9297ced 100644 --- a/drivers/usb/host/xhci-fsl.c +++ b/drivers/usb/host/xhci-fsl.c @@ -84,6 +84,14 @@ static int fsl_xhci_core_init(struct fsl_xhci *fsl_xhci) /* Change beat burst and outstanding pipelined transfers requests */ fsl_xhci_set_beat_burst_length(fsl_xhci->dwc3_reg);
- /*
* A-010151: USB controller to configure USB in P2 mode* whenever the Receive Detect feature is required*/- if (has_erratum_a010151())
dwc3_set_rxdetect_power_mode(fsl_xhci->dwc3_reg,DWC3_GUSB3PIPECTL_DISRXDETP3);Can't you parse these errata infos from device tree ?
Currently, all the freescale Socs using this controller are not using DM.
I am asking about device tree, not driver model. These two are orthogonal.
Shall we proceed with this solution currently, and then when the DM is supported by all Socs, modify the implementation according to device tree? What do you suggest?
[...]