Re: [RFC PATCH 2/2] usb: phy: Add platform driver support for ULPI PHYs

On Thu, Sep 24, 2015 at 09:21:16AM +, Subbaraya Sundeep Bhatta wrote: > > > +uphy->flags); > > > + > > > + uphy->usb_phy->set_vbus = usbphy_set_vbus; > > > > When you will call it? > > I am calling it in host.c and otg_fsm.c of Chipidea driver wherever > regulator_enable/disable is called to

RE: [PATCH 1/3][v4] Documentation: dt: dwc3: Add snps,quirk-frame-length-adjustment property

Hi Felipe, Any comments on the below [v4] patches? [PATCH 1/3][v4] Documentation: dt: dwc3: Add snps,quirk-frame-length-adjustment property [PATCH 2/3][v4] drivers: usb: dwc3: Add frame length adjustment quirk [PATCH 3/3][v4] arm: dts: ls1021a: Add quirk for Erratum A009116 I will be taking

RE: [RFC PATCH 1/2] usb: doc: Add bindings for ULPI platform driver

Hi Peter, > -Original Message- > From: Peter Chen [mailto:peter.c...@freescale.com] > Sent: Thursday, September 24, 2015 2:41 PM > To: Subbaraya Sundeep Bhatta > Cc: ba...@ti.com; devicet...@vger.kernel.org; kis...@ti.com; > gre...@linuxfoundation.org; linux-usb@vger.kernel.org; linux- >

Re: [PATCH 1/3] avr32: fix build failure

On Wed, Sep 23, 2015 at 07:15:16PM +0200, Hans-Christian Egtvedt wrote: > Around Wed 23 Sep 2015 21:26:01 +0530 or thereabout, Sudip Mukherjee wrote: > > On Mon, Sep 21, 2015 at 01:31:44PM +0530, Sudip Mukherjee wrote: > >> On Mon, Sep 21, 2015 at 09:33:00AM +0200, Hans-Christian Egtvedt wrote: >

RE: [RFC PATCH 2/2] usb: phy: Add platform driver support for ULPI PHYs

Hi Peter, > -Original Message- > From: Peter Chen [mailto:peter.c...@freescale.com] > Sent: Thursday, September 24, 2015 2:37 PM > To: Subbaraya Sundeep Bhatta > Cc: ba...@ti.com; devicet...@vger.kernel.org; kis...@ti.com; > gre...@linuxfoundation.org; linux-usb@vger.kernel.org; linux- >

Re: [RFC PATCH 1/2] usb: doc: Add bindings for ULPI platform driver

On Wed, Sep 23, 2015 at 06:24:01PM +0530, Subbaraya Sundeep Bhatta wrote: > This patch adds binding doc info for generic ULPI PHYs > platform driver. > > Signed-off-by: Subbaraya Sundeep Bhatta > --- > .../devicetree/bindings/usb/ulpi-platform-phy.txt | 34 >

Re: [RFC PATCH 2/2] usb: phy: Add platform driver support for ULPI PHYs

On Wed, Sep 23, 2015 at 06:24:33PM +0530, Subbaraya Sundeep Bhatta wrote: > Based on board design USB controller needs explicit software > access to ULPI PHY for controlling VBUS. This patch adds platform > driver support for generic ULPI PHYs and provides a USB2 PHY device > to controllers. > >

Re: [RFC][PATCH] Add spurious wakeup quirk for Lynxpoint controllers

On 18.09.2015 23:25, Oliver Neukum wrote: On Fri, 2015-09-18 at 09:56 -0700, Laura Abbott wrote: Would you rather see a revert of the patch you gave rather than a new one re-introducing the flag? We need a big fat comment here saying that different tests should different results and the quirk

Re: [PATCH v4] usb: of: add an api to get dr_mode by the phy node

Hi, On 23-09-15 22:59, Bin Liu wrote: Hi, On 09/23/2015 02:53 PM, Hans de Goede wrote: Hi, On 23-09-15 19:10, Bin Liu wrote: Hi, On 09/22/2015 04:18 PM, Felipe Balbi wrote: On Tue, Sep 22, 2015 at 02:31:18PM -0500, Bin Liu wrote: Hi, On 09/22/2015 09:40 AM, Felipe Balbi wrote: On Mon,

