- 22 Dec, 2015 9 commits
-
-
Douglas Anderson authored
Calls to dwc2_core_reset() are currently very slow, taking at least 150ms (possibly more). It behooves us to take as many of these calls out as possible. It turns out that the calls in dwc2_fs_phy_init() and dwc2_hs_phy_init() should (as documented in the code) only be needed if we need to do a PHY SELECT. That means that if we see that we can avoid the PHY SELECT then we can avoid the reset. This patch appears to successfully bypass two resets (one per USB device) on rk3288-based ARM Chromebooks. Signed-off-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
John Youn <johnyoun@synopsys.com> Signed-off-by:
Felipe Balbi <balbi@ti.com>
-
Yunzhi Li authored
I found that the probe function of dwc2 driver takes much time when kernel boot up. There are many long delays in the probe function these take almost 1 second. This patch trying to reduce unnecessary delay time. In dwc2_core_reset() I see it use two at least 20ms delays to wait AHB idle and core soft reset, but dwc2 data book said that dwc2 core soft reset and AHB idle just need a few clocks (I think it refers to AHB clock, and AHB clock run at 150MHz in my RK3288 board), so 20ms is too long, delay 1us for wait AHB idle and soft reset is enough. And in dwc2_get_hwparams() it takes 150ms to wait ForceHostMode and ForceDeviceMode valid but in data book it said software must wait at least 25ms before the change to take effect, so I reduce this time to 25ms~50ms. By the way, is there any state bit show that the force mode take effect ? Could we poll curmod bit for figuring out if the change take effect ? It seems that usleep_range() at boot time will pick the longest value in the range. In dwc2_core_reset() there is a very long delay takes 200ms, and this function run twice when probe, could any one tell me is this delay time resonable ? I have tried this patch in my RK3288-evb board. It works well. Signed-off-by:
Yunzhi Li <lyz@rock-chips.com> Signed-off-by:
-
Douglas Anderson authored
On some host-only DWC2 ports (like the one in rk3288) when we set GUSBCFG_FORCEHOSTMODE in GUSBCFG and then read back, we don't see the bit set. Presumably that's because the port is always forced to HOST mode so there's no reason to implement these status bits. Since we know dwc2_core_reset() is always called before dwc2_get_hwparams() and we know dwc2_core_reset() should have set GUSBCFG_FORCEHOSTMODE whenever hsotg->dr_mode == USB_DR_MODE_HOST, we can just check hsotg->dr_mode to decide that we can skip the delays in dwc2_get_hwparams(). Signed-off-by:
-
Douglas Anderson authored
In (usb: dwc2: reset dwc2 core before dwc2_get_hwparams()) we added an extra reset to the probe path for the dwc2 USB controllers. This allowed proper detection of parameters even if the firmware had already used the USB part. Unfortunately, this extra reset is quite slow and is affecting boot speed. We can avoid the double-reset by skipping the extra reset that would happen just after the one we added. Logic that explains why this is safe: * As of the CL mentioned above, we now always call dwc2_core_reset() in dwc2_driver_probe() before dwc2_hcd_init(). * The only caller of dwc2_hcd_init() is dwc2_driver_probe(), so we're guaranteed that dwc2_core_reset() was called before dwc2_hdc_init(). * dwc2_hdc_init() is the only caller that passes an irq other than -1 to dwc2_core_init(). Thus if dwc2_core_init() is called with an irq other than -1 we're guaranteed that dwc2_core_reset was called before dwc2_core_init(). ...this allows us to remove the dwc2_core_reset() in dwc2_core_init() if irq is not < 0. Note that since "irq" wasn't used in the function dwc2_core_init() anyway and since select_phy was always set at exactly the same times we could avoid the reset, we remove "irq" and rename "select_phy" to "initial_setup" and adjust the callers accordingly. Signed-off-by:
-
Yunzhi Li authored
We initiate dwc2 usb controller in BIOS, dwc2_core_reset() should be called before dwc2_get_hwparams() to reset core registers to default value. Without this the FIFO setting might be incorrect because calculating FIFO size need power-on value of GRXFSIZ/GNPTXFSIZ/HPTXFSIZ registers. This patch could avoid warnning massage like in rk3288 platform: [ 2.074764] dwc2 ff580000.usb: 256 invalid for host_perio_tx_fifo_size. Check HW configuration. Signed-off-by:
-
Douglas Anderson authored
Previously dwc2_get_hwparams() was changing GUSBCFG and not putting it back the way it was (specifically it set and cleared FORCEHOSTMODE). Since we want to move dwc2_core_reset() _before_ dwc2_get_hwparams() we should make sure dwc2_get_hwparams() isn't messing with things in a permanent way. Since we're now looking at GUSBCFG, it's obvious that we shouldn't need all the extra delays if FORCEHOSTMODE was already set. This will avoid some delays for any ports that have forced host mode. Signed-off-by:
-
Gregory Herrero authored
When receiving GINTSTS_GINNAKEFF or GINTSTS_GOUTNAKEFF interrupt, DCTL will be overwritten with DCTL_CGOUTNAK or DCTL_CGNPINNAK values. Instead of overwriting it, write only needed bits. It could cause an issue if GINTSTS_GINNAKEFF or GINTSTS_GOUTNAKEFF interrupt is received after dwc2 disabled pullup by writing DCTL_SFTDISCON bit. Pullup will then be re-enabled whereas it should not. Acked-by:
Gregory Herrero <gregory.herrero@intel.com> Signed-off-by:
-
Du, Changbin authored
To stop an out endpoint, software should set sets the Global OUT NAK, but not the Global Non-periodic IN NAK. This driver bug leads the out-ep failed be in disabled state with below error. dwc2_hsotg_ep_stop_xfr: timeout DOEPCTL.EPDisable Acked-by:
Du, Changbin <changbin.du@intel.com> Signed-off-by:
-
Baolin Wang authored
It dose not work when we want to use the usb-to-serial port based on one usb gadget as a console. Thus this patch adds the console initialization to support this request. To avoid the re-entrance when transferring data with usb endpoint, it introduces a kthread to do the IO transmission. Signed-off-by:
Baolin Wang <baolin.wang@linaro.org> Signed-off-by:
-
- 17 Dec, 2015 1 commit
-
-
Felipe Balbi authored
If OF is disabled, we will try to define a stub for of_usb_get_dr_mode_by_phy(), however that missed a static inline annotation which made us redefine the stub over and over again. Fix that. Fixes: 98bfb394 ("usb: of: add an api to get dr_mode by the phy node") Signed-off-by:
-
- 16 Dec, 2015 20 commits
-
-
David Eccher authored
Fix bad unlock balance: ep0_write enter with the locks locked from inode.c:1769, hence it must exit with spinlock held to avoid double unlock in dev_config. Signed-off-by:
David Eccher <d.eccher@gmail.com> Signed-off-by:
-
Simon Horman authored
Simply document new compatibility string. As a previous patch adds a generic R-Car Gen2 compatibility string there appears to be no need for a driver updates. Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Acked-by:
Rob Herring <robh@kernel.org> Acked-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by:
-
Simon Horman authored
Add fallback compatibility strings for R-Car Gen2 and Gen3. This is in keeping with the fallback scheme being adopted wherever appropriate for drivers for Renesas SoCs. Signed-off-by:
-
Simon Horman authored
This extends the documentation of compatibility strings a little to include the SoC names. Signed-off-by:
-
Mike Looijmans authored
The gadget ethernet driver supports changing the MTU, but only allows this when the USB cable is removed. The comment indicates that this is because the "peer won't know". Even if the network link is still down and only the USB link is established, the driver won't allow the change. Other network interfaces allow changing the MTU any time, and don't force the link to be disabled. This makes perfect sense, because in order to be able to negotiate the MTU, the link needs to be up. Remove the restriction so that it is now actually possible to change the MTU (e.g. using "ifconfig usb0 mtu 15000") without having to manually pull the plug or change the driver's default setting. This is especially important after commit bba787a8 ("usb: gadget: ether: Allow jumbo frames") Signed-off-by:
Mike Looijmans <mike.looijmans@topic.nl> Signed-off-by:
-
Robert Baldyga authored
It seems that gitorious repository is no longer accessible, so we replace it with address to active repository. Signed-off-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
-
Felipe F. Tonello authored
This patch introduces pre-allocation of IN endpoint USB requests. This improves on latency (requires no usb request allocation on transmit) and avoid several potential probles on allocating too many usb requests (which involves DMA pool allocation problems). This implementation also handles better multiple MIDI Gadget ports, always processing the last processed MIDI substream if the last USB request wasn't enought to handle the whole stream. Signed-off-by:
Felipe F. Tonello <eu@felipetonello.com> Signed-off-by:
-
Felipe F. Tonello authored
This ensures that the midi function will only work if the proper number of IN and OUT requrests are allocated. Otherwise the function will work with less requests then what the user wants. Signed-off-by:
-
Felipe F. Tonello authored
This avoids duplication of USB requests for OUT endpoint and re-enabling endpoints. Signed-off-by:
-
Tony Lindgren authored
When reloading omap2430 kernel module we get a warning about unbalanced pm_runtime_enable. Let's fix this. Note that we need to do this after the child musb-core platform_device is removed because of pm_runtime_irq_safe being set at the child. Cc: Bin Liu <b-liu@ti.com> Cc: Felipe Balbi <balbi@ti.com> Cc: Kishon Vijay Abraham I <kishon@ti.com> Cc: NeilBrown <neil@brown.name> Reviewed-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Tony Lindgren authored
We currently can't unload omap2430 MUSB platform glue driver module and this cause issues for fixing the MUSB code further. The reason we can't remove omap2430 is because it uses the PHY functions and also exports the omap_musb_mailbox function that some PHY drivers are using. Let's fix the issue by exporting a more generic musb_mailbox function from the MUSB core and allow platform glue layers to register phy_callback function as needed. And now we can now also get rid of the include/linux/musb-omap.h. Cc: Bin Liu <b-liu@ti.com> Cc: Felipe Balbi <balbi@ti.com> Cc: Kishon Vijay Abraham I <kishon@ti.com> Cc: NeilBrown <neil@brown.name> Reviewed-by:
-
Geyslan G. Bem authored
This patch removes redundant condition. (!A || (A && B)) is the same as (!A || B). Fixes indentation too. Tested by: compilation only Caught by: cppcheck Signed-off-by:
Geyslan G. Bem <geyslan@gmail.com> Signed-off-by:
-
Geyslan G. Bem authored
This patch removes redundant condition. (!A || (A && B)) is the same as (!A || B). Tested by compilation only. Caught by cppcheck. Signed-off-by:
-
Felipe Balbi authored
instead of using: if (condition) { dev_WARN_ONCE(dev, true, "foo"); return -EINVAL; } let's use: if (dev_WARN_ONCE(dev, condition, "foo")) return -EINVAL; Signed-off-by: -
Ruslan Bilovol authored
Change behavior during registration of gadgets and gadget drivers in udc-core. Instead of previous approach when for successful probe of usb gadget driver at least one usb gadget should be already registered use another one where gadget drivers and gadgets can be registered in udc-core independently. Independent registration of gadgets and gadget drivers is useful for built-in into kernel gadget and gadget driver case - because it's possible that gadget is really probed only on late_init stage (due to deferred probe) whereas gadget driver's probe is silently failed on module_init stage due to no any UDC added. Also it is useful for modules case - now there is no difference what module to insert first: gadget module or gadget driver one. Tested-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
Ruslan Bilovol <ruslan.bilovol@gmail.com> [simplified code as requested by Alan Stern and Felipe Balbi, fixed checkpatch issues] Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Tested-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
-
Ruslan Bilovol authored
Now when last user of usb_udc_attach_driver() is switched to passing UDC name via usb_gadget_driver struct, it's safe to remove this function Tested-by:
-
Ruslan Bilovol authored
Now when udc-core supports binding to specific UDC by passing its name via 'udc_name' member of usb_gadget_driver struct, switch to this generic approach. Tested-by:
-
Ruslan Bilovol authored
Introduce new 'udc_name' member to usb_gadget_driver structure. The 'udc_name' is a name of UDC that usb_gadget_driver should be bound to. If udc_name is NULL, it will be bound to any available UDC. Tested-by:
-
Bin Liu authored
To prevent VBUS contention, the am335x MUSB phy senses VBUS first before transitioning to host mode. However, for host-only mode, VBUS could be directly tied to 5V power rail which could prevent MUSB transitions to host mode. This change receives dr_mode of the controller then bypass the first VBUS sensing for host-only mode, so that MUSB can work in host mode event if VBUS is tied to 5V. Signed-off-by:
Bin Liu <b-liu@ti.com> Signed-off-by:
-
Bin Liu authored
The filename of am35x-phy-control.h is confusing. The header is used by the am335x phy driver, but the filename refers to am35x. Even worse there is indeed another device called am35x but it does not use this header at all. Signed-off-by:
-
- 15 Dec, 2015 10 commits
-
-
Geert Uytterhoeven authored
As of commit 3d7608e4 ("ARM: shmobile: bockw: remove legacy board file and config"), the Renesas R-Car (Gen1) USB PHY driver is no longer used. In theory it could still be used on R-Car Gen1 SoCs, but that would require adding DT support to the driver. Instead, a new driver using the generic PHY framework should be written, as was done for R-Car Gen2. Remove the driver for good. Acked-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Vladimir Zapolskiy authored
Remove mach/irq.h from the list of included headers, there is no compilation dependency on this include file, and the change is needed to prevent a compilation failure, when mach/irq.h is removed. Additionally remove other unneeded includes and sort out their order. Signed-off-by:
Vladimir Zapolskiy <vz@mleia.com> Signed-off-by:
-
Felipe Balbi authored
struct usb_request have 3 flags which might be important to know about during debug. This patch shows each of the 3 flags as a single letter: z -> for zero s -> short not okay i -> interrupt A capital letter means the feature is enabled while a lower case letter means it is disabled; Thus 'zsI' indicates that a ZLP is not needed, that we can accept a short packet and interrupt for this request should be enabled. Signed-off-by: -
Felipe Balbi authored
So far, dwc3 has always missed request->zero handling for every endpoint. Let's implement that so we can handle cases where transfer must be finished with a ZLP. Note that dwc3 is a little special. Even though we're dealing with a ZLP, we still need a buffer of wMaxPacketSize bytes; to hide that detail from every gadget driver, we have a preallocated buffer of 1024 bytes (biggest bulk size) to use (and share) among all endpoints. Reported-by:
Ravi B <ravibabu@ti.com> Signed-off-by:
-
Rasmus Villemoes authored
This file already uses pr_debug in a few places; this converts the remaining printks. Signed-off-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
-
Douglas Anderson authored
In general it is wise to clear interrupts before processing them. If you don't do that, you can get: 1. Interrupt happens 2. You look at system state and process interrupt 3. A new interrupt happens 4. You clear interrupt without processing it. This patch was actually a first attempt to fix missing device insertions as described in (usb: dwc2: host: Fix missing device insertions) and it did solve some of the signal bouncing problems but not all of them (which is why I submitted the other patch). Specifically, this patch itself would sometimes change: 1. hardware sees connect 2. hardware sees disconnect 3. hardware sees connect 4. dwc2_port_intr() - clears connect interrupt 5. dwc2_handle_common_intr() - calls dwc2_hcd_disconnect() ...to: 1. hardware sees connect 2. hardware sees disconnect 3. dwc2_port_intr() - clears connect interrupt 4. hardware sees connect 5. dwc2_handle_common_intr() - calls dwc2_hcd_disconnect() ...but with different timing then sometimes we'd still miss cable insertions. In any case, though this patch doesn't fix any (known) problems, it still seems wise as a general policy to clear interrupt before handling them. Note that for dwc2_handle_usb_port_intr(), instead of moving the clear of PRTINT to the beginning of the function we remove it completely. The only way to clear PRTINT is to clear the sources that set it in the first place. Signed-off-by:
-
Douglas Anderson authored
The dwc2_hcd_reset_func() function is only ever called directly by a delayed work function. As such no locks are already held when the function is called. Doing a read-modify-write of CPU registers and setting fields in the main hsotg data structure is a bad idea without locks. Let's add locks. The bug was found by code inspection only. It turns out that the dwc2_hcd_reset_func() is only ever called today if the "host_support_fs_ls_low_power" parameter is enabled and no code in mainline enables that parameter. Thus no known issues in mainline are fixed by this patch, but it's still probably wise to fix the function. Signed-off-by:
-
Bin Liu authored
Some USB phy drivers have different handling for the controller in each dr_mode. But the phy driver does not have visibility to the dr_mode of the controller. This adds an api to return the dr_mode of the controller which associates the given phy node. Signed-off-by:
-
Peter Chen authored
Since now, we may have more than one request during the test, and it is better we just quit once the error occurs instead of try queueing further requests. Signed-off-by:
Krzysztof Opasiak <k.opasiak@samsung.com> Reviewed-by:
-
Igor Kotrasinski authored
Since composite now overwrites bcdUSB for any gadget, remove setting it in legacy gadgets. All legacy gadgets set 0x0200, the same as the value additionally set by composite, so there is no behaviour change. Signed-off-by:
Igor Kotrasinski <i.kotrasinsk@samsung.com> Rebase onto current balbi/next Signed-off-by:
-
