Some high speed mass storage devices fail to enumerate with following
error:

Cannot enable port %i.  Maybe the USB cable is bad?

This happens only when the device is plugged while the controller
is in hibernation state. After exiting hibernation, the controller
detects the device as a low speed device and fail to enumerate it.

Problem occurs only if HPRT0.PWR bit is programmed in a too short
delay after exiting hibernation. Dumping hprt register in
_dwc2_hcd_resume() directly after dwc2_exit_hibernation() shows that
HPRT0.LNSTS (D+/D- level) becomes valid approximately 2ms after
exiting hibernation.

Since dwc2_exit_hibernation() is called from atomic context, move the
delay out of this function.

Delay value is experimental and not mentioned in Synopsys
documentation. To be on the safe side 3ms delay is used.
Signed-off-by: NGregory Herrero <gregory.herrero@intel.com>
Signed-off-by: NMian Yousaf Kaukab <yousaf.kaukab@intel.com>
Tested-by: NRobert Baldyga <r.baldyga@samsung.com>
Tested-by: NDinh Nguyen <dinguyen@opensource.altera.com>
Tested-by: NJohn Youn <johnyoun@synopsys.com>
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

If an interrupt rises during hibernation process, dwc2 will assert
interrupt line to interrupt controller. If interrupt is level
sensitive, interrupt handler will be called in a loop because dwc2
will not be able to clear it while controller is hibernated.
Thus, clear all controller interrupts before hibernation entry.
Signed-off-by: NGregory Herrero <gregory.herrero@intel.com>
Signed-off-by: NMian Yousaf Kaukab <yousaf.kaukab@intel.com>
Tested-by: NRobert Baldyga <r.baldyga@samsung.com>
Tested-by: NDinh Nguyen <dinguyen@opensource.altera.com>
Tested-by: NJohn Youn <johnyoun@synopsys.com>
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Disable host interrupts before synchronising dwc2 irq.
So that interrupts are not generated once controller is stopped.
Signed-off-by: NGregory Herrero <gregory.herrero@intel.com>
Signed-off-by: NMian Yousaf Kaukab <yousaf.kaukab@intel.com>
Tested-by: NRobert Baldyga <r.baldyga@samsung.com>
Tested-by: NDinh Nguyen <dinguyen@opensource.altera.com>
Tested-by: NJohn Youn <johnyoun@synopsys.com>
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

GINTSTS.DisconnInt is host only interrupt and should be disable after
dwc2_disable_host_interrupts is called.
Signed-off-by: NMian Yousaf Kaukab <yousaf.kaukab@intel.com>
Tested-by: NRobert Baldyga <r.baldyga@samsung.com>
Tested-by: NDinh Nguyen <dinguyen@opensource.altera.com>
Tested-by: NJohn Youn <johnyoun@synopsys.com>
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

In case controller is asked to stop while devices are connected,
disconnect all devices and clean up before stopping.
Signed-off-by: NGregory Herrero <gregory.herrero@intel.com>
Signed-off-by: NMian Yousaf Kaukab <yousaf.kaukab@intel.com>
Tested-by: NRobert Baldyga <r.baldyga@samsung.com>
Tested-by: NDinh Nguyen <dinguyen@opensource.altera.com>
Tested-by: NJohn Youn <johnyoun@synopsys.com>
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Frame number is reset in hardware after exiting hibernation.
Thus, reset frame_number and ensure qh are queued with correct
sched_frame.

Otherwise, qh->sched_frame may be too high compared to
current frame number (which is 0). This can delay addition of qh in
the list of transfers until frame number reaches qh->sched_frame.
Signed-off-by: NGregory Herrero <gregory.herrero@intel.com>
Signed-off-by: NMian Yousaf Kaukab <yousaf.kaukab@intel.com>
Tested-by: NRobert Baldyga <r.baldyga@samsung.com>
Tested-by: NDinh Nguyen <dinguyen@opensource.altera.com>
Tested-by: NJohn Youn <johnyoun@synopsys.com>
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Port can be resumed in bus_resume callback.
In this case, there is no need to drive resume a second time
when hcd ask for it.
Signed-off-by: NGregory Herrero <gregory.herrero@intel.com>
Signed-off-by: NMian Yousaf Kaukab <yousaf.kaukab@intel.com>
Tested-by: NRobert Baldyga <r.baldyga@samsung.com>
Tested-by: NDinh Nguyen <dinguyen@opensource.altera.com>
Tested-by: NJohn Youn <johnyoun@synopsys.com>
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