Re: [PATCH v2 2/3] usb: gadget: f_midi: free usb request when done

Peter Chen wrote: > I can't make my aplaymidi to receive data > # aplaymidi > open /dev/snd/seq failed: No such file or directory modprobe snd-seq There are mechanisms to load it automatically, but your embedded system might not bother about any of them. Or CONFIG_SND_SEQUENCER isn't enabled

Re: Overly conservative xHCI bandwidth estimation

On 09/23/2015 10:08 PM, Steinar H. Gunderson wrote: Hi again, I'm trying to figure out why my xHCI controller refuses me to run two very similar video cards at the same time. I'm not sure if this is a bug or if I'm just misunderstanding, so let me see if I understand this right: The

Re: Overly conservative xHCI bandwidth estimation

On 09/24/2015 03:14 PM, Steinar H. Gunderson wrote: On Thu, Sep 24, 2015 at 03:09:55PM +0200, Krzysztof Opasiak wrote: But still the problem may exist. Is the 2.16 GBit bandwidth for 4th altset? No. The 2nd altset is 2.16, the 4th altset is 1.04. Unless my calculations are wrong. How do

Re: Overly conservative xHCI bandwidth estimation

On Thu, Sep 24, 2015 at 03:35:10PM +0200, Krzysztof Opasiak wrote: >> No. The 2nd altset is 2.16, the 4th altset is 1.04. Unless my calculations >> are wrong. > How do you do your calculations? Like I said in my initial email: >>> The interface of each card has two relevant alternates, 2 and 4.

Re: Overly conservative xHCI bandwidth estimation

On Thu, Sep 24, 2015 at 03:09:55PM +0200, Krzysztof Opasiak wrote: > But still the problem may exist. Is the 2.16 GBit bandwidth for 4th altset? No. The 2nd altset is 2.16, the 4th altset is 1.04. Unless my calculations are wrong. > Remember that according to USB spec not whole bandwidth can be

Re: [PATCH v4] usb: of: add an api to get dr_mode by the phy node

Hi Felipe, On 09/24/2015 03:37 AM, Hans de Goede wrote: Hi, On 23-09-15 22:59, Bin Liu wrote: Hi, On 09/23/2015 02:53 PM, Hans de Goede wrote: Hi, On 23-09-15 19:10, Bin Liu wrote: Hi, On 09/22/2015 04:18 PM, Felipe Balbi wrote: On Tue, Sep 22, 2015 at 02:31:18PM -0500, Bin Liu wrote:

Re: AM3517 usb host issue

On 22/05/15 14:50, Felipe Balbi wrote: > Hi, > > On Fri, May 22, 2015 at 11:04:33AM +0300, Ben Dooks wrote: >> I am trying to get the full-speed USB host working on an custom >> AM3517 device with the 3.18.12 kernel. The hardware works (a >> 2.6.37 kernel has been used for testing). >> >> Does

Re: Overly conservative xHCI bandwidth estimation

On Thu, Sep 24, 2015 at 02:09:41PM +0200, Krzysztof Opasiak wrote: > Let's start from the beginning. Your device use ISO endpoints which means > that host allocates specific amount of bandwidth on the bus. More over, > interfaces in your devices has many alternate settings. Probably each of > them

Re: Overly conservative xHCI bandwidth estimation

On 09/24/2015 02:50 PM, Steinar H. Gunderson wrote: On Thu, Sep 24, 2015 at 02:09:41PM +0200, Krzysztof Opasiak wrote: Let's start from the beginning. Your device use ISO endpoints which means that host allocates specific amount of bandwidth on the bus. More over, interfaces in your devices

Re: Overly conservative xHCI bandwidth estimation

On Thu, Sep 24, 2015 at 10:17:19AM -0400, Alan Stern wrote: > However, none of this answers the question of why you can use both > cards on a different machine but not on yours. It comes down to the > implementations of the xHCI controller chips. In USB-3, bandwidth > allocation is handled by

[PATCH 1/2] usb: gadget: f_sourcesink: fix function params handling

Move function parameters to struct f_sourcesink to make them per instance instead of having them as global variables. Since we can have multiple instances of USB function we also want to have separate set of parameters for each instance. Signed-off-by: Robert Baldyga ---

[PATCH 0/2] usb: gadget: fixes for f_sourcesink and f_loopback

