Overview of stream transfer requirement:
 * A transfer will have a set of TRBs of the same stream ID.
 * A transfer is started with a stream ID in START_TRANSFER command.
 * A new stream will only start when the previous completes.

Overview of stream events:
 * A "prime" from host indicates that its endpoints are active
   (buffers prepared and ready to receive/transmit data). The controller
   automatically initiates stream if it sees this.
 * A "NoStream" rejection event indicates that the host isn't ready.
   Host will put the endpoint back to idle state. Device may need to
   reinitiate the stream to start transfer again.
 * A Stream Found event means host accepted device initiated stream.
   Nothing needs to be done from driver.

To initiate a stream, the driver will issue START_TRANSFER command with
a stream ID. To reinitiate the stream, the driver must issue
END_TRANSFER and restart the transfer with START_TRANSFER command with
the same stream ID.

This implementation handles device-initated streams (e.g. UASP driver).
It also handles some hosts' quirky behavior where they only prime each
endpoint once.
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

Don't prepare TRBs beyond a transfer. In DWC_usb32, its transfer burst
capability may try to read and use TRBs beyond the active transfer. For
other controllers, they don't process the next transfer TRBs until the
current transfer is completed. Explicitly prevent preparing TRBs ahead
for all controllers.
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

If a transfer is in-progress, any new request should not kick off
another transfer. The driver needs to wait for the current transfer to
complete before starting off the next transfer. Introduce a new flag
DWC3_EP_WAIT_TRANSFER_COMPLETE for this.
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

In DWC3, to prepare TRBs for streams, all the TRBs of a transfer will
use the same stream ID. To start a new stream, the driver needs to wait
for the current transfer to complete or ended (by END_TRANFER command).
As a result, inform the controller of the last TRB of a transfer so that
it knows when a transfer completes and start a new transfer of a new
stream.

Even though the transfer completion handling can be applied for other
non-isoc endpoints, only do it for streams due to its requirement.
It's better to keep the controller's TRB cache full than waiting for
transfer completion and starting a new transfer.
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

To switch from one stream to another, this requires the driver to start
a new transfer with a specific stream ID. For a transfer to complete,
the driver needs to indicate the last TRB of a transfer, and it needs to
enable XferComplete event to handle completed TRBs of a transfer. Let's
enable this event only for stream capable endpoints.
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

To prepare for handling of XferComplete event, let's refactor and split
up dwc3_gadget_endpoint_transfer_in_progress() to handle TRBs completion
for different events. The handling of TRBs completion will be the same,
but the status of XferComplete event is different than XferInProgress.
No functional change in this commit.
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

While handling TRBs completion, if a END_TRANSFER command isn't
completed, don't kick new transfer or issue END_TRANSFER command.
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

DWC_usb32 supports MDWIDTH value larger than 255 and up to 1023. The
field HWPARAMS6[9:8] stores the upper 2-bit values of the DWC_usb32's
MDWIDTH. Check that parameter and properly get the MDWIDTH for
DWC_usb32.
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

Synopsys introduces a new controller DWC_usb32. It supports dual-lane
and speed up to 20 Gbps, and the DWC3 driver will drive this controller.
Currently the driver uses a single field dwc->revision to ID both
DWC_usb3 and DWC_usb31 and their version number. This was sufficient for
two IPs, but this method doesn't work with additional IPs. As a result,
let's separate the dwc->revision field to 2 separate fields: ip and
revision. The ip field now stores the ID of the controller's IP while
the revision field stores the controller's version number.

This new scheme enforces DWC3 to compare the revision within the same IP
only. As a result, we must update all the revision check of the
controller to check its corresponding IP.

To help with this enforcement, we create a few macros to help with
the common version checks:

DWC3_IP_IS(IP)
DWC3_VER_IS(IP, VERSION)
DWC3_VER_IS_PRIOR(IP, VERSION)
DWC3_VER_IS_WITHIN(IP, LOWER_VERSION, UPPER_VERSION)
DWC3_VER_TYPE_IS_WITHIN(IP, VERSION,
			LOWER_VERSION_TYPE,
			UPPER_VERSION_TYPE)

The DWC_usb32 controller operates using the same programming model and
with very similar configurations as its previous controllers. Please
note that the various IP and revision checks in this patch match the
current checks for DWC_usb31 version 1.90a. Additional configurations
that are unique to DWC_usb32 are applied separately.
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

If there are still pending requests because no TRB was available,
prepare more when started requests are completed.

Introduce dwc3_gadget_ep_should_continue() to check for incomplete and
pending requests to resume updating new TRBs to the controller's TRB
cache.
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

If the driver issued START_TRANSFER and received a no-resource status,
then generally there are a few reasons for this:

1) The driver did not allocate resource for the endpoint during
power-on-reset initialization.

2) The transfer resource was reset. At this moment, we don't do this in
the driver, but it occurs when the driver issues START_CONFIG cmd to ep0
with resource index=2.

3) The driver issues the START_TRANSFER command to an already started
endpoint. Usually, this is because the END_TRANSFER command hasn't
completed yet.

Print out a warning to help debug this issue in the driver.
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

After a number of unsuccessful start isoc attempts due to bus-expiry
status, issue END_TRANSFER command and retry on the next XferNotReady
event.
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

As long as the START_TRANSFER command completes, it provides the
resource index of the endpoint. Use this when we need to issue
END_TRANSFER command to an isoc endpoint to retry with a new
XferNotReady event.
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

If dwc3 fails to issue START_TRANSFER/UPDATE_TRANSFER command, then we
should properly end an active transfer and give back all the started
requests. However if it's for an isoc endpoint, the failure maybe due to
bus-expiry status. In this case, don't give back the requests and wait
for the next retry.

Fixes: 72246da4 ("usb: Introduce DesignWare USB3 DRD Driver")
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

The flow from function dwc3_gadget_ep_dequeue() is not easy to follow.
Refactor it for easier read. No functional change in this commit.
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

Remove 2 unnecessary checks:
1) A request in the started_list must have its trb field set. So
checking for req->trb is unnecessary.

