- 01 Oct, 2015 10 commits
-
-
Gregory Herrero authored
In case controller is asked to stop while devices are connected, disconnect all devices and clean up before stopping. Signed-off-by:
Gregory Herrero <gregory.herrero@intel.com> Signed-off-by:
Mian Yousaf Kaukab <yousaf.kaukab@intel.com> Tested-by:
Robert Baldyga <r.baldyga@samsung.com> Tested-by:
Dinh Nguyen <dinguyen@opensource.altera.com> Tested-by:
John Youn <johnyoun@synopsys.com> Acked-by:
Felipe Balbi <balbi@ti.com>
-
Gregory Herrero authored
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:
-
Gregory Herrero authored
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:
-
Gregory Herrero authored
If hibernation is supported, resume of devices will be handled in bus_resume callback. Signed-off-by:
-
Gregory Herrero authored
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:
-
Gregory Herrero authored
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:
-
Gregory Herrero authored
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:
-
Gregory Herrero authored
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:
-
Gregory Herrero authored
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:
-
Gregory Herrero authored
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:
-
- 28 Sep, 2015 5 commits
-
-
Felipe Balbi authored
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: -
Felipe Balbi authored
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: -
Felipe Balbi authored
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: -
Felipe Balbi authored
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: -
Felipe Balbi authored
gadget methods should be called without spinlocks held. Reported-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by:
-
- 27 Sep, 2015 25 commits
-
-
Heikki Krogerus authored
Sharing the ACPI companion with dwc3 core so it has access to the properties defined for DWC3 in ACPI tables. Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
-
Heikki Krogerus authored
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:
-
Heikki Krogerus authored
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:
-
Heikki Krogerus authored
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:
-
Heikki Krogerus authored
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:
-
Peter Chen authored
- Replace all "transceiver" with "phy" - Replace one "OTG controller" with "phy" Signed-off-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
-
Robert Baldyga authored
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:
-
Robert Baldyga authored
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:
-
Robert Baldyga authored
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:
-
Robert Baldyga authored
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:
-
Robert Baldyga authored
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:
-
Robert Baldyga authored
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:
-
Robert Baldyga authored
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:
-
Robert Baldyga authored
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:
-
Robert Baldyga authored
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:
-
Robert Baldyga authored
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:
-
Robert Baldyga authored
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:
-
Robert Baldyga authored
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:
-
Robert Baldyga authored
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:
-
Robert Baldyga authored
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:
-
Robert Baldyga authored
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:
-
Robert Baldyga authored
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_midi we only need to store in ep->driver_data pointer to struct f_midi, as it's used in f_midi_complete() callback and related functions. All other uses of ep->driver_data are now meaningless and can be safely removed. Signed-off-by:
-
Robert Baldyga authored
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_mass_storage we only need to store in ep->driver_data pointer to struct fsg_common, which is used in bulk_in_complete() and bulk_out_complete() callbacks. All other uses of ep->driver_data are now meaningless and can be safely removed. Signed-off-by:
-
Robert Baldyga authored
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_hid we only need to store in ep->driver_data pointer to struct f_loopback, as it's used in loopback_complete() callback. All other uses of ep->driver_data are now meaningless and can be safely removed. Signed-off-by:
-
Robert Baldyga authored
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_hid we only need to store in ep->driver_data pointer to struct f_hidg, as it's used in f_hidg_req_complete() callback. All other uses of ep->driver_data are now meaningless and can be safely removed. Signed-off-by:
-