Hi Felipe, There are two bugfix patches. The problem was that function parameters in f_sourcesink and f_loopback were stored in global variables, and in result setting parameters in one function instance caused overwriting them in all other instances. This patchset fixes this problem by replacing

[PATCH 2/2] usb: gadget: f_loopfack: fix function params handling

Move function parameters to struct f_loopback to make them per instance instead of having them as global variables. Since we can have multiple instances of USB function we also want to have separate set of parameters for each instance. Signed-off-by: Robert Baldyga ---

Re: Overly conservative xHCI bandwidth estimation

On Wed, 23 Sep 2015, Steinar H. Gunderson wrote: > Hi again, > > I'm trying to figure out why my xHCI controller refuses me to run two very > similar video cards at the same time. I'm not sure if this is a bug or if I'm > just misunderstanding, so let me see if I understand this right: > > The

Re: Overly conservative xHCI bandwidth estimation

On 09/24/2015 03:50 PM, Steinar H. Gunderson wrote: On Thu, Sep 24, 2015 at 03:35:10PM +0200, Krzysztof Opasiak wrote: No. The 2nd altset is 2.16, the 4th altset is 1.04. Unless my calculations are wrong. How do you do your calculations? Like I said in my initial email: The interface of

[PATCH v2] usb: gadget: f_sourcesink: fix function params handling

Move function parameters to struct f_sourcesink to make them per instance instead of having them as global variables. Since we can have multiple instances of USB function we also want to have separate set of parameters for each instance. Cc: # 3.10+ Signed-off-by: Robert

Re: [PATCH 2/2] usb: gadget: f_loopfack: fix function params handling

Hi Felipe, I see that Krzysztof Opasiak made the same change in patch https://lkml.org/lkml/2015/9/22/578, so please just ignore my patch. My first patch is still needed - I will resend it with CC: stable. Thanks, Robert Baldyga On 09/24/2015 05:02 PM, Robert Baldyga wrote: > Move function

Re: [PATCH v3 1/2] usb: gadget: loopback: fix: Don't share qlen and buflen between instances

On 09/22/2015 08:40 PM, Krzysztof Opasiak wrote: > Each instance of loopback function may have different qlen > and buflen attributes values. When linking function to > configuration those values had been assigned to global > variables. Linking other instance to config overwrites those > values. >

Re: Overly conservative xHCI bandwidth estimation

On Thu, 24 Sep 2015, Steinar H. Gunderson wrote: > On Thu, Sep 24, 2015 at 10:17:19AM -0400, Alan Stern wrote: > > However, none of this answers the question of why you can use both > > cards on a different machine but not on yours. It comes down to the > > implementations of the xHCI controller

Re: [PATCH 3/3] page-flags: rectify forward declaration

> > > > Also, I'm finding that the patch series introduces a pretty large > > bisection hole: > > > > include/linux/page-flags.h: In function 'PageYoung': > > include/linux/page-flags.h:327: error: implicit declaration of function > > 'PF_ANY' > > include/linux/page-flags.h:327: error: invalid

Re: [RFC PATCH 1/2] usb: doc: Add bindings for ULPI platform driver

On Wed, Sep 23, 2015 at 7:54 AM, Subbaraya Sundeep Bhatta wrote: > This patch adds binding doc info for generic ULPI PHYs > platform driver. > > Signed-off-by: Subbaraya Sundeep Bhatta > --- >

Re: [RFC PATCH 1/2] usb: doc: Add bindings for ULPI platform driver

On Thu, Sep 24, 2015 at 4:26 AM, Subbaraya Sundeep Bhatta wrote: > Hi Peter, > >> -Original Message- >> From: Peter Chen [mailto:peter.c...@freescale.com] >> Sent: Thursday, September 24, 2015 2:41 PM >> To: Subbaraya Sundeep Bhatta >> Cc:

Re: [PATCH v2] usb: gadget: f_sourcesink: fix function params handling

On 09/24/2015 06:49 PM, Felipe Balbi wrote: On Thu, Sep 24, 2015 at 05:23:09PM +0200, Robert Baldyga wrote: Move function parameters to struct f_sourcesink to make them per instance instead of having them as global variables. Since we can have multiple instances of USB function we also want

RE: [PATCH v3 0/1] USB DWC2 parity fix in isochronous mode