2) An endpoint must have started (and have not ended) for the request to
still be in the started_list. There's no point to check if the endpoint
is started. We had this check because previously the driver didn't
handle the endpoint's started/ended flags for END_TRANSFER command
properly. See commit 9f45581f ("usb: dwc3: gadget: early giveback
if End Transfer already completed").
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

If a request is dequeued, the transfer is cancelled. Give back all
the started requests.

In most scenarios, the function driver dequeues all requests of a
transfer when there's a failure. If the function driver follows this,
then it's fine. If not, then we'd be skipping TRBs at different points
within the dequeue and enqueue pointers, making dequeue/enqueue pointers
useless. To enforce and make sure that we're properly skipping TRBs,
cancel all the started requests and give back all the cancelled requests
to the function drivers.
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

DWC3 must not issue CLEAR_STALL command to control endpoints. The
controller automatically clears the STALL when it receives the SETUP
token. Also, when the driver receives ClearFeature(halt_ep), DWC3 must
stop any active transfer from the endpoint and give back all the
requests to the function drivers.

Fixes: 72246da4 ("usb: Introduce DesignWare USB3 DRD Driver")
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

A request may not be completed because not all the TRBs are prepared for
it. This happens when we run out of available TRBs. When some TRBs are
completed, the driver needs to prepare the rest of the TRBs for the
request. The check dwc3_gadget_ep_request_completed() shouldn't be
checking the amount of data received but rather the number of pending
TRBs. Revise this request completion check.

Cc: stable@vger.kernel.org
Fixes: e0c42ce5 ("usb: dwc3: gadget: simplify IOC handling")
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

The controller always supports link recovery for device in SS and SSP.
Remove the speed limit check. Also, when the device is in RESUME or
RESET state, it means the controller received the resume/reset request.
The driver must send the link recovery to acknowledge the request. They
are valid states for the driver to send link recovery.

Fixes: 72246da4 ("usb: Introduce DesignWare USB3 DRD Driver")
Fixes: ee5cd41c ("usb: dwc3: Update speed checks for SuperSpeedPlus")
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

Currently the calculation of max packet size limit for IN endpoints is
too restrictive. This prevents a matching of a capable hardware endpoint
during configuration. Below is the minimum recommended HW configuration
to support a particular endpoint setup from the databook:

For OUT endpoints, the databook recommended the minimum RxFIFO size to
be at least 3x MaxPacketSize + 3x setup packets size (8 bytes each) +
clock crossing margin (16 bytes).

For IN endpoints, the databook recommended the minimum TxFIFO size to be
at least 3x MaxPacketSize for endpoints that support burst. If the
endpoint doesn't support burst or when the device is operating in USB
2.0 mode, a minimum TxFIFO size of 2x MaxPacketSize is recommended.

Base on these recommendations, we can calculate the MaxPacketSize limit
of each endpoint. This patch revises the IN endpoint MaxPacketSize limit
and also sets the MaxPacketSize limit for OUT endpoints.

Reference: Databook 3.30a section 3.2.2 and 3.2.3
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

Change the macro name DWC3_GTXFIFOSIZ_TXFDEF to DWC3_GTXFIFOSIZ_TXFDEP
to match with the register name GTXFIFOSIZ.TXFDEP.

Fixes: 457e84b6 ("usb: dwc3: gadget: dynamically re-size TxFifos")
Fixes: 0cab8d26 ("usb: dwc3: Update DWC_usb31 GTXFIFOSIZ reg fields")
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

When skipping TRBs, we need to account for wrapping around the ring
buffer and not modifying some invalid TRBs. Without this fix, dwc3 won't
be able to check for available TRBs.

Cc: stable <stable@vger.kernel.org>
Fixes: 7746a8df ("usb: dwc3: gadget: extract dwc3_gadget_ep_skip_trbs()")
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

We track END_TRANSFER command completion. Don't clear transfer
started/ended flag prematurely. Otherwise, we'd run into the problem
with restarting transfer before END_TRANSFER command finishes.

Fixes: 6d8a0196 ("usb: dwc3: gadget: check for Missed Isoc from event status")
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

If scatter-gather operation is allowed, a large USB request is split
into multiple TRBs. For preparing TRBs for sg list, driver iterates
over the list and creates TRB for each sg and mark the chain bit to
false for the last sg. The current IOMMU driver is clubbing the list
of sgs which shares a page boundary into one and giving it to USB driver.
With this the number of sgs mapped it not equal to the the number of sgs
passed. Because of this USB driver is not marking the chain bit to false
since it couldn't iterate to the last sg. This patch addresses this issue
by marking the chain bit to false if it is the last mapped sg.

At a practical level, this patch resolves USB transfer stalls
seen with adb on dwc3 based db845c, pixel3 and other qcom
hardware after functionfs gadget added scatter-gather support
around v4.20.

Credit also to Anurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com>
who implemented a very similar fix to this issue.

Cc: Felipe Balbi <balbi@kernel.org>
Cc: Yang Fei <fei.yang@intel.com>
Cc: Thinh Nguyen <thinhn@synopsys.com>
Cc: Tejas Joglekar <tejas.joglekar@synopsys.com>
Cc: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Cc: Jack Pham <jackp@codeaurora.org>
Cc: Todd Kjos <tkjos@google.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Linux USB List <linux-usb@vger.kernel.org>
Cc: stable <stable@vger.kernel.org> #4.20+
Signed-off-by: NPratham Pratap <prathampratap@codeaurora.org>
[jstultz: Slight tweak to remove sg_is_last() usage, reworked
          commit message, minor comment tweak]
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Link: https://lore.kernel.org/r/20200302214443.55783-1-john.stultz@linaro.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The current code in dwc3_gadget_ep_reclaim_completed_trb() will
check for IOC/LST bit in the event->status and returns if
IOC/LST bit is set. This logic doesn't work if multiple TRBs
are queued per request and the IOC/LST bit is set on the last
TRB of that request.

Consider an example where a queued request has multiple queued
TRBs and IOC/LST bit is set only for the last TRB. In this case,
the core generates XferComplete/XferInProgress events only for
the last TRB (since IOC/LST are set only for the last TRB). As
per the logic in dwc3_gadget_ep_reclaim_completed_trb()
event->status is checked for IOC/LST bit and returns on the
first TRB. This leaves the remaining TRBs left unhandled.

Similarly, if the gadget function enqueues an unaligned request
with sglist already in it, it should fail the same way, since we
will append another TRB to something that already uses more than
one TRB.

To aviod this, this patch changes the code to check for IOC/LST
bits in TRB->ctrl instead.

At a practical level, this patch resolves USB transfer stalls seen
with adb on dwc3 based HiKey960 after functionfs gadget added
scatter-gather support around v4.20.

Cc: Felipe Balbi <balbi@kernel.org>
Cc: Yang Fei <fei.yang@intel.com>
Cc: Thinh Nguyen <thinhn@synopsys.com>
Cc: Tejas Joglekar <tejas.joglekar@synopsys.com>
Cc: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Cc: Jack Pham <jackp@codeaurora.org>
Cc: Todd Kjos <tkjos@google.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Linux USB List <linux-usb@vger.kernel.org>
Cc: stable <stable@vger.kernel.org>
Tested-by: NTejas Joglekar <tejas.joglekar@synopsys.com>
Reviewed-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NAnurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com>
[jstultz: forward ported to mainline, reworded commit log, reworked
 to only check trb->ctrl as suggested by Felipe]
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

We had a 100us delay to synchronize the END_TRANSFER command completion
before giving back requests to the function drivers. Now, the controller
driver can handle cancelled TRBs with the requests' cancelled_list and
it can also wait until the END_TRANSFER completion before starting new
transfers. Synchronization can simply base on the controller's command
completion interrupt. The 100us delay is no longer needed. Remove this
arbitrary delay.
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If the END_TRANSFER command hasn't completed yet, then don't send the
START_TRANSFER command. The controller may not be able to start if
that's the case. Some controller revisions depend on this. See
commit 76a638f8 ("usb: dwc3: gadget: wait for End Transfer to
complete"). Let's only send START_TRANSFER command after the
END_TRANSFER command had completed.

Fixes: 3aec9915 ("usb: dwc3: gadget: remove DWC3_EP_END_TRANSFER_PENDING")
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

While the END_TRANSFER command is sent but not completed, any request
dequeue during this time will cause the driver to issue the END_TRANSFER
command. The driver needs to submit the command only once to stop the
controller from processing further. The controller may take more time to
process the same command multiple times unnecessarily. Let's add a flag
DWC3_EP_END_TRANSFER_PENDING to check for this condition.

Fixes: 3aec9915 ("usb: dwc3: gadget: remove DWC3_EP_END_TRANSFER_PENDING")
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Send a no-action link state change request before the actual request
so DWC3 can send the same request whenever we call
dwc3_gadget_set_link_state().
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When DWC3 receives disconnect event, it needs to set the link state to
RX_Detect.

DWC_usb3 3.30a programming guide 4.1.7
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

DCTL.ULSTCHNGREQ is a write-only field. When doing a read-modify-write
to DCTL, the driver must make sure that there's no unintended link state
change request from whatever is read from DCTL.ULSTCHNGREQ. Set link
state change to no-action when the driver writes to DCTL.
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We can only check for IN direction if the request had completed. For OUT
direction, it's perfectly fine that the host can send less than the
setup length. Let's return true fall all cases of OUT direction.

Fixes: e0c42ce5 ("usb: dwc3: gadget: simplify IOC handling")
Cc: stable@vger.kernel.org
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Link: https://lore.kernel.org/r/ac5a3593a94fdaa3d92e6352356b5f7a01ccdc7c.1576291140.git.thinhn@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Normally the END_TRANSFER command completion handler will clear the
DWC3_EP_TRANSFER_STARTED flag. However, if the command was sent without
interrupt on completion, then the flag will not be cleared. Make sure to
clear the flag in this case.

Cc: stable@vger.kernel.org
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

This patch corrects the condition to kick the transfer without
giving back the requests when either request has remaining data
or when there are pending SGs. The && check was introduced during
spliting up the dwc3_gadget_ep_cleanup_completed_requests() function.

Fixes: f38e35dd ("usb: dwc3: gadget: split dwc3_gadget_ep_cleanup_completed_requests()")

Cc: stable@vger.kernel.org
Signed-off-by: NTejas Joglekar <joglekar@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

When disabling an endpoint which has cancelled requests, we should
make sure to giveback requests that are currently pending in the
cancelled list, otherwise we may fall into a situation where command
completion interrupt fires after endpoint has been disabled, therefore
causing a splat.

Fixes: fec9095b "usb: dwc3: gadget: remove wait_end_transfer"
Reported-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
Link: https://lore.kernel.org/r/20191031090713.1452818-1-felipe.balbi@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since commit 7723f4c5 ("driver core: platform: Add an error message to
platform_get_irq*()"), platform_get_irq() will call dev_err() itself on
failure, so there is no need for the driver to also do this.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
Link: https://lore.kernel.org/r/20191005210449.3926-4-hdegoede@redhat.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The dwc3 code to get the "peripheral" / "host" / "otg" IRQ first tries
platform_get_irq_byname() and then falls back to the IRQ at index 0 if
the platform_get_irq_byname().

In this case we do not want platform_get_irq_byname() to print an error
on failure, so switch to platform_get_irq_byname_optional() instead which
does not print an error.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205037Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
Link: https://lore.kernel.org/r/20191005210449.3926-3-hdegoede@redhat.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

While testing our host system using Microsoft's usb stack against our
gadget for various BESL values, we found an issue with their usb stack
when the recommended baseline BESL value is 0 (125us) or when the deep
BESL is 1 or less. The Windows host will issue a usb reset immediately
after it receives the extended BOS descriptor and the enumeration will
fail after a few attempts.

To keep compatibility with Microsoft's host usb stack, let's workaround
this issue by using the recommended baseline BESL of 1 (or 150us)
and clamp the deep BESL value within 2 to 15.

This was tested against Windows 10 build 18956.
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>

When operating with LPM signals, the controller asserts the deep
low-power signal (utmi_l1_suspend_n) to the phy when the BESL value of
the LPM token is equal to or greater than DCTL.HIRD_Thres[3:0] (and
with DCTL.HIRD_Thres[4] set). Otherwise, the shallow low-power signal
(utmi_sleep_n) is asserted. Set the recommended deep BESL equal to the
controller's DCTL.HIRD_Thres[3:0] setting, and set the baseline BESL
to 0 for the shallow low-power signal. This maximizes the opportunity
for L1 residency and optimizes power savings.
Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>