Re: [PATCH] usb: gadget: f_uac2: modulate playback data rate
On Fri, Aug 29, 2014 at 11:43 AM, Jassi Brar wrote:
> The UAC2 function driver currently responds to all packets at all times
> with wMaxPacketSize packets. That results in way too fast audio
> playback as the function driver (which is in fact supposed to define
> the audio stream pace) delivers as fast as it can.
>
> We need data rate to match, as accurately as possible, the sampling rate
> expressed by the UAC2 topology to the Host.
>
> We do this by sending packets of varying length (1 sample more than usual)
> in a pattern so that we get the desired data rate over a period of a
> second or sooner. The payload pattern is calculated only once (using
> "Alan's Algo"), when the Host enables the interface, and saved in an
> array so that the 2 ping-pong usb_requests directly index into the
> pattern array to figure out the payload length they are supposed to
> transfer next. Note that the increased overhead in agdev_iso_complete()
> is almost zero.
>
> Signed-off-by: Jassi Brar
> ---
> drivers/usb/gadget/function/f_uac2.c | 70
> ++--
> 1 file changed, 67 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/f_uac2.c
> b/drivers/usb/gadget/function/f_uac2.c
> index 246a778..84fd3b0 100644
> --- a/drivers/usb/gadget/function/f_uac2.c
> +++ b/drivers/usb/gadget/function/f_uac2.c
> @@ -59,8 +59,15 @@ const char *uac2_name = "snd_uac2";
> struct uac2_req {
> struct uac2_rtd_params *pp; /* parent param */
> struct usb_request *req;
> + unsigned idx; /* current element of length-pattern loop */
> };
>
> +/*
> + * 5512.5Hz is going to need the maximum number of elements (80),
> + * in the length-pattern loop, among standard ALSA supported rates.
> + */
> +#define MAX_LOOP_LEN 80
> +
> struct uac2_rtd_params {
> struct snd_uac2_chip *uac2; /* parent chip */
> bool ep_enabled; /* if the ep is enabled */
> @@ -80,6 +87,9 @@ struct uac2_rtd_params {
> unsigned max_psize;
> struct uac2_req ureq[USB_XFERS];
>
> + unsigned pattern[MAX_LOOP_LEN];
> + unsigned plen; /* valid entries in pattern[] */
> +
> spinlock_t lock;
> };
>
> @@ -191,8 +201,12 @@ agdev_iso_complete(struct usb_ep *ep, struct usb_request
> *req)
>
> spin_lock_irqsave(&prm->lock, flags);
>
> - if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
> + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
> + /* Update length for next payload */
> + ur->idx = (ur->idx + USB_XFERS) % prm->plen;
> + req->length = prm->pattern[ur->idx];
> req->actual = req->length;
> + }
>
> pending = prm->hw_ptr % prm->period_size;
> pending += req->actual;
> @@ -1066,6 +1080,31 @@ err:
> return -EINVAL;
> }
>
> +/*
> + * Find optimal pattern of payloads for a given number
> + * of samples and maximum sync period (in ms) over which
> + * we have to distribute them uniformly.
> + */
> +static unsigned
> +get_pattern(unsigned samples, unsigned sync, unsigned *pt)
> +{
> + unsigned n, x = 0, i = 0, p = samples % sync;
> +
> + do {
> + x += p;
> + n = samples / sync;
> + if (x >= sync) {
> + n += 1;
> + x -= sync;
> + }
> + if (pt)
> + pt[i] = n;
> + i++;
> + } while (x);
> +
> + return i;
> +}
> +
> static int
> afunc_set_alt(struct usb_function *fn, unsigned intf, unsigned alt)
> {
> @@ -1097,11 +1136,35 @@ afunc_set_alt(struct usb_function *fn, unsigned intf,
> unsigned alt)
> if (intf == agdev->as_out_intf) {
> ep = agdev->out_ep;
> prm = &uac2->c_prm;
> + prm->plen = 1;
> + prm->pattern[0] = prm->max_psize;
> config_ep_by_speed(gadget, fn, ep);
> agdev->as_out_alt = alt;
> } else if (intf == agdev->as_in_intf) {
> + struct f_uac2_opts *opts = agdev_to_uac2_opts(agdev);
> + unsigned intvl, rate;
> +
> + if (gadget->speed == USB_SPEED_FULL)
> + intvl = (1 << (fs_epin_desc.bInterval - 1)) * 1000;
> + else
> + intvl = (1 << (hs_epin_desc.bInterval - 1)) * 125;
> +
> + rate = opts->p_srate;
> + if (rate == 5512) { /* which implies 5512.5 practically */
> + rate = 55125;
> + intvl *= 10;
> + }
> +
> ep = agdev->in_ep;
> prm = &uac2->p_prm;
> + prm->plen = get_pattern(rate, intvl, NULL); /* dry run */
> + /* We try to support arbitrary rates too */
> + if (prm->plen > MAX_LOOP_LEN) {
> + prm->plen = 1;
> + prm->pattern[0] = rate / intvl;
> + } else
[PATCH] usb: gadget: f_uac2: modulate playback data rate
The UAC2 function driver currently responds to all packets at all times
with wMaxPacketSize packets. That results in way too fast audio
playback as the function driver (which is in fact supposed to define
the audio stream pace) delivers as fast as it can.
We need data rate to match, as accurately as possible, the sampling rate
expressed by the UAC2 topology to the Host.
We do this by sending packets of varying length (1 sample more than usual)
in a pattern so that we get the desired data rate over a period of a
second or sooner. The payload pattern is calculated only once (using
"Alan's Algo"), when the Host enables the interface, and saved in an
array so that the 2 ping-pong usb_requests directly index into the
pattern array to figure out the payload length they are supposed to
transfer next. Note that the increased overhead in agdev_iso_complete()
is almost zero.
Signed-off-by: Jassi Brar
---
drivers/usb/gadget/function/f_uac2.c | 70 ++--
1 file changed, 67 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/function/f_uac2.c
b/drivers/usb/gadget/function/f_uac2.c
index 246a778..84fd3b0 100644
--- a/drivers/usb/gadget/function/f_uac2.c
+++ b/drivers/usb/gadget/function/f_uac2.c
@@ -59,8 +59,15 @@ const char *uac2_name = "snd_uac2";
struct uac2_req {
struct uac2_rtd_params *pp; /* parent param */
struct usb_request *req;
+ unsigned idx; /* current element of length-pattern loop */
};
+/*
+ * 5512.5Hz is going to need the maximum number of elements (80),
+ * in the length-pattern loop, among standard ALSA supported rates.
+ */
+#define MAX_LOOP_LEN 80
+
struct uac2_rtd_params {
struct snd_uac2_chip *uac2; /* parent chip */
bool ep_enabled; /* if the ep is enabled */
@@ -80,6 +87,9 @@ struct uac2_rtd_params {
unsigned max_psize;
struct uac2_req ureq[USB_XFERS];
+ unsigned pattern[MAX_LOOP_LEN];
+ unsigned plen; /* valid entries in pattern[] */
+
spinlock_t lock;
};
@@ -191,8 +201,12 @@ agdev_iso_complete(struct usb_ep *ep, struct usb_request
*req)
spin_lock_irqsave(&prm->lock, flags);
- if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+ if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
+ /* Update length for next payload */
+ ur->idx = (ur->idx + USB_XFERS) % prm->plen;
+ req->length = prm->pattern[ur->idx];
req->actual = req->length;
+ }
pending = prm->hw_ptr % prm->period_size;
pending += req->actual;
@@ -1066,6 +1080,31 @@ err:
return -EINVAL;
}
+/*
+ * Find optimal pattern of payloads for a given number
+ * of samples and maximum sync period (in ms) over which
+ * we have to distribute them uniformly.
+ */
+static unsigned
+get_pattern(unsigned samples, unsigned sync, unsigned *pt)
+{
+ unsigned n, x = 0, i = 0, p = samples % sync;
+
+ do {
+ x += p;
+ n = samples / sync;
+ if (x >= sync) {
+ n += 1;
+ x -= sync;
+ }
+ if (pt)
+ pt[i] = n;
+ i++;
+ } while (x);
+
+ return i;
+}
+
static int
afunc_set_alt(struct usb_function *fn, unsigned intf, unsigned alt)
{
@@ -1097,11 +1136,35 @@ afunc_set_alt(struct usb_function *fn, unsigned intf,
unsigned alt)
if (intf == agdev->as_out_intf) {
ep = agdev->out_ep;
prm = &uac2->c_prm;
+ prm->plen = 1;
+ prm->pattern[0] = prm->max_psize;
config_ep_by_speed(gadget, fn, ep);
agdev->as_out_alt = alt;
} else if (intf == agdev->as_in_intf) {
+ struct f_uac2_opts *opts = agdev_to_uac2_opts(agdev);
+ unsigned intvl, rate;
+
+ if (gadget->speed == USB_SPEED_FULL)
+ intvl = (1 << (fs_epin_desc.bInterval - 1)) * 1000;
+ else
+ intvl = (1 << (hs_epin_desc.bInterval - 1)) * 125;
+
+ rate = opts->p_srate;
+ if (rate == 5512) { /* which implies 5512.5 practically */
+ rate = 55125;
+ intvl *= 10;
+ }
+
ep = agdev->in_ep;
prm = &uac2->p_prm;
+ prm->plen = get_pattern(rate, intvl, NULL); /* dry run */
+ /* We try to support arbitrary rates too */
+ if (prm->plen > MAX_LOOP_LEN) {
+ prm->plen = 1;
+ prm->pattern[0] = rate / intvl;
+ } else {
+ prm->plen = get_pattern(rate, intvl, prm->pattern);
+ }
config_ep_by_speed(gadget, fn, ep);
agdev->as_in_alt = alt;
} else {
@@ -1125,12 +1188,13 @@ afunc_set_alt(struct usb_function *fn, unsigned intf,
unsigned alt)
Re: [PATCH V5 2/2] usbtest: Add interrupt EP testcases
Felipe, I just checked your testing/next branch. 'git log' of that branch doesn't show the complete commit log of this patch. On 8/22/2014 2:36 PM, Amit VIRDI wrote: Two simple test cases for interrupt endpoints are added to the usbtest.c file. These are simple non-queued interrupt IN and interrupt OUT transfers. Currently, only gadget zero is capable of executing the interrupt EP test cases. However, extending the same to other gadgets is extremely simple and can be done on-demand. The two new tests added are - Test 25: To verify Interrupt OUT transfer - Test 26: To verify Interrupt IN transfer Since the default value of wMaxPacketSize is set as 1024, so interrupt IN transfers must be specified with the size parameter = multiple of 1024. Otherwise the default value (512) in the usbtest application fails the transfer. See [RUN 4] for sample logs The application logs (usbtest) and corresponding kernel logs are as following: It only shows up to here. Rest of the commit log is missing. --- I guess this is the culprit... [Run 1] ./testusb -a -c 10 -s 2048 -t 26 -v 511 Jul 17 10:31:13 dlhl1014 kernel: [72056.950910] usbtest 7-1:3.0: TEST 26: read 2048 bytes 10 times [Run 2] ./testusb -a -c 10 -s 1024 -t 25 -v 511 Jul 17 10:31:29 dlhl1014 kernel: [72072.834853] usbtest 7-1:3.0: TEST 25: write 1024 bytes 10 times [Run 3] ./testusb -a -c 10 -s 1098 -t 25 -v 511 Jul 17 10:31:39 dlhl1014 kernel: [72082.322219] usbtest 7-1:3.0: TEST 25: write 1098 bytes 10 times [Run 4 - Failure case scenario] ./testusb -a -t 26 unknown speed /dev/bus/usb/007/0040 /dev/bus/usb/007/004 test 26 --> 75 (Value too large for defined data type) Jul 17 11:11:30 dlhl1014 kernel: [74473.347219] usbtest 7-1:3.0: TEST 26: read 512 bytes 1000 times Jul 17 11:11:30 dlhl1014 kernel: [74473.348959] usb 7-1: test26 failed, iterations left 999, status -75 (not 0) --- This code has been tested only with gadget zero and care has been taken so as to not break the existing functionality. However, if anyone can test with other gadgets then that would be great! Signed-off-by: Amit Virdi --- drivers/usb/misc/usbtest.c | 113 +++-- 1 file changed, 98 insertions(+), 15 deletions(-) Please let me know if there's anything I can help with. Regards Amit Virdi -- 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/1] USB: Add device quirk for ASUS T100 Base Station keyboard
This full-speed USB device generates spurious remote wakeup event
as soon as USB_DEVICE_REMOTE_WAKEUP feature is set. As the result,
Linux can't enter system suspend and S0ix power saving modes once
this keyboard is used.
This patch tries to introduce USB_QUIRK_IGNOR_REMOTE_WAKEUP quirk.
With this quirk set, wakeup capability will be ignored during
device configure.
This patch could be back-ported to kernels as old as 2.6.39.
Signed-off-by: Lu Baolu
---
drivers/usb/core/hub.c | 6 --
drivers/usb/core/quirks.c | 4
include/linux/usb/quirks.h | 3 +++
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 8a4dcbc..5df1457 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1977,8 +1977,10 @@ void usb_set_device_state(struct usb_device *udev,
|| new_state == USB_STATE_SUSPENDED)
; /* No change to wakeup settings */
else if (new_state == USB_STATE_CONFIGURED)
- wakeup = udev->actconfig->desc.bmAttributes
-& USB_CONFIG_ATT_WAKEUP;
+ wakeup = (udev->quirks &
+ USB_QUIRK_IGNOR_REMOTE_WAKEUP) ? 0 :
+ udev->actconfig->desc.bmAttributes &
+ USB_CONFIG_ATT_WAKEUP;
else
wakeup = 0;
}
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index bae636e..e7d1e3c 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -159,6 +159,10 @@ static const struct usb_device_id usb_quirk_list[] = {
/* USB3503 */
{ USB_DEVICE(0x0424, 0x3503), .driver_info = USB_QUIRK_RESET_RESUME },
+ /* ASUS Base Station(T100) */
+ { USB_DEVICE(0x0b05, 0x17e0), .driver_info =
+ USB_QUIRK_IGNOR_REMOTE_WAKEUP },
+
{ } /* terminating entry must be last */
};
diff --git a/include/linux/usb/quirks.h b/include/linux/usb/quirks.h
index 55a17b1..0f784c3 100644
--- a/include/linux/usb/quirks.h
+++ b/include/linux/usb/quirks.h
@@ -41,4 +41,7 @@
*/
#define USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL 0x0080
+/* device generates spurious wakeup, ignore remote wakeup capability */
+#define USB_QUIRK_IGNOR_REMOTE_WAKEUP 0x0100
+
#endif /* __LINUX_USB_QUIRKS_H */
--
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
Bind usb device to another class driver
hi all: I have read the article below and try to do the same operation on my device. http://lwn.net/Articles/143397/ My environment: 1. my kernel is 3.16 2. device descriptor is attached. 3. below are my operation logs: # echo -n "4-2:1.0" > /sys/bus/usb/drivers/uas/unbind # echo -n "4-2:1.0" > /sys/bus/usb/drivers/usb-storage/unbind bash: echo: write error: No such device # My questions: 1. is there anything I need to do, such as PCI driver, before bind to usb-storage driver? 2. I can check whether the usb device is bound to specific driver through "cat /sys/kernel/debug/usb/devices". is there any alternative way to do so? how about other drivers, except usb, to let user know whether the binding/unbinding successfully and which device is bound to which driver? thanks for your help in advance, usb_hd_desc.tar.bz2 Description: BZip2 compressed data
RE: [RFC PATCH 0/7] usb: gadget: add reset API at usb_gadget_driver
> On Thu, 28 Aug 2014, Alan Stern wrote: > > > Okay, so we need to add a "vbus_is_on" flag to the usb_gadget > > structure. The gadget driver will set this flag in its connect > > callback and clear the flag in its disconnect callback. If the UDC > > driver doesn't have a Vbus handler, it will invoke the connect > > callback just once during startup, and it will invoke the disconnect > > callback just once during removal. > > After more thought, if the vbus_is_on flag is going to be controlled by > the gadget driver rather than the UDC driver, then it really belongs in > the gadget driver's private data structure and not in struct usb_gadget. > Also, a better name for the flag would be "is_connected". > Yes, we should have some places to change "is_connected", that is one of thing we are discussing. > > The gadget driver should include an adjust_pullup() routine. It > > should get called whenever a function is activated or deactivated, and > > also by the connect and disconnect callbacks. The logic is simple: > > > > If (any functions are deactivated) > > turn off the pullup > > else if (gadget->vbus_is_on) > > turn on the pullup > > else > > turn off the pullup > > This logic can be compressed a little: > > if (!is_connected || any functions are deactivated) > turn off the pullup > else > turn on the pullup > Thanks, Alan. I have a similar implementation at below, http://www.spinics.net/lists/linux-usb/msg111976.html Peter -- 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: [RFC PATCH 0/7] usb: gadget: add reset API at usb_gadget_driver
On Thu, Aug 28, 2014 at 09:56:06AM -0500, Felipe Balbi wrote: > Hi, > > > > > For other three stages (no need to control at bus_reset), we can > > > > control dp > > > > at two gadget driver's API relies on flag pullup_on_vbus. > > > > > > I also can't get what you mean here. > > > > If the UDC driver doesn't want to pull up dp at insmod gadget driver, it > > can pull up dp when the cable is connected. > > how will UDC know that cable was connected if its pullups aren't > connected ? > Through vbus handler, these kinds of udc has flag pullup_on_vbus. > > > > Do you agree above? > > > > > > > > If you agree, the first patchset for adding reset API at > > > > usb_gadget_driver may > > > > do less thing, and the reset API implementation at each gadget driver > > > > is the > > > > same with disconnect. > > > > > > that's why we never had a ->reset() callback so far. From a gadget > > > driver perspective, it's the same as disconnect followed by a connect. > > > > Yes, it is the current design, but if we want to call usb_gadget_disconnect > > at ->disconnect callback, things will be different, besides, the kernel > > doc says it is invoked when "when the host is disconnected". > > you shouldn't call usb_gadget_disconnect() from ->disconnect(). It's the > other way around. You get a disconnect IRQ, then you call gadget > driver's ->disconnect(), but gadget driver doesn't need to ask UDC to > remove pullup at that time. Not every UDC driver has disconnect IRQ. > > This has been getting more and more confusing of a problem. I'll go curl > down in a corner and think about it :-) > Felipe & Alan, thanks for your comments for these patches, I think I may need to list these issues again to make things clearer. The purpose of these patchsets are to fix two issues: - Some udcs failures at USB-IF certification Back-Voltage test, it needs the dp is not pulled up when the vbus is not there, usb 2.0 spec 7.2.1 and 7.1.5 require it. - Some function drivers (f_uvc, f_obex, and android functions later) do not want to pull up dp at the udc_start, they want it on demand, like app has run. So, we can't pull up dp unconditionally at udc-core, I proposal the strategy for pulling up dp after below two conditions are satisfied [1]: - If the udc is ready to pull up dp - all functions at gadget driver want to pullup dp, it will pull up dp. The first condition depends on UDCs, Some UDCs(UDC-A) doesn't need to clear software pull up(run/stop) bit after vbus has disconnected, the possible reason may these kinds of UDC have hardware logic to disable pullup at dp when the vbus is not there, then it can pass back-voltage test, so for these kinds of UDCs, they are always ready to pull up dp. But for other UDCs(UDC-B, like chipidea), it needs to clear pullup bit after vbus has disconnected to pass back-voltage test, for these kinds of UDCs, they are only ready to pull up dp when the vbus is there. The second condition are the same for all UDCs, the function/gadget driver determine it. The patchset[1] has implemented above idea, UDC-A is always ready to pull up dp, it will set ready (connect) bit at the end of udc_start, and UDC-B will be ready when the vbus is there.[2], and the dp control strategy is decided by two conditions[3]. Alan concerns why the .connect API has **connect** argument, the reason is we need to call it at vbus handler to disable pullup bit when the vbus is not there. It is indeed strange we have **connect** argument at .connect, but current .disconnect API does not call usb_gadget_disconnect, so we have no way to pull down dp when the vbus is not there, that is the story we have this patchset and discussion. What's the next step for me? [1] http://www.spinics.net/lists/linux-usb/msg111969.html [2] http://www.spinics.net/lists/linux-usb/msg111973.html [3] http://www.spinics.net/lists/linux-usb/msg111976.html -- 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
Re: Status of g_webcam uvc-gadget
Hi Ricardo, On Wednesday 27 August 2014 18:09:13 Ricardo Ribalda Delgado wrote: > Hello > > Is somebody using/supporting g_webcam? I believe so, as I get kernel patches from time to time. > The only reference userland server is uvc-gadget from > http://git.ideasonboard.org/?p=uvc-gadget.git;a=summary ? That's the only public userspace implementation I know of. And I should be blamed for not having taken the time to properly review and apply Bhupesh's patches :-/ > I have an industrial fpga camera that speaks v4l2, my plan is to > export it as an uvc camera via usb3380 as a debug interface. -- Regards, Laurent Pinchart -- 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: dwc3: exynos: remove usb_phy_generic support
On Thu, Aug 28, 2014 at 08:11:04PM +0200, Bartlomiej Zolnierkiewicz wrote:
>
> [ added Alan and Greg to cc: ]
>
> Hi,
>
> On Wednesday, August 27, 2014 11:42:25 PM Vivek Gautam wrote:
> > Hi Baltlomiej,
> >
> >
> > On Wed, Aug 27, 2014 at 1:22 PM, Bartlomiej Zolnierkiewicz
> > wrote:
> > > dwc3 driver is using the new Exynos5 SoC series USB DRD PHY driver
> > > (PHY_EXYNOS5_USBDRD which selects GENERIC_PHY) as can be seen by
> > > looking at the following commits:
> > >
> > > 7a4cf0fde054 ("ARM: dts: Update DWC3 usb controller to use new
> > > phy driver for exynos5250")
> > >
> > > f070267b5fc1 ("ARM: dts: Enable support for DWC3 controller for
> > > exynos5420")
> > >
> > > Thus remove unused usb_phy_generic support from dwc3 Exynos glue
> > > layer.
> > >
> > > [ The code that is being removed is harmful in the context of
> > > multi_v7_defconfig and enabling "EHCI support for Samsung
> > > S5P/EXYNOS SoC Series" (USB_EHCI_EXYNOS) + "OHCI support for
> > > Samsung S5P/EXYNOS SoC Series" (USB_OHCI_EXYNOS) because "EHCI
> > > support for OMAP3 and later chips" (USB_EHCI_HCD_OMAP) selects
> > > "NOP USB Transceiver Driver" (NOP_USB_XCEIV). NOP USB driver
> > > attaches itself to usb_phy_generic platform devices created by
> > > dwc3 Exynos glue layer and later causes Exynos EHCI driver to
> > > fail probe and Exynos OHCI driver to hang on probe (as observed
> > > on Exynos5250 Arndale board). ]
> >
> > The issue with EHCI and OHCI on exynos platforms is that until now
> > they also request
> > usb-phy and only later if they don't find one, they go ahead and get a
> > 'phy' generic.
> >
> > Fortunately we missed this issue with exynos_defconfig, and as you rightly
> > mentioned with multi_v7_defconfig, the NOP_USB_XCEIV gets enabled and
> > EHCI and OHCI exynos get no-op usb-phy, which actually blocks EHCI/OHCI from
> > initializing the real PHYs.
> >
> > This issue is resolved with patches:
> > [PATCH v2 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support
> > [PATCH v2 2/2] usb: host: ohci-exynos: Remove unnecessary usb-phy support
> > wherein we are completely removing the usb-phy support from
> > ehci/ohci-exynos.
> > So with these patches we should not see the issue mentioned by you.
>
> Indeed, your patches fix the issue.
>
> Greg, could these two patches ([1] & [2]) get merged quickly, pretty please
> (they were already acked by Alan)? They are not a mere cleanups because
> they fix the actual problem with using multi_v7_defconfig which in turn has
> been blocking Olof's defconfig update patch [3] for quite some time now.
> Moreover these patches are limited to Exynos host drivers so they should be
> pretty safe when it comes to potential regressions.
>
> [1] http://www.spinics.net/lists/linux-usb/msg112294.html
> [2] http://www.spinics.net/lists/linux-usb/msg112293.html
> [3] http://www.spinics.net/lists/arm-kernel/msg349654.html
merged for 3.18-rc1, or do you "need" them for 3.17-final?
I already reverted one patch for exynos for 3.17-final that is sitting
in my tree to go to Linus soon as you all didn't seem to want it
anymore, so I'm getting really confused here...
thanks,
greg k-h
--
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 4/5] usb: dwc3: Adding Kconfig dependency for Exynos7
On Thu, Aug 28, 2014 at 01:31:59PM +0530, Vivek Gautam wrote: > The Exynos-DWC3 USB 3.0 DRD controller is also present on > Exynos7 platform, so adding the dependency on ARCH_EXYNOS7 > for this driver. > > Signed-off-by: Vivek Gautam > --- > drivers/usb/dwc3/Kconfig |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig > index 785510a..e235894 100644 > --- a/drivers/usb/dwc3/Kconfig > +++ b/drivers/usb/dwc3/Kconfig > @@ -55,7 +55,7 @@ config USB_DWC3_OMAP > > config USB_DWC3_EXYNOS > tristate "Samsung Exynos Platform" > - depends on ARCH_EXYNOS || COMPILE_TEST > + depends on (ARCH_EXYNOS || ARCH_EXYNOS7) || COMPILE_TEST wait when building for ARCH_EXYNOS7 you don't get ARCH_EXYNOS ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 3/5] phy: exynos5-usbdrd: Add facility for VBUS-BOOST-5V supply
hi,
On Thu, Aug 28, 2014 at 01:31:58PM +0530, Vivek Gautam wrote:
> @@ -457,11 +458,19 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
> clk_prepare_enable(phy_drd->ref_clk);
>
> /* Enable VBUS supply */
> + if (phy_drd->vbus_boost) {
> + ret = regulator_enable(phy_drd->vbus_boost);
> + if (ret) {
> + dev_err(phy_drd->dev,
> + "Failed to enable VBUS boost supply\n");
> + goto fail_vbus;
> + }
> + }
really this is nitpicking, but can you add a blank line here just make
my inner child happy ? :-)
> @@ -470,6 +479,9 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
>
> return 0;
>
> +fail_vbus_boost:
> + if (phy_drd->vbus_boost)
> + regulator_disable(phy_drd->vbus_boost);
same here
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 2/5] phy: exynos5-usbdrd: Add pipe-clk and utmi-clk support
On Thu, Aug 28, 2014 at 09:01:57AM +0100, Vivek Gautam wrote:
> Exynos7 SoC has now separate gate control for 125MHz pipe3 phy
> clock, as well as 60MHz utmi phy clock.
> So get the same and control in the phy-exynos5-usbdrd driver.
>
> Signed-off-by: Vivek Gautam
> ---
> .../devicetree/bindings/phy/samsung-phy.txt|4
> drivers/phy/phy-exynos5-usbdrd.c | 24
>
> 2 files changed, 28 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> index 7a6feea..b64d616 100644
> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> @@ -135,6 +135,10 @@ Required properties:
> PHY operations, associated by phy name. It is used to
> determine bit values for clock settings register.
> For Exynos5420 this is given as 'sclk_usbphy30' in CMU.
> + - optional clocks: Next gen Exynos SoCs have following additional
It's not going to be 'Next gen' for long...
> +gate clocks available:
> +- phy_pipe: for PIPE3 phy
> +- phy_utmi: for UTMI+ phy
> - samsung,pmu-syscon: phandle for PMU system controller interface, used to
> control pmu registers for power isolation.
> - #phy-cells : from the generic PHY bindings, must be 1;
> diff --git a/drivers/phy/phy-exynos5-usbdrd.c
> b/drivers/phy/phy-exynos5-usbdrd.c
> index b05302b..685c108 100644
> --- a/drivers/phy/phy-exynos5-usbdrd.c
> +++ b/drivers/phy/phy-exynos5-usbdrd.c
> @@ -148,6 +148,8 @@ struct exynos5_usbdrd_phy_drvdata {
> * @dev: pointer to device instance of this platform device
> * @reg_phy: usb phy controller register memory base
> * @clk: phy clock for register access
> + * @pipeclk: clock for pipe3 phy
> + * @utmiclk: clock for utmi+ phy
> * @drv_data: pointer to SoC level driver data structure
> * @phys[]: array for 'EXYNOS5_DRDPHYS_NUM' number of PHY
> * instances each with its 'phy' and 'phy_cfg'.
> @@ -161,6 +163,8 @@ struct exynos5_usbdrd_phy {
> struct device *dev;
> void __iomem *reg_phy;
> struct clk *clk;
> + struct clk *pipeclk;
> + struct clk *utmiclk;
> const struct exynos5_usbdrd_phy_drvdata *drv_data;
> struct phy_usb_instance {
> struct phy *phy;
> @@ -446,6 +450,10 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
>
> dev_dbg(phy_drd->dev, "Request to power_on usbdrd_phy phy\n");
>
> + if (!IS_ERR(phy_drd->utmiclk))
> + clk_prepare_enable(phy_drd->utmiclk);
> + if (!IS_ERR(phy_drd->pipeclk))
> + clk_prepare_enable(phy_drd->pipeclk);
> clk_prepare_enable(phy_drd->ref_clk);
>
> /* Enable VBUS supply */
> @@ -464,6 +472,10 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
>
> fail_vbus:
> clk_disable_unprepare(phy_drd->ref_clk);
> + if (!IS_ERR(phy_drd->pipeclk))
> + clk_disable_unprepare(phy_drd->pipeclk);
> + if (!IS_ERR(phy_drd->utmiclk))
> + clk_disable_unprepare(phy_drd->utmiclk);
>
> return ret;
> }
> @@ -483,6 +495,10 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
> regulator_disable(phy_drd->vbus);
>
> clk_disable_unprepare(phy_drd->ref_clk);
> + if (!IS_ERR(phy_drd->pipeclk))
> + clk_disable_unprepare(phy_drd->pipeclk);
> + if (!IS_ERR(phy_drd->utmiclk))
> + clk_disable_unprepare(phy_drd->utmiclk);
>
> return 0;
> }
> @@ -581,6 +597,14 @@ static int exynos5_usbdrd_phy_probe(struct
> platform_device *pdev)
> return PTR_ERR(phy_drd->clk);
> }
>
> + phy_drd->pipeclk = devm_clk_get(dev, "phy_pipe");
> + if (IS_ERR(phy_drd->pipeclk))
> + dev_warn(dev, "Failed to get pipe3 phy operational clock\n");
> +
> + phy_drd->utmiclk = devm_clk_get(dev, "phy_utmi");
> + if (IS_ERR(phy_drd->utmiclk))
> + dev_warn(dev, "Failed to get utmi phy operational clock\n");
> +
Pointless warnings for !Exynos7?
Would it not be better to set these to NULL and not litter the code with
IS_ERR checks?
Mark.
--
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/5] usb: dwc3: exynos: Add support for SCLK present on Exynos7
On Thu, Aug 28, 2014 at 09:01:56AM +0100, Vivek Gautam wrote:
> Exynos7 also has a separate special gate clock going to the IP
> apart from the usual AHB clock. So add support for the same.
>
> Signed-off-by: Vivek Gautam
> ---
> drivers/usb/dwc3/dwc3-exynos.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
> index f9fb8ad..bab6395 100644
> --- a/drivers/usb/dwc3/dwc3-exynos.c
> +++ b/drivers/usb/dwc3/dwc3-exynos.c
> @@ -35,6 +35,7 @@ struct dwc3_exynos {
> struct device *dev;
>
> struct clk *clk;
> + struct clk *sclk;
> struct regulator*vdd33;
> struct regulator*vdd10;
> };
> @@ -141,10 +142,17 @@ static int dwc3_exynos_probe(struct platform_device
> *pdev)
> return -EINVAL;
> }
>
> + /* Exynos7 has a special gate clock going to this IP */
> + exynos->sclk = devm_clk_get(dev, "usbdrd30_sclk");
> + if (IS_ERR(exynos->sclk))
> + dev_warn(dev, "couldn't get sclk\n");
Doesn't this introduce a pointless warning for Exynos SoCs other than
Exynos7?
> +
> exynos->dev = dev;
> exynos->clk = clk;
>
> clk_prepare_enable(exynos->clk);
> + if (!IS_ERR(exynos->sclk))
> + clk_prepare_enable(exynos->sclk);
If you replaced the returned err value with NULL you could avoid these
IS_ERR cases.
Mark.
>
> exynos->vdd33 = devm_regulator_get(dev, "vdd33");
> if (IS_ERR(exynos->vdd33)) {
> @@ -187,6 +195,8 @@ err4:
> err3:
> regulator_disable(exynos->vdd33);
> err2:
> + if (!IS_ERR(exynos->sclk))
> + clk_disable_unprepare(exynos->sclk);
> clk_disable_unprepare(clk);
> return ret;
> }
> @@ -199,6 +209,8 @@ static int dwc3_exynos_remove(struct platform_device
> *pdev)
> platform_device_unregister(exynos->usb2_phy);
> platform_device_unregister(exynos->usb3_phy);
>
> + if (!IS_ERR(exynos->sclk))
> + clk_disable_unprepare(exynos->sclk);
> clk_disable_unprepare(exynos->clk);
>
> regulator_disable(exynos->vdd33);
> @@ -220,6 +232,8 @@ static int dwc3_exynos_suspend(struct device *dev)
> {
> struct dwc3_exynos *exynos = dev_get_drvdata(dev);
>
> + if (!IS_ERR(exynos->sclk))
> + clk_disable(exynos->sclk);
> clk_disable(exynos->clk);
>
> regulator_disable(exynos->vdd33);
> @@ -245,6 +259,8 @@ static int dwc3_exynos_resume(struct device *dev)
> }
>
> clk_enable(exynos->clk);
> + if (!IS_ERR(exynos->sclk))
> + clk_enable(exynos->sclk);
>
> /* runtime set active to reflect active state. */
> pm_runtime_disable(dev);
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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: phy: twl6030-usb: Remove unused irq_enabled
It's not being used any longer.
Signed-off-by: Tony Lindgren
---
Felipe, here's the twl6030 only version for you to pick.
--- a/drivers/usb/phy/phy-twl6030-usb.c
+++ b/drivers/usb/phy/phy-twl6030-usb.c
@@ -104,7 +104,6 @@ struct twl6030_usb {
int irq2;
enum omap_musb_vbus_id_status linkstat;
u8 asleep;
- boolirq_enabled;
boolvbus_enable;
const char *regulator;
};
@@ -373,7 +372,6 @@ static int twl6030_usb_probe(struct platform_device *pdev)
INIT_WORK(&twl->set_vbus_work, otg_set_vbus_work);
- twl->irq_enabled = true;
status = request_threaded_irq(twl->irq1, NULL, twl6030_usbotg_irq,
IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING |
IRQF_ONESHOT,
"twl6030_usb", twl);
--
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/5] usb: phy: twl4030-usb: Remove unused irq_enabled
* Felipe Balbi [140827 19:21]:
> Hi,
>
> On Wed, Aug 27, 2014 at 04:28:07PM -0700, Tony Lindgren wrote:
> > It's not being used any longer.
> >
> > Signed-off-by: Tony Lindgren
> > ---
> > drivers/phy/phy-twl4030-usb.c | 2 --
> > drivers/usb/phy/phy-twl6030-usb.c | 2 --
> > 2 files changed, 4 deletions(-)
> >
> > diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
> > index 9cd33a4..bc28ecc 100644
> > --- a/drivers/phy/phy-twl4030-usb.c
> > +++ b/drivers/phy/phy-twl4030-usb.c
> > @@ -164,7 +164,6 @@ struct twl4030_usb {
> > enum omap_musb_vbus_id_status linkstat;
> > boolvbus_supplied;
> > u8 asleep;
> > - boolirq_enabled;
> >
> > struct delayed_work id_workaround_work;
> > };
> > @@ -755,7 +754,6 @@ static int twl4030_usb_probe(struct platform_device
> > *pdev)
> > * set_host() and/or set_peripheral() ... OTG_capable boards
> > * need both handles, otherwise just one suffices.
> > */
> > - twl->irq_enabled = true;
> > status = devm_request_threaded_irq(twl->dev, twl->irq, NULL,
> > twl4030_usb_irq, IRQF_TRIGGER_FALLING |
> > IRQF_TRIGGER_RISING | IRQF_ONESHOT, "twl4030_usb", twl);
>
> can you split this into two patches ? drivers/phy will be taken by
> Kishon and drivers/usb/phy by me. another possibility is that I get an
> Acked-by from Kishon and I can take $subject as is.
Oops yes sorry I already forgot I'm patching twl6030 too. Below
is the updated version of this patch for Kishon with just the
twl4030 changes. I will post the twl6030 changes separately.
Regards,
Tony
8< -
From: Tony Lindgren
Date: Mon, 18 Aug 2014 07:54:16 -0700
Subject: [PATCH] usb: phy: twl4030-usb: Remove unused irq_enabled
It's not being used any longer.
Signed-off-by: Tony Lindgren
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -164,7 +164,6 @@ struct twl4030_usb {
enum omap_musb_vbus_id_status linkstat;
boolvbus_supplied;
u8 asleep;
- boolirq_enabled;
struct delayed_work id_workaround_work;
};
@@ -755,7 +754,6 @@ static int twl4030_usb_probe(struct platform_device *pdev)
* set_host() and/or set_peripheral() ... OTG_capable boards
* need both handles, otherwise just one suffices.
*/
- twl->irq_enabled = true;
status = devm_request_threaded_irq(twl->dev, twl->irq, NULL,
twl4030_usb_irq, IRQF_TRIGGER_FALLING |
IRQF_TRIGGER_RISING | IRQF_ONESHOT, "twl4030_usb", twl);
--
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: dwc3: exynos: remove usb_phy_generic support
[ added Alan and Greg to cc: ]
Hi,
On Wednesday, August 27, 2014 11:42:25 PM Vivek Gautam wrote:
> Hi Baltlomiej,
>
>
> On Wed, Aug 27, 2014 at 1:22 PM, Bartlomiej Zolnierkiewicz
> wrote:
> > dwc3 driver is using the new Exynos5 SoC series USB DRD PHY driver
> > (PHY_EXYNOS5_USBDRD which selects GENERIC_PHY) as can be seen by
> > looking at the following commits:
> >
> > 7a4cf0fde054 ("ARM: dts: Update DWC3 usb controller to use new
> > phy driver for exynos5250")
> >
> > f070267b5fc1 ("ARM: dts: Enable support for DWC3 controller for
> > exynos5420")
> >
> > Thus remove unused usb_phy_generic support from dwc3 Exynos glue
> > layer.
> >
> > [ The code that is being removed is harmful in the context of
> > multi_v7_defconfig and enabling "EHCI support for Samsung
> > S5P/EXYNOS SoC Series" (USB_EHCI_EXYNOS) + "OHCI support for
> > Samsung S5P/EXYNOS SoC Series" (USB_OHCI_EXYNOS) because "EHCI
> > support for OMAP3 and later chips" (USB_EHCI_HCD_OMAP) selects
> > "NOP USB Transceiver Driver" (NOP_USB_XCEIV). NOP USB driver
> > attaches itself to usb_phy_generic platform devices created by
> > dwc3 Exynos glue layer and later causes Exynos EHCI driver to
> > fail probe and Exynos OHCI driver to hang on probe (as observed
> > on Exynos5250 Arndale board). ]
>
> The issue with EHCI and OHCI on exynos platforms is that until now
> they also request
> usb-phy and only later if they don't find one, they go ahead and get a
> 'phy' generic.
>
> Fortunately we missed this issue with exynos_defconfig, and as you rightly
> mentioned with multi_v7_defconfig, the NOP_USB_XCEIV gets enabled and
> EHCI and OHCI exynos get no-op usb-phy, which actually blocks EHCI/OHCI from
> initializing the real PHYs.
>
> This issue is resolved with patches:
> [PATCH v2 1/2] usb: host: ehci-exynos: Remove unnecessary usb-phy support
> [PATCH v2 2/2] usb: host: ohci-exynos: Remove unnecessary usb-phy support
> wherein we are completely removing the usb-phy support from ehci/ohci-exynos.
> So with these patches we should not see the issue mentioned by you.
Indeed, your patches fix the issue.
Greg, could these two patches ([1] & [2]) get merged quickly, pretty please
(they were already acked by Alan)? They are not a mere cleanups because
they fix the actual problem with using multi_v7_defconfig which in turn has
been blocking Olof's defconfig update patch [3] for quite some time now.
Moreover these patches are limited to Exynos host drivers so they should be
pretty safe when it comes to potential regressions.
[1] http://www.spinics.net/lists/linux-usb/msg112294.html
[2] http://www.spinics.net/lists/linux-usb/msg112293.html
[3] http://www.spinics.net/lists/arm-kernel/msg349654.html
> Now for the DWC3 part, the usb-phy part was added to use register two
> separate no-op-xceivers of USB2_PHY type and USB3_PHY type,
> so that platforms with no separate PHY can still be able to use dwc3.
Is such support actually useful for Exynos platforms (it resides in
dwc3-exynos.c)? I think that all DWC3 Exynos users need corresponding
USB PHY support, no?
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> > Cc: Olof Johansson
> > Cc: Kukjin Kim
> > Cc: Vivek Gautam
> > Acked-by: Kyungmin Park
> > Signed-off-by: Bartlomiej Zolnierkiewicz
> > ---
> > drivers/usb/dwc3/dwc3-exynos.c | 68
> > -
> > 1 file changed, 1 insertion(+), 67 deletions(-)
> >
> > Index: b/drivers/usb/dwc3/dwc3-exynos.c
> > ===
> > --- a/drivers/usb/dwc3/dwc3-exynos.c2014-08-25 14:57:04.991781925 +0200
> > +++ b/drivers/usb/dwc3/dwc3-exynos.c2014-08-27 09:16:38.312617727 +0200
> > @@ -23,15 +23,12 @@
> > #include
> > #include
> > #include
> > -#include
> > -#include
> > +#include
> > #include
> > #include
> > #include
> >
> > struct dwc3_exynos {
> > - struct platform_device *usb2_phy;
> > - struct platform_device *usb3_phy;
> > struct device *dev;
> >
> > struct clk *clk;
> > @@ -39,61 +36,6 @@ struct dwc3_exynos {
> > struct regulator*vdd10;
> > };
> >
> > -static int dwc3_exynos_register_phys(struct dwc3_exynos *exynos)
> > -{
> > - struct usb_phy_generic_platform_data pdata;
> > - struct platform_device *pdev;
> > - int ret;
> > -
> > - memset(&pdata, 0x00, sizeof(pdata));
> > -
> > - pdev = platform_device_alloc("usb_phy_generic",
> > PLATFORM_DEVID_AUTO);
> > - if (!pdev)
> > - return -ENOMEM;
> > -
> > - exynos->usb2_phy = pdev;
> > - pdata.type = USB_PHY_TYPE_USB2;
> > - pdata.gpio_reset = -1;
> > -
> > - ret = platform_device_add_data(exynos->usb2_phy, &pdata,
> > sizeof(pdata));
> > - if (ret)
> > - goto err1;
> > -
> > - pdev = platform_device_alloc("usb_phy_generic",
Re: [RFC PATCH 0/7] usb: gadget: add reset API at usb_gadget_driver
On Thu, 28 Aug 2014, Alan Stern wrote: > Okay, so we need to add a "vbus_is_on" flag to the usb_gadget > structure. The gadget driver will set this flag in its connect > callback and clear the flag in its disconnect callback. If the UDC > driver doesn't have a Vbus handler, it will invoke the connect callback > just once during startup, and it will invoke the disconnect callback > just once during removal. After more thought, if the vbus_is_on flag is going to be controlled by the gadget driver rather than the UDC driver, then it really belongs in the gadget driver's private data structure and not in struct usb_gadget. Also, a better name for the flag would be "is_connected". > The gadget driver should include an adjust_pullup() routine. It should > get called whenever a function is activated or deactivated, and also by > the connect and disconnect callbacks. The logic is simple: > > If (any functions are deactivated) > turn off the pullup > else if (gadget->vbus_is_on) > turn on the pullup > else > turn off the pullup This logic can be compressed a little: if (!is_connected || any functions are deactivated) turn off the pullup else turn on the pullup 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] xhci-ring: Fix Null pointer dereference
Sure, but the hw leaves my desk until next monday in 30 minutes. So unless you send the patch right now you will have to wait for results until next Monday Thanks! On Thu, Aug 28, 2014 at 5:20 PM, Mathias Nyman wrote: > On 08/28/2014 03:36 PM, Ricardo Ribalda Delgado wrote: >> Hello Mathias >> >> This is the dmesg output after your patch. No WARN(), no crash :), but >> still some weird messages: >> >> [ 146.511623] usb 2-2: new SuperSpeed USB device number 2 using xhci_hcd >> [ 146.531652] usb 2-2: New USB device found, idVendor=0525, idProduct=a4a5 >> [ 146.531661] usb 2-2: New USB device strings: Mfr=3, Product=4, >> SerialNumber=0 >> [ 146.531666] usb 2-2: Product: Mass Storage Gadget >> [ 146.531670] usb 2-2: Manufacturer: Linux 3.16.0-qtec-standard+ with >> net2280 >> [ 147.772743] usb-storage 2-2:1.0: USB Mass Storage device detected >> [ 147.773018] usb-storage 2-2:1.0: Quirks match for vid 0525 pid a4a5: 1 >> [ 147.773185] scsi host6: usb-storage 2-2:1.0 >> [ 147.773361] usbcore: registered new interface driver usb-storage >> [ 147.788950] usbcore: registered new interface driver uas >> [ 148.772699] scsi 6:0:0:0: Direct-Access LinuxFile-Stor >> Gadget 0316 PQ: 0 ANSI: 2 >> [ 148.773192] sd 6:0:0:0: Attached scsi generic sg2 type 0 >> [ 148.774860] sd 6:0:0:0: [sdb] 32768 512-byte logical blocks: (16.7 >> MB/16.0 MiB) >> [ 148.888294] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd >> [ 148.905202] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called >> with disabled ep 880036f3cc88 >> [ 148.905207] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called >> with disabled ep 880036f3cc40 >> [ 148.906324] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state >> [ 148.912639] sd 6:0:0:0: [sdb] Test WP failed, assume Write Enabled >> [ 149.014972] sd 6:0:0:0: [sdb] Write cache: enabled, read cache: >> enabled, doesn't support DPO or FUA >> [ 149.128640] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd >> [ 149.145953] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called >> with disabled ep 880036f3cc88 >> [ 149.145963] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called >> with disabled ep 880036f3cc40 >> [ 149.147525] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state >> [ 149.268626] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd >> [ 149.285563] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called >> with disabled ep 880036f3cc88 >> [ 149.285573] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called >> with disabled ep 880036f3cc40 >> [ 149.286904] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state >> [ 149.404621] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd >> [ 149.421397] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called >> with disabled ep 880036f3cc88 >> [ 149.421404] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called >> with disabled ep 880036f3cc40 >> [ 149.422855] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state >> [ 149.431667] sdb: unknown partition table >> [ 149.544713] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd >> [ 149.561649] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called >> with disabled ep 880036f3cc88 >> [ 149.561658] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called >> with disabled ep 880036f3cc40 >> [ 149.563021] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state >> [ 149.680733] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd >> [ 149.697766] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called >> with disabled ep 880036f3cc88 >> [ 149.697774] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called >> with disabled ep 880036f3cc40 >> [ 149.699025] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state >> [ 149.706700] sd 6:0:0:0: [sdb] Write cache: enabled, read cache: >> enabled, doesn't support DPO or FUA >> [ 149.706712] sd 6:0:0:0: [sdb] Attached SCSI disk >> [ 149.820933] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd >> [ 149.837887] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called >> with disabled ep 880036f3cc88 >> [ 149.837895] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called >> with disabled ep 880036f3cc40 >> [ 149.839242] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state >> [ 155.752101] usb 3-1.5.6: reset high-speed USB device number 10 using >> ehci-pci >> [ 155.866642] cdc_acm 3-1.5.6:1.1: This device cannot do calls on its >> own. It is not a modem. >> [ 155.866756] cdc_acm 3-1.5.6:1.1: ttyACM0: USB ACM device >> [ 155.867613] usb 3-1.5.6: usbfs: process 1521 (pool) did not claim >> interface 0 before use >> [ 160.471327] pool[1680]: segfault at fc0e61c0 ip >> 7f570f036200 sp 7f570639f0d0 error 5 in >> libc-2.19.so[7f570efee000+19f000] >> >> Thanks! >> > > Thanks, I see you already found bug 75521 > https://bugzi
Re: [PATCH] xhci-ring: Fix Null pointer dereference
On 08/28/2014 03:36 PM, Ricardo Ribalda Delgado wrote: > Hello Mathias > > This is the dmesg output after your patch. No WARN(), no crash :), but > still some weird messages: > > [ 146.511623] usb 2-2: new SuperSpeed USB device number 2 using xhci_hcd > [ 146.531652] usb 2-2: New USB device found, idVendor=0525, idProduct=a4a5 > [ 146.531661] usb 2-2: New USB device strings: Mfr=3, Product=4, > SerialNumber=0 > [ 146.531666] usb 2-2: Product: Mass Storage Gadget > [ 146.531670] usb 2-2: Manufacturer: Linux 3.16.0-qtec-standard+ with net2280 > [ 147.772743] usb-storage 2-2:1.0: USB Mass Storage device detected > [ 147.773018] usb-storage 2-2:1.0: Quirks match for vid 0525 pid a4a5: 1 > [ 147.773185] scsi host6: usb-storage 2-2:1.0 > [ 147.773361] usbcore: registered new interface driver usb-storage > [ 147.788950] usbcore: registered new interface driver uas > [ 148.772699] scsi 6:0:0:0: Direct-Access LinuxFile-Stor > Gadget 0316 PQ: 0 ANSI: 2 > [ 148.773192] sd 6:0:0:0: Attached scsi generic sg2 type 0 > [ 148.774860] sd 6:0:0:0: [sdb] 32768 512-byte logical blocks: (16.7 > MB/16.0 MiB) > [ 148.888294] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd > [ 148.905202] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called > with disabled ep 880036f3cc88 > [ 148.905207] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called > with disabled ep 880036f3cc40 > [ 148.906324] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state > [ 148.912639] sd 6:0:0:0: [sdb] Test WP failed, assume Write Enabled > [ 149.014972] sd 6:0:0:0: [sdb] Write cache: enabled, read cache: > enabled, doesn't support DPO or FUA > [ 149.128640] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd > [ 149.145953] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called > with disabled ep 880036f3cc88 > [ 149.145963] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called > with disabled ep 880036f3cc40 > [ 149.147525] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state > [ 149.268626] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd > [ 149.285563] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called > with disabled ep 880036f3cc88 > [ 149.285573] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called > with disabled ep 880036f3cc40 > [ 149.286904] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state > [ 149.404621] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd > [ 149.421397] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called > with disabled ep 880036f3cc88 > [ 149.421404] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called > with disabled ep 880036f3cc40 > [ 149.422855] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state > [ 149.431667] sdb: unknown partition table > [ 149.544713] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd > [ 149.561649] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called > with disabled ep 880036f3cc88 > [ 149.561658] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called > with disabled ep 880036f3cc40 > [ 149.563021] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state > [ 149.680733] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd > [ 149.697766] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called > with disabled ep 880036f3cc88 > [ 149.697774] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called > with disabled ep 880036f3cc40 > [ 149.699025] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state > [ 149.706700] sd 6:0:0:0: [sdb] Write cache: enabled, read cache: > enabled, doesn't support DPO or FUA > [ 149.706712] sd 6:0:0:0: [sdb] Attached SCSI disk > [ 149.820933] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd > [ 149.837887] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called > with disabled ep 880036f3cc88 > [ 149.837895] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called > with disabled ep 880036f3cc40 > [ 149.839242] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state > [ 155.752101] usb 3-1.5.6: reset high-speed USB device number 10 using > ehci-pci > [ 155.866642] cdc_acm 3-1.5.6:1.1: This device cannot do calls on its > own. It is not a modem. > [ 155.866756] cdc_acm 3-1.5.6:1.1: ttyACM0: USB ACM device > [ 155.867613] usb 3-1.5.6: usbfs: process 1521 (pool) did not claim > interface 0 before use > [ 160.471327] pool[1680]: segfault at fc0e61c0 ip > 7f570f036200 sp 7f570639f0d0 error 5 in > libc-2.19.so[7f570efee000+19f000] > > Thanks! > Thanks, I see you already found bug 75521 https://bugzilla.kernel.org/show_bug.cgi?id=75521 I think this is the same cause. Currently I suspect that one halted endpoint is not handled before the entire device is reset. After device reset we try to handle the old halted endpoint that has a pointer to a invalid old dequeue state. I'll see If I can make a patch tha
Re: [PATCH 5/5] phy: exynos5-usbdrd: Adding Kconfig dependency for Exynos7
2014-08-28 10:02 GMT+02:00 Vivek Gautam: > This USB 3.0 PHY controller is also present on Exynos7 > platform, so adding the dependency on ARCH_EXYNOS7 for this driver. > +++ b/drivers/phy/Kconfig > @@ -186,7 +186,7 @@ config PHY_EXYNOS5250_USB2 > > config PHY_EXYNOS5_USBDRD > tristate "Exynos5 SoC series USB DRD PHY driver" > - depends on ARCH_EXYNOS5 && OF > + depends on (ARCH_EXYNOS5 || ARCH_EXYNOS7) && OF shouldn't that prompt and its help text be updated to mention also Exynos7? -- Daniele Forsi -- 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: [RFC PATCH 0/7] usb: gadget: add reset API at usb_gadget_driver
On Thu, 28 Aug 2014, Peter Chen wrote: > > DWC3 doesn't really have a pullup bit. It's got a RUN/STOP bit. Sure, it > > controls the pullups but it also kills the internal DMA and quite a bit > > of other internal blocks. > > It is the same with chipidea, it has RUN/STOP bit at usbcmd, and its > function is most like dwc3's. > > If the RUN/STOP bit is cleared at usb_gadget_driver.disconnect when > the cable is disconnected, when we set it again after cable is connected? > The UDC drivers who has vbus handler can set run/stop bit at .vbus_session, > but if the UDC drivers do not have vbus handler, where we can set it? Okay, so we need to add a "vbus_is_on" flag to the usb_gadget structure. The gadget driver will set this flag in its connect callback and clear the flag in its disconnect callback. If the UDC driver doesn't have a Vbus handler, it will invoke the connect callback just once during startup, and it will invoke the disconnect callback just once during removal. The gadget driver should include an adjust_pullup() routine. It should get called whenever a function is activated or deactivated, and also by the connect and disconnect callbacks. The logic is simple: If (any functions are deactivated) turn off the pullup else if (gadget->vbus_is_on) turn on the pullup else turn off the pullup How does that sound? 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 02/13] usb: udc: set the udc is ready to pullup dp when it needs
Hi, On Thu, Aug 28, 2014 at 04:46:41PM +0800, Peter Chen wrote: > On Wed, Aug 27, 2014 at 02:22:30PM -0500, Felipe Balbi wrote: > > On Wed, Aug 20, 2014 at 01:30:40PM +0800, Peter Chen wrote: > > > On Tue, Aug 19, 2014 at 09:02:54PM +, Paul Zimmerman wrote: > > > > > From: linux-usb-ow...@vger.kernel.org > > > > > [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Peter Chen > > > > > Sent: Tuesday, August 19, 2014 7:26 AM > > > > > > > > > > On Tue, Aug 19, 2014 at 01:46:17AM +, Paul Zimmerman wrote: > > > > > > > From: Peter Chen [mailto:peter.c...@freescale.com] > > > > > > > Sent: Sunday, August 17, 2014 9:14 PM > > > > > > > > > > > > > > Except for chipidea driver, all other udc drivers will tell the > > > > > > > gadget driver that they are ready to pullup dp at udc_start, it > > > > > > > is the default behaviour. > > > > > > > > > > > > > > The chipidea driver is ready to pullup dp when the vbus is there, > > > > > > > and isn't ready to pullup dp when the vbus is not there. Other > > > > > > > udc drivers which should not pull up when vbus is not there should > > > > > > > change like chipidea does to pass the Back-Voltage Testing at > > > > > > > www.usb.org/developers/docs/USB-IFTestProc1_3.pdf. > > > > > > > > > > > > > > Signed-off-by: Peter Chen > > > > > > > --- > > > > > > > drivers/usb/chipidea/udc.c |9 - > > > > > > > drivers/usb/dwc2/gadget.c |2 ++ > > > > > > > drivers/usb/dwc3/gadget.c |2 ++ > > > > > > > drivers/usb/gadget/udc/amd5536udc.c |1 + > > > > > > > drivers/usb/gadget/udc/atmel_usba_udc.c |2 ++ > > > > > > > drivers/usb/gadget/udc/bcm63xx_udc.c|2 ++ > > > > > > > drivers/usb/gadget/udc/dummy_hcd.c |1 + > > > > > > > drivers/usb/gadget/udc/fotg210-udc.c|1 + > > > > > > > drivers/usb/gadget/udc/fsl_qe_udc.c |1 + > > > > > > > drivers/usb/gadget/udc/fsl_udc_core.c |2 ++ > > > > > > > drivers/usb/gadget/udc/fusb300_udc.c|1 + > > > > > > > drivers/usb/gadget/udc/gr_udc.c |2 ++ > > > > > > > drivers/usb/gadget/udc/lpc32xx_udc.c|2 ++ > > > > > > > drivers/usb/gadget/udc/m66592-udc.c |2 ++ > > > > > > > drivers/usb/gadget/udc/mv_u3d_core.c|1 + > > > > > > > drivers/usb/gadget/udc/mv_udc_core.c|2 ++ > > > > > > > drivers/usb/gadget/udc/net2272.c|1 + > > > > > > > drivers/usb/gadget/udc/net2280.c|1 + > > > > > > > drivers/usb/gadget/udc/omap_udc.c |1 + > > > > > > > drivers/usb/gadget/udc/pch_udc.c|1 + > > > > > > > drivers/usb/gadget/udc/pxa25x_udc.c |1 + > > > > > > > drivers/usb/gadget/udc/pxa27x_udc.c |1 + > > > > > > > drivers/usb/gadget/udc/r8a66597-udc.c |1 + > > > > > > > drivers/usb/gadget/udc/s3c-hsudc.c |1 + > > > > > > > drivers/usb/gadget/udc/s3c2410_udc.c|1 + > > > > > > > drivers/usb/musb/musb_gadget.c |2 ++ > > > > > > > drivers/usb/renesas_usbhs/mod_gadget.c |7 ++- > > > > > > > 27 files changed, 45 insertions(+), 6 deletions(-) > > > > > > > > > > > > Instead of modifying all of the UDC drivers, how about adding a > > > > > > flag to > > > > > > 'struct usb_gadget' named 'needs_ready' or similar? If the UDC > > > > > > doesn't > > > > > > set the flag, udc-core would call usb_udc_ready_to_connect() on > > > > > > behalf > > > > > > of the UDC. If the UDC sets the flag (chipidea only?) then the UDC > > > > > > would > > > > > > be responsible for calling usb_udc_ready_to_connect(). > > > > > > > > > > > > > > > > USB spec requires dp is not pulled up when the vbus is not there, the > > > > > dwc3 is > > > > > the newest core, I don't think other older udc cores all has similar > > > > > capability > > > > > that does don't draw back voltage if software pullup bit is set and > > > > > vbus is > > > > > not there. > > > > > > > > > > This patchset will delete the unconditional pullup dp operation at > > > > > udc-core, > > > > > and we need to pullup dp at the end of hardware initialization (not > > > > > consider > > > > > vbus case), then the end of .udc_start at udc driver is the old place. > > > > > > > > I think you misunderstood my suggestion. Since you are adding a call > > > > to usb_udc_ready_to_connect() at the end of almost every .udc_start > > > > function, why not have udc-core do it instead, immediately after the > > > > call to .udc_start? Unless the 'needs_ready' flag is set, which would > > > > only be set by the udc drivers for those controllers that need it. > > > > > > > > > > Thanks. > > > > > > Yes, we can do that, my original plan is > > > usb_gadget_connect/usb_gadget_disconnect > > > are only called by gadget driver. If Felipe has no comment for it, I will > > > > not directly though. At least not for those using the composite layer. > > All functions using composite layer should use activate/deactivate. > > > > -- >
Re: [RFC PATCH 0/7] usb: gadget: add reset API at usb_gadget_driver
Hi, On Thu, Aug 28, 2014 at 05:08:08PM +0800, Peter Chen wrote: > On Wed, Aug 27, 2014 at 02:37:35PM -0500, Felipe Balbi wrote: > > Hi, > > > > On Tue, Aug 26, 2014 at 03:30:32PM +0800, Peter Chen wrote: > > > On Mon, Aug 25, 2014 at 11:27:47AM -0400, Alan Stern wrote: > > > > On Mon, 25 Aug 2014, Peter Chen wrote: > > > > > > > > > Hi Felipe & Alan, > > > > > > > > > > It is the follow-up for: > > > > > http://www.spinics.net/lists/linux-usb/msg112193.html > > > > > > > > > > This patchset adds reset API at usb_gadget_driver, the UDC driver > > > > > can call it at bus_reset handler instead of calling disconnect. > > > > > The benefits of this patchset are: > > > > > - We can let the gadget driver do different things for bus reset. > > > > > and host is disconnected, eg, whether pull down dp or not. > > > > > - Match kernel doc for disconnect API, it says it is invoked > > > > > "when the host is disconnected". > > > > > - Will be more match for the real things the gadget driver > > > > > does for connect and disconnect, when we introduce connect API later. > > > > > > > > > > The reason for I mark RFC is I don't add the modification for mass > > > > > UDC driver changes, if you consider this patchset is ok, I will > > > > > add them without RFC later. > > > > > > > > This looks good. > > > > > > > > In patches 2, 4, and 5, shouldn't you call usb_gadget_disconnect() > > > > _before_ the gadget driver's original disconnect handler, instead of > > > > _after_? That's how we do it now. > > > > > > > > > > Hi Alan & Felipe, > > > > > > During the changing UDC drivers process, I find we can't simply move > > > usb_gadget_disconnect to usb_gadget_driver.disconnect, some UDC > > > drivers (like dwc3) will be no chance to set software pullup bit > > > (dp control always means software dp pullup bit if no specific at below) > > > again between disconnection and re-connection. > > > > sorry, can you rephrase this a bit, I really can't get what you mean. > > > > DWC3 doesn't really have a pullup bit. It's got a RUN/STOP bit. Sure, it > > controls the pullups but it also kills the internal DMA and quite a bit > > of other internal blocks. > > It is the same with chipidea, it has RUN/STOP bit at usbcmd, and its > function is most like dwc3's. > > If the RUN/STOP bit is cleared at usb_gadget_driver.disconnect when > the cable is disconnected, when we set it again after cable is connected? > The UDC drivers who has vbus handler can set run/stop bit at .vbus_session, > but if the UDC drivers do not have vbus handler, where we can set it? some UDC drivers don't have a VBUS handler because they don't have internal VBUS comparators and there's no way to implement that for that UDC. > > The way the code is today, we will have a pullup connected when a gadget > > driver is loaded and not before that. > > > > > There are two kinds of UDCs, dp is always pullup(UDC-A), pullup dp relies > > > on vbus (UDC-B), so we may need to introduce a flag like pullup_on_vbus > > > at struct usb_gadget, UDC-B needs to set this flag at .udc_start. > > > > > > For the whole gadget life cycle, the dp change for the two kinds of > > > UDC like below: > > > Process dp at UDC-A dp at UDC-B > > > insmod1 0 > > > connect 1 1 > > > bus_reset 1 1 > > > disconnect1 0 > > > rmmod 0 0 > > > > > > For insmod/rmmod gadget driver, we can control dp at udc-core relies > > > on flag pullup_on_vbus. > > > > > > For other three stages (no need to control at bus_reset), we can control > > > dp > > > at two gadget driver's API relies on flag pullup_on_vbus. > > > > I also can't get what you mean here. > > If the UDC driver doesn't want to pull up dp at insmod gadget driver, it > can pull up dp when the cable is connected. how will UDC know that cable was connected if its pullups aren't connected ? > > > Do you agree above? > > > > > > If you agree, the first patchset for adding reset API at > > > usb_gadget_driver may > > > do less thing, and the reset API implementation at each gadget driver is > > > the > > > same with disconnect. > > > > that's why we never had a ->reset() callback so far. From a gadget > > driver perspective, it's the same as disconnect followed by a connect. > > Yes, it is the current design, but if we want to call usb_gadget_disconnect > at ->disconnect callback, things will be different, besides, the kernel > doc says it is invoked when "when the host is disconnected". you shouldn't call usb_gadget_disconnect() from ->disconnect(). It's the other way around. You get a disconnect IRQ, then you call gadget driver's ->disconnect(), but gadget driver doesn't need to ask UDC to remove pullup at that time. This has been getting more and more confusing of a problem. I'll go curl down in a corner and think about it :-) --
Re: [PATCH] usb: gadget: f_uvc fix transition to video_ioctl2
On Thu, Aug 28, 2014 at 04:39:27PM +0200, Andrzej Pietrasiewicz wrote: > W dniu 28.08.2014 o 13:28, Laurent Pinchart pisze: > > > > >>diff --git a/drivers/usb/gadget/function/f_uvc.c > >>b/drivers/usb/gadget/function/f_uvc.c index 5209105..95dc1c6 100644 > >>--- a/drivers/usb/gadget/function/f_uvc.c > >>+++ b/drivers/usb/gadget/function/f_uvc.c > >>@@ -411,6 +411,7 @@ uvc_register_video(struct uvc_device *uvc) > >>video->fops = &uvc_v4l2_fops; > >>video->ioctl_ops = &uvc_v4l2_ioctl_ops; > >>video->release = video_device_release; > >>+ video->vfl_dir = VFL_DIR_TX; > > > >Do you have any objection against squashing this patch into "usb: gadget: > >f_uvc: Move to video_ioctl2" ? > > > Not at all. Feel free to squash it. This is in my testing/fixes, though. I'll drop it from there. -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: gadget: f_uvc fix transition to video_ioctl2
W dniu 28.08.2014 o 13:28, Laurent Pinchart pisze: diff --git a/drivers/usb/gadget/function/f_uvc.c b/drivers/usb/gadget/function/f_uvc.c index 5209105..95dc1c6 100644 --- a/drivers/usb/gadget/function/f_uvc.c +++ b/drivers/usb/gadget/function/f_uvc.c @@ -411,6 +411,7 @@ uvc_register_video(struct uvc_device *uvc) video->fops = &uvc_v4l2_fops; video->ioctl_ops = &uvc_v4l2_ioctl_ops; video->release = video_device_release; + video->vfl_dir = VFL_DIR_TX; Do you have any objection against squashing this patch into "usb: gadget: f_uvc: Move to video_ioctl2" ? Not at all. Feel free to squash it. AP -- 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: composite: dequeue cdev->req before free its buffer
commit f226708(usb: gadget: composite: dequeue cdev->req before free it in
composite_dev_cleanup) fixed a bug: free the usb request(i.e. cdev->req) but
does not dequeue it beforehand. This fix is not proper enough because it
dequeues the request after free its data buffer, considering the hardware can
access the buffer's memory anytime before the request's complettion rountine
runs, and usb_ep_dequeue always call the complettion rountine before it returns,
so the best way is to dequeue the request before free its buffer.
Suggested-by: Felipe Balbi
Signed-off-by: Li Jun
---
drivers/usb/gadget/composite.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 6935a82..4514e73 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1955,8 +1955,8 @@ void composite_dev_cleanup(struct usb_composite_dev *cdev)
usb_ep_free_request(cdev->gadget->ep0, cdev->os_desc_req);
}
if (cdev->req) {
- kfree(cdev->req->buf);
usb_ep_dequeue(cdev->gadget->ep0, cdev->req);
+ kfree(cdev->req->buf);
usb_ep_free_request(cdev->gadget->ep0, cdev->req);
}
cdev->next_string_id = 0;
--
1.7.9.5
--
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: composite: dequeue cdev->req before free its buffer
On Wed, Aug 27, 2014 at 01:56:36PM -0500, Felipe Balbi wrote: > Hi, > > On Mon, Aug 25, 2014 at 04:49:12PM +0800, Li Jun wrote: > > As Felipe suggested, dequeue the cdev->req before free its buffer. > > > > Suggested-by: Felipe Balbi > > Signed-off-by: Li Jun > > please read Documentation/SubmittingPatches. Your commit log does not > make sense. You need to explain why the change is necessary and what is > it fixing. > > -- > balbi Sorry, I will improve my commit log and resend. Li Jun -- 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: [RFC v1 1/2] USB: OTG: Hold wakeupsource when VBUS present
Hi,
On Thu, Aug 28, 2014 at 03:25:10PM +0530, Kiran Kumar Raparthy wrote:
> +bool enabled = false;
> +
> +static DEFINE_SPINLOCK(otgws_spinlock);
> +static struct usb_phy *get_phy_hook(void);
> +
> +/* Only one lock, but since these 2 fields are associated with each other...
> */
> +
> +struct otgws_lock {
> + char name[40];
> + struct wakeup_source wsource;
> +};
> +
> +/* VBUS present lock */
> +
> +static struct otgws_lock vbus_lock;
I believe I mentioned that all of this should be per-PHY.
--
balbi
signature.asc
Description: Digital signature
Re: Regarding USB gadget MSG Regression failed
Hi, first of all, always keep linux-usb in Cc On Thu, Aug 28, 2014 at 02:48:20PM +0530, shishir tiwari wrote: > As your are author of USB DRD controller drvier . we using DW USB3 > DRD controller in our project , But when usb device is connected to > Linux host machice and we run regression testing its failed. > > OS : Linux - 3.4.14 this is kernel is really, really old. Either upgrade to something newer (like v3.16 or v3.17-rc2) or ask for support from whoever gave you that kernel. > We are just copying 50M file for host to device and reading back and > comparing . we trying sequence for 1000 times but its fail after 20- > times only. I can't help with an ancient kernel, sorry > You can please share USB device Framework so i could find issue/bug. huh ? -- balbi signature.asc Description: Digital signature
[PATCH] USB: sierra: add 1199:68AA device ID
This VID:PID is used for some Direct IP devices behaving
identical to the already supported 0F3D:68AA devices.
Cc:
Reported-by: Lars Melin
Signed-off-by: Bjørn Mork
---
This should be applied on top of my 'USB: sierra: avoid CDC class
functions on "68A3" devices' to avoid unnecessary conflicts.
Apologies for not sending them as a series. It's a matter of one
patch triggering another report...
Thanks,
Bjørn
drivers/usb/serial/sierra.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/serial/sierra.c b/drivers/usb/serial/sierra.c
index fa45d39619ca..46179a0828eb 100644
--- a/drivers/usb/serial/sierra.c
+++ b/drivers/usb/serial/sierra.c
@@ -286,6 +286,9 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(0x1199, 0x68A3, 0xFF, 0xFF, 0xFF),
.driver_info = (kernel_ulong_t)&direct_ip_interface_blacklist
},
+ { USB_DEVICE_AND_INTERFACE_INFO(0x1199, 0x68AA, 0xFF, 0xFF, 0xFF),
+ .driver_info = (kernel_ulong_t)&direct_ip_interface_blacklist
+ },
/* AT&T Direct IP LTE modems */
{ USB_DEVICE_AND_INTERFACE_INFO(0x0F3D, 0x68AA, 0xFF, 0xFF, 0xFF),
.driver_info = (kernel_ulong_t)&direct_ip_interface_blacklist
--
2.1.0
--
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] xhci-ring: Fix Null pointer dereference
Hello Mathias This is the dmesg output after your patch. No WARN(), no crash :), but still some weird messages: [ 146.511623] usb 2-2: new SuperSpeed USB device number 2 using xhci_hcd [ 146.531652] usb 2-2: New USB device found, idVendor=0525, idProduct=a4a5 [ 146.531661] usb 2-2: New USB device strings: Mfr=3, Product=4, SerialNumber=0 [ 146.531666] usb 2-2: Product: Mass Storage Gadget [ 146.531670] usb 2-2: Manufacturer: Linux 3.16.0-qtec-standard+ with net2280 [ 147.772743] usb-storage 2-2:1.0: USB Mass Storage device detected [ 147.773018] usb-storage 2-2:1.0: Quirks match for vid 0525 pid a4a5: 1 [ 147.773185] scsi host6: usb-storage 2-2:1.0 [ 147.773361] usbcore: registered new interface driver usb-storage [ 147.788950] usbcore: registered new interface driver uas [ 148.772699] scsi 6:0:0:0: Direct-Access LinuxFile-Stor Gadget 0316 PQ: 0 ANSI: 2 [ 148.773192] sd 6:0:0:0: Attached scsi generic sg2 type 0 [ 148.774860] sd 6:0:0:0: [sdb] 32768 512-byte logical blocks: (16.7 MB/16.0 MiB) [ 148.888294] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd [ 148.905202] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called with disabled ep 880036f3cc88 [ 148.905207] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called with disabled ep 880036f3cc40 [ 148.906324] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state [ 148.912639] sd 6:0:0:0: [sdb] Test WP failed, assume Write Enabled [ 149.014972] sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 149.128640] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd [ 149.145953] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called with disabled ep 880036f3cc88 [ 149.145963] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called with disabled ep 880036f3cc40 [ 149.147525] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state [ 149.268626] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd [ 149.285563] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called with disabled ep 880036f3cc88 [ 149.285573] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called with disabled ep 880036f3cc40 [ 149.286904] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state [ 149.404621] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd [ 149.421397] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called with disabled ep 880036f3cc88 [ 149.421404] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called with disabled ep 880036f3cc40 [ 149.422855] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state [ 149.431667] sdb: unknown partition table [ 149.544713] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd [ 149.561649] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called with disabled ep 880036f3cc88 [ 149.561658] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called with disabled ep 880036f3cc40 [ 149.563021] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state [ 149.680733] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd [ 149.697766] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called with disabled ep 880036f3cc88 [ 149.697774] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called with disabled ep 880036f3cc40 [ 149.699025] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state [ 149.706700] sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 149.706712] sd 6:0:0:0: [sdb] Attached SCSI disk [ 149.820933] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd [ 149.837887] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called with disabled ep 880036f3cc88 [ 149.837895] xhci_hcd :0e:00.0: xHCI xhci_drop_endpoint called with disabled ep 880036f3cc40 [ 149.839242] xhci_hcd :0e:00.0: Error: Failed finding new dequeue state [ 155.752101] usb 3-1.5.6: reset high-speed USB device number 10 using ehci-pci [ 155.866642] cdc_acm 3-1.5.6:1.1: This device cannot do calls on its own. It is not a modem. [ 155.866756] cdc_acm 3-1.5.6:1.1: ttyACM0: USB ACM device [ 155.867613] usb 3-1.5.6: usbfs: process 1521 (pool) did not claim interface 0 before use [ 160.471327] pool[1680]: segfault at fc0e61c0 ip 7f570f036200 sp 7f570639f0d0 error 5 in libc-2.19.so[7f570efee000+19f000] Thanks! On Thu, Aug 28, 2014 at 12:50 PM, Ricardo Ribalda Delgado wrote: > Hello > > On Thu, Aug 28, 2014 at 12:41 PM, Mathias Nyman > wrote: >> On 08/27/2014 07:10 PM, Ricardo Ribalda Delgado wrote: >>> Perhaps we could apply both patches to current tree and backport mine >>> to older kernels? >>> >> >> The already applied patch fixes many other issues than just this one. >> backporting it to stable < 3.13 turned out to not be that difficult, stable >> maintainers >> said they can do it themselves. > > then I agree, there is absolutely no need for my patch :). > > I have a broken gadget dr
[PATCH] USB: sierra: avoid CDC class functions on "68A3" devices
Sierra Wireless Direct IP devices using the 68A3 product ID
can be configured for modes including a CDC ECM class function.
The known example uses interface numbers 12 and 13 for the ECM
control and data interfaces respectively, consistent with CDC
MBIM function interface numbering on other Sierra devices.
It seems cleaner to restrict this driver to the ff/ff/ff
vendor specific interfaces rather than increasing the already
long interface number blacklist. This should be more future
proof if Sierra adds more class functions using interface
numbers not yet in the blacklist.
Cc:
Signed-off-by: Bjørn Mork
---
drivers/usb/serial/sierra.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/serial/sierra.c b/drivers/usb/serial/sierra.c
index 6f7f01eb556a..fa45d39619ca 100644
--- a/drivers/usb/serial/sierra.c
+++ b/drivers/usb/serial/sierra.c
@@ -282,14 +282,16 @@ static const struct usb_device_id id_table[] = {
/* Sierra Wireless HSPA Non-Composite Device */
{ USB_DEVICE_AND_INTERFACE_INFO(0x1199, 0x6892, 0xFF, 0xFF, 0xFF)},
{ USB_DEVICE(0x1199, 0x6893) }, /* Sierra Wireless Device */
- { USB_DEVICE(0x1199, 0x68A3), /* Sierra Wireless Direct IP modems */
+ /* Sierra Wireless Direct IP modems */
+ { USB_DEVICE_AND_INTERFACE_INFO(0x1199, 0x68A3, 0xFF, 0xFF, 0xFF),
.driver_info = (kernel_ulong_t)&direct_ip_interface_blacklist
},
/* AT&T Direct IP LTE modems */
{ USB_DEVICE_AND_INTERFACE_INFO(0x0F3D, 0x68AA, 0xFF, 0xFF, 0xFF),
.driver_info = (kernel_ulong_t)&direct_ip_interface_blacklist
},
- { USB_DEVICE(0x0f3d, 0x68A3), /* Airprime/Sierra Wireless Direct IP
modems */
+ /* Airprime/Sierra Wireless Direct IP modems */
+ { USB_DEVICE_AND_INTERFACE_INFO(0x0F3D, 0x68A3, 0xFF, 0xFF, 0xFF),
.driver_info = (kernel_ulong_t)&direct_ip_interface_blacklist
},
--
2.1.0
--
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 v3] usb: phy: samsung: remove old common USB PHY code
drivers/usb/phy/phy-samsung-usb[2,3] drivers got replaced by
drivers/phy/phy-samsung-usb[2,3] ones and the old common Samsung
USB PHY code is no longer used.
Signed-off-by: Bartlomiej Zolnierkiewicz
Acked-by: Kyungmin Park
Reviewed-by: Vivek Gautam
Reviewed-by: Jingoo Han
Acked-by: Kishon Vijay Abraham I
Cc: Kamil Debski
---
v3:
- rebased on testing/next branch of balbi/usb.git tree
drivers/usb/phy/phy-samsung-usb.c| 241
drivers/usb/phy/phy-samsung-usb.h| 317 ---
include/linux/platform_data/samsung-usbphy.h | 27 ---
3 files changed, 585 deletions(-)
delete mode 100644 drivers/usb/phy/phy-samsung-usb.c
delete mode 100644 drivers/usb/phy/phy-samsung-usb.h
delete mode 100644 include/linux/platform_data/samsung-usbphy.h
diff --git a/drivers/usb/phy/phy-samsung-usb.c
b/drivers/usb/phy/phy-samsung-usb.c
deleted file mode 100644
index ac025ca..000
--- a/drivers/usb/phy/phy-samsung-usb.c
+++ /dev/null
@@ -1,241 +0,0 @@
-/* linux/drivers/usb/phy/phy-samsung-usb.c
- *
- * Copyright (c) 2012 Samsung Electronics Co., Ltd.
- * http://www.samsung.com
- *
- * Author: Praveen Paneri
- *
- * Samsung USB-PHY helper driver with common function calls;
- * interacts with Samsung USB 2.0 PHY controller driver and later
- * with Samsung USB 3.0 PHY driver.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * 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
-#include
-
-#include "phy-samsung-usb.h"
-
-int samsung_usbphy_parse_dt(struct samsung_usbphy *sphy)
-{
- struct device_node *usbphy_sys;
-
- /* Getting node for system controller interface for usb-phy */
- usbphy_sys = of_get_child_by_name(sphy->dev->of_node, "usbphy-sys");
- if (!usbphy_sys) {
- dev_err(sphy->dev, "No sys-controller interface for usb-phy\n");
- return -ENODEV;
- }
-
- sphy->pmuregs = of_iomap(usbphy_sys, 0);
-
- if (sphy->pmuregs == NULL) {
- dev_err(sphy->dev, "Can't get usb-phy pmu control register\n");
- goto err0;
- }
-
- sphy->sysreg = of_iomap(usbphy_sys, 1);
-
- /*
-* Not returning error code here, since this situation is not fatal.
-* Few SoCs may not have this switch available
-*/
- if (sphy->sysreg == NULL)
- dev_warn(sphy->dev, "Can't get usb-phy sysreg cfg register\n");
-
- of_node_put(usbphy_sys);
-
- return 0;
-
-err0:
- of_node_put(usbphy_sys);
- return -ENXIO;
-}
-EXPORT_SYMBOL_GPL(samsung_usbphy_parse_dt);
-
-/*
- * Set isolation here for phy.
- * Here 'on = true' would mean USB PHY block is isolated, hence
- * de-activated and vice-versa.
- */
-void samsung_usbphy_set_isolation_4210(struct samsung_usbphy *sphy, bool on)
-{
- void __iomem *reg = NULL;
- u32 reg_val;
- u32 en_mask = 0;
-
- if (!sphy->pmuregs) {
- dev_warn(sphy->dev, "Can't set pmu isolation\n");
- return;
- }
-
- if (sphy->phy_type == USB_PHY_TYPE_DEVICE) {
- reg = sphy->pmuregs + sphy->drv_data->devphy_reg_offset;
- en_mask = sphy->drv_data->devphy_en_mask;
- } else if (sphy->phy_type == USB_PHY_TYPE_HOST) {
- reg = sphy->pmuregs + sphy->drv_data->hostphy_reg_offset;
- en_mask = sphy->drv_data->hostphy_en_mask;
- }
-
- reg_val = readl(reg);
-
- if (on)
- reg_val &= ~en_mask;
- else
- reg_val |= en_mask;
-
- writel(reg_val, reg);
-
- if (sphy->drv_data->cpu_type == TYPE_EXYNOS4X12) {
- writel(reg_val, sphy->pmuregs + EXYNOS4X12_PHY_HSIC_CTRL0);
- writel(reg_val, sphy->pmuregs + EXYNOS4X12_PHY_HSIC_CTRL1);
- }
-}
-EXPORT_SYMBOL_GPL(samsung_usbphy_set_isolation_4210);
-
-/*
- * Configure the mode of working of usb-phy here: HOST/DEVICE.
- */
-void samsung_usbphy_cfg_sel(struct samsung_usbphy *sphy)
-{
- u32 reg;
-
- if (!sphy->sysreg) {
- dev_warn(sphy->dev, "Can't configure specified phy mode\n");
- return;
- }
-
- reg = readl(sphy->sysreg);
-
- if (sphy->phy_type == USB_PHY_TYPE_DEVICE)
- reg &= ~EXYNOS_USB20PHY_CFG_HOST_LINK;
- else if (sphy->phy_type == USB_PHY_TYPE_HOST)
- reg |= EXYNOS_USB20PHY_CFG_HOST_LINK;
-
- writel(reg, sphy->sysreg);
-}
-EXPORT_SYMBOL_GPL(samsung_usbphy_cfg_sel);
-
-/*
- * PHYs are different for USB Device and USB H
Re: [PATCH] usb: gadget: f_uvc fix transition to video_ioctl2
Hi Andrzej, Thank you for the patch. On Wednesday 27 August 2014 17:16:38 Andrzej Pietrasiewicz wrote: > UVC video node is a TX device from the point of view of the gadget, > so we cannot rely on the video struct being filled with zeros, because > VFL_DIR_TX is actually 1. > > Suggested-by: Sylwester Nawrocki > Signed-off-by: Andrzej Pietrasiewicz > --- > drivers/usb/gadget/function/f_uvc.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/usb/gadget/function/f_uvc.c > b/drivers/usb/gadget/function/f_uvc.c index 5209105..95dc1c6 100644 > --- a/drivers/usb/gadget/function/f_uvc.c > +++ b/drivers/usb/gadget/function/f_uvc.c > @@ -411,6 +411,7 @@ uvc_register_video(struct uvc_device *uvc) > video->fops = &uvc_v4l2_fops; > video->ioctl_ops = &uvc_v4l2_ioctl_ops; > video->release = video_device_release; > + video->vfl_dir = VFL_DIR_TX; Do you have any objection against squashing this patch into "usb: gadget: f_uvc: Move to video_ioctl2" ? > strlcpy(video->name, cdev->gadget->name, sizeof(video->name)); > > uvc->vdev = video; -- Regards, Laurent Pinchart -- 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 0/7] g_webcam: Preparation for configfs
Hi Andrzej, On Wednesday 27 August 2014 17:33:16 Andrzej Pietrasiewicz wrote: > W dniu 18.08.2014 o 21:45, Laurent Pinchart pisze: > > Hi Andrzej, > > > > Thank you for the patches. The series looks good, I only had a few > > comments. > > > > I have rebased the patches on top of my UVC gadget branch, addressed my > > comments (the modified patches are marked as such in the commit message) > > and pushed the result to > > > > git://linuxtv.org/pinchartl/media.git uvc/gadget > > > > Would you be able to test the result and hopefully ack it ? If everything > > is fine with you there's no need to submit a new version. > > It seems that the f_uvc transition to video_ioctl2 is missing > vfl_dir flag; I posted a patch fixing it. > > After the fix is applied I was able to test on real hardware, so > as far as your changes to my patches are concerned, this is > > Acked-by: Andrzej Pietrasiewicz Thank you. I'll fix the video_ioctl2 implementation and will send an updated version of the patches. -- Regards, Laurent Pinchart -- 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 v6 5/5] usb: gadget: f_uac2: send reasonably sized packets
Daniel Mack wrote: > [...] > Please note, however, that you can't do the divison 'uac2->p_residue / > uac2->p_interval' in a pre-calucated value, as that won't cover cases > with a per-packet residual value that isn't a multiple of the frame > size. Partial frames are not allowed (neither in ALSA nor in USB audio). Regards, Clemens -- 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] xhci-ring: Fix Null pointer dereference
Hello On Thu, Aug 28, 2014 at 12:41 PM, Mathias Nyman wrote: > On 08/27/2014 07:10 PM, Ricardo Ribalda Delgado wrote: >> Perhaps we could apply both patches to current tree and backport mine >> to older kernels? >> > > The already applied patch fixes many other issues than just this one. > backporting it to stable < 3.13 turned out to not be that difficult, stable > maintainers > said they can do it themselves. then I agree, there is absolutely no need for my patch :). I have a broken gadget driver that was very good at triggering the bug, I will try it out with your patch. Thanks! > > Stable kernels prefer patches that are already upstream, as > Documentation/stable_kernel_rules.txt states: > "- It or an equivalent fix must already exist in Linus' tree (upstream)." > > There is no need for the other patch anymore, not upstream nor to stable > > -Mathias > -- Ricardo Ribalda -- 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: zte_ev: fix removed PIDs
Add back some PIDs that were mistakingly remove when reverting commit
73228a0538a7 ("USB: option,zte_ev: move most ZTE CDMA devices to
zte_ev"), which apparently did more than its commit message claimed in
that it not only moved some PIDs from option to zte_ev but also added
some new ones.
Fixes: 63a901c06e3c ("Revert "USB: option,zte_ev: move most ZTE CDMA
devices to zte_ev"")
Reported-by: Lei Liu
Cc: stable
Signed-off-by: Johan Hovold
---
Greg, this one should also go in to rc3 along with the offending commit
if possible.
The zte_ev driver is scheduled for removal in 3.18, but lets add back
the PIDs that has never been handled by any other driver in the mean
time (rather than move them to option directly).
Johan
drivers/usb/serial/zte_ev.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/usb/serial/zte_ev.c b/drivers/usb/serial/zte_ev.c
index 1a132e9e947a..c9bb107d5e5c 100644
--- a/drivers/usb/serial/zte_ev.c
+++ b/drivers/usb/serial/zte_ev.c
@@ -272,6 +272,14 @@ static void zte_ev_usb_serial_close(struct usb_serial_port
*port)
}
static const struct usb_device_id id_table[] = {
+ { USB_DEVICE(0x19d2, 0xffec) },
+ { USB_DEVICE(0x19d2, 0xffee) },
+ { USB_DEVICE(0x19d2, 0xfff6) },
+ { USB_DEVICE(0x19d2, 0xfff7) },
+ { USB_DEVICE(0x19d2, 0xfff8) },
+ { USB_DEVICE(0x19d2, 0xfff9) },
+ { USB_DEVICE(0x19d2, 0xfffb) },
+ { USB_DEVICE(0x19d2, 0xfffc) },
/* MG880 */
{ USB_DEVICE(0x19d2, 0xfffd) },
{ },
--
1.8.5.5
--
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: Re: "Revert "USB: option,zte_ev: move most ZTE CDMA devices to zte_ev""
On Thu, Aug 28, 2014 at 11:25:30AM +0800, 刘磊 wrote:
> Dear Johan:
> Thanks for you reply.
> i had been find the pid of 0x9008 and 0x3197 was in moto-modem and
> qcserial drivers.
> but the pid from 0xfff6 to 0xfffb and 0xffee/0xffec had been delete in
> new patch, that pid was not in usb drivers before.
> i hope we can add that pid in option.c. thanks.
Ahhh, commit 73228a0538a7 ("USB: option,zte_ev: move most ZTE CDMA
devices to zte_ev") not only moved PIDs as its changelog claimed but
also added new ones. Sneaky.
I think we should be conservative here and add them back to zte_ev for
now and then move them to option in 3.18. They have after all never been
handled by any other driver than zte_ev.
Thanks for catching this!
Johan
> >> - { USB_DEVICE(0x19d2, 0xfffc) },
> >> - { USB_DEVICE(0x19d2, 0xfffb) },
> >> - /* AC8710_V3 */
> >> - { USB_DEVICE(0x19d2, 0xfff6) },
> >> - { USB_DEVICE(0x19d2, 0xfff7) },
> >> - { USB_DEVICE(0x19d2, 0xfff8) },
> >> - { USB_DEVICE(0x19d2, 0xfff9) },
> >> - { USB_DEVICE(0x19d2, 0xffee) },
> >> - { USB_DEVICE(0x19d2, 0xffec) },
--
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] xhci-ring: Fix Null pointer dereference
On 08/27/2014 07:10 PM, Ricardo Ribalda Delgado wrote: > Perhaps we could apply both patches to current tree and backport mine > to older kernels? > The already applied patch fixes many other issues than just this one. backporting it to stable < 3.13 turned out to not be that difficult, stable maintainers said they can do it themselves. Stable kernels prefer patches that are already upstream, as Documentation/stable_kernel_rules.txt states: "- It or an equivalent fix must already exist in Linus' tree (upstream)." There is no need for the other patch anymore, not upstream nor to stable -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: [PATCH v6 5/5] usb: gadget: f_uac2: send reasonably sized packets
On Thu, Aug 28, 2014 at 3:47 PM, Daniel Mack wrote: > On 08/28/2014 12:10 PM, Jassi Brar wrote: >> On Thu, Aug 28, 2014 at 3:33 PM, Daniel Mack wrote: > >>> It's still superior to a number of unnecessary calculations done every >>> millisecond which will come up with the same result every time. So I >>> clearly favor that approach. Three more ints in a struct don't hurt >>> really for something that's usually not instantiated more than once per >>> system. >>> >>> Anyway, I'll leave it to Felipe whether to merge v5 or v6 :) >>> >> Please wait, let me cook up a patch that uses (a) Alan's algo, (b) >> cause lesser churn and (c) is even 'faster'. > > Alright. > > Please note, however, that you can't do the divison 'uac2->p_residue / > uac2->p_interval' in a pre-calucated value, as that won't cover cases > with a per-packet residual value that isn't a multiple of the frame > size. Hence, the residue counter has to go in bytes, not frames, and for > that reason, I left that division in the per-packet loop. > > Felipe, could you already merge patch 1-5 of the last series (v6)? > err.. 1-4 of v6 :) right? Yes please, Felipe, we have no contention on those nice patches. Thanks Jassi -- 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 v6 5/5] usb: gadget: f_uac2: send reasonably sized packets
On 08/28/2014 12:17 PM, Daniel Mack wrote: > Felipe, could you already merge patch 1-5 of the last series (v6)? 1-4, of course. Jassi's changes will only affect patch 5/5. Daniel -- 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 v6 5/5] usb: gadget: f_uac2: send reasonably sized packets
On 08/28/2014 12:10 PM, Jassi Brar wrote: > On Thu, Aug 28, 2014 at 3:33 PM, Daniel Mack wrote: >> It's still superior to a number of unnecessary calculations done every >> millisecond which will come up with the same result every time. So I >> clearly favor that approach. Three more ints in a struct don't hurt >> really for something that's usually not instantiated more than once per >> system. >> >> Anyway, I'll leave it to Felipe whether to merge v5 or v6 :) >> > Please wait, let me cook up a patch that uses (a) Alan's algo, (b) > cause lesser churn and (c) is even 'faster'. Alright. Please note, however, that you can't do the divison 'uac2->p_residue / uac2->p_interval' in a pre-calucated value, as that won't cover cases with a per-packet residual value that isn't a multiple of the frame size. Hence, the residue counter has to go in bytes, not frames, and for that reason, I left that division in the per-packet loop. Felipe, could you already merge patch 1-5 of the last series (v6)? Thanks, Daniel -- 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 v6 5/5] usb: gadget: f_uac2: send reasonably sized packets
On Thu, Aug 28, 2014 at 3:33 PM, Daniel Mack wrote:
> On 08/28/2014 11:33 AM, Jassi Brar wrote:
>> On Wed, Aug 27, 2014 at 10:39 PM, Daniel Mack wrote:
>
>>> diff --git a/drivers/usb/gadget/function/f_uac2.c
>>> b/drivers/usb/gadget/function/f_uac2.c
>>> index 246a778..a5a27a5 100644
>>> --- a/drivers/usb/gadget/function/f_uac2.c
>>> +++ b/drivers/usb/gadget/function/f_uac2.c
>>> @@ -92,6 +92,15 @@ struct snd_uac2_chip {
>>>
>>> struct snd_card *card;
>>> struct snd_pcm *pcm;
>>> +
>>> + /* timekeeping for the playback endpoint */
>>> + unsigned int p_interval;
>>> + unsigned int p_residue;
>>> +
>>> + /* pre-calculated values for playback iso completion */
>>> + unsigned int p_pktsize;
>>> + unsigned int p_pktsize_residue;
>>> + unsigned int p_framesize;
>>> };
>>>
>> I admire Alan's simple algo. I couldn't have matched that.
>>
>> However I am not sure how worth is the implementation if it requires 3
>> more members to avoid calculations simple enough to cause no
>> noticeable overhead. Once every millisecond is perfectly bearable IMO.
>
> Alan is right. If we can avoid that, we should.
>
It started with avoiding storing values (even lesser overhead) and
doing things in runtime (code looking elegant).
>> 5 members in uac2 structure for only playback, look ugly.
>
> It's still superior to a number of unnecessary calculations done every
> millisecond which will come up with the same result every time. So I
> clearly favor that approach. Three more ints in a struct don't hurt
> really for something that's usually not instantiated more than once per
> system.
>
> Anyway, I'll leave it to Felipe whether to merge v5 or v6 :)
>
Please wait, let me cook up a patch that uses (a) Alan's algo, (b)
cause lesser churn and (c) is even 'faster'.
-jassi
--
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
[RFC v1 2/2] usb: otg: Temporarily hold wakeupsource on charger
From: Todd Poynor
usb: otg: Temporarily hold wakeupsource on charger connect and disconnect
events
Allow other parts of the system to react to the charger connect/disconnect
event without allowing the system to suspend before the other parts can process
the event. This wakeup_source times out after 2 seconds; if nobody else holds a
wakeup_source by that time then the device can sleep.
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-ker...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: Android Kernel Team
Cc: John Stultz
Signed-off-by: Todd Poynor
[kiran: Added context to commit message]
Signed-off-by: Kiran Raparthy
---
drivers/usb/phy/otg-wakeupsource.c | 10 +++---
include/linux/usb/otg.h| 2 ++
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/phy/otg-wakeupsource.c
b/drivers/usb/phy/otg-wakeupsource.c
index 7c838d1..9f3c5c1 100644
--- a/drivers/usb/phy/otg-wakeupsource.c
+++ b/drivers/usb/phy/otg-wakeupsource.c
@@ -34,8 +34,11 @@ struct otgws_lock {
struct wakeup_source wsource;
};
-/* VBUS present lock */
-
+/*
+ * VBUS present lock. Also used as a timed lock on charger
+ * connect/disconnect and USB host disconnect, to allow the system
+ * to react to the change in power.
+ */
static struct otgws_lock vbus_lock;
static void otgws_handle_event(unsigned long event)
@@ -59,7 +62,8 @@ static void otgws_handle_event(unsigned long event)
case USB_EVENT_NONE:
case USB_EVENT_ID:
case USB_EVENT_CHARGER:
- __pm_relax(&vbus_lock.wsource);
+ __pm_wakeup_event(&vbus_lock.wsource,
+ msecs_to_jiffies(TEMPORARY_HOLD_TIME));
break;
default:
diff --git a/include/linux/usb/otg.h b/include/linux/usb/otg.h
index 154332b..4243747 100644
--- a/include/linux/usb/otg.h
+++ b/include/linux/usb/otg.h
@@ -11,6 +11,8 @@
#include
+#define TEMPORARY_HOLD_TIME2000
+
struct usb_otg {
u8 default_a;
--
1.8.2.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 v6 5/5] usb: gadget: f_uac2: send reasonably sized packets
On 08/28/2014 11:33 AM, Jassi Brar wrote:
> On Wed, Aug 27, 2014 at 10:39 PM, Daniel Mack wrote:
>> diff --git a/drivers/usb/gadget/function/f_uac2.c
>> b/drivers/usb/gadget/function/f_uac2.c
>> index 246a778..a5a27a5 100644
>> --- a/drivers/usb/gadget/function/f_uac2.c
>> +++ b/drivers/usb/gadget/function/f_uac2.c
>> @@ -92,6 +92,15 @@ struct snd_uac2_chip {
>>
>> struct snd_card *card;
>> struct snd_pcm *pcm;
>> +
>> + /* timekeeping for the playback endpoint */
>> + unsigned int p_interval;
>> + unsigned int p_residue;
>> +
>> + /* pre-calculated values for playback iso completion */
>> + unsigned int p_pktsize;
>> + unsigned int p_pktsize_residue;
>> + unsigned int p_framesize;
>> };
>>
> I admire Alan's simple algo. I couldn't have matched that.
>
> However I am not sure how worth is the implementation if it requires 3
> more members to avoid calculations simple enough to cause no
> noticeable overhead. Once every millisecond is perfectly bearable IMO.
Alan is right. If we can avoid that, we should.
> 5 members in uac2 structure for only playback, look ugly.
It's still superior to a number of unnecessary calculations done every
millisecond which will come up with the same result every time. So I
clearly favor that approach. Three more ints in a struct don't hurt
really for something that's usually not instantiated more than once per
system.
Anyway, I'll leave it to Felipe whether to merge v5 or v6 :)
Thanks,
Daniel
--
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
[RFC v1 2/2] usb: otg: Temporarily hold wakeupsource on charger and disconnect events
From: Todd Poynor
usb: otg: Temporarily hold wakeupsource on charger and disconnect events
Allow other parts of the system to react to the charger connect/disconnect
event without allowing the system to suspend before the other parts can process
the event. This wakeup_source times out after 2 seconds; if nobody else holds a
wakeup_source by that time then the device can sleep.
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-ker...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: Android Kernel Team
Cc: John Stultz
Signed-off-by: Todd Poynor
[kiran: Added context to commit message]
Signed-off-by: Kiran Raparthy
---
drivers/usb/phy/otg-wakeupsource.c | 10 +++---
include/linux/usb/otg.h| 2 ++
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/phy/otg-wakeupsource.c
b/drivers/usb/phy/otg-wakeupsource.c
index 7c838d1..9f3c5c1 100644
--- a/drivers/usb/phy/otg-wakeupsource.c
+++ b/drivers/usb/phy/otg-wakeupsource.c
@@ -34,8 +34,11 @@ struct otgws_lock {
struct wakeup_source wsource;
};
-/* VBUS present lock */
-
+/*
+ * VBUS present lock. Also used as a timed lock on charger
+ * connect/disconnect and USB host disconnect, to allow the system
+ * to react to the change in power.
+ */
static struct otgws_lock vbus_lock;
static void otgws_handle_event(unsigned long event)
@@ -59,7 +62,8 @@ static void otgws_handle_event(unsigned long event)
case USB_EVENT_NONE:
case USB_EVENT_ID:
case USB_EVENT_CHARGER:
- __pm_relax(&vbus_lock.wsource);
+ __pm_wakeup_event(&vbus_lock.wsource,
+ msecs_to_jiffies(TEMPORARY_HOLD_TIME));
break;
default:
diff --git a/include/linux/usb/otg.h b/include/linux/usb/otg.h
index 154332b..4243747 100644
--- a/include/linux/usb/otg.h
+++ b/include/linux/usb/otg.h
@@ -11,6 +11,8 @@
#include
+#define TEMPORARY_HOLD_TIME2000
+
struct usb_otg {
u8 default_a;
--
1.8.2.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
[RFC v1 2/2] usb: otg: Temporarily hold wakeupsource on charger and disconnect events
From: Todd Poynor
usb: otg: Temporarily hold wakeupsource on charger and disconnect events
Allow other parts of the system to react to the charger connect/disconnect
event without allowing the system to suspend before the other parts can process
the event. This wakeup_source times out after 2 seconds; if nobody else holds a
wakeup_source by that time then the device can sleep.
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-ker...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: Android Kernel Team
Cc: John Stultz
Signed-off-by: Todd Poynor
[kiran: Added context to commit message]
Signed-off-by: Kiran Raparthy
---
drivers/usb/phy/otg-wakeupsource.c | 10 +++---
include/linux/usb/otg.h| 2 ++
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/phy/otg-wakeupsource.c
b/drivers/usb/phy/otg-wakeupsource.c
index 7c838d1..9f3c5c1 100644
--- a/drivers/usb/phy/otg-wakeupsource.c
+++ b/drivers/usb/phy/otg-wakeupsource.c
@@ -34,8 +34,11 @@ struct otgws_lock {
struct wakeup_source wsource;
};
-/* VBUS present lock */
-
+/*
+ * VBUS present lock. Also used as a timed lock on charger
+ * connect/disconnect and USB host disconnect, to allow the system
+ * to react to the change in power.
+ */
static struct otgws_lock vbus_lock;
static void otgws_handle_event(unsigned long event)
@@ -59,7 +62,8 @@ static void otgws_handle_event(unsigned long event)
case USB_EVENT_NONE:
case USB_EVENT_ID:
case USB_EVENT_CHARGER:
- __pm_relax(&vbus_lock.wsource);
+ __pm_wakeup_event(&vbus_lock.wsource,
+ msecs_to_jiffies(TEMPORARY_HOLD_TIME));
break;
default:
diff --git a/include/linux/usb/otg.h b/include/linux/usb/otg.h
index 154332b..4243747 100644
--- a/include/linux/usb/otg.h
+++ b/include/linux/usb/otg.h
@@ -11,6 +11,8 @@
#include
+#define TEMPORARY_HOLD_TIME2000
+
struct usb_otg {
u8 default_a;
--
1.8.2.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
[RFC v1 1/2] USB: OTG: Hold wakeupsource when VBUS present
From: Todd Poynor
USB: OTG: Hold wakeupsource when VBUS present
Purpose of this is to prevent the system to enter into
suspend state from USB peripheral traffic by hodling a
wakeupsource when USB(otg) is connected and enumerated
in peripheral mode(say adb).
Disabled by default, can enable with:
echo Y > /sys/module/otg_wakeupsource/parameters/enabled
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-ker...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: Android Kernel Team
Cc: John Stultz
Cc: Arve Hj�nnev�g
Cc: Benoit Goby
Signed-off-by: Todd Poynor
[kiran: Added context to commit message.
Included build fix from Benoit Goby and Arve Hj�nnev�g.
Removed lock->held field in driver as this mechanism is
provided in wakeupsource driver.
wakelock(wl) terminology replaced with wakeup_source(ws).
changed to disabled by default from "enable by default".
sys entry(module param) field modified to otg_wakeupsource.
included Todd's refactoring logic.
Introduced get_phy_hook to handle otgws_xceiv per-PHY.
otgws_nb moved to otg_wakeupsource_init function.
__pm_stay_awake and __pm_relax called directly from the main.
code instead of calling them via otgws_grab,otgws_drop.
modified Kconfig help text]
Signed-off-by: Kiran Raparthy
---
drivers/usb/phy/Kconfig| 8 +++
drivers/usb/phy/Makefile | 1 +
drivers/usb/phy/otg-wakeupsource.c | 144 +
3 files changed, 153 insertions(+)
create mode 100644 drivers/usb/phy/otg-wakeupsource.c
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index e253fa0..d9ddd85 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -6,6 +6,14 @@ menu "USB Physical Layer drivers"
config USB_PHY
def_bool n
+config USB_OTG_WAKEUPSOURCE
+ bool "Hold wakeupsource when USB is enumerated in peripheral mode"
+ depends on PM_SLEEP
+ select USB_PHY
+ help
+ Prevent the system going into automatic suspend while
+ it is attached as a USB peripheral by holding a wakeupsource.
+
#
# USB Transceiver Drivers
#
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 24a9133..ca2fbaf 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -3,6 +3,7 @@
#
obj-$(CONFIG_USB_PHY) += phy.o
obj-$(CONFIG_OF) += of.o
+obj-$(CONFIG_USB_OTG_WAKEUPSOURCE) += otg-wakeupsource.o
# transceiver drivers, keep the list sorted
diff --git a/drivers/usb/phy/otg-wakeupsource.c
b/drivers/usb/phy/otg-wakeupsource.c
new file mode 100644
index 000..7c838d1
--- /dev/null
+++ b/drivers/usb/phy/otg-wakeupsource.c
@@ -0,0 +1,144 @@
+/*
+ * otg-wakeupsource.c
+ *
+ * Copyright (C) 2011 Google, Inc.
+ *
+ * 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
+
+bool enabled = false;
+
+static DEFINE_SPINLOCK(otgws_spinlock);
+static struct usb_phy *get_phy_hook(void);
+
+/* Only one lock, but since these 2 fields are associated with each other... */
+
+struct otgws_lock {
+ char name[40];
+ struct wakeup_source wsource;
+};
+
+/* VBUS present lock */
+
+static struct otgws_lock vbus_lock;
+
+static void otgws_handle_event(unsigned long event)
+{
+ unsigned long irqflags;
+
+ spin_lock_irqsave(&otgws_spinlock, irqflags);
+
+ if (!enabled) {
+ __pm_relax(&vbus_lock.wsource);
+ spin_unlock_irqrestore(&otgws_spinlock, irqflags);
+ return;
+ }
+
+ switch (event) {
+ case USB_EVENT_VBUS:
+ case USB_EVENT_ENUMERATED:
+ __pm_stay_awake(&vbus_lock.wsource);
+ break;
+
+ case USB_EVENT_NONE:
+ case USB_EVENT_ID:
+ case USB_EVENT_CHARGER:
+ __pm_relax(&vbus_lock.wsource);
+ break;
+
+ default:
+ break;
+ }
+
+ spin_unlock_irqrestore(&otgws_spinlock, irqflags);
+}
+static struct usb_phy *get_phy_hook(void)
+{
+ struct usb_phy *phy;
+
+ phy = usb_get_phy(USB_PHY_TYPE_USB2);
+
+ if (IS_ERR(phy)) {
+ pr_err("%s: No OTG transceiver found\n", __func__);
+ return NULL;
+ }
+
+ return phy;
+}
+static int otgws_otg_notifications(struct notifier_block *nb,
+ unsigned long event, void *unused)
+{
+ otgws_handle_event(event);
+ return NOTIFY_O
Re: [PATCH v2] usb: hub: Prevent hub autosuspend if usbcore.autosuspend is -1
On 08/28/2014 12:02 AM, Greg KH wrote: > On Wed, Aug 27, 2014 at 12:23:39PM -0700, Greg KH wrote: >> On Wed, Aug 27, 2014 at 03:11:10PM +0300, Roger Quadros wrote: >>> If user specifies that USB autosuspend must be disabled by module >>> parameter "usbcore.autosuspend=-1" then we must prevent >>> autosuspend of USB hub devices as well. >>> >>> commit 596d789a211d introduced in v3.8 changed the original behaivour >>> and stopped respecting the usbcore.autosuspend parameter for hubs. >>> >>> Fixes: 596d789a211d "USB: set hub's default autosuspend delay as 0" >>> >>> Cc: [3.8+] >>> Signed-off-by: Roger Quadros >>> --- >>> drivers/usb/core/hub.c | 8 +++- >>> 1 file changed, 7 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c >>> index 8a4dcbc..59b599d 100644 >>> --- a/drivers/usb/core/hub.c >>> +++ b/drivers/usb/core/hub.c >>> @@ -1728,8 +1728,14 @@ static int hub_probe(struct usb_interface *intf, >>> const struct usb_device_id *id) >>> * - Change autosuspend delay of hub can avoid unnecessary auto >>> * suspend timer for hub, also may decrease power consumption >>> * of USB bus. >>> +* >>> +* - If user has indicated to prevent autosuspend by passing >>> +* usbcore.autosuspend = -1 then keep autosuspend disabled. >>> */ >>> - pm_runtime_set_autosuspend_delay(&hdev->dev, 0); >>> +#ifdef CONFIG_PM_RUNTIME >>> + if (hdev->dev.power.autosuspend_delay >= 0) >>> + pm_runtime_set_autosuspend_delay(&hdev->dev, 0); >>> +#endif >>> >>> /* >>> * Hubs have proper suspend/resume support, except for root hubs >> >> Sorry, but can I have a patch that just adds the #ifdef as I already >> have your original one in my tree. > > This should be all that is needed, right? > > - > > > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c > index 003cb6b1a6bf..46f5161c7891 100644 > --- a/drivers/usb/core/hub.c > +++ b/drivers/usb/core/hub.c > @@ -1732,8 +1732,10 @@ static int hub_probe(struct usb_interface *intf, const > struct usb_device_id *id) >* - If user has indicated to prevent autosuspend by passing >* usbcore.autosuspend = -1 then keep autosuspend disabled. >*/ > +#ifdef CONFIG_PM_RUNTIME > if (hdev->dev.power.autosuspend_delay >= 0) > pm_runtime_set_autosuspend_delay(&hdev->dev, 0); > +#endif > > /* >* Hubs have proper suspend/resume support, except for root hubs > Yes. Thanks Greg. cheers, -roger -- 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 v6 5/5] usb: gadget: f_uac2: send reasonably sized packets
On Wed, Aug 27, 2014 at 10:39 PM, Daniel Mack wrote:
> The UAC2 function driver currently responds to all packets at all times
> with wMaxPacketSize packets. That results in way too fast audio
> playback as the function driver (which is in fact supposed to define
> the audio stream pace) delivers as fast as it can.
>
> Fix this by sizing each packet correctly with the following steps:
>
> a) Set the packet's size by dividing the nominal data rate by the
> playback endpoint's interval.
>
> b) If there is a residual value from the calculation in a), add
> it to a accumulator to keep track of it across packets.
>
> c) If the accumulator has gathered at least the number of bytes
> that are needed for one sample frame, increase the packet size.
>
> This way, the packet size calculation will get rid of any kind of
> imprecision that would otherwise occur with a simple division over
> time.
>
> Some of the variables that are needed while processing each packet
> are pre-computed for performance reasons.
>
> Signed-off-by: Daniel Mack
> ---
> drivers/usb/gadget/function/f_uac2.c | 69
> +---
> 1 file changed, 65 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/f_uac2.c
> b/drivers/usb/gadget/function/f_uac2.c
> index 246a778..a5a27a5 100644
> --- a/drivers/usb/gadget/function/f_uac2.c
> +++ b/drivers/usb/gadget/function/f_uac2.c
> @@ -92,6 +92,15 @@ struct snd_uac2_chip {
>
> struct snd_card *card;
> struct snd_pcm *pcm;
> +
> + /* timekeeping for the playback endpoint */
> + unsigned int p_interval;
> + unsigned int p_residue;
> +
> + /* pre-calculated values for playback iso completion */
> + unsigned int p_pktsize;
> + unsigned int p_pktsize_residue;
> + unsigned int p_framesize;
> };
>
I admire Alan's simple algo. I couldn't have matched that.
However I am not sure how worth is the implementation if it requires 3
more members to avoid calculations simple enough to cause no
noticeable overhead. Once every millisecond is perfectly bearable IMO.
5 members in uac2 structure for only playback, look ugly.
regards,
-jassi
>
> #define BUFF_SIZE_MAX (PAGE_SIZE * 16)
> @@ -191,8 +200,29 @@ agdev_iso_complete(struct usb_ep *ep, struct usb_request
> *req)
>
> spin_lock_irqsave(&prm->lock, flags);
>
> - if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
> + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
> + /*
> +* For each IN packet, take the quotient of the current data
> +* rate and the endpoint's interval as the base packet size.
> +* If there is a residue from this division, add it to the
> +* residue accumulator.
> +*/
> + req->length = uac2->p_pktsize;
> + uac2->p_residue += uac2->p_pktsize_residue;
> +
> + /*
> +* Whenever there are more bytes in the accumulator than we
> +* need to add one more sample frame, increase this packet's
> +* size and decrease the accumulator.
> +*/
> + if (uac2->p_residue / uac2->p_interval >= uac2->p_framesize) {
> + req->length += uac2->p_framesize;
> + uac2->p_residue -= uac2->p_framesize *
> + uac2->p_interval;
> + }
> +
> req->actual = req->length;
> + }
>
> pending = prm->hw_ptr % prm->period_size;
> pending += req->actual;
> @@ -346,6 +376,7 @@ static int uac2_pcm_open(struct snd_pcm_substream
> *substream)
> c_srate = opts->c_srate;
> p_chmask = opts->p_chmask;
> c_chmask = opts->c_chmask;
> + uac2->p_residue = 0;
>
> runtime->hw = uac2_pcm_hardware;
>
> @@ -1077,7 +1108,7 @@ afunc_set_alt(struct usb_function *fn, unsigned intf,
> unsigned alt)
> struct usb_request *req;
> struct usb_ep *ep;
> struct uac2_rtd_params *prm;
> - int i;
> + int req_len, i;
>
> /* No i/f has more than 2 alt settings */
> if (alt > 1) {
> @@ -1099,11 +1130,41 @@ afunc_set_alt(struct usb_function *fn, unsigned intf,
> unsigned alt)
> prm = &uac2->c_prm;
> config_ep_by_speed(gadget, fn, ep);
> agdev->as_out_alt = alt;
> + req_len = prm->max_psize;
> } else if (intf == agdev->as_in_intf) {
> + struct f_uac2_opts *opts = agdev_to_uac2_opts(agdev);
> + unsigned int factor, rate;
> + struct usb_endpoint_descriptor *ep_desc;
> +
> ep = agdev->in_ep;
> prm = &uac2->p_prm;
> config_ep_by_speed(gadget, fn, ep);
> agdev->as_in_alt = alt;
> +
> + /* pre-calculate the playback endpoint's interval */
> + if (ga
Re: [RFC PATCH 0/7] usb: gadget: add reset API at usb_gadget_driver
On Wed, Aug 27, 2014 at 04:20:25PM -0400, Alan Stern wrote: > On Wed, 27 Aug 2014, Felipe Balbi wrote: > > > > Hi Alan & Felipe, > > > > > > During the changing UDC drivers process, I find we can't simply move > > > usb_gadget_disconnect to usb_gadget_driver.disconnect, some UDC > > > drivers (like dwc3) will be no chance to set software pullup bit > > > (dp control always means software dp pullup bit if no specific at below) > > > again between disconnection and re-connection. > > > > sorry, can you rephrase this a bit, I really can't get what you mean. > > > > DWC3 doesn't really have a pullup bit. It's got a RUN/STOP bit. Sure, it > > controls the pullups but it also kills the internal DMA and quite a bit > > of other internal blocks. > > > > The way the code is today, we will have a pullup connected when a gadget > > driver is loaded and not before that. > > > > > There are two kinds of UDCs, dp is always pullup(UDC-A), pullup dp relies > > > on vbus (UDC-B), so we may need to introduce a flag like pullup_on_vbus > > > at struct usb_gadget, UDC-B needs to set this flag at .udc_start. > > > > > > For the whole gadget life cycle, the dp change for the two kinds of > > > UDC like below: > > > Process dp at UDC-A dp at UDC-B > > > insmod1 0 > > > connect 1 1 > > > bus_reset 1 1 > > > disconnect1 0 > > > rmmod 0 0 > > > > > > For insmod/rmmod gadget driver, we can control dp at udc-core relies > > > on flag pullup_on_vbus. > > > > > > For other three stages (no need to control at bus_reset), we can control > > > dp > > > at two gadget driver's API relies on flag pullup_on_vbus. > > > > I also can't get what you mean here. > > I think Peter is saying that some UDC hardware (which he calls UDC-A) > automatically turns off the pullup when Vbus is absent, whereas other > hardware (UDC-B) relies on software to do this. > > I'm not sure why this matters, however. Does anything go wrong if the > driver tells UDC-A hardware to turn off the pullup when the cable is > unplugged and Vbus goes away? Like I replied at last email, the UDC-A has no chance to pullup dp again after cable has connected if there is no vbus handler to do it (.vbus_session). If we don't no pullup dp, there will be no interrupt, the line state is SE0 after cable has connected. > > > > Do you agree above? > > > > > > If you agree, the first patchset for adding reset API at > > > usb_gadget_driver may > > > do less thing, and the reset API implementation at each gadget driver is > > > the > > > same with disconnect. > > > > that's why we never had a ->reset() callback so far. From a gadget > > driver perspective, it's the same as disconnect followed by a connect. > > > > > At the second patchset, we introduce the flag pullup_on_vbus, connect API > > > at usb_gadget_driver, change the disconnect implementation at > > > each gadget driver, and add control dp through function driver. > > > > IIRC, only mass storage gadget was showing a need for a ->reset() > > callback, why would you need to modify every gadget driver ? > > The mass-storage gadget is a function driver, not a gadget driver. > Even g_mass_storage.c is simply a single-function wrapper; it still > relies on the composite layer. > > There are only four gadget drivers in the tree: composite, configfs, > gadgetfs, and dbgp. > > Alan Stern > -- 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
Re: [RFC PATCH 0/7] usb: gadget: add reset API at usb_gadget_driver
On Wed, Aug 27, 2014 at 03:29:20PM -0500, Felipe Balbi wrote: > On Wed, Aug 27, 2014 at 04:20:25PM -0400, Alan Stern wrote: > > On Wed, 27 Aug 2014, Felipe Balbi wrote: > > > > > > Hi Alan & Felipe, > > > > > > > > During the changing UDC drivers process, I find we can't simply move > > > > usb_gadget_disconnect to usb_gadget_driver.disconnect, some UDC > > > > drivers (like dwc3) will be no chance to set software pullup bit > > > > (dp control always means software dp pullup bit if no specific at below) > > > > again between disconnection and re-connection. > > > > > > > > > that's why we never had a ->reset() callback so far. From a gadget > > > driver perspective, it's the same as disconnect followed by a connect. > > > > > > > At the second patchset, we introduce the flag pullup_on_vbus, connect > > > > API > > > > at usb_gadget_driver, change the disconnect implementation at > > > > each gadget driver, and add control dp through function driver. > > > > > > IIRC, only mass storage gadget was showing a need for a ->reset() > > > callback, why would you need to modify every gadget driver ? > > > > The mass-storage gadget is a function driver, not a gadget driver. > > Even g_mass_storage.c is simply a single-function wrapper; it still > > relies on the composite layer. > > > > There are only four gadget drivers in the tree: composite, configfs, > > gadgetfs, and dbgp. > > right, but those are the only ones which should be modified. For all > gadget drivers which are composed of function drivers (even single > function drivers) they should rely on the function knowing what to do, > otherwise we might still mistakenly connect to the host when some > userspace daemon isn't ready yet. > Yes, like Alan said, we only need to modify above four gadget drivers for changing dp pullup strategies, other legacy drivers will rely on their function drivers. -- 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
Re: [RFC PATCH 0/7] usb: gadget: add reset API at usb_gadget_driver
On Wed, Aug 27, 2014 at 02:37:35PM -0500, Felipe Balbi wrote: > Hi, > > On Tue, Aug 26, 2014 at 03:30:32PM +0800, Peter Chen wrote: > > On Mon, Aug 25, 2014 at 11:27:47AM -0400, Alan Stern wrote: > > > On Mon, 25 Aug 2014, Peter Chen wrote: > > > > > > > Hi Felipe & Alan, > > > > > > > > It is the follow-up for: > > > > http://www.spinics.net/lists/linux-usb/msg112193.html > > > > > > > > This patchset adds reset API at usb_gadget_driver, the UDC driver > > > > can call it at bus_reset handler instead of calling disconnect. > > > > The benefits of this patchset are: > > > > - We can let the gadget driver do different things for bus reset. > > > > and host is disconnected, eg, whether pull down dp or not. > > > > - Match kernel doc for disconnect API, it says it is invoked > > > > "when the host is disconnected". > > > > - Will be more match for the real things the gadget driver > > > > does for connect and disconnect, when we introduce connect API later. > > > > > > > > The reason for I mark RFC is I don't add the modification for mass > > > > UDC driver changes, if you consider this patchset is ok, I will > > > > add them without RFC later. > > > > > > This looks good. > > > > > > In patches 2, 4, and 5, shouldn't you call usb_gadget_disconnect() > > > _before_ the gadget driver's original disconnect handler, instead of > > > _after_? That's how we do it now. > > > > > > > Hi Alan & Felipe, > > > > During the changing UDC drivers process, I find we can't simply move > > usb_gadget_disconnect to usb_gadget_driver.disconnect, some UDC > > drivers (like dwc3) will be no chance to set software pullup bit > > (dp control always means software dp pullup bit if no specific at below) > > again between disconnection and re-connection. > > sorry, can you rephrase this a bit, I really can't get what you mean. > > DWC3 doesn't really have a pullup bit. It's got a RUN/STOP bit. Sure, it > controls the pullups but it also kills the internal DMA and quite a bit > of other internal blocks. It is the same with chipidea, it has RUN/STOP bit at usbcmd, and its function is most like dwc3's. If the RUN/STOP bit is cleared at usb_gadget_driver.disconnect when the cable is disconnected, when we set it again after cable is connected? The UDC drivers who has vbus handler can set run/stop bit at .vbus_session, but if the UDC drivers do not have vbus handler, where we can set it? > > The way the code is today, we will have a pullup connected when a gadget > driver is loaded and not before that. > > > There are two kinds of UDCs, dp is always pullup(UDC-A), pullup dp relies > > on vbus (UDC-B), so we may need to introduce a flag like pullup_on_vbus > > at struct usb_gadget, UDC-B needs to set this flag at .udc_start. > > > > For the whole gadget life cycle, the dp change for the two kinds of > > UDC like below: > > Process dp at UDC-A dp at UDC-B > > insmod 1 0 > > connect 1 1 > > bus_reset 1 1 > > disconnect 1 0 > > rmmod 0 0 > > > > For insmod/rmmod gadget driver, we can control dp at udc-core relies > > on flag pullup_on_vbus. > > > > For other three stages (no need to control at bus_reset), we can control dp > > at two gadget driver's API relies on flag pullup_on_vbus. > > I also can't get what you mean here. If the UDC driver doesn't want to pull up dp at insmod gadget driver, it can pull up dp when the cable is connected. > > > Do you agree above? > > > > If you agree, the first patchset for adding reset API at usb_gadget_driver > > may > > do less thing, and the reset API implementation at each gadget driver is the > > same with disconnect. > > that's why we never had a ->reset() callback so far. From a gadget > driver perspective, it's the same as disconnect followed by a connect. Yes, it is the current design, but if we want to call usb_gadget_disconnect at ->disconnect callback, things will be different, besides, the kernel doc says it is invoked when "when the host is disconnected". -- 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
Re: [PATCH 02/13] usb: udc: set the udc is ready to pullup dp when it needs
On Wed, Aug 27, 2014 at 02:22:30PM -0500, Felipe Balbi wrote: > On Wed, Aug 20, 2014 at 01:30:40PM +0800, Peter Chen wrote: > > On Tue, Aug 19, 2014 at 09:02:54PM +, Paul Zimmerman wrote: > > > > From: linux-usb-ow...@vger.kernel.org > > > > [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Peter Chen > > > > Sent: Tuesday, August 19, 2014 7:26 AM > > > > > > > > On Tue, Aug 19, 2014 at 01:46:17AM +, Paul Zimmerman wrote: > > > > > > From: Peter Chen [mailto:peter.c...@freescale.com] > > > > > > Sent: Sunday, August 17, 2014 9:14 PM > > > > > > > > > > > > Except for chipidea driver, all other udc drivers will tell the > > > > > > gadget driver that they are ready to pullup dp at udc_start, it > > > > > > is the default behaviour. > > > > > > > > > > > > The chipidea driver is ready to pullup dp when the vbus is there, > > > > > > and isn't ready to pullup dp when the vbus is not there. Other > > > > > > udc drivers which should not pull up when vbus is not there should > > > > > > change like chipidea does to pass the Back-Voltage Testing at > > > > > > www.usb.org/developers/docs/USB-IFTestProc1_3.pdf. > > > > > > > > > > > > Signed-off-by: Peter Chen > > > > > > --- > > > > > > drivers/usb/chipidea/udc.c |9 - > > > > > > drivers/usb/dwc2/gadget.c |2 ++ > > > > > > drivers/usb/dwc3/gadget.c |2 ++ > > > > > > drivers/usb/gadget/udc/amd5536udc.c |1 + > > > > > > drivers/usb/gadget/udc/atmel_usba_udc.c |2 ++ > > > > > > drivers/usb/gadget/udc/bcm63xx_udc.c|2 ++ > > > > > > drivers/usb/gadget/udc/dummy_hcd.c |1 + > > > > > > drivers/usb/gadget/udc/fotg210-udc.c|1 + > > > > > > drivers/usb/gadget/udc/fsl_qe_udc.c |1 + > > > > > > drivers/usb/gadget/udc/fsl_udc_core.c |2 ++ > > > > > > drivers/usb/gadget/udc/fusb300_udc.c|1 + > > > > > > drivers/usb/gadget/udc/gr_udc.c |2 ++ > > > > > > drivers/usb/gadget/udc/lpc32xx_udc.c|2 ++ > > > > > > drivers/usb/gadget/udc/m66592-udc.c |2 ++ > > > > > > drivers/usb/gadget/udc/mv_u3d_core.c|1 + > > > > > > drivers/usb/gadget/udc/mv_udc_core.c|2 ++ > > > > > > drivers/usb/gadget/udc/net2272.c|1 + > > > > > > drivers/usb/gadget/udc/net2280.c|1 + > > > > > > drivers/usb/gadget/udc/omap_udc.c |1 + > > > > > > drivers/usb/gadget/udc/pch_udc.c|1 + > > > > > > drivers/usb/gadget/udc/pxa25x_udc.c |1 + > > > > > > drivers/usb/gadget/udc/pxa27x_udc.c |1 + > > > > > > drivers/usb/gadget/udc/r8a66597-udc.c |1 + > > > > > > drivers/usb/gadget/udc/s3c-hsudc.c |1 + > > > > > > drivers/usb/gadget/udc/s3c2410_udc.c|1 + > > > > > > drivers/usb/musb/musb_gadget.c |2 ++ > > > > > > drivers/usb/renesas_usbhs/mod_gadget.c |7 ++- > > > > > > 27 files changed, 45 insertions(+), 6 deletions(-) > > > > > > > > > > Instead of modifying all of the UDC drivers, how about adding a flag > > > > > to > > > > > 'struct usb_gadget' named 'needs_ready' or similar? If the UDC doesn't > > > > > set the flag, udc-core would call usb_udc_ready_to_connect() on behalf > > > > > of the UDC. If the UDC sets the flag (chipidea only?) then the UDC > > > > > would > > > > > be responsible for calling usb_udc_ready_to_connect(). > > > > > > > > > > > > > USB spec requires dp is not pulled up when the vbus is not there, the > > > > dwc3 is > > > > the newest core, I don't think other older udc cores all has similar > > > > capability > > > > that does don't draw back voltage if software pullup bit is set and > > > > vbus is > > > > not there. > > > > > > > > This patchset will delete the unconditional pullup dp operation at > > > > udc-core, > > > > and we need to pullup dp at the end of hardware initialization (not > > > > consider > > > > vbus case), then the end of .udc_start at udc driver is the old place. > > > > > > I think you misunderstood my suggestion. Since you are adding a call > > > to usb_udc_ready_to_connect() at the end of almost every .udc_start > > > function, why not have udc-core do it instead, immediately after the > > > call to .udc_start? Unless the 'needs_ready' flag is set, which would > > > only be set by the udc drivers for those controllers that need it. > > > > > > > Thanks. > > > > Yes, we can do that, my original plan is > > usb_gadget_connect/usb_gadget_disconnect > > are only called by gadget driver. If Felipe has no comment for it, I will > > not directly though. At least not for those using the composite layer. > All functions using composite layer should use activate/deactivate. > > -- But the first usb_gadget_connect can't be called by most of function drivers, it needs to be called after .udc_start. -- 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 Mor
Re: [PATCH 2/2] doc: dt: mxs-phy: add compatible string for imx6sx-usbphy
On Wed, Aug 27, 2014 at 02:09:04PM -0500, Felipe Balbi wrote: > On Tue, Aug 26, 2014 at 10:55:18AM +0800, Peter Chen wrote: > > Add compatible string for imx6sx-usbphy. > > > > Signed-off-by: Peter Chen > > do I need to take this one as well or will DT folks take care of patch 2 ? > It is DT change for driver, if there is no objection from DT guys, the driver maintainer needs to take it. -- 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
Re: [PATCH] usb: gadget: use $(srctree) instead of $(PWD) for includes
On Wed, Aug 27, 2014 at 10:42 AM, wrote: > From: Yegor Yefremov > > Using $(PWD) breaks builds when make was invoked from outside > of the kernel tree. Some details: I've experienced this issue with Buildroot. I don't know, if this will happen with OpenEmbedded, but it is also possible. So far gadget subsystems is the only one, that uses $(PWD) for include directories and the changes were newly introduced due to subsystem cleanup. It would be great, if this can be fixed before releasing 3.17. Regards, Yegor -- 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/5] usb: dwc3/phy-exynos5-usbdrd: Extend support to Exynos7
Adding required support for clocks and additional VBUS regulators to enable USB 3.0 support on Exynos7 SoC. This series depends for ACRH_EXYNOS7 support on following series: [PATCH 00/14] Support 64bit Cortex A57 based Exynos7 SoC https://www.mail-archive.com/devicetree@vger.kernel.org/msg39392.html The series is based on usb-next branch. Vivek Gautam (5): usb: dwc3: exynos: Add support for SCLK present on Exynos7 phy: exynos5-usbdrd: Add pipe-clk and utmi-clk support phy: exynos5-usbdrd: Add facility for VBUS-BOOST-5V supply usb: dwc3: Adding Kconfig dependency for Exynos7 phy: exynos5-usbdrd: Adding Kconfig dependency for Exynos7 .../devicetree/bindings/phy/samsung-phy.txt|4 ++ drivers/phy/Kconfig|2 +- drivers/phy/phy-exynos5-usbdrd.c | 51 +++- drivers/usb/dwc3/Kconfig |2 +- drivers/usb/dwc3/dwc3-exynos.c | 16 ++ 5 files changed, 71 insertions(+), 4 deletions(-) -- 1.7.10.4 -- 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/5] phy: exynos5-usbdrd: Add pipe-clk and utmi-clk support
Exynos7 SoC has now separate gate control for 125MHz pipe3 phy
clock, as well as 60MHz utmi phy clock.
So get the same and control in the phy-exynos5-usbdrd driver.
Signed-off-by: Vivek Gautam
---
.../devicetree/bindings/phy/samsung-phy.txt|4
drivers/phy/phy-exynos5-usbdrd.c | 24
2 files changed, 28 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 7a6feea..b64d616 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -135,6 +135,10 @@ Required properties:
PHY operations, associated by phy name. It is used to
determine bit values for clock settings register.
For Exynos5420 this is given as 'sclk_usbphy30' in CMU.
+ - optional clocks: Next gen Exynos SoCs have following additional
+ gate clocks available:
+ - phy_pipe: for PIPE3 phy
+ - phy_utmi: for UTMI+ phy
- samsung,pmu-syscon: phandle for PMU system controller interface, used to
control pmu registers for power isolation.
- #phy-cells : from the generic PHY bindings, must be 1;
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index b05302b..685c108 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -148,6 +148,8 @@ struct exynos5_usbdrd_phy_drvdata {
* @dev: pointer to device instance of this platform device
* @reg_phy: usb phy controller register memory base
* @clk: phy clock for register access
+ * @pipeclk: clock for pipe3 phy
+ * @utmiclk: clock for utmi+ phy
* @drv_data: pointer to SoC level driver data structure
* @phys[]: array for 'EXYNOS5_DRDPHYS_NUM' number of PHY
* instances each with its 'phy' and 'phy_cfg'.
@@ -161,6 +163,8 @@ struct exynos5_usbdrd_phy {
struct device *dev;
void __iomem *reg_phy;
struct clk *clk;
+ struct clk *pipeclk;
+ struct clk *utmiclk;
const struct exynos5_usbdrd_phy_drvdata *drv_data;
struct phy_usb_instance {
struct phy *phy;
@@ -446,6 +450,10 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
dev_dbg(phy_drd->dev, "Request to power_on usbdrd_phy phy\n");
+ if (!IS_ERR(phy_drd->utmiclk))
+ clk_prepare_enable(phy_drd->utmiclk);
+ if (!IS_ERR(phy_drd->pipeclk))
+ clk_prepare_enable(phy_drd->pipeclk);
clk_prepare_enable(phy_drd->ref_clk);
/* Enable VBUS supply */
@@ -464,6 +472,10 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
fail_vbus:
clk_disable_unprepare(phy_drd->ref_clk);
+ if (!IS_ERR(phy_drd->pipeclk))
+ clk_disable_unprepare(phy_drd->pipeclk);
+ if (!IS_ERR(phy_drd->utmiclk))
+ clk_disable_unprepare(phy_drd->utmiclk);
return ret;
}
@@ -483,6 +495,10 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
regulator_disable(phy_drd->vbus);
clk_disable_unprepare(phy_drd->ref_clk);
+ if (!IS_ERR(phy_drd->pipeclk))
+ clk_disable_unprepare(phy_drd->pipeclk);
+ if (!IS_ERR(phy_drd->utmiclk))
+ clk_disable_unprepare(phy_drd->utmiclk);
return 0;
}
@@ -581,6 +597,14 @@ static int exynos5_usbdrd_phy_probe(struct platform_device
*pdev)
return PTR_ERR(phy_drd->clk);
}
+ phy_drd->pipeclk = devm_clk_get(dev, "phy_pipe");
+ if (IS_ERR(phy_drd->pipeclk))
+ dev_warn(dev, "Failed to get pipe3 phy operational clock\n");
+
+ phy_drd->utmiclk = devm_clk_get(dev, "phy_utmi");
+ if (IS_ERR(phy_drd->utmiclk))
+ dev_warn(dev, "Failed to get utmi phy operational clock\n");
+
phy_drd->ref_clk = devm_clk_get(dev, "ref");
if (IS_ERR(phy_drd->ref_clk)) {
dev_err(dev, "Failed to get reference clock of usbdrd phy\n");
--
1.7.10.4
--
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 4/5] usb: dwc3: Adding Kconfig dependency for Exynos7
The Exynos-DWC3 USB 3.0 DRD controller is also present on Exynos7 platform, so adding the dependency on ARCH_EXYNOS7 for this driver. Signed-off-by: Vivek Gautam --- drivers/usb/dwc3/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig index 785510a..e235894 100644 --- a/drivers/usb/dwc3/Kconfig +++ b/drivers/usb/dwc3/Kconfig @@ -55,7 +55,7 @@ config USB_DWC3_OMAP config USB_DWC3_EXYNOS tristate "Samsung Exynos Platform" - depends on ARCH_EXYNOS || COMPILE_TEST + depends on (ARCH_EXYNOS || ARCH_EXYNOS7) || COMPILE_TEST default USB_DWC3 help Recent Exynos5 SoCs ship with one DesignWare Core USB3 IP inside, -- 1.7.10.4 -- 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/5] usb: dwc3: exynos: Add support for SCLK present on Exynos7
Exynos7 also has a separate special gate clock going to the IP
apart from the usual AHB clock. So add support for the same.
Signed-off-by: Vivek Gautam
---
drivers/usb/dwc3/dwc3-exynos.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index f9fb8ad..bab6395 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -35,6 +35,7 @@ struct dwc3_exynos {
struct device *dev;
struct clk *clk;
+ struct clk *sclk;
struct regulator*vdd33;
struct regulator*vdd10;
};
@@ -141,10 +142,17 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
return -EINVAL;
}
+ /* Exynos7 has a special gate clock going to this IP */
+ exynos->sclk = devm_clk_get(dev, "usbdrd30_sclk");
+ if (IS_ERR(exynos->sclk))
+ dev_warn(dev, "couldn't get sclk\n");
+
exynos->dev = dev;
exynos->clk = clk;
clk_prepare_enable(exynos->clk);
+ if (!IS_ERR(exynos->sclk))
+ clk_prepare_enable(exynos->sclk);
exynos->vdd33 = devm_regulator_get(dev, "vdd33");
if (IS_ERR(exynos->vdd33)) {
@@ -187,6 +195,8 @@ err4:
err3:
regulator_disable(exynos->vdd33);
err2:
+ if (!IS_ERR(exynos->sclk))
+ clk_disable_unprepare(exynos->sclk);
clk_disable_unprepare(clk);
return ret;
}
@@ -199,6 +209,8 @@ static int dwc3_exynos_remove(struct platform_device *pdev)
platform_device_unregister(exynos->usb2_phy);
platform_device_unregister(exynos->usb3_phy);
+ if (!IS_ERR(exynos->sclk))
+ clk_disable_unprepare(exynos->sclk);
clk_disable_unprepare(exynos->clk);
regulator_disable(exynos->vdd33);
@@ -220,6 +232,8 @@ static int dwc3_exynos_suspend(struct device *dev)
{
struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+ if (!IS_ERR(exynos->sclk))
+ clk_disable(exynos->sclk);
clk_disable(exynos->clk);
regulator_disable(exynos->vdd33);
@@ -245,6 +259,8 @@ static int dwc3_exynos_resume(struct device *dev)
}
clk_enable(exynos->clk);
+ if (!IS_ERR(exynos->sclk))
+ clk_enable(exynos->sclk);
/* runtime set active to reflect active state. */
pm_runtime_disable(dev);
--
1.7.10.4
--
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/5] phy: exynos5-usbdrd: Add facility for VBUS-BOOST-5V supply
Some Exynos SoCs have a separate regulator controlling a
Boost 5V supply which goes as input for VBUS regulator.
So adding a control for the same in driver, to enable
vbus supply on the port.
Signed-off-by: Vivek Gautam
---
drivers/phy/phy-exynos5-usbdrd.c | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index 685c108..a6d0cb7 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -176,6 +176,7 @@ struct exynos5_usbdrd_phy {
u32 extrefclk;
struct clk *ref_clk;
struct regulator *vbus;
+ struct regulator *vbus_boost;
};
static inline
@@ -457,11 +458,19 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
clk_prepare_enable(phy_drd->ref_clk);
/* Enable VBUS supply */
+ if (phy_drd->vbus_boost) {
+ ret = regulator_enable(phy_drd->vbus_boost);
+ if (ret) {
+ dev_err(phy_drd->dev,
+ "Failed to enable VBUS boost supply\n");
+ goto fail_vbus;
+ }
+ }
if (phy_drd->vbus) {
ret = regulator_enable(phy_drd->vbus);
if (ret) {
dev_err(phy_drd->dev, "Failed to enable VBUS supply\n");
- goto fail_vbus;
+ goto fail_vbus_boost;
}
}
@@ -470,6 +479,9 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
return 0;
+fail_vbus_boost:
+ if (phy_drd->vbus_boost)
+ regulator_disable(phy_drd->vbus_boost);
fail_vbus:
clk_disable_unprepare(phy_drd->ref_clk);
if (!IS_ERR(phy_drd->pipeclk))
@@ -493,6 +505,8 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
/* Disable VBUS supply */
if (phy_drd->vbus)
regulator_disable(phy_drd->vbus);
+ if (phy_drd->vbus_boost)
+ regulator_disable(phy_drd->vbus_boost);
clk_disable_unprepare(phy_drd->ref_clk);
if (!IS_ERR(phy_drd->pipeclk))
@@ -645,7 +659,7 @@ static int exynos5_usbdrd_phy_probe(struct platform_device
*pdev)
break;
}
- /* Get Vbus regulator */
+ /* Get Vbus regulators */
phy_drd->vbus = devm_regulator_get(dev, "vbus");
if (IS_ERR(phy_drd->vbus)) {
ret = PTR_ERR(phy_drd->vbus);
@@ -655,6 +669,15 @@ static int exynos5_usbdrd_phy_probe(struct platform_device
*pdev)
dev_warn(dev, "Failed to get VBUS supply regulator\n");
phy_drd->vbus = NULL;
}
+ phy_drd->vbus_boost = devm_regulator_get(dev, "vbus-boost");
+ if (IS_ERR(phy_drd->vbus_boost)) {
+ ret = PTR_ERR(phy_drd->vbus_boost);
+ if (ret == -EPROBE_DEFER)
+ return ret;
+
+ dev_warn(dev, "Failed to get VBUS boost supply regulator\n");
+ phy_drd->vbus_boost = NULL;
+ }
dev_vdbg(dev, "Creating usbdrd_phy phy\n");
--
1.7.10.4
--
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/5] phy: exynos5-usbdrd: Adding Kconfig dependency for Exynos7
This USB 3.0 PHY controller is also present on Exynos7 platform, so adding the dependency on ARCH_EXYNOS7 for this driver. Signed-off-by: Vivek Gautam --- drivers/phy/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 0dd7427..c3bc380 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -186,7 +186,7 @@ config PHY_EXYNOS5250_USB2 config PHY_EXYNOS5_USBDRD tristate "Exynos5 SoC series USB DRD PHY driver" - depends on ARCH_EXYNOS5 && OF + depends on (ARCH_EXYNOS5 || ARCH_EXYNOS7) && OF depends on HAS_IOMEM depends on USB_DWC3_EXYNOS select GENERIC_PHY -- 1.7.10.4 -- 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