> -Original Message- > From: John Youn [mailto:john.y...@synopsys.com] > Sent: September-23-15 9:21 PM > To: Scott Branden; John Youn; Greg Kroah-Hartman; linux- > u...@vger.kernel.org; Roman Bacik > Cc: linux-ker...@vger.kernel.org; bcm-kernel-feedback-list > Subject: Re: [PATCH v3 0/1]

Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M

Hi Alan, > > Frankly, I don't dare to upgrade the BIOS right now. > > All right. Maybe at some point in the future. The thing is, I don't > want to patch the kernel only to find that the problem has already been > fixed in a newer BIOS. Fair enough. I'll see if I can make time for setting

[PATCH v4 0/5] Introduce usb charger framework to deal with the usb gadget power negotation

Currently the Linux kernel does not provide any standard integration of this feature that integrates the USB subsystem with the system power regulation provided by PMICs meaning that either vendors must add this in their kernels or USB gadget devices based on Linux (such as mobile phones) may not

[PATCH v4 5/5] power: wm831x_power: Support USB charger current limit management

Integrate with the newly added USB charger interface to limit the current we draw from the USB input based on the input device configuration identified by the USB stack, allowing us to charge more quickly from high current inputs without drawing more current than specified from others.

[PATCH v4 2/5] gadget: Introduce the usb charger framework

This patch introduces the usb charger driver based on usb gadget that makes an enhancement to a power driver. It works well in practice but that requires a system with suitable hardware. The basic conception of the usb charger is that, when one usb charger is added or removed by reporting from

[PATCH v4 1/5] gadget: Introduce the notifier functions

The usb charger framework is based on usb gadget. The usb charger need to be notified the state changing of usb gadget to confirm the usb charger state. Thus this patch adds a notifier mechanism for usb gadget to report a event to usb charger when the usb gadget state is changed. Signed-off-by:

[PATCH v4 3/5] gadget: Support for the usb charger framework

For supporting the usb charger, it adds the usb_charger_init() and usb_charger_exit() functions for usb charger initialization and exit. Introduce a callback 'get_charger_type' which will implemented by user for usb gadget operations to get the usb charger type. Signed-off-by: Baolin Wang

[PATCH v4 4/5] gadget: Integrate with the usb gadget supporting for usb charger

When the usb gadget supporting for usb charger is ready, the usb charger should get the type by the 'get_charger_type' callback which is implemented by the usb gadget operations, and get the usb charger pointer from struct 'usb_gadget'. Signed-off-by: Baolin Wang ---

Re: Overly conservative xHCI bandwidth estimation

On Thu, Sep 24, 2015 at 11:22:57AM -0400, Alan Stern wrote: >> I assume there's no way I can lie to the chip? Like, if I know for a fact >> that the card will send less data than the alternate claims (like, >> I'm using a video mode that will require only a few hundred megabits/second >> in

Re: Overly conservative xHCI bandwidth estimation

On Thu, Sep 24, 2015 at 02:33:06PM -0700, Paul Zimmerman wrote: > IIRC, at least some of the Intel controllers require the bandwidth > calculations to be done by the xHCI driver, instead of doing it > themselves in hardware. Perhaps you're tripping over a bug in the xHCI > driver? Mathias is

Re: Overly conservative xHCI bandwidth estimation

IIRC, at least some of the Intel controllers require the bandwidth calculations to be done by the xHCI driver, instead of doing it themselves in hardware. Perhaps you're tripping over a bug in the xHCI driver? Mathias is probably best the one to comment on this. -- Paul -- To unsubscribe from

Re: Overly conservative xHCI bandwidth estimation

Yep, that's the one. -- Paul On Thu, Sep 24, 2015 at 2:37 PM, Steinar H. Gunderson wrote: > On Thu, Sep 24, 2015 at 02:33:06PM -0700, Paul Zimmerman wrote: >> IIRC, at least some of the Intel controllers require the bandwidth >> calculations to be done by the xHCI

Re: Overly conservative xHCI bandwidth estimation

On Fri, Sep 25, 2015 at 12:42:22AM +0200, Steinar H. Gunderson wrote: > I downgraded to Debian's 3.16 kernel. Both cards came up without a hitch. > But I only seem to get frames back from the second one. ...and after a quick app fix, I have capture from both cards. Does this mean I have a long