If hibernation is supported, resume of devices will be handled in
bus_resume callback.
Signed-off-by: NGregory Herrero <gregory.herrero@intel.com>
Signed-off-by: NMian Yousaf Kaukab <yousaf.kaukab@intel.com>
Tested-by: NRobert Baldyga <r.baldyga@samsung.com>
Tested-by: NDinh Nguyen <dinguyen@opensource.altera.com>
Tested-by: NJohn Youn <johnyoun@synopsys.com>
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

When a device is disconnected, lx_state must not be changed since the
device may be disconnected whereas controller is still powered.
Signed-off-by: NGregory Herrero <gregory.herrero@intel.com>
Signed-off-by: NMian Yousaf Kaukab <yousaf.kaukab@intel.com>
Tested-by: NRobert Baldyga <r.baldyga@samsung.com>
Tested-by: NDinh Nguyen <dinguyen@opensource.altera.com>
Tested-by: NJohn Youn <johnyoun@synopsys.com>
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

During hcd initialization, hardware accessible flag and lx_state must
be reset to the working state since controller is powered at this stage.

Same logic applied for stop callback.
Signed-off-by: NGregory Herrero <gregory.herrero@intel.com>
Signed-off-by: NMian Yousaf Kaukab <yousaf.kaukab@intel.com>
Tested-by: NRobert Baldyga <r.baldyga@samsung.com>
Tested-by: NDinh Nguyen <dinguyen@opensource.altera.com>
Tested-by: NJohn Youn <johnyoun@synopsys.com>
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Disable controller power and enter hibernation when usb bus is
suspended. A phy driver is required to disable the power of the
controller and detect remote-wakeup or disconnection since the
controller will not be able to detect these in this state.

Once the phy driver detects bus activity, it must call
usb_hcd_resume_root_hub.
Signed-off-by: NGregory Herrero <gregory.herrero@intel.com>
Signed-off-by: NMian Yousaf Kaukab <yousaf.kaukab@intel.com>
Tested-by: NRobert Baldyga <r.baldyga@samsung.com>
Tested-by: NDinh Nguyen <dinguyen@opensource.altera.com>
Tested-by: NJohn Youn <johnyoun@synopsys.com>
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

lx_state must be used to reflect controller power state only and not
bus state. Thus add a flag to track state during bus suspend.
Signed-off-by: NGregory Herrero <gregory.herrero@intel.com>
Signed-off-by: NMian Yousaf Kaukab <yousaf.kaukab@intel.com>
Tested-by: NRobert Baldyga <r.baldyga@samsung.com>
Tested-by: NDinh Nguyen <dinguyen@opensource.altera.com>
Tested-by: NJohn Youn <johnyoun@synopsys.com>
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

port resume sequence may be used in different places. Create a
function to handle it. Make hprt0 read-modify-write atomic and
clear HPRT0_SUSP for both writes as it is a "read, write-set,
and self-clear (R_WS_SC)" bit. Since the lock is released
between the writes, read hprt0 again.

Since the phy clock is stopped in dwc2_port_suspend(), enable it
here and remove the PCGCTL write from dwc2_hcd_hub_control()
Signed-off-by: NGregory Herrero <gregory.herrero@intel.com>
Signed-off-by: NMian Yousaf Kaukab <yousaf.kaukab@intel.com>
Tested-by: NRobert Baldyga <r.baldyga@samsung.com>
Tested-by: NDinh Nguyen <dinguyen@opensource.altera.com>
Tested-by: NJohn Youn <johnyoun@synopsys.com>
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

When entering hibernation hprt0 must be read using dwc2_read_hprt0().
Otherwise, any set hprt0 status bits will be cleared when restoring
hprt0 on exit from hibernation.
Signed-off-by: NGregory Herrero <gregory.herrero@intel.com>
Signed-off-by: NMian Yousaf Kaukab <yousaf.kaukab@intel.com>
Tested-by: NRobert Baldyga <r.baldyga@samsung.com>
Tested-by: NDinh Nguyen <dinguyen@opensource.altera.com>
Tested-by: NJohn Youn <johnyoun@synopsys.com>
Acked-by: NJohn Youn <johnyoun@synopsys.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

We *know* our threads executes with our IRQs
disabled. We really don't need to use the _irqsave()
variant of spin_lock().
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Instead of limiting __dwc3_gadget_kick_transfer() to
Xfer Complete, we can try to issue Update Transfer
command from Xfer In Progress too.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

If we get a Xfer Not Ready event with reason
"Transfer Active" it means endpoint is still
transferring data and we can use that to issue
update transfer for this particular endpoint
in case we have pending requests in our queue.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

