Hi,
On Mon, Apr-07-2014 at 06:02:18 PM -0500, Felipe Balbi wrote:
Hi,
On Mon, Apr 07, 2014 at 03:12:09PM -0700, Randy Dunlap wrote:
On 04/05/2014 11:42 AM, Apelete Seketeli wrote:
Document the process of writing an musb glue layer by taking the
Ingenic JZ4740 glue layer as an example,
On 07.04.2014 18:04, Felipe Balbi wrote:
snip
that's not caused by my patch, it's a previously existing bug. This
should sort it out:
commit e7f69404a878b5345ad07bf06d78559ecd31db79
Author: Felipe Balbi ba...@ti.com
Date: Mon Apr 7 10:58:01 2014 -0500
usb: musb: omap2430: make
On Tue, Apr 08, 2014 at 11:05:20AM +0800, Xiao Jin wrote:
We find two problems on acm tty write delayed mechanism.
Then you should split this into two patches.
(1) When acm resume, the delayed wb will be started. But now
only one write can be saved during acm suspend. More acm write
may be
I completely understand your frustration, and it actually is relevant to
kernel development. :) Perhaps the attached patch would have at least
saved you some time and frustration in debugging the driver and host
issue?
Thanks Sarah. An error like that would allow me to know what the error
On Mon, Apr 07, 2014 at 07:26:01PM +0300, Mathias Nyman wrote:
On 04/03/2014 07:32 PM, Johan Hovold wrote:
Hi Mathias and Benjamin,
Mathias, I understand you've got quite a lot on your plate with xhci at
the moment, but have you had a change to look at this issue yet? It's an
xhci-issue
AceLan Kao acelan@canonical.com writes:
Hi,
I'm not an expert of this field, so I can't really understand your reply.
So, is the patch is acceptable?
And I have another pci modem card with id 413c:81a3.
I tried to add its id into sierra driver, but no luck.
I still don't think the
Glue layers for the DWC3 driver only make sense on specific platforms.
Add dependencies so that they are not built where they aren't needed.
Signed-off-by: Jean Delvare jdelv...@suse.de
Cc: Felipe Balbi ba...@ti.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: WingMan Kwok w-kw...@ti.com
-- Forwarded message --
From: Russel Hughes russel.hug...@gmail.com
Date: 6 April 2014 11:32
Subject: Isochronos audio
To: linux-usb linux-usb@vger.kernel.org
Can you describe the actual problem ? How can you trigger it ? What are
you doing when the problem arises ? Do you
On Tue, 2014-04-08 at 09:33 +0200, Johan Hovold wrote:
On Tue, Apr 08, 2014 at 11:05:20AM +0800, Xiao Jin wrote:
We find two problems on acm tty write delayed mechanism.
Then you should split this into two patches.
(1) When acm resume, the delayed wb will be started. But now
only one
On Tue, 2014-04-08 at 09:33 +0200, Johan Hovold wrote:
On Tue, Apr 08, 2014 at 11:05:20AM +0800, Xiao Jin wrote:
(2) acm tty port ASYNCB_INITIALIZED flag will be cleared when
close. If acm resume callback run after ASYNCB_INITIALIZED flag
cleared, there will have no chance for delayed
(2) acm tty port ASYNCB_INITIALIZED flag will be cleared when
close. If acm resume callback run after ASYNCB_INITIALIZED flag
cleared, there will have no chance for delayed write to start.
That lead to acm_wb.use can't be cleared. If user space open
acm tty again and try to setd, tty will be
dear linuxfoundation:
I'm not sure if you receive our mails in lase week , i resend it now.
Please confirm whether it is correct format for submit.
Looking forward to your reply.
modify reason:
1. Move device pid fffe from zte_ev.c back to option.c for our company.
2. Modify the
hi Alan:
2014-04-07 10:06 GMT+08:00 Alan Stern st...@rowland.harvard.edu:
On Sun, 6 Apr 2014, vichy wrote:
hi alan:
Why you think it is a bug in hardware?
The timeout error means that the kernel told the controller to turn off
the PORT_RESET bit, and 1000 us later the bit was still on.
[ +CC: Oliver ]
On Tue, Apr 08, 2014 at 12:22:29PM +0100, One Thousand Gnomes wrote:
(2) acm tty port ASYNCB_INITIALIZED flag will be cleared when
close. If acm resume callback run after ASYNCB_INITIALIZED flag
cleared, there will have no chance for delayed write to start.
That lead to
[ +CC: Alan ]
On Tue, Apr 08, 2014 at 12:33:31PM +0200, Oliver Neukum wrote:
On Tue, 2014-04-08 at 09:33 +0200, Johan Hovold wrote:
On Tue, Apr 08, 2014 at 11:05:20AM +0800, Xiao Jin wrote:
(2) acm tty port ASYNCB_INITIALIZED flag will be cleared when
close. If acm resume callback run
On Tue, 2014-04-08 at 15:17 +0200, Johan Hovold wrote:
[ +CC: Alan ]
On Tue, Apr 08, 2014 at 12:33:31PM +0200, Oliver Neukum wrote:
On Tue, 2014-04-08 at 09:33 +0200, Johan Hovold wrote:
On Tue, Apr 08, 2014 at 11:05:20AM +0800, Xiao Jin wrote:
(2) acm tty port ASYNCB_INITIALIZED
Hi,
On Tue, Apr 08, 2014 at 09:24:09AM +0200, Stefan Roese wrote:
On 07.04.2014 18:04, Felipe Balbi wrote:
snip
that's not caused by my patch, it's a previously existing bug. This
should sort it out:
commit e7f69404a878b5345ad07bf06d78559ecd31db79
Author: Felipe Balbi
Removing this older USB 3.0 DRD controller PHY driver, since
a new driver based on generic phy framework is now available.
Also removing the dt node for older driver from Exynos5250
device tree and updating the dt node for DWC3 controller.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
Add device tree node for new usbdrd-phy driver, which
is based on generic phy framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
Patch : 14982e3 USB: OHCI: Properly handle ohci-exynos suspend
has already removed 'ohci_hcd' settings from exynos glue layer
as a part of streamlining the ohci controller's suspend.
So we don't need the locks for 'ohci_hcd' anymore.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc:
Add device tree nodes for DWC3 controller present on
Exynos 5420 SoC, to enable support for USB 3.0.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi | 34 ++
1 file changed, 34 insertions(+)
diff --git
Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
The new driver uses the generic PHY framework and will interact
with DWC3 controller present on Exynos5 series of SoCs.
Thereby, removing old phy-samsung-usb3 driver and related code
used untill now which was based on usb/phy
On Mon, Apr 7, 2014 at 10:05 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Mon, Apr 07, 2014 at 02:36:13PM +0530, sundeep subbaraya wrote:
+/**
+ * xudc_wrstatus - Sets up the usb device status stages.
+ * @udc: pointer to the usb device controller structure.
+ */
+static void
Hi
On 04/07/2014 09:12 PM, Eric Gross wrote:
Hi all,
I am implementing a driver (currently libusb-based, but may change to
kernel-based eventually) for a USB standard class type that makes use of
endpoint stalling as a synchronization mechanism to recover after error
conditions between device
On Tue, Apr 08, 2014 at 07:59:28PM +0800, 刘磊 wrote:
dear linuxfoundation:
I'm not sure if you receive our mails in lase week , i resend it now.
Please confirm whether it is correct format for submit.
Looking forward to your reply.
modify reason:
1. Move device pid fffe from
On Tue, Apr 08, 2014 at 07:53:39AM +, Amund Hov wrote:
I completely understand your frustration, and it actually is relevant to
kernel development. :) Perhaps the attached patch would have at least
saved you some time and frustration in debugging the driver and host
issue?
Thanks
Thanks for your help, Mathias! See my comments inline below:
Mathias Nyman mathias.ny...@linux.intel.com wrote on 04/08/2014 10:26:43
AM:
The issue we currently have is that the xHCI (both driver and hw)
refuses to reset an endpoint if it's not halted.
SetFeature(ENDPOINT_HALT) will set the
Hi,
On Tue, Apr 08, 2014 at 09:31:29PM +0530, sundeep subbaraya wrote:
+static const struct usb_gadget_ops xusb_udc_ops = {
+ .get_frame = xudc_get_frame,
+ .wakeup = xudc_wakeup,
+ .udc_start = xudc_start,
+ .udc_stop = xudc_stop,
no pullup ??? What gives ?
On Tue, 8 Apr 2014, vichy wrote:
That's a different bit. USB_PORT_FEAT_C_RESET isn't the same as
USB_PORT_FEAT_RESET.
what I am curious is,
if port reset bit will clear to 0 within 2ms, why we still need to
clear_port_feature with USB_PORT_FEAT_C_RESET
(clear Port reset )
if
On Tue, 8 Apr 2014, Russel Hughes wrote:
Hi,
I put in a new kernel and get the response from uname -r of
3.14.0-031400-generic, apologies for the pedantry I am not that sure
what I am doing. The device behaves exactly the same as default Linux
kernel, buffer is erratic not stable like USB
On Sat, Apr 05, 2014 at 01:37:14PM +0800, Li Jun wrote:
This patch adds OTG fsm related initialization when do otg init,
add a seperate file for OTG fsm related utilities.
Signed-off-by: Li Jun b47...@freescale.com
---
drivers/usb/chipidea/Makefile |1 +
drivers/usb/chipidea/ci.h
On Sat, Apr 05, 2014 at 01:37:16PM +0800, Li Jun wrote:
Init otg_port number of otg capable host to be 1 at host start.
Signed-off-by: Li Jun b47...@freescale.com
---
drivers/usb/chipidea/host.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git
On Sat, Apr 05, 2014 at 01:37:13PM +0800, Li Jun wrote:
From: Li Jun b47...@freescale.com
This patchset adds USB OTG HNP and SRP support on chipidea usb driver,
existing OTG port role swtich function by ID pin status kept unchanged,
based on that, if select CONFIG_USB_OTG_FSM, OTG HNP and
On Tuesday, April 08, 2014 11:41 PM, Vivek Gautam wrote:
Patch : 14982e3 USB: OHCI: Properly handle ohci-exynos suspend
has already removed 'ohci_hcd' settings from exynos glue layer
as a part of streamlining the ohci controller's suspend.
So we don't need the locks for 'ohci_hcd' anymore.
Patch 'b8efdaf USB: EHCI: add check for wakeup/suspend race'
adds a check for possible race between suspend and wakeup interrupt,
and thereby it returns -EBUSY as error code if there's a wakeup
interrupt.
So the platform host controller should not proceed further with
its suspend callback, rather
Patch 'b8efdaf USB: EHCI: add check for wakeup/suspend race'
adds a check for possible race between suspend and wakeup interrupt,
and thereby it returns -EBUSY as error code if there's a wakeup
interrupt.
So the platform host controller should not proceed further with
its suspend callback, rather
On Wednesday, April 09, 2014 1:01 PM, Vivek Gautam wrote:
Patch 'b8efdaf USB: EHCI: add check for wakeup/suspend race'
adds a check for possible race between suspend and wakeup interrupt,
and thereby it returns -EBUSY as error code if there's a wakeup
interrupt.
So the platform host
37 matches
Mail list logo
