- 03 Nov, 2014 40 commits
-
-
Peter Chen authored
The memory subsystem has already had similar message for it. Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Peter Chen authored
The memory subsystem has already had similar message for it. Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Peter Chen authored
The memory subsystem has already had similar message for it. Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Peter Chen authored
The memory subsystem has already had similar message for it. Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Peter Chen authored
The memory subsystem has already had similar message for it. Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Peter Chen authored
The memory subsystem has already had similar message for it. Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Peter Chen authored
The memory subsystem has already had similar message for it. Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Peter Chen authored
The memory subsystem has already had similar message for it. Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Peter Chen authored
The memory subsystem has already had similar message for it. Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Peter Chen authored
The memory subsystem has already had similar message for it. Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Peter Chen authored
The memory subsystem has already had similar message for it. Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Peter Chen authored
The memory subsystem has already had similar message for it. Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Peter Chen authored
The memory subsystem has already had similar message for it. Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Peter Chen authored
The memory subsystem has already had similar message for it. Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Peter Chen authored
The memory subsystem has already had similar message for it. Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Peter Chen authored
The memory subsystem has already had similar message for it. Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Peter Chen authored
The memory subsystem has already had similar message for it. Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Peter Chen authored
The memory subsystem has already had similar message for it. Signed-off-by: Peter Chen <peter.chen@freescale.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
Some gadget/function drivers might want to do improper request recycling by allocating a single request from one particular endpoint and queueing it to another completely unrelated endpoint. One such case was found with f_loopback.c. To prevent such cases from happening again, let's WARN() so we get a loud enough failure and persuade users to report errors. Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
whenever we get a Disconnect Interrupt, we should make sure to update out udc state to NOT_ATTACHED, otherwise sysfs will show wrong values. Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
I noticed that this has been missing for quite some time so I decided it was about time to document it. Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Andrzej Pietrasiewicz authored
USB gadgets composed with configfs lack suspend and resume methods. This patch uses composite_suspend()/composite_resume() the same way e.g. composite_setup() or composite_disconnect() are used in a configfs-based gadget. Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Dan Carpenter authored
This NULL check sets off a static checker warning because we already dereferenced "card" earlier in the function. However, since "card" is never NULL so we can just remove the check. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
when disconnecting from host using our soft_connect sysfs interface, also let the gadget driver know about it by calling the gadget driver's ->disconnect() method. No problems have been found while not calling ->disconnect() so far, it's just good convention. Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
Using ->prepare()/->complete() to mask/unmask IRQs is wrong at least for dwc3. We need to make sure that by the end of ->resume(), IRQs are working and ready to fire because a child device may need working IRQs for its own ->resume() method. Signed-off-by: Felipe Balbi <balbi@ti.com>
-
George Cherian authored
Enabling the core interrupts in complete is too late for XHCI, and stops it from proper operation. The root of the problem is due to a disagreement between dwc3-omap and XHCI about when IRQs should be enabled. As it turns out, ->resume's documentation states that: "... generally the driver is expected to start working again, responding to hardware events and software requests (the device itself may be left in a low-power state, waiting for a runtime resume to occur) ..." From that we infer that IRQs must be unmasked by the end of ->resume(). Due to that, we will remove ->prepare() and ->complete() and disable/enable interrupts in ->suspend()/->resume(). Acked-by: Roger Quadros <rogerq@ti.com> Signed-off-by: George Cherian <george.cherian@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Robert Jarzmik authored
Add support for device-tree device discovery. If devicetree is not provided, fallback to legacy platform data "discovery". Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Cc: devicetree@vger.kernel.org Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Robert Jarzmik authored
Convert the mach info, and store the udc_command in the pxa_udc control structure. It is to be noticed that the udc_is_connected() in mach info is not transfered. This was not used, as mioa701 machine doesn't need it, balloon3 doesn't really use it, and most importantly the current driver never uses it. Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Robert Jarzmik authored
For this preparation, a preliminary cleanup is done : - convert the probing of pxa27x_udc to gpio_desc. The conversion is partial because : - the platform data still provides a gpio number, not a gpio desc Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Yoshihiro Shimoda authored
This patch adds support for the generic PHY. The generic PHY will be used in multiplatform environment. Acked-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Yoshihiro Shimoda authored
To support both usb PHY and generic PHY, this patch cleans up rcar2.c. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Yoshihiro Shimoda authored
To support a generic phy driver in this driver later, this patch renames "struct usb_phy *phy" to "struct usb_phy *usb_phy". Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
Add TRB tracepoints for ep0 TRBs as that might help finding bugs with ep0 handling. Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
In case we unload a gadget driver while any of os_desc_req or req are still pending, we need to make sure to dequeue them. By using our setup_pending and os_desc_pending flags we achieve that in a way that doesn't cause any regressions because we won't dequeue a request which was already completed. The original idea came from Li Jun's commit f2267089 (usb: gadget: composite: dequeue cdev->req before free it in composite_dev_cleanup) which, unfortunately, caused two regressions (kfree() being called before usb_ep_dequeue() and calling usb_ep_dequeue() when the request was already completed). That commit also didn't take care of os_desc_req which can fall into the same situation so we must care for that one too. Note that in order to make code slightly easier to read, we introduce composite_ep_queue() which hides details about how to fiddle with our pending flags. Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
by doing that we will be able to match our requests against req and os_desc_req and also clear our pending flags from complete callback. Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
These flags we be set to true whenever their matching request is queued. They will be cleared to false when that request completes. Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Heikki Krogerus authored
Adding ACPI ID used on newer Intel SoCs. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Heikki Krogerus authored
If the probe drivers have already set the dma_mask, not replacing the value. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
tracing infrastructure already adds those for us. Signed-off-by: Felipe Balbi <balbi@ti.com>
-
Felipe Balbi authored
DWC3's GUID register is supposed to be used to write any sort of version we might want. It helps when getting bug reports for platforms you don't have HW to know which kernel version of the driver was running on the platform. Because we don't really track driver version, but we _do_ track the kernel version, let's write LINUX_VERSION_CODE to that register and use it for debugging. Reviewed-by: Paul Zimmerman <paulz@synopsys.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
-