Re: [PATCH] usb: musb: omap2430: use *syscon* framework API to write to mailbox register
* Kishon Vijay Abraham I [150819 23:38]: > Hi, > > On Thursday 06 August 2015 02:17 PM, Tony Lindgren wrote: > > * Kishon Vijay Abraham I [150805 07:10]: > >> On Wednesday 05 August 2015 01:31 PM, Tony Lindgren wrote: > >>> > >>> We don't have syscon-otghs and to me it seems we need a PHY driver > >>> as I pointed out at: > >> > >> If *syscon-otghs* is not present, then it'll fall-back to using the > >> *ctrl-module*. > > > > OK great. > > > >>> > >>> https://lkml.org/lkml/2015/6/24/231 > >> > >> Maybe I should have explained this in the previous thread. The *otghs* > >> register > >> that we are trying to access here does _not_ belong to the PHY. It acts as > >> mailbox register from MUSB glue (TI integration layer) to MUSB core. > >> That's why > >> it's programmed in the TI glue layer (omap2430.c). > >> > >> Even when we were using the older API [omap_control_usb_set_mode()], we > >> first > >> call omap_musb_mailbox from the PHY drivers (phy-twl4030-usb.c, > >> phy-twl6030-usb.c) and then omap_musb_mailbox in the TI glue writes to the > >> control module instead of PHY drivers directly calling > >> omap_control_usb_set_mode(). > > > > Hmm looking at "Table 18-204. CONTROL_USBOTGHS_CONTROL" it seems to mention > > "transceiver" for quite a few bitfields :) Probably what that register does > > is control a PHY over ULPI. > > OMAP4 uses UTMI PHY and it uses CONTROL_USBOTGHS_CONTROL too. So can't we make the phy-omap-usb2.c driver the onlly user of this register then and get rid of the mailbox stuff? I think the phy framework can handle everything now? > > So from Linux kernel point of view we're best off treating it as a PHY. > > It seems it should have a minimal PHY driver similar to what we have for > > dm816x control module in drivers/phy/phy-dm816x-usb.c. > > hmm.. IMHO CONTROL_USBOTGHS_CONTROL register belongs to the TI MUSB glue and > should be programmed in omap2430.c. It's better to get the opinion of Felipe > here. Felipe? > > > > For reference, here is the register bitfields pasted from 4460 TRM: > > > > Table 18-204. CONTROL_USBOTGHS_CONTROL, p3972 > > Physical Address 0x4A00 233C > > > > BIT NAMEDESCIPTION > > 8 DISCHRGVBUS ... OTG transceiver does (not) discharge VBUS ... > > 7 CHRGVBUS... OTG transceiver does (not) charge VBUS ... > > 6 IDPULLUP... OTG transceiver does (not) drive VBUS ... > > 4 IDDIG ... OTG transceiver does (not) apply a pullup to ID ... > > 3 SESSEND ... VBUS voltage is above/below VB_SESS_END ... > > 2 VBUSVALID ... VBUS is above the threshold ... > > 1 BVALID ... VBUS voltage is above/below VB_SESS_VLD ... > > 0 AVALID ... BUS voltage is above/below VA_SESS_VLD ... > > > > So how about just adding ONTROL_USBOTGHS_CONTROL support to the existing > > drivers/phy/phy-omap-usb2.c instead? It seems that it should allow us > > to completely get rid of the custom mailbox stuff for MUSB 2430 support? > > Not in phy-omap-usb2.c. It's the UTMI PHY driver and is not used by OMAP3 > based > boards (uses twl4030 ULPI PHY). CONTROL_USBOTGHS_CONTROL has to be programmed > for OMAP3 also. Hmm I don't think omap3 uses that register? There's no ti,control-phy anything in the omap3 dts files? And no USBOTGHS_CONTROL in the TRM? Or am I missing something here? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: USB devices not appearing after upgrading 4.1.4 => 4.1.5
On 21.08.2015 04:26, Daurnimator wrote: Description: After upgrading from linux kernel 4.1.4 to 4.1.5 I'm having trouble with my USB devices. First boot: my external keyboard wasn't working Second boot: my external mouse wasn't working Third boot: my internal touchpad wasn't working Additional info: The computer is a Dell M3800. Example log snippets: Aug 19 09:57:54 daurn-m3800 kernel: xhci_hcd :00:14.0: Timeout while waiting for configure endpoint command Looks like a command is stuck, we never get a command completion event for it. 4.1.4 to 4.1.5 xhci changes are mostly related to USB3 suspend and resume state tweaking. Looking at the stable tree they are: commit 81b75e85593dcbfde8a86cd44bd75cc96a22849e xhci: do not report PLC when link is in internal resume state commit c65fd970bbb46be9e517d93e67b5e9f27f5e45a0 xhci: prevent bus_suspend if SS port resuming in phase 1 commit 6f0433c52944a822f338f300fff672fa2fd43ac5 xhci: report U3 when link is in resume state commit eb9a669517a2eeb2e55fff733191c128b2f55830 xhci: Calculate old endpoints correctly on device reset I can't directly see what would cause it. Only theory for now is if one those changes left some port change event uncleared, blocking port status change events and thus maybe also command completion event, and thus causing timeout. If possible, could you try to bisect (or just cherry pick) the changes and try to find the one causing issues? Does booting without USB3 devices help? Just to quickly check if it's related to the USB3 suspend/resume changes. -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: USB devices not appearing after upgrading 4.1.4 => 4.1.5
On 21 August 2015 at 17:39, Mathias Nyman wrote: > I can't directly see what would cause it. Only theory for now is if one > those changes left > some port change event uncleared, blocking port status change events and > thus maybe also > command completion event, and thus causing timeout. > > If possible, could you try to bisect (or just cherry pick) the changes and > try to find > the one causing issues? It's probably best I do this at my office (which I'll be back at on Monday) > Does booting without USB3 devices help? > Just to quickly check if it's related to the USB3 suspend/resume changes. I did a boot without any devices plugged in, and the touchpad was dead. Though now I'm not entirely sure the touchpad is even USB... I think the Elan device in the lsusb output is the touchscreen rather than the touchpad; and then the other HID devices are 2 keyboards; and the Logitech mouse has 2 interfaces... -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Some restrictions when using usbtest and g_zero
On Thu, Aug 20, 2015 at 04:58:13PM -0400, Alan Stern wrote: > On Thu, 20 Aug 2015, Felipe Balbi wrote: > > > > > Doesn't Peter need to cope with differentiating protocol vs non-protocol > > > > stalls ? > > > > > > Those matter only for ep0, not for bulk/interrupt. > > > > huh ? usbtest send SetFeature(HALT) for the bulk endpoint, right ? > > That's what Peter's UDC driver is missing. It's this special case of > > halting the endpoint when the host asks it to regardless of having > > queued struct usb_requests or not. > > Yes, that's what I said. Peter's UDC driver doesn't handle halts for > bulk endpoints properly. But the difference between protocol and > functional (or non-protocol) stalls matters only for ep0, not for > bulk/interrupt, so it's not relevant to Peter's problem. > Thanks, Alan and Felipe. My problem should be the chipidea udc driver does not support functional stall well, it fixes the handling between functional and protocol stall. My understanding for these two stalls: - Functional stall, the host stalls the endpoints through SET_FEATURE by ep0, the ep0 does not recommend to support functional stall from the spec. The device should always set stall for this endpoint, and return success for it. - Protocol stall, if the endpoint doesn't support one request, it can stall itself. If there is an IN request on this endpoint, it should not do stall, and return error. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: gadget: fix possible regression introduced with ep->claimed
This patch fixes possible regression introduced by patch reworking endpoint
claiming mechanism. It restores setring ep->driver_data to NULL in
usb_ep_autoconfig_reset(), which was removed by patch [1].
[1] commit cc476b42a39d ("usb: gadget: encapsulate endpoint claiming
mechanism")
Reported-by: Felipe Balbi
Signed-off-by: Robert Baldyga
---
Hi Felipe,
I was not able to reproduce the problem that you have described (functions
trying to enable eps that are already enabled, and disable eps that are
already disabled), but I have analysed the problem and I have concluded
that the only possible cause of regression can be that my patch removed
setting ep->driver_data to NULL in usb_ep_autoconfig_reset() function.
Because of this change initial state of ep->driver_data could be non-NULL
value, which could change behavoiur of some functions. I can't imagine
any other possible cause of regression introduced by such simple patch.
Thanks,
Robert
drivers/usb/gadget/epautoconf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index 978435a..6399c10 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -186,6 +186,7 @@ void usb_ep_autoconfig_reset (struct usb_gadget *gadget)
list_for_each_entry (ep, &gadget->ep_list, ep_list) {
ep->claimed = false;
+ ep->driver_data = NULL;
}
gadget->in_epnum = 0;
gadget->out_epnum = 0;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Some restrictions when using usbtest and g_zero
On Thu, Aug 20, 2015 at 12:41:26PM -0500, Felipe Balbi wrote: > Hi, > > > > > > > > pass USB CV2.0 MSC TEST. (othwerwise, "Command Set Test - Device > > > > > > Configured" > > > > > > will fail) > > > > > > > > > > Why would a pending struct usb_request in your queue fail USB CV ? > > > > > > > > _Lack_ of a pending request can cause the USB CV to fail. In Peter's > > > > example, if you're testing a Mass-Storage gadget, USB CV requires that > > > > there be a pending Bulk-OUT request when the gadget is idle (so that > > > > the next SCSI command can be sent out). > > > > > > > > But if there's a pending usb_request on a bulk-OUT endpoint, will a UDC > > > > driver be able to carry out a Set-Halt-Feature request from the host? > > > > The answer isn't clear. And it's even worse for bulk-IN. > > > > > > how can USB CV even test that there is a pending request on the UDC's > > > side ? Short of actually moving data on that pipe, there's not way. > > > > That's exactly what the USB CV does -- it tries to send data. If it > > can't, the test fails. (At least, that's what I remember; it was a > > while ago that I looked at this.) > > > > However, in this respect Peter was a little inconsistent. The USB CV > > MSC test requires a pending bulk-OUT request, but the Set-Halt problem > > affects bulk-IN endpoints. > > right > Thanks. I don't have much time to debug this problem deeply today. Below are some information: - The parameter 'stall' is y for g_mass_storage - The stall bulk-IN is from the line 1571 at f_mass_storage.c If I do not stall this bulk-IN, and return -EAGAIN, the USB CV log like below, and the bus analyzer log at success.png Issuing Command Set Test for Op Code 0x12, Test Variation #7 INFO Issuing CBW (attempt #1): INFO |- CBW LUN = 0x0 INFO |- CBW Flags= 0x80 INFO |- CBW Data Transfer Length = 0xff INFO |- CBW CDB Length = 0x6 INFO |- CBW CDB-00 = 0x12 INFO |- CBW CDB-01 = 0x0 INFO |- CBW CDB-02 = 0x0 INFO |- CBW CDB-03 = 0x0 INFO |- CBW CDB-04 = 0xff INFO |- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW phase stalled, clear stall on CBW endpoint INFO Retrieving status on stalled CSW endpoint INFO CSW endpoint status = 0x1 INFO Issuing CSW : try 2 INFO CSW residue returned = 0xdb INFO CSW status returned = 0x0 INFO Getting Device Type If I do stall this bulk-IN, and return 0, the USB CV log like below, and the bus analyzer log at failure.png INFO Issuing Command Set Test for Op Code 0x12, Test Variation #7 INFO Issuing CBW (attempt #1): INFO |- CBW LUN = 0x0 INFO |- CBW Flags= 0x80 INFO |- CBW Data Transfer Length = 0xff INFO |- CBW CDB Length = 0x6 INFO |- CBW CDB-00 = 0x12 INFO |- CBW CDB-01 = 0x0 INFO |- CBW CDB-02 = 0x0 INFO |- CBW CDB-03 = 0x0 INFO |- CBW CDB-04 = 0xff INFO |- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO DATA phase stalled INFO Retrieving status on stalled bulk endpoint INFO Bulk endpoint status = 0x1 INFO Issuing CSW : try 1 INFO CSW Bulk Request failed with bus error! INFO Failed CSW phase : should have been success or stall ERROR BOTCommonMSCRequest failed: error=80004005 INFO Re-enumerating device INFO Detected hard error, issuing BOT MSC Reset INFO Allowing Errors on odd-byte transfers The difference between success and failure routine is, one is bulk-in is stalled at CSW stage, the other is at data stage. -- Best Regards, Peter Chen
Re: MUSB dual-role on AM335x behaving weirdly
On 20/08/2015 18:46, Felipe Balbi wrote: > On Thu, Aug 20, 2015 at 06:35:17PM +0200, Gregory CLEMENT wrote: >> Hi Felipe, >> >> On 18/08/2015 16:13, Felipe Balbi wrote: >>> Hi, >>> >>> On Tue, Aug 18, 2015 at 02:36:13PM +0200, Gregory CLEMENT wrote: Hi again Felipe, I sent this email again without the capture because it prevented to be delivered to the mailing lists. On 04/08/2015 21:32, Felipe Balbi wrote: > On Tue, Aug 04, 2015 at 04:23:02PM +0200, Gregory CLEMENT wrote: >> Hi again, >> On 04/08/2015 15:08, Gregory CLEMENT wrote: >>> Hi Bin, >>> >>> On 02/07/2015 19:05, Bin Liu wrote: Hi, On Thu, Jul 2, 2015 at 2:16 AM, Gregory CLEMENT wrote: > Hi Felipe, > > On 27/05/2015 11:42, Alexandre Belloni wrote: >> Hi, >> >> On 26/05/2015 at 09:51:18 -0500, Felipe Balbi wrote : >>> On Thu, May 14, 2015 at 04:36:33PM -0500, Bin Liu wrote: Alexandre, On Thu, May 14, 2015 at 4:26 PM, Alexandre Belloni wrote: > On 14/05/2015 at 16:16:12 -0500, Bin Liu wrote : >> I think I found the root cause of the problem: board design >> issue - I >> bet the custom board has too much cap on VBUS line. It should be >> < >> 10uF. >> > > We have a custom board that exhibits the issue but it only has a > 100nF > cap on VBUS. Have you measured the VBUS discharging? Is there any way to share your schematics? >>> >>> Alexandre, any further comments ? >>> >> >> Yeah, I have just got more info. >> >> This is the relevant part of the schematic: >> http://free-electrons.com/~alexandre/usb.png >> >> The total VBUS capacitance is 200nF and the USB0 pins are connected >> directly to the AM3358 pins. U1 is actually not fitted. >> >> We didn't measure VBUS discharging but we observe the OTG pin sensing >> stops when plugging an OTG cable without any device. > > Do you have any news about this topic? > > > Is there something else that we can do to help solving this issue? In the case of CONFIG_USB_MUSB_DUAL_ROLE=y and dr_mode=otg, how is the gadget driver configured? It has to be a module not built-in. >>> >>> Indeed when I configured CONFIG_USB_MUSB_HDRC=m and >>> CONFIG_USB_MUSB_DSPS=m >>> it worked seamless. >>> >> >> Actually it didn't worked. And now sometimes I even received continuously >> the following message: >> >> musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active > > this is likely because your VBUS hasn't dropped below 0.8V fast enough. > > I could only trigger this message in that situation. Use a scope to poke > at VBUS and see how long is takes to reach 0.8V, this could all be cause > by too much capacitance on VBUS line. We got some news: "The capacitance on VBUS due to components is 200nF and the additional parasitic capacitance will be much smaller than this" The rail discharge time is ~36ms when an USB drive is removed from the OTG adapter. I attached a capture of this. What do you think about these values? However, "there appears to be a considerable delay between the removal of a usb drive and the initiation of the VBUS discharge (maybe ~1 second, I wasn't able to measure this time)." >>> >>> yeah, this is really weird. I can't think of anything that would make >>> VBUS discharge slower from a SW point of view. Once you remove the >>> cable, VBUS is physically removed and there's nothing else charging it. >> >> I have more feedback about it: "When I look at it on the oscilloscope >> this isn't a 'slow discharge' like a slowly draining capacitor, it is >> a delay between the removal of a device and the initiation of the >> discharge. The discharge itself is quite fast once it begins, it just >> seems as if the SOC/driver is taking a long time to notice the cable >> is disconnected. At this stage, this isn't actually a problem, just >> odd." >> >> While working on this issue we found that the >> tg_state_a_wait_vrise_timeout case seemed not managed by musb_dsps >> driver. I've just submitted a patch for it: >> https://lkml.org/lkml/2015/8/20/507 > > cool, I'll test it next week. Good finding btw. Thanks, however it seemed already needs to be amended. > >> I made most of my test on a 3.17 kernel and today by using a 4.1 >> kernel with the patch I have submitted I didn't manage to reproduce >> the issue. I saw that since 3.17, there were some patches related to >> the babble interrupts;
Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case
Hi all,
On 20/08/2015 18:12, Gregory CLEMENT wrote:
> According to the OTG specification after a timeout of
> OTG_TIME_A_WAIT_VRISE (the maximum value is 100ms) the driver must
> move from the state a_wait_vrise to the state a_wait_bcon. However,
> the dsps version of musb does not handle this case.
>
> Without it, the driver could remain stuck in the a_wait_vrise. It can
> be reproduce with the following steps:
>
> 1) Boot a board with no USB adapter inserted
> 2) Insert an empty OTG adapter
> 3) Wait 2 seconds then remove the OTG adapter
> 4) The unit is now stuck in host mode, the VBUS switch is latched on
> and the ID pin is no longer polled.
>
> The only way to exit this state was to insert a OTG adapter with an
> USB device connected. Until this, the usb device mode was not
> available.
>
> It was tested on a AM35x based board.
>
> CC:
> Signed-off-by: Gregory CLEMENT
> ---
> drivers/usb/musb/musb_dsps.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
> index 65d931a..2d22683 100644
> --- a/drivers/usb/musb/musb_dsps.c
> +++ b/drivers/usb/musb/musb_dsps.c
> @@ -145,6 +145,7 @@ struct dsps_glue {
> struct timer_list timer;/* otg_workaround timer */
> unsigned long last_timer;/* last timer data for each instance */
> bool sw_babble_enabled;
> + int otg_state_a_wait_vrise_timeout;
>
> struct dsps_context context;
> struct debugfs_regset32 regset;
> @@ -268,9 +269,18 @@ static void otg_timer(unsigned long _musb)
>
> spin_lock_irqsave(&musb->lock, flags);
> switch (musb->xceiv->otg->state) {
> + case OTG_STATE_A_WAIT_VRISE:
> + if ((glue->otg_state_a_wait_vrise_timeout)) {
> + musb->xceiv->otg->state = OTG_STATE_A_WAIT_BCON;
> + musb->is_active = 0;
> + }
> + mod_timer(&glue->timer, jiffies +
> + msecs_to_jiffies(OTG_TIME_A_WAIT_VRISE));
After more test on more USB drive, it seems that for some of them
OTG_TIME_A_WAIT_VRISE is too short. 200ms seems better. It is
disturbing because according to the OTG specification the maximum
is 100ms, however I am not so surprised that USB device maker don't
follow it.
> + break;
> case OTG_STATE_A_WAIT_BCON:
> dsps_writeb(musb->mregs, MUSB_DEVCTL, 0);
> skip_session = 1;
> + glue->otg_state_a_wait_vrise_timeout = 0;
> /* fall */
>
> case OTG_STATE_A_IDLE:
> @@ -359,7 +369,9 @@ static irqreturn_t dsps_interrupt(int irq, void *hci)
> MUSB_HST_MODE(musb);
> musb->xceiv->otg->default_a = 1;
> musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE;
> - del_timer(&glue->timer);
> + glue->otg_state_a_wait_vrise_timeout = 1;
> + mod_timer(&glue->timer, jiffies +
> + msecs_to_jiffies(OTG_TIME_A_WAIT_VRISE));
> } else {
> musb->is_active = 0;
> MUSB_DEV_MODE(musb);
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] Exynos4412-based Trats2 USB gadget (DWC2) fixes
Dear All,
Since v3.19 s3c-hsotg (DWC2) USB controller stopped working on
Exynos4412-based Trats2 platform. However on Odroid-U3 (which is also
Exynos4412-based) it worked fine all the time. After long investigation
it turned out that this was caused by 2 independent issues.
First issue was caused by patch 7eec1266751bd3a25e35ce88686634c768fedc24
("ARM: dts: Add Maxim 77693 PMIC to exynos4412-trats2") added support
for Maxim 77693 regulators, but without defining consumers for them.
This causes regulator core to disable them. However SAFEOUT1 regulator
provides power supply to VBUS signal, which also power some USB phy
related parts of Exynos SoC core. This has been fixed by patches 1-3,
which adds support for VBUS regulator, defines them in DTS for all
Exynos platforms and changes probe sequence of the drivers to ensure no
deferred probe occurs (USB gadget subsystem doesn't support deferred
probe yet).
Second issue is related to DWC2 driver rewrite and host/gadget/dual-role
integration code. DWC2 module on some platforms needs three additional
hardware resources: phy, clock and power supply. All of them must be
enabled/activated to properly initialize and operate. This was initially
handled in s3c-hsotg driver, which has been converted to 'gadget' part
of dwc2 driver. Unfortunately, not all of this code got moved to common
platform code, what resulted in accessing DWC2 registers without
enabling power supply regulators and clock. This caused initialization
failure on Exynos4412-based Trats2. Odroid U3 board worked fine, because
power supplies used by DWC2 module are marked there as 'always-on',
because they are also used by other modules (USB hub) and clock was
shared with USB2 PHY, so it was already enabled. This initialization
issue has been fixed by the last patch. While preparing it I've also
fixed a few minor issues found in nearby code (patches 4-6).
I would like to get those patches merged separately to respective
subsystem trees:
patch 1: phy subsystem tree
patch 2: Samsung Exynos tree
patch 3: regulator subsystem tree
patch 4-7: USB gadget subsystem tree
Patches have been prepared on top of linux-next from 20150821.
Best regards
Marek Szyprowski
Samsung R&D Institute Poland
Patch summary:
Marek Szyprowski (7):
phy: exynos-usb2: add vbus regulator support
arm: dts: exynos: add vbus regulator to USB2 phy nodes
regulators: max77693: register driver earlier to avoid deferred probe
usb: dwc2: remove double call to s3c_hsotg_of_probe
usb: dwc2: remove non-functional clock gating
usb: dwc2: fix unbalanced phy control
usb: dwc2: refactor common low-level hw code to platform.c
.../devicetree/bindings/phy/samsung-phy.txt| 3 +
arch/arm/boot/dts/exynos3250-monk.dts | 1 +
arch/arm/boot/dts/exynos3250-rinato.dts| 1 +
arch/arm/boot/dts/exynos4210-trats.dts | 2 +-
arch/arm/boot/dts/exynos4210-universal_c210.dts| 2 +-
arch/arm/boot/dts/exynos4412-trats2.dts| 1 +
drivers/phy/phy-samsung-usb2.c | 25 ++-
drivers/phy/phy-samsung-usb2.h | 2 +
drivers/regulator/max77693.c | 12 +-
drivers/usb/dwc2/core.h| 4 +-
drivers/usb/dwc2/gadget.c | 196 +++
drivers/usb/dwc2/platform.c| 209 +
12 files changed, 239 insertions(+), 219 deletions(-)
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] arm: dts: exynos: add vbus regulator to USB2 phy nodes
Exynos USB2 PHY driver now supports VBUS regulator, so add it to all
boards which have it available. This also fixes commit
7eec1266751bd3a25e35ce88686634c768fedc24 ("ARM: dts: Add Maxim 77693
PMIC to exynos4412-trats2"), which added new regulators to Trats2 board,
but without linking them to the consumers.
Signed-off-by: Marek Szyprowski
---
arch/arm/boot/dts/exynos3250-monk.dts | 1 +
arch/arm/boot/dts/exynos3250-rinato.dts | 1 +
arch/arm/boot/dts/exynos4210-trats.dts | 2 +-
arch/arm/boot/dts/exynos4210-universal_c210.dts | 2 +-
arch/arm/boot/dts/exynos4412-trats2.dts | 1 +
5 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos3250-monk.dts
b/arch/arm/boot/dts/exynos3250-monk.dts
index 540a0adf2be6..35b39d2255d3 100644
--- a/arch/arm/boot/dts/exynos3250-monk.dts
+++ b/arch/arm/boot/dts/exynos3250-monk.dts
@@ -161,6 +161,7 @@
};
&exynos_usbphy {
+ vbus-supply = <&safeout_reg>;
status = "okay";
};
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 41a5fafb9aa9..23623cd3ebd9 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -153,6 +153,7 @@
&exynos_usbphy {
status = "okay";
+ vbus-supply = <&safeout_reg>;
};
&hsotg {
diff --git a/arch/arm/boot/dts/exynos4210-trats.dts
b/arch/arm/boot/dts/exynos4210-trats.dts
index ba34886f8b65..01d38f2145b9 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -251,6 +251,7 @@
&exynos_usbphy {
status = "okay";
+ vbus-supply = <&safe1_sreg>;
};
&fimd {
@@ -448,7 +449,6 @@
safe1_sreg: ESAFEOUT1 {
regulator-name = "SAFEOUT1";
-regulator-always-on;
};
safe2_sreg: ESAFEOUT2 {
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index eb379526e234..2c04297825fe 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -248,6 +248,7 @@
&exynos_usbphy {
status = "okay";
+ vbus-supply = <&safeout1_reg>;
};
&fimd {
@@ -486,7 +487,6 @@
safeout1_reg: ESAFEOUT1 {
regulator-name = "SAFEOUT1";
- regulator-always-on;
};
safeout2_reg: ESAFEOUT2 {
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 2a1ebb76ebe0..50a5e8a85283 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -391,6 +391,7 @@
};
&exynos_usbphy {
+ vbus-supply = <&esafeout1_reg>;
status = "okay";
};
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] usb: dwc2: remove non-functional clock gating
During typical gadget operation, dwc2 clock was enabled 3 times: from
dwc2_gadget_init(), s3c_hsotg_udc_start() and s3c_hsotg_pullup(), and then
disabled in s3c_hsotg_pullup(), s3c_hsotg_udc_stop() and
s3c_hsotg_remove(). This really makes no sense, so leave clock control
code only in dwc2_gadget_init/remove functions.
Signed-off-by: Marek Szyprowski
---
drivers/usb/dwc2/gadget.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 47960787f572..bccb60fcdd70 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3068,8 +3068,6 @@ static int s3c_hsotg_udc_start(struct usb_gadget *gadget,
hsotg->gadget.dev.of_node = hsotg->dev->of_node;
hsotg->gadget.speed = USB_SPEED_UNKNOWN;
- clk_enable(hsotg->clk);
-
ret = regulator_bulk_enable(ARRAY_SIZE(hsotg->supplies),
hsotg->supplies);
if (ret) {
@@ -3139,8 +3137,6 @@ static int s3c_hsotg_udc_stop(struct usb_gadget *gadget)
regulator_bulk_disable(ARRAY_SIZE(hsotg->supplies), hsotg->supplies);
- clk_disable(hsotg->clk);
-
mutex_unlock(&hsotg->init_mutex);
return 0;
@@ -3174,7 +3170,6 @@ static int s3c_hsotg_pullup(struct usb_gadget *gadget,
int is_on)
mutex_lock(&hsotg->init_mutex);
spin_lock_irqsave(&hsotg->lock, flags);
if (is_on) {
- clk_enable(hsotg->clk);
hsotg->enabled = 1;
s3c_hsotg_core_init_disconnected(hsotg, false);
s3c_hsotg_core_connect(hsotg);
@@ -3182,7 +3177,6 @@ static int s3c_hsotg_pullup(struct usb_gadget *gadget,
int is_on)
s3c_hsotg_core_disconnect(hsotg);
s3c_hsotg_disconnect(hsotg);
hsotg->enabled = 0;
- clk_disable(hsotg->clk);
}
hsotg->gadget.speed = USB_SPEED_UNKNOWN;
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] phy: exynos-usb2: add vbus regulator support
Exynos USB2 PHY has separate power supply, which is usually provided by
VBUS regulator. This patch adds support for it. VBUS regulator is
optional, to keep compatibility with boards, which have VBUS provided
from some always-on power source.
Signed-off-by: Marek Szyprowski
---
.../devicetree/bindings/phy/samsung-phy.txt| 3 +++
drivers/phy/phy-samsung-usb2.c | 25 --
drivers/phy/phy-samsung-usb2.h | 2 ++
3 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 60c6f2a633e0..0289d3b07853 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -44,6 +44,9 @@ Required properties:
- the "ref" clock is used to get the rate of the clock provided to the
PHY module
+Optional properties:
+- vbus-supply: power-supply phandle for vbus power source
+
The first phandle argument in the PHY specifier identifies the PHY, its
meaning is compatible dependent. For the currently supported SoCs (Exynos 4210
and Exynos 4212) it is as follows:
diff --git a/drivers/phy/phy-samsung-usb2.c b/drivers/phy/phy-samsung-usb2.c
index f278a9c547e1..1d22d93b552d 100644
--- a/drivers/phy/phy-samsung-usb2.c
+++ b/drivers/phy/phy-samsung-usb2.c
@@ -27,6 +27,13 @@ static int samsung_usb2_phy_power_on(struct phy *phy)
dev_dbg(drv->dev, "Request to power_on \"%s\" usb phy\n",
inst->cfg->label);
+
+ if (drv->vbus) {
+ ret = regulator_enable(drv->vbus);
+ if (ret)
+ goto err_regulator;
+ }
+
ret = clk_prepare_enable(drv->clk);
if (ret)
goto err_main_clk;
@@ -48,6 +55,9 @@ err_power_on:
err_instance_clk:
clk_disable_unprepare(drv->clk);
err_main_clk:
+ if (drv->vbus)
+ regulator_disable(drv->vbus);
+err_regulator:
return ret;
}
@@ -55,7 +65,7 @@ static int samsung_usb2_phy_power_off(struct phy *phy)
{
struct samsung_usb2_phy_instance *inst = phy_get_drvdata(phy);
struct samsung_usb2_phy_driver *drv = inst->drv;
- int ret;
+ int ret = 0;
dev_dbg(drv->dev, "Request to power_off \"%s\" usb phy\n",
inst->cfg->label);
@@ -68,7 +78,10 @@ static int samsung_usb2_phy_power_off(struct phy *phy)
}
clk_disable_unprepare(drv->ref_clk);
clk_disable_unprepare(drv->clk);
- return 0;
+ if (drv->vbus)
+ ret = regulator_disable(drv->vbus);
+
+ return ret;
}
static const struct phy_ops samsung_usb2_phy_ops = {
@@ -203,6 +216,14 @@ static int samsung_usb2_phy_probe(struct platform_device
*pdev)
return ret;
}
+ drv->vbus = devm_regulator_get(dev, "vbus");
+ if (IS_ERR(drv->vbus)) {
+ ret = PTR_ERR(drv->vbus);
+ if (ret == -EPROBE_DEFER)
+ return ret;
+ drv->vbus = NULL;
+ }
+
for (i = 0; i < drv->cfg->num_phys; i++) {
char *label = drv->cfg->phys[i].label;
struct samsung_usb2_phy_instance *p = &drv->instances[i];
diff --git a/drivers/phy/phy-samsung-usb2.h b/drivers/phy/phy-samsung-usb2.h
index 44bead9b8f34..6563e7ca0ac4 100644
--- a/drivers/phy/phy-samsung-usb2.h
+++ b/drivers/phy/phy-samsung-usb2.h
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#define KHZ 1000
#define MHZ (KHZ * KHZ)
@@ -37,6 +38,7 @@ struct samsung_usb2_phy_driver {
const struct samsung_usb2_phy_config *cfg;
struct clk *clk;
struct clk *ref_clk;
+ struct regulator *vbus;
unsigned long ref_rate;
u32 ref_reg_val;
struct device *dev;
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] usb: dwc2: fix unbalanced phy control
Even when DWC2 is in (internal) suspended state, it should disable PHY
in suspend and then enable it in resume. This patch fixes unbalanced PHY
control sequence.
Signed-off-by: Marek Szyprowski
---
drivers/usb/dwc2/platform.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 90935304185a..dad15ad1ecb4 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -290,8 +290,6 @@ static int __maybe_unused dwc2_suspend(struct device *dev)
if (dwc2_is_device_mode(dwc2)) {
ret = s3c_hsotg_suspend(dwc2);
} else {
- if (dwc2->lx_state == DWC2_L0)
- return 0;
phy_exit(dwc2->phy);
phy_power_off(dwc2->phy);
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] regulators: max77693: register driver earlier to avoid deferred probe
MAX77693 based regulators are used by USB gadget subsystem, which
doesn't support deferred probe, so the driver should be registered
before USB gadget drivers get probed.
Signed-off-by: Marek Szyprowski
---
drivers/regulator/max77693.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/max77693.c b/drivers/regulator/max77693.c
index 788379b87962..de730fd3f8a5 100644
--- a/drivers/regulator/max77693.c
+++ b/drivers/regulator/max77693.c
@@ -300,7 +300,17 @@ static struct platform_driver max77693_pmic_driver = {
.id_table = max77693_pmic_id,
};
-module_platform_driver(max77693_pmic_driver);
+static int __init max77693_pmic_init(void)
+{
+ return platform_driver_register(&max77693_pmic_driver);
+}
+subsys_initcall(max77693_pmic_init);
+
+static void __exit max77693_pmic_cleanup(void)
+{
+ platform_driver_unregister(&max77693_pmic_driver);
+}
+module_exit(max77693_pmic_cleanup);
MODULE_DESCRIPTION("MAXIM 77693/77843 regulator driver");
MODULE_AUTHOR("Jonghwa Lee ");
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] usb: dwc2: refactor common low-level hw code to platform.c
DWC2 module on some platforms needs three additional hardware
resources: phy controller, clock and power supply. All of them must be
enabled/activated to properly initialize and operate. This was initially
handled in s3c-hsotg driver, which has been converted to 'gadget' part
of dwc2 driver. Unfortunately, not all of this code got moved to common
platform code, what resulted in accessing DWC2 registers without
enabling low-level hardware resources. This fails for example on Exynos
SoCs. This patch moves all the code for managing those resources to
common platform.c file and provides convenient wrappers for controlling
them.
Signed-off-by: Marek Szyprowski
---
drivers/usb/dwc2/core.h | 4 +-
drivers/usb/dwc2/gadget.c | 188 +---
drivers/usb/dwc2/platform.c | 207
3 files changed, 195 insertions(+), 204 deletions(-)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 0ed87620941b..ec820bdf98c0 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -690,6 +690,7 @@ struct dwc2_hsotg {
enum usb_dr_mode dr_mode;
unsigned int hcd_enabled:1;
unsigned int gadget_enabled:1;
+ unsigned int ll_hw_enabled:1;
struct phy *phy;
struct usb_phy *uphy;
@@ -1088,7 +1089,8 @@ extern void dwc2_set_all_params(struct dwc2_core_params
*params, int value);
extern int dwc2_get_hwparams(struct dwc2_hsotg *hsotg);
-
+extern int dwc2_lowlevel_hw_enable(struct dwc2_hsotg *hsotg);
+extern int dwc2_lowlevel_hw_disable(struct dwc2_hsotg *hsotg);
/*
* Dump core registers and SPRAM
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index bccb60fcdd70..98f139be8c7f 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -25,15 +25,11 @@
#include
#include
#include
-#include
-#include
#include
-#include
#include
#include
#include
-#include
#include "core.h"
#include "hw.h"
@@ -2944,50 +2940,6 @@ static struct usb_ep_ops s3c_hsotg_ep_ops = {
};
/**
- * s3c_hsotg_phy_enable - enable platform phy dev
- * @hsotg: The driver state
- *
- * A wrapper for platform code responsible for controlling
- * low-level USB code
- */
-static void s3c_hsotg_phy_enable(struct dwc2_hsotg *hsotg)
-{
- struct platform_device *pdev = to_platform_device(hsotg->dev);
-
- dev_dbg(hsotg->dev, "pdev 0x%p\n", pdev);
-
- if (hsotg->uphy)
- usb_phy_init(hsotg->uphy);
- else if (hsotg->plat && hsotg->plat->phy_init)
- hsotg->plat->phy_init(pdev, hsotg->plat->phy_type);
- else {
- phy_init(hsotg->phy);
- phy_power_on(hsotg->phy);
- }
-}
-
-/**
- * s3c_hsotg_phy_disable - disable platform phy dev
- * @hsotg: The driver state
- *
- * A wrapper for platform code responsible for controlling
- * low-level USB code
- */
-static void s3c_hsotg_phy_disable(struct dwc2_hsotg *hsotg)
-{
- struct platform_device *pdev = to_platform_device(hsotg->dev);
-
- if (hsotg->uphy)
- usb_phy_shutdown(hsotg->uphy);
- else if (hsotg->plat && hsotg->plat->phy_exit)
- hsotg->plat->phy_exit(pdev, hsotg->plat->phy_type);
- else {
- phy_power_off(hsotg->phy);
- phy_exit(hsotg->phy);
- }
-}
-
-/**
* s3c_hsotg_init - initalize the usb core
* @hsotg: The driver state
*/
@@ -3068,14 +3020,13 @@ static int s3c_hsotg_udc_start(struct usb_gadget
*gadget,
hsotg->gadget.dev.of_node = hsotg->dev->of_node;
hsotg->gadget.speed = USB_SPEED_UNKNOWN;
- ret = regulator_bulk_enable(ARRAY_SIZE(hsotg->supplies),
- hsotg->supplies);
- if (ret) {
- dev_err(hsotg->dev, "failed to enable supplies: %d\n", ret);
- goto err;
+ if (hsotg->dr_mode == USB_DR_MODE_PERIPHERAL) {
+ ret = dwc2_lowlevel_hw_enable(hsotg);
+ if (ret)
+ goto err;
+ hsotg->ll_hw_enabled = true;
}
- s3c_hsotg_phy_enable(hsotg);
if (!IS_ERR_OR_NULL(hsotg->uphy))
otg_set_peripheral(hsotg->uphy->otg, &hsotg->gadget);
@@ -3133,9 +3084,11 @@ static int s3c_hsotg_udc_stop(struct usb_gadget *gadget)
if (!IS_ERR_OR_NULL(hsotg->uphy))
otg_set_peripheral(hsotg->uphy->otg, NULL);
- s3c_hsotg_phy_disable(hsotg);
- regulator_bulk_disable(ARRAY_SIZE(hsotg->supplies), hsotg->supplies);
+ if (hsotg->dr_mode == USB_DR_MODE_PERIPHERAL) {
+ dwc2_lowlevel_hw_disable(hsotg);
+ hsotg->ll_hw_enabled = false;
+ }
mutex_unlock(&hsotg->init_mutex);
@@ -3473,7 +3426,6 @@ static inline void s3c_hsotg_of_probe(struct dwc2_hsotg
*hsotg) { }
int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq)
{
struct device *dev = hsotg->dev;
- struct s3c_hsotg_plat *plat
[PATCH 4/7] usb: dwc2: remove double call to s3c_hsotg_of_probe
This patch removes doubled call to s3c_hsotg_of_probe() function. Signed-off-by: Marek Szyprowski --- drivers/usb/dwc2/gadget.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c index 3ee5b4c77a1f..47960787f572 100644 --- a/drivers/usb/dwc2/gadget.c +++ b/drivers/usb/dwc2/gadget.c @@ -3488,8 +3488,6 @@ int dwc2_gadget_init(struct dwc2_hsotg *hsotg, int irq) /* Set default UTMI width */ hsotg->phyif = GUSBCFG_PHYIF16; - s3c_hsotg_of_probe(hsotg); - /* Initialize to legacy fifo configuration values */ hsotg->g_rx_fifo_sz = 2048; hsotg->g_np_g_tx_fifo_sz = 1024; -- 1.9.2 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] phy: exynos-usb2: add vbus regulator support
Hi,
On Friday 21 August 2015 06:08 PM, Marek Szyprowski wrote:
> Exynos USB2 PHY has separate power supply, which is usually provided by
> VBUS regulator. This patch adds support for it. VBUS regulator is
> optional, to keep compatibility with boards, which have VBUS provided
> from some always-on power source.
>
> Signed-off-by: Marek Szyprowski
> ---
> .../devicetree/bindings/phy/samsung-phy.txt| 3 +++
> drivers/phy/phy-samsung-usb2.c | 25
> --
> drivers/phy/phy-samsung-usb2.h | 2 ++
> 3 files changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> index 60c6f2a633e0..0289d3b07853 100644
> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> @@ -44,6 +44,9 @@ Required properties:
> - the "ref" clock is used to get the rate of the clock provided to the
> PHY module
>
> +Optional properties:
> +- vbus-supply: power-supply phandle for vbus power source
how about using phy-supply?
Thanks
Kishon
> +
> The first phandle argument in the PHY specifier identifies the PHY, its
> meaning is compatible dependent. For the currently supported SoCs (Exynos
> 4210
> and Exynos 4212) it is as follows:
> diff --git a/drivers/phy/phy-samsung-usb2.c b/drivers/phy/phy-samsung-usb2.c
> index f278a9c547e1..1d22d93b552d 100644
> --- a/drivers/phy/phy-samsung-usb2.c
> +++ b/drivers/phy/phy-samsung-usb2.c
> @@ -27,6 +27,13 @@ static int samsung_usb2_phy_power_on(struct phy *phy)
>
> dev_dbg(drv->dev, "Request to power_on \"%s\" usb phy\n",
> inst->cfg->label);
> +
> + if (drv->vbus) {
> + ret = regulator_enable(drv->vbus);
> + if (ret)
> + goto err_regulator;
> + }
> +
> ret = clk_prepare_enable(drv->clk);
> if (ret)
> goto err_main_clk;
> @@ -48,6 +55,9 @@ err_power_on:
> err_instance_clk:
> clk_disable_unprepare(drv->clk);
> err_main_clk:
> + if (drv->vbus)
> + regulator_disable(drv->vbus);
> +err_regulator:
> return ret;
> }
>
> @@ -55,7 +65,7 @@ static int samsung_usb2_phy_power_off(struct phy *phy)
> {
> struct samsung_usb2_phy_instance *inst = phy_get_drvdata(phy);
> struct samsung_usb2_phy_driver *drv = inst->drv;
> - int ret;
> + int ret = 0;
>
> dev_dbg(drv->dev, "Request to power_off \"%s\" usb phy\n",
> inst->cfg->label);
> @@ -68,7 +78,10 @@ static int samsung_usb2_phy_power_off(struct phy *phy)
> }
> clk_disable_unprepare(drv->ref_clk);
> clk_disable_unprepare(drv->clk);
> - return 0;
> + if (drv->vbus)
> + ret = regulator_disable(drv->vbus);
> +
> + return ret;
> }
>
> static const struct phy_ops samsung_usb2_phy_ops = {
> @@ -203,6 +216,14 @@ static int samsung_usb2_phy_probe(struct platform_device
> *pdev)
> return ret;
> }
>
> + drv->vbus = devm_regulator_get(dev, "vbus");
> + if (IS_ERR(drv->vbus)) {
> + ret = PTR_ERR(drv->vbus);
> + if (ret == -EPROBE_DEFER)
> + return ret;
> + drv->vbus = NULL;
> + }
> +
> for (i = 0; i < drv->cfg->num_phys; i++) {
> char *label = drv->cfg->phys[i].label;
> struct samsung_usb2_phy_instance *p = &drv->instances[i];
> diff --git a/drivers/phy/phy-samsung-usb2.h b/drivers/phy/phy-samsung-usb2.h
> index 44bead9b8f34..6563e7ca0ac4 100644
> --- a/drivers/phy/phy-samsung-usb2.h
> +++ b/drivers/phy/phy-samsung-usb2.h
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
>
> #define KHZ 1000
> #define MHZ (KHZ * KHZ)
> @@ -37,6 +38,7 @@ struct samsung_usb2_phy_driver {
> const struct samsung_usb2_phy_config *cfg;
> struct clk *clk;
> struct clk *ref_clk;
> + struct regulator *vbus;
> unsigned long ref_rate;
> u32 ref_reg_val;
> struct device *dev;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
On Thu, 20 Aug 2015, Roland Weber wrote: > [1.] One line summary of the problem: > "lsusb -v" as root freezes the kernel on Acer ES1-111M > > [2.] Full description of the problem/report: > As root, "lsusb -v" against USB devices "003:001" or "003:002" > of my Acer ES1-111M netbook freezes the kernel. > No log entry, no oops, no magic sysreq key. > Reproducible: always. > There are only those two devices on bus 003. > There is no problem with the other USB buses or devices of the machine. > I have no external USB devices attached. > When I had, there was no problem with them. > > [3.] Keywords (i.e., modules, networking, kernel): > > [4.] Kernel version (from /proc/version): > Linux version 4.1.6-040106-generic (kernel@gomeisa) (gcc version 4.8.4 > (Ubuntu 4.8.4-2ubuntu1~14.04) ) #201508170230 SMP Mon Aug 17 06:32:14 UTC 2015 > > The problem also occurs with kernel versions 4.2-rc7 and 3.18. > There is no problem with kernel versions 3.17 and 3.17.8. Can you use "git bisect" between 3.17 and 3.18 to find the commit that caused the problem to start? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Some restrictions when using usbtest and g_zero
On Fri, 21 Aug 2015, Peter Chen wrote: > Thanks, Alan and Felipe. > > My problem should be the chipidea udc driver does not support functional > stall well, it fixes the handling between functional and protocol stall. > > My understanding for these two stalls: > > - Functional stall, the host stalls the endpoints through SET_FEATURE > by ep0, the ep0 does not recommend to support functional stall from > the spec. The device should always set stall for this endpoint, and > return success for it. That's almost right. I just checked the USB spec to make sure (section 8.4.5). A functional stall occurs whenever the endpoint's HALT feature is set. This could be caused the host sending a Set-Halt request, _or_ it could be caused by the device's firmware (for example, by a call to usb_ep_set_halt()). Either way, the endpoint continues to stall until the host sends a Clear-Halt request. (And yes, the spec recommends that devices should not set the HALT feature for ep0. If they do, it is undefined whether the device will respond to a Clear-Halt request!) > - Protocol stall, if the endpoint doesn't support one request, it can > stall itself. If there is an IN request on this endpoint, it should > not do stall, and return error. Protocol stalls occur only on control endpoints; they indicate the device does not understand or cannot carry out a control request. They are automatically cleared the next time a Setup packet arrives. So if you're talking about a bulk/interrupt endpoint, the only kind of stall you have to worry about is a functional stall. The host can cause a functional stall at any time by sending Set-Halt. The gadget driver can also cause a functional stall, but it makes no sense to do so while it is in the middle of transferring data to/from the host. For this reason, usb_ep_set_halt() always returns an error if the endpoint queue or the FIFO is non-empty. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: hub: remove redundant declarations
Fix two occurrences of the Sparse warning:
warning: symbol XXX shadows an earlier one
Signed-off-by: Kris Borer
---
drivers/usb/core/hub.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 431839b..a0db6a4 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1070,7 +1070,7 @@ static void hub_activate(struct usb_hub *hub, enum
hub_activation_type type)
* for HUB_POST_RESET, but it's easier not to.
*/
if (type == HUB_INIT) {
- unsigned delay = hub_power_on_good_delay(hub);
+ delay = hub_power_on_good_delay(hub);
hub_power_on(hub, false);
INIT_DELAYED_WORK(&hub->init_work, hub_init_func2);
@@ -1404,7 +1404,6 @@ static int hub_configure(struct usb_hub *hub,
/* FIXME for USB 3.0, skip for now */
if ((wHubCharacteristics & HUB_CHAR_COMPOUND) &&
!(hub_is_superspeed(hdev))) {
- int i;
charportstr[USB_MAXCHILDREN + 1];
for (i = 0; i < maxchild; i++)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: hub: remove redundant declarations
On Fri, Aug 21, 2015 at 10:26:00AM -0400, Kris Borer wrote:
> Fix two occurrences of the Sparse warning:
>
> warning: symbol XXX shadows an earlier one
>
> Signed-off-by: Kris Borer
Reviewed-by: Felipe Balbi
> ---
> drivers/usb/core/hub.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index 431839b..a0db6a4 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -1070,7 +1070,7 @@ static void hub_activate(struct usb_hub *hub, enum
> hub_activation_type type)
>* for HUB_POST_RESET, but it's easier not to.
>*/
> if (type == HUB_INIT) {
> - unsigned delay = hub_power_on_good_delay(hub);
> + delay = hub_power_on_good_delay(hub);
>
> hub_power_on(hub, false);
> INIT_DELAYED_WORK(&hub->init_work, hub_init_func2);
> @@ -1404,7 +1404,6 @@ static int hub_configure(struct usb_hub *hub,
> /* FIXME for USB 3.0, skip for now */
> if ((wHubCharacteristics & HUB_CHAR_COMPOUND) &&
> !(hub_is_superspeed(hdev))) {
> - int i;
> charportstr[USB_MAXCHILDREN + 1];
>
> for (i = 0; i < maxchild; i++)
> --
> 1.9.1
>
--
balbi
signature.asc
Description: Digital signature
Re: Some restrictions when using usbtest and g_zero
On Fri, 21 Aug 2015, Peter Chen wrote: > Thanks. > > I don't have much time to debug this problem deeply today. Below > are some information: > > - The parameter 'stall' is y for g_mass_storage > - The stall bulk-IN is from the line 1571 at f_mass_storage.c > > If I do not stall this bulk-IN, and return -EAGAIN, the USB > CV log like below, and the bus analyzer log at success.png That's how it's supposed to work. You should return -EAGAIN because the endpoint is busy. > Issuing Command Set Test for Op Code 0x12, Test Variation #7 > INFO > Issuing CBW (attempt #1): > INFO > |- CBW LUN = 0x0 > INFO > |- CBW Flags= 0x80 > INFO > |- CBW Data Transfer Length = 0xff > INFO > |- CBW CDB Length = 0x6 > INFO > |- CBW CDB-00 = 0x12 > INFO > |- CBW CDB-01 = 0x0 > INFO > |- CBW CDB-02 = 0x0 > INFO > |- CBW CDB-03 = 0x0 > INFO > |- CBW CDB-04 = 0xff > INFO > |- CBW CDB-05 = 0x0 > INFO > Issuing DATA IN > INFO > Issuing CSW : try 1 > INFO > CSW phase stalled, clear stall on CBW endpoint > INFO > Retrieving status on stalled CSW endpoint > INFO > CSW endpoint status = 0x1 > INFO > Issuing CSW : try 2 > INFO > CSW residue returned = 0xdb > INFO > CSW status returned = 0x0 > INFO > Getting Device Type Okay, that's all normal. > If I do stall this bulk-IN, and return 0, the USB > CV log like below, and the bus analyzer log at failure.png > > INFO > Issuing Command Set Test for Op Code 0x12, Test Variation #7 > INFO > Issuing CBW (attempt #1): > INFO > |- CBW LUN = 0x0 > INFO > |- CBW Flags= 0x80 > INFO > |- CBW Data Transfer Length = 0xff > INFO > |- CBW CDB Length = 0x6 > INFO > |- CBW CDB-00 = 0x12 > INFO > |- CBW CDB-01 = 0x0 > INFO > |- CBW CDB-02 = 0x0 > INFO > |- CBW CDB-03 = 0x0 > INFO > |- CBW CDB-04 = 0xff > INFO > |- CBW CDB-05 = 0x0 > INFO > Issuing DATA IN > INFO > DATA phase stalled The problem occurs here. You can't tell from this log, but you can see it in the analyzer output. Your failure.png file shows that the STALL occurred before any data was sent (transaction 2585). That's not supposed to happen. The gadget should send a 24-byte bulk-IN packet before sending the STALL. When the call to halt_bulk_in_endpoint() occurs on line 1571, the subroutine should call fsg_set_halt() and get a -EAGAIN error because the 24-byte response packet is still being sent to the host. It appears that your UDC halted the endpoint immediately and did not return -EAGAIN. That's the bug. > INFO > Retrieving status on stalled bulk endpoint > INFO > Bulk endpoint status = 0x1 > INFO > Issuing CSW : try 1 > INFO > CSW Bulk Request failed with bus error! I don't know what this means. Something went wrong, probably another bug in the UDC. > INFO > Failed CSW phase : should have been success or stall > ERROR > BOTCommonMSCRequest failed: error=80004005 > INFO > Re-enumerating device > INFO > Detected hard error, issuing BOT MSC Reset > INFO > Allowing Errors on odd-byte transfers > > The difference between success and failure routine is, one > is bulk-in is stalled at CSW stage, the other is at data > stage. The data-stage stall is not supposed to happen until _after_ the data has been sent to the host. See Case (5) in section 6.7.2 of the Bulk-Only Transport spec. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: fix possible regression introduced with ep->claimed
On Fri, Aug 21, 2015 at 11:01:29AM +0200, Robert Baldyga wrote:
> This patch fixes possible regression introduced by patch reworking endpoint
> claiming mechanism. It restores setring ep->driver_data to NULL in
> usb_ep_autoconfig_reset(), which was removed by patch [1].
>
> [1] commit cc476b42a39d ("usb: gadget: encapsulate endpoint claiming
> mechanism")
>
> Reported-by: Felipe Balbi
> Signed-off-by: Robert Baldyga
> ---
>
> Hi Felipe,
>
> I was not able to reproduce the problem that you have described (functions
> trying to enable eps that are already enabled, and disable eps that are
> already disabled), but I have analysed the problem and I have concluded
it happens with all, you can't see it because dwc3 (only) has a WARN()
for when an endpoint is enabled and has previously been enabled
(drivers/usb/dwc3/gadget.c). If you track your endpoint's state
regarding being enabled or not, you can add a WARN() to see the error.
> that the only possible cause of regression can be that my patch removed
> setting ep->driver_data to NULL in usb_ep_autoconfig_reset() function.
> Because of this change initial state of ep->driver_data could be non-NULL
> value, which could change behavoiur of some functions. I can't imagine
> any other possible cause of regression introduced by such simple patch.
yeah, I'll test this later.
>
> Thanks,
> Robert
>
> drivers/usb/gadget/epautoconf.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
> index 978435a..6399c10 100644
> --- a/drivers/usb/gadget/epautoconf.c
> +++ b/drivers/usb/gadget/epautoconf.c
> @@ -186,6 +186,7 @@ void usb_ep_autoconfig_reset (struct usb_gadget *gadget)
>
> list_for_each_entry (ep, &gadget->ep_list, ep_list) {
> ep->claimed = false;
> + ep->driver_data = NULL;
> }
> gadget->in_epnum = 0;
> gadget->out_epnum = 0;
> --
> 1.9.1
>
--
balbi
signature.asc
Description: Digital signature
Re: [PATCHv2] Input: xpad - Fix double URB submission races
Hi Laura, On Mon, Aug 10, 2015 at 05:26:12PM -0700, Laura Abbott wrote: > v2: Created a proper queue for events instead of just dropping them How long does it take for the queue to exhaust your memory if you keep bombarding the driver with requests? I do not think you need a queue. I believe the nature of LEDs and rumble force feedback effect is such that you can discard all requests but the latest that arrived between the moment you submitted a request to the device and the moment you are ready submit a new one. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
Hello Alan, > Can you use "git bisect" between 3.17 and 3.18 to find the commit that > caused the problem to start? I was afraid I'd have to do that... it's been years since I compiled kernels. There's a good description on how to do it though. So yes, I should manage. I have to do it on a netbook, in my spare time, so it's gonna take a while. git clone is running now. thanks and cheers, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: fix possible regression introduced with ep->claimed
Hi,
On Fri, Aug 21, 2015 at 10:00:50AM -0500, Felipe Balbi wrote:
> On Fri, Aug 21, 2015 at 11:01:29AM +0200, Robert Baldyga wrote:
> > This patch fixes possible regression introduced by patch reworking endpoint
> > claiming mechanism. It restores setring ep->driver_data to NULL in
> > usb_ep_autoconfig_reset(), which was removed by patch [1].
> >
> > [1] commit cc476b42a39d ("usb: gadget: encapsulate endpoint claiming
> > mechanism")
> >
> > Reported-by: Felipe Balbi
> > Signed-off-by: Robert Baldyga
> > ---
> >
> > Hi Felipe,
> >
> > I was not able to reproduce the problem that you have described (functions
> > trying to enable eps that are already enabled, and disable eps that are
> > already disabled), but I have analysed the problem and I have concluded
>
> it happens with all, you can't see it because dwc3 (only) has a WARN()
> for when an endpoint is enabled and has previously been enabled
> (drivers/usb/dwc3/gadget.c). If you track your endpoint's state
> regarding being enabled or not, you can add a WARN() to see the error.
>
> > that the only possible cause of regression can be that my patch removed
> > setting ep->driver_data to NULL in usb_ep_autoconfig_reset() function.
> > Because of this change initial state of ep->driver_data could be non-NULL
> > value, which could change behavoiur of some functions. I can't imagine
> > any other possible cause of regression introduced by such simple patch.
>
> yeah, I'll test this later.
this has been running for many hours and I couldn't find any problems so
far. Just in case, I'll keep it running, but I doubt we'll find
anything. Once -rc1 is tagged, I'll send this to Greg.
thanks
--
balbi
signature.asc
Description: Digital signature
[PATCH v6 5/5] arm64: dts: mediatek: add xHCI & usb phy for mt8173
add xHCI and phy drivers for MT8173-EVB
Signed-off-by: Chunfeng Yun
---
arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 16 +++
arch/arm64/boot/dts/mediatek/mt8173.dtsi| 44 +
2 files changed, 60 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index f433c21..112f3f3 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -13,6 +13,7 @@
*/
/dts-v1/;
+#include
#include "mt8173.dtsi"
/ {
@@ -32,6 +33,15 @@
};
chosen { };
+
+ usb_p1_vbus: regulator@0 {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = <&pio 130 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
};
&pwrap {
@@ -211,3 +221,9 @@
&uart0 {
status = "okay";
};
+
+&usb30 {
+ vusb33-supply = <&mt6397_vusb_reg>;
+ vbus-supply = <&usb_p1_vbus>;
+ mediatek,wakeup-src = <1>;
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 0696f8f..f88b2f9 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -14,6 +14,8 @@
#include
#include
#include
+#include
+#include
#include
#include "mt8173-pinfunc.h"
@@ -393,6 +395,48 @@
#size-cells = <0>;
status = "disabled";
};
+
+ usb30: usb@1127 {
+ compatible = "mediatek,mt8173-xhci";
+ reg = <0 0x1127 0 0x4000>,
+ <0 0x1128 0 0x0800>;
+ interrupts = ;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
+ clocks = <&topckgen CLK_TOP_USB30_SEL>,
+<&pericfg CLK_PERI_USB0>,
+<&pericfg CLK_PERI_USB1>;
+ clock-names = "sys_ck",
+ "wakeup_deb_p0",
+ "wakeup_deb_p1";
+ phys = <&phy_port0 PHY_TYPE_USB3>,
+ <&phy_port1 PHY_TYPE_USB2>;
+ usb3-lpm-capable;
+ mediatek,syscon-wakeup = <&pericfg>;
+ status = "okay";
+ };
+
+ u3phy: usb-phy@1129 {
+ compatible = "mediatek,mt8173-u3phy";
+ reg = <0 0x1129 0 0x800>;
+ clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
+ clock-names = "u3phya_ref";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "okay";
+
+ phy_port0: port@11290800 {
+ reg = <0 0x11290800 0 0x800>;
+ #phy-cells = <1>;
+ status = "okay";
+ };
+
+ phy_port1: port@11291000 {
+ reg = <0 0x11291000 0 0x800>;
+ #phy-cells = <1>;
+ status = "okay";
+ };
+ };
};
};
--
1.8.1.1.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Mediatek xHCI support
>From 4cab60015fd73f37b7c970ba56c2625fe346fcf3 Mon Sep 17 00:00:00 2001 From: Chunfeng Yun Date: Sat, 22 Aug 2015 09:35:14 +0800 Subject: [PATCH v6 0/5] Mediatek xHCI support The patch supports MediaTek's xHCI controller. There are some differences from xHCI spec: 1. The interval is specified in 250 * 8ns increments for Interrupt Moderation Interval(IMODI) of the Interrupter Moderation(IMOD) register, it is 8 times as much as that defined in xHCI spec. 2. For the value of TD Size in Normal TRB, MTK's xHCI controller defines a number of packets that remain to be transferred for a TD after processing all Max packets in all previous TRBs,that means don't include the current TRB's, but in xHCI spec it includes the current ones. 3. To minimize the scheduling effort for synchronous endpoints in xHC, the MTK architecture defines some extra SW scheduling parameters for HW. According to these parameters provided by SW, the xHC can easily decide whether a synchronous endpoint should be scheduled in a specific uFrame. The extra SW scheduling parameters are put into reserved DWs in Slot and Endpoint Context. And a bandwidth scheduler algorithm is added to support such feature. A usb3.0 phy driver is also added which used by mt65xx SoCs platform, it supports two usb2.0 ports and one usb3.0 port. Change in v6: 1. get register base address of port in probe instead of of_xlate 2. enable clock in phy_init instead of probe Change in v5: 1. descripte more exactly for each specifiers in xHCI binding 2. make use of new multi-phy feature for phy driver Change in v4: 1. descripte more exactly for each specifiers in binding file 2. use BIT() to define a bit mask mcro Change in v3: 1. implement generic phy 2. move opperations for IPPC and wakeup from phy driver to xHCI driver 3. seperate quirk functions into a single C file to fix up dependence issue Change in v2: 1. Rebase to 4.2-rc1 2. Remove probe phy before add usb_hcd patch from this series due to 4.2-rc1 already fix this issue 3. add xhci mac clocks 4. add suspend/resume 5. support remote wakeup Chunfeng Yun (5): dt-bindings: Add usb3.0 phy binding for MT65xx SoCs dt-bindings: Add a binding for Mediatek xHCI host controller usb: phy: add usb3.0 phy driver for mt65xx SoCs xhci: mediatek: support MTK xHCI host controller arm64: dts: mediatek: add xHCI & usb phy for mt8173 .../devicetree/bindings/phy/phy-mt65xx-usb.txt | 69 ++ .../devicetree/bindings/usb/mt8173-xhci.txt| 52 ++ arch/arm64/boot/dts/mediatek/mt8173-evb.dts| 16 + arch/arm64/boot/dts/mediatek/mt8173.dtsi | 44 ++ drivers/phy/Kconfig| 9 + drivers/phy/Makefile | 1 + drivers/phy/phy-mt65xx-usb3.c | 456 +++ drivers/usb/host/Kconfig | 9 + drivers/usb/host/Makefile | 4 + drivers/usb/host/xhci-mtk-sch.c| 436 +++ drivers/usb/host/xhci-mtk.c| 831 + drivers/usb/host/xhci-mtk.h| 133 drivers/usb/host/xhci-ring.c | 35 +- drivers/usb/host/xhci.c| 19 +- drivers/usb/host/xhci.h| 1 + 15 files changed, 2108 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt create mode 100644 drivers/phy/phy-mt65xx-usb3.c create mode 100644 drivers/usb/host/xhci-mtk-sch.c create mode 100644 drivers/usb/host/xhci-mtk.c create mode 100644 drivers/usb/host/xhci-mtk.h -- 1.8.1.1.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 4/5] xhci: mediatek: support MTK xHCI host controller
MTK xhci host controller defines some extra SW scheduling
parameters for HW to minimize the scheduling effort for
synchronous and interrupt endpoints. The parameters are
put into reseved DWs of slot context and endpoint context
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/Kconfig| 9 +
drivers/usb/host/Makefile | 4 +
drivers/usb/host/xhci-mtk-sch.c | 436 +
drivers/usb/host/xhci-mtk.c | 831
drivers/usb/host/xhci-mtk.h | 133 +++
drivers/usb/host/xhci-ring.c| 35 +-
drivers/usb/host/xhci.c | 19 +-
drivers/usb/host/xhci.h | 1 +
8 files changed, 1461 insertions(+), 7 deletions(-)
create mode 100644 drivers/usb/host/xhci-mtk-sch.c
create mode 100644 drivers/usb/host/xhci-mtk.c
create mode 100644 drivers/usb/host/xhci-mtk.h
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 8afc3c1..358ab6d 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -34,6 +34,15 @@ config USB_XHCI_PCI
config USB_XHCI_PLATFORM
tristate
+config USB_XHCI_MTK
+ tristate "xHCI support for Mediatek MT65xx"
+ select MFD_SYSCON
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ ---help---
+ Say 'Y' to enable the support for the xHCI host controller
+ found in Mediatek MT65xx SoCs.
+ If unsure, say N.
+
config USB_XHCI_MVEBU
tristate "xHCI support for Marvell Armada 375/38x"
select USB_XHCI_PLATFORM
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 754efaa..00401f9 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -13,6 +13,9 @@ fhci-$(CONFIG_FHCI_DEBUG) += fhci-dbg.o
xhci-hcd-y := xhci.o xhci-mem.o
xhci-hcd-y += xhci-ring.o xhci-hub.o xhci-dbg.o
xhci-hcd-y += xhci-trace.o
+ifneq ($(CONFIG_USB_XHCI_MTK), )
+ xhci-hcd-y += xhci-mtk-sch.o
+endif
xhci-plat-hcd-y := xhci-plat.o
ifneq ($(CONFIG_USB_XHCI_MVEBU), )
@@ -30,6 +33,7 @@ endif
obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
obj-$(CONFIG_USB_XHCI_PLATFORM) += xhci-plat-hcd.o
+obj-$(CONFIG_USB_XHCI_MTK) += xhci-mtk.o
obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o
obj-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o
diff --git a/drivers/usb/host/xhci-mtk-sch.c b/drivers/usb/host/xhci-mtk-sch.c
new file mode 100644
index 000..d4b41a6
--- /dev/null
+++ b/drivers/usb/host/xhci-mtk-sch.c
@@ -0,0 +1,436 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author:
+ * Zhigang.Wei
+ * Chunfeng.Yun
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+
+#include "xhci.h"
+#include "xhci-mtk.h"
+
+#define SS_BW_BOUNDARY 51000
+/* table 5-5. High-speed Isoc Transaction Limits in usb_20 spec */
+#define HS_BW_BOUNDARY 6144
+/* usb2 spec section11.18.1: at most 188 FS bytes per microframe */
+#define FS_PAYLOAD_MAX 188
+
+/* mtk scheduler bitmasks */
+#define EP_BPKTS(p)((p) & 0x3f)
+#define EP_BCSCOUNT(p) (((p) & 0x7) << 8)
+#define EP_BBM(p) ((p) << 11)
+#define EP_BOFFSET(p) ((p) & 0x3fff)
+#define EP_BREPEAT(p) (((p) & 0x7fff) << 16)
+
+static int is_fs_or_ls(enum usb_device_speed speed)
+{
+ return speed == USB_SPEED_FULL || speed == USB_SPEED_LOW;
+}
+
+static int get_bw_index(struct xhci_hcd *xhci, struct usb_device *udev,
+ struct usb_host_endpoint *ep)
+{
+ int bw_index;
+ int port_id;
+ struct xhci_virt_device *virt_dev;
+
+ virt_dev = xhci->devs[udev->slot_id];
+ port_id = virt_dev->real_port;
+
+ if (udev->speed == USB_SPEED_SUPER) {
+ if (usb_endpoint_dir_out(&ep->desc))
+ bw_index = (port_id - 1) * 2;
+ else
+ bw_index = (port_id - 1) * 2 + 1;
+ } else {
+ bw_index = port_id + xhci->num_usb3_ports - 1;
+ }
+
+ return bw_index;
+}
+
+static void setup_sch_info(struct usb_device *udev,
+ struct xhci_ep_ctx *ep_ctx, struct mu3h_sch_ep_info *sch_ep)
+{
+ u32 ep_type;
+ u32 ep_interval;
+ u32 max_packet_size;
+ u32 max_burst;
+ u32 mult;
+ u32 esit_pkts;
+
+ ep_type = CTX_TO_EP_TYPE(le32_to_cpu(ep_ctx->ep_info2));
+ ep_interval = CTX_TO_EP_INTERVAL(le32_to_cpu(ep_ctx->ep_info));
+ max_packet_size = MAX_PACKET_DECODED(le32_to_cpu(ep_ctx->ep_info2));
+ max_burst = CTX_TO_MAX_BURST(le32_to_cpu(ep_ctx->ep_info2));
+ mult = CTX_TO_EP_MULT(le32_to_cpu(ep_ctx->ep_info));
+
+ sch_ep->ep_type = ep_type;
+ sch
[PATCH v6 2/5] dt-bindings: Add a binding for Mediatek xHCI host controller
add a DT binding documentation of xHCI host controller for the
MT8173 SoC from Mediatek.
Signed-off-by: Chunfeng Yun
---
.../devicetree/bindings/usb/mt8173-xhci.txt| 52 ++
1 file changed, 52 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt
diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
new file mode 100644
index 000..8e6e463
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
@@ -0,0 +1,52 @@
+mt65XX xHCI
+
+The device node for Mediatek SOC usb3.0 host controller
+
+Required properties:
+ - compatible : should contain "mediatek,mt8173-xhci"
+ - reg : specifies physical base address and size of the registers,
+ the first one for MAC, the second for IPPC
+ - interrupts : interrupt used by the controller
+ - power-domains : a phandle to USB power domain node to control usb's
+ mtcmos
+ - vusb33-supply : regulator of usb avdd3.3v
+
+ - clocks : a list of phandle + clock-specifier pairs, one for each
+ entry in clock-names
+ - clock-names : must contain
+ "sys_ck": for clock of xHCI MAC
+ "wakeup_deb_p0": for usb wakeup debounce clock of port0
+ "wakeup_deb_p0": for usb wakeup debounce clock of port1
+
+ - phys : a list of phandle + phy specifier pairs
+ - usb3-lpm-capable : supports USB3 LPM
+ - mediatek,syscon-wakeup : phandle to syscon used to access usb wakeup
+ control register
+ - mediatek,wakeup-src : 1: ip sleep wakeup mode; 2: line state wakeup
+ mode; others means don't enable wakeup source of usb
+
+Optional properties:
+ - vbus-supply : Reference to the VBUS regulator;
+
+Example:
+usb30: usb@1127 {
+ compatible = "mediatek,mt8173-xhci";
+ reg = <0 0x1127 0 0x4000>,
+ <0 0x1128 0 0x0800>;
+ interrupts = ;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
+ clocks = <&topckgen CLK_TOP_USB30_SEL>,
+<&pericfg CLK_PERI_USB0>,
+<&pericfg CLK_PERI_USB1>;
+ clock-names = "sys_ck",
+ "wakeup_deb_p0",
+ "wakeup_deb_p1";
+ phys = <&phy_port0 PHY_TYPE_USB3>,
+ <&phy_port1 PHY_TYPE_USB2>;
+ vusb33-supply = <&mt6397_vusb_reg>;
+ vbus-supply = <&usb_p1_vbus>;
+ usb3-lpm-capable;
+ mediatek,syscon-wakeup = <&pericfg>;
+ mediatek,wakeup-src = <1>;
+ status = "okay";
+};
--
1.8.1.1.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 1/5] dt-bindings: Add usb3.0 phy binding for MT65xx SoCs
add a DT binding documentation of usb3.0 phy for MT65xx
SoCs from Mediatek.
Signed-off-by: Chunfeng Yun
---
.../devicetree/bindings/phy/phy-mt65xx-usb.txt | 69 ++
1 file changed, 69 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
new file mode 100644
index 000..5812d20
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
@@ -0,0 +1,69 @@
+mt65xx USB3.0 PHY binding
+--
+
+This binding describes a usb3.0 phy for mt65xx platforms of Medaitek SoC.
+
+Required properties (controller (parent) node):
+ - compatible : should be "mediatek,mt8173-u3phy"
+ - reg : offset and length of register for phy, exclude port's
+ register.
+ - clocks : a list of phandle + clock-specifier pairs, one for each
+ entry in clock-names
+ - clock-names : must contain
+ "u3phya_ref": for reference clock of usb3.0 analog phy.
+
+Required nodes : a sub-node is required for each port the controller
+ provides. Address range information including the usual
+ 'reg' property is used inside these nodes to describe
+ the controller's topology. These nodes are translated
+ by the driver's .xlate() function.
+
+Required properties (port (child) node):
+- reg : address and length of the register set for the port.
+- #phy-cells : should be 1 (See second example)
+ cell after port phandle is phy type from:
+ - PHY_TYPE_USB2
+ - PHY_TYPE_USB3
+
+Example:
+
+u3phy: usb-phy@1129 {
+ compatible = "mediatek,mt8173-u3phy";
+ reg = <0 0x1129 0 0x800>;
+ clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
+ clock-names = "u3phya_ref";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "okay";
+
+ phy_port0: port@11290800 {
+ reg = <0 0x11290800 0 0x800>;
+ #phy-cells = <1>;
+ status = "okay";
+ };
+
+ phy_port1: port@11291000 {
+ reg = <0 0x11291000 0 0x800>;
+ #phy-cells = <1>;
+ status = "okay";
+ };
+};
+
+Specifying phy control of devices
+-
+
+Device nodes should specify the configuration required in their "phys"
+property, containing a phandle to the phy port node and a device type;
+phy-names for each port are optional.
+
+Example:
+
+#include
+
+usb30: usb@1127 {
+ ...
+ phys = <&phy_port0 PHY_TYPE_USB3>;
+ phy-names = "usb3-0";
+ ...
+};
--
1.8.1.1.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 3/5] usb: phy: add usb3.0 phy driver for mt65xx SoCs
support usb3.0 phy of mt65xx SoCs Signed-off-by: Chunfeng Yun --- drivers/phy/Kconfig | 9 + drivers/phy/Makefile | 1 + drivers/phy/phy-mt65xx-usb3.c | 456 ++ 3 files changed, 466 insertions(+) create mode 100644 drivers/phy/phy-mt65xx-usb3.c diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index c0e6ede..019cf8b 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -193,6 +193,15 @@ config PHY_HIX5HD2_SATA help Support for SATA PHY on Hisilicon hix5hd2 Soc. +config PHY_MT65XX_USB3 + tristate "Mediatek USB3.0 PHY Driver" + depends on ARCH_MEDIATEK && OF + select GENERIC_PHY + help + Say 'Y' here to add support for Mediatek USB3.0 PHY driver + for mt65xx SoCs. it supports two usb2.0 ports and + one usb3.0 port. + config PHY_SUN4I_USB tristate "Allwinner sunxi SoC USB PHY driver" depends on ARCH_SUNXI && HAS_IOMEM && OF diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile index f344e1b..3ceff2a 100644 --- a/drivers/phy/Makefile +++ b/drivers/phy/Makefile @@ -22,6 +22,7 @@ obj-$(CONFIG_TI_PIPE3)+= phy-ti-pipe3.o obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o obj-$(CONFIG_PHY_EXYNOS5250_SATA) += phy-exynos5250-sata.o obj-$(CONFIG_PHY_HIX5HD2_SATA) += phy-hix5hd2-sata.o +obj-$(CONFIG_PHY_MT65XX_USB3) += phy-mt65xx-usb3.o obj-$(CONFIG_PHY_SUN4I_USB)+= phy-sun4i-usb.o obj-$(CONFIG_PHY_SUN9I_USB)+= phy-sun9i-usb.o obj-$(CONFIG_PHY_SAMSUNG_USB2) += phy-exynos-usb2.o diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c new file mode 100644 index 000..7510fda --- /dev/null +++ b/drivers/phy/phy-mt65xx-usb3.c @@ -0,0 +1,456 @@ +/* + * Copyright (c) 2015 MediaTek Inc. + * Author: Chunfeng Yun + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +/* + * for sifslv2 register, but exclude port's; + * relative to USB3_SIF2_BASE base address + */ +#define SSUSB_SIFSLV_SPLLC 0x + +/* offsets of sub-segment in each port registers */ +#define SSUSB_SIFSLV_U2PHY_COM_BASE0x +#define SSUSB_SIFSLV_U3PHYD_BASE 0x0100 +#define SSUSB_USB30_PHYA_SIV_B_BASE0x0300 +#define SSUSB_SIFSLV_U3PHYA_DA_BASE0x0400 + +#define U3P_USBPHYACR0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x) +#define PA0_RG_U2PLL_FORCE_ON BIT(15) + +#define U3P_USBPHYACR2 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0008) +#define PA2_RG_SIF_U2PLL_FORCE_EN BIT(18) + +#define U3P_USBPHYACR5 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0014) +#define PA5_RG_U2_HSTX_SRCTRL (0x7 << 12) +#define PA5_RG_U2_HSTX_SRCTRL_VAL(x) ((0x7 & (x)) << 12) +#define PA5_RG_U2_HS_100U_U3_ENBIT(11) + +#define U3P_USBPHYACR6 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0018) +#define PA6_RG_U2_ISO_EN BIT(31) +#define PA6_RG_U2_BC11_SW_EN BIT(23) +#define PA6_RG_U2_OTG_VBUSCMP_EN BIT(20) + +#define U3P_U2PHYACR4 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0020) +#define P2C_RG_USB20_GPIO_CTL BIT(9) +#define P2C_USB20_GPIO_MODEBIT(8) +#define P2C_U2_GPIO_CTR_MSK(P2C_RG_USB20_GPIO_CTL | P2C_USB20_GPIO_MODE) + +#define U3D_U2PHYDCR0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0060) +#define P2C_RG_SIF_U2PLL_FORCE_ON BIT(24) + +#define U3P_U2PHYDTM0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0068) +#define P2C_FORCE_UART_EN BIT(26) +#define P2C_FORCE_DATAIN BIT(23) +#define P2C_FORCE_DM_PULLDOWN BIT(21) +#define P2C_FORCE_DP_PULLDOWN BIT(20) +#define P2C_FORCE_XCVRSEL BIT(19) +#define P2C_FORCE_SUSPENDM BIT(18) +#define P2C_FORCE_TERMSEL BIT(17) +#define P2C_RG_DATAIN (0xf << 10) +#define P2C_RG_DATAIN_VAL(x) ((0xf & (x)) << 10) +#define P2C_RG_DMPULLDOWN BIT(7) +#define P2C_RG_DPPULLDOWN BIT(6) +#define P2C_RG_XCVRSEL (0x3 << 4) +#define P2C_RG_XCVRSEL_VAL(x) ((0x3 & (x)) << 4) +#define P2C_RG_SUSPENDMBIT(3) +#define P2C_RG_TERMSEL BIT(2) +#define P2C_DTM0_PART_MASK \ + (P2C_FORCE_DATAIN | P2C_FORCE_DM_PULLDOWN | \ + P2C_FORCE_DP_PULLDOWN | P2C_FORCE_XCVRSEL | \ + P2C_FORCE_TERMSEL | P2C_RG_DMPULLDOWN | \ + P2C_RG_DPPULLDOWN | P2C_
Re: [PATCH] usb: gadget: f_uac1: Convert use of __constant_cpu_to_le16 to cpu_to_le16
On Thu, Aug 20, 2015 at 4:20 PM, David Laight wrote:
> From: Vaishali Thakkar
>> Sent: 19 August 2015 06:31
>> To: Felipe Balbi
>> Cc: Greg Kroah-Hartman; linux-usb@vger.kernel.org;
>> linux-ker...@vger.kernel.org
>> Subject: [PATCH] usb: gadget: f_uac1: Convert use of __constant_cpu_to_le16
>> to cpu_to_le16
>>
>> In big endian cases, macro cpu_to_le16 unfolds to __swab16 which
>> provides special case for constants. In little endian cases,
>> __constant_cpu_to_le16 and cpu_to_le16 expand directly to the
>> same expression. So, replace __constant_cpu_to_le16 with
>> cpu_to_le16 with the goal of getting rid of the definition of
>> __constant_cpu_to_le16 completely.
>>
>> The semantic patch that performs this transformation is as follows:
>>
>> @@expression x;@@
>>
>> - __constant_cpu_to_le16(x)
>> + cpu_to_le16(x)
>>
>> Signed-off-by: Vaishali Thakkar
>> ---
>> drivers/usb/gadget/function/f_uac1.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/function/f_uac1.c
>> b/drivers/usb/gadget/function/f_uac1.c
>> index 7856b33..5aa8d8a 100644
>> --- a/drivers/usb/gadget/function/f_uac1.c
>> +++ b/drivers/usb/gadget/function/f_uac1.c
>> @@ -57,8 +57,8 @@ static struct uac1_ac_header_descriptor_1 ac_header_desc =
>> {
>> .bLength = UAC_DT_AC_HEADER_LENGTH,
>> .bDescriptorType = USB_DT_CS_INTERFACE,
>> .bDescriptorSubtype = UAC_HEADER,
>> - .bcdADC = __constant_cpu_to_le16(0x0100),
>> - .wTotalLength = __constant_cpu_to_le16(UAC_DT_TOTAL_LENGTH),
>> + .bcdADC = cpu_to_le16(0x0100),
>> + .wTotalLength = cpu_to_le16(UAC_DT_TOTAL_LENGTH),
>
> Have you test compiled this on a big-endian system?
> My gut feeling is that is fails.
No. I have tested it on little-endian system only. But I'll
be really surprised if this will fail. Can you please tell me
if I am missing something in this particular case or same
applies for other cases because most of the cases like
__constant_ are already converted to ?
As far as I know, if the argument is a constant the
conversion happens at compile time. And unfolding both
definitions returns to same expression. Still I am trying if
someone can test it for me on big endian system.
> David
>
--
Vaishali
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