Re: Overly conservative xHCI bandwidth estimation

On Thu, 24 Sep 2015, Steinar H. Gunderson wrote: > On Thu, Sep 24, 2015 at 11:22:57AM -0400, Alan Stern wrote: > >> I assume there's no way I can lie to the chip? Like, if I know for a fact > >> that the card will send less data than the alternate claims (like, > >> I'm using a video mode that

Re: Overly conservative xHCI bandwidth estimation

On Wed, Sep 23, 2015 at 10:08:05PM +0200, Steinar H. Gunderson wrote: > I've tried on another machine and it works fine there, so my code should, > at least on the surface of it, be fine. PLOT TWIST: I downgraded to Debian's 3.16 kernel. Both cards came up without a hitch. But I only seem to get

Re: Overly conservative xHCI bandwidth estimation

On Thu, Sep 24, 2015 at 04:46:22PM -0400, Alan Stern wrote: > It does. Grep for max_burst in drivers/usb/host/x*.c to see where it > gets used. (Note that in a couple of places involving USB-2 devices, > the code uses max_burst where it really means multiplicity.) OK, so this is very curious.

Re: [PATCH v2 00/32] usb: dwc2: various bug fixes

On 9/22/2015 6:15 AM, Mian Yousaf Kaukab wrote: > Hi, > This series consists of various bug fixes for both host and gadget > sides. All patches are verified on dwc2 v3.0a with dedicated fifos. > It would be good to get some Tested-bys for other platforms. > > It is based on testing/next branch in

Re: [PATCH v2] usb: gadget: f_sourcesink: fix function params handling

On Thu, Sep 24, 2015 at 05:23:09PM +0200, Robert Baldyga wrote: > Move function parameters to struct f_sourcesink to make them per instance > instead of having them as global variables. Since we can have multiple > instances of USB function we also want to have separate set of parameters > for

Re: [PATCH v3 1/2] usb: gadget: loopback: fix: Don't share qlen and buflen between instances

On Thu, Sep 24, 2015 at 05:19:12PM +0200, Robert Baldyga wrote: > On 09/22/2015 08:40 PM, Krzysztof Opasiak wrote: > > Each instance of loopback function may have different qlen > > and buflen attributes values. When linking function to > > configuration those values had been assigned to global >

Re: [PATCH v3 1/2] usb: gadget: loopback: fix: Don't share qlen and buflen between instances

On 09/24/2015 06:51 PM, Felipe Balbi wrote: On Thu, Sep 24, 2015 at 05:19:12PM +0200, Robert Baldyga wrote: On 09/22/2015 08:40 PM, Krzysztof Opasiak wrote: Each instance of loopback function may have different qlen and buflen attributes values. When linking function to configuration those

Re: PROBLEM: lsusb -v freezes kernel on Acer ES1-111M

Hello Andrew, > ES1-111M running BIOS v1.13 and have had no problems booting from an > external USB stick to install Debian (using legacy mode -- I haven't > tried UEFI). It also worked fine under v1.10 (factory-installed). Thanks, that's good to know. Btw, I'm also using legacy mode. Maybe I

Re: [PATCH 2/2] Doc: usb: ci-hdrc-usb2: Add phy-clkgate-delay-us entry

Hi Peter, On Tue, Sep 8, 2015 at 11:27 PM, Peter Chen wrote: > I will queue both for next rc, thanks. It would be nice if these patches could appear in linux-next soon. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to

Re: [PATCH v3 0/1] USB DWC2 parity fix in isochronous mode

On 9/24/2015 10:28 AM, Roman Bacik wrote: >> -Original Message- >> From: John Youn [mailto:john.y...@synopsys.com] >> Sent: September-23-15 9:21 PM >> To: Scott Branden; John Youn; Greg Kroah-Hartman; linux- >> u...@vger.kernel.org; Roman Bacik >> Cc: linux-ker...@vger.kernel.org;

Re: Problems with printk logs and my driver

On Thu, 24 Sep 2015, Jiri Kosina wrote: > On Wed, 23 Sep 2015, Alan Stern wrote: > > > Your mistake was thinking that the driver for your keyboard is usbkbd. > > It isn't. It's usbhid, as you can see in the "lsusb -t" output above. > > As Eric is absolutely not the first person ever who got