[U-Boot] [PATCH v3] drivers: usb: xhci-fsl: Implement Erratum A-010151 for FSL USB3 controller

[Marek Vasut]

On 09/15/2016 08:31 AM, Sriram Dash wrote:
>> From: Marek Vasut [mailto:marex at 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 at nxp.com>
>>> Signed-off-by: Rajesh Bhagat <rajesh.bhagat at 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?
> 
[...]


-- 
Best regards,
Marek Vasut