if by the time we get to XFER_COMPLETE we have
pending requests to be processed, instead of waiting
for a following XFER_NOT_READY, let's start the request
right away and, maybe, save the time of a few NAKs
due to lack of started transfers.
Signed-off-by: NFelipe Balbi <balbi@ti.com>

gadget methods should be called without
spinlocks held.
Reported-by: NAlexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Sharing the ACPI companion with dwc3 core so it has access
to the properties defined for DWC3 in ACPI tables.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

No functional affect on existing platforms, but the driver
is now ready to extract the properties also from ACPI tables
as well as from DT.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

By using the unified device property interface, the function
can be made available for all platforms and not just the
ones using DT.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

of_usb_get_dr_mode will be converted into more generic
usb_get_dr_mode function that will take struct device
instead of struct device_node as its parameter.

To make the conversion possible later, waiting for the
platform device for dwc3 to be populated before calling
of_usb_get_dr_mode.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
CC: Giuseppe Cavallaro <peppe.cavallaro@st.com>
CC: Peter Griffin <peter.griffin@linaro.org>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

By using the unified device property interface, the function
can be made available for all platforms and not just the
ones using DT.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

- Replace all "transceiver" with "phy"
- Replace one "OTG controller" with "phy"
Signed-off-by: NPeter Chen <peter.chen@freescale.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.

In case of tcm, ep->driver_data was used only for endpoint claiming so
we can simplify code by reducing it. We also remove give_back_ep()
function which is not needed after all - when error code is returned
from bind() function, composite will release all endpoints anyway.
Signed-off-by: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.

In case of dbgp, ep->driver_data was used only for endpoint claiming
and marking endpoints as enabled, so we can simplify code by reducing
it.
Signed-off-by: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.

In case of u_serial ep->driver_data stores pointer to struct gs_port,
which is referenced in many places in code. Code using ep->driver_data
to mark endpoint as enabled/disabled has been removed.
Signed-off-by: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.

In case of u_ether we only need to store in ep->driver_data pointer to
struct eth_dev, as it's used in rx_complete() and tx_complete() callbacks.
All other uses of ep->driver_data are now meaningless and can be safely
removed.
Signed-off-by: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.

In case of f_uvc, ep->driver_data was used only for endpoint claiming
and marking endpoints as enabled, so we can simplify code by reducing
it.
Signed-off-by: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.

In case of f_uac2, ep->driver_data was used only for endpoint claiming
and marking endpoints as enabled, so we can simplify code by reducing
it.
Signed-off-by: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.

In case of f_uac1, ep->driver_data was used only for endpoint claiming
and marking endpoints as enabled, so we can simplify code by reducing
it.
Signed-off-by: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.

In case of f_subset, ep->driver_data was used only for endpoint claiming
and marking endpoints as enabled, so we can simplify code by reducing
it.
Signed-off-by: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.

In case of f_sourcesink we only need to store in ep->driver_data pointer
to struct f_sourcesink, as it's used in source_sink_complete() callback.
All other uses of ep->driver_data are now meaningless and can be safely
removed.
Signed-off-by: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.

In case of f_serial, ep->driver_data was used only for endpoint claiming
and marking endpoints as enabled, so we can simplify code by reducing
it.
Signed-off-by: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.

In case of f_rndis, ep->driver_data was used only for endpoint claiming
and marking endpoints as enabled, so we can simplify code by reducing
it.
Signed-off-by: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.

In case of f_printer we only need to store in ep->driver_data pointer to
struct printer_dev, as it's used in rx_complete() and tx_complete()
callbacks. All other uses of ep->driver_data are now meaningless and can
be safely removed.
Signed-off-by: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.

In case of f_phonet we only need to store in ep->driver_data pointer to
struct f_phonet, as it's used in pn_tx_complete() and pn_rx_complete()
callbacks. All other uses of ep->driver_data are now meaningless and can
be safely removed.
Signed-off-by: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.

In case of f_obex, ep->driver_data was used only for endpoint claiming
and marking endpoints as enabled, so we can simplify code by reducing
it.
Signed-off-by: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Since ep->driver_data is not used for endpoint claiming, neither for
enabled/disabled state storing, we can reduce number of places where
we read or modify it's value, as now it has no particular meaning for
function or framework logic.

In case of f_ncm, ep->driver_data was used only for endpoint claiming
and marking endpoints as enabled, so we can simplify code by reducing
it.
Signed-off-by: NRobert Baldyga <r.baldyga@samsung.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>