Re: [PATCH v7] usb:serial:pl2303: add GPIOs interface on PL2303
On Wed, Aug 13, 2014 at 08:17:50AM +0200, Hannes Petermaier wrote: > > > > > > Known issue: > > > If gpios are in use(export to userspace through sysfs interface, etc), > > > then call pl2303_release(unplug usb-serial convertor, modprobe -r, > etc), > > > will cause trouble, so we need to make sure there is no gpio user > before > > > call pl2303_release. > > > > This is a real problem that we need to address. gpiolib isn't really > > able to handle devices that just disappear. In fact, it's API claims > that > > we must not call gpiochip_remove with requested gpios and this is > > exactly what you might do in pl2303hx_gpio_release below. > > > > As I mentioned earlier, this crashes the kernel when a new gpiochip is > > later added (the gpiochip data structures are likely corrupted and we > > get a NULL pointer deref in gpiochip_find_base). > > > > Linus, any thoughts on this? > > Hi, > there are several USB to I2C bus adapters and I2C IO-Expanders, > how is this handled there ? The short answer is: it isn't. A few i2c-gpio-expander drivers have teardown callbacks that can be used from board files to release any gpios requested there, but this neither translates to device tree or is of any help when gpios have been exported to user space. Thanks, Johan -- 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 v7] usb:serial:pl2303: add GPIOs interface on PL2303
On Wed, Aug 13, 2014 at 09:05:09AM +0200, Johan Hovold wrote: > On Wed, Aug 13, 2014 at 08:17:50AM +0200, Hannes Petermaier wrote: > > > > > > > > Known issue: > > > > If gpios are in use(export to userspace through sysfs interface, etc), > > > > then call pl2303_release(unplug usb-serial convertor, modprobe -r, > > etc), > > > > will cause trouble, so we need to make sure there is no gpio user > > before > > > > call pl2303_release. > > > > > > This is a real problem that we need to address. gpiolib isn't really > > > able to handle devices that just disappear. In fact, it's API claims > > that > > > we must not call gpiochip_remove with requested gpios and this is > > > exactly what you might do in pl2303hx_gpio_release below. > > > > > > As I mentioned earlier, this crashes the kernel when a new gpiochip is > > > later added (the gpiochip data structures are likely corrupted and we > > > get a NULL pointer deref in gpiochip_find_base). > > > > > > Linus, any thoughts on this? > > > > Hi, > > there are several USB to I2C bus adapters and I2C IO-Expanders, > > how is this handled there ? > > The short answer is: it isn't. > > A few i2c-gpio-expander drivers have teardown callbacks that can be used > from board files to release any gpios requested there, but this neither > translates to device tree or is of any help when gpios have been > exported to user space. For some reason I thought I saw some patches recently that was trying to resolve this problem. So it might get fixed for 3.18... 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: usbserial_generic
On Tue, Aug 12, 2014 at 09:53:41AM -0600, Kirk Madsen wrote: > After a great deal of searching, I discovered that instead of doing a > simple "/sbin/modprobe usbserial vendor=0x09d7 product=0x0100", with > fedora 20 you now have to edit your grub2 config to add a generic > serial device. Dmesg reported the following, so I am following > directions. Please add this device to a proper driver. > > [ 1.391259] usb 1-1.1: new full-speed USB device number 3 using ehci-pci > [ 1.478121] usb 1-1.1: New USB device found, idVendor=09d7, idProduct=0100 > [ 1.478127] usb 1-1.1: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [ 1.478130] usb 1-1.1: Product: Novatel GPS Receiver > [ 1.478133] usb 1-1.1: Manufacturer: Novatel Inc. > [ 1.478135] usb 1-1.1: SerialNumber: BFN14190250 > [ 1.479205] usbserial_generic 1-1.1:1.0: The "generic" usb-serial driver > is only for testing and one-off prototypes. > [ 1.479209] usbserial_generic 1-1.1:1.0: Tell linux-usb@vger.kernel.org to > add your device to a proper driver. > [ 1.479212] usbserial_generic 1-1.1:1.0: generic converter detected > [ 1.479345] usb 1-1.1: generic converter now attached to ttyUSB0 > [ 1.479420] usb 1-1.1: generic converter now attached to ttyUSB1 > [ 1.479448] usb 1-1.1: generic converter now attached to ttyUSB2 Thanks for reporting back. What is the full "lsusb -v" output for this device? Could you test a patch for Novatel GPS support if I send you one? Note that you can also add a VID/PID using sysfs, e.g.: echo 09d7 0100 >/sys/bus/usb-serial/drivers/generic/new_id Thanks, Johan -- 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 v4] usb: gadget: at91_udc: move prepare clk into process context
On Fri, 8 Aug 2014 11:42:42 +0200
Ronald Wahl wrote:
> Commit 7628083227b6bc4a7e33d7c381d7a4e558424b6b (usb: gadget: at91_udc:
> prepare clk before calling enable) added clock preparation in interrupt
> context. This is not allowed as it might sleep. Also setting the clock
> rate is unsafe to call from there for the same reason. Move clock
> preparation and setting clock rate into process context (at91udc_probe).
>
> Signed-off-by: Ronald Wahl
Acked-by: Boris Brezillon
> ---
> v3 -> v4:
> - no code changes
> - update commit message
> - add changelog
>
> v2 -> v3: (NOTE: this patch was also send with the v2 tag)
> - moved setting the clock rate into process context as well as it may
> also sleep
> - update commit message
>
> v1 -> v2:
> - no changes (first v2 got out accidently)
>
> drivers/usb/gadget/udc/at91_udc.c | 44
> ---
> 1 file changed, 32 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc/at91_udc.c
> b/drivers/usb/gadget/udc/at91_udc.c
> index cfd18bc..0d685d0 100644
> --- a/drivers/usb/gadget/udc/at91_udc.c
> +++ b/drivers/usb/gadget/udc/at91_udc.c
> @@ -870,12 +870,10 @@ static void clk_on(struct at91_udc *udc)
> return;
> udc->clocked = 1;
>
> - if (IS_ENABLED(CONFIG_COMMON_CLK)) {
> - clk_set_rate(udc->uclk, 4800);
> - clk_prepare_enable(udc->uclk);
> - }
> - clk_prepare_enable(udc->iclk);
> - clk_prepare_enable(udc->fclk);
> + if (IS_ENABLED(CONFIG_COMMON_CLK))
> + clk_enable(udc->uclk);
> + clk_enable(udc->iclk);
> + clk_enable(udc->fclk);
> }
>
> static void clk_off(struct at91_udc *udc)
> @@ -884,10 +882,10 @@ static void clk_off(struct at91_udc *udc)
> return;
> udc->clocked = 0;
> udc->gadget.speed = USB_SPEED_UNKNOWN;
> - clk_disable_unprepare(udc->fclk);
> - clk_disable_unprepare(udc->iclk);
> + clk_disable(udc->fclk);
> + clk_disable(udc->iclk);
> if (IS_ENABLED(CONFIG_COMMON_CLK))
> - clk_disable_unprepare(udc->uclk);
> + clk_disable(udc->uclk);
> }
>
> /*
> @@ -1780,14 +1778,24 @@ static int at91udc_probe(struct platform_device *pdev)
> }
>
> /* don't do anything until we have both gadget driver and VBUS */
> + if (IS_ENABLED(CONFIG_COMMON_CLK)) {
> + clk_set_rate(udc->uclk, 4800);
> + retval = clk_prepare(udc->uclk);
> + if (retval)
> + goto fail1;
> + }
> + retval = clk_prepare(udc->fclk);
> + if (retval)
> + goto fail1a;
> +
> retval = clk_prepare_enable(udc->iclk);
> if (retval)
> - goto fail1;
> + goto fail1b;
> at91_udp_write(udc, AT91_UDP_TXVC, AT91_UDP_TXVC_TXVDIS);
> at91_udp_write(udc, AT91_UDP_IDR, 0x);
> /* Clear all pending interrupts - UDP may be used by bootloader. */
> at91_udp_write(udc, AT91_UDP_ICR, 0x);
> - clk_disable_unprepare(udc->iclk);
> + clk_disable(udc->iclk);
>
> /* request UDC and maybe VBUS irqs */
> udc->udp_irq = platform_get_irq(pdev, 0);
> @@ -1795,7 +1803,7 @@ static int at91udc_probe(struct platform_device *pdev)
> 0, driver_name, udc);
> if (retval < 0) {
> DBG("request irq %d failed\n", udc->udp_irq);
> - goto fail1;
> + goto fail1c;
> }
> if (gpio_is_valid(udc->board.vbus_pin)) {
> retval = gpio_request(udc->board.vbus_pin, "udc_vbus");
> @@ -1848,6 +1856,13 @@ fail3:
> gpio_free(udc->board.vbus_pin);
> fail2:
> free_irq(udc->udp_irq, udc);
> +fail1c:
> + clk_unprepare(udc->iclk);
> +fail1b:
> + clk_unprepare(udc->fclk);
> +fail1a:
> + if (IS_ENABLED(CONFIG_COMMON_CLK))
> + clk_unprepare(udc->uclk);
> fail1:
> if (IS_ENABLED(CONFIG_COMMON_CLK) && !IS_ERR(udc->uclk))
> clk_put(udc->uclk);
> @@ -1896,6 +1911,11 @@ static int __exit at91udc_remove(struct
> platform_device *pdev)
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> release_mem_region(res->start, resource_size(res));
>
> + if (IS_ENABLED(CONFIG_COMMON_CLK))
> + clk_unprepare(udc->uclk);
> + clk_unprepare(udc->fclk);
> + clk_unprepare(udc->iclk);
> +
> clk_put(udc->iclk);
> clk_put(udc->fclk);
> if (IS_ENABLED(CONFIG_COMMON_CLK))
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] Revert "usb: chipidea: udc: .pullup is valid only when vbus is there"
On Wed, Aug 13, 2014 at 01:26:07AM +, Peter Chen wrote:
>
> > On Mon, Aug 11, 2014 at 02:34:33PM +0200, Michael Grzeschik wrote:
> > > Hi Peter,
> > >
> > > On Mon, Aug 11, 2014 at 12:56:47AM +, Peter Chen wrote:
> > > > > I have seen this call is still returning EOPNOTSUPP which is also
> > > > > returned by usb_gadget_connect and usb_gadget_disconnect if the
> > > > > pullup function is not available. Should it not handle that case
> > somehow special?
> > > > >
> > > > >
> > > > > Is it still a valid condition to bailout if vbus is not active?
> > > > >
> > > >
> > > > Hi Michael,
> > > >
> > > > I did this for possible pullup dp without connection (eg load gadget
> > > > driver before vbus connect), it breaks USB spec, see 7.1.7.3 Connect
> > and Disconnect Signaling at USB 2.0 spec.
> > > >
> > > > I don't know what exactly problem you met, but current pullup dp
> > > > during loading gadget driver behavior is not suitable for webcam and
> > > > android use case even vbus is there.
> > >
> > > I still work with the uvc gadget. The code in gadget/f_uvc.c calls
> > > usb_function_deactivate. The code of uvc_function_bind will bail out
> > > in the error code path, when the usb cable is not plugged (vbus not
> > > valid) in that situation.
> >
> > I see the problem, doesn't there have problem with usb cable connected?
> > I don't see any places can avoid pull up dp at udc-core during loading
> > gadget driver.
> >
> > >
> > > When the spec defines that calling pullup is only allowed on valid
> > > vbus, we should somehow tell something different then EOPNOTSUPP so
> > > the caller and that can bail out differently.
> > >
> >
> > I will have a look for this problem
> >
>
> Does below patch can satisfy your requirement?
Yes.
> diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> index b8125aa..cad0808 100644
> --- a/drivers/usb/chipidea/udc.c
> +++ b/drivers/usb/chipidea/udc.c
> @@ -1531,8 +1531,9 @@ static int ci_udc_pullup(struct usb_gadget *_gadget,
> int is_on)
> {
> struct ci_hdrc *ci = container_of(_gadget, struct ci_hdrc, gadget);
>
> - if (!ci->vbus_active)
> - return -EOPNOTSUPP;
> + if (!ci->vbus_active && is_on)
> + /* See USB 2.0 Spec 7.2.1 and 7.1.5.1 */
> + return -EPERM;
>
> But long term, we should avoid it from udc-core and composite driver, since
> pullup dp when
> the vbus is not there breaks usb spec.
>
> http://marc.info/?l=linux-usb&m=140785265013418&w=2
This will probably better handled in the api not in every
single udc driver itself. So until we have a proper solution
we can keep the above patch.
Thanks,
Michael
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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 v4] usb: gadget: at91_udc: move prepare clk into process context
On 08/08/2014 11:42, Ronald Wahl :
> Commit 7628083227b6bc4a7e33d7c381d7a4e558424b6b (usb: gadget: at91_udc:
> prepare clk before calling enable) added clock preparation in interrupt
> context. This is not allowed as it might sleep. Also setting the clock
> rate is unsafe to call from there for the same reason. Move clock
> preparation and setting clock rate into process context (at91udc_probe).
>
> Signed-off-by: Ronald Wahl
Acked-by: Nicolas Ferre
> ---
> v3 -> v4:
> - no code changes
> - update commit message
> - add changelog
>
> v2 -> v3: (NOTE: this patch was also send with the v2 tag)
> - moved setting the clock rate into process context as well as it may
> also sleep
> - update commit message
>
> v1 -> v2:
> - no changes (first v2 got out accidently)
>
> drivers/usb/gadget/udc/at91_udc.c | 44
> ---
> 1 file changed, 32 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc/at91_udc.c
> b/drivers/usb/gadget/udc/at91_udc.c
> index cfd18bc..0d685d0 100644
> --- a/drivers/usb/gadget/udc/at91_udc.c
> +++ b/drivers/usb/gadget/udc/at91_udc.c
> @@ -870,12 +870,10 @@ static void clk_on(struct at91_udc *udc)
> return;
> udc->clocked = 1;
>
> - if (IS_ENABLED(CONFIG_COMMON_CLK)) {
> - clk_set_rate(udc->uclk, 4800);
> - clk_prepare_enable(udc->uclk);
> - }
> - clk_prepare_enable(udc->iclk);
> - clk_prepare_enable(udc->fclk);
> + if (IS_ENABLED(CONFIG_COMMON_CLK))
> + clk_enable(udc->uclk);
> + clk_enable(udc->iclk);
> + clk_enable(udc->fclk);
> }
>
> static void clk_off(struct at91_udc *udc)
> @@ -884,10 +882,10 @@ static void clk_off(struct at91_udc *udc)
> return;
> udc->clocked = 0;
> udc->gadget.speed = USB_SPEED_UNKNOWN;
> - clk_disable_unprepare(udc->fclk);
> - clk_disable_unprepare(udc->iclk);
> + clk_disable(udc->fclk);
> + clk_disable(udc->iclk);
> if (IS_ENABLED(CONFIG_COMMON_CLK))
> - clk_disable_unprepare(udc->uclk);
> + clk_disable(udc->uclk);
> }
>
> /*
> @@ -1780,14 +1778,24 @@ static int at91udc_probe(struct platform_device *pdev)
> }
>
> /* don't do anything until we have both gadget driver and VBUS */
> + if (IS_ENABLED(CONFIG_COMMON_CLK)) {
> + clk_set_rate(udc->uclk, 4800);
> + retval = clk_prepare(udc->uclk);
> + if (retval)
> + goto fail1;
> + }
> + retval = clk_prepare(udc->fclk);
> + if (retval)
> + goto fail1a;
> +
> retval = clk_prepare_enable(udc->iclk);
> if (retval)
> - goto fail1;
> + goto fail1b;
> at91_udp_write(udc, AT91_UDP_TXVC, AT91_UDP_TXVC_TXVDIS);
> at91_udp_write(udc, AT91_UDP_IDR, 0x);
> /* Clear all pending interrupts - UDP may be used by bootloader. */
> at91_udp_write(udc, AT91_UDP_ICR, 0x);
> - clk_disable_unprepare(udc->iclk);
> + clk_disable(udc->iclk);
>
> /* request UDC and maybe VBUS irqs */
> udc->udp_irq = platform_get_irq(pdev, 0);
> @@ -1795,7 +1803,7 @@ static int at91udc_probe(struct platform_device *pdev)
> 0, driver_name, udc);
> if (retval < 0) {
> DBG("request irq %d failed\n", udc->udp_irq);
> - goto fail1;
> + goto fail1c;
> }
> if (gpio_is_valid(udc->board.vbus_pin)) {
> retval = gpio_request(udc->board.vbus_pin, "udc_vbus");
> @@ -1848,6 +1856,13 @@ fail3:
> gpio_free(udc->board.vbus_pin);
> fail2:
> free_irq(udc->udp_irq, udc);
> +fail1c:
> + clk_unprepare(udc->iclk);
> +fail1b:
> + clk_unprepare(udc->fclk);
> +fail1a:
> + if (IS_ENABLED(CONFIG_COMMON_CLK))
> + clk_unprepare(udc->uclk);
> fail1:
> if (IS_ENABLED(CONFIG_COMMON_CLK) && !IS_ERR(udc->uclk))
> clk_put(udc->uclk);
> @@ -1896,6 +1911,11 @@ static int __exit at91udc_remove(struct
> platform_device *pdev)
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> release_mem_region(res->start, resource_size(res));
>
> + if (IS_ENABLED(CONFIG_COMMON_CLK))
> + clk_unprepare(udc->uclk);
> + clk_unprepare(udc->fclk);
> + clk_unprepare(udc->iclk);
> +
> clk_put(udc->iclk);
> clk_put(udc->fclk);
> if (IS_ENABLED(CONFIG_COMMON_CLK))
>
--
Nicolas Ferre
--
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] pl2303: use divisors for unsupported baud rates
On Wed, Aug 13, 2014 at 07:51:52AM +0300, Lauri Hintsala wrote: Please describe your change also in the message body. > This change has been tested to work with PL-2303HX at 115200, 50, > 100, 200, 250, 300 and 400 baud rates. 115200 and 3Mbaud can be set directly and are thus handled in the same way also after this change. > Signed-off-by: Lauri Hintsala > --- > CC: Johan Hovold > CC: Greg Kroah-Hartman > CC: linux-usb@vger.kernel.org > > drivers/usb/serial/pl2303.c | 10 -- > 1 file changed, 4 insertions(+), 6 deletions(-) > > diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c > index b3d5a35..51f2420 100644 > --- a/drivers/usb/serial/pl2303.c > +++ b/drivers/usb/serial/pl2303.c > @@ -394,16 +394,14 @@ static void pl2303_encode_baud_rate(struct tty_struct > *tty, > if (spriv->type->max_baud_rate) > baud = min_t(speed_t, baud, spriv->type->max_baud_rate); > /* > - * Set baud rate to nearest supported value. > - * > - * NOTE: Baud rate 500k can only be set using divisors. > + * Use direct method for supported baud rates, otherwise use divisors. >*/ > baud_sup = pl2303_get_supported_baud_rate(baud); > > - if (baud == 50) > - baud = pl2303_encode_baud_rate_divisor(buf, baud); > + if (baud == baud_sup) > + baud = pl2303_encode_baud_rate_direct(buf, baud); > else > - baud = pl2303_encode_baud_rate_direct(buf, baud_sup); > + baud = pl2303_encode_baud_rate_divisor(buf, baud); The reason this hasn't been done already is partly that there are a bunch of devices out there that apparently cannot handle the divisor encoding. There were also some concerns raised about the accuracy of the current divisor calculations. Did you measure the resulting baud rates? We'd want to restrict the divisor encoding to chip types that support it (500 kbaud is only there for legacy reasons). Frank Schäfer did a great job at sorting out the details and there's some info in the git logs in some patches from him (that were prematurely merged and later reverted). Thanks, Johan -- 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] pl2303: use divisors for unsupported baud rates
On 08/13/2014 01:01 PM, Johan Hovold wrote: On Wed, Aug 13, 2014 at 07:51:52AM +0300, Lauri Hintsala wrote: Please describe your change also in the message body. OK This change has been tested to work with PL-2303HX at 115200, 50, 100, 200, 250, 300 and 400 baud rates. 115200 and 3Mbaud can be set directly and are thus handled in the same way also after this change. That's true. I tested them to make sure I didn't break anything. The reason this hasn't been done already is partly that there are a bunch of devices out there that apparently cannot handle the divisor encoding. Do we have that information for driver? Can be enable divisors only for devices which support them? There were also some concerns raised about the accuracy of the current divisor calculations. Did you measure the resulting baud rates? I didn't measure the accuracy. I just tested it by sending and receiving data to/from ST's ARM Cortex-M0 based CPU at high baud rates. I didn't notice any problems in data. Windows driver is accepting "unsupported" baud rates, at least 1, 2 and 4 Mbauds. We'd want to restrict the divisor encoding to chip types that support it (500 kbaud is only there for legacy reasons). Frank Schäfer did a great job at sorting out the details and there's some info in the git logs in some patches from him (that were prematurely merged and later reverted). Current driver behaviour is the worst it could be. Currently it rounds the baud rate to the nearest one and doesn't inform the user about that. I just spent hours for debugging my embedded platform before I noticed that the problem was in the PL2303 driver. I guess someone else may also run into that problem as well in some day... Do we have any chance to fix it somehow? Best regards, Lauri Hintsala -- 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] pl2303: use divisors for unsupported baud rates
On Wed, Aug 13, 2014 at 01:21:28PM +0300, Lauri Hintsala wrote: > On 08/13/2014 01:01 PM, Johan Hovold wrote: > > On Wed, Aug 13, 2014 at 07:51:52AM +0300, Lauri Hintsala wrote: > > The reason this hasn't been done already is partly that there are a > > bunch of devices out there that apparently cannot handle the divisor > > encoding. > > Do we have that information for driver? Can be enable divisors only for > devices which support them? Yes, we could add a new quirk for any device types that do not support divisor encoding. > > There were also some concerns raised about the accuracy of the current > > divisor calculations. Did you measure the resulting baud rates? > > I didn't measure the accuracy. I just tested it by sending and receiving > data to/from ST's ARM Cortex-M0 based CPU at high baud rates. I didn't > notice any problems in data. > > Windows driver is accepting "unsupported" baud rates, at least 1, 2 and > 4 Mbauds. > > > We'd want to restrict the divisor encoding to chip types that support > > it (500 kbaud is only there for legacy reasons). Frank Schäfer did a > > great job at sorting out the details and there's some info in the git > > logs in some patches from him (that were prematurely merged and later > > reverted). > > Current driver behaviour is the worst it could be. Currently it rounds > the baud rate to the nearest one and doesn't inform the user about that. You can always read back the resulting baud rate. > I just spent hours for debugging my embedded platform before I noticed > that the problem was in the PL2303 driver. I guess someone else may also > run into that problem as well in some day... > > Do we have any chance to fix it somehow? But agreed, with all (or most of) the infrastructure in place, we should probably just enable it. Could you just add a max-baud rate of 12Mbaud for TYPE_HX to you patch? If anyone complains we can add a no-divisor quirk (and possibly type detection) for those devices later. Thanks, Johan -- 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
Transient USB disconnects
We are seeing some transient USB disconnects, these cause serious grief if we use the xhci driver, so the ports are all forced to use ehci (bios config). Even with ehci they are slightly problematic, partially resolved by using a 'bond' interface to stop the ethernet interface and address disappearing. The hardware is a custom board containing an smsc95xx hub+ethernet. The kernel trace just shows (at about 4am): [39203.215205] hid-generic 0003:03F0:034A.0004: can't reset device, :00:1d.0-1.5.4/input1, status -71 [39203.223659] usb 2-1.5: clear tt 4 (0070) error -71 [39203.232065] hid-generic 0003:03F0:034A.0003: can't reset device, :00:1d.0-1.5.4/input0, status -71 [39203.236024] usb 2-1.5: clear tt 4 (0070) error -71 [39203.241057] hid-generic 0003:03F0:034A.0004: can't reset device, :00:1d.0-1.5.4/input1, status -71 [39203.244019] usb 2-1.5: clear tt 4 (0070) error -71 [39203.254161] hid-generic 0003:03F0:034A.0003: can't reset device, :00:1d.0-1.5.4/input0, status -71 [39203.258132] usb 2-1.5: clear tt 4 (0070) error -71 [39203.263274] hid-generic 0003:03F0:034A.0004: can't reset device, :00:1d.0-1.5.4/input1, status -71 [39203.266120] usb 2-1.5: clear tt 4 (0070) error -71 [39203.276519] hid-generic 0003:03F0:034A.0003: can't reset device, :00:1d.0-1.5.4/input0, status -71 [39203.280479] usb 2-1.5: clear tt 4 (0070) error -71 [39203.286082] hid-generic 0003:03F0:034A.0004: can't reset device, :00:1d.0-1.5.4/input1, status -71 [39203.288342] usb 2-1.5: USB disconnect, device number 3 [39203.288347] usb 2-1.5.1: USB disconnect, device number 4 [39203.290948] usb 2-1.5: clear tt 4 (0070) error -71 [39203.293313] smsc95xx 2-1.5.1:1.0 eth1: unregister 'smsc95xx' usb-:00:1d.0-1.5.1, smsc95xx USB 2.0 Ethernet [39203.29] smsc95xx 2-1.5.1:1.0 eth1: hardware isn't capable of remote wakeup [39203.322991] usb 2-1.5.2: USB disconnect, device number 5 [39203.323794] usb 2-1.5.3: USB disconnect, device number 6 [39203.367370] usb 2-1.5.4: USB disconnect, device number 7 The device(s) then reattach... [39203.698501] usb 2-1.5: new high-speed USB device number 8 using ehci-pci [39203.790708] usb 2-1.5: New USB device found, idVendor=0424, idProduct=9514 [39203.790718] usb 2-1.5: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [39203.791226] hub 2-1.5:1.0: USB hub found [39203.791387] hub 2-1.5:1.0: 5 ports detected I don't really know what happens first. 'input0' and 'input1' are both the USB keyboard. It would be nice to know why the reset was requested, and why the disconnects were done. Is the recovery from the failed resets forcing the disconnects - or is that just a symptom of the same underlying error? Trouble is this happens about once a day, and we haven't found anything that really changes the frequency. It doesn't seem to be affected by real USB data (saturating the ethernet interface makes little difference). It might be that there are actually a lot of silent retries going on, but I don't really know where to look to find out. We currently have cut the 5v line on the USB interface - just in case it was carrying noise. Any ideas? David -- 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 v2] pl2303: use divisors for unsupported baud rates
Please ignore this patch. There was a typo. I sent it too early before
testing it. My mistake. Sorry.
Lauri
On 08/13/2014 02:46 PM, Lauri Hintsala wrote:
Use direct method for supported baud rates, otherwise use divisors.
Limit baud rate to 12 Mbaud with HX type.
This change has been tested to work with PL-2303HX at 115200, 50,
100, 200, 250, 300 and 400 baud rates.
Signed-off-by: Lauri Hintsala
---
CC: Johan Hovold
CC: Greg Kroah-Hartman
CC: Frank Schäfer
CC: linux-usb@vger.kernel.org
Changes since V1:
* added baud rate limit for HX
drivers/usb/serial/pl2303.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index b3d5a35..e84151a 100644
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -161,6 +161,9 @@ static const struct pl2303_type_data
pl2303_type_data[TYPE_COUNT] = {
.max_baud_rate =1228800,
.quirks = PL2303_QUIRK_LEGACY,
},
+ [HX] = {
+ .max_baud_rate =1200,
+ },
};
static int pl2303_vendor_read(struct usb_serial *serial, u16 value,
@@ -394,16 +397,14 @@ static void pl2303_encode_baud_rate(struct tty_struct
*tty,
if (spriv->type->max_baud_rate)
baud = min_t(speed_t, baud, spriv->type->max_baud_rate);
/*
-* Set baud rate to nearest supported value.
-*
-* NOTE: Baud rate 500k can only be set using divisors.
+* Use direct method for supported baud rates, otherwise use divisors.
*/
baud_sup = pl2303_get_supported_baud_rate(baud);
- if (baud == 50)
- baud = pl2303_encode_baud_rate_divisor(buf, baud);
+ if (baud == baud_sup)
+ baud = pl2303_encode_baud_rate_direct(buf, baud);
else
- baud = pl2303_encode_baud_rate_direct(buf, baud_sup);
+ baud = pl2303_encode_baud_rate_divisor(buf, baud);
/* Save resulting baud rate */
tty_encode_baud_rate(tty, baud, baud);
--
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 v2] pl2303: use divisors for unsupported baud rates
Use direct method for supported baud rates, otherwise use divisors.
Limit baud rate to 12 Mbaud with HX type.
This change has been tested to work with PL-2303HX at 115200, 50,
100, 200, 250, 300 and 400 baud rates.
Signed-off-by: Lauri Hintsala
---
CC: Johan Hovold
CC: Greg Kroah-Hartman
CC: Frank Schäfer
CC: linux-usb@vger.kernel.org
Changes since V1:
* added baud rate limit for HX
drivers/usb/serial/pl2303.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index b3d5a35..e84151a 100644
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -161,6 +161,9 @@ static const struct pl2303_type_data
pl2303_type_data[TYPE_COUNT] = {
.max_baud_rate =1228800,
.quirks = PL2303_QUIRK_LEGACY,
},
+ [HX] = {
+ .max_baud_rate =1200,
+ },
};
static int pl2303_vendor_read(struct usb_serial *serial, u16 value,
@@ -394,16 +397,14 @@ static void pl2303_encode_baud_rate(struct tty_struct
*tty,
if (spriv->type->max_baud_rate)
baud = min_t(speed_t, baud, spriv->type->max_baud_rate);
/*
-* Set baud rate to nearest supported value.
-*
-* NOTE: Baud rate 500k can only be set using divisors.
+* Use direct method for supported baud rates, otherwise use divisors.
*/
baud_sup = pl2303_get_supported_baud_rate(baud);
- if (baud == 50)
- baud = pl2303_encode_baud_rate_divisor(buf, baud);
+ if (baud == baud_sup)
+ baud = pl2303_encode_baud_rate_direct(buf, baud);
else
- baud = pl2303_encode_baud_rate_direct(buf, baud_sup);
+ baud = pl2303_encode_baud_rate_divisor(buf, baud);
/* Save resulting baud rate */
tty_encode_baud_rate(tty, baud, baud);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: xhci: amd chipset also needs short TX quirk
On 08/12/2014 05:13 PM, Huang Rui wrote:
> AMD xHC also needs short tx quirk after tested on most of chipset
> generations. That's because there is the same incorrect behavior like
> Fresco Logic host. Please see below message with on USB webcam
> attached on xHC host:
>
> [ 139.262944] xhci_hcd :00:10.0: WARN Successful completion on short TX:
> needs XHCI_TRUST_TX_LENGTH quirk?
> [ 139.266934] xhci_hcd :00:10.0: WARN Successful completion on short TX:
> needs XHCI_TRUST_TX_LENGTH quirk?
> [ 139.270913] xhci_hcd :00:10.0: WARN Successful completion on short TX:
> needs XHCI_TRUST_TX_LENGTH quirk?
> [ 139.274937] xhci_hcd :00:10.0: WARN Successful completion on short TX:
> needs XHCI_TRUST_TX_LENGTH quirk?
> [ 139.278914] xhci_hcd :00:10.0: WARN Successful completion on short TX:
> needs XHCI_TRUST_TX_LENGTH quirk?
> [ 139.282936] xhci_hcd :00:10.0: WARN Successful completion on short TX:
> needs XHCI_TRUST_TX_LENGTH quirk?
> [ 139.286915] xhci_hcd :00:10.0: WARN Successful completion on short TX:
> needs XHCI_TRUST_TX_LENGTH quirk?
> [ 139.290938] xhci_hcd :00:10.0: WARN Successful completion on short TX:
> needs XHCI_TRUST_TX_LENGTH quirk?
> [ 139.294913] xhci_hcd :00:10.0: WARN Successful completion on short TX:
> needs XHCI_TRUST_TX_LENGTH quirk?
> [ 139.298917] xhci_hcd :00:10.0: WARN Successful completion on short TX:
> needs XHCI_TRUST_TX_LENGTH quirk?
>
> Reported-by: Arindam Nath
> Tested-by: Shriraj-Rai P
> Cc:
> Signed-off-by: Huang Rui
> ---
> drivers/usb/host/xhci-pci.c |4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index e20520f..399a222 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -101,6 +101,10 @@ static void xhci_pci_quirks(struct device *dev, struct
> xhci_hcd *xhci)
> /* AMD PLL quirk */
> if (pdev->vendor == PCI_VENDOR_ID_AMD && usb_amd_find_chipset_info())
> xhci->quirks |= XHCI_AMD_PLL_FIX;
> +
> + if (pdev->vendor == PCI_VENDOR_ID_AMD)
> + xhci->quirks |= XHCI_TRUST_TX_LENGTH;
> +
> if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
> xhci->quirks |= XHCI_LPM_SUPPORT;
> xhci->quirks |= XHCI_INTEL_HOST;
>
Thanks, I got a report that the AMD FCH hosts needed this quirk earlier, and
have a patch pending for those.
I'll use this instead
-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
[PATCH v3] pl2303: use divisors for unsupported baud rates
Use direct method for supported baud rates, otherwise use divisors.
Limit baud rate to 12 Mbaud with HX type.
This change has been tested to work with PL-2303HX at 115200, 50,
100, 200, 250, 300 and 400 baud rates.
Signed-off-by: Lauri Hintsala
---
CC: Johan Hovold
CC: Greg Kroah-Hartman
CC: Frank Schäfer
CC: linux-usb@vger.kernel.org
Changes since V2:
* fixed typo in type name
Changes since V1:
* added baud rate limit for HX
drivers/usb/serial/pl2303.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index b3d5a35..0a9a3b3 100644
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -161,6 +161,9 @@ static const struct pl2303_type_data
pl2303_type_data[TYPE_COUNT] = {
.max_baud_rate =1228800,
.quirks = PL2303_QUIRK_LEGACY,
},
+ [TYPE_HX] = {
+ .max_baud_rate =1200,
+ },
};
static int pl2303_vendor_read(struct usb_serial *serial, u16 value,
@@ -394,16 +397,14 @@ static void pl2303_encode_baud_rate(struct tty_struct
*tty,
if (spriv->type->max_baud_rate)
baud = min_t(speed_t, baud, spriv->type->max_baud_rate);
/*
-* Set baud rate to nearest supported value.
-*
-* NOTE: Baud rate 500k can only be set using divisors.
+* Use direct method for supported baud rates, otherwise use divisors.
*/
baud_sup = pl2303_get_supported_baud_rate(baud);
- if (baud == 50)
- baud = pl2303_encode_baud_rate_divisor(buf, baud);
+ if (baud == baud_sup)
+ baud = pl2303_encode_baud_rate_direct(buf, baud);
else
- baud = pl2303_encode_baud_rate_direct(buf, baud_sup);
+ baud = pl2303_encode_baud_rate_divisor(buf, baud);
/* Save resulting baud rate */
tty_encode_baud_rate(tty, baud, baud);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: xhci: amd chipset also needs short TX quirk
Hi Mathias,
On Wed, Aug 13, 2014 at 03:12:25PM +0300, Mathias Nyman wrote:
> On 08/12/2014 05:13 PM, Huang Rui wrote:
> > AMD xHC also needs short tx quirk after tested on most of chipset
> > generations. That's because there is the same incorrect behavior like
> > Fresco Logic host. Please see below message with on USB webcam
> > attached on xHC host:
> >
> > [ 139.262944] xhci_hcd :00:10.0: WARN Successful completion on short
> > TX: needs XHCI_TRUST_TX_LENGTH quirk?
> > [ 139.266934] xhci_hcd :00:10.0: WARN Successful completion on short
> > TX: needs XHCI_TRUST_TX_LENGTH quirk?
> > [ 139.270913] xhci_hcd :00:10.0: WARN Successful completion on short
> > TX: needs XHCI_TRUST_TX_LENGTH quirk?
> > [ 139.274937] xhci_hcd :00:10.0: WARN Successful completion on short
> > TX: needs XHCI_TRUST_TX_LENGTH quirk?
> > [ 139.278914] xhci_hcd :00:10.0: WARN Successful completion on short
> > TX: needs XHCI_TRUST_TX_LENGTH quirk?
> > [ 139.282936] xhci_hcd :00:10.0: WARN Successful completion on short
> > TX: needs XHCI_TRUST_TX_LENGTH quirk?
> > [ 139.286915] xhci_hcd :00:10.0: WARN Successful completion on short
> > TX: needs XHCI_TRUST_TX_LENGTH quirk?
> > [ 139.290938] xhci_hcd :00:10.0: WARN Successful completion on short
> > TX: needs XHCI_TRUST_TX_LENGTH quirk?
> > [ 139.294913] xhci_hcd :00:10.0: WARN Successful completion on short
> > TX: needs XHCI_TRUST_TX_LENGTH quirk?
> > [ 139.298917] xhci_hcd :00:10.0: WARN Successful completion on short
> > TX: needs XHCI_TRUST_TX_LENGTH quirk?
> >
> > Reported-by: Arindam Nath
> > Tested-by: Shriraj-Rai P
> > Cc:
> > Signed-off-by: Huang Rui
> > ---
> > drivers/usb/host/xhci-pci.c |4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> > index e20520f..399a222 100644
> > --- a/drivers/usb/host/xhci-pci.c
> > +++ b/drivers/usb/host/xhci-pci.c
> > @@ -101,6 +101,10 @@ static void xhci_pci_quirks(struct device *dev, struct
> > xhci_hcd *xhci)
> > /* AMD PLL quirk */
> > if (pdev->vendor == PCI_VENDOR_ID_AMD && usb_amd_find_chipset_info())
> > xhci->quirks |= XHCI_AMD_PLL_FIX;
> > +
> > + if (pdev->vendor == PCI_VENDOR_ID_AMD)
> > + xhci->quirks |= XHCI_TRUST_TX_LENGTH;
> > +
> > if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
> > xhci->quirks |= XHCI_LPM_SUPPORT;
> > xhci->quirks |= XHCI_INTEL_HOST;
> >
>
> Thanks, I got a report that the AMD FCH hosts needed this quirk earlier, and
> have a patch pending for those.
>
> I'll use this instead
>
Thanks a lot. When you encountered AMD FCH issues in future, please
add me :)
Thanks,
Rui
--
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 RFC] usb: gadget: dwc2: make driver run on a version 3.10a instance of DWC_OTG
We are trying to make a driver run on our PCD only instance of Synopsys
DWC_OTG IP with the following parameters :
- Dedicated Fifos : Yes
- Descriptor DMA : Yes
- PHY : 8bit UTMI+ (may need also support for ULPI)
- Endpoints : 6 (7 with ep0)
- Periodic IN Endpoints : 0
- IN Endpoints : 3 (4 with ep0)
- EP repartition : INOUT, IN, OUT, IN , OUT, IN, OUT
- DFifo Depth : 1844
I do not know what is the original s3c hsotg IP config, but to
correctly support the Dedicated Fifos you need to attribute a FIFO
index for each IN endpoints, and on the 3.10a release we only have
4 TX FIFOS, so we just cannot give the EP number as fifo index.
It impacts the FIFO repartition, it is not perfect since we do
not take into account the Isochronous needs, so it needs some
rework.
To managed these FIFOs, I load from the registers the EP
repartition, HW fifo depth and HW revision.
It also impacts that hw_cfg must be done before init call.
Same for the num_of_eps value, in the Synopsys documentation,
it specifies it is the count of non-ep0 endpoints, but the
driver for loops where like :
for(i = 1 ; i < hsotg->num_of_eps ; ++i)
which is absolutely invalid and ignores the last EP.
We never managed to make the driver work in FIFO mode, but in DMA
mode it works like a charm, and to support all the gadget drivers,
we implemented a silly Bounce Buffer mode.
The PHY configuration was also rewritten according to the
documentation.
Fo the descripto DMA mode, I tried to add missing parts, but I get stuck
with weird HW beheviours
Signed-off-by: Neil Armstrong
---
drivers/usb/dwc2/core.h | 14 +++
drivers/usb/dwc2/gadget.c | 267 +++--
2 files changed, 221 insertions(+), 60 deletions(-)
This is mainly an RFC in order to make this driver run with recent HW.
This is why the patch is not 100% clean.
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 1efd10c..21c136e 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -102,6 +102,7 @@ struct s3c_hsotg_req;
* @dir_in: Set to true if this endpoint is of the IN direction, which
* means that it is sending data to the Host.
* @index: The index for the endpoint registers.
+ * @txfnum: The TX fifo index.
* @mc: Multi Count - number of transactions per microframe
* @interval - Interval for periodic endpoints
* @name: The name array passed to the USB core.
@@ -142,6 +143,7 @@ struct s3c_hsotg_ep {
unsigned char dir_in;
unsigned char index;
+unsigned inttxfnum;
unsigned char mc;
unsigned char interval;
@@ -167,6 +169,10 @@ struct s3c_hsotg_ep {
* @phyif: PHY interface width
* @dedicated_fifos: Set if the hardware has dedicated IN-EP fifos.
* @num_of_eps: Number of available EPs (excluding EP0)
+ * @dfifo_depth: depth of HW DFIFO
+ * @dir_of_eps: direction of each endpoint
+ * @hw_major: Hardware Major number
+ * @hw_minor: Hardware minor ID
* @debug_root: root directrory for debugfs.
* @debug_file: main status file for debugfs.
* @debug_fifo: FIFO status file for debugfs.
@@ -195,7 +201,12 @@ struct s3c_hsotg {
u32 phyif;
unsigned intdedicated_fifos:1;
+unsigned intdfifo_depth;
unsigned char num_of_eps;
+unsigned intdma_enable:1;
+unsigned char dir_of_eps[16];
+unsigned inthw_major;
+unsigned inthw_minor[3];
struct dentry *debug_root;
struct dentry *debug_file;
@@ -224,6 +235,9 @@ struct s3c_hsotg_req {
struct list_headqueue;
unsigned char in_progress;
unsigned char mapped;
+unsignedbounced_dma;
+dma_addr_t bounce_phys;
+void* bounce;
};
#define call_gadget(_hs, _entry) \
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 392b373..1f3f9b9 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -89,7 +89,7 @@ static void s3c_hsotg_dump(struct s3c_hsotg *hsotg);
*/
static inline bool using_dma(struct s3c_hsotg *hsotg)
{
-return false;/* support is not complete */
+return hsotg->dma_enable;
}
/**
@@ -163,17 +163,30 @@ static void s3c_hsotg_ctrl_epint(struct s3c_hsotg *hsotg,
*/
static void s3c_hsotg_init_fifo(struct s3c_hsotg *hsotg)
{
+unsigned int rxfifo_size;
unsigned int ep;
unsigned int addr;
unsigned int size;
+unsigned int txfifonum;
int timeout;
u32 val;
-/* set FIFO sizes to 2048/1024 */
+rxfifo_size = (4 * 1) + 6; // (4 * number of control endpoint + 6)
+rxfifo_size += (1024 / 4) + 1; // (largest packet / 4) + 1
+rxfifo_size += 2; // for ep0 as OUT endpoint
+for (ep = 1; ep <= hsotg->num_of_eps; ep++)
+if(hsotg->dir_of_eps[ep] > 1)
+rxfifo_size += 2; // OUT endpoint
+rxfifo_size += 1; // fo
Re: [PATCH v3] pl2303: use divisors for unsupported baud rates
On Wed, Aug 13, 2014 at 03:02:53PM +0300, Lauri Hintsala wrote:
> Use direct method for supported baud rates, otherwise use divisors.
> Limit baud rate to 12 Mbaud with HX type.
>
> This change has been tested to work with PL-2303HX at 115200, 50,
> 100, 200, 250, 300 and 400 baud rates.
>
> Signed-off-by: Lauri Hintsala
Looks good. I'll queue this up after the merge window.
Thanks,
Johan
> ---
> CC: Johan Hovold
> CC: Greg Kroah-Hartman
> CC: Frank Schäfer
> CC: linux-usb@vger.kernel.org
>
> Changes since V2:
> * fixed typo in type name
>
> Changes since V1:
> * added baud rate limit for HX
>
>
> drivers/usb/serial/pl2303.c | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
> index b3d5a35..0a9a3b3 100644
> --- a/drivers/usb/serial/pl2303.c
> +++ b/drivers/usb/serial/pl2303.c
> @@ -161,6 +161,9 @@ static const struct pl2303_type_data
> pl2303_type_data[TYPE_COUNT] = {
> .max_baud_rate =1228800,
> .quirks = PL2303_QUIRK_LEGACY,
> },
> + [TYPE_HX] = {
> + .max_baud_rate =1200,
> + },
> };
>
> static int pl2303_vendor_read(struct usb_serial *serial, u16 value,
> @@ -394,16 +397,14 @@ static void pl2303_encode_baud_rate(struct tty_struct
> *tty,
> if (spriv->type->max_baud_rate)
> baud = min_t(speed_t, baud, spriv->type->max_baud_rate);
> /*
> - * Set baud rate to nearest supported value.
> - *
> - * NOTE: Baud rate 500k can only be set using divisors.
> + * Use direct method for supported baud rates, otherwise use divisors.
>*/
> baud_sup = pl2303_get_supported_baud_rate(baud);
>
> - if (baud == 50)
> - baud = pl2303_encode_baud_rate_divisor(buf, baud);
> + if (baud == baud_sup)
> + baud = pl2303_encode_baud_rate_direct(buf, baud);
> else
> - baud = pl2303_encode_baud_rate_direct(buf, baud_sup);
> + baud = pl2303_encode_baud_rate_divisor(buf, baud);
>
> /* Save resulting baud rate */
> tty_encode_baud_rate(tty, baud, baud);
--
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] Revert "usb: chipidea: udc: .pullup is valid only when vbus is there"
On Wed, 13 Aug 2014, Peter Chen wrote: > > So here's what the UDC driver should do: If the pullup routine is called > > while Vbus is off, the driver should leave the D+ pullup disconnected but > > remember the call. Then when Vbus gets turned on, the driver should > > activate the pullup. > > > > In other words, the UDC driver should keep track of the pullup's > > "logical" state. When Vbus is off, the pullup must also be off. When > > Vbus is on, the pullup's physical state should be the same as the logical > > state. > > > > We had a similar discussion at last year, but Felipe " don't want to let UDC > drivers call usb_gadget_connect()/disconnect() directly." All right, let's see what Felipe says about my suggestion. 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: Transient USB disconnects
On Wed, 13 Aug 2014, David Laight wrote: > We are seeing some transient USB disconnects, these cause serious grief > if we use the xhci driver, so the ports are all forced to use ehci (bios > config). > Even with ehci they are slightly problematic, partially resolved by using a > 'bond' interface to stop the ethernet interface and address disappearing. > > The hardware is a custom board containing an smsc95xx hub+ethernet. > > The kernel trace just shows (at about 4am): > [39203.215205] hid-generic 0003:03F0:034A.0004: can't reset device, > :00:1d.0-1.5.4/input1, status -71 > [39203.223659] usb 2-1.5: clear tt 4 (0070) error -71 > [39203.232065] hid-generic 0003:03F0:034A.0003: can't reset device, > :00:1d.0-1.5.4/input0, status -71 > [39203.236024] usb 2-1.5: clear tt 4 (0070) error -71 > [39203.241057] hid-generic 0003:03F0:034A.0004: can't reset device, > :00:1d.0-1.5.4/input1, status -71 > [39203.244019] usb 2-1.5: clear tt 4 (0070) error -71 > [39203.254161] hid-generic 0003:03F0:034A.0003: can't reset device, > :00:1d.0-1.5.4/input0, status -71 > [39203.258132] usb 2-1.5: clear tt 4 (0070) error -71 > [39203.263274] hid-generic 0003:03F0:034A.0004: can't reset device, > :00:1d.0-1.5.4/input1, status -71 > [39203.266120] usb 2-1.5: clear tt 4 (0070) error -71 > [39203.276519] hid-generic 0003:03F0:034A.0003: can't reset device, > :00:1d.0-1.5.4/input0, status -71 > [39203.280479] usb 2-1.5: clear tt 4 (0070) error -71 > [39203.286082] hid-generic 0003:03F0:034A.0004: can't reset device, > :00:1d.0-1.5.4/input1, status -71 > [39203.288342] usb 2-1.5: USB disconnect, device number 3 > [39203.288347] usb 2-1.5.1: USB disconnect, device number 4 > [39203.290948] usb 2-1.5: clear tt 4 (0070) error -71 > [39203.293313] smsc95xx 2-1.5.1:1.0 eth1: unregister 'smsc95xx' > usb-:00:1d.0-1.5.1, smsc95xx USB 2.0 Ethernet > [39203.29] smsc95xx 2-1.5.1:1.0 eth1: hardware isn't capable of remote > wakeup > [39203.322991] usb 2-1.5.2: USB disconnect, device number 5 > [39203.323794] usb 2-1.5.3: USB disconnect, device number 6 > [39203.367370] usb 2-1.5.4: USB disconnect, device number 7 > > The device(s) then reattach... > > [39203.698501] usb 2-1.5: new high-speed USB device number 8 using ehci-pci > [39203.790708] usb 2-1.5: New USB device found, idVendor=0424, idProduct=9514 > [39203.790718] usb 2-1.5: New USB device strings: Mfr=0, Product=0, > SerialNumber=0 > [39203.791226] hub 2-1.5:1.0: USB hub found > [39203.791387] hub 2-1.5:1.0: 5 ports detected > > I don't really know what happens first. > 'input0' and 'input1' are both the USB keyboard. > It would be nice to know why the reset was requested, and why the disconnects > were done. > Is the recovery from the failed resets forcing the disconnects - or is that > just a symptom > of the same underlying error? The resets were done because of communication errors. The errors occurred because the HID device's parent hub disconnected from the bus. I suppose the usbhid driver could stop working so hard, and simply give up when a reset fails instead of retrying the reset. That would reduce the number of error messages in the system log, but it wouldn't solve anything. > Trouble is this happens about once a day, and we haven't found anything that > really > changes the frequency. It doesn't seem to be affected by real USB data > (saturating > the ethernet interface makes little difference). > It might be that there are actually a lot of silent retries going on, but I > don't > really know where to look to find out. > We currently have cut the 5v line on the USB interface - just in case it was > carrying noise. > > Any ideas? Have you used a bus analyzer on the wire connected to the parent hub's upstream port? If you do, you should be able to see the events leading up to a reset. My guess is that they will all look normal until at some point the HID device stops responding to packets. Probably the hub disconnects from the bus first and that's the reason the responses stop. Why does the hub disconnect? I have no idea. 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: [RFC PATCH] Revert "usb: chipidea: udc: .pullup is valid only when vbus is there"
Hi, On Wed, Aug 13, 2014 at 10:02:08AM -0400, Alan Stern wrote: > > > So here's what the UDC driver should do: If the pullup routine is called > > > while Vbus is off, the driver should leave the D+ pullup disconnected but > > > remember the call. Then when Vbus gets turned on, the driver should > > > activate the pullup. > > > > > > In other words, the UDC driver should keep track of the pullup's > > > "logical" state. When Vbus is off, the pullup must also be off. When > > > Vbus is on, the pullup's physical state should be the same as the logical > > > state. > > > > > > > We had a similar discussion at last year, but Felipe " don't want to let UDC > > drivers call usb_gadget_connect()/disconnect() directly." > > All right, let's see what Felipe says about my suggestion. Keeping track of the pullup's state like that will just add complexity to the UDC drivers. There's really no problem in connecting pullups before VBUS is above session valid threshold. The whole idea of udc-core was to handle those details generically so we don't have to patch every single UDC driver. The best solution, IMO, would be to teach every function about activate/deactivate and only connect pullups based on that. So that functions, and only functions, are responsible for managing pullups. Functions which don't need to wait for userspace can just call usb_function_activate() from their bind() method, while functions relying on userspace can do so when the devnode is opened or whatever. -- balbi signature.asc Description: Digital signature
Re: [PATCH v4] kconfig/symbol.c: handle choice_values that depend on 'm' symbols
All,
On Mon, Nov 18, 2013 at 12:08 PM, Yann E. MORIN wrote:
> Dirk, All,
>
> On 2013-11-07 15:05 +0100, Dirk Gouders spake thusly:
>> If choices consist of choice_values that depend on symbols set to 'm',
>> those choice_values are not set to 'n' if the choice is changed from
>> 'm' to 'y' (in which case only one active choice_value is allowed).
>> Those values are also written to the config file causing modules to be
>> built when they should not.
>>
>> The following config can be used to reproduce and examine the problem;
>> with the frontend of your choice set "Choice 0" and "Choice 1" to 'm',
>> then set "Tristate Choice" to 'y' and save the configuration:
>>
>> config modules
>> boolean modules
>> default y
>> option modules
>>
>> config dependency
>> tristate "Dependency"
>> default m
>>
>> choice
>> prompt "Tristate Choice"
>> default choice0
>>
>> config choice0
>> tristate "Choice 0"
>>
>> config choice1
>> tristate "Choice 1"
>> depends on dependency
>>
>> endchoice
>>
>> This patch sets choice_values' visibility that depend on symbols set
>> to 'm' to 'n' if the corresponding choice is set to 'y'. This makes
>> them disappear from the choice list and will also cause the
>> choice_values' value set to 'n' in sym_calc_value() and as a result
>> they are written as "not set" to the resulting .config file.
>>
>> Reported-by: Sebastian Andrzej Siewior
>> Signed-off-by: Dirk Gouders
>> Tested-by: Sebastian Andrzej Siewior
>
> Acked-by: "Yann E. MORIN"
>
> It will be in my tree soon. Thanks!
I don't see this patch in 3.16 but 3.16 does not have the issue any
more. Anyone has an idea how the issue got fixed? I am trying to find
the right patch to backport.
Thanks,
-Bin.
>
> Regards,
> Yann E. MORIN.
>
>> ---
>> scripts/kconfig/symbol.c | 11 +++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
>> index c9a6775..06d96c9 100644
>> --- a/scripts/kconfig/symbol.c
>> +++ b/scripts/kconfig/symbol.c
>> @@ -189,12 +189,23 @@ static void sym_validate_range(struct symbol *sym)
>> static void sym_calc_visibility(struct symbol *sym)
>> {
>> struct property *prop;
>> + struct symbol *choice_sym = NULL;
>> tristate tri;
>>
>> /* any prompt visible? */
>> tri = no;
>> +
>> + if (sym_is_choice_value(sym))
>> + choice_sym = prop_get_symbol(sym_get_choice_prop(sym));
>> +
>> for_all_prompts(sym, prop) {
>> prop->visible.tri = expr_calc_value(prop->visible.expr);
>> + /*
>> + * choice_values with visibility 'mod' are not visible if the
>> + * corresponding choice's value is 'yes'.
>> + */
>> + if (prop->visible.tri == mod && (choice_sym &&
>> choice_sym->curr.tri == yes))
>> + prop->visible.tri = no;
>> tri = EXPR_OR(tri, prop->visible.tri);
>> }
>> if (tri == mod && (sym->type != S_TRISTATE || modules_val == no))
>> --
>> 1.8.4
>>
>
> --
> .-..--..
> | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics'
> conspiracy: |
> | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___
> |
> | +33 223 225 172 `.---: X AGAINST | \e/ There is no
> |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL| v conspiracy.
> |
> '--^---^--^'
> --
> 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
--
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: FTDI Kernel driver
On Wed, Aug 13, 2014 at 02:48:25PM +0200, Nicolas Alt wrote: > Hi, > > there is a comment in the code ftdi_sio.c, saying that new device IDs > should be reported to be added to the driver. I guess you are the > current maintainer? > > I have a converter from Basic Micro, which uses 0x0403 / 0xa559. > Comments about this device can be found in various forums, e.g. > http://forums.basicmicro.com/atomnano-f485/usb2serial-with-linux-t9602.html. > I tested it successfully using: > > echo 0403 a559 | sudo tee /sys/bus/usb-serial/drivers/ftdi_sio/new_id Thanks for the report. I'll respond to this mail with a patch adding this PID to the driver. Please test if you can, and I'll queue it up once the merge window closes. Thanks, Johan -- 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: ftdi_sio: add Basic Micro ATOM Nano USB2Serial PID
Add device id for Basic Micro ATOM Nano USB2Serial adapters.
Reported-by: Nicolas Alt
Cc: stable
Signed-off-by: Johan Hovold
---
drivers/usb/serial/ftdi_sio.c | 1 +
drivers/usb/serial/ftdi_sio_ids.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 216ce3078270..93e088ed4306 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -146,6 +146,7 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(FTDI_VID, FTDI_AMC232_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_CANUSB_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_CANDAPTER_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_BM_ATOM_NANO_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_NXTCAM_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_EV3CON_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_SCS_DEVICE_0_PID) },
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serial/ftdi_sio_ids.h
index 1e58d90a0b6c..3168a0191973 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -42,6 +42,8 @@
/* www.candapter.com Ewert Energy Systems CANdapter device */
#define FTDI_CANDAPTER_PID 0x9F80 /* Product Id */
+#define FTDI_BM_ATOM_NANO_PID 0xa559 /* Basic Micro ATOM Nano USB2Serial */
+
/*
* Texas Instruments XDS100v2 JTAG / BeagleBone A3
* http://processors.wiki.ti.com/index.php/XDS100
--
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: usbserial_generic
I can try a patch, but the testing will have to fit in between the primary uses of the machine (we have entirely too few Linux boxes at work, and far too many Windows ones), so there might be a little latency in getting to it. Shouldn't be more than a couple of days though. I was unaware of the sysfs method, yet another undocumented (or at least I didn't find it in in my google searching when trying to figure out why modprobe wasn't working and wasn't generating ANY feedback) method. It is in my notes now! Much cleaner. Thanks. I bet I could put it in a udev script and automate this... but a proper patch would be better. The Novatel seems to work fine as it is currently configured, although I have not tried to receive any binary logs over USB on the Linux box yet. Below is the relevant portion of the 'lsusb -v' output. The device I am actually testing with is a NovaTel FlexPac6 rev 2 with a OEM628 board in it. This is NovaTel's middle of the line civilian GPS receiver hardware, although I understand that all of their hardware with a USB port uses the same USB hardware (and vender and product IDs). Kirk Bus 001 Device 005: ID 09d7:0100 Novatel Wireless NovAtel FlexPack GPS receiver Couldn't open device, some information will be missing Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 255 bMaxPacketSize064 idVendor 0x09d7 Novatel Wireless idProduct 0x0100 NovAtel FlexPack GPS receiver bcdDevice1.01 iManufacturer 1 iProduct2 iSerial 3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 60 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 bmAttributes 0xc0 Self Powered MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 6 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol255 iInterface 5 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x06 EP 6 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 -Original Message- From: Johan Hovold [mailto:jhov...@gmail.com] On Behalf Of Johan Hovold Sent: Wednesday, August 13, 2014 01:16 To: Kirk Madsen Cc: linux-usb@vger.kernel.org Subject: Re: usbserial_generic On Tue, Aug 12, 2014 at 09:53:41AM -0600, Kirk Madsen wrote: > After a great deal of searching, I discovered that instead of doing a > simple "/sbin
Re: [RFC PATCH] Revert "usb: chipidea: udc: .pullup is valid only when vbus is there"
On Wed, 13 Aug 2014, Felipe Balbi wrote: > Keeping track of the pullup's state like that will just add complexity > to the UDC drivers. There's really no problem in connecting pullups > before VBUS is above session valid threshold. Except that doing so violates the hardware test suite Peter mentioned. That was the starting point of this discussion. > The whole idea of udc-core was to handle those details generically so we > don't have to patch every single UDC driver. The best solution, IMO, > would be to teach every function about activate/deactivate and only > connect pullups based on that. So that functions, and only functions, > are responsible for managing pullups. > > Functions which don't need to wait for userspace can just call > usb_function_activate() from their bind() method, while functions > relying on userspace can do so when the devnode is opened or whatever. usb_function_activate() is part of libcomposite. Do we still have any of the old-style gadgets that don't use libcomposite? Aside from inode.c, it doesn't look like there are any... If you want libcomposite to handle the pullups on behalf of the function drivers, there has to be a way for the UDC driver to tell libcomposite when Vbus turns on and off. Add a new callback to the usb_gadget_driver structure? 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: [RFC PATCH] Revert "usb: chipidea: udc: .pullup is valid only when vbus is there"
On Wed, Aug 13, 2014 at 09:19:31AM -0500, Felipe Balbi wrote: > Hi, > > On Wed, Aug 13, 2014 at 10:02:08AM -0400, Alan Stern wrote: > > > > So here's what the UDC driver should do: If the pullup routine is called > > > > while Vbus is off, the driver should leave the D+ pullup disconnected > > > > but > > > > remember the call. Then when Vbus gets turned on, the driver should > > > > activate the pullup. > > > > > > > > In other words, the UDC driver should keep track of the pullup's > > > > "logical" state. When Vbus is off, the pullup must also be off. When > > > > Vbus is on, the pullup's physical state should be the same as the > > > > logical > > > > state. > > > > > > > > > > We had a similar discussion at last year, but Felipe " don't want to let > > > UDC > > > drivers call usb_gadget_connect()/disconnect() directly." > > > > All right, let's see what Felipe says about my suggestion. > > Keeping track of the pullup's state like that will just add complexity > to the UDC drivers. There's really no problem in connecting pullups > before VBUS is above session valid threshold. > > The whole idea of udc-core was to handle those details generically so we > don't have to patch every single UDC driver. The best solution, IMO, > would be to teach every function about activate/deactivate and only > connect pullups based on that. So that functions, and only functions, > are responsible for managing pullups. > > Functions which don't need to wait for userspace can just call > usb_function_activate() from their bind() method, while functions > relying on userspace can do so when the devnode is opened or whatever. That will not solve the scenario where one composite device manage e.g. three different functions. Lets assume we have one acm, one uvc and one ncm (in that exact order). That will lead to one usb_function_activate, one usb_function_deactivate and one usb_function_activate. Not even speaking of the complexity we gain, when using g_ffs. That is composing the composite gadget in userspace runtime. Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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] Revert "usb: chipidea: udc: .pullup is valid only when vbus is there"
On Wed, Aug 13, 2014 at 12:02:05PM -0400, Alan Stern wrote: > On Wed, 13 Aug 2014, Felipe Balbi wrote: > > > Keeping track of the pullup's state like that will just add complexity > > to the UDC drivers. There's really no problem in connecting pullups > > before VBUS is above session valid threshold. > > Except that doing so violates the hardware test suite Peter mentioned. > That was the starting point of this discussion. oh ok. > > The whole idea of udc-core was to handle those details generically so we > > don't have to patch every single UDC driver. The best solution, IMO, > > would be to teach every function about activate/deactivate and only > > connect pullups based on that. So that functions, and only functions, > > are responsible for managing pullups. > > > > Functions which don't need to wait for userspace can just call > > usb_function_activate() from their bind() method, while functions > > relying on userspace can do so when the devnode is opened or whatever. > > usb_function_activate() is part of libcomposite. Do we still have any > of the old-style gadgets that don't use libcomposite? Aside from > inode.c, it doesn't look like there are any... > > If you want libcomposite to handle the pullups on behalf of the > function drivers, there has to be a way for the UDC driver to tell > libcomposite when Vbus turns on and off. Add a new callback to the > usb_gadget_driver structure? usb_gadget_driver, why ? We need a way for udc-core to ask the PHY if VBUS is already above session valid threshold. My fear is that we might end up implementing this by polling this PHY method until it's valid. Are we starting to see a need for a kgadgetd which gets awaken on different conditions ? Any other ideas ? -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH] Revert "usb: chipidea: udc: .pullup is valid only when vbus is there"
On Wed, Aug 13, 2014 at 06:08:55PM +0200, Michael Grzeschik wrote:
> On Wed, Aug 13, 2014 at 09:19:31AM -0500, Felipe Balbi wrote:
> > Hi,
> >
> > On Wed, Aug 13, 2014 at 10:02:08AM -0400, Alan Stern wrote:
> > > > > So here's what the UDC driver should do: If the pullup routine is
> > > > > called
> > > > > while Vbus is off, the driver should leave the D+ pullup disconnected
> > > > > but
> > > > > remember the call. Then when Vbus gets turned on, the driver should
> > > > > activate the pullup.
> > > > >
> > > > > In other words, the UDC driver should keep track of the pullup's
> > > > > "logical" state. When Vbus is off, the pullup must also be off. When
> > > > > Vbus is on, the pullup's physical state should be the same as the
> > > > > logical
> > > > > state.
> > > > >
> > > >
> > > > We had a similar discussion at last year, but Felipe " don't want to
> > > > let UDC
> > > > drivers call usb_gadget_connect()/disconnect() directly."
> > >
> > > All right, let's see what Felipe says about my suggestion.
> >
> > Keeping track of the pullup's state like that will just add complexity
> > to the UDC drivers. There's really no problem in connecting pullups
> > before VBUS is above session valid threshold.
> >
> > The whole idea of udc-core was to handle those details generically so we
> > don't have to patch every single UDC driver. The best solution, IMO,
> > would be to teach every function about activate/deactivate and only
> > connect pullups based on that. So that functions, and only functions,
> > are responsible for managing pullups.
> >
> > Functions which don't need to wait for userspace can just call
> > usb_function_activate() from their bind() method, while functions
> > relying on userspace can do so when the devnode is opened or whatever.
>
>
> That will not solve the scenario where one composite device manage e.g.
> three different functions. Lets assume we have one acm, one uvc and one ncm
> (in that exact order). That will lead to one usb_function_activate,
> one usb_function_deactivate and one usb_function_activate.
something like this:
/* done automatically by composite layer */
for_each_function_bind() {
usb_function_deactivate();
}
so you know that you'll have 3 deactivations by default (per your
example). NCM calls activate without waiting for userland, you still
have 2 activations missing. Those will be called when the userland UVC
and ACM counterparts open the respective devnodes.
> Not even speaking of the complexity we gain, when using g_ffs. That
> is composing the composite gadget in userspace runtime.
right, we'd need an ioctl to let userspace call that when using g_ffs.
--
balbi
signature.asc
Description: Digital signature
Re: [RFC PATCH] Revert "usb: chipidea: udc: .pullup is valid only when vbus is there"
On Wed, 13 Aug 2014, Felipe Balbi wrote: > > If you want libcomposite to handle the pullups on behalf of the > > function drivers, there has to be a way for the UDC driver to tell > > libcomposite when Vbus turns on and off. Add a new callback to the > > usb_gadget_driver structure? > > usb_gadget_driver, why ? We need a way for udc-core to ask the PHY if Not udc-core. libcomposite. > VBUS is already above session valid threshold. My fear is that we might > end up implementing this by polling this PHY method until it's valid. > > Are we starting to see a need for a kgadgetd which gets awaken on > different conditions ? Any other ideas ? The UDC driver ought to know when Vbus turns on or off, without polling. It should get an interrupt when that happens, or its ops->vbus_session routine should be called. So at that time, the UDC driver could invoke a new usb_gadget_driver callback. Let's also call it vbus_session. Since composite.c defines a usb_gadget_driver structure, it can have a composite_vbus_session() callback. When this routine is called, it will check to see whether all the functions are activated. If they are and Vbus is now on, it will call usb_gadget_connect(); otherwise it will call usb_gadget_disconnect(). 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: [RFC PATCH] Revert "usb: chipidea: udc: .pullup is valid only when vbus is there"
Hi, On Wed, Aug 13, 2014 at 12:56:27PM -0400, Alan Stern wrote: > > > If you want libcomposite to handle the pullups on behalf of the > > > function drivers, there has to be a way for the UDC driver to tell > > > libcomposite when Vbus turns on and off. Add a new callback to the > > > usb_gadget_driver structure? > > > > usb_gadget_driver, why ? We need a way for udc-core to ask the PHY if > > Not udc-core. libcomposite. > > > VBUS is already above session valid threshold. My fear is that we might > > end up implementing this by polling this PHY method until it's valid. > > > > Are we starting to see a need for a kgadgetd which gets awaken on > > different conditions ? Any other ideas ? > > The UDC driver ought to know when Vbus turns on or off, without > polling. It should get an interrupt when that happens, or its > ops->vbus_session routine should be called. So at that time, the UDC > driver could invoke a new usb_gadget_driver callback. Let's also call > it vbus_session. > > Since composite.c defines a usb_gadget_driver structure, it can have a > composite_vbus_session() callback. When this routine is called, it > will check to see whether all the functions are activated. If they are > and Vbus is now on, it will call usb_gadget_connect(); otherwise it > will call usb_gadget_disconnect(). sounds good. I think we will be able to drop gadget->vbus_session() once this is all done as most current implementations will call gadget->disconnect/connect() conditionally on vbus being active or not. -- balbi signature.asc Description: Digital signature
RE: [PATCH RFC] usb: gadget: dwc2: make driver run on a version 3.10a instance of DWC_OTG
> From: Neil Armstrong [mailto:narmstr...@neotion.com] > Sent: Wednesday, August 13, 2014 5:17 AM > > We are trying to make a driver run on our PCD only instance of Synopsys > DWC_OTG IP with the following parameters : > - Dedicated Fifos : Yes > - Descriptor DMA : Yes > - PHY : 8bit UTMI+ (may need also support for ULPI) > - Endpoints : 6 (7 with ep0) > - Periodic IN Endpoints : 0 > - IN Endpoints : 3 (4 with ep0) > - EP repartition : INOUT, IN, OUT, IN , OUT, IN, OUT > - DFifo Depth : 1844 > > I do not know what is the original s3c hsotg IP config, but to > correctly support the Dedicated Fifos you need to attribute a FIFO > index for each IN endpoints, and on the 3.10a release we only have > 4 TX FIFOS, so we just cannot give the EP number as fifo index. > > It impacts the FIFO repartition, it is not perfect since we do > not take into account the Isochronous needs, so it needs some > rework. > > To managed these FIFOs, I load from the registers the EP > repartition, HW fifo depth and HW revision. > It also impacts that hw_cfg must be done before init call. > > Same for the num_of_eps value, in the Synopsys documentation, > it specifies it is the count of non-ep0 endpoints, but the > driver for loops where like : > for(i = 1 ; i < hsotg->num_of_eps ; ++i) > which is absolutely invalid and ignores the last EP. > > We never managed to make the driver work in FIFO mode, but in DMA > mode it works like a charm, and to support all the gadget drivers, > we implemented a silly Bounce Buffer mode. > > The PHY configuration was also rewritten according to the > documentation. > > Fo the descripto DMA mode, I tried to add missing parts, but I get stuck > with weird HW beheviours Hi Neil, Thanks for your work on this. First off, please always submit patches, even RFCs, with the proper kernel coding style. scripts/checkpatch.pl will help you there. That way other developers are more likely to take your patches seriously. Second, you should base your work on top of Robert Baldyga's patch series "usb: dwc2/gadget: fix series". That should be going into the kernel when the merge window opens up next week. That series also touches the FIFO configuration code. You can find it at http://marc.info/?l=linux-kernel&m=140568383216978. Third, it looks like we may need some way to customize the FIFO configuration depending on the platform. I don't think it's possible to configure the FIFOs properly for all platforms otherwise. Maybe you and Robert could work together on that? Fourth, you should split out the fixes (like the off-by-one in the endpoint loops) into separate patches. Those could be applied right away. Other than that, this looks OK to me. I especially like that you are providing a way to enable DMA support, since I will need that myself in the near future ;) -- Paul -- 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] Revert "usb: chipidea: udc: .pullup is valid only when vbus is there"
> From: linux-usb-ow...@vger.kernel.org > [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Felipe Balbi > Sent: Wednesday, August 13, 2014 10:20 AM > > On Wed, Aug 13, 2014 at 12:56:27PM -0400, Alan Stern wrote: > > > > If you want libcomposite to handle the pullups on behalf of the > > > > function drivers, there has to be a way for the UDC driver to tell > > > > libcomposite when Vbus turns on and off. Add a new callback to the > > > > usb_gadget_driver structure? > > > > > > usb_gadget_driver, why ? We need a way for udc-core to ask the PHY if > > > > Not udc-core. libcomposite. > > > > > VBUS is already above session valid threshold. My fear is that we might > > > end up implementing this by polling this PHY method until it's valid. > > > > > > Are we starting to see a need for a kgadgetd which gets awaken on > > > different conditions ? Any other ideas ? > > > > The UDC driver ought to know when Vbus turns on or off, without > > polling. It should get an interrupt when that happens, or its > > ops->vbus_session routine should be called. So at that time, the UDC > > driver could invoke a new usb_gadget_driver callback. Let's also call > > it vbus_session. > > > > Since composite.c defines a usb_gadget_driver structure, it can have a > > composite_vbus_session() callback. When this routine is called, it > > will check to see whether all the functions are activated. If they are > > and Vbus is now on, it will call usb_gadget_connect(); otherwise it > > will call usb_gadget_disconnect(). Is there a difference between a VBus on/off and a connect/disconnect? Because AFAIK the Synopsys USB 3.0 controller (unless it is configured for OTG mode) does not have a way to detect when VBus is enabled/ disabled, other than by a connect/disconnect interrupt. > sounds good. I think we will be able to drop gadget->vbus_session() once > this is all done as most current implementations will call > gadget->disconnect/connect() conditionally on vbus being active or not. > > -- > balbi -- 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] Revert "usb: chipidea: udc: .pullup is valid only when vbus is there"
Hi, On Wed, Aug 13, 2014 at 07:15:37PM +, Paul Zimmerman wrote: > > From: linux-usb-ow...@vger.kernel.org > > [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Felipe Balbi > > Sent: Wednesday, August 13, 2014 10:20 AM > > > > On Wed, Aug 13, 2014 at 12:56:27PM -0400, Alan Stern wrote: > > > > > If you want libcomposite to handle the pullups on behalf of the > > > > > function drivers, there has to be a way for the UDC driver to tell > > > > > libcomposite when Vbus turns on and off. Add a new callback to the > > > > > usb_gadget_driver structure? > > > > > > > > usb_gadget_driver, why ? We need a way for udc-core to ask the PHY if > > > > > > Not udc-core. libcomposite. > > > > > > > VBUS is already above session valid threshold. My fear is that we might > > > > end up implementing this by polling this PHY method until it's valid. > > > > > > > > Are we starting to see a need for a kgadgetd which gets awaken on > > > > different conditions ? Any other ideas ? > > > > > > The UDC driver ought to know when Vbus turns on or off, without > > > polling. It should get an interrupt when that happens, or its > > > ops->vbus_session routine should be called. So at that time, the UDC > > > driver could invoke a new usb_gadget_driver callback. Let's also call > > > it vbus_session. > > > > > > Since composite.c defines a usb_gadget_driver structure, it can have a > > > composite_vbus_session() callback. When this routine is called, it > > > will check to see whether all the functions are activated. If they are > > > and Vbus is now on, it will call usb_gadget_connect(); otherwise it > > > will call usb_gadget_disconnect(). > > Is there a difference between a VBus on/off and a connect/disconnect? > Because AFAIK the Synopsys USB 3.0 controller (unless it is configured > for OTG mode) does not have a way to detect when VBus is enabled/ > disabled, other than by a connect/disconnect interrupt. yeah, there's no difference from the digital side of things. Most boards I've seen use USB vbus comparators present on the PMIC. -- balbi signature.asc Description: Digital signature
RE: [RFC PATCH] Revert "usb: chipidea: udc: .pullup is valid only when vbus is there"
> From: Felipe Balbi [mailto:ba...@ti.com] > Sent: Wednesday, August 13, 2014 12:21 PM > > On Wed, Aug 13, 2014 at 07:15:37PM +, Paul Zimmerman wrote: > > > From: linux-usb-ow...@vger.kernel.org > > > [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Felipe Balbi > > > Sent: Wednesday, August 13, 2014 10:20 AM > > > > > > On Wed, Aug 13, 2014 at 12:56:27PM -0400, Alan Stern wrote: > > > > > > If you want libcomposite to handle the pullups on behalf of the > > > > > > function drivers, there has to be a way for the UDC driver to tell > > > > > > libcomposite when Vbus turns on and off. Add a new callback to the > > > > > > usb_gadget_driver structure? > > > > > > > > > > usb_gadget_driver, why ? We need a way for udc-core to ask the PHY if > > > > > > > > Not udc-core. libcomposite. > > > > > > > > > VBUS is already above session valid threshold. My fear is that we > > > > > might > > > > > end up implementing this by polling this PHY method until it's valid. > > > > > > > > > > Are we starting to see a need for a kgadgetd which gets awaken on > > > > > different conditions ? Any other ideas ? > > > > > > > > The UDC driver ought to know when Vbus turns on or off, without > > > > polling. It should get an interrupt when that happens, or its > > > > ops->vbus_session routine should be called. So at that time, the UDC > > > > driver could invoke a new usb_gadget_driver callback. Let's also call > > > > it vbus_session. > > > > > > > > Since composite.c defines a usb_gadget_driver structure, it can have a > > > > composite_vbus_session() callback. When this routine is called, it > > > > will check to see whether all the functions are activated. If they are > > > > and Vbus is now on, it will call usb_gadget_connect(); otherwise it > > > > will call usb_gadget_disconnect(). > > > > Is there a difference between a VBus on/off and a connect/disconnect? > > Because AFAIK the Synopsys USB 3.0 controller (unless it is configured > > for OTG mode) does not have a way to detect when VBus is enabled/ > > disabled, other than by a connect/disconnect interrupt. > > yeah, there's no difference from the digital side of things. Most boards > I've seen use USB vbus comparators present on the PMIC. I guess what I was trying to say, is that if you have a DWC3 platform that uses a generic Phy, there is no way that I can see to detect when VBus is enabled/disabled. Aside from Connect/Disconnect, but I realise now the pullups would have to be enabled already to see a Connect, so that wouldn't work either. So any method that depends on detecting VBus would have to be optional, since not all platforms can support it. -- Paul -- 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] Revert "usb: chipidea: udc: .pullup is valid only when vbus is there"
On Wed, 13 Aug 2014, Paul Zimmerman wrote: > > > The UDC driver ought to know when Vbus turns on or off, without > > > polling. It should get an interrupt when that happens, or its > > > ops->vbus_session routine should be called. So at that time, the UDC > > > driver could invoke a new usb_gadget_driver callback. Let's also call > > > it vbus_session. > > > > > > Since composite.c defines a usb_gadget_driver structure, it can have a > > > composite_vbus_session() callback. When this routine is called, it > > > will check to see whether all the functions are activated. If they are > > > and Vbus is now on, it will call usb_gadget_connect(); otherwise it > > > will call usb_gadget_disconnect(). > > Is there a difference between a VBus on/off and a connect/disconnect? > Because AFAIK the Synopsys USB 3.0 controller (unless it is configured > for OTG mode) does not have a way to detect when VBus is enabled/ > disabled, other than by a connect/disconnect interrupt. That's an excellent point; it completely slipped my mind. So we already have all the callbacks we need. 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: [RFC PATCH] Revert "usb: chipidea: udc: .pullup is valid only when vbus is there"
> From: Alan Stern [mailto:st...@rowland.harvard.edu] > Sent: Wednesday, August 13, 2014 12:46 PM > > On Wed, 13 Aug 2014, Paul Zimmerman wrote: > > > > > The UDC driver ought to know when Vbus turns on or off, without > > > > polling. It should get an interrupt when that happens, or its > > > > ops->vbus_session routine should be called. So at that time, the UDC > > > > driver could invoke a new usb_gadget_driver callback. Let's also call > > > > it vbus_session. > > > > > > > > Since composite.c defines a usb_gadget_driver structure, it can have a > > > > composite_vbus_session() callback. When this routine is called, it > > > > will check to see whether all the functions are activated. If they are > > > > and Vbus is now on, it will call usb_gadget_connect(); otherwise it > > > > will call usb_gadget_disconnect(). > > > > Is there a difference between a VBus on/off and a connect/disconnect? > > Because AFAIK the Synopsys USB 3.0 controller (unless it is configured > > for OTG mode) does not have a way to detect when VBus is enabled/ > > disabled, other than by a connect/disconnect interrupt. > > That's an excellent point; it completely slipped my mind. So we > already have all the callbacks we need. No, that was a brain fart on my part. The DWC3 controller needs to have the pullups enabled before it can see a connect. Well, it's actually the host that won't see the device being connected until the pullups are enabled, but it amounts to the same thing, since the device needs to see some bus activity from the host before it asserts the ConnectDone interrupt. -- Paul -- 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] Revert "usb: chipidea: udc: .pullup is valid only when vbus is there"
On Wed, 13 Aug 2014, Paul Zimmerman wrote: > > > Is there a difference between a VBus on/off and a connect/disconnect? > > > Because AFAIK the Synopsys USB 3.0 controller (unless it is configured > > > for OTG mode) does not have a way to detect when VBus is enabled/ > > > disabled, other than by a connect/disconnect interrupt. > > > > That's an excellent point; it completely slipped my mind. So we > > already have all the callbacks we need. > > No, that was a brain fart on my part. The DWC3 controller needs to have > the pullups enabled before it can see a connect. Well, it's actually > the host that won't see the device being connected until the pullups > are enabled, but it amounts to the same thing, since the device needs > to see some bus activity from the host before it asserts the ConnectDone > interrupt. Then how can the DWC3 be USB-compliant? It can't see a connect unless the pullups are enabled, but enabling the pullups before Vbus is active violates the USB spec. Does the controller hardware have some special switch that prevents the pullup from engaging if Vbus is off? 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: Kernel 3.16.0 USB crash
On Wed, Aug 13, 2014 at 10:24 PM, Matt wrote: > Hi Claudio, > > this issue is clearly caused by UAS. > > if > > zcat /proc/config.gz | grep UAS > # CONFIG_USB_UAS is not set > > is de-selected, everything's fine > > when this is selected (usb is compiled as a module here) > > the system crashes or hardlocks as soon as an USB 3.0 capable drive is > connected. > > During bootup the system crashes as soon as the kernel module is loaded. > > This happened for me with 3.15.6 and 3.16.0 kernel (and 3.16-rc6). > > I've a different chipset but the symptoms are similar: > > 00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset > Family USB xHCI (rev 05) > > > So the only solution to work with newer kernels right now is to > de-select that option and re-compile the kernel. It doesn't help fix > the problem but at least it mitigates the issues for now (crash). > > > Regards > > Matt Adding some relevant CCs -- 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] Revert "usb: chipidea: udc: .pullup is valid only when vbus is there"
> From: Alan Stern [mailto:st...@rowland.harvard.edu] > Sent: Wednesday, August 13, 2014 2:09 PM > > On Wed, 13 Aug 2014, Paul Zimmerman wrote: > > > > > Is there a difference between a VBus on/off and a connect/disconnect? > > > > Because AFAIK the Synopsys USB 3.0 controller (unless it is configured > > > > for OTG mode) does not have a way to detect when VBus is enabled/ > > > > disabled, other than by a connect/disconnect interrupt. > > > > > > That's an excellent point; it completely slipped my mind. So we > > > already have all the callbacks we need. > > > > No, that was a brain fart on my part. The DWC3 controller needs to have > > the pullups enabled before it can see a connect. Well, it's actually > > the host that won't see the device being connected until the pullups > > are enabled, but it amounts to the same thing, since the device needs > > to see some bus activity from the host before it asserts the ConnectDone > > interrupt. > > Then how can the DWC3 be USB-compliant? It can't see a connect unless > the pullups are enabled, but enabling the pullups before Vbus is active > violates the USB spec. > > Does the controller hardware have some special switch that prevents the > pullup from engaging if Vbus is off? Either in the controller or in the Synopsys Phy, I'm not sure which. It seems like an obvious thing to be handled automatically by the hardware. We've never seen a failure on the USB-IF test suite as was mentioned earlier in the thread, and we have our device hardware recertified on a regular basis. -- Paul -- 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] Revert "usb: chipidea: udc: .pullup is valid only when vbus is there"
On Wed, Aug 13, 2014 at 09:41:17PM +, Paul Zimmerman wrote: > > From: Alan Stern [mailto:st...@rowland.harvard.edu] > > Sent: Wednesday, August 13, 2014 2:09 PM > > > > On Wed, 13 Aug 2014, Paul Zimmerman wrote: > > > > > > > Is there a difference between a VBus on/off and a connect/disconnect? > > > > > Because AFAIK the Synopsys USB 3.0 controller (unless it is configured > > > > > for OTG mode) does not have a way to detect when VBus is enabled/ > > > > > disabled, other than by a connect/disconnect interrupt. > > > > > > > > That's an excellent point; it completely slipped my mind. So we > > > > already have all the callbacks we need. > > > > > > No, that was a brain fart on my part. The DWC3 controller needs to have > > > the pullups enabled before it can see a connect. Well, it's actually > > > the host that won't see the device being connected until the pullups > > > are enabled, but it amounts to the same thing, since the device needs > > > to see some bus activity from the host before it asserts the ConnectDone > > > interrupt. > > > > Then how can the DWC3 be USB-compliant? It can't see a connect unless > > the pullups are enabled, but enabling the pullups before Vbus is active > > violates the USB spec. > > > > Does the controller hardware have some special switch that prevents the > > pullup from engaging if Vbus is off? > > Either in the controller or in the Synopsys Phy, I'm not sure which. It > seems like an obvious thing to be handled automatically by the hardware. > > We've never seen a failure on the USB-IF test suite as was mentioned > earlier in the thread, and we have our device hardware recertified on > a regular basis. using a mainline linux kernel or something entirely different ? It could be that this would only be apparent with a recent linux gadget framework. cheers -- balbi signature.asc Description: Digital signature
RE: [RFC PATCH] Revert "usb: chipidea: udc: .pullup is valid only when vbus is there"
> From: Felipe Balbi [mailto:ba...@ti.com] > Sent: Wednesday, August 13, 2014 3:25 PM > > On Wed, Aug 13, 2014 at 09:41:17PM +, Paul Zimmerman wrote: > > > From: Alan Stern [mailto:st...@rowland.harvard.edu] > > > Sent: Wednesday, August 13, 2014 2:09 PM > > > > > > On Wed, 13 Aug 2014, Paul Zimmerman wrote: > > > > > > > > > Is there a difference between a VBus on/off and a > > > > > > connect/disconnect? > > > > > > Because AFAIK the Synopsys USB 3.0 controller (unless it is > > > > > > configured > > > > > > for OTG mode) does not have a way to detect when VBus is enabled/ > > > > > > disabled, other than by a connect/disconnect interrupt. > > > > > > > > > > That's an excellent point; it completely slipped my mind. So we > > > > > already have all the callbacks we need. > > > > > > > > No, that was a brain fart on my part. The DWC3 controller needs to have > > > > the pullups enabled before it can see a connect. Well, it's actually > > > > the host that won't see the device being connected until the pullups > > > > are enabled, but it amounts to the same thing, since the device needs > > > > to see some bus activity from the host before it asserts the ConnectDone > > > > interrupt. > > > > > > Then how can the DWC3 be USB-compliant? It can't see a connect unless > > > the pullups are enabled, but enabling the pullups before Vbus is active > > > violates the USB spec. > > > > > > Does the controller hardware have some special switch that prevents the > > > pullup from engaging if Vbus is off? > > > > Either in the controller or in the Synopsys Phy, I'm not sure which. It > > seems like an obvious thing to be handled automatically by the hardware. > > > > We've never seen a failure on the USB-IF test suite as was mentioned > > earlier in the thread, and we have our device hardware recertified on > > a regular basis. > > using a mainline linux kernel or something entirely different ? It could > be that this would only be apparent with a recent linux gadget > framework. Using a mainline kernel, but with our vendor driver instead of DWC3. Our vendor driver enables run/stop as soon as the driver loads, and never touches it again. So the pullups are always enabled from the software point of view. This thread seems to have wandered pretty far off-topic. I just wanted to make the point that if you create another API function for this issue, please be aware that not all controllers/phys will need it or be able to support it. In fact, I think this issue is specific to the chipidea core, so maybe it just needs a quirk or something? -- Paul -- 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] Revert "usb: chipidea: udc: .pullup is valid only when vbus is there"
On Wed, Aug 13, 2014 at 09:41:17PM +, Paul Zimmerman wrote: > > From: Alan Stern [mailto:st...@rowland.harvard.edu] > > Sent: Wednesday, August 13, 2014 2:09 PM > > > > On Wed, 13 Aug 2014, Paul Zimmerman wrote: > > > > > > > Is there a difference between a VBus on/off and a connect/disconnect? > > > > > Because AFAIK the Synopsys USB 3.0 controller (unless it is configured > > > > > for OTG mode) does not have a way to detect when VBus is enabled/ > > > > > disabled, other than by a connect/disconnect interrupt. > > > > > > > > That's an excellent point; it completely slipped my mind. So we > > > > already have all the callbacks we need. > > > > > > No, that was a brain fart on my part. The DWC3 controller needs to have > > > the pullups enabled before it can see a connect. Well, it's actually > > > the host that won't see the device being connected until the pullups > > > are enabled, but it amounts to the same thing, since the device needs > > > to see some bus activity from the host before it asserts the ConnectDone > > > interrupt. > > > > Then how can the DWC3 be USB-compliant? It can't see a connect unless > > the pullups are enabled, but enabling the pullups before Vbus is active > > violates the USB spec. > > > > Does the controller hardware have some special switch that prevents the > > pullup from engaging if Vbus is off? > > Either in the controller or in the Synopsys Phy, I'm not sure which. It > seems like an obvious thing to be handled automatically by the hardware. > > We've never seen a failure on the USB-IF test suite as was mentioned > earlier in the thread, and we have our device hardware recertified on > a regular basis. > What's voltage for dwc3 platfrom's dp before connecting to host? If you connect a usb cable with host (using another board), but the host does not supply vbus, will you see a CONNECT? If the host power off vbus, but the usb cable does not disconnect, will you see DISCONNECT? I assume you will only see CONNECT if vbus is there, and DISCONNECT if vbus is off when the cable is connected , the physical dp pullup should need vbus. Please correct me if my assumption is wrong. When talking about Alan's suggestion, for the platform like dwc3 which doesn't need to know vbus, it can set .vbus_active at usb_gadget_driver as true at udc_start unconditionally. -- 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
What is the command line commands to use UAC2 at USB client side?
Hi Community, Based on Freescale platform , I am trying to use USB Audio Class version 2.0. Host can detect this UAC2 device. At device side (after modprobe g_audio): root@imx6slevk:~# aplay -l List of PLAYBACK Hardware Devices card 0: wm8962audio [wm8962-audio], device 0: HiFi wm8962-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: imxspdif [imx-spdif], device 0: S/PDIF PCM Playback dit-hifi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: UAC2Gadget [UAC2_Gadget], device 0: UAC2 PCM [UAC2 PCM] Subdevices: 1/1 Subdevice #0: subdevice #0 At device side, in driver/usb/gadget/Kconfig, it says before for CONFIG_USB_AUDIO - This driver doesn't expect any real Audio codec to be present on the device - the audio streams are simply sinked to and sourced from a virtual ALSA sound card created. The user-space application may choose to do whatever it wants with the data received from the USB Host and choose to provide whatever it wants as audio data to the USB Host. - My question is: at device side, how to configure sink/source for UAC2 virtual ALSA sound card (hw:2,0, UAC2_Gadget)? Thank you very much. Xuebing Wang -- 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: What is the command line commands to use UAC2 at USB client side?
On Thu, Aug 14, 2014 at 12:05 PM, Xuebing Wang wrote: > Hi Community, > > Based on Freescale platform , I am trying to use USB Audio Class version > 2.0. Host can detect this UAC2 device. > > At device side (after modprobe g_audio): > > root@imx6slevk:~# aplay -l > List of PLAYBACK Hardware Devices > card 0: wm8962audio [wm8962-audio], device 0: HiFi wm8962-0 [] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > card 1: imxspdif [imx-spdif], device 0: S/PDIF PCM Playback dit-hifi-0 [] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > card 2: UAC2Gadget [UAC2_Gadget], device 0: UAC2 PCM [UAC2 PCM] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > > At device side, in driver/usb/gadget/Kconfig, it says before for > CONFIG_USB_AUDIO > - > This driver doesn't expect any real Audio codec to be present > on the device - the audio streams are simply sinked to and > sourced from a virtual ALSA sound card created. The user-space > application may choose to do whatever it wants with the data > received from the USB Host and choose to provide whatever it > wants as audio data to the USB Host. > - > > My question is: at device side, how to configure sink/source for UAC2 > virtual ALSA sound card (hw:2,0, UAC2_Gadget)? > At OS level, select the UAC2 card like any other - Control Panel -> Sound settings. You want to select the same Card on Host as well as Gadget side. -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
