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 a
On 07.04.2014 18:04, Felipe Balbi wrote:
> that's not caused by my patch, it's a previously existing bug. This
> should sort it out:
>
> commit e7f69404a878b5345ad07bf06d78559ecd31db79
> Author: Felipe Balbi
> Date: Mon Apr 7 10:58:01 2014 -0500
>
> usb: musb: omap2430: make sure clock
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 b
> 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 erro
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
> >
AceLan Kao 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 sierra driver is corr
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
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: WingMan Kwok
---
drivers/usb/dwc3/Kconfig |4 +++-
1 file changed, 3 inserti
-- Forwarded message --
From: Russel Hughes
Date: 6 April 2014 11:32
Subject: Isochronos audio
To: linux-usb
>
> Can you describe the actual problem ? How can you trigger it ? What are
> you doing when the problem arises ? Do you hear audio glitches or does
> the device disconne
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
> > o
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 delaye
> (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
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 paramete
hi Alan:
2014-04-07 10:06 GMT+08:00 Alan Stern :
> 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. That's
[ +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 lea
[ +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 call
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_
> > > If I see this correctly, then ASYNCB_INITIALIZED is cleared in
> > > tty_port_close() we is called from acm_tty_close(). Thus it should
> > > be enough to make sure that the device is resumed at the beginning
> > > of acm_tty_close() and acm_resume() will do the job automatically.
> > > What
Hi,
On Tue, Apr 08, 2014 at 09:24:09AM +0200, Stefan Roese wrote:
> On 07.04.2014 18:04, Felipe Balbi wrote:
>
>
>
> > that's not caused by my patch, it's a previously existing bug. This
> > should sort it out:
> >
> > commit e7f69404a878b5345ad07bf06d78559ecd31db79
> > Author: Felipe Balbi
>
Based on 'next' branch of Kishon's phy tree (linux-phy).
Tested on 'usb-next' of Greg's usb tree.
Changes from V3:
1) Separated out the phy init sequences for utmi and pipe3 phys.
2) Changed the nomenclature across the phy to 'usbdrd-phy' to
indicate USB 3.0 DRD PHY controller; and thereby chan
Add device tree nodes for USB 3.0 PHY present alongwith
USB 3.0 controller Exynos 5420 SoC. This phy driver is
based on generic phy framework.
Signed-off-by: Vivek Gautam
---
arch/arm/boot/dts/exynos5420.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/bo
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
---
NOTE: This patch should
Add device tree node for new usbdrd-phy driver, which
is based on generic phy framework.
Signed-off-by: Vivek Gautam
---
arch/arm/boot/dts/exynos5250.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
inde
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
Cc: Manjunath Goudar
Cc: Alan Ster
Add device tree nodes for DWC3 controller present on
Exynos 5420 SoC, to enable support for USB 3.0.
Signed-off-by: Vivek Gautam
---
arch/arm/boot/dts/exynos5420.dtsi | 34 ++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/ar
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 framework
On Mon, Apr 7, 2014 at 10:05 PM, Felipe Balbi 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 a
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 for your help, Mathias! See my comments inline below:
Mathias Nyman 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 device to halted state, but
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,
> >> >
>
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 )
> >
> >>
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
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
> ---
> drivers/usb/chipidea/Makefile |1 +
> drivers/usb/chipidea/ci.h | 17 +
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
> ---
> drivers/usb/chipidea/host.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/chipidea/hos
On Sat, Apr 05, 2014 at 01:37:13PM +0800, Li Jun wrote:
> From: Li Jun
>
> 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 SRP will be
> supp
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' anymor
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 s
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 s
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 co
Hi Balbi,
Glad to see the OTG mode is prepare to support in your dwc3-role-switch
branch. But it is not fit for intel Merrfield/Moorfield platforms. :(
The reason is we implemented DRD mode instead of OTG mode. So the
GCTL.PortCapDir will be set as 01 for host mode, and 10 for device mode.
And t
41 matches
Mail list logo
