RE: [RFC] usb: gadget: Ensure correct functionality for gadgets that wish to 'connect' only when directed by user-space
Hi,
> -Original Message-
> From: Bhupesh SHARMA
> Sent: Wednesday, June 27, 2012 9:08 AM
> To: ba...@ti.com; linux-usb@vger.kernel.org
> Cc: gre...@linuxfoundation.org; laurent.pinch...@ideasonboard.com
> Subject: [RFC] usb: gadget: Ensure correct functionality for gadgets
> that wish to 'connect' only when directed by user-space
>
> Hi Felipe, All,
>
> While working with the webcam gadget in recent past I came to realize
> that if the webcam gadget
> is compiled as a static part of the kernel, the USB webcam device when
> connected to the USB
> host will not successfully enumerate (as the USB host will send a
> GET_DEF class specific UVC
> request), which is handled by a user-space application responsible for
> ensuring command/data
> flow between the UVC gadget and a real V4L2 device.
>
> I believe similar will be the case for other gadgets like obex while
> working with an underlying
> UDC during the start-up phase (during the enumeration process).
>
> Gadgets like webcam/obex explicitly call the 'pullup' routine of the
> underlying
> UDC (with is_on argument set to 0) to issue soft-disconnect command at
> the very start. This is
> done to prevent the enumeration process to proceed unless a supporting
> user-space application
> is first up and running (which can handle the class-specific control
> requests on the basis of
> certain negotiations with other entities, like for e.g. a real video
> device in case of webcam).
> (see [1] for reference).
>
> However with the current framework (newstyle UDC) just after the 'bind'
> of the
> function (f_uvc/f_obex) is called, the UDC framework calls the 'pullup'
> routine of the
> UDC again with a parameter is_on set to 1 to initiate connection with
> the Host.
> (see [2] for reference).
>
> This seems to be an incorrect implementation as it causes the
> enumeration to
> start even for gadgets like webcam/obex which have explicitly requested
> only a soft-connect (as the user-space application has not been
> launched yet).
>
> Please let me know your ideas on the same.
> At the moment I have used a temporary approach like the one given below
> (though it is in
> no way a very good way out :) ).
>
>
> [1] http://lxr.linux.no/linux+v3.4.4/drivers/usb/gadget/f_uvc.c#L548
> [2] http://lxr.linux.no/linux+v3.4.4/drivers/usb/gadget/udc-core.c#L341
>
>
> Signed-off-by: Bhupesh Sharma
> ---
> drivers/usb/dwc3/core.h |1 +
> drivers/usb/dwc3/gadget.c | 24 ++--
> drivers/usb/gadget/udc-core.c | 19 ++-
> include/linux/usb/gadget.h|1 +
> 4 files changed, 38 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index 2d8676c..9125ec9 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -712,6 +712,7 @@ struct dwc3 {
> struct dwc3_hwparamshwparams;
> struct dentry *root;
> + booldeactivated_at_start;
>
> u8 test_mode;
> u8 test_mode_nr;
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index b82fe61..0d6ea17 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -1341,6 +1341,12 @@ static const struct usb_ep_ops
> dwc3_gadget_ep_ops = {
> };
>
> /* ---
> --- */
> +static bool dwc3_gadget_is_deactivated_at_start(struct usb_gadget *g)
> +{
> + struct dwc3 *dwc = gadget_to_dwc(g);
> +
> + return dwc->deactivated_at_start;
> +}
>
> static int dwc3_gadget_get_frame(struct usb_gadget *g)
> {
> @@ -1448,6 +1454,7 @@ static void dwc3_gadget_run_stop(struct dwc3
> *dwc, int is_on)
> {
> u32 reg;
> u32 timeout = 500;
> + static bool first_deactivation;
>
> reg = dwc3_readl(dwc->regs, DWC3_DCTL);
> if (is_on) {
> @@ -1461,6 +1468,10 @@ static void dwc3_gadget_run_stop(struct dwc3
> *dwc, int is_on)
> reg |= DWC3_DCTL_RUN_STOP;
> } else {
> reg &= ~DWC3_DCTL_RUN_STOP;
> + if (first_deactivation == false) {
> + dwc->deactivated_at_start = true;
> + first_deactivation = true;
> + }
> }
>
> dwc3_writel(dwc->regs, DWC3_DCTL, reg);
> @@ -1600,12 +1611,13 @@ static int dwc3_gadget_stop(struct usb_gadget
> *g,
> }
>
> static const struct usb_gadget_ops dwc3_gadget_ops = {
> - .get_frame = dwc3_gadget_get_frame,
> - .wakeup = dwc3_gadget_wakeup,
> - .set_selfpowered= dwc3_gadget_set_selfpowered,
> - .pullup = dwc3_gadget_pullup,
> - .udc_start = dwc3_gadget_start,
> - .udc_stop = dwc3_gadget_stop,
> + .is_deactivated_at_start=
> dwc3_gadget_is_deactivated_at_start,
> + .get_frame
Re: [PATCH] USB: musb: NAK timeout scheme on bulk TX endpoint
Hi, On Thu, Jul 19, 2012 at 01:41:59PM +0530, Ajay Kumar Gupta wrote: > Fixes endpoint starvation issue when more than one bulk QH is > multiplexed on the reserved bulk TX endpoint. > > This patch sets the NAK timeout interval for such QHs, and when > a timeout triggers the next QH will be scheduled. > > This scheme doesn't work for devices which are connected to a > high to full speed tree (transaction translator) as there is > no NAK timeout interrupt from the musb controller from such > devices. > > Signed-off-by: Ajay Kumar Gupta Are you saying this patch will break full speed devices when we have a HS hub in between ? If that's the case I cannot take this patch... -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 01/11] usb: musb: add musb->id to identify core instance
Hi,
On Thu, Jul 19, 2012 at 05:15:57PM +0530, Ajay Kumar Gupta wrote:
> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
> index 89d1871..3e09984 100644
> --- a/drivers/usb/musb/musb_core.c
> +++ b/drivers/usb/musb/musb_core.c
> @@ -99,6 +99,7 @@
> #include
> #include
> #include
> +#include
>
> #include "musb_core.h"
>
> @@ -114,6 +115,7 @@
>
> #define MUSB_DRIVER_NAME "musb-hdrc"
> const char musb_driver_name[] = MUSB_DRIVER_NAME;
> +static DEFINE_IDA(musb_ida);
>
> MODULE_DESCRIPTION(DRIVER_INFO);
> MODULE_AUTHOR(DRIVER_AUTHOR);
> @@ -130,6 +132,33 @@ static inline struct musb *dev_to_musb(struct device
> *dev)
>
> /*-*/
>
> +int musb_get_id(struct device *dev, gfp_t gfp_mask)
> +{
> + int ret;
> + int id;
> +
> + ret = ida_pre_get(&musb_ida, gfp_mask);
> + if (!ret) {
> + dev_err(dev, "failed to reserve resource for id\n");
> + return -ENOMEM;
> + }
> +
> + ret = ida_get_new(&musb_ida, &id);
> + if (ret < 0) {
> + dev_err(dev, "failed to allocate a new id\n");
> + return ret;
> + }
> +
> + return id;
> +}
> +
> +void musb_put_id(struct device *dev, int id)
> +{
> +
> + dev_dbg(dev, "removing id %d\n", id);
> + ida_remove(&musb_ida, id);
> +}
both of these should be EXPORT_SYMBOL_GPL() for cases when musb and glue
are compiled as modules.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v4 02/11] usb: musb: kill global and static for multi instance
Hi,
On Thu, Jul 19, 2012 at 05:15:58PM +0530, Ajay Kumar Gupta wrote:
> Moved global variable "musb_debugfs_root" and static variable
> "old_state" to 'struct musb' to help support multi instance of
> musb controller as present on AM335x platform.
>
> Also removed the global variable "orig_dma_mask" and filled the
> dev->dma_mask with parent device's dma_mask.
>
> Signed-off-by: Ajay Kumar Gupta
> ---
> drivers/usb/musb/musb_core.c| 16 +++-
> drivers/usb/musb/musb_core.h|4
> drivers/usb/musb/musb_debugfs.c | 14 --
> 3 files changed, 15 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
> index 3e09984..a5db4dd 100644
> --- a/drivers/usb/musb/musb_core.c
> +++ b/drivers/usb/musb/musb_core.c
> @@ -1802,10 +1802,9 @@ static const struct attribute_group musb_attr_group = {
> static void musb_irq_work(struct work_struct *data)
> {
> struct musb *musb = container_of(data, struct musb, irq_work);
> - static int old_state;
>
> - if (musb->xceiv->state != old_state) {
> - old_state = musb->xceiv->state;
> + if (musb->xceiv->state != musb->xceiv_old_state) {
> + musb->xceiv_old_state = musb->xceiv->state;
> sysfs_notify(&musb->controller->kobj, NULL, "mode");
> }
> }
> @@ -2115,11 +2114,6 @@ fail0:
> /* all implementations (PCI bridge to FPGA, VLYNQ, etc) should just
> * bridge to a platform device; this driver then suffices.
> */
> -
> -#ifndef CONFIG_MUSB_PIO_ONLY
> -static u64 *orig_dma_mask;
> -#endif
> -
> static int __devinit musb_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> @@ -2138,10 +2132,6 @@ static int __devinit musb_probe(struct platform_device
> *pdev)
> return -ENOMEM;
> }
>
> -#ifndef CONFIG_MUSB_PIO_ONLY
> - /* clobbered by use_dma=n */
> - orig_dma_mask = dev->dma_mask;
> -#endif
> status = musb_init_controller(dev, irq, base);
> if (status < 0)
> iounmap(base);
> @@ -2166,7 +2156,7 @@ static int __devexit musb_remove(struct platform_device
> *pdev)
> iounmap(ctrl_base);
> device_init_wakeup(&pdev->dev, 0);
> #ifndef CONFIG_MUSB_PIO_ONLY
> - pdev->dev.dma_mask = orig_dma_mask;
> + pdev->dev.dma_mask = (&dev->dev.parent)->dma_mask;
are you sure ?? This should be:
dev->parent.dma_mask;
In fact, while doing that you could use dma_set_mask() instead ;-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] omap: usb: host: remove deprecated flag 'es2_compatibility'
Hi,
On Tue, Jul 24, 2012 at 09:08:40PM +0300, Ruslan Bilovol wrote:
> Currently this flag is not used anywhere and may be safely removed.
>
> Signed-off-by: Ruslan Bilovol
looks good to me. Keshava ?
> ---
> arch/arm/mach-omap2/usb-host.c|1 -
> arch/arm/plat-omap/include/plat/usb.h |4
> 2 files changed, 0 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
> index dde8a11..5e1cb53 100644
> --- a/arch/arm/mach-omap2/usb-host.c
> +++ b/arch/arm/mach-omap2/usb-host.c
> @@ -500,7 +500,6 @@ void __init usbhs_init(const struct usbhs_omap_board_data
> *pdata)
> ehci_data.regulator[i] = pdata->regulator[i];
> }
> ehci_data.phy_reset = pdata->phy_reset;
> - ohci_data.es2_compatibility = pdata->es2_compatibility;
> usbhs_data.ehci_data = &ehci_data;
> usbhs_data.ohci_data = &ohci_data;
>
> diff --git a/arch/arm/plat-omap/include/plat/usb.h
> b/arch/arm/plat-omap/include/plat/usb.h
> index 762eeb0..f8c1eb8 100644
> --- a/arch/arm/plat-omap/include/plat/usb.h
> +++ b/arch/arm/plat-omap/include/plat/usb.h
> @@ -32,9 +32,6 @@ struct usbhs_omap_board_data {
> /* have to be valid if phy_reset is true and portx is in phy mode */
> int reset_gpio_port[OMAP3_HS_USB_PORTS];
>
> - /* Set this to true for ES2.x silicon */
> - unsignedes2_compatibility:1;
> -
> unsignedphy_reset:1;
>
> /*
> @@ -53,7 +50,6 @@ struct ehci_hcd_omap_platform_data {
>
> struct ohci_hcd_omap_platform_data {
> enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS];
> - unsignedes2_compatibility:1;
> };
>
> struct usbhs_omap_platform_data {
> --
> 1.7.1
>
--
balbi
signature.asc
Description: Digital signature
the dreaded "needs XHCI_TRUST_TX_LENGTH quirk" returns
Hello Sarah et. al, I am attempting to use an Inland brand USB 3.0 multi-purpose Memory Card reader, which I purchased from Micro Center, along with a Patriot EP Series SDXC UHS-1 64 GB memory card, which I purchased from Fry's. I am connecting these to my Debian unstable system running Linux 3.4.6 kernel self-compiled. I am getting the dreaded "xhci_hcd :03:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?" looping infinitely into my dmesg buffer. I saw this discussed on July 2nd and 3rd in a thread Sarah cross-posted onto linux-usb which originated from Gary Miller's bug report to her privately. http://marc.info/?l=linux-usb&m=134125692925503 I pre-apologize to Alan in advance if I have butchered the USB terminology as he pointed out in the earlier thread. ;-) Card Reader Specs: http://www.microcenter.com/single_product_results.phtml?product_id=0371800 I read through all of the messages in this original thread and collected all of the various troubleshooting items requested, while the USB and XHCI debug were enabled: 1) the configuration of my self-compiled Linux 3.4.6 kernel, and dmesg from booting the system 2) lspci -vvv and lspci -vvv -n 3) dmesg and lsusb -v from plugging the reader into the SuperSpeed (3.0) port 4) dmesg and lsusb -v from plugging the reader into the HighSpeed (2.0) port I placed all of these here: http://www.mhcomputing.net/tmp/xhci-bug/ I would really like to fix whatever is causing this, as it's not very good for performance, stability, and reliability if something is putting this tremendously many printk's into the ring constantly. It's liable to cause some kind of crash or corrupt the data going to and from the SDXC card. I would also politely suggest that each USB device should only squawk about this problem once per insertion rather than repeatedly, to avoid making things go haywire in the kernel with all these tight-looped printk's. So, is there anything else which is needed to clear up the problem in my environment or is this enough data as-is? I never saw a clear answer if Gary Miller's problem got fixed or not. Hopefully Gary could provide some clarification what happened to his issue over the long haul. Regards, Matthew. -- 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: musb: NAK timeout scheme on bulk TX endpoint
Hi, > On Thu, Jul 19, 2012 at 01:41:59PM +0530, Ajay Kumar Gupta wrote: > > Fixes endpoint starvation issue when more than one bulk QH is > > multiplexed on the reserved bulk TX endpoint. > > > > This patch sets the NAK timeout interval for such QHs, and when > > a timeout triggers the next QH will be scheduled. > > > > This scheme doesn't work for devices which are connected to a > > high to full speed tree (transaction translator) as there is > > no NAK timeout interrupt from the musb controller from such > > devices. > > > > Signed-off-by: Ajay Kumar Gupta > > Are you saying this patch will break full speed devices when we have a > HS hub in between ? If that's the case I cannot take this patch... This only says that this NAK timeout scheme will not work in such cases and so will continue to work the way it is currently available. Which means IN tokens being sent continuously to a NAKing device. Ajay > > -- > 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: [PATCH v4 01/11] usb: musb: add musb->id to identify core instance
Hi,
> On Thu, Jul 19, 2012 at 05:15:57PM +0530, Ajay Kumar Gupta wrote:
> > diff --git a/drivers/usb/musb/musb_core.c
> > b/drivers/usb/musb/musb_core.c index 89d1871..3e09984 100644
> > --- a/drivers/usb/musb/musb_core.c
> > +++ b/drivers/usb/musb/musb_core.c
> > @@ -99,6 +99,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "musb_core.h"
> >
> > @@ -114,6 +115,7 @@
> >
> > #define MUSB_DRIVER_NAME "musb-hdrc"
> > const char musb_driver_name[] = MUSB_DRIVER_NAME;
> > +static DEFINE_IDA(musb_ida);
> >
> > MODULE_DESCRIPTION(DRIVER_INFO);
> > MODULE_AUTHOR(DRIVER_AUTHOR);
> > @@ -130,6 +132,33 @@ static inline struct musb *dev_to_musb(struct
> > device *dev)
> >
> >
> > /*
> > -*/
> >
> > +int musb_get_id(struct device *dev, gfp_t gfp_mask) {
> > + int ret;
> > + int id;
> > +
> > + ret = ida_pre_get(&musb_ida, gfp_mask);
> > + if (!ret) {
> > + dev_err(dev, "failed to reserve resource for id\n");
> > + return -ENOMEM;
> > + }
> > +
> > + ret = ida_get_new(&musb_ida, &id);
> > + if (ret < 0) {
> > + dev_err(dev, "failed to allocate a new id\n");
> > + return ret;
> > + }
> > +
> > + return id;
> > +}
> > +
> > +void musb_put_id(struct device *dev, int id) {
> > +
> > + dev_dbg(dev, "removing id %d\n", id);
> > + ida_remove(&musb_ida, id);
> > +}
>
> both of these should be EXPORT_SYMBOL_GPL() for cases when musb and glue are
> compiled as modules.
Sure. I will fix this.
Ajay
>
> --
> 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: [PATCH v4 02/11] usb: musb: kill global and static for multi instance
Hi,
>
> On Thu, Jul 19, 2012 at 05:15:58PM +0530, Ajay Kumar Gupta wrote:
> > Moved global variable "musb_debugfs_root" and static variable
> > "old_state" to 'struct musb' to help support multi instance of musb
> > controller as present on AM335x platform.
> >
> > Also removed the global variable "orig_dma_mask" and filled the
> > dev->dma_mask with parent device's dma_mask.
> >
> > Signed-off-by: Ajay Kumar Gupta
> > ---
> > drivers/usb/musb/musb_core.c| 16 +++-
> > drivers/usb/musb/musb_core.h|4
> > drivers/usb/musb/musb_debugfs.c | 14 --
> > 3 files changed, 15 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/usb/musb/musb_core.c
> > b/drivers/usb/musb/musb_core.c index 3e09984..a5db4dd 100644
> > --- a/drivers/usb/musb/musb_core.c
> > +++ b/drivers/usb/musb/musb_core.c
> > @@ -1802,10 +1802,9 @@ static const struct attribute_group
> > musb_attr_group = { static void musb_irq_work(struct work_struct
> > *data) {
> > struct musb *musb = container_of(data, struct musb, irq_work);
> > - static int old_state;
> >
> > - if (musb->xceiv->state != old_state) {
> > - old_state = musb->xceiv->state;
> > + if (musb->xceiv->state != musb->xceiv_old_state) {
> > + musb->xceiv_old_state = musb->xceiv->state;
> > sysfs_notify(&musb->controller->kobj, NULL, "mode");
> > }
> > }
> > @@ -2115,11 +2114,6 @@ fail0:
> > /* all implementations (PCI bridge to FPGA, VLYNQ, etc) should just
> > * bridge to a platform device; this driver then suffices.
> > */
> > -
> > -#ifndef CONFIG_MUSB_PIO_ONLY
> > -static u64 *orig_dma_mask;
> > -#endif
> > -
> > static int __devinit musb_probe(struct platform_device *pdev) {
> > struct device *dev = &pdev->dev;
> > @@ -2138,10 +2132,6 @@ static int __devinit musb_probe(struct
> platform_device *pdev)
> > return -ENOMEM;
> > }
> >
> > -#ifndef CONFIG_MUSB_PIO_ONLY
> > - /* clobbered by use_dma=n */
> > - orig_dma_mask = dev->dma_mask;
> > -#endif
> > status = musb_init_controller(dev, irq, base);
> > if (status < 0)
> > iounmap(base);
> > @@ -2166,7 +2156,7 @@ static int __devexit musb_remove(struct
> platform_device *pdev)
> > iounmap(ctrl_base);
> > device_init_wakeup(&pdev->dev, 0);
> > #ifndef CONFIG_MUSB_PIO_ONLY
> > - pdev->dev.dma_mask = orig_dma_mask;
> > + pdev->dev.dma_mask = (&dev->dev.parent)->dma_mask;
>
> are you sure ?? This should be:
>
> dev->parent.dma_mask;
Actually both are fine and I used parent based on your recommendation
in my earlier version of patch at
http://marc.info/?l=linux-usb&m=134121391908734&w=2
anyways I will change to :
pdev->dev.dma_mask = dma_set_mask((&pdev->dev, DMA_BIT_MASK(64));
Ajay
>
> In fact, while doing that you could use dma_set_mask() instead ;-)
>
> --
> 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: [PATCH] USB: musb: NAK timeout scheme on bulk TX endpoint
Hi, > > On Thu, Jul 19, 2012 at 01:41:59PM +0530, Ajay Kumar Gupta wrote: > > > Fixes endpoint starvation issue when more than one bulk QH is > > > multiplexed on the reserved bulk TX endpoint. > > > > > > This patch sets the NAK timeout interval for such QHs, and when > > > a timeout triggers the next QH will be scheduled. > > > > > > This scheme doesn't work for devices which are connected to a > > > high to full speed tree (transaction translator) as there is > > > no NAK timeout interrupt from the musb controller from such > > > devices. > > > > > > Signed-off-by: Ajay Kumar Gupta > > > > Are you saying this patch will break full speed devices when we have a > > HS hub in between ? If that's the case I cannot take this patch... > > This only says that this NAK timeout scheme will not work in such cases > and so will continue to work the way it is currently available. Which means > IN tokens being sent continuously to a NAKing device. and for OUT case, PING token being sent to a NAKing device and we not able to use NAK timeout scheme to use the hardware endpoint resource for other devices. Ajay > > Ajay > > > > -- > > 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 -- 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 02/11] usb: musb: kill global and static for multi instance
On Wed, Jul 25, 2012 at 10:34:49AM +, Gupta, Ajay Kumar wrote:
> Hi,
> >
> > On Thu, Jul 19, 2012 at 05:15:58PM +0530, Ajay Kumar Gupta wrote:
> > > Moved global variable "musb_debugfs_root" and static variable
> > > "old_state" to 'struct musb' to help support multi instance of musb
> > > controller as present on AM335x platform.
> > >
> > > Also removed the global variable "orig_dma_mask" and filled the
> > > dev->dma_mask with parent device's dma_mask.
> > >
> > > Signed-off-by: Ajay Kumar Gupta
> > > ---
> > > drivers/usb/musb/musb_core.c| 16 +++-
> > > drivers/usb/musb/musb_core.h|4
> > > drivers/usb/musb/musb_debugfs.c | 14 --
> > > 3 files changed, 15 insertions(+), 19 deletions(-)
> > >
> > > diff --git a/drivers/usb/musb/musb_core.c
> > > b/drivers/usb/musb/musb_core.c index 3e09984..a5db4dd 100644
> > > --- a/drivers/usb/musb/musb_core.c
> > > +++ b/drivers/usb/musb/musb_core.c
> > > @@ -1802,10 +1802,9 @@ static const struct attribute_group
> > > musb_attr_group = { static void musb_irq_work(struct work_struct
> > > *data) {
> > > struct musb *musb = container_of(data, struct musb, irq_work);
> > > - static int old_state;
> > >
> > > - if (musb->xceiv->state != old_state) {
> > > - old_state = musb->xceiv->state;
> > > + if (musb->xceiv->state != musb->xceiv_old_state) {
> > > + musb->xceiv_old_state = musb->xceiv->state;
> > > sysfs_notify(&musb->controller->kobj, NULL, "mode");
> > > }
> > > }
> > > @@ -2115,11 +2114,6 @@ fail0:
> > > /* all implementations (PCI bridge to FPGA, VLYNQ, etc) should just
> > > * bridge to a platform device; this driver then suffices.
> > > */
> > > -
> > > -#ifndef CONFIG_MUSB_PIO_ONLY
> > > -static u64 *orig_dma_mask;
> > > -#endif
> > > -
> > > static int __devinit musb_probe(struct platform_device *pdev) {
> > > struct device *dev = &pdev->dev;
> > > @@ -2138,10 +2132,6 @@ static int __devinit musb_probe(struct
> > platform_device *pdev)
> > > return -ENOMEM;
> > > }
> > >
> > > -#ifndef CONFIG_MUSB_PIO_ONLY
> > > - /* clobbered by use_dma=n */
> > > - orig_dma_mask = dev->dma_mask;
> > > -#endif
> > > status = musb_init_controller(dev, irq, base);
> > > if (status < 0)
> > > iounmap(base);
> > > @@ -2166,7 +2156,7 @@ static int __devexit musb_remove(struct
> > platform_device *pdev)
> > > iounmap(ctrl_base);
> > > device_init_wakeup(&pdev->dev, 0);
> > > #ifndef CONFIG_MUSB_PIO_ONLY
> > > - pdev->dev.dma_mask = orig_dma_mask;
> > > + pdev->dev.dma_mask = (&dev->dev.parent)->dma_mask;
> >
> > are you sure ?? This should be:
> >
> > dev->parent.dma_mask;
>
> Actually both are fine and I used parent based on your recommendation
> in my earlier version of patch at
> http://marc.info/?l=linux-usb&m=134121391908734&w=2
>
> anyways I will change to :
> pdev->dev.dma_mask = dma_set_mask((&pdev->dev, DMA_BIT_MASK(64));
no Ajay, you misunderstood... I don't see how this patch would compile.
the variable named "dev" is already a pointer to a struct device, and
struct device doesn't have a "dev" field.
what I asked to do while doing that is:
dev_set_mask(dev, *dev->parent->dma_mask);
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] USB: musb: NAK timeout scheme on bulk TX endpoint
On Wed, Jul 25, 2012 at 10:38:59AM +, Gupta, Ajay Kumar wrote: > Hi, > > > On Thu, Jul 19, 2012 at 01:41:59PM +0530, Ajay Kumar Gupta wrote: > > > > Fixes endpoint starvation issue when more than one bulk QH is > > > > multiplexed on the reserved bulk TX endpoint. > > > > > > > > This patch sets the NAK timeout interval for such QHs, and when > > > > a timeout triggers the next QH will be scheduled. > > > > > > > > This scheme doesn't work for devices which are connected to a > > > > high to full speed tree (transaction translator) as there is > > > > no NAK timeout interrupt from the musb controller from such > > > > devices. > > > > > > > > Signed-off-by: Ajay Kumar Gupta > > > > > > Are you saying this patch will break full speed devices when we have a > > > HS hub in between ? If that's the case I cannot take this patch... > > > > This only says that this NAK timeout scheme will not work in such cases > > and so will continue to work the way it is currently available. Which means > > IN tokens being sent continuously to a NAKing device. > > and for OUT case, PING token being sent to a NAKing device and we not able > to use NAK timeout scheme to use the hardware endpoint resource for other > devices. Ok, I misunderstood the commit log. Thought you were saying there would be a regression. Nevermind. -- balbi signature.asc Description: Digital signature
RE: [PATCH v4 02/11] usb: musb: kill global and static for multi instance
Hi,
> On Wed, Jul 25, 2012 at 10:34:49AM +, Gupta, Ajay Kumar wrote:
> > Hi,
> > >
> > > On Thu, Jul 19, 2012 at 05:15:58PM +0530, Ajay Kumar Gupta wrote:
> > > > Moved global variable "musb_debugfs_root" and static variable
> > > > "old_state" to 'struct musb' to help support multi instance of
> > > > musb controller as present on AM335x platform.
> > > >
> > > > Also removed the global variable "orig_dma_mask" and filled the
> > > > dev->dma_mask with parent device's dma_mask.
> > > >
> > > > Signed-off-by: Ajay Kumar Gupta
> > > > ---
> > > > drivers/usb/musb/musb_core.c| 16 +++-
> > > > drivers/usb/musb/musb_core.h|4
> > > > drivers/usb/musb/musb_debugfs.c | 14 --
> > > > 3 files changed, 15 insertions(+), 19 deletions(-)
> > > >
> > > > diff --git a/drivers/usb/musb/musb_core.c
> > > > b/drivers/usb/musb/musb_core.c index 3e09984..a5db4dd 100644
> > > > --- a/drivers/usb/musb/musb_core.c
> > > > +++ b/drivers/usb/musb/musb_core.c
> > > > @@ -1802,10 +1802,9 @@ static const struct attribute_group
> > > > musb_attr_group = { static void musb_irq_work(struct work_struct
> > > > *data) {
> > > > struct musb *musb = container_of(data, struct musb, irq_work);
> > > > - static int old_state;
> > > >
> > > > - if (musb->xceiv->state != old_state) {
> > > > - old_state = musb->xceiv->state;
> > > > + if (musb->xceiv->state != musb->xceiv_old_state) {
> > > > + musb->xceiv_old_state = musb->xceiv->state;
> > > > sysfs_notify(&musb->controller->kobj, NULL, "mode");
> > > > }
> > > > }
> > > > @@ -2115,11 +2114,6 @@ fail0:
> > > > /* all implementations (PCI bridge to FPGA, VLYNQ, etc) should just
> > > > * bridge to a platform device; this driver then suffices.
> > > > */
> > > > -
> > > > -#ifndef CONFIG_MUSB_PIO_ONLY
> > > > -static u64 *orig_dma_mask;
> > > > -#endif
> > > > -
> > > > static int __devinit musb_probe(struct platform_device *pdev) {
> > > > struct device *dev = &pdev->dev;
> > > > @@ -2138,10 +2132,6 @@ static int __devinit musb_probe(struct
> > > platform_device *pdev)
> > > > return -ENOMEM;
> > > > }
> > > >
> > > > -#ifndef CONFIG_MUSB_PIO_ONLY
> > > > - /* clobbered by use_dma=n */
> > > > - orig_dma_mask = dev->dma_mask;
> > > > -#endif
> > > > status = musb_init_controller(dev, irq, base);
> > > > if (status < 0)
> > > > iounmap(base);
> > > > @@ -2166,7 +2156,7 @@ static int __devexit musb_remove(struct
> > > platform_device *pdev)
> > > > iounmap(ctrl_base);
> > > > device_init_wakeup(&pdev->dev, 0); #ifndef
> CONFIG_MUSB_PIO_ONLY
> > > > - pdev->dev.dma_mask = orig_dma_mask;
> > > > + pdev->dev.dma_mask = (&dev->dev.parent)->dma_mask;
> > >
> > > are you sure ?? This should be:
> > >
> > > dev->parent.dma_mask;
> >
> > Actually both are fine and I used parent based on your recommendation
> > in my earlier version of patch at
> > http://marc.info/?l=linux-usb&m=134121391908734&w=2
> >
> > anyways I will change to :
> > pdev->dev.dma_mask = dma_set_mask((&pdev->dev, DMA_BIT_MASK(64));
>
> no Ajay, you misunderstood... I don't see how this patch would compile.
It was my bad. I am testing it with PIO mode only and so code was not compiled.
"dev" was actually a "pdev".
> the variable named "dev" is already a pointer to a struct device, and struct
> device doesn't have a "dev" field.
>
> what I asked to do while doing that is:
>
> dev_set_mask(dev, *dev->parent->dma_mask);
Sure.
Thanks.
>
> --
> 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 v2] usb: dwc3: Introduce OTG driver for dwc3
Hi Anton,
On Tue, July 17, 2012 9:27 pm, Anton Tikhomirov wrote:
> Hi,
>
>> -Original Message-
>> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
>> ow...@vger.kernel.org] On Behalf Of Ido Shayevitz
>> Sent: Thursday, July 12, 2012 1:24 AM
>> To: ba...@ti.com
>> Cc: linux-usb@vger.kernel.org; i...@codeaurora.org
>> Subject: [RFC/PATCH v2] usb: dwc3: Introduce OTG driver for dwc3
>>
>> This is first release of otg driver for the dwc3 Synopsys USB3 core.
>> The otg driver implements the otg final state machine and control the
>> activation of the device controller or host controller.
>>
>> In this first implementation, only simple DRD mode is implemented,
>> determine if A or B device according to the ID pin as reflected in the
>> OSTS.ConIDSts field.
>>
>> Signed-off-by: Ido Shayevitz
>>
>> ---
>> drivers/usb/dwc3/Kconfig |6 +-
>> drivers/usb/dwc3/Makefile|2 +
>> drivers/usb/dwc3/core.c | 15 +-
>> drivers/usb/dwc3/core.h | 51 -
>> drivers/usb/dwc3/dwc3_otg.c | 512
>> ++
>> drivers/usb/dwc3/dwc3_otg.h | 38 +++
>> drivers/usb/dwc3/gadget.c| 63 +
>> drivers/usb/host/xhci-plat.c | 21 ++
>> drivers/usb/host/xhci.c | 13 +-
>> 9 files changed, 708 insertions(+), 13 deletions(-)
>> create mode 100644 drivers/usb/dwc3/dwc3_otg.c
>> create mode 100644 drivers/usb/dwc3/dwc3_otg.h
>>
>> diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
>> index d13c60f..0cc108d 100644
>> --- a/drivers/usb/dwc3/Kconfig
>> +++ b/drivers/usb/dwc3/Kconfig
>> @@ -1,9 +1,9 @@
>> config USB_DWC3
>> tristate "DesignWare USB3 DRD Core Support"
>> -depends on (USB && USB_GADGET)
>> +depends on (USB || USB_GADGET)
>> select USB_OTG_UTILS
>> -select USB_GADGET_DUALSPEED
>> -select USB_GADGET_SUPERSPEED
>> +select USB_GADGET_DUALSPEED if USB_GADGET
>> +select USB_GADGET_SUPERSPEED if USB_GADGET
>> select USB_XHCI_PLATFORM if USB_SUPPORT && USB_XHCI_HCD
>> help
>>Say Y or M here if your system has a Dual Role SuperSpeed
>> diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
>> index d441fe4..ffb3f55 100644
>> --- a/drivers/usb/dwc3/Makefile
>> +++ b/drivers/usb/dwc3/Makefile
>> @@ -1,11 +1,13 @@
>> ccflags-$(CONFIG_USB_DWC3_DEBUG):= -DDEBUG
>> ccflags-$(CONFIG_USB_DWC3_VERBOSE) += -DVERBOSE_DEBUG
>> +ccflags-y += -Idrivers/usb/host
>>
>> obj-$(CONFIG_USB_DWC3) += dwc3.o
>>
>> dwc3-y := core.o
>> dwc3-y += host.o
>> dwc3-y += gadget.o ep0.o
>> +dwc3-y += dwc3_otg.o
>>
>> ifneq ($(CONFIG_DEBUG_FS),)
>> dwc3-y += debugfs.o
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index c34452a..5343e39 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -517,15 +517,24 @@ static int __devinit dwc3_probe(struct
>> platform_device *pdev)
>> break;
>> case DWC3_MODE_DRD:
>> dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
>> +ret = dwc3_otg_init(dwc);
>> +if (ret) {
>> +dev_err(dev, "failed to initialize otg\n");
>> +goto err1;
>> +}
>> +
>> ret = dwc3_host_init(dwc);
>> if (ret) {
>> dev_err(dev, "failed to initialize host\n");
>> +dwc3_otg_exit(dwc);
>> goto err1;
>> }
>>
>> ret = dwc3_gadget_init(dwc);
>> if (ret) {
>> dev_err(dev, "failed to initialize gadget\n");
>> +dwc3_host_exit(dwc);
>> +dwc3_otg_exit(dwc);
>> goto err1;
>> }
>> break;
>> @@ -554,8 +563,9 @@ err2:
>> dwc3_host_exit(dwc);
>> break;
>> case DWC3_MODE_DRD:
>> -dwc3_host_exit(dwc);
>> dwc3_gadget_exit(dwc);
>> +dwc3_host_exit(dwc);
>> +dwc3_otg_exit(dwc);
>> break;
>> default:
>> /* do nothing */
>> @@ -588,8 +598,9 @@ static int __devexit dwc3_remove(struct
>> platform_device *pdev)
>> dwc3_host_exit(dwc);
>> break;
>> case DWC3_MODE_DRD:
>> -dwc3_host_exit(dwc);
>> dwc3_gadget_exit(dwc);
>> +dwc3_host_exit(dwc);
>> +dwc3_otg_exit(dwc);
>> break;
>> default:
>> /* do nothing */
>> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
>> index 151eca8..793758b 100644
>> --- a/drivers/usb/dwc3/core.h
>> +++ b/drivers/usb/dwc3/core.h
>> @@ -50,6 +50,8 @@
>> #include
>> #include
>>
>> +#include "dwc3_otg.h"
>> +
>> /* Global constants */
>> #define DWC3_EP0_BOUNCE_SIZE
[PATCH v5 09/11] usb: musb: dsps: remove explicit NOP device creation
As NOP device node is now added in am33xx tree so remove the call which creates the NOP platform_device. Signed-off-by: Ajay Kumar Gupta --- drivers/usb/musb/musb_dsps.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index ac9f58b..78c88fd 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -425,8 +425,7 @@ static int dsps_musb_init(struct musb *musb) /* mentor core register starts at offset of 0x400 from musb base */ musb->mregs += wrp->musb_core_offset; - /* Register NOP driver */ - usb_nop_xceiv_register(musb->id); + /* Get the NOP PHY */ musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2); if (IS_ERR_OR_NULL(musb->xceiv)) return -ENODEV; -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 08/11] arm/dts: am33xx: add dt data for usb nop phy
AM33xx has two musb controller and they have one NOP PHY each.
Added the device tree data for NOP PHY.
Signed-off-by: Ajay Kumar Gupta
---
arch/arm/boot/dts/am33xx.dtsi |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 08e9a40..b03a9b5 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -155,6 +155,14 @@
ti,hwmods = "i2c3";
};
+ usb0_phy: phy0 {
+ compatible = "nop-xceiv-usb";
+ };
+
+ usb1_phy: phy1 {
+ compatible = "nop-xceiv-usb";
+ };
+
usb_otg_hs: usb_otg_hs {
compatible = "ti,musb-am33xx";
ti,hwmods = "usb_otg_hs";
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 11/11] arm/dts: am33xx: add phy phandle to usbss
Added NOP PHY phandle to usbss device node as same will be used to get the phy from otg framework. Signed-off-by: Ajay Kumar Gupta --- arch/arm/boot/dts/am33xx.dtsi |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index b03a9b5..d3ab69a 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -172,6 +172,8 @@ port0_mode = <3>; port1_mode = <1>; power = <250>; + usb0-phy = <&usb0_phy>; + usb1-phy = <&usb1_phy>; }; }; }; -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 06/11] arm/dts: am33xx: Add dt data for usbss
Added device tree data for usbss on am33xx. There are two musb controllers
on am33xx platform so have port0_mode and port1_mode additional data.
Signed-off-by: Ajay Kumar Gupta
---
arch/arm/boot/dts/am33xx.dtsi | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 59509c4..08e9a40 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -154,5 +154,16 @@
#size-cells = <0>;
ti,hwmods = "i2c3";
};
+
+ usb_otg_hs: usb_otg_hs {
+ compatible = "ti,musb-am33xx";
+ ti,hwmods = "usb_otg_hs";
+ multipoint = <1>;
+ num_eps = <16>;
+ ram_bits = <12>;
+ port0_mode = <3>;
+ port1_mode = <1>;
+ power = <250>;
+ };
};
};
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/11] usb: musb: kill global and static for multi instance
Moved global variable "musb_debugfs_root" and static variable
"old_state" to 'struct musb' to help support multi instance of
musb controller as present on AM335x platform.
Also removed the global variable "orig_dma_mask" and filled the
dev->dma_mask with parent device's dma_mask.
Signed-off-by: Ajay Kumar Gupta
---
drivers/usb/musb/musb_core.c| 22 +++---
drivers/usb/musb/musb_core.h|4
drivers/usb/musb/musb_debugfs.c | 14 --
3 files changed, 19 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index f5eb8a7..cfd93b7 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -100,6 +100,7 @@
#include
#include
#include
+#include
#include "musb_core.h"
@@ -1804,10 +1805,9 @@ static const struct attribute_group musb_attr_group = {
static void musb_irq_work(struct work_struct *data)
{
struct musb *musb = container_of(data, struct musb, irq_work);
- static int old_state;
- if (musb->xceiv->state != old_state) {
- old_state = musb->xceiv->state;
+ if (musb->xceiv->state != musb->xceiv_old_state) {
+ musb->xceiv_old_state = musb->xceiv->state;
sysfs_notify(&musb->controller->kobj, NULL, "mode");
}
}
@@ -2117,11 +2117,6 @@ fail0:
/* all implementations (PCI bridge to FPGA, VLYNQ, etc) should just
* bridge to a platform device; this driver then suffices.
*/
-
-#ifndef CONFIG_MUSB_PIO_ONLY
-static u64 *orig_dma_mask;
-#endif
-
static int __devinit musb_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -2140,10 +2135,6 @@ static int __devinit musb_probe(struct platform_device
*pdev)
return -ENOMEM;
}
-#ifndef CONFIG_MUSB_PIO_ONLY
- /* clobbered by use_dma=n */
- orig_dma_mask = dev->dma_mask;
-#endif
status = musb_init_controller(dev, irq, base);
if (status < 0)
iounmap(base);
@@ -2153,7 +2144,8 @@ static int __devinit musb_probe(struct platform_device
*pdev)
static int __devexit musb_remove(struct platform_device *pdev)
{
- struct musb *musb = dev_to_musb(&pdev->dev);
+ struct device *dev = &pdev->dev;
+ struct musb *musb = dev_to_musb(dev);
void __iomem*ctrl_base = musb->ctrl_base;
/* this gets called on rmmod.
@@ -2166,9 +2158,9 @@ static int __devexit musb_remove(struct platform_device
*pdev)
musb_free(musb);
iounmap(ctrl_base);
- device_init_wakeup(&pdev->dev, 0);
+ device_init_wakeup(dev, 0);
#ifndef CONFIG_MUSB_PIO_ONLY
- pdev->dev.dma_mask = orig_dma_mask;
+ dma_set_mask(dev, *dev->parent->dma_mask);
#endif
return 0;
}
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 69ed141..6b6cee9 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -452,6 +452,10 @@ struct musb {
#endif
/* id for multiple musb instances */
u8 id;
+ int xceiv_old_state;
+#ifdef CONFIG_DEBUG_FS
+ struct dentry *debugfs_root;
+#endif
};
static inline struct musb *gadget_to_musb(struct usb_gadget *g)
diff --git a/drivers/usb/musb/musb_debugfs.c b/drivers/usb/musb/musb_debugfs.c
index 40a37c9..b1e8f21 100644
--- a/drivers/usb/musb/musb_debugfs.c
+++ b/drivers/usb/musb/musb_debugfs.c
@@ -103,8 +103,6 @@ static const struct musb_register_map musb_regmap[] = {
{ }/* Terminating Entry */
};
-static struct dentry *musb_debugfs_root;
-
static int musb_regdump_show(struct seq_file *s, void *unused)
{
struct musb *musb = s->private;
@@ -240,20 +238,24 @@ int __devinit musb_init_debugfs(struct musb *musb)
struct dentry *root;
struct dentry *file;
int ret;
+ charname[10];
- root = debugfs_create_dir("musb", NULL);
+ sprintf(name, "musb%d", musb->id);
+ root = debugfs_create_dir(name, NULL);
if (!root) {
ret = -ENOMEM;
goto err0;
}
- file = debugfs_create_file("regdump", S_IRUGO, root, musb,
+ sprintf(name, "regdump%d", musb->id);
+ file = debugfs_create_file(name, S_IRUGO, root, musb,
&musb_regdump_fops);
if (!file) {
ret = -ENOMEM;
goto err1;
}
+ sprintf(name, "testmode%d", musb->id);
file = debugfs_create_file("testmode", S_IRUGO | S_IWUSR,
root, musb, &musb_test_mode_fops);
if (!file) {
@@ -261,7 +263,7 @@ int __devinit musb_init_debugfs(struct musb *musb)
goto err1;
}
- musb_debugfs_root = root;
+ musb->debugfs_root = root;
return 0;
@@ -274,5 +276,5 @@ err0:
void /* __init_or_exit */ mus
[PATCH v5 01/11] usb: musb: add musb->id to identify core instance
Added 'id' field within 'struct musb' which can be used to determine
the current instance of musb controller.
Also defined musb_ida in musb_core.c to manage the core ids.
Signed-off-by: Ajay Kumar Gupta
---
drivers/usb/musb/am35x.c | 42 --
drivers/usb/musb/blackfin.c | 26 --
drivers/usb/musb/da8xx.c | 34 --
drivers/usb/musb/davinci.c | 34 --
drivers/usb/musb/musb_core.c | 33 +
drivers/usb/musb/musb_core.h |4
drivers/usb/musb/musb_dsps.c | 25 ++---
drivers/usb/musb/omap2430.c | 26 --
drivers/usb/musb/tusb6010.c | 26 --
drivers/usb/musb/ux500.c | 33 +++--
10 files changed, 214 insertions(+), 69 deletions(-)
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 7a95ab8..01203eb 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -468,6 +468,7 @@ static int __devinit am35x_probe(struct platform_device
*pdev)
struct clk *clk;
int ret = -ENOMEM;
+ int musbid;
glue = kzalloc(sizeof(*glue), GFP_KERNEL);
if (!glue) {
@@ -475,38 +476,47 @@ static int __devinit am35x_probe(struct platform_device
*pdev)
goto err0;
}
- musb = platform_device_alloc("musb-hdrc", -1);
+ /* get the musb id */
+ musbid = musb_get_id(&pdev->dev, GFP_KERNEL);
+ if (musbid < 0) {
+ dev_err(&pdev->dev, "failed to allocate musb id\n");
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ musb = platform_device_alloc("musb-hdrc", musbid);
if (!musb) {
dev_err(&pdev->dev, "failed to allocate musb device\n");
- goto err1;
+ goto err2;
}
phy_clk = clk_get(&pdev->dev, "fck");
if (IS_ERR(phy_clk)) {
dev_err(&pdev->dev, "failed to get PHY clock\n");
ret = PTR_ERR(phy_clk);
- goto err2;
+ goto err3;
}
clk = clk_get(&pdev->dev, "ick");
if (IS_ERR(clk)) {
dev_err(&pdev->dev, "failed to get clock\n");
ret = PTR_ERR(clk);
- goto err3;
+ goto err4;
}
ret = clk_enable(phy_clk);
if (ret) {
dev_err(&pdev->dev, "failed to enable PHY clock\n");
- goto err4;
+ goto err5;
}
ret = clk_enable(clk);
if (ret) {
dev_err(&pdev->dev, "failed to enable clock\n");
- goto err5;
+ goto err6;
}
+ musb->id= musbid;
musb->dev.parent= &pdev->dev;
musb->dev.dma_mask = &am35x_dmamask;
musb->dev.coherent_dma_mask = am35x_dmamask;
@@ -524,38 +534,41 @@ static int __devinit am35x_probe(struct platform_device
*pdev)
pdev->num_resources);
if (ret) {
dev_err(&pdev->dev, "failed to add resources\n");
- goto err6;
+ goto err7;
}
ret = platform_device_add_data(musb, pdata, sizeof(*pdata));
if (ret) {
dev_err(&pdev->dev, "failed to add platform_data\n");
- goto err6;
+ goto err7;
}
ret = platform_device_add(musb);
if (ret) {
dev_err(&pdev->dev, "failed to register musb device\n");
- goto err6;
+ goto err7;
}
return 0;
-err6:
+err7:
clk_disable(clk);
-err5:
+err6:
clk_disable(phy_clk);
-err4:
+err5:
clk_put(clk);
-err3:
+err4:
clk_put(phy_clk);
-err2:
+err3:
platform_device_put(musb);
+err2:
+ musb_put_id(&pdev->dev, musbid);
+
err1:
kfree(glue);
@@ -567,6 +580,7 @@ static int __devexit am35x_remove(struct platform_device
*pdev)
{
struct am35x_glue *glue = platform_get_drvdata(pdev);
+ musb_put_id(&pdev->dev, glue->musb->id);
platform_device_del(glue->musb);
platform_device_put(glue->musb);
clk_disable(glue->clk);
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index 428e6aa..c848b82 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -471,6 +471,7 @@ static int __devinit bfin_probe(struct platform_device
*pdev)
struct bfin_glue*glue;
int ret = -ENOMEM;
+ int musbid;
glue = kzalloc(sizeof(*glue), GFP_KERNEL);
if (!glue) {
@@ -478,12 +479,21 @@ static int __devinit bfin_probe(struct p
[PATCH v5 00/11] usb: musb: adding multi instance support
This series of patches adds, a) Multi instances support in musb driver b) DT support for musb_dsps glue layer c) DT support for NOP transceiver AM33xx and TI81xx has dual musb controller and has two usb PHY of same type. This patch series uses 'phandle' based API devm_usb_get_phy_by_phandle() to get the PHY of same type. This API support is being added by Kishon's patch discussed at [1] The series applies to linux-omap (master branch) + Vaibhav baseport patches on his tree at [3] + Kishon's multi phy patches on Felipe's branch 'xceiv' + Kishon's patch on phandle at [1] + AM33xx musb glue compile and bugfix patches at [4], [5], [6] and [7] + Damodar's recent patch at [2] and have been tested on Beaglebone board. 1. http://marc.info/?l=linux-usb&m=134070369306112&w=2 2. http://marc.info/?l=linux-usb&m=134200284230689&w=2 3. https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-staging 4. http://marc.info/?l=linux-usb&m=134131746111637&w=2 5. http://marc.info/?l=linux-usb&m=134131746411639&w=2 6. http://marc.info/?l=linux-usb&m=134062716011251&w=2 7. http://marc.info/?l=linux-usb&m=134061179405213&w=2 Changes from v4: - Fixed Felipe's comment for adding EXPORT_SYMBOL_GPL() - Fixed Felipe's comment on using dev_set_mask() Changes from v3: - Fixed Kishon's comment on removing "id" from phy struct and removing unneeded "#else" part. Changes from v2: - Fixed Sergei's comment on not using address prefix in musb_dsps glue and nop transceiver dt dats. - Also removed the "ti" string in compatible property for nop data. Changes from v1: - Defined musb_ida to manage core ids based on Felipe's comment in [PATCH 01/11] Ajay Kumar Gupta (11): usb: musb: add musb->id to identify core instance usb: musb: kill global and static for multi instance usb: musb: am335x: add support for dual instance usb: otg: nop: add support for multiple tranceiver usb: musb: dsps: add dt support arm/dts: am33xx: Add dt data for usbss usb: otg: nop: add dt support arm/dts: am33xx: add dt data for usb nop phy usb: musb: dsps: remove explicit NOP device creation usb: musb: dsps: get the PHY using phandle api arm/dts: am33xx: add phy phandle to usbss .../devicetree/bindings/usb/am33xx-usb.txt | 19 ++ arch/arm/boot/dts/am33xx.dtsi | 21 +++ arch/arm/mach-omap2/board-omap3evm.c |2 +- drivers/usb/musb/am35x.c | 46 +++-- drivers/usb/musb/blackfin.c| 30 +++- drivers/usb/musb/da8xx.c | 38 +++-- drivers/usb/musb/davinci.c | 40 +++-- drivers/usb/musb/musb_core.c | 55 -- drivers/usb/musb/musb_core.h |8 + drivers/usb/musb/musb_debugfs.c| 14 +- drivers/usb/musb/musb_dsps.c | 189 ++-- drivers/usb/musb/omap2430.c| 26 ++- drivers/usb/musb/tusb6010.c| 32 +++- drivers/usb/musb/ux500.c | 33 +++- drivers/usb/otg/nop-usb-xceiv.c| 29 +++- include/linux/usb/otg.h|8 +- 16 files changed, 425 insertions(+), 165 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/am33xx-usb.txt -- 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 v5 10/11] usb: musb: dsps: get the PHY using phandle api
AM33xx has two PHY of same type used by each musb controller so use phandle of phy nodes to get the phy pointer. Signed-off-by: Ajay Kumar Gupta --- .../devicetree/bindings/usb/am33xx-usb.txt |2 ++ drivers/usb/musb/musb_dsps.c |4 +++- 2 files changed, 5 insertions(+), 1 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt b/Documentation/devicetree/bindings/usb/am33xx-usb.txt index 9782585..e2702df 100644 --- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt +++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt @@ -12,6 +12,8 @@ AM33XX MUSB GLUE represents PERIPHERAL. - power : Should be "250". This signifies the controller can supply upto 500mA when operating in host mode. + - usb0-phy : phandle for usb0 NOP PHY + - usb1-phy : phandle for usb1 NOP PHY NOP USB PHY - compatible : Should be "nop-xceiv-usb" diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index 78c88fd..ab6b74c 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -419,6 +419,7 @@ static int dsps_musb_init(struct musb *musb) struct dsps_glue *glue = platform_get_drvdata(pdev); const struct dsps_musb_wrapper *wrp = glue->wrp; void __iomem *reg_base = musb->ctrl_base; + char name[10]; u32 rev, val; int status; @@ -426,7 +427,8 @@ static int dsps_musb_init(struct musb *musb) musb->mregs += wrp->musb_core_offset; /* Get the NOP PHY */ - musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2); + sprintf(name, "usb%d-phy", musb->id); + musb->xceiv = devm_usb_get_phy_by_phandle(&pdev->dev, name); if (IS_ERR_OR_NULL(musb->xceiv)) return -ENODEV; -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 04/11] usb: otg: nop: add support for multiple tranceiver
Currently we have one single nop transceiver support as same is
defined as a global variable in drivers/usb/otg/nop-usb-xceiv.c.
This need to be changed to support multiple otg controller each
using nop transceiver on a platform such as am335x.
Signed-off-by: Ajay Kumar Gupta
---
arch/arm/mach-omap2/board-omap3evm.c |2 +-
drivers/usb/musb/am35x.c |4 ++--
drivers/usb/musb/blackfin.c |4 ++--
drivers/usb/musb/da8xx.c |4 ++--
drivers/usb/musb/davinci.c |6 +++---
drivers/usb/musb/musb_dsps.c | 10 +-
drivers/usb/musb/tusb6010.c |6 +++---
drivers/usb/otg/nop-usb-xceiv.c | 19 +++
include/linux/usb/otg.h |8
9 files changed, 33 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index ef230a0..a3393bc 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -704,7 +704,7 @@ static void __init omap3_evm_init(void)
omap_sdrc_init(mt46h32m32lf6_sdrc_params, NULL);
/* OMAP3EVM uses ISP1504 phy and so register nop transceiver */
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(0);
if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2) {
/* enable EHCI VBUS using GPIO22 */
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 01203eb..eb6220f 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -364,7 +364,7 @@ static int am35x_musb_init(struct musb *musb)
if (!rev)
return -ENODEV;
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(musb->id);
musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb->xceiv))
return -ENODEV;
@@ -408,7 +408,7 @@ static int am35x_musb_exit(struct musb *musb)
data->set_phy_power(0);
usb_put_phy(musb->xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb->xceiv);
return 0;
}
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index c848b82..03d081c 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -415,7 +415,7 @@ static int bfin_musb_init(struct musb *musb)
}
gpio_direction_output(musb->config->gpio_vrsel, 0);
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(musb->id);
musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb->xceiv)) {
gpio_free(musb->config->gpio_vrsel);
@@ -442,7 +442,7 @@ static int bfin_musb_exit(struct musb *musb)
gpio_free(musb->config->gpio_vrsel);
usb_put_phy(musb->xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb->xceiv);
return 0;
}
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index cebd9d7..3ce4a92 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -425,7 +425,7 @@ static int da8xx_musb_init(struct musb *musb)
if (!rev)
goto fail;
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(musb->id);
musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb->xceiv))
goto fail;
@@ -460,7 +460,7 @@ static int da8xx_musb_exit(struct musb *musb)
phy_off();
usb_put_phy(musb->xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb->xceiv);
return 0;
}
diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
index 3f094f2..d5156b3 100644
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -385,7 +385,7 @@ static int davinci_musb_init(struct musb *musb)
void __iomem*tibase = musb->ctrl_base;
u32 revision;
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(musb->id);
musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb->xceiv))
goto unregister;
@@ -447,7 +447,7 @@ static int davinci_musb_init(struct musb *musb)
fail:
usb_put_phy(musb->xceiv);
unregister:
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb->xceiv);
return -ENODEV;
}
@@ -496,7 +496,7 @@ static int davinci_musb_exit(struct musb *musb)
phy_off();
usb_put_phy(musb->xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb->xceiv);
return 0;
}
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index a2c8a06..9fcacff 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -420,8 +420,8 @@ static int dsps_musb_init(struct musb *musb)
/* mentor core register starts at offset of 0x400 from musb base */
musb->mregs += wrp->musb_core_offset;
- /* NOP driver needs change if supporting dual
[PATCH v5 07/11] usb: otg: nop: add dt support
Added device tree support for nop transceiver driver and updated the
Documentation with device tree binding information for am33xx platform.
Signed-off-by: Ajay Kumar Gupta
---
.../devicetree/bindings/usb/am33xx-usb.txt |3 +++
drivers/usb/otg/nop-usb-xceiv.c| 10 ++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index ca8fa56..9782585 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -12,3 +12,6 @@ AM33XX MUSB GLUE
represents PERIPHERAL.
- power : Should be "250". This signifies the controller can supply upto
500mA when operating in host mode.
+
+NOP USB PHY
+ - compatible : Should be "nop-xceiv-usb"
diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
index aa2f767..2788a00 100644
--- a/drivers/usb/otg/nop-usb-xceiv.c
+++ b/drivers/usb/otg/nop-usb-xceiv.c
@@ -27,6 +27,7 @@
*/
#include
+#include
#include
#include
#include
@@ -151,12 +152,21 @@ static int __devexit nop_usb_xceiv_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id nop_xceiv_id_table[] = {
+ { .compatible = "nop-xceiv-usb" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, nop_xceiv_id_table);
+#endif
+
static struct platform_driver nop_usb_xceiv_driver = {
.probe = nop_usb_xceiv_probe,
.remove = __devexit_p(nop_usb_xceiv_remove),
.driver = {
.name = "nop_usb_xceiv",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(nop_xceiv_id_table),
},
};
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 05/11] usb: musb: dsps: add dt support
Added device tree support for dsps musb glue driver and updated the
Documentation with device tree binding information.
Signed-off-by: Ajay Kumar Gupta
---
.../devicetree/bindings/usb/am33xx-usb.txt | 14 +
drivers/usb/musb/musb_dsps.c | 60 +---
2 files changed, 65 insertions(+), 9 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/am33xx-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
new file mode 100644
index 000..ca8fa56
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -0,0 +1,14 @@
+AM33XX MUSB GLUE
+ - compatible : Should be "ti,musb-am33xx"
+ - ti,hwmods : must be "usb_otg_hs"
+ - multipoint : Should be "1" indicating the musb controller supports
+ multipoint. This is a MUSB configuration-specific setting.
+ - num_eps : Specifies the number of endpoints. This is also a
+ MUSB configuration-specific setting. Should be set to "16"
+ - ram_bits : Specifies the ram address size. Should be set to "12"
+ - port0_mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
+ represents PERIPHERAL.
+ - port1_mode : Should be "1" to represent HOST. "3" signifies OTG and "2"
+ represents PERIPHERAL.
+ - power : Should be "250". This signifies the controller can supply upto
+ 500mA when operating in host mode.
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 9fcacff..ac9f58b 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -31,6 +31,7 @@
#include
#include
+#include
#include
#include
#include
@@ -45,6 +46,10 @@
#include "musb_core.h"
+#ifdef CONFIG_OF
+static const struct of_device_id musb_dsps_of_match[];
+#endif
+
/**
* avoid using musb_readx()/musb_writex() as glue layer should not be
* dependent on musb core layer symbols.
@@ -496,6 +501,8 @@ static int __devinit dsps_create_musb_pdev(struct dsps_glue
*glue, u8 id)
struct device *dev = glue->dev;
struct platform_device *pdev = to_platform_device(dev);
struct musb_hdrc_platform_data *pdata = dev->platform_data;
+ struct device_node *np = pdev->dev.of_node;
+ struct musb_hdrc_config *config;
struct platform_device *musb;
struct resource *res;
struct resource resources[2];
@@ -562,14 +569,40 @@ static int __devinit dsps_create_musb_pdev(struct
dsps_glue *glue, u8 id)
glue->musb[id] = musb;
- pdata->platform_ops = &dsps_ops;
-
ret = platform_device_add_resources(musb, resources, 2);
if (ret) {
dev_err(dev, "failed to add resources\n");
goto err2;
}
+ if (np) {
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(&pdev->dev,
+ "failed to allocate musb platfrom data\n");
+ ret = -ENOMEM;
+ goto err2;
+ }
+
+ config = devm_kzalloc(&pdev->dev, sizeof(*config), GFP_KERNEL);
+ if (!config) {
+ dev_err(&pdev->dev,
+ "failed to allocate musb hdrc config\n");
+ goto err2;
+ }
+
+ of_property_read_u32(np, "num_eps", (u32 *)&config->num_eps);
+ of_property_read_u32(np, "ram_bits", (u32 *)&config->ram_bits);
+ sprintf(res_name, "port%d_mode", id);
+ of_property_read_u32(np, res_name, (u32 *)&pdata->mode);
+ of_property_read_u32(np, "power", (u32 *)&pdata->power);
+ config->multipoint = of_property_read_bool(np, "multipoint");
+
+ pdata->config = config;
+ }
+
+ pdata->platform_ops = &dsps_ops;
+
ret = platform_device_add_data(musb, pdata, sizeof(*pdata));
if (ret) {
dev_err(dev, "failed to add platform_data\n");
@@ -601,14 +634,22 @@ static void __devexit dsps_delete_musb_pdev(struct
dsps_glue *glue, u8 id)
static int __devinit dsps_probe(struct platform_device *pdev)
{
- const struct platform_device_id *id = platform_get_device_id(pdev);
- const struct dsps_musb_wrapper *wrp =
- (struct dsps_musb_wrapper *)id->driver_data;
+ struct device_node *np = pdev->dev.of_node;
+ const struct of_device_id *match;
+ const struct dsps_musb_wrapper *wrp;
struct dsps_glue *glue;
struct resource *iomem;
u32 __iomem *usbss;
int ret, i;
+ match = of_match_node(musb_dsps_of_match, np);
+ if (!match) {
+ dev_err(&pdev->dev, "fail to get matching of_match struct\n");
+ ret = -EINVAL;
+ goto err0;
+ }
+ wrp = match->data;
+
[PATCH v5 03/11] usb: musb: am335x: add support for dual instance
AM335x and TI81xx platform has dual musb controller so updating the
musb_dspc.c to support the same.
Changes:
- Moved otg_workaround timer to glue structure
- Moved static local variable last_timer to glue structure
- PHY on/off related cleanups
Signed-off-by: Ajay Kumar Gupta
---
drivers/usb/musb/musb_dsps.c | 93 +
1 files changed, 57 insertions(+), 36 deletions(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 2174699..a2c8a06 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -105,6 +105,8 @@ struct dsps_musb_wrapper {
/* miscellaneous stuff */
u32 musb_core_offset;
u8 poll_seconds;
+ /* number of musb instances */
+ u8 instances;
};
/**
@@ -112,16 +114,18 @@ struct dsps_musb_wrapper {
*/
struct dsps_glue {
struct device *dev;
- struct platform_device *musb; /* child musb pdev */
+ struct platform_device *musb[2];/* child musb pdev */
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
- struct timer_list timer;/* otg_workaround timer */
- u32 __iomem *usb_ctrl;
+ struct timer_list timer[2]; /* otg_workaround timer */
+ unsigned long last_timer[2];/* last timer data for each instance */
+ u32 __iomem *usb_ctrl[2];
u8 usbss_rev;
};
/**
* musb_dsps_phy_control - phy on/off
* @glue: struct dsps_glue *
+ * @id: musb instance
* @on: flag for phy to be switched on or off
*
* This is to enable the PHY using usb_ctrl register in system control
@@ -130,11 +134,11 @@ struct dsps_glue {
* XXX: This function will be removed once we have a seperate driver for
* control module
*/
-static void musb_dsps_phy_control(struct dsps_glue *glue, u8 on)
+static void musb_dsps_phy_control(struct dsps_glue *glue, u8 id, u8 on)
{
u32 usbphycfg;
- usbphycfg = __raw_readl(glue->usb_ctrl);
+ usbphycfg = __raw_readl(glue->usb_ctrl[id]);
if (on) {
if (glue->usbss_rev == MUSB_USBSS_REV_816X) {
@@ -157,7 +161,7 @@ static void musb_dsps_phy_control(struct dsps_glue *glue,
u8 on)
glue->usbss_rev == MUSB_USBSS_REV_33XX)
usbphycfg |= USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN;
}
- __raw_writel(usbphycfg, glue->usb_ctrl);
+ __raw_writel(usbphycfg, glue->usb_ctrl[id]);
}
/**
* dsps_musb_enable - enable interrupts
@@ -247,7 +251,7 @@ static void otg_timer(unsigned long _musb)
devctl = dsps_readb(mregs, MUSB_DEVCTL);
if (devctl & MUSB_DEVCTL_BDEVICE)
- mod_timer(&glue->timer,
+ mod_timer(&glue->timer[musb->id],
jiffies + wrp->poll_seconds * HZ);
else
musb->xceiv->state = OTG_STATE_A_IDLE;
@@ -263,7 +267,6 @@ static void dsps_musb_try_idle(struct musb *musb, unsigned
long timeout)
struct device *dev = musb->controller;
struct platform_device *pdev = to_platform_device(dev->parent);
struct dsps_glue *glue = platform_get_drvdata(pdev);
- static unsigned long last_timer;
if (!is_otg_enabled(musb))
return;
@@ -276,22 +279,23 @@ static void dsps_musb_try_idle(struct musb *musb,
unsigned long timeout)
musb->xceiv->state == OTG_STATE_A_WAIT_BCON)) {
dev_dbg(musb->controller, "%s active, deleting timer\n",
otg_state_string(musb->xceiv->state));
- del_timer(&glue->timer);
- last_timer = jiffies;
+ del_timer(&glue->timer[musb->id]);
+ glue->last_timer[musb->id] = jiffies;
return;
}
- if (time_after(last_timer, timeout) && timer_pending(&glue->timer)) {
+ if (time_after(glue->last_timer[musb->id], timeout) &&
+ timer_pending(&glue->timer[musb->id])) {
dev_dbg(musb->controller,
"Longer idle timer already pending, ignoring...\n");
return;
}
- last_timer = timeout;
+ glue->last_timer[musb->id] = timeout;
dev_dbg(musb->controller, "%s inactive, starting idle timer for %u
ms\n",
otg_state_string(musb->xceiv->state),
jiffies_to_msecs(timeout - jiffies));
- mod_timer(&glue->timer, timeout);
+ mod_timer(&glue->timer[musb->id], timeout);
}
static irqreturn_t dsps_interrupt(int irq, void *hci)
@@ -360,7 +364,7 @@ static irqreturn_t dsps_interrupt(int irq, void *hci)
*/
musb->int_usb &= ~MUSB_INTR_VBUSERROR;
musb->xceiv->state = OTG_STATE_A_WAIT_VFALL;
- mod_ti
[PATCH v5 02/11] usb: musb: kill global and static for multi instance
Moved global variable "musb_debugfs_root" and static variable
"old_state" to 'struct musb' to help support multi instance of
musb controller as present on AM335x platform.
Also removed the global variable "orig_dma_mask" and filled the
dev->dma_mask with parent device's dma_mask.
Signed-off-by: Ajay Kumar Gupta
---
drivers/usb/musb/musb_core.c| 22 +++---
drivers/usb/musb/musb_core.h|4
drivers/usb/musb/musb_debugfs.c | 14 --
3 files changed, 19 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index f5eb8a7..cfd93b7 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -100,6 +100,7 @@
#include
#include
#include
+#include
#include "musb_core.h"
@@ -1804,10 +1805,9 @@ static const struct attribute_group musb_attr_group = {
static void musb_irq_work(struct work_struct *data)
{
struct musb *musb = container_of(data, struct musb, irq_work);
- static int old_state;
- if (musb->xceiv->state != old_state) {
- old_state = musb->xceiv->state;
+ if (musb->xceiv->state != musb->xceiv_old_state) {
+ musb->xceiv_old_state = musb->xceiv->state;
sysfs_notify(&musb->controller->kobj, NULL, "mode");
}
}
@@ -2117,11 +2117,6 @@ fail0:
/* all implementations (PCI bridge to FPGA, VLYNQ, etc) should just
* bridge to a platform device; this driver then suffices.
*/
-
-#ifndef CONFIG_MUSB_PIO_ONLY
-static u64 *orig_dma_mask;
-#endif
-
static int __devinit musb_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -2140,10 +2135,6 @@ static int __devinit musb_probe(struct platform_device
*pdev)
return -ENOMEM;
}
-#ifndef CONFIG_MUSB_PIO_ONLY
- /* clobbered by use_dma=n */
- orig_dma_mask = dev->dma_mask;
-#endif
status = musb_init_controller(dev, irq, base);
if (status < 0)
iounmap(base);
@@ -2153,7 +2144,8 @@ static int __devinit musb_probe(struct platform_device
*pdev)
static int __devexit musb_remove(struct platform_device *pdev)
{
- struct musb *musb = dev_to_musb(&pdev->dev);
+ struct device *dev = &pdev->dev;
+ struct musb *musb = dev_to_musb(dev);
void __iomem*ctrl_base = musb->ctrl_base;
/* this gets called on rmmod.
@@ -2166,9 +2158,9 @@ static int __devexit musb_remove(struct platform_device
*pdev)
musb_free(musb);
iounmap(ctrl_base);
- device_init_wakeup(&pdev->dev, 0);
+ device_init_wakeup(dev, 0);
#ifndef CONFIG_MUSB_PIO_ONLY
- pdev->dev.dma_mask = orig_dma_mask;
+ dma_set_mask(dev, *dev->parent->dma_mask);
#endif
return 0;
}
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 69ed141..6b6cee9 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -452,6 +452,10 @@ struct musb {
#endif
/* id for multiple musb instances */
u8 id;
+ int xceiv_old_state;
+#ifdef CONFIG_DEBUG_FS
+ struct dentry *debugfs_root;
+#endif
};
static inline struct musb *gadget_to_musb(struct usb_gadget *g)
diff --git a/drivers/usb/musb/musb_debugfs.c b/drivers/usb/musb/musb_debugfs.c
index 40a37c9..b1e8f21 100644
--- a/drivers/usb/musb/musb_debugfs.c
+++ b/drivers/usb/musb/musb_debugfs.c
@@ -103,8 +103,6 @@ static const struct musb_register_map musb_regmap[] = {
{ }/* Terminating Entry */
};
-static struct dentry *musb_debugfs_root;
-
static int musb_regdump_show(struct seq_file *s, void *unused)
{
struct musb *musb = s->private;
@@ -240,20 +238,24 @@ int __devinit musb_init_debugfs(struct musb *musb)
struct dentry *root;
struct dentry *file;
int ret;
+ charname[10];
- root = debugfs_create_dir("musb", NULL);
+ sprintf(name, "musb%d", musb->id);
+ root = debugfs_create_dir(name, NULL);
if (!root) {
ret = -ENOMEM;
goto err0;
}
- file = debugfs_create_file("regdump", S_IRUGO, root, musb,
+ sprintf(name, "regdump%d", musb->id);
+ file = debugfs_create_file(name, S_IRUGO, root, musb,
&musb_regdump_fops);
if (!file) {
ret = -ENOMEM;
goto err1;
}
+ sprintf(name, "testmode%d", musb->id);
file = debugfs_create_file("testmode", S_IRUGO | S_IWUSR,
root, musb, &musb_test_mode_fops);
if (!file) {
@@ -261,7 +263,7 @@ int __devinit musb_init_debugfs(struct musb *musb)
goto err1;
}
- musb_debugfs_root = root;
+ musb->debugfs_root = root;
return 0;
@@ -274,5 +276,5 @@ err0:
void /* __init_or_exit */ mus
RE: [PATCH 0/7 v2] usb: gadget: mv_udc: bug fix and feature add
Hi Balbi, > -Original Message- > From: Neil Zhang > Sent: 2012年7月19日 22:48 > To: Neil Zhang; ba...@ti.com; gre...@linuxfoundation.org > Cc: Chao Xie; khoroshi...@ispras.ru; linux-usb@vger.kernel.org > Subject: RE: [PATCH 0/7 v2] usb: gadget: mv_udc: bug fix and feature > add > > Hi Balbi, > > > -Original Message- > > From: Neil Zhang [mailto:zhan...@marvell.com] > > Sent: 2012年7月10日 10:07 > > To: ba...@ti.com; gre...@linuxfoundation.org > > Cc: Chao Xie; khoroshi...@ispras.ru; linux-usb@vger.kernel.org; Neil > > Zhang > > Subject: [PATCH 0/7 v2] usb: gadget: mv_udc: bug fix and feature add > > > > This patch set will add ISO support for mv_udc and do some bug fix. > > > > ChangeLog: > > V2: > > 1. Fix some syntax error in comments. > > 2. Use usb_endpoint_xfer_isoc instead of redundant code, thanks > Sergei. > > > > Chao Xie (1): > > usb: gadget: mv_udc: add iso support > > > > Neil Zhang (5): > > usb: gadget: mv_udc: reduce the delay interval > > usb: gadget: mv_udc: remove unused code > > usb: gadget: mv_udc: avoid sleeping on spinlock > > usb: gadget: mv_udc: enable stream mode > > usb: gadget: mv_udc: fix boot up hang > > > > Yunfan Zhang (1): > > usb: gadget: mv_udc: fix hang when shutdown > > > > drivers/usb/gadget/mv_udc_core.c | 85 +++- > -- > > --- > > 1 files changed, 62 insertions(+), 23 deletions(-) > > > > -- > > 1.7.4.1 > > Would you please pay your time to review these patches? > Thanks. > > Best Regards, > Neil Zhang Would you please help to review these patches? Thanks. Best Regards, Neil Zhang
Re: [PATCH v5 01/11] usb: musb: add musb->id to identify core instance
hi, On Wed, Jul 25, 2012 at 05:37:19PM +0530, Ajay Kumar Gupta wrote: > diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c > index 89d1871..f5eb8a7 100644 > --- a/drivers/usb/musb/musb_core.c > +++ b/drivers/usb/musb/musb_core.c > @@ -1889,6 +1921,7 @@ musb_init_controller(struct device *dev, int nIrq, void > __iomem *ctrl) > pm_runtime_enable(musb->controller); > > spin_lock_init(&musb->lock); > + musb->id = pdev->id; I fail to see where this musb->id would be used. Care to clarify ? -- balbi signature.asc Description: Digital signature
RE: [PATCH v5 01/11] usb: musb: add musb->id to identify core instance
Hi, > > On Wed, Jul 25, 2012 at 05:37:19PM +0530, Ajay Kumar Gupta wrote: > > diff --git a/drivers/usb/musb/musb_core.c > > b/drivers/usb/musb/musb_core.c index 89d1871..f5eb8a7 100644 > > --- a/drivers/usb/musb/musb_core.c > > +++ b/drivers/usb/musb/musb_core.c > > > > > @@ -1889,6 +1921,7 @@ musb_init_controller(struct device *dev, int nIrq, > void __iomem *ctrl) > > pm_runtime_enable(musb->controller); > > > > spin_lock_init(&musb->lock); > > + musb->id = pdev->id; > > I fail to see where this musb->id would be used. Care to clarify ? Sure, It is used in musb_init_debugfs(). Please refer 02/11. Ajay > > -- > 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: [PATCH v5 01/11] usb: musb: add musb->id to identify core instance
Hi. On Wed, Jul 25, 2012 at 12:19:32PM +, Gupta, Ajay Kumar wrote: > Hi, > > > > On Wed, Jul 25, 2012 at 05:37:19PM +0530, Ajay Kumar Gupta wrote: > > > diff --git a/drivers/usb/musb/musb_core.c > > > b/drivers/usb/musb/musb_core.c index 89d1871..f5eb8a7 100644 > > > --- a/drivers/usb/musb/musb_core.c > > > +++ b/drivers/usb/musb/musb_core.c > > > > > > > > > @@ -1889,6 +1921,7 @@ musb_init_controller(struct device *dev, int nIrq, > > void __iomem *ctrl) > > > pm_runtime_enable(musb->controller); > > > > > > spin_lock_init(&musb->lock); > > > + musb->id = pdev->id; > > > > I fail to see where this musb->id would be used. Care to clarify ? > > Sure, It is used in musb_init_debugfs(). Please refer 02/11. Then it's a bit unnecessary right ? You can change the directory name to dev_name(musb->controller) as that will already have the id appended to it. -- balbi signature.asc Description: Digital signature
RE: [PATCH v5 01/11] usb: musb: add musb->id to identify core instance
Hi, > On Wed, Jul 25, 2012 at 12:19:32PM +, Gupta, Ajay Kumar wrote: > > Hi, > > > > > > On Wed, Jul 25, 2012 at 05:37:19PM +0530, Ajay Kumar Gupta wrote: > > > > diff --git a/drivers/usb/musb/musb_core.c > > > > b/drivers/usb/musb/musb_core.c index 89d1871..f5eb8a7 100644 > > > > --- a/drivers/usb/musb/musb_core.c > > > > +++ b/drivers/usb/musb/musb_core.c > > > > > > > > > > > > > @@ -1889,6 +1921,7 @@ musb_init_controller(struct device *dev, int > > > > nIrq, > > > void __iomem *ctrl) > > > > pm_runtime_enable(musb->controller); > > > > > > > > spin_lock_init(&musb->lock); > > > > + musb->id = pdev->id; > > > > > > I fail to see where this musb->id would be used. Care to clarify ? > > > > Sure, It is used in musb_init_debugfs(). Please refer 02/11. > > Then it's a bit unnecessary right ? > > You can change the directory name to dev_name(musb->controller) as that will > already have the id appended to it. Well, musb->id is used at many more places and it has to be there. Please refer 01/11 where all glue layers using it for: + musb_put_id(&pdev->dev, glue->musb->id); 03/11 where musb dsps glue is extensively using it at multiple places. 04/11 where all glue using if then need nop. Thanks, Ajay > > -- > 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: [PATCH] omap: usb: host: remove deprecated flag 'es2_compatibility'
On Wed, Jul 25, 2012 at 1:24 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Jul 24, 2012 at 09:08:40PM +0300, Ruslan Bilovol wrote:
>> Currently this flag is not used anywhere and may be safely removed.
>>
>> Signed-off-by: Ruslan Bilovol
>
> looks good to me. Keshava ?
Ruslan
please remove the structure ohci_hcd_omap_platform_data too.
the ohci port configuration is any taken care by omap-usb-host.c file..
regards
keshava
>
>> ---
>> arch/arm/mach-omap2/usb-host.c|1 -
>> arch/arm/plat-omap/include/plat/usb.h |4
>> 2 files changed, 0 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
>> index dde8a11..5e1cb53 100644
>> --- a/arch/arm/mach-omap2/usb-host.c
>> +++ b/arch/arm/mach-omap2/usb-host.c
>> @@ -500,7 +500,6 @@ void __init usbhs_init(const struct
>> usbhs_omap_board_data *pdata)
>> ehci_data.regulator[i] = pdata->regulator[i];
>> }
>> ehci_data.phy_reset = pdata->phy_reset;
>> - ohci_data.es2_compatibility = pdata->es2_compatibility;
>> usbhs_data.ehci_data = &ehci_data;
>> usbhs_data.ohci_data = &ohci_data;
>>
>> diff --git a/arch/arm/plat-omap/include/plat/usb.h
>> b/arch/arm/plat-omap/include/plat/usb.h
>> index 762eeb0..f8c1eb8 100644
>> --- a/arch/arm/plat-omap/include/plat/usb.h
>> +++ b/arch/arm/plat-omap/include/plat/usb.h
>> @@ -32,9 +32,6 @@ struct usbhs_omap_board_data {
>> /* have to be valid if phy_reset is true and portx is in phy mode */
>> int reset_gpio_port[OMAP3_HS_USB_PORTS];
>>
>> - /* Set this to true for ES2.x silicon */
>> - unsignedes2_compatibility:1;
>> -
>> unsignedphy_reset:1;
>>
>> /*
>> @@ -53,7 +50,6 @@ struct ehci_hcd_omap_platform_data {
>>
>> struct ohci_hcd_omap_platform_data {
>> enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS];
>> - unsignedes2_compatibility:1;
>> };
>>
>> struct usbhs_omap_platform_data {
>> --
>> 1.7.1
>>
>
> --
> 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 00/13] firmware loader: introduce cache/uncache firmware
CC usb guys and list
On Wed, Jul 25, 2012 at 1:53 AM, Linus Torvalds
wrote:
>
> I really think the isight thing is a totally different thing entirely.
>
> And quite frankly, that's just a BUG in the USB implementation. If the
> USB ID changes, it shouldn't be considered a "resume" thing at all,
> but a probe thing, and that should not be done in early resume - it
> should be done *after* the resume is done.
IMO, usbcore may have found the ID changes during resume(reset_resume),
and make the device disconnect. The disconnect event will be handled
in hubd kthread, which is woken up before usermodehelper_enable()(see
thaw_processes), so request_firmware will return failure during probe()
inside hubd kthread.
The cache firmware patch set may not help the situation, because the
original isight usb device for downloading firmware has been disconnected
before system suspend, so firmware loader can't cache the firmware for
the device.
The below patch should fix the problem above.
diff --git a/kernel/power/process.c b/kernel/power/process.c
index 19db29f..eb8355f 100644
--- a/kernel/power/process.c
+++ b/kernel/power/process.c
@@ -185,16 +185,18 @@ void thaw_processes(void)
printk("Restarting tasks ... ");
- thaw_workqueues();
-
read_lock(&tasklist_lock);
do_each_thread(g, p) {
- __thaw_task(p);
+ if (!(p->flags & (PF_KTHREAD | PF_WQ_WORKER)))
+ __thaw_task(p);
} while_each_thread(g, p);
read_unlock(&tasklist_lock);
usermodehelper_enable();
+ /* let kthread see usermodehelper enabled flag */
+ thaw_kernel_threads();
+
schedule();
printk("done.\n");
}
Thanks,
--
Ming Lei
--
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 v5 01/11] usb: musb: add musb->id to identify core instance
On Wed, Jul 25, 2012 at 12:30:12PM +, Gupta, Ajay Kumar wrote:
> Hi,
> > On Wed, Jul 25, 2012 at 12:19:32PM +, Gupta, Ajay Kumar wrote:
> > > Hi,
> > > >
> > > > On Wed, Jul 25, 2012 at 05:37:19PM +0530, Ajay Kumar Gupta wrote:
> > > > > diff --git a/drivers/usb/musb/musb_core.c
> > > > > b/drivers/usb/musb/musb_core.c index 89d1871..f5eb8a7 100644
> > > > > --- a/drivers/usb/musb/musb_core.c
> > > > > +++ b/drivers/usb/musb/musb_core.c
> > > >
> > > >
> > > >
> > > > > @@ -1889,6 +1921,7 @@ musb_init_controller(struct device *dev, int
> > > > > nIrq,
> > > > void __iomem *ctrl)
> > > > > pm_runtime_enable(musb->controller);
> > > > >
> > > > > spin_lock_init(&musb->lock);
> > > > > + musb->id = pdev->id;
> > > >
> > > > I fail to see where this musb->id would be used. Care to clarify ?
> > >
> > > Sure, It is used in musb_init_debugfs(). Please refer 02/11.
> >
> > Then it's a bit unnecessary right ?
> >
> > You can change the directory name to dev_name(musb->controller) as that will
> > already have the id appended to it.
>
> Well, musb->id is used at many more places and it has to be there. Please
> refer
>
> 01/11 where all glue layers using it for:
> + musb_put_id(&pdev->dev, glue->musb->id);
your struct *_glue{}; should be the one holding the ID as it's the one
who requested it. If you request multiple IDs, you hold multiple IDs
(glue->id0, glue->id1, glue->idN) and so on.
--
balbi
signature.asc
Description: Digital signature
RE: [PATCH v5 01/11] usb: musb: add musb->id to identify core instance
Hi,
> On Wed, Jul 25, 2012 at 12:30:12PM +, Gupta, Ajay Kumar wrote:
> > Hi,
> > > On Wed, Jul 25, 2012 at 12:19:32PM +, Gupta, Ajay Kumar wrote:
> > > > Hi,
> > > > >
> > > > > On Wed, Jul 25, 2012 at 05:37:19PM +0530, Ajay Kumar Gupta wrote:
> > > > > > diff --git a/drivers/usb/musb/musb_core.c
> > > > > > b/drivers/usb/musb/musb_core.c index 89d1871..f5eb8a7 100644
> > > > > > --- a/drivers/usb/musb/musb_core.c
> > > > > > +++ b/drivers/usb/musb/musb_core.c
> > > > >
> > > > >
> > > > >
> > > > > > @@ -1889,6 +1921,7 @@ musb_init_controller(struct device *dev,
> > > > > > int nIrq,
> > > > > void __iomem *ctrl)
> > > > > > pm_runtime_enable(musb->controller);
> > > > > >
> > > > > > spin_lock_init(&musb->lock);
> > > > > > + musb->id = pdev->id;
> > > > >
> > > > > I fail to see where this musb->id would be used. Care to clarify ?
> > > >
> > > > Sure, It is used in musb_init_debugfs(). Please refer 02/11.
> > >
> > > Then it's a bit unnecessary right ?
> > >
> > > You can change the directory name to dev_name(musb->controller) as
> > > that will already have the id appended to it.
> >
> > Well, musb->id is used at many more places and it has to be there.
> > Please refer
> >
> > 01/11 where all glue layers using it for:
> > + musb_put_id(&pdev->dev, glue->musb->id);
Here glue->musb is a platform_device and not "struct musb". So it's limited
at glue layer alone. All IDs are being saved in each pdev->id. We have two
musb instances and so we have glue->musb[2] pdevs and so each IDs getting saved
at glue->musb[0]->id and glue->musb[1]->id.
How about musb->id (I mean struct musb here) uses at other places?
03/11 where musb dsps glue is extensively using it at multiple places.
04/11 where all glue using if they need nop.
Ajay
>
> your struct *_glue{}; should be the one holding the ID as it's the one who
> requested it. If you request multiple IDs, you hold multiple IDs (glue->id0,
> glue->id1, glue->idN) and so on.
>
> --
> 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 00/13] firmware loader: introduce cache/uncache firmware
On Wednesday 25 July 2012 20:35:28 Ming Lei wrote: > CC usb guys and list > > On Wed, Jul 25, 2012 at 1:53 AM, Linus Torvalds > wrote: > > > > I really think the isight thing is a totally different thing entirely. > > > > And quite frankly, that's just a BUG in the USB implementation. If the > > USB ID changes, it shouldn't be considered a "resume" thing at all, > > but a probe thing, and that should not be done in early resume - it > > should be done *after* the resume is done. > > IMO, usbcore may have found the ID changes during resume(reset_resume), > and make the device disconnect. The disconnect event will be handled > in hubd kthread, which is woken up before usermodehelper_enable()(see > thaw_processes), so request_firmware will return failure during probe() > inside hubd kthread. > > The cache firmware patch set may not help the situation, because the > original isight usb device for downloading firmware has been disconnected > before system suspend, so firmware loader can't cache the firmware for > the device. > > The below patch should fix the problem above. This is likely unwise. You'd better introduce a special flag for kernel threads that should be thawed only after user space will have been thawed. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH v3] usb: dwc3: Introduce OTG driver for dwc3
This is first release of otg driver for the dwc3 Synopsys USB3 core.
The otg driver implements the otg final state machine and control the
activation of the device controller or host controller.
In this first implementation, only simple DRD mode is implemented,
determine if A or B device according to the ID pin as reflected in the
OSTS.ConIDSts field.
Signed-off-by: Ido Shayevitz
---
drivers/usb/dwc3/Kconfig |6 +-
drivers/usb/dwc3/Makefile|2 +
drivers/usb/dwc3/core.c | 15 +-
drivers/usb/dwc3/core.h | 54 +-
drivers/usb/dwc3/dwc3_otg.c | 512 ++
drivers/usb/dwc3/dwc3_otg.h | 38 +++
drivers/usb/dwc3/gadget.c| 63 +
drivers/usb/host/xhci-plat.c | 21 ++
drivers/usb/host/xhci.c | 13 +-
9 files changed, 711 insertions(+), 13 deletions(-)
create mode 100644 drivers/usb/dwc3/dwc3_otg.c
create mode 100644 drivers/usb/dwc3/dwc3_otg.h
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index d13c60f..0cc108d 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -1,9 +1,9 @@
config USB_DWC3
tristate "DesignWare USB3 DRD Core Support"
- depends on (USB && USB_GADGET)
+ depends on (USB || USB_GADGET)
select USB_OTG_UTILS
- select USB_GADGET_DUALSPEED
- select USB_GADGET_SUPERSPEED
+ select USB_GADGET_DUALSPEED if USB_GADGET
+ select USB_GADGET_SUPERSPEED if USB_GADGET
select USB_XHCI_PLATFORM if USB_SUPPORT && USB_XHCI_HCD
help
Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index d441fe4..ffb3f55 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -1,11 +1,13 @@
ccflags-$(CONFIG_USB_DWC3_DEBUG) := -DDEBUG
ccflags-$(CONFIG_USB_DWC3_VERBOSE) += -DVERBOSE_DEBUG
+ccflags-y += -Idrivers/usb/host
obj-$(CONFIG_USB_DWC3) += dwc3.o
dwc3-y := core.o
dwc3-y += host.o
dwc3-y += gadget.o ep0.o
+dwc3-y += dwc3_otg.o
ifneq ($(CONFIG_DEBUG_FS),)
dwc3-y += debugfs.o
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index c34452a..5343e39 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -517,15 +517,24 @@ static int __devinit dwc3_probe(struct platform_device
*pdev)
break;
case DWC3_MODE_DRD:
dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
+ ret = dwc3_otg_init(dwc);
+ if (ret) {
+ dev_err(dev, "failed to initialize otg\n");
+ goto err1;
+ }
+
ret = dwc3_host_init(dwc);
if (ret) {
dev_err(dev, "failed to initialize host\n");
+ dwc3_otg_exit(dwc);
goto err1;
}
ret = dwc3_gadget_init(dwc);
if (ret) {
dev_err(dev, "failed to initialize gadget\n");
+ dwc3_host_exit(dwc);
+ dwc3_otg_exit(dwc);
goto err1;
}
break;
@@ -554,8 +563,9 @@ err2:
dwc3_host_exit(dwc);
break;
case DWC3_MODE_DRD:
- dwc3_host_exit(dwc);
dwc3_gadget_exit(dwc);
+ dwc3_host_exit(dwc);
+ dwc3_otg_exit(dwc);
break;
default:
/* do nothing */
@@ -588,8 +598,9 @@ static int __devexit dwc3_remove(struct platform_device
*pdev)
dwc3_host_exit(dwc);
break;
case DWC3_MODE_DRD:
- dwc3_host_exit(dwc);
dwc3_gadget_exit(dwc);
+ dwc3_host_exit(dwc);
+ dwc3_otg_exit(dwc);
break;
default:
/* do nothing */
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index c611d80..29a03e0 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -50,6 +50,8 @@
#include
#include
+#include "dwc3_otg.h"
+
/* Global constants */
#define DWC3_EP0_BOUNCE_SIZE 512
#define DWC3_ENDPOINTS_NUM 32
@@ -152,8 +154,9 @@
/* OTG Registers */
#define DWC3_OCFG 0xcc00
#define DWC3_OCTL 0xcc04
-#define DWC3_OEVTEN0xcc08
-#define DWC3_OSTS 0xcc0C
+#define DWC3_OEVT 0xcc08
+#define DWC3_OEVTEN0xcc0c
+#define DWC3_OSTS 0xcc10
/* Bit fields */
@@ -203,6 +206,9 @@
#define DWC3_GHWPARAMS4_HIBER_SCRATCHBUFS(n) (((n) & (0x0f << 13)) >> 13)
#define DWC3_MAX_HIBER_SCRATCHBUFS 15
+/* Global HWPARAMS6 Register */
+#define DWC3_GHWPARAMS6_SRP_SUPPORT(1 << 10)
+
/* Device
Re: [RFC PATCH 00/13] firmware loader: introduce cache/uncache firmware
On Wed, Jul 25, 2012 at 8:43 PM, Oliver Neukum wrote: > This is likely unwise. You'd better introduce a special flag for kernel > threads > that should be thawed only after user space will have been thawed. IMO, it is not necessary to introduce one extra flag for the purpose since - usermodehelper flag should be set/get as enabled after user space tasks have been waken up - no harm to thaw all user space tasks before thawing all kernel threads (there isn't any dependency about the thawing order) Thanks, -- Ming Lei -- 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
usb : mass storage : short_not_ok for non usb3 udc
The short_not_ok field is used by class drivers to indicate udc whether short
packet is expected during a particular transfer.
In case of mass storage, during command and status phase this field is set as
false and set to true during data phase.
musb driver uses this field to decide whether to program DMA for mode1.
This code is essential for musb driver to program DMA.
Signed-off-by: Balakumar Rajendran
Signed-off-by: Rajaram R
---
drivers/usb/gadget/f_mass_storage.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c
index f67b453..db8bf4a 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -878,6 +878,7 @@ static int do_write(struct fsg_common *common)
unsigned intamount;
ssize_t nwritten;
int rc;
+ struct usb_gadget *gadget = common->cdev->gadget;
if (curlun->ro) {
curlun->sense_data = SS_WRITE_PROTECTED; @@ -960,6 +961,8 @@
static int do_write(struct fsg_common *common)
* the bulk-out maxpacket size.
*/
set_bulk_out_req_length(common, bh, amount);
+ if (!gadget_is_superspeed(gadget))
+ bh->outreq->short_not_ok = 1;
if (!start_out_transfer(common, bh))
/* Dunno what to do if common->fsg is NULL */
return -EIO;
@@ -1584,6 +1587,7 @@ static int throw_away_data(struct fsg_common *common)
struct fsg_buffhd *bh;
u32 amount;
int rc;
+ struct usb_gadget *gadget = common->cdev->gadget;
for (bh = common->next_buffhd_to_drain;
bh->state != BUF_STATE_EMPTY || common->usb_amount_left > 0; @@
-1617,6 +1621,8 @@ static int throw_away_data(struct fsg_common *common)
* the bulk-out maxpacket size.
*/
set_bulk_out_req_length(common, bh, amount);
+ if (!gadget_is_superspeed(gadget))
+ bh->outreq->short_not_ok = 1;
if (!start_out_transfer(common, bh))
/* Dunno what to do if common->fsg is NULL */
return -EIO;
@@ -2292,6 +2298,7 @@ static int get_next_command(struct fsg_common *common) {
struct fsg_buffhd *bh;
int rc = 0;
+ struct usb_gadget *gadget = common->cdev->gadget;
/* Wait for the next buffer to become available */
bh = common->next_buffhd_to_fill;
@@ -2303,6 +2310,8 @@ static int get_next_command(struct fsg_common *common)
/* Queue a request to read a Bulk-only CBW */
set_bulk_out_req_length(common, bh, US_BULK_CB_WRAP_LEN);
+ if (!gadget_is_superspeed(gadget))
+ bh->outreq->short_not_ok = 0;
if (!start_out_transfer(common, bh))
/* Don't know what to do if common->fsg is NULL */
return -EIO;
--
1.7.4.3
--
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 00/13] firmware loader: introduce cache/uncache firmware
On Wed, Jul 25, 2012 at 8:50 PM, Ming Lei wrote: > - no harm to thaw all user space tasks before thawing all kernel threads > (there isn't any dependency about the thawing order) Sorry, I mean there isn't any constraint about the order, but the 'dependency' may be just what the patch is introducing. Thanks, -- Ming Lei -- 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: usb : mass storage : short_not_ok for non usb3 udc
On Wed, 25 Jul 2012 14:53:00 +0200, Rajaram REGUPATHY
wrote:
The short_not_ok field is used by class drivers to indicate udc whether short
packet is expected during a particular transfer.
In case of mass storage, during command and status phase this field is set as
false and set to true during data phase.
musb driver uses this field to decide whether to program DMA for mode1.
This code is essential for musb driver to program DMA.
There's one thing I don't get. The message talks about musb but the code
checks for non Super Speed devices. So maybe the code is correct, maybe
it's not, but the message does not really explain it (at least to me).
(Also, you probably should wrap the message before 80th column.)
Signed-off-by: Balakumar Rajendran
Signed-off-by: Rajaram R
---
drivers/usb/gadget/f_mass_storage.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c
index f67b453..db8bf4a 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -878,6 +878,7 @@ static int do_write(struct fsg_common *common)
unsigned intamount;
ssize_t nwritten;
int rc;
+ struct usb_gadget *gadget = common->cdev->gadget;
if (curlun->ro) {
curlun->sense_data = SS_WRITE_PROTECTED; @@ -960,6 +961,8 @@
static int do_write(struct fsg_common *common)
* the bulk-out maxpacket size.
*/
set_bulk_out_req_length(common, bh, amount);
+ if (!gadget_is_superspeed(gadget))
+ bh->outreq->short_not_ok = 1;
if (!start_out_transfer(common, bh))
/* Dunno what to do if common->fsg is NULL */
return -EIO;
@@ -1584,6 +1587,7 @@ static int throw_away_data(struct fsg_common *common)
struct fsg_buffhd *bh;
u32 amount;
int rc;
+ struct usb_gadget *gadget = common->cdev->gadget;
for (bh = common->next_buffhd_to_drain;
bh->state != BUF_STATE_EMPTY || common->usb_amount_left > 0; @@
-1617,6 +1621,8 @@ static int throw_away_data(struct fsg_common *common)
* the bulk-out maxpacket size.
*/
set_bulk_out_req_length(common, bh, amount);
+ if (!gadget_is_superspeed(gadget))
+ bh->outreq->short_not_ok = 1;
if (!start_out_transfer(common, bh))
/* Dunno what to do if common->fsg is NULL */
return -EIO;
@@ -2292,6 +2298,7 @@ static int get_next_command(struct fsg_common *common) {
struct fsg_buffhd *bh;
int rc = 0;
+ struct usb_gadget *gadget = common->cdev->gadget;
/* Wait for the next buffer to become available */
bh = common->next_buffhd_to_fill;
@@ -2303,6 +2310,8 @@ static int get_next_command(struct fsg_common *common)
/* Queue a request to read a Bulk-only CBW */
set_bulk_out_req_length(common, bh, US_BULK_CB_WRAP_LEN);
+ if (!gadget_is_superspeed(gadget))
+ bh->outreq->short_not_ok = 0;
if (!start_out_transfer(common, bh))
/* Don't know what to do if common->fsg is NULL */
return -EIO;
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--
--
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] usb: gadget: Ensure correct functionality for gadgets that wish to 'connect' only when directed by user-space
Hi Bhupesh, On Wednesday 25 July 2012 15:06:37 Bhupesh SHARMA wrote: [snip] > It's been almost a month since this RFC was circulated. > As no comments have been received so far, http://www.spinics.net/lists/linux-usb/msg66755.html Mails get lost sometime. BTW, http://www.spinics.net/lists/linux-usb/msg65828.html might be related. > can I assume that this approach is fine and send a formal patch for the same > and will that be acceptable for inclusion in mainline? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bisected regression, v3.5 -> next-20120724: PCI PM causes USB hotplug failure
Hi, Bjorn, Thank you very much for your detailed information. On Wed, Jul 25, 2012 at 5:58 PM, Bjørn Mork wrote: > Huang Ying writes: >> On Wed, 2012-07-25 at 06:08 +0200, Bjørn Mork wrote: >>> Enabling autosuspend for USB causes hotplug failure in the current >>> linux-next. Newly plugged devices are not detected at all until the >>> port/controller is manually powered on by writing "on" to power/control. >>> Testing is pretty simple: >>> >>> 1) for f in /sys/bus/usb/devices/*/power/control; do echo auto > $f; done >> >> Have you done: >> >> for f in /sys/bus/pci/devices/*/power/confol; do echo auto > $f; done >> >> ? >> >> If not, the pci device will not be suspended at all. > > Yes, sorry for missing that. I had it automatically enabled. Yes, > autosuspend for the PCI device and all child devices must be enabled for > the device to be suspended at all, of course. > >>> 2) wait for the controllers to suspend >>> 3) plugin a new USB device >> >> After plugin the new USB device, is there anything in dmesg? > > No. Absolutely nothing, so the USB devices is not enumerated. Another > indication of the same: Plugging a device like an Android phone, which > normally detects being connected to a host and presents a device type > menu to the user, results in the charging LED lighting up but no menu. > > > Trying to show the sequence of events: > > 1) the controllers are suspended: > > Jul 25 11:27:12 nemi kernel: [ 38.962792] uhci_hcd :00:1a.2: power > state changed by ACPI to D2 > Jul 25 11:27:12 nemi kernel: [ 39.006718] uhci_hcd :00:1d.0: power > state changed by ACPI to D2 > Jul 25 11:27:15 nemi kernel: [ 41.808471] uhci_hcd :00:1a.0: power > state changed by ACPI to D2 > Jul 25 11:27:15 nemi kernel: [ 41.824123] ehci_hcd :00:1a.7: power > state changed by ACPI to D2 > Jul 25 11:27:15 nemi kernel: [ 41.824194] ehci_hcd :00:1d.7: power > state changed by ACPI to D2 Here uhci controller is put into D2 [snip] > > Doing the same with commit 448bd857d reverted: > > > 1) the controllers are suspended (to state D3? instead of D2?): > > Jul 25 11:34:01 nemi kernel: [ 37.064955] uhci_hcd :00:1a.2: power > state changed by ACPI to D3 > Jul 25 11:34:01 nemi kernel: [ 37.106586] uhci_hcd :00:1d.0: power > state changed by ACPI to D3 > Jul 25 11:34:04 nemi kernel: [ 39.808329] uhci_hcd :00:1a.0: power > state changed by ACPI to D3 > Jul 25 11:34:04 nemi kernel: [ 39.840054] ehci_hcd :00:1d.7: power > state changed by ACPI to D3 > Jul 25 11:34:04 nemi kernel: [ 39.840068] ehci_hcd :00:1a.7: power > state changed by ACPI to D3 With commit reverted, the uhci_controller is put into D3 (ACPI D3cold). And the uhci controller on your system may not work properly under D2 state, while OK in D3 state, and the commit will make uhci controller choose D2 instead of D3. Please try following command line before testing. for f in /sys/bus/pci/devices/*/d3cold_allowed; do echo 1 > $f; done And please provide the output of the following command line. acpidump Best Regards, Huang Ying [snip] -- 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: usb : mass storage : short_not_ok for non usb3 udc
Hi
On Wed, Jul 25, 2012 at 6:33 PM, Michal Nazarewicz wrote:
> On Wed, 25 Jul 2012 14:53:00 +0200, Rajaram REGUPATHY
> wrote:
>>
>> The short_not_ok field is used by class drivers to indicate udc whether
>> short packet is expected during a particular transfer.
>> In case of mass storage, during command and status phase this field is set
>> as false and set to true during data phase.
>> musb driver uses this field to decide whether to program DMA for mode1.
>> This code is essential for musb driver to program DMA.
>
>
> There's one thing I don't get. The message talks about musb but the code
> checks for non Super Speed devices. So maybe the code is correct, maybe
> it's not, but the message does not really explain it (at least to me).
>
Please let me know if this thread sets the context ?
http://www.spinics.net/lists/linux-usb/msg64938.html
> (Also, you probably should wrap the message before 80th column.)
>
>
>> Signed-off-by: Balakumar Rajendran
>> Signed-off-by: Rajaram R
>> ---
>> drivers/usb/gadget/f_mass_storage.c |9 +
>> 1 files changed, 9 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/f_mass_storage.c
>> b/drivers/usb/gadget/f_mass_storage.c
>> index f67b453..db8bf4a 100644
>> --- a/drivers/usb/gadget/f_mass_storage.c
>> +++ b/drivers/usb/gadget/f_mass_storage.c
>> @@ -878,6 +878,7 @@ static int do_write(struct fsg_common *common)
>> unsigned intamount;
>> ssize_t nwritten;
>> int rc;
>> + struct usb_gadget *gadget = common->cdev->gadget;
>> if (curlun->ro) {
>> curlun->sense_data = SS_WRITE_PROTECTED; @@ -960,6 +961,8
>> @@ static int do_write(struct fsg_common *common)
>> * the bulk-out maxpacket size.
>> */
>> set_bulk_out_req_length(common, bh, amount);
>> + if (!gadget_is_superspeed(gadget))
>> + bh->outreq->short_not_ok = 1;
>> if (!start_out_transfer(common, bh))
>> /* Dunno what to do if common->fsg is NULL
>> */
>> return -EIO;
>> @@ -1584,6 +1587,7 @@ static int throw_away_data(struct fsg_common
>> *common)
>> struct fsg_buffhd *bh;
>> u32 amount;
>> int rc;
>> + struct usb_gadget *gadget = common->cdev->gadget;
>> for (bh = common->next_buffhd_to_drain;
>> bh->state != BUF_STATE_EMPTY || common->usb_amount_left > 0;
>> @@ -1617,6 +1621,8 @@ static int throw_away_data(struct fsg_common *common)
>> * the bulk-out maxpacket size.
>> */
>> set_bulk_out_req_length(common, bh, amount);
>> + if (!gadget_is_superspeed(gadget))
>> + bh->outreq->short_not_ok = 1;
>> if (!start_out_transfer(common, bh))
>> /* Dunno what to do if common->fsg is NULL
>> */
>> return -EIO;
>> @@ -2292,6 +2298,7 @@ static int get_next_command(struct fsg_common
>> *common) {
>> struct fsg_buffhd *bh;
>> int rc = 0;
>> + struct usb_gadget *gadget = common->cdev->gadget;
>> /* Wait for the next buffer to become available */
>> bh = common->next_buffhd_to_fill;
>> @@ -2303,6 +2310,8 @@ static int get_next_command(struct fsg_common
>> *common)
>> /* Queue a request to read a Bulk-only CBW */
>> set_bulk_out_req_length(common, bh, US_BULK_CB_WRAP_LEN);
>> + if (!gadget_is_superspeed(gadget))
>> + bh->outreq->short_not_ok = 0;
>> if (!start_out_transfer(common, bh))
>> /* Don't know what to do if common->fsg is NULL */
>> return -EIO;
>
>
> --
> Best regards, _ _
> .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
> ..o | Computer Science, Michał “mina86” Nazarewicz(o o)
> ooo +--ooO--(_)--Ooo--
>
> --
> 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: bisected regression, v3.5 -> next-20120724: PCI PM causes USB hotplug failure
huang ying writes: > Hi, Bjorn, > > Thank you very much for your detailed information. > > On Wed, Jul 25, 2012 at 5:58 PM, Bjørn Mork wrote: >> Huang Ying writes: >>> On Wed, 2012-07-25 at 06:08 +0200, Bjørn Mork wrote: Enabling autosuspend for USB causes hotplug failure in the current linux-next. Newly plugged devices are not detected at all until the port/controller is manually powered on by writing "on" to power/control. Testing is pretty simple: 1) for f in /sys/bus/usb/devices/*/power/control; do echo auto > $f; done >>> >>> Have you done: >>> >>> for f in /sys/bus/pci/devices/*/power/confol; do echo auto > $f; done >>> >>> ? >>> >>> If not, the pci device will not be suspended at all. >> >> Yes, sorry for missing that. I had it automatically enabled. Yes, >> autosuspend for the PCI device and all child devices must be enabled for >> the device to be suspended at all, of course. >> 2) wait for the controllers to suspend 3) plugin a new USB device >>> >>> After plugin the new USB device, is there anything in dmesg? >> >> No. Absolutely nothing, so the USB devices is not enumerated. Another >> indication of the same: Plugging a device like an Android phone, which >> normally detects being connected to a host and presents a device type >> menu to the user, results in the charging LED lighting up but no menu. >> >> >> Trying to show the sequence of events: >> >> 1) the controllers are suspended: >> >> Jul 25 11:27:12 nemi kernel: [ 38.962792] uhci_hcd :00:1a.2: power >> state changed by ACPI to D2 >> Jul 25 11:27:12 nemi kernel: [ 39.006718] uhci_hcd :00:1d.0: power >> state changed by ACPI to D2 >> Jul 25 11:27:15 nemi kernel: [ 41.808471] uhci_hcd :00:1a.0: power >> state changed by ACPI to D2 >> Jul 25 11:27:15 nemi kernel: [ 41.824123] ehci_hcd :00:1a.7: power >> state changed by ACPI to D2 >> Jul 25 11:27:15 nemi kernel: [ 41.824194] ehci_hcd :00:1d.7: power >> state changed by ACPI to D2 > > Here uhci controller is put into D2 > > [snip] >> >> Doing the same with commit 448bd857d reverted: >> >> >> 1) the controllers are suspended (to state D3? instead of D2?): >> >> Jul 25 11:34:01 nemi kernel: [ 37.064955] uhci_hcd :00:1a.2: power >> state changed by ACPI to D3 >> Jul 25 11:34:01 nemi kernel: [ 37.106586] uhci_hcd :00:1d.0: power >> state changed by ACPI to D3 >> Jul 25 11:34:04 nemi kernel: [ 39.808329] uhci_hcd :00:1a.0: power >> state changed by ACPI to D3 >> Jul 25 11:34:04 nemi kernel: [ 39.840054] ehci_hcd :00:1d.7: power >> state changed by ACPI to D3 >> Jul 25 11:34:04 nemi kernel: [ 39.840068] ehci_hcd :00:1a.7: power >> state changed by ACPI to D3 > > With commit reverted, the uhci_controller is put into D3 (ACPI D3cold). > > And the uhci controller on your system may not work properly under D2 > state, while OK in D3 state, and the commit will make uhci controller > choose D2 instead of D3. > > Please try following command line before testing. > > for f in /sys/bus/pci/devices/*/d3cold_allowed; do echo 1 > $f; done That made it work. The USB controllers ended up in D4 though: Jul 25 15:52:33 nemi kernel: [ 152.753280] uhci_hcd :00:1a.0: power state changed by ACPI to D0 Jul 25 15:52:33 nemi kernel: [ 152.753453] uhci_hcd :00:1a.0: setting latency timer to 64 Jul 25 15:52:33 nemi kernel: [ 152.753619] uhci_hcd :00:1a.0: power state changed by ACPI to D4 Jul 25 15:52:33 nemi kernel: [ 152.753875] uhci_hcd :00:1a.1: setting latency timer to 64 Jul 25 15:52:33 nemi kernel: [ 152.754153] uhci_hcd :00:1a.2: power state changed by ACPI to D0 Jul 25 15:52:33 nemi kernel: [ 152.754279] uhci_hcd :00:1a.2: setting latency timer to 64 Jul 25 15:52:33 nemi kernel: [ 152.754432] uhci_hcd :00:1a.2: power state changed by ACPI to D4 Jul 25 15:52:33 nemi kernel: [ 152.754668] ehci_hcd :00:1a.7: setting latency timer to 64 Jul 25 15:52:33 nemi kernel: [ 152.768089] ehci_hcd :00:1a.7: power state changed by ACPI to D4 Jul 25 15:52:33 nemi kernel: [ 152.768573] uhci_hcd :00:1d.0: power state changed by ACPI to D0 Jul 25 15:52:33 nemi kernel: [ 152.768726] uhci_hcd :00:1d.0: setting latency timer to 64 Jul 25 15:52:33 nemi kernel: [ 152.768891] uhci_hcd :00:1d.0: power state changed by ACPI to D4 Jul 25 15:52:33 nemi kernel: [ 152.769144] uhci_hcd :00:1d.1: setting latency timer to 64 Jul 25 15:52:33 nemi kernel: [ 152.769530] uhci_hcd :00:1d.2: setting latency timer to 64 Jul 25 15:52:33 nemi kernel: [ 152.769902] ehci_hcd :00:1d.7: setting latency timer to 64 Jul 25 15:52:33 nemi kernel: [ 152.784189] ehci_hcd :00:1d.7: power state changed by ACPI to D4 was that expected? Anyway, waking up the controller from this state by plugging a USB device works, so it's a perfectly OK workaround. Is this something that could/should be implemented as a system specific quirk, or is the proble
Re: usb : mass storage : short_not_ok for non usb3 udc
On Wed, 25 Jul 2012, Rajaram REGUPATHY wrote:
> The short_not_ok field is used by class drivers to indicate udc whether short
> packet is expected during a particular transfer.
> In case of mass storage, during command and status phase this field is set as
> false and set to true during data phase.
> musb driver uses this field to decide whether to program DMA for mode1.
> This code is essential for musb driver to program DMA.
>
> Signed-off-by: Balakumar Rajendran
> Signed-off-by: Rajaram R
> ---
> drivers/usb/gadget/f_mass_storage.c |9 +
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/usb/gadget/f_mass_storage.c
> b/drivers/usb/gadget/f_mass_storage.c
> index f67b453..db8bf4a 100644
> --- a/drivers/usb/gadget/f_mass_storage.c
> +++ b/drivers/usb/gadget/f_mass_storage.c
> @@ -878,6 +878,7 @@ static int do_write(struct fsg_common *common)
> unsigned intamount;
> ssize_t nwritten;
> int rc;
> + struct usb_gadget *gadget = common->cdev->gadget;
>
> if (curlun->ro) {
> curlun->sense_data = SS_WRITE_PROTECTED; @@ -960,6 +961,8 @@
> static int do_write(struct fsg_common *common)
>* the bulk-out maxpacket size.
>*/
> set_bulk_out_req_length(common, bh, amount);
> + if (!gadget_is_superspeed(gadget))
> + bh->outreq->short_not_ok = 1;
This new code is added everywhere set_bulk_out_req_length() is called.
You might as well move it into that function; set short_not_ok whenever
the gadget isn't running at SuperSpeed and the requested length is >=
the block size.
> if (!start_out_transfer(common, bh))
> /* Dunno what to do if common->fsg is NULL */
> return -EIO;
The patch is wrong. Later on in the function we have:
/* Did something go wrong with the transfer? */
if (bh->outreq->status != 0) {
curlun->sense_data = SS_COMMUNICATION_FAILURE;
curlun->sense_data_info =
file_offset >> curlun->blkbits;
curlun->info_valid = 1;
break;
}
We don't want the "if" statement to succeed when the status is nonzero
because a short packet was received.
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: usb : mass storage : short_not_ok for non usb3 udc
On Wed, 25 Jul 2012, Rajaram R wrote: > Hi > > On Wed, Jul 25, 2012 at 6:33 PM, Michal Nazarewicz wrote: > > On Wed, 25 Jul 2012 14:53:00 +0200, Rajaram REGUPATHY > > wrote: > >> > >> The short_not_ok field is used by class drivers to indicate udc whether > >> short packet is expected during a particular transfer. > >> In case of mass storage, during command and status phase this field is set > >> as false and set to true during data phase. > >> musb driver uses this field to decide whether to program DMA for mode1. > >> This code is essential for musb driver to program DMA. > > > > > > There's one thing I don't get. The message talks about musb but the code > > checks for non Super Speed devices. So maybe the code is correct, maybe > > it's not, but the message does not really explain it (at least to me). > > > Please let me know if this thread sets the context ? > > http://www.spinics.net/lists/linux-usb/msg64938.html I don't understand this either. What's wrong with setting short_not_ok while at SuperSpeed? It shouldn't force the use of a bounce buffer. In any case, the patch description should be improved to explain more clearly what the real problem is. It should also be more clear about what the existing code does and what changes the patch makes; your description above seems to say that the existing code sets short_not_ok during the data phase. 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
[PATCH] USB: ohci-pxa27x: add DT bindings
Add DT bindings to the ohci-pxa27x driver and some documentation.
Successfully tested on a PXA3xx board.
Signed-off-by: Daniel Mack
---
Documentation/devicetree/bindings/usb/pxa-usb.txt | 31 ++
drivers/usb/host/ohci-pxa27x.c| 68 +
2 files changed, 99 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/pxa-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/pxa-usb.txt
b/Documentation/devicetree/bindings/usb/pxa-usb.txt
new file mode 100644
index 000..d623012
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/pxa-usb.txt
@@ -0,0 +1,31 @@
+PXA USB controllers
+
+OHCI
+
+Required properties:
+ - compatible: Should be "mrvl,pxa-ohci" for USB controllers
+ used in host mode.
+
+Optional properties:
+ - "mrvl,enable-port1", "mrvl,enable-port2", "mrvl,enable-port3"
+ If present, enables the appropriate USB port of the controller.
+ - "mrvl,port-mode" selects the mode of the ports:
+ 1 = PMM_NPS_MODE
+ 2 = PMM_GLOBAL_MODE
+ 3 = PMM_PERPORT_MODE
+ - "mrvl,power-sense-low" - power sense pin is low-active.
+ - "mrvl,power-control-low" - power control pin is low-active.
+ - "mrvl,no-oc-protection" - disable over-current protection.
+ - "mrvl,oc-mode-perport" - enable per-port over-current protection.
+ - "mrvl,power_on_delay" Power On to Power Good time - in ms.
+
+Example:
+
+ usb0: ohci@4c00 {
+ compatible = "mrvl,pxa-ohci", "usb-ohci";
+ reg = <0x4c00 0x10>;
+ interrupts = <18>;
+ mrvl,enable-port1;
+ mrvl,port-mode = <2>; /* PMM_GLOBAL_MODE */
+ };
+
diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index e1a3cc6..9cec49f 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -23,6 +23,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -272,6 +274,67 @@ static void pxa27x_stop_hc(struct pxa27x_ohci *ohci,
struct device *dev)
clk_disable_unprepare(ohci->clk);
}
+#ifdef CONFIG_OF
+static const struct of_device_id pxa_ohci_dt_ids[] = {
+ { .compatible = "mrvl,pxa-ohci" },
+ { }
+};
+
+MODULE_DEVICE_TABLE(of, pxa_ohci_dt_ids);
+
+static u64 pxa_ohci_dma_mask = DMA_BIT_MASK(32);
+
+static int __devinit ohci_pxa_of_init(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct pxaohci_platform_data *pdata;
+ u32 tmp;
+
+ if (!np)
+ return 0;
+
+ /* Right now device-tree probed devices don't get dma_mask set.
+* Since shared usb code relies on it, set it here for now.
+* Once we have dma capability bindings this can go away.
+*/
+ if (!pdev->dev.dma_mask)
+ pdev->dev.dma_mask = &pxa_ohci_dma_mask;
+
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ if (of_get_property(np, "mrvl,enable-port1", NULL))
+ pdata->flags |= ENABLE_PORT1;
+ if (of_get_property(np, "mrvl,enable-port2", NULL))
+ pdata->flags |= ENABLE_PORT2;
+ if (of_get_property(np, "mrvl,enable-port3", NULL))
+ pdata->flags |= ENABLE_PORT3;
+ if (of_get_property(np, "mrvl,port-sense-low", NULL))
+ pdata->flags |= POWER_SENSE_LOW;
+ if (of_get_property(np, "mrvl,power-control-low", NULL))
+ pdata->flags |= POWER_CONTROL_LOW;
+ if (of_get_property(np, "mrvl,no-oc-protection", NULL))
+ pdata->flags |= NO_OC_PROTECTION;
+ if (of_get_property(np, "mrvl,oc-mode-perport", NULL))
+ pdata->flags |= OC_MODE_PERPORT;
+ if (!of_property_read_u32(np, "mrvl,power-on-delay", &tmp))
+ pdata->power_on_delay = tmp;
+ if (!of_property_read_u32(np, "mrvl,port-mode", &tmp))
+ pdata->port_mode = tmp;
+ if (!of_property_read_u32(np, "mrvl,power-budget", &tmp))
+ pdata->power_budget = tmp;
+
+ pdev->dev.platform_data = pdata;
+
+ return 0;
+}
+#else
+static int __devinit ohci_pxa_of_init(struct platform_device *pdev)
+{
+ return 0;
+}
+#endif
/*-*/
@@ -297,6 +360,10 @@ int usb_hcd_pxa27x_probe (const struct hc_driver *driver,
struct platform_device
struct resource *r;
struct clk *usb_clk;
+ retval = ohci_pxa_of_init(pdev);
+ if (retval)
+ return retval;
+
inf = pdev->dev.platform_data;
if (!inf)
@@ -544,6 +611,7 @@ static struct platform_driver ohci_hcd_pxa27x_driver = {
.driver = {
.name = "pxa27x-ohci",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(pxa_ohci_dt_ids),
#ifdef CONFIG_PM
.pm = &ohci_hcd_pxa27x_pm_ops,
#e
RE: [RFC] usb: gadget: Ensure correct functionality for gadgets that wish to 'connect' only when directed by user-space
Hi Laurent, > -Original Message- > From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] > Sent: Wednesday, July 25, 2012 6:41 PM > To: Bhupesh SHARMA > Cc: ba...@ti.com; linux-usb@vger.kernel.org; gre...@linuxfoundation.org > Subject: Re: [RFC] usb: gadget: Ensure correct functionality for > gadgets that wish to 'connect' only when directed by user-space > > Hi Bhupesh, > > On Wednesday 25 July 2012 15:06:37 Bhupesh SHARMA wrote: > > [snip] > > > It's been almost a month since this RFC was circulated. > > As no comments have been received so far, > > http://www.spinics.net/lists/linux-usb/msg66755.html > > Mails get lost sometime. :) No no, I went through your reply in detail but got confused by the line: "The overall approach looks good. I'll let Felipe comment on the details, he's much more knowledgeable than me about UDC.", so I thought I need to wait for Felipe, others to comment to take this further. Since it's been a long time now, I sent another mail to the list to seek Felipe/other's comment on the same, so that we can finalize a approach. Sorry if I caused any unnecessary noise on the list. > BTW, http://www.spinics.net/lists/linux-usb/msg65828.html might be > related. > Yes this patch also seems related and does similar to what my resent patch does (same can be viewed here: http://www.spinics.net/lists/linux-usb/msg66338.html) I am open to any good approach which solves this issue, which is an long-pending issue for gadgets like webcam and obex. > > can I assume that this approach is fine and send a formal patch for > the same > > and will that be acceptable for inclusion in mainline? > > -- > Regards, > > Laurent Pinchart Regards, Bhupesh -- 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: usb : mass storage : short_not_ok for non usb3 udc
Hi Alan On Wed, Jul 25, 2012 at 9:07 PM, Alan Stern wrote: > On Wed, 25 Jul 2012, Rajaram R wrote: > >> Hi >> >> On Wed, Jul 25, 2012 at 6:33 PM, Michal Nazarewicz wrote: >> > On Wed, 25 Jul 2012 14:53:00 +0200, Rajaram REGUPATHY >> > wrote: >> >> >> >> The short_not_ok field is used by class drivers to indicate udc whether >> >> short packet is expected during a particular transfer. >> >> In case of mass storage, during command and status phase this field is set >> >> as false and set to true during data phase. >> >> musb driver uses this field to decide whether to program DMA for mode1. >> >> This code is essential for musb driver to program DMA. >> > >> > >> > There's one thing I don't get. The message talks about musb but the code >> > checks for non Super Speed devices. So maybe the code is correct, maybe >> > it's not, but the message does not really explain it (at least to me). >> > >> Please let me know if this thread sets the context ? >> >> http://www.spinics.net/lists/linux-usb/msg64938.html > > I don't understand this either. What's wrong with setting short_not_ok > while at SuperSpeed? It shouldn't force the use of a bounce buffer. > I have just brought back some code removed by patch "usb: fix mass storage gadgets to work with Synopsys UDC". > In any case, the patch description should be improved to explain more > clearly what the real problem is. It should also be more clear about Sure. Will update the description > what the existing code does and what changes the patch makes; your > description above seems to say that the existing code sets short_not_ok > during the data phase. > > Alan Stern > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: ohci-pxa27x: add DT bindings
On Wednesday 25 July 2012, Daniel Mack wrote: > --- /dev/null > +++ b/Documentation/devicetree/bindings/usb/pxa-usb.txt > @@ -0,0 +1,31 @@ > +PXA USB controllers > + > +OHCI > + > +Required properties: > + - compatible: Should be "mrvl,pxa-ohci" for USB controllers > + used in host mode. > + > +Optional properties: > + - "mrvl,enable-port1", "mrvl,enable-port2", "mrvl,enable-port3" > + If present, enables the appropriate USB port of the controller. > + - "mrvl,port-mode" selects the mode of the ports: > + 1 = PMM_NPS_MODE > + 2 = PMM_GLOBAL_MODE > + 3 = PMM_PERPORT_MODE > + - "mrvl,power-sense-low" - power sense pin is low-active. > + - "mrvl,power-control-low" - power control pin is low-active. > + - "mrvl,no-oc-protection" - disable over-current protection. > + - "mrvl,oc-mode-perport" - enable per-port over-current protection. > + - "mrvl,power_on_delay" Power On to Power Good time - in ms. > We're in the process of changing all uses of "mrvl" to "marvell" so we use the same everywhere. Please change this too. For the various flags, I wonder which ones actually depend on the board configuration and which ones depend only on the SoC variant that is used. If they are just different between SoCs, I would recommend using different "compatible" values and looking up the entire flags word. If most of them are board specific, better leave it like you have now. For the three enable-port* values, I think using a bit mask would be slightly nicer, but your version is fine too. Arnd -- 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: usb : mass storage : short_not_ok for non usb3 udc
On Wed, 25 Jul 2012, Rajaram R wrote: > >> > There's one thing I don't get. The message talks about musb but the code > >> > checks for non Super Speed devices. So maybe the code is correct, maybe > >> > it's not, but the message does not really explain it (at least to me). > >> > > >> Please let me know if this thread sets the context ? > >> > >> http://www.spinics.net/lists/linux-usb/msg64938.html > > > > I don't understand this either. What's wrong with setting short_not_ok > > while at SuperSpeed? It shouldn't force the use of a bounce buffer. > > > > I have just brought back some code removed by patch "usb: fix mass > storage gadgets to work with Synopsys UDC". Maybe while bringing it back you can remove the checks for SuperSpeed. Is there any reason to keep them? 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 00/13] firmware loader: introduce cache/uncache firmware
On Wed, Jul 25, 2012 at 5:35 AM, Ming Lei wrote:
>
> The below patch should fix the problem above.
Actually, I think we could make this even simpler.
There's nothing wrong with saying "user mode is enabled" *just* before
we unthaw things, if we also simply guarantee that there is no
sleeping lock or similar that we might get caught on (causing a
deadlock or other untimely waking) before we've actually thawed
everything.
So *if* the only problem wrt the USB hub code comes from this area,
then I think the solution might be as simple as just moving the
"usermodehelper_enable()" up a few lines, with a comment. Something
like the *untested* and whitespace-damaged thing below..
Rafael? Who has one of those isight things and has seen the warning to test?
Linus
---
diff --git a/kernel/power/process.c b/kernel/power/process.c
index 19db29f67558..5bf50e488196 100644
--- a/kernel/power/process.c
+++ b/kernel/power/process.c
@@ -181,6 +181,12 @@ void thaw_processes(void)
pm_freezing = false;
pm_nosig_freezing = false;
+ /*
+* User mode helper are available again (or will be,
+* modulo scheduling)
+*/
+ usermodehelper_enable();
+
oom_killer_enable();
printk("Restarting tasks ... ");
@@ -193,8 +199,6 @@ void thaw_processes(void)
} while_each_thread(g, p);
read_unlock(&tasklist_lock);
- usermodehelper_enable();
-
schedule();
printk("done.\n");
}
--
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: usb : mass storage : short_not_ok for non usb3 udc
On Wed, Jul 25, 2012 at 10:51 PM, Alan Stern wrote: > On Wed, 25 Jul 2012, Rajaram R wrote: > >> >> > There's one thing I don't get. The message talks about musb but the >> >> > code >> >> > checks for non Super Speed devices. So maybe the code is correct, maybe >> >> > it's not, but the message does not really explain it (at least to me). >> >> > >> >> Please let me know if this thread sets the context ? >> >> >> >> http://www.spinics.net/lists/linux-usb/msg64938.html >> > >> > I don't understand this either. What's wrong with setting short_not_ok >> > while at SuperSpeed? It shouldn't force the use of a bounce buffer. >> > >> >> I have just brought back some code removed by patch "usb: fix mass >> storage gadgets to work with Synopsys UDC". > > Maybe while bringing it back you can remove the checks for SuperSpeed. > Is there any reason to keep them? Looks like it is required for DWC. > > 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: the dreaded "needs XHCI_TRUST_TX_LENGTH quirk" returns
On Wed, Jul 25, 2012 at 02:31:20AM -0700, Matthew Hall wrote: > Hello Sarah et. al, Hi Matthew! It helps if you Cc my email address in your mail. Otherwise it might get lost in a separate folder and ignored for a couple days. > I am attempting to use an Inland brand USB 3.0 multi-purpose Memory Card > reader, which I purchased from Micro Center, along with a Patriot EP Series > SDXC UHS-1 64 GB memory card, which I purchased from Fry's. I am connecting > these to my Debian unstable system running Linux 3.4.6 kernel self-compiled. > > I am getting the dreaded "xhci_hcd :03:00.0: WARN Successful completion > on > short TX: needs XHCI_TRUST_TX_LENGTH quirk?" looping infinitely into my dmesg > buffer. I saw this discussed on July 2nd and 3rd in a thread Sarah > cross-posted onto linux-usb which originated from Gary Miller's bug report to > her privately. > > http://marc.info/?l=linux-usb&m=134125692925503 > > I pre-apologize to Alan in advance if I have butchered the USB terminology as > he pointed out in the earlier thread. ;-) > > Card Reader Specs: > > http://www.microcenter.com/single_product_results.phtml?product_id=0371800 > > I read through all of the messages in this original thread and collected all > of the various troubleshooting items requested, while the USB and XHCI debug > were enabled: > > 1) the configuration of my self-compiled Linux 3.4.6 kernel, and dmesg from > booting the system > > 2) lspci -vvv and lspci -vvv -n Ok, it looks like the same version of Etron host controller as Gary: 03:00.0 USB controller: Etron Technology, Inc. EJ168 USB 3.0 Host Controller (rev 01) (prog-if 30 [XHCI]) 03:00.0 0c03: 1b6f:7023 (rev 01) (prog-if 30 [XHCI]) Have you tried applying the patch I sent to Gary for testing? I think that will remove the messages. > 3) dmesg and lsusb -v from plugging the reader into the SuperSpeed (3.0) port > > 4) dmesg and lsusb -v from plugging the reader into the HighSpeed (2.0) port > > I placed all of these here: > > http://www.mhcomputing.net/tmp/xhci-bug/ > > I would really like to fix whatever is causing this, as it's not very good > for > performance, stability, and reliability if something is putting this > tremendously many printk's into the ring constantly. It's liable to cause > some > kind of crash or corrupt the data going to and from the SDXC card. I don't think it will corrupt the data. It will just slow down reading data from the card. But you have a point about the messages filling up dmesg. I'll send you a patch shortly that rate limits the warning messages. > I would also politely suggest that each USB device should only squawk about > this problem once per insertion rather than repeatedly, to avoid making > things > go haywire in the kernel with all these tight-looped printk's. The patch will make the printk only trigger once per USB host controller. The USB device really has nothing to do with these messages; it's the host that gives back the confusing completion code and untransferred buffer length. > So, is there anything else which is needed to clear up the problem in my > environment or is this enough data as-is? I never saw a clear answer if Gary > Miller's problem got fixed or not. Hopefully Gary could provide some > clarification what happened to his issue over the long haul. The patch fixed Gary's printk warnings, but didn't fix his overall issue. I need to follow up on that. So, can you test with the patch that I sent Gary and make sure that the printks go away and USB devices work properly under the Etron host? Then revert the patch, apply the printk rate limiting patch I'll send you shortly, and make sure you only get the SHORT_TX quirk message once. Sarah Sharp -- 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
[RFT] xhci: Rate-limit XHCI_TRUST_TX_LENGTH quirk warning.
When we encounter an xHCI host that needs the XHCI_TRUST_TX_LENGTH quirk, the xHCI driver ends up spewing messages about the quirk into dmesg every time a short packet occurs. Change the xHCI driver to rate-limit such warnings. This patch should be backported to kernels as old as 2.6.36, that contain a backported version of commit 1530bbc6272d9da1e39ef8e06190d42c13a02733 "xhci: Add new short TX quirk for Fresco Logic host." Signed-off-by: Sarah Sharp Reported-by: Matthew Hall Reported-by: Gary E. Miller Cc: sta...@vger.kernel.org --- drivers/usb/host/xhci-ring.c |4 ++-- drivers/usb/host/xhci.h |2 ++ 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 8275645..0c93f5d 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -2073,8 +2073,8 @@ static int handle_tx_event(struct xhci_hcd *xhci, if (xhci->quirks & XHCI_TRUST_TX_LENGTH) trb_comp_code = COMP_SHORT_TX; else - xhci_warn(xhci, "WARN Successful completion on short TX: " - "needs XHCI_TRUST_TX_LENGTH quirk?\n"); + xhci_warn_ratelimited(xhci, + "WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?\n"); case COMP_SHORT_TX: break; case COMP_STOP: diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h index 55c0785..96f49db 100644 --- a/drivers/usb/host/xhci.h +++ b/drivers/usb/host/xhci.h @@ -1537,6 +1537,8 @@ static inline struct usb_hcd *xhci_to_hcd(struct xhci_hcd *xhci) dev_err(xhci_to_hcd(xhci)->self.controller , fmt , ## args) #define xhci_warn(xhci, fmt, args...) \ dev_warn(xhci_to_hcd(xhci)->self.controller , fmt , ## args) +#define xhci_warn_ratelimited(xhci, fmt, args...) \ + dev_warn_ratelimited(xhci_to_hcd(xhci)->self.controller , fmt , ## args) /* TODO: copied from ehci.h - can be refactored? */ /* xHCI spec says all registers are little endian */ -- 1.7.9 -- 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 5/5] usb: gadget/uvc: Add support for 'USB_GADGET_DELAYED_STATUS' response for a set_intf(alt-set 1) command
Hi Laurent, > -Original Message- > From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] > Sent: Saturday, July 07, 2012 6:37 PM > To: Bhupesh SHARMA > Cc: linux-usb@vger.kernel.org; ba...@ti.com; linux- > me...@vger.kernel.org; gre...@linuxfoundation.org > Subject: Re: [PATCH 5/5] usb: gadget/uvc: Add support for > 'USB_GADGET_DELAYED_STATUS' response for a set_intf(alt-set 1) command > > Hi Bhupesh, > > On Tuesday 03 July 2012 23:47:14 Bhupesh SHARMA wrote: > > On Wednesday, June 20, 2012 3:19 AM Laurent Pinchart wrote: > > > On Friday 01 June 2012 15:08:58 Bhupesh Sharma wrote: > > > > This patch adds the support in UVC webcam gadget design for > providing > > > > USB_GADGET_DELAYED_STATUS in response to a set_interface(alt > setting 1) > > > > command issue by the Host. > > > > > > > > The current UVC webcam gadget design generates a STREAMON event > > > > corresponding to a set_interface(alt setting 1) command from the > Host. > > > > This STREAMON event will eventually be routed to a real V4L2 > device. > > > > > > > > To start video streaming, it may be required to perform some > register > > > > writes to a camera sensor device over slow external busses like > I2C or > > > > SPI. So, it makes sense to ensure that we delay the STATUS stage > of the > > > > set_interface(alt setting 1) command. > > > > > > > > Otherwise, a lot of ISOC IN tokens sent by the Host will be > replied to > > > > by zero-length packets by the webcam device. On certain Hosts > this may > > > > even> lead to ISOC URBs been cancelled from the Host side. > > > > > > > > So, as soon as we finish doing all the "streaming" related stuff > on the > > > > real V4L2 device, we call a STREAMON ioctl on the UVC side and > from here > > > > we call the 'usb_composite_setup_continue' function to complete > the > > > > status stage of the set_interface(alt setting 1) command. > > > > > > That sounds good, thank you for coming up with a solution to this > > > issue. > > > > > > > Further, we need to ensure that we queue no video buffers on the > UVC > > > > webcam gadget, until we de-queue a video buffer from the V4L2 > device. > > > > Also, we need to enable UVC video related stuff at the first QBUF > ioctl > > > > call itself, as the application will call the STREAMON on UVC > side only > > > > when it has dequeued sufficient buffers from the V4L2 side and > queued > > > > them to the UVC gadget. So, the UVC video enable stuff cannot be > done in > > > > STREAMON ioctl call. > > > > > > Is that really required ? First of all, the userspace application > can > > > queue buffers before it calls VIDIOC_STREAMON. Assuming it doesn't, > the > > > gadget driver calls uvc_video_enable() at streamon time, which then > calls > > > uvc_video_pump(). As no buffer is queued, the function will return > without > > > queuing any USB request, so we shouldn't have any problem. > > > > I think that while working with a real video device, it will be > possible to > > queue a buffer at UVC end only when atleast one buffer has been > dequeued > > from the V4L2 device side (and has some real data). > > > > This is because for a uvc buffer being queued we need to pass the > v4l2 > > buffer's buffer.start and buffer.length in the qbuf call at UVC side. > > I agree with you, queuing a buffer on the UVC gadget side will usually > require > starting capture and waiting for a frame on a V4L2 source device. > However, > unless I'm mistaken, the UVC gadget code already deals with that > situation > correctly. As I explained, when your application calls VIDIOC_STREAMON > on the > UVC gadget, the uvc_video_pump() will not find any V4L2 buffer to be > transferred, and will return without queuing any URB. It will then be > called > again by VIDIOC_QBUF, and will then start the transfer. > > Adding support for USB_GADGET_DELAYED_STATUS is thus a good idea, but > the pre- > streaming state is in my opinion not needed. Feel free to prove me > wrong > though :-) I did some extensive tests and also managed to reproduce the problem Georgios mentioned regarding UVC not able to stream when an application using the webcam is stopped and started again (sorry Georgios, it took me some time to finish all the checks, and thanks for pointing out the issue) You are right the PRE_STREAMING state is not required. I will resend the patches 4/5 and 5/5 of this patchset with all your comments addressed in the next couple of days. > > > > For the same we add two more UVC states: > > > > - PRE_STREAMING : not even a single buffer has been queued > to UVC > > > > - BUF_QUEUED_STREAMING_OFF : one video buffer has been > queued to UVC > > > > but we have not yet enabled STREAMING on UVC > side. > > > > > > > > Signed-off-by: Bhupesh Sharma > > -- Regards, Bhupesh -- 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.
RE: [PATCH 4/5] usb: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework
Hi Laurent,
Sorry for the delayed reply. I thought of performing some extensive tests
before replying to your comments.
> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
> Sent: Saturday, July 07, 2012 5:28 PM
> To: Bhupesh SHARMA
> Cc: linux-usb@vger.kernel.org; ba...@ti.com; linux-
> me...@vger.kernel.org; gre...@linuxfoundation.org
> Subject: Re: [PATCH 4/5] usb: gadget/uvc: Port UVC webcam gadget to use
> videobuf2 framework
>
> Hi Bhupesh,
>
> On Tuesday 03 July 2012 23:42:59 Bhupesh SHARMA wrote:
> > Hi Laurent,
> >
> > Thanks for your review and sorry for being late with my replies.
> > I have a lot on my plate these days :)
>
> No worries, I'm no less busy anyway :-)
:)
> > On Tuesday, June 19, 2012 4:19 AM Laurent Pinchart wrote:
> > > On Friday 01 June 2012 15:08:57 Bhupesh Sharma wrote:
>
> [snip]
>
> > > > diff --git a/drivers/usb/gadget/uvc_queue.c
> > > > b/drivers/usb/gadget/uvc_queue.c
> > > > index 0cdf89d..907ece8 100644
> > > > --- a/drivers/usb/gadget/uvc_queue.c
> > > > +++ b/drivers/usb/gadget/uvc_queue.c
>
> [snip]
>
> > > > +static int uvc_buffer_prepare(struct vb2_buffer *vb)
> > > > {
>
> [snip]
>
> > > > + buf->state = UVC_BUF_STATE_QUEUED;
> > > > + buf->mem = vb2_plane_vaddr(vb, 0);
> > > > + buf->length = vb2_plane_size(vb, 0);
> > > > + if (vb->v4l2_buf.type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
> > > > + buf->bytesused = 0;
> > > > + else
> > > > + buf->bytesused = vb2_get_plane_payload(vb, 0);
> > >
> > > The driver doesn't support the capture type at the moment so this
> might be
> > > a bit overkill, but I think it's a good idea to support capture in
> the
> > > queue imeplementation. I plan to try and merge the uvcvideo and
> uvcgadget
> > > queue implementations at some point.
> >
> > I am thinking now whether we really need to support UVC as a capture
> type
> > video device. The use cases that I can think of now, UVC always seems
> to be
> > a output device.
> >
> > Any use-case where you think UVC can be a capture device?
>
> It could be useful for video output devices. I know of at least one UVC
> output
> device (albeit not Linux-based), which I used to implement and test
> video
> output in the UVC host driver. As the host driver supports video output
> devices, supporting them in the gadget driver can be useful as well.
Ok.
> > > > + return 0;
> > > > +}
>
> [snip]
>
> > > > static struct uvc_buffer *
> > > > uvc_queue_next_buffer(struct uvc_video_queue *queue, struct
> uvc_buffer
> > > > *buf)
>
> [snip]
>
> > > > - buf->buf.sequence = queue->sequence++;
> > > > - do_gettimeofday(&buf->buf.timestamp);
> > >
> > > videobuf2 doesn't fill the sequence number or timestamp fields, so
> you
> > > either need to keep this here or move it to the caller.
> >
> > Yes I think these fields are only valid for video capture devices.
> > As my use-case was only an output UVC video device, I didn't add the
> same.
> >
> > Please let me know your views on the same.
>
> Good point. The spec isn't clear about this, so I'd rather keep these
> two
> lines for now.
Ok, sure.
> > > > + vb2_set_plane_payload(&buf->buf, 0, buf->bytesused);
> > > > + vb2_buffer_done(&buf->buf, VB2_BUF_STATE_DONE);
> > > >
> > > > - wake_up(&buf->wait);
> > > >
> > > > return nextbuf;
> > > > }
>
> [snip]
>
> > > > diff --git a/drivers/usb/gadget/uvc_v4l2.c
> > > b/drivers/usb/gadget/uvc_v4l2.c
> > > > index f6e083b..9c2b45b 100644
> > > > --- a/drivers/usb/gadget/uvc_v4l2.c
> > > > +++ b/drivers/usb/gadget/uvc_v4l2.c
> > > > @@ -144,20 +144,23 @@ uvc_v4l2_release(struct file *file)
> > > >
> > > > struct uvc_device *uvc = video_get_drvdata(vdev);
> > > > struct uvc_file_handle *handle = to_uvc_file_handle(file-
> > > >
> > > >private_data);
> > > >
> > > > struct uvc_video *video = handle->device;
> > > >
> > > > + int ret;
> > > >
> > > > uvc_function_disconnect(uvc);
> > > >
> > > > - uvc_video_enable(video, 0);
> > > > - mutex_lock(&video->queue.mutex);
> > > > - if (uvc_free_buffers(&video->queue) < 0)
> > > > - printk(KERN_ERR "uvc_v4l2_release: Unable to free "
> > > > - "buffers.\n");
> > > > - mutex_unlock(&video->queue.mutex);
> > > > + ret = uvc_video_enable(video, 0);
> > > > + if (ret < 0) {
> > > > + printk(KERN_ERR "uvc_v4l2_release: uvc video disable
> > >
> > > failed\n");
> > >
> > > > + return ret;
> > > > + }
> > >
> > > This shouldn't prevent uvc_v4l2_release() from succeeding. In
> practive
> > > uvc_video_enable(0) will never fail, so you can remove the error
> check.
> >
> > To be honest, I saw once the 'uvc_video_enable(0)' failing that's why
> I
> > added this check. I don't remember the exact instance of the failure,
> but
> > I can try to check again and then will come back on the same.
>
> The only reason I see for uvc_video_enable(video, 0) to fail is if the
> video
> endpoi
Re: controlling record light on camera
I'm not getting much traction with this approach. I get:
Turning light on now...[73405.001220] usb 1-1.2: usbfs: process 30710
(badusbled) did not claim interface 0 before use
libusb_control_transfer() returned -1
I'm not familiar enough with libusb to know what this error means.
--Adam
On 07/23/2012 05:22 PM, Peter Stuge wrote:
Adam Wozniak wrote:
so I know this is a "control output" message with "setup" values
bmRequestType=21, bRequest=01, wValue=0900, wIndex=0700, wLength=0005
and data of 01,0N,00,00,0a where N=1 for on and N=0 for off
How would I send this same packet from a userspace application?
Install a libusb-1.0 API provider. I suggest libusb-1.0.9 because I
maintain libusb. I think the author of the kernel driver for your
camera works on the libusbx fork of libusb, so he will probably
suggest libusbx-1.0.12.
--8<-- test.c
/* build: gcc $(pkg-config --cflags --libs libusb-1.0) -o test test.c */
/* run:
* ./test 0 # turns light off
* ./test # with non-zero parameter or without parameter turns light on
*/
#include
#include
#include
#define TIMEOUT_MS 1000 /* arbitrarily chosen millisecond timeout */
/* USB Video Class 1.1 documentation:
* http://www.usb.org/developers/devclass_docs/USB_Video_Class_1_1_090711.zip
*/
#define UVC_SET_CUR 0x01 /* bRequest per USB Video Class 1.1 Table A-8 */
#define UVC_CS 0x09 /* See about wValue in USB Video Class 1.1 Table 4-4 */
int main(int argc, char *argv[]) {
int ret = 1;
libusb_device_handle *dh;
unsigned char data[] = { 0x01, 0x01, 0x00, 0x00, 0x0a };
if (libusb_init(NULL))
return ret;
dh = libusb_open_device_with_vid_pid(NULL, 0x046d, 0x0825);
if (NULL == dh) {
fprintf(stderr, "open vid:pid 046d:0825 failed\n");
goto done;
}
if (argc > 1)
data[1] = !!atoi(argv[1]);
printf("Turning light %s now...\n", data[1] ? "on" : "off");
fflush(stdout);
ret = libusb_control_transfer(dh,
LIBUSB_REQUEST_TYPE_CLASS | LIBUSB_RECIPIENT_INTERFACE, /* 0x21 */
UVC_SET_CUR, (UVC_CS << 8), 0x0700, data, sizeof(data), TIMEOUT_MS);
if (ret) {
fprintf(stderr, "libusb_control_transfer() returned %d\n", ret);
goto done;
}
ret = 0;
done:
if (dh)
libusb_close(dh);
libusb_exit(NULL);
return ret;
}
-->8--
BUT! Since this is a recipient=interface request it is not
neccessarily true that wIndex=0x0700 is always correct.
wIndex identifies *which* interface in the device that the request is
destined for, and if any other of the many interface altsettings has
been set by the Linux uvc driver then the 0x0700 will not
neccessarily be correct anymore.
AND! Since this is a type=class request with recipient=interface this
code goes behind the back of the kernel driver which is handling the
interface, and that could lead to corrupted internal state in the
kernel, since it is reasonable for a driver to expect that noone else
will go poking at the device!
The above is very portable code because it uses libusb. But since the
particular USB interface is a standard device class it is worth
investigating if the Linux kernel driver for the USB video class
already exposes this LED control operation to userspace in some way.
The kernel has LED infrastructure, so the kernel driver might already
expose your camera LED there. That would be the appropriate and
friendly (to the driver) way to control the LED in Linux. Of course
it does not work on other systems.
//Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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: usb : mass storage : short_not_ok for non usb3 udc
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb- > ow...@vger.kernel.org] On Behalf Of Alan Stern > > On Wed, 25 Jul 2012, Rajaram R wrote: > > > >> > There's one thing I don't get. The message talks about musb but > > >> > the code checks for non Super Speed devices. So maybe the code > > >> > is correct, maybe it's not, but the message does not really explain it > > >> > (at > least to me). > > >> > > > >> Please let me know if this thread sets the context ? > > >> > > >> http://www.spinics.net/lists/linux-usb/msg64938.html > > > > > > I don't understand this either. What's wrong with setting > > > short_not_ok while at SuperSpeed? It shouldn't force the use of a > bounce buffer. > > > > > > > I have just brought back some code removed by patch "usb: fix mass > > storage gadgets to work with Synopsys UDC". > > Maybe while bringing it back you can remove the checks for SuperSpeed. > Is there any reason to keep them? Hi Alan, The problem only arises because at super-speed the MaxPacket size is 1024, which is greater than the sector size of 512. So the whole point of the patch is to fix the SuperSpeed operation, while allowing high-speed devices to operate as they always did. -- 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: bisected regression, v3.5 -> next-20120724: PCI PM causes USB hotplug failure
On Wednesday, July 25, 2012, Bjørn Mork wrote: > huang ying writes: > > > Hi, Bjorn, > > > > Thank you very much for your detailed information. > > > > On Wed, Jul 25, 2012 at 5:58 PM, Bjørn Mork wrote: > >> Huang Ying writes: > >>> On Wed, 2012-07-25 at 06:08 +0200, Bjørn Mork wrote: > Enabling autosuspend for USB causes hotplug failure in the current > linux-next. Newly plugged devices are not detected at all until the > port/controller is manually powered on by writing "on" to power/control. > Testing is pretty simple: > > 1) for f in /sys/bus/usb/devices/*/power/control; do echo auto > $f; > done > >>> > >>> Have you done: > >>> > >>> for f in /sys/bus/pci/devices/*/power/confol; do echo auto > $f; done > >>> > >>> ? > >>> > >>> If not, the pci device will not be suspended at all. > >> > >> Yes, sorry for missing that. I had it automatically enabled. Yes, > >> autosuspend for the PCI device and all child devices must be enabled for > >> the device to be suspended at all, of course. > >> > 2) wait for the controllers to suspend > 3) plugin a new USB device > >>> > >>> After plugin the new USB device, is there anything in dmesg? > >> > >> No. Absolutely nothing, so the USB devices is not enumerated. Another > >> indication of the same: Plugging a device like an Android phone, which > >> normally detects being connected to a host and presents a device type > >> menu to the user, results in the charging LED lighting up but no menu. > >> > >> > >> Trying to show the sequence of events: > >> > >> 1) the controllers are suspended: > >> > >> Jul 25 11:27:12 nemi kernel: [ 38.962792] uhci_hcd :00:1a.2: power > >> state changed by ACPI to D2 > >> Jul 25 11:27:12 nemi kernel: [ 39.006718] uhci_hcd :00:1d.0: power > >> state changed by ACPI to D2 > >> Jul 25 11:27:15 nemi kernel: [ 41.808471] uhci_hcd :00:1a.0: power > >> state changed by ACPI to D2 > >> Jul 25 11:27:15 nemi kernel: [ 41.824123] ehci_hcd :00:1a.7: power > >> state changed by ACPI to D2 > >> Jul 25 11:27:15 nemi kernel: [ 41.824194] ehci_hcd :00:1d.7: power > >> state changed by ACPI to D2 > > > > Here uhci controller is put into D2 > > > > [snip] > >> > >> Doing the same with commit 448bd857d reverted: > >> > >> > >> 1) the controllers are suspended (to state D3? instead of D2?): > >> > >> Jul 25 11:34:01 nemi kernel: [ 37.064955] uhci_hcd :00:1a.2: power > >> state changed by ACPI to D3 > >> Jul 25 11:34:01 nemi kernel: [ 37.106586] uhci_hcd :00:1d.0: power > >> state changed by ACPI to D3 > >> Jul 25 11:34:04 nemi kernel: [ 39.808329] uhci_hcd :00:1a.0: power > >> state changed by ACPI to D3 > >> Jul 25 11:34:04 nemi kernel: [ 39.840054] ehci_hcd :00:1d.7: power > >> state changed by ACPI to D3 > >> Jul 25 11:34:04 nemi kernel: [ 39.840068] ehci_hcd :00:1a.7: power > >> state changed by ACPI to D3 > > > > With commit reverted, the uhci_controller is put into D3 (ACPI D3cold). > > > > And the uhci controller on your system may not work properly under D2 > > state, while OK in D3 state, and the commit will make uhci controller > > choose D2 instead of D3. > > > > Please try following command line before testing. > > > > for f in /sys/bus/pci/devices/*/d3cold_allowed; do echo 1 > $f; done > > That made it work. The USB controllers ended up in D4 though: The D4 really is D3_cold. I'll send a patch to fix the state labeling. Thanks, Rafael > Jul 25 15:52:33 nemi kernel: [ 152.753280] uhci_hcd :00:1a.0: power > state changed by ACPI to D0 > Jul 25 15:52:33 nemi kernel: [ 152.753453] uhci_hcd :00:1a.0: setting > latency timer to 64 > Jul 25 15:52:33 nemi kernel: [ 152.753619] uhci_hcd :00:1a.0: power > state changed by ACPI to D4 > Jul 25 15:52:33 nemi kernel: [ 152.753875] uhci_hcd :00:1a.1: setting > latency timer to 64 > Jul 25 15:52:33 nemi kernel: [ 152.754153] uhci_hcd :00:1a.2: power > state changed by ACPI to D0 > Jul 25 15:52:33 nemi kernel: [ 152.754279] uhci_hcd :00:1a.2: setting > latency timer to 64 > Jul 25 15:52:33 nemi kernel: [ 152.754432] uhci_hcd :00:1a.2: power > state changed by ACPI to D4 > Jul 25 15:52:33 nemi kernel: [ 152.754668] ehci_hcd :00:1a.7: setting > latency timer to 64 > Jul 25 15:52:33 nemi kernel: [ 152.768089] ehci_hcd :00:1a.7: power > state changed by ACPI to D4 > Jul 25 15:52:33 nemi kernel: [ 152.768573] uhci_hcd :00:1d.0: power > state changed by ACPI to D0 > Jul 25 15:52:33 nemi kernel: [ 152.768726] uhci_hcd :00:1d.0: setting > latency timer to 64 > Jul 25 15:52:33 nemi kernel: [ 152.768891] uhci_hcd :00:1d.0: power > state changed by ACPI to D4 > Jul 25 15:52:33 nemi kernel: [ 152.769144] uhci_hcd :00:1d.1: setting > latency timer to 64 > Jul 25 15:52:33 nemi kernel: [ 152.769530] uhci_hcd :00:1d.2: setting > latency timer to 64 > Jul 25 15:52:33 nemi kernel: [ 152.769902] ehci_hcd :0
Re: controlling record light on camera
Got now, thanks.
On 07/25/2012 11:39 AM, Adam Wozniak wrote:
I'm not getting much traction with this approach. I get:
Turning light on now...[73405.001220] usb 1-1.2: usbfs: process 30710
(badusbled) did not claim interface 0 before use
libusb_control_transfer() returned -1
I'm not familiar enough with libusb to know what this error means.
--Adam
On 07/23/2012 05:22 PM, Peter Stuge wrote:
Adam Wozniak wrote:
so I know this is a "control output" message with "setup" values
bmRequestType=21, bRequest=01, wValue=0900, wIndex=0700, wLength=0005
and data of 01,0N,00,00,0a where N=1 for on and N=0 for off
How would I send this same packet from a userspace application?
Install a libusb-1.0 API provider. I suggest libusb-1.0.9 because I
maintain libusb. I think the author of the kernel driver for your
camera works on the libusbx fork of libusb, so he will probably
suggest libusbx-1.0.12.
--8<-- test.c
/* build: gcc $(pkg-config --cflags --libs libusb-1.0) -o test test.c */
/* run:
* ./test 0 # turns light off
* ./test # with non-zero parameter or without parameter turns
light on
*/
#include
#include
#include
#define TIMEOUT_MS 1000 /* arbitrarily chosen millisecond timeout */
/* USB Video Class 1.1 documentation:
*
http://www.usb.org/developers/devclass_docs/USB_Video_Class_1_1_090711.zip
*/
#define UVC_SET_CUR 0x01 /* bRequest per USB Video Class 1.1 Table
A-8 */
#define UVC_CS 0x09 /* See about wValue in USB Video Class 1.1 Table
4-4 */
int main(int argc, char *argv[]) {
int ret = 1;
libusb_device_handle *dh;
unsigned char data[] = { 0x01, 0x01, 0x00, 0x00, 0x0a };
if (libusb_init(NULL))
return ret;
dh = libusb_open_device_with_vid_pid(NULL, 0x046d, 0x0825);
if (NULL == dh) {
fprintf(stderr, "open vid:pid 046d:0825 failed\n");
goto done;
}
if (argc > 1)
data[1] = !!atoi(argv[1]);
printf("Turning light %s now...\n", data[1] ? "on" : "off");
fflush(stdout);
ret = libusb_control_transfer(dh,
LIBUSB_REQUEST_TYPE_CLASS | LIBUSB_RECIPIENT_INTERFACE, /* 0x21 */
UVC_SET_CUR, (UVC_CS << 8), 0x0700, data, sizeof(data),
TIMEOUT_MS);
if (ret) {
fprintf(stderr, "libusb_control_transfer() returned %d\n", ret);
goto done;
}
ret = 0;
done:
if (dh)
libusb_close(dh);
libusb_exit(NULL);
return ret;
}
-->8--
BUT! Since this is a recipient=interface request it is not
neccessarily true that wIndex=0x0700 is always correct.
wIndex identifies *which* interface in the device that the request is
destined for, and if any other of the many interface altsettings has
been set by the Linux uvc driver then the 0x0700 will not
neccessarily be correct anymore.
AND! Since this is a type=class request with recipient=interface this
code goes behind the back of the kernel driver which is handling the
interface, and that could lead to corrupted internal state in the
kernel, since it is reasonable for a driver to expect that noone else
will go poking at the device!
The above is very portable code because it uses libusb. But since the
particular USB interface is a standard device class it is worth
investigating if the Linux kernel driver for the USB video class
already exposes this LED control operation to userspace in some way.
The kernel has LED infrastructure, so the kernel driver might already
expose your camera LED there. That would be the appropriate and
friendly (to the driver) way to control the LED in Linux. Of course
it does not work on other systems.
//Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 00/13] firmware loader: introduce cache/uncache firmware
On Wednesday, July 25, 2012, Linus Torvalds wrote:
> On Wed, Jul 25, 2012 at 5:35 AM, Ming Lei wrote:
> >
> > The below patch should fix the problem above.
>
> Actually, I think we could make this even simpler.
>
> There's nothing wrong with saying "user mode is enabled" *just* before
> we unthaw things, if we also simply guarantee that there is no
> sleeping lock or similar that we might get caught on (causing a
> deadlock or other untimely waking) before we've actually thawed
> everything.
>
> So *if* the only problem wrt the USB hub code comes from this area,
> then I think the solution might be as simple as just moving the
> "usermodehelper_enable()" up a few lines, with a comment. Something
> like the *untested* and whitespace-damaged thing below..
>
> Rafael?
Yes, we can do this I think.
> Who has one of those isight things and has seen the warning to test?
That I can't answer, sorry.
Rafael
> ---
> diff --git a/kernel/power/process.c b/kernel/power/process.c
> index 19db29f67558..5bf50e488196 100644
> --- a/kernel/power/process.c
> +++ b/kernel/power/process.c
> @@ -181,6 +181,12 @@ void thaw_processes(void)
> pm_freezing = false;
> pm_nosig_freezing = false;
>
> + /*
> +* User mode helper are available again (or will be,
> +* modulo scheduling)
> +*/
> + usermodehelper_enable();
> +
> oom_killer_enable();
>
> printk("Restarting tasks ... ");
> @@ -193,8 +199,6 @@ void thaw_processes(void)
> } while_each_thread(g, p);
> read_unlock(&tasklist_lock);
>
> - usermodehelper_enable();
> -
> schedule();
> printk("done.\n");
> }
>
>
--
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: usb : mass storage : short_not_ok for non usb3 udc
On Wed, 25 Jul 2012, Rajaram R wrote: > On Wed, Jul 25, 2012 at 10:51 PM, Alan Stern > wrote: > > On Wed, 25 Jul 2012, Rajaram R wrote: > > > >> >> > There's one thing I don't get. The message talks about musb but the > >> >> > code > >> >> > checks for non Super Speed devices. So maybe the code is correct, > >> >> > maybe > >> >> > it's not, but the message does not really explain it (at least to me). > >> >> > > >> >> Please let me know if this thread sets the context ? > >> >> > >> >> http://www.spinics.net/lists/linux-usb/msg64938.html > >> > > >> > I don't understand this either. What's wrong with setting short_not_ok > >> > while at SuperSpeed? It shouldn't force the use of a bounce buffer. > >> > > >> > >> I have just brought back some code removed by patch "usb: fix mass > >> storage gadgets to work with Synopsys UDC". > > > > Maybe while bringing it back you can remove the checks for SuperSpeed. > > Is there any reason to keep them? > > Looks like it is required for DWC. Please explain why it is required for DWC. I don't understand. 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
[PATCH] PCI / PM: Fix messages printed by acpi_pci_set_power_state()
If a PCI device is put into D3_cold by acpi_bus_set_power(),
the message printed by acpi_pci_set_power_state() says that its
power state has been changed to D4, which doesn't make sense.
In turn, if the device is put into D3_hot, the message says just
"D3" without specifying which variant of D3 it is.
Fix that by using an array of state names corresponding to the
PCI device power states instead of building the state name from
the numeric value corresponding to the given state directly.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/pci-acpi.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
Index: linux/drivers/pci/pci-acpi.c
===
--- linux.orig/drivers/pci/pci-acpi.c
+++ linux/drivers/pci/pci-acpi.c
@@ -265,9 +265,17 @@ static int acpi_pci_set_power_state(stru
error = acpi_bus_set_power(handle, state_conv[state]);
}
- if (!error)
- dev_printk(KERN_INFO, &dev->dev,
- "power state changed by ACPI to D%d\n", state);
+ if (!error) {
+ static const char *state_name[] = {
+ [PCI_D0] = "D0",
+ [PCI_D1] = "D1",
+ [PCI_D2] = "D2",
+ [PCI_D3hot] = "D3hot",
+ [PCI_D3cold] = "D3cold"
+ };
+ dev_info(&dev->dev, "power state changed by ACPI to %s\n",
+state_name[state]);
+ }
return error;
}
--
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: usb : mass storage : short_not_ok for non usb3 udc
On Wed, 25 Jul 2012, Paul Zimmerman wrote: > > > > I don't understand this either. What's wrong with setting > > > > short_not_ok while at SuperSpeed? It shouldn't force the use of a > > bounce buffer. > > > > > > > > > > I have just brought back some code removed by patch "usb: fix mass > > > storage gadgets to work with Synopsys UDC". > > > > Maybe while bringing it back you can remove the checks for SuperSpeed. > > Is there any reason to keep them? > > Hi Alan, > > The problem only arises because at super-speed the MaxPacket size is > 1024, which is greater than the sector size of 512. So the whole point of > the patch is to fix the SuperSpeed operation, while allowing high-speed > devices to operate as they always did. Don't the mass-storage drivers already operate correctly at SuperSpeed? If not, what goes wrong? Besides, how could the patch possibly affect SuperSpeed operation? Everything it does is protected by if (!gadget_is_superspeed(gadget)) So I'm afraid I don't understand your point. 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
add ZTE EV_DO to a proper driver
hello there,
i have an usb modem zte ev-do that i used with kernel from 2.6.29 up to 3.5.
since 3.5, i got the following message:
[77496.664090] usb 5-2: udev 10, busnum 5, minor = 521
[77496.664097] usb 5-2: New USB device found, idVendor=19d2, idProduct=
[77496.664102] usb 5-2: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[77496.664107] usb 5-2: Product: ZTE CDMA Tech
[77496.664112] usb 5-2: Manufacturer: ZTE, Incorporated
[77496.664226] usb 5-2: usb_probe_device
[77496.664232] usb 5-2: configuration #1 chosen from 1 choice
[77496.667119] usb 5-2: adding 5-2:1.0 (config #1, interface 0)
[77496.670161] usbserial_generic 5-2:1.0: usb_probe_interface
[77496.670169] usbserial_generic 5-2:1.0: usb_probe_interface - got id
[77496.670177] usbserial_generic 5-2:1.0: The "generic" usb-serial driver
is only for testing and
one-off prototypes.
[77496.670182] usbserial_generic 5-2:1.0: Tell linux-usb@vger.kernel.org to
add your device to a
proper driver.
[77496.670186] usbserial_generic 5-2:1.0: generic converter detected
[77496.670276] usb 5-2: generic converter now attached to ttyUSB0
i would be nice to have a driver for this device in the kernel.
the device is shipped with sources to build its modules. if i understand
correctly thet are released under GPL, so i attached them below.
this is portion of Makefile i used:
obj-m := ztemt.o
ztemt-objs := usb-serial.o bus.o generic.o ezusb.o zte_ev.o
usb-serial.c, bus.c, generic.c and ezusb.c are from the kernel source.
the patch against 3.5 i used for generic.c is also attached below.
and since 3.5, i've also got the following message:
[77694.270178] usb 5-2: uhci_result_common: failed with status 44
[77694.272174] usb 5-2: uhci_result_common: failed with status 44
/
/*-- begin zte_ev.c --*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include "zte_ev.h"
#define MAX_SETUP_DATA_SIZE 32
static int debug=0;
void zte_ev_usb_serial_init(struct usb_serial_port *port)
{
struct usb_serial *serial = port->serial;
int result = 0,len;
unsigned char *buf;
if (port->number != 0) return;
printk("zte ev enter---
");
buf = kmalloc(MAX_SETUP_DATA_SIZE, GFP_KERNEL);
/*send 1st ctl cmd(CTL21 22 01 00 00 00 00 00)*/
len = 0;
result = usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0),
0x22, 0x21,
0x0001, 0x, NULL, len,
HZ * USB_CTRL_GET_TIMEOUT);
dbg("result = %d
",result);
/*send 2st cmd and recieve data*/
/*
16.0 CTLa1 21 00 00 00 00 07 00
CLASS 25.1.0(5)
16.0 DI 00 96 00 00 00 00 08
*/
len = 0x0007;
result = usb_control_msg(serial->dev, usb_rcvctrlpipe(serial->dev, 0),
0x21, 0xa1,
0x, 0x, buf, len,
HZ * USB_CTRL_GET_TIMEOUT);
dbg("result = %d
",result);
if (result == len)
usb_serial_debug_data(debug,&port->dev, __FUNCTION__, len,buf);
/*send 3 cmd*/
/*
16.0 CTL21 20 00 00 00 00 07 00
CLASS 30.1.0
16.0 DO 80 25 00 00 00 00 08
.%. 30.2.0
*/
len = 0x0007;
buf[0]=0x80;
buf[1]=0x25;
buf[2]=0x00;
buf[3]=0x00;
buf[4]=0x00;
buf[5]=0x00;
buf[6]=0x08;
result = usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0),
0x20, 0x21,
0x, 0x, buf, len,
HZ * USB_CTRL_GET_TIMEOUT);
dbg("result = %d
",result);
if (result == len)
usb_serial_debug_data(debug,&port->dev, __FUNCTION__, len,buf);
/*send 4 cmd*/
/*
16.0 CTL21 22 03 00 00 00 00 00
*/
len = 0;
result = usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0),
0x22, 0x21,
0x0003, 0x, NULL, len,
HZ * USB_CTRL_GET_TIMEOUT);
dbg("result = %d
",result);
/*send 5 cmd*/
/*
16.0 CTLa1 21 00 00 00 00 07 00
CLASS 33.1.0
16.0 DI 80 25 00 00 00 00 08
*/
len = 0x0007;
result = usb_control_msg(serial->dev, usb_rcvctrlpipe(serial->dev, 0),
0x21, 0xa1,
Re: bisected regression, v3.5 -> next-20120724: PCI PM causes USB hotplug failure
On Wednesday, July 25, 2012, Bjørn Mork wrote: > huang ying writes: > > > Hi, Bjorn, > > > > Thank you very much for your detailed information. > > > > On Wed, Jul 25, 2012 at 5:58 PM, Bjørn Mork wrote: > >> Huang Ying writes: > >>> On Wed, 2012-07-25 at 06:08 +0200, Bjørn Mork wrote: > Enabling autosuspend for USB causes hotplug failure in the current > linux-next. Newly plugged devices are not detected at all until the > port/controller is manually powered on by writing "on" to power/control. > Testing is pretty simple: > > 1) for f in /sys/bus/usb/devices/*/power/control; do echo auto > $f; > done > >>> > >>> Have you done: > >>> > >>> for f in /sys/bus/pci/devices/*/power/confol; do echo auto > $f; done > >>> > >>> ? > >>> > >>> If not, the pci device will not be suspended at all. > >> > >> Yes, sorry for missing that. I had it automatically enabled. Yes, > >> autosuspend for the PCI device and all child devices must be enabled for > >> the device to be suspended at all, of course. > >> > 2) wait for the controllers to suspend > 3) plugin a new USB device > >>> > >>> After plugin the new USB device, is there anything in dmesg? > >> > >> No. Absolutely nothing, so the USB devices is not enumerated. Another > >> indication of the same: Plugging a device like an Android phone, which > >> normally detects being connected to a host and presents a device type > >> menu to the user, results in the charging LED lighting up but no menu. > >> > >> > >> Trying to show the sequence of events: > >> > >> 1) the controllers are suspended: > >> > >> Jul 25 11:27:12 nemi kernel: [ 38.962792] uhci_hcd :00:1a.2: power > >> state changed by ACPI to D2 > >> Jul 25 11:27:12 nemi kernel: [ 39.006718] uhci_hcd :00:1d.0: power > >> state changed by ACPI to D2 > >> Jul 25 11:27:15 nemi kernel: [ 41.808471] uhci_hcd :00:1a.0: power > >> state changed by ACPI to D2 > >> Jul 25 11:27:15 nemi kernel: [ 41.824123] ehci_hcd :00:1a.7: power > >> state changed by ACPI to D2 > >> Jul 25 11:27:15 nemi kernel: [ 41.824194] ehci_hcd :00:1d.7: power > >> state changed by ACPI to D2 > > > > Here uhci controller is put into D2 > > > > [snip] > >> > >> Doing the same with commit 448bd857d reverted: > >> > >> > >> 1) the controllers are suspended (to state D3? instead of D2?): > >> > >> Jul 25 11:34:01 nemi kernel: [ 37.064955] uhci_hcd :00:1a.2: power > >> state changed by ACPI to D3 > >> Jul 25 11:34:01 nemi kernel: [ 37.106586] uhci_hcd :00:1d.0: power > >> state changed by ACPI to D3 > >> Jul 25 11:34:04 nemi kernel: [ 39.808329] uhci_hcd :00:1a.0: power > >> state changed by ACPI to D3 > >> Jul 25 11:34:04 nemi kernel: [ 39.840054] ehci_hcd :00:1d.7: power > >> state changed by ACPI to D3 > >> Jul 25 11:34:04 nemi kernel: [ 39.840068] ehci_hcd :00:1a.7: power > >> state changed by ACPI to D3 > > > > With commit reverted, the uhci_controller is put into D3 (ACPI D3cold). > > > > And the uhci controller on your system may not work properly under D2 > > state, while OK in D3 state, and the commit will make uhci controller > > choose D2 instead of D3. > > > > Please try following command line before testing. > > > > for f in /sys/bus/pci/devices/*/d3cold_allowed; do echo 1 > $f; done > > That made it work. The USB controllers ended up in D4 though: > > Jul 25 15:52:33 nemi kernel: [ 152.753280] uhci_hcd :00:1a.0: power > state changed by ACPI to D0 > Jul 25 15:52:33 nemi kernel: [ 152.753453] uhci_hcd :00:1a.0: setting > latency timer to 64 > Jul 25 15:52:33 nemi kernel: [ 152.753619] uhci_hcd :00:1a.0: power > state changed by ACPI to D4 > Jul 25 15:52:33 nemi kernel: [ 152.753875] uhci_hcd :00:1a.1: setting > latency timer to 64 > Jul 25 15:52:33 nemi kernel: [ 152.754153] uhci_hcd :00:1a.2: power > state changed by ACPI to D0 > Jul 25 15:52:33 nemi kernel: [ 152.754279] uhci_hcd :00:1a.2: setting > latency timer to 64 > Jul 25 15:52:33 nemi kernel: [ 152.754432] uhci_hcd :00:1a.2: power > state changed by ACPI to D4 > Jul 25 15:52:33 nemi kernel: [ 152.754668] ehci_hcd :00:1a.7: setting > latency timer to 64 > Jul 25 15:52:33 nemi kernel: [ 152.768089] ehci_hcd :00:1a.7: power > state changed by ACPI to D4 > Jul 25 15:52:33 nemi kernel: [ 152.768573] uhci_hcd :00:1d.0: power > state changed by ACPI to D0 > Jul 25 15:52:33 nemi kernel: [ 152.768726] uhci_hcd :00:1d.0: setting > latency timer to 64 > Jul 25 15:52:33 nemi kernel: [ 152.768891] uhci_hcd :00:1d.0: power > state changed by ACPI to D4 > Jul 25 15:52:33 nemi kernel: [ 152.769144] uhci_hcd :00:1d.1: setting > latency timer to 64 > Jul 25 15:52:33 nemi kernel: [ 152.769530] uhci_hcd :00:1d.2: setting > latency timer to 64 > Jul 25 15:52:33 nemi kernel: [ 152.769902] ehci_hcd :00:1d.7: setting > latency timer to 64 > Jul 25 15:52:33 nemi kernel: [ 152.784189] ehc
Re: [PATCH] PCI / PM: Fix messages printed by acpi_pci_set_power_state()
On Wed, 25 Jul 2012, Rafael J. Wysocki wrote:
>
> If a PCI device is put into D3_cold by acpi_bus_set_power(),
> the message printed by acpi_pci_set_power_state() says that its
> power state has been changed to D4, which doesn't make sense.
> In turn, if the device is put into D3_hot, the message says just
> "D3" without specifying which variant of D3 it is.
>
> Fix that by using an array of state names corresponding to the
> PCI device power states instead of building the state name from
> the numeric value corresponding to the given state directly.
>
> Signed-off-by: Rafael J. Wysocki
> ---
> drivers/pci/pci-acpi.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> Index: linux/drivers/pci/pci-acpi.c
> ===
> --- linux.orig/drivers/pci/pci-acpi.c
> +++ linux/drivers/pci/pci-acpi.c
> @@ -265,9 +265,17 @@ static int acpi_pci_set_power_state(stru
> error = acpi_bus_set_power(handle, state_conv[state]);
> }
>
> - if (!error)
> - dev_printk(KERN_INFO, &dev->dev,
> - "power state changed by ACPI to D%d\n", state);
> + if (!error) {
> + static const char *state_name[] = {
> + [PCI_D0] = "D0",
> + [PCI_D1] = "D1",
> + [PCI_D2] = "D2",
> + [PCI_D3hot] = "D3hot",
> + [PCI_D3cold] = "D3cold"
> + };
> + dev_info(&dev->dev, "power state changed by ACPI to %s\n",
> + state_name[state]);
> + }
How about using the pci_power_name macro defined in
include/linux/pci.h instead?
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
[PATCH] ueagle-atm: Declare MODULE_FIRMWARE usage
Cc: Matthieu CASTET
Cc: Stanislaw Gruszka
Cc: Greg Kroah-Hartman
Cc: linux-usb@vger.kernel.org
Signed-off-by: Tim Gardner
---
drivers/usb/atm/ueagle-atm.c | 79 +++---
1 file changed, 66 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/atm/ueagle-atm.c b/drivers/usb/atm/ueagle-atm.c
index d7e422d..e1f8b2c 100644
--- a/drivers/usb/atm/ueagle-atm.c
+++ b/drivers/usb/atm/ueagle-atm.c
@@ -307,6 +307,34 @@ enum {
#define FW_GET_BYTE(p) (*((__u8 *) (p)))
#define FW_DIR "ueagle-atm/"
+#define EAGLE_FIRMWARE FW_DIR "eagle.fw"
+#define ADI930_FIRMWARE FW_DIR "adi930.fw"
+#define EAGLE_I_FIRMWARE FW_DIR "eagleI.fw"
+#define EAGLE_II_FIRMWARE FW_DIR "eagleII.fw"
+#define EAGLE_III_FIRMWARE FW_DIR "eagleIII.fw"
+#define EAGLE_IV_FIRMWARE FW_DIR "eagleIV.fw"
+
+#define DSP4I_FIRMWARE FW_DIR "DSP4i.bin"
+#define DSP4P_FIRMWARE FW_DIR "DSP4p.bin"
+#define DSP9I_FIRMWARE FW_DIR "DSP9i.bin"
+#define DSP9P_FIRMWARE FW_DIR "DSP9p.bin"
+#define DSPEI_FIRMWARE FW_DIR "DSPei.bin"
+#define DSPEP_FIRMWARE FW_DIR "DSPep.bin"
+#define FPGA930_FIRMWARE FW_DIR "930-fpga.bin"
+
+#define CMV4P_FIRMWARE FW_DIR "CMV4p.bin"
+#define CMV4PV2_FIRMWARE FW_DIR "CMV4p.bin.v2"
+#define CMV4I_FIRMWARE FW_DIR "CMV4i.bin"
+#define CMV4IV2_FIRMWARE FW_DIR "CMV4i.bin.v2"
+#define CMV9P_FIRMWARE FW_DIR "CMV9p.bin"
+#define CMV9PV2_FIRMWARE FW_DIR "CMV9p.bin.v2"
+#define CMV9I_FIRMWARE FW_DIR "CMV9i.bin"
+#define CMV9IV2_FIRMWARE FW_DIR "CMV9i.bin.v2"
+#define CMVEP_FIRMWARE FW_DIR "CMVep.bin"
+#define CMVEPV2_FIRMWARE FW_DIR "CMVep.bin.v2"
+#define CMVEI_FIRMWARE FW_DIR "CMVei.bin"
+#define CMVEIV2_FIRMWARE FW_DIR "CMVei.bin.v2"
+
#define UEA_FW_NAME_MAX 30
#define NB_MODEM 4
@@ -694,26 +722,26 @@ err:
static int uea_load_firmware(struct usb_device *usb, unsigned int ver)
{
int ret;
- char *fw_name = FW_DIR "eagle.fw";
+ char *fw_name = EAGLE_FIRMWARE;
uea_enters(usb);
uea_info(usb, "pre-firmware device, uploading firmware\n");
switch (ver) {
case ADI930:
- fw_name = FW_DIR "adi930.fw";
+ fw_name = ADI930_FIRMWARE;
break;
case EAGLE_I:
- fw_name = FW_DIR "eagleI.fw";
+ fw_name = EAGLE_I_FIRMWARE;
break;
case EAGLE_II:
- fw_name = FW_DIR "eagleII.fw";
+ fw_name = EAGLE_II_FIRMWARE;
break;
case EAGLE_III:
- fw_name = FW_DIR "eagleIII.fw";
+ fw_name = EAGLE_III_FIRMWARE;
break;
case EAGLE_IV:
- fw_name = FW_DIR "eagleIV.fw";
+ fw_name = EAGLE_IV_FIRMWARE;
break;
}
@@ -869,19 +897,19 @@ static int request_dsp(struct uea_softc *sc)
if (UEA_CHIP_VERSION(sc) == EAGLE_IV) {
if (IS_ISDN(sc))
- dsp_name = FW_DIR "DSP4i.bin";
+ dsp_name = DSP4I_FIRMWARE;
else
- dsp_name = FW_DIR "DSP4p.bin";
+ dsp_name = DSP4P_FIRMWARE;
} else if (UEA_CHIP_VERSION(sc) == ADI930) {
if (IS_ISDN(sc))
- dsp_name = FW_DIR "DSP9i.bin";
+ dsp_name = DSP9I_FIRMWARE;
else
- dsp_name = FW_DIR "DSP9p.bin";
+ dsp_name = DSP9P_FIRMWARE;
} else {
if (IS_ISDN(sc))
- dsp_name = FW_DIR "DSPei.bin";
+ dsp_name = DSPEI_FIRMWARE;
else
- dsp_name = FW_DIR "DSPep.bin";
+ dsp_name = DSPEP_FIRMWARE;
}
ret = request_firmware(&sc->dsp_firm, dsp_name, &sc->usb_dev->dev);
@@ -1925,7 +1953,7 @@ static int load_XILINX_firmware(struct uea_softc *sc)
int ret, size, u, ln;
const u8 *pfw;
u8 value;
- char *fw_name = FW_DIR "930-fpga.bin";
+ char *fw_name = FPGA930_FIRMWARE;
uea_enters(INS_TO_USBDEV(sc));
@@ -2753,3 +2781,28 @@ module_usb_driver(uea_driver);
MODULE_AUTHOR("Damien Bergamini/Matthieu Castet/Stanislaw W. Gruszka");
MODULE_DESCRIPTION("ADI 930/Eagle USB ADSL Modem driver");
MODULE_LICENSE("Dual BSD/GPL");
+MODULE_FIRMWARE(EAGLE_FIRMWARE);
+MODULE_FIRMWARE(ADI930_FIRMWARE);
+MODULE_FIRMWARE(EAGLE_I_FIRMWARE);
+MODULE_FIRMWARE(EAGLE_II_FIRMWARE);
+MODULE_FIRMWARE(EAGLE_III_FIRMWARE);
+MODULE_FIRMWARE(EAGLE_IV_FIRMWARE);
+MODULE_FIRMWARE(DSP4I_FIRMWARE);
+MODULE_FIRMWARE(DSP4P_FIRMWARE);
+MODULE_FIRMWARE(DSP9I_FIRMWARE);
+MODULE_FIRMWARE(DSP9P_FIRMWARE);
+MODULE_FIRMWARE(DSPEI_FIRMWARE);
+MODULE_FIRMWARE(DSPEP_FIRMWARE);
+MODULE_FIRMWARE(FPGA930_FIRMWARE);
+MODULE_FIRMWARE(CMV4P_FIRMWARE);
+MODULE_FIRMWARE(CMV4PV2_FIRMWARE);
+MODULE_FIRMWARE(CMV4I_FIRMWARE);
+MODULE_FIRMWARE(CMV4IV2_FIRMWARE);
+MODULE_FIRMWARE(CMV9P_FIRMWARE);
+MODULE_FIRMWARE(CMV9PV2_FIRMWARE);
+MODULE_FIRMWARE(CMV9I
RE: usb : mass storage : short_not_ok for non usb3 udc
> From: Alan Stern [mailto:st...@rowland.harvard.edu] > Sent: Wednesday, July 25, 2012 12:48 PM > To: Paul Zimmerman > Cc: Rajaram R; Michal Nazarewicz; linux-usb@vger.kernel.org > Subject: RE: usb : mass storage : short_not_ok for non usb3 udc > > On Wed, 25 Jul 2012, Paul Zimmerman wrote: > > > > > > I don't understand this either. What's wrong with setting > > > > > short_not_ok while at SuperSpeed? It shouldn't force the use of a > > > bounce buffer. > > > > > > > > > > > > > I have just brought back some code removed by patch "usb: fix mass > > > > storage gadgets to work with Synopsys UDC". > > > > > > Maybe while bringing it back you can remove the checks for SuperSpeed. > > > Is there any reason to keep them? > > > > Hi Alan, > > > > The problem only arises because at super-speed the MaxPacket size is > > 1024, which is greater than the sector size of 512. So the whole point of > > the patch is to fix the SuperSpeed operation, while allowing high-speed > > devices to operate as they always did. > > Don't the mass-storage drivers already operate correctly at SuperSpeed? > If not, what goes wrong? > > Besides, how could the patch possibly affect SuperSpeed operation? > Everything it does is protected by > > if (!gadget_is_superspeed(gadget)) > > So I'm afraid I don't understand your point. Sorry for not being clear. The original patch: http://www.spinics.net/lists/linux-usb/msg52549.html was required to make mass-storage work with DWC3 at SuperSpeed. However, it apparently broke platforms like musb which depend on short-not-ok being set. The current patch fixes that, by setting short-not-ok if not running SuperSpeed. DWC3 will still work fine with this latest patch, since its problem was only with SuperSpeed. -- 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
[PATCH][update] PCI / PM: Fix messages printed by acpi_pci_set_power_state()
On Wednesday, July 25, 2012, Alan Stern wrote:
> On Wed, 25 Jul 2012, Rafael J. Wysocki wrote:
>
> >
> > If a PCI device is put into D3_cold by acpi_bus_set_power(),
> > the message printed by acpi_pci_set_power_state() says that its
> > power state has been changed to D4, which doesn't make sense.
> > In turn, if the device is put into D3_hot, the message says just
> > "D3" without specifying which variant of D3 it is.
> >
> > Fix that by using an array of state names corresponding to the
> > PCI device power states instead of building the state name from
> > the numeric value corresponding to the given state directly.
> >
> > Signed-off-by: Rafael J. Wysocki
> > ---
> > drivers/pci/pci-acpi.c | 14 +++---
> > 1 file changed, 11 insertions(+), 3 deletions(-)
> >
> > Index: linux/drivers/pci/pci-acpi.c
> > ===
> > --- linux.orig/drivers/pci/pci-acpi.c
> > +++ linux/drivers/pci/pci-acpi.c
> > @@ -265,9 +265,17 @@ static int acpi_pci_set_power_state(stru
> > error = acpi_bus_set_power(handle, state_conv[state]);
> > }
> >
> > - if (!error)
> > - dev_printk(KERN_INFO, &dev->dev,
> > - "power state changed by ACPI to D%d\n", state);
> > + if (!error) {
> > + static const char *state_name[] = {
> > + [PCI_D0] = "D0",
> > + [PCI_D1] = "D1",
> > + [PCI_D2] = "D2",
> > + [PCI_D3hot] = "D3hot",
> > + [PCI_D3cold] = "D3cold"
> > + };
> > + dev_info(&dev->dev, "power state changed by ACPI to %s\n",
> > +state_name[state]);
> > + }
>
> How about using the pci_power_name macro defined in
> include/linux/pci.h instead?
That's even better, I forgot that the macro was there. :-)
Updated patch follows.
Thanks,
Rafael
---
From: Rafael J. Wysocki
Subject: PCI / PM: Fix messages printed by acpi_pci_set_power_state()
If a PCI device is put into D3_cold by acpi_bus_set_power(),
the message printed by acpi_pci_set_power_state() says that its
power state has been changed to D4, which doesn't make sense.
In turn, if the device is put into D3_hot, the message simply
says "D3" without specifying the variant of the D3 state.
Fix this by using the pci_power_name() macro for printing the state
name instead of building it from the numeric value corresponding to
the given state directly.
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/pci-acpi.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux/drivers/pci/pci-acpi.c
===
--- linux.orig/drivers/pci/pci-acpi.c
+++ linux/drivers/pci/pci-acpi.c
@@ -266,8 +266,8 @@ static int acpi_pci_set_power_state(stru
}
if (!error)
- dev_printk(KERN_INFO, &dev->dev,
- "power state changed by ACPI to D%d\n", state);
+ dev_info(&dev->dev, "power state changed by ACPI to %s\n",
+pci_power_name(state));
return error;
}
--
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: usb : mass storage : short_not_ok for non usb3 udc
On Wed, 25 Jul 2012, Paul Zimmerman wrote: > > From: Alan Stern [mailto:st...@rowland.harvard.edu] > > Sent: Wednesday, July 25, 2012 12:48 PM > > To: Paul Zimmerman > > Cc: Rajaram R; Michal Nazarewicz; linux-usb@vger.kernel.org > > Subject: RE: usb : mass storage : short_not_ok for non usb3 udc > > > > On Wed, 25 Jul 2012, Paul Zimmerman wrote: > > > > > > > > I don't understand this either. What's wrong with setting > > > > > > short_not_ok while at SuperSpeed? It shouldn't force the use of a > > > > bounce buffer. > > > > > > > > > > > > > > > > I have just brought back some code removed by patch "usb: fix mass > > > > > storage gadgets to work with Synopsys UDC". > > > > > > > > Maybe while bringing it back you can remove the checks for SuperSpeed. > > > > Is there any reason to keep them? > > > > > > Hi Alan, > > > > > > The problem only arises because at super-speed the MaxPacket size is > > > 1024, which is greater than the sector size of 512. So the whole point of > > > the patch is to fix the SuperSpeed operation, while allowing high-speed > > > devices to operate as they always did. > > > > Don't the mass-storage drivers already operate correctly at SuperSpeed? > > If not, what goes wrong? > > > > Besides, how could the patch possibly affect SuperSpeed operation? > > Everything it does is protected by > > > > if (!gadget_is_superspeed(gadget)) > > > > So I'm afraid I don't understand your point. > > Sorry for not being clear. The original patch: > > http://www.spinics.net/lists/linux-usb/msg52549.html > > was required to make mass-storage work with DWC3 at SuperSpeed. > However, it apparently broke platforms like musb which depend on > short-not-ok being set. The current patch fixes that, by setting > short-not-ok if not running SuperSpeed. DWC3 will still work fine > with this latest patch, since its problem was only with SuperSpeed. Okay, that's fine. But it doesn't answer my earlier question: Is there really any need for the SuperSpeed checks in this patch? In other words, will DWC3 continue to work correctly if short_not_ok is set? 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: usb : mass storage : short_not_ok for non usb3 udc
> From: Alan Stern [mailto:st...@rowland.harvard.edu] > Sent: Wednesday, July 25, 2012 2:03 PM > > On Wed, 25 Jul 2012, Paul Zimmerman wrote: > > > > From: Alan Stern [mailto:st...@rowland.harvard.edu] > > > Sent: Wednesday, July 25, 2012 12:48 PM > > > To: Paul Zimmerman > > > Cc: Rajaram R; Michal Nazarewicz; linux-usb@vger.kernel.org > > > Subject: RE: usb : mass storage : short_not_ok for non usb3 udc > > > > > > On Wed, 25 Jul 2012, Paul Zimmerman wrote: > > > > > > > > > > I don't understand this either. What's wrong with setting > > > > > > > short_not_ok while at SuperSpeed? It shouldn't force the use of a > > > > > bounce buffer. > > > > > > > > > > > > > > > > > > > I have just brought back some code removed by patch "usb: fix mass > > > > > > storage gadgets to work with Synopsys UDC". > > > > > > > > > > Maybe while bringing it back you can remove the checks for SuperSpeed. > > > > > Is there any reason to keep them? > > > > > > > > Hi Alan, > > > > > > > > The problem only arises because at super-speed the MaxPacket size is > > > > 1024, which is greater than the sector size of 512. So the whole point > > > > of > > > > the patch is to fix the SuperSpeed operation, while allowing high-speed > > > > devices to operate as they always did. > > > > > > Don't the mass-storage drivers already operate correctly at SuperSpeed? > > > If not, what goes wrong? > > > > > > Besides, how could the patch possibly affect SuperSpeed operation? > > > Everything it does is protected by > > > > > > if (!gadget_is_superspeed(gadget)) > > > > > > So I'm afraid I don't understand your point. > > > > Sorry for not being clear. The original patch: > > > > http://www.spinics.net/lists/linux-usb/msg52549.html > > > > was required to make mass-storage work with DWC3 at SuperSpeed. > > However, it apparently broke platforms like musb which depend on > > short-not-ok being set. The current patch fixes that, by setting > > short-not-ok if not running SuperSpeed. DWC3 will still work fine > > with this latest patch, since its problem was only with SuperSpeed. > > Okay, that's fine. But it doesn't answer my earlier question: Is there > really any need for the SuperSpeed checks in this patch? > > In other words, will DWC3 continue to work correctly if short_not_ok is > set? Ah, sorry, I missed that. I think so, I don't think the DWC3 driver looks at the short-not-ok flag. But I haven't looked at that driver for a while, so we had better ask Felipe. Felipe? What do you say? -- 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: add ZTE EV_DO to a proper driver
On Wed, Jul 25, 2012 at 12:51:34PM -0700, nirinA raseliarison wrote: > hello there, > i have an usb modem zte ev-do that i used with kernel from 2.6.29 up to 3.5. > since 3.5, i got the following message: > > [77496.664090] usb 5-2: udev 10, busnum 5, minor = 521 > [77496.664097] usb 5-2: New USB device found, idVendor=19d2, > idProduct= > [77496.664102] usb 5-2: New USB device strings: Mfr=1, Product=2, > SerialNumber=0 > [77496.664107] usb 5-2: Product: ZTE CDMA Tech > [77496.664112] usb 5-2: Manufacturer: ZTE, Incorporated > [77496.664226] usb 5-2: usb_probe_device > [77496.664232] usb 5-2: configuration #1 chosen from 1 choice > [77496.667119] usb 5-2: adding 5-2:1.0 (config #1, interface 0) > [77496.670161] usbserial_generic 5-2:1.0: usb_probe_interface > [77496.670169] usbserial_generic 5-2:1.0: usb_probe_interface - got id > [77496.670177] usbserial_generic 5-2:1.0: The "generic" usb-serial driver > is only for testing and > one-off prototypes. > [77496.670182] usbserial_generic 5-2:1.0: Tell linux-usb@vger.kernel.org > to add your device to a > proper driver. > [77496.670186] usbserial_generic 5-2:1.0: generic converter detected > [77496.670276] usb 5-2: generic converter now attached to ttyUSB0 > > i would be nice to have a driver for this device in the kernel. > the device is shipped with sources to build its modules. if i understand > correctly thet are released under GPL, so i attached them below. > this is portion of Makefile i used: > > obj-m := ztemt.o > ztemt-objs := usb-serial.o bus.o generic.o ezusb.o zte_ev.o Ick, that's not really the "proper" way to support this device, but I can take the file below and write a real driver for it. Can you test a patch if I create it? Also, where did you find this patch and .c file? I'd like to give credit to the proper developers who first wrote it. And I never thought that this message would cause this kind of code to come out of the woodwork, thanks so much for sending it in. 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: New input driver for eBeam device (ask for review)
On Sun, Jul 22, 2012 at 05:28:12PM +0200, Yann Cantin wrote:
> /***
> * sysfs part
> */
>
> /*
> * screen min/max and H matrix coefs
> * _get return *current* value
> * _set set new value
> */
> #define DEVICE_MINMAX_ATTR(MM)
> \
> static ssize_t ebeam_##MM##_get(struct device *dev,
> \
> struct device_attribute *attr,
> \
> char *buf)
> \
> {
> \
> struct ebeam_device *ebeam = dev_get_drvdata(dev);
> \
>
> \
> return snprintf(buf, PAGE_SIZE, "%d\n", ebeam->cursetting.MM);
> \
> }
> \
> static ssize_t ebeam_##MM##_set(struct device *dev,
> \
> struct device_attribute *attr,
> \
> const char *buf,
> \
> size_t count)
> \
> {
> \
> struct ebeam_device *ebeam = dev_get_drvdata(dev);
> \
> int err, MM;
> \
>
> \
> err = kstrtoint(buf, 10, &MM);
> \
> if (err)
> \
> return err;
> \
>
> \
> ebeam->newsetting.MM = MM;
> \
> return count;
> \
> }
> \
> static DEVICE_ATTR(MM, S_IRUGO | S_IWUGO,
> \
>ebeam_##MM##_get,
> \
>ebeam_##MM##_set)
>
> DEVICE_MINMAX_ATTR(min_x);
> DEVICE_MINMAX_ATTR(max_x);
> DEVICE_MINMAX_ATTR(min_y);
> DEVICE_MINMAX_ATTR(max_y);
What are all of these custom sysfs files for? Are they needed? Who
reads them? Shouldn't all of this be handled through the input layer
instead?
You should also post this on the linux-input mailing list, the
developers there can help you out with how it should be integrated into
that subsystem.
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: bisected regression, v3.5 -> next-20120724: PCI PM causes USB hotplug failure
"Rafael J. Wysocki" writes: > This is not really necessary. The problem is the change of behavior I was > worried about some time ago. > > Namely, the device in question apparently doesn't support ACPI D3_hot, > so acpi_pm_device_sleep_state() returns D2 as the target state, where it > would return D3(cold) before the commit in question. > > To fix the regression, we'd need to reverse the current initial value of > the d3cold_allowed flag so that it is set to "true" by default and only > set to "false" for devices where we suspect there may be problems with > D3_cold (like PCI Express ports). Good. May I also request a few lines describing d3cold_allowed in e.g Documentation/ABI/testing/sysfs-bus-pci? I must admit that I thought that was the policy for any new sysfs file, but it seems that is only in the USB subsystem? Anyway, I believe it ought to be a requirement. If we are meant to tweak some knob, then we must known how and when to do so. If not, then why add it in the first place? Bjørn -- 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: Writing a driver for a not really HID compliant device
On Sun, Jul 22, 2012 at 07:35:58PM +0200, Marian Beermann wrote: > Hi, > > I have here a "Microsoft Sidewinder Strategic Commander". It's > basically a fancy joystick (two axis plus rotation and a dozen or so > buttons), but it's not HID compliant, i.e. I can only use it via > hidraw. > I already elaborated the "protocol" that it uses ( > https://gist.github.com/3131917 ) and found out, that > drivers/hid/hid-microsoft.c is probably the proper location for > this. > What have I done so far? I defined the product ID in > drivers/hid/hid-ids.h (USB_DEVICE_ID_SIDEWINDER_SC) and added an > entry to the id_table. Now I don't really now any further... my > experience in writing Windows device drivers doesn't really help > here :-) > > So here go my questions: > -The events intercepted by hidraw and written to /dev/hidrawX are > sent to the hid_driver.raw_event function, I guess? > -How do I tell the input subsystem what properties this device has? > I guess I need to do something in hid_driver.probe ...? Try asking this on the linux-input mailing list, the developers there can help you out better than we can. 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: [RFC] usb: gadget: Ensure correct functionality for gadgets that wish to 'connect' only when directed by user-space
Hi Bhupesh, On Thursday 26 July 2012 00:12:46 Bhupesh SHARMA wrote: > On Wednesday, July 25, 2012 6:41 PM Laurent Pinchart wrote: > > On Wednesday 25 July 2012 15:06:37 Bhupesh SHARMA wrote: > > > > [snip] > > > > > It's been almost a month since this RFC was circulated. > > > As no comments have been received so far, > > > > http://www.spinics.net/lists/linux-usb/msg66755.html > > > > Mails get lost sometime. > > :) > > No no, I went through your reply in detail but got confused by the line: > "The overall approach looks good. I'll let Felipe comment on the details, > he's much more knowledgeable than me about UDC.", so I thought I need to > wait for Felipe, others to comment to take this further. > > Since it's been a long time now, I sent another mail to the list to seek > Felipe/other's comment on the same, so that we can finalize a approach. I would like to hear Felipe's opinion as well. > Sorry if I caused any unnecessary noise on the list. No worries, pinging is totally appropriate. > > BTW, http://www.spinics.net/lists/linux-usb/msg65828.html might be > > related. > > Yes this patch also seems related and does similar to what my resent patch > does (same can be viewed here: > http://www.spinics.net/lists/linux-usb/msg66338.html) > > I am open to any good approach which solves this issue, which is an long- > pending issue for gadgets like webcam and obex. Strictly speaking your patch and the pullup refcount patch are independent, but I think both issues should be addressed in the same patch set as they're still related. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCH] USB merge for 3.6-rc1
The following changes since commit 84a1caf1453c3d44050bd22db958af4a7f99315c: Linux 3.5-rc7 (2012-07-14 15:40:28 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-3.6-rc1 for you to fetch changes up to e387ef5c47ddeaeaa3cbdc54424cdb7a28dae2c0: usb: Add USB_QUIRK_RESET_RESUME for all Logitech UVC webcams (2012-07-19 15:46:32 -0700) USB patches for 3.6-rc1 Here's the big USB patch set for the 3.6-rc1 merge window. Lots of little changes in here, primarily for gadget controllers and drivers. There's some scsi changes that I think also went in through the scsi tree, but they merge just fine. All of these patches have been in the linux-next tree for a while now. Signed-off-by: Greg Kroah-Hartman Alan Stern (28): USB: EHCI: define extension registers like normal ones EHCI: centralize controller suspend/resume EHCI: centralize controller initialization USB: EHCI: initialize data before resetting hardware USB: EHCI: remove unneeded suspend/resume code USB: EHCI: don't refcount QHs USB: EHCI: add symbolic constants for QHs USB: EHCI: rename "reclaim" USB: EHCI: add pointer to end of async-unlink list USB: EHCI: add new root-hub state: STOPPING USB: EHCI: introduce high-res timer USB: EHCI: use hrtimer for the periodic schedule USB: EHCI: return void instead of 0 USB: EHCI: remove PS3 status polling USB: EHCI: use hrtimer for async schedule USB: EHCI: use hrtimer for interrupt QH unlink USB: EHCI: use hrtimer for controller death USB: EHCI: use hrtimer for (s)iTD deallocation USB: EHCI: don't refcount iso_stream structures USB: EHCI: use hrtimer for the IAA watchdog USB: EHCI: unlink multiple async QHs together USB: EHCI: use hrtimer for unlinking empty async QHs USB: EHCI: don't lose events during a scan USB: EHCI: always scan each interrupt QH USB: EHCI: use hrtimer for the I/O watchdog USB: EHCI: simplify isochronous scanning USB: EHCI: fix up locking USB: EHCI: resolve some unlikely races Alexander Shishkin (1): usb: chipidea: remove unneeded NULL check Alexandre Pereira da Silva (6): USB: ohci-nxp: add usbd and otg clock initialization usb: gadget: lpc32xx_udc: move clock init to clock framework usb: gadget: lpc32xx_udc: Propagate devicetree to gadget drivers usb: gadget: s3c-hsotg: Propagate devicetree to gadget drivers usb: gadget: fsl_udc: Propagate devicetree to gadget drivers usb: gadget: at91_udc: Propagate devicetree to gadget drivers Ben Minerds (5): USB: serial: keyspan: Fix spacing around conditional. USB: serial: keyspan: Fixed space around equals. USB: serial: keyspan: Fixed space near open parenthesis. USB: serial: keyspan: Removed trailing whitespace. USB: serial: keyspan: Removed unrequired parentheses. Bhupesh Sharma (3): usb: gadget: uvc: Fix string descriptor STALL issue when multiple uvc functions are added to a configuration usb: gadget: uvc: Use macro for interrupt endpoint status size instead of using a MAGIC number usb: gadget: uvc: Add super-speed support to UVC webcam gadget Bill Pemberton (2): USB: serial: Remove unused s_priv variable USB: serial: Remove unused serial_priv variable Bjørn Mork (9): USB: allow match on bInterfaceNumber USB: cdc-wdm: QMI devices are now handled by qmi_wwan USB: qcserial: consolidate usb_set_interface calls USB: qcserial: centralize probe exit path USB: qcserial: make probe more flexible USB: qcserial: support generic Qualcomm serial ports USB: qcserial: adding Sierra Wireless devices USB: sierra: QMI mode MC7710 moved to qcserial USB: option: add ZTE MF821D Daniel Mack (1): usb: gadget: hidg: register OUT INT endpoint for SET_REPORT Du, ChangbinX (1): testusb: expose looping forever option "l" to user Fabio Estevam (4): usb: fsl_mxc_udc.c : Use clk_prepare_enable/clk_disable_unprepare usb: imx_udc.c: Use clk_prepare_enable/clk_disable_unprepare usb: imx21-hcd.c: Use clk_prepare_enable/clk_disable_unprepare usb: gadget: fsl_mxc_udc: do not depend on grouped clocks Felipe Balbi (30): usb: dwc3: fix a WARN and a comment usb: dwc3: handle pending unaligned Control OUT data phase correctly usb: dwc3: ep0: switch over to IS_ALIGNED usb: dwc3: ep0: align on function signature usb: dwc3: ep0: fix a typo in comment usb: dwc3: gadget: remove trailing semicolon usb: dwc3: gadget: prevent DCTL register corruption usb: dwc3: gadget: disable U1/U2 on disconnect usb: dwc3: ep0: simplify error handling on dwc3_ep0_inspect_setup usb: d
Re: [RFC PATCH 00/13] firmware loader: introduce cache/uncache firmware
On Thu, Jul 26, 2012 at 1:23 AM, Linus Torvalds wrote: > > So *if* the only problem wrt the USB hub code comes from this area, IMO, USB hub code may not be the only one because both device_add and device_del can just be run in process context, so any hotplug bus may have this kind of problem since the devices in the bus may be unplugged and plugged again during suspend or experience power loss , then the bus driver may take similar handling policy as USB. > then I think the solution might be as simple as just moving the > "usermodehelper_enable()" up a few lines, with a comment. Something > like the *untested* and whitespace-damaged thing below.. > > Rafael? Who has one of those isight things and has seen the warning to test? I fake one USB device disconnect in reset_resume path and looks the patch is good: the device driver can request firmware successfully in its .probe(). > >Linus > > --- > diff --git a/kernel/power/process.c b/kernel/power/process.c > index 19db29f67558..5bf50e488196 100644 > --- a/kernel/power/process.c > +++ b/kernel/power/process.c > @@ -181,6 +181,12 @@ void thaw_processes(void) > pm_freezing = false; > pm_nosig_freezing = false; > > + /* > +* User mode helper are available again (or will be, > +* modulo scheduling) > +*/ > + usermodehelper_enable(); This may wake up tasks earlier than before, not sure if it might have side effects. Thanks, -- Ming Lei -- 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 v3] usb: dwc3: Introduce OTG driver for dwc3
Hi Ido,
> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Ido Shayevitz
> Sent: Wednesday, July 25, 2012 9:46 PM
> To: ba...@ti.com; av.tikhomi...@samsung.com
> Cc: linux-usb@vger.kernel.org; i...@codeaurora.org
> Subject: [RFC/PATCH v3] usb: dwc3: Introduce OTG driver for dwc3
>
> This is first release of otg driver for the dwc3 Synopsys USB3 core.
> The otg driver implements the otg final state machine and control the
> activation of the device controller or host controller.
>
> In this first implementation, only simple DRD mode is implemented,
> determine if A or B device according to the ID pin as reflected in the
> OSTS.ConIDSts field.
>
> Signed-off-by: Ido Shayevitz
>
> ---
> drivers/usb/dwc3/Kconfig |6 +-
> drivers/usb/dwc3/Makefile|2 +
> drivers/usb/dwc3/core.c | 15 +-
> drivers/usb/dwc3/core.h | 54 +-
> drivers/usb/dwc3/dwc3_otg.c | 512
> ++
> drivers/usb/dwc3/dwc3_otg.h | 38 +++
> drivers/usb/dwc3/gadget.c| 63 +
> drivers/usb/host/xhci-plat.c | 21 ++
> drivers/usb/host/xhci.c | 13 +-
> 9 files changed, 711 insertions(+), 13 deletions(-)
> create mode 100644 drivers/usb/dwc3/dwc3_otg.c
> create mode 100644 drivers/usb/dwc3/dwc3_otg.h
>
> diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
> index d13c60f..0cc108d 100644
> --- a/drivers/usb/dwc3/Kconfig
> +++ b/drivers/usb/dwc3/Kconfig
> @@ -1,9 +1,9 @@
> config USB_DWC3
> tristate "DesignWare USB3 DRD Core Support"
> - depends on (USB && USB_GADGET)
> + depends on (USB || USB_GADGET)
> select USB_OTG_UTILS
> - select USB_GADGET_DUALSPEED
> - select USB_GADGET_SUPERSPEED
> + select USB_GADGET_DUALSPEED if USB_GADGET
> + select USB_GADGET_SUPERSPEED if USB_GADGET
> select USB_XHCI_PLATFORM if USB_SUPPORT && USB_XHCI_HCD
> help
> Say Y or M here if your system has a Dual Role SuperSpeed
> diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
> index d441fe4..ffb3f55 100644
> --- a/drivers/usb/dwc3/Makefile
> +++ b/drivers/usb/dwc3/Makefile
> @@ -1,11 +1,13 @@
> ccflags-$(CONFIG_USB_DWC3_DEBUG) := -DDEBUG
> ccflags-$(CONFIG_USB_DWC3_VERBOSE) += -DVERBOSE_DEBUG
> +ccflags-y += -Idrivers/usb/host
>
> obj-$(CONFIG_USB_DWC3) += dwc3.o
>
> dwc3-y := core.o
> dwc3-y += host.o
> dwc3-y += gadget.o ep0.o
> +dwc3-y += dwc3_otg.o
>
> ifneq ($(CONFIG_DEBUG_FS),)
> dwc3-y += debugfs.o
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index c34452a..5343e39 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -517,15 +517,24 @@ static int __devinit dwc3_probe(struct
> platform_device *pdev)
> break;
> case DWC3_MODE_DRD:
> dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
> + ret = dwc3_otg_init(dwc);
> + if (ret) {
> + dev_err(dev, "failed to initialize otg\n");
> + goto err1;
> + }
> +
> ret = dwc3_host_init(dwc);
> if (ret) {
> dev_err(dev, "failed to initialize host\n");
> + dwc3_otg_exit(dwc);
> goto err1;
> }
>
> ret = dwc3_gadget_init(dwc);
> if (ret) {
> dev_err(dev, "failed to initialize gadget\n");
> + dwc3_host_exit(dwc);
> + dwc3_otg_exit(dwc);
> goto err1;
> }
> break;
> @@ -554,8 +563,9 @@ err2:
> dwc3_host_exit(dwc);
> break;
> case DWC3_MODE_DRD:
> - dwc3_host_exit(dwc);
> dwc3_gadget_exit(dwc);
> + dwc3_host_exit(dwc);
> + dwc3_otg_exit(dwc);
> break;
> default:
> /* do nothing */
> @@ -588,8 +598,9 @@ static int __devexit dwc3_remove(struct
> platform_device *pdev)
> dwc3_host_exit(dwc);
> break;
> case DWC3_MODE_DRD:
> - dwc3_host_exit(dwc);
> dwc3_gadget_exit(dwc);
> + dwc3_host_exit(dwc);
> + dwc3_otg_exit(dwc);
> break;
> default:
> /* do nothing */
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index c611d80..29a03e0 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -50,6 +50,8 @@
> #include
> #include
>
> +#include "dwc3_otg.h"
> +
> /* Global constants */
> #define DWC3_EP0_BOUNCE_SIZE 512
> #define DWC3_ENDPOINTS_NUM 32
> @@ -152,8 +154,9 @@
> /* OTG Registers */
> #define DWC3_OC
Re: bisected regression, v3.5 -> next-20120724: PCI PM causes USB hotplug failure
Hi, Rafael, On Wed, 2012-07-25 at 22:02 +0200, Rafael J. Wysocki wrote: > On Wednesday, July 25, 2012, Bjørn Mork wrote: > > huang ying writes: > > > > > Hi, Bjorn, > > > > > > Thank you very much for your detailed information. > > > > > > On Wed, Jul 25, 2012 at 5:58 PM, Bjørn Mork wrote: > > >> Huang Ying writes: > > >>> On Wed, 2012-07-25 at 06:08 +0200, Bjørn Mork wrote: > > Enabling autosuspend for USB causes hotplug failure in the current > > linux-next. Newly plugged devices are not detected at all until the > > port/controller is manually powered on by writing "on" to > > power/control. > > Testing is pretty simple: > > > > 1) for f in /sys/bus/usb/devices/*/power/control; do echo auto > $f; > > done > > >>> > > >>> Have you done: > > >>> > > >>> for f in /sys/bus/pci/devices/*/power/confol; do echo auto > $f; done > > >>> > > >>> ? > > >>> > > >>> If not, the pci device will not be suspended at all. > > >> > > >> Yes, sorry for missing that. I had it automatically enabled. Yes, > > >> autosuspend for the PCI device and all child devices must be enabled for > > >> the device to be suspended at all, of course. > > >> > > 2) wait for the controllers to suspend > > 3) plugin a new USB device > > >>> > > >>> After plugin the new USB device, is there anything in dmesg? > > >> > > >> No. Absolutely nothing, so the USB devices is not enumerated. Another > > >> indication of the same: Plugging a device like an Android phone, which > > >> normally detects being connected to a host and presents a device type > > >> menu to the user, results in the charging LED lighting up but no menu. > > >> > > >> > > >> Trying to show the sequence of events: > > >> > > >> 1) the controllers are suspended: > > >> > > >> Jul 25 11:27:12 nemi kernel: [ 38.962792] uhci_hcd :00:1a.2: power > > >> state changed by ACPI to D2 > > >> Jul 25 11:27:12 nemi kernel: [ 39.006718] uhci_hcd :00:1d.0: power > > >> state changed by ACPI to D2 > > >> Jul 25 11:27:15 nemi kernel: [ 41.808471] uhci_hcd :00:1a.0: power > > >> state changed by ACPI to D2 > > >> Jul 25 11:27:15 nemi kernel: [ 41.824123] ehci_hcd :00:1a.7: power > > >> state changed by ACPI to D2 > > >> Jul 25 11:27:15 nemi kernel: [ 41.824194] ehci_hcd :00:1d.7: power > > >> state changed by ACPI to D2 > > > > > > Here uhci controller is put into D2 > > > > > > [snip] > > >> > > >> Doing the same with commit 448bd857d reverted: > > >> > > >> > > >> 1) the controllers are suspended (to state D3? instead of D2?): > > >> > > >> Jul 25 11:34:01 nemi kernel: [ 37.064955] uhci_hcd :00:1a.2: power > > >> state changed by ACPI to D3 > > >> Jul 25 11:34:01 nemi kernel: [ 37.106586] uhci_hcd :00:1d.0: power > > >> state changed by ACPI to D3 > > >> Jul 25 11:34:04 nemi kernel: [ 39.808329] uhci_hcd :00:1a.0: power > > >> state changed by ACPI to D3 > > >> Jul 25 11:34:04 nemi kernel: [ 39.840054] ehci_hcd :00:1d.7: power > > >> state changed by ACPI to D3 > > >> Jul 25 11:34:04 nemi kernel: [ 39.840068] ehci_hcd :00:1a.7: power > > >> state changed by ACPI to D3 > > > > > > With commit reverted, the uhci_controller is put into D3 (ACPI D3cold). > > > > > > And the uhci controller on your system may not work properly under D2 > > > state, while OK in D3 state, and the commit will make uhci controller > > > choose D2 instead of D3. > > > > > > Please try following command line before testing. > > > > > > for f in /sys/bus/pci/devices/*/d3cold_allowed; do echo 1 > $f; done > > > > That made it work. The USB controllers ended up in D4 though: > > > > Jul 25 15:52:33 nemi kernel: [ 152.753280] uhci_hcd :00:1a.0: power > > state changed by ACPI to D0 > > Jul 25 15:52:33 nemi kernel: [ 152.753453] uhci_hcd :00:1a.0: setting > > latency timer to 64 > > Jul 25 15:52:33 nemi kernel: [ 152.753619] uhci_hcd :00:1a.0: power > > state changed by ACPI to D4 > > Jul 25 15:52:33 nemi kernel: [ 152.753875] uhci_hcd :00:1a.1: setting > > latency timer to 64 > > Jul 25 15:52:33 nemi kernel: [ 152.754153] uhci_hcd :00:1a.2: power > > state changed by ACPI to D0 > > Jul 25 15:52:33 nemi kernel: [ 152.754279] uhci_hcd :00:1a.2: setting > > latency timer to 64 > > Jul 25 15:52:33 nemi kernel: [ 152.754432] uhci_hcd :00:1a.2: power > > state changed by ACPI to D4 > > Jul 25 15:52:33 nemi kernel: [ 152.754668] ehci_hcd :00:1a.7: setting > > latency timer to 64 > > Jul 25 15:52:33 nemi kernel: [ 152.768089] ehci_hcd :00:1a.7: power > > state changed by ACPI to D4 > > Jul 25 15:52:33 nemi kernel: [ 152.768573] uhci_hcd :00:1d.0: power > > state changed by ACPI to D0 > > Jul 25 15:52:33 nemi kernel: [ 152.768726] uhci_hcd :00:1d.0: setting > > latency timer to 64 > > Jul 25 15:52:33 nemi kernel: [ 152.768891] uhci_hcd :00:1d.0: power > > state changed by ACPI to D4 > > Jul 25 15:52:33 nemi kernel: [ 152.76
Re: bisected regression, v3.5 -> next-20120724: PCI PM causes USB hotplug failure
On Thu, 2012-07-26 at 00:36 +0200, Bjørn Mork wrote: > "Rafael J. Wysocki" writes: > > > This is not really necessary. The problem is the change of behavior I was > > worried about some time ago. > > > > Namely, the device in question apparently doesn't support ACPI D3_hot, > > so acpi_pm_device_sleep_state() returns D2 as the target state, where it > > would return D3(cold) before the commit in question. > > > > To fix the regression, we'd need to reverse the current initial value of > > the d3cold_allowed flag so that it is set to "true" by default and only > > set to "false" for devices where we suspect there may be problems with > > D3_cold (like PCI Express ports). > > Good. May I also request a few lines describing d3cold_allowed in e.g > Documentation/ABI/testing/sysfs-bus-pci? I must admit that I thought > that was the policy for any new sysfs file, but it seems that is only > in the USB subsystem? > > Anyway, I believe it ought to be a requirement. If we are meant to > tweak some knob, then we must known how and when to do so. If not, then > why add it in the first place? Yes. I should have added the ABI document. Will write a patch for that. Best Regards, Huang Ying -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Fixes for UVC test suite (available in USBCV) failures
This patchset addresses a few issues found out while enumerating/running USBCV's UVC test suite with the UVC webcam gadget. After these fixes, all the UVC related test assertions PASS (but one also need to handle the Processing Unit/Selector Unit and Camera Terminal Unit test cases in the application space daemon which is responsible for interaction between UVC webcam gadget and a real V4L2 video capture device). USBCV can be downloaded from here: http://www.usb.org/developers/tools/ Bhupesh Sharma (3): usb: gadget/uvc: Fix 'Illegal endpoint address 0x80' issue for VC Endpoint usb: gadget/uvc: Add fix for UVC compliance test suite assertion 6.3.90 failure usb: gadget/uvc: Add fix for UVC compliance test suite's assertion 6.1.25 failure drivers/usb/gadget/f_uvc.c | 15 +++ 1 files changed, 11 insertions(+), 4 deletions(-) -- 1.7.3.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] usb: gadget/uvc: Fix 'Illegal endpoint address 0x80' issue for VC Endpoint
In case of super-speed descriptors for a UVC device, the `bEndpointAddress` of the video control endpoint (interrupt endpoint), was not correctly assigned and hence it was initialized with a default value of 0x80. This caused the enumeration of a super-speed UVC device on a Windows7 host machine to fail. This patch fixes this issue and the UVC device enumeration has been tested on a Windows7 host machine. Signed-off-by: Bhupesh Sharma --- drivers/usb/gadget/f_uvc.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/usb/gadget/f_uvc.c b/drivers/usb/gadget/f_uvc.c index 2a8bf06..70fa610 100644 --- a/drivers/usb/gadget/f_uvc.c +++ b/drivers/usb/gadget/f_uvc.c @@ -703,6 +703,10 @@ uvc_function_bind(struct usb_configuration *c, struct usb_function *f) uvc_ss_streaming_ep.bEndpointAddress = uvc_fs_streaming_ep.bEndpointAddress; + /* Video Control endpoint */ + uvc_ss_control_ep.bEndpointAddress = + uvc_fs_control_ep.bEndpointAddress; + /* Copy descriptors. */ f->ss_descriptors = uvc_copy_descriptors(uvc, USB_SPEED_SUPER); } -- 1.7.3.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] usb: gadget/uvc: Add fix for UVC compliance test suite assertion 6.3.90 failure
As per UVC compliance test specification's assertion number 6.3.90
related to 'Standard VS Isochronous Video Data Endpoint Descriptor Assertions',
the bits D3..2 of 'bmAttributes' field of Standard VS Isochronous Video Data
Endpoint Descriptor should be 01 (binary) to indicate that the
synchronization type is ASYNCHRONOUS.
This mandatory requirement has been captured in section 3.10.1.1 of the UVC
Video Class Specification version 1.1
This patch adds a fix for the same.
Signed-off-by: Bhupesh Sharma
---
drivers/usb/gadget/f_uvc.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/f_uvc.c b/drivers/usb/gadget/f_uvc.c
index 70fa610..4ef386a 100644
--- a/drivers/usb/gadget/f_uvc.c
+++ b/drivers/usb/gadget/f_uvc.c
@@ -147,7 +147,8 @@ static struct usb_endpoint_descriptor uvc_fs_streaming_ep =
{
.bLength= USB_DT_ENDPOINT_SIZE,
.bDescriptorType= USB_DT_ENDPOINT,
.bEndpointAddress = USB_DIR_IN,
- .bmAttributes = USB_ENDPOINT_XFER_ISOC,
+ .bmAttributes = USB_ENDPOINT_SYNC_ASYNC |
+ USB_ENDPOINT_XFER_ISOC,
.wMaxPacketSize = cpu_to_le16(512),
.bInterval = 1,
};
@@ -156,7 +157,8 @@ static struct usb_endpoint_descriptor uvc_hs_streaming_ep =
{
.bLength= USB_DT_ENDPOINT_SIZE,
.bDescriptorType= USB_DT_ENDPOINT,
.bEndpointAddress = USB_DIR_IN,
- .bmAttributes = USB_ENDPOINT_XFER_ISOC,
+ .bmAttributes = USB_ENDPOINT_SYNC_ASYNC |
+ USB_ENDPOINT_XFER_ISOC,
.wMaxPacketSize = cpu_to_le16(1024),
.bInterval = 1,
};
@@ -187,7 +189,8 @@ static struct usb_endpoint_descriptor uvc_ss_streaming_ep
__initdata = {
.bDescriptorType = USB_DT_ENDPOINT,
.bEndpointAddress = USB_DIR_IN,
- .bmAttributes = USB_ENDPOINT_XFER_ISOC,
+ .bmAttributes = USB_ENDPOINT_SYNC_ASYNC |
+ USB_ENDPOINT_XFER_ISOC,
.wMaxPacketSize = cpu_to_le16(1024),
.bInterval =4,
};
--
1.7.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] usb: gadget/uvc: Add fix for UVC compliance test suite's assertion 6.1.25 failure
As per the UVC compliance test suite's assertion 6.1.25, the `iFunction` field of the Interface Association Descriptor (IAD) should the match the `iInterface` field of the standard Video Control (VC) Interface Descriptor for this Video Interface Collection (VIC). This mandatory case is captured in section 3.11 of the USB Video Class Compliance specification revision 1.1 This patch fixes this test assertion's failure and has been tested on Linux FC16, WinXP, WIN7 and WIN8 High speed and Super Speed hosts for successful enumeration. Signed-off-by: Bhupesh Sharma --- drivers/usb/gadget/f_uvc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/gadget/f_uvc.c b/drivers/usb/gadget/f_uvc.c index 4ef386a..60ff726 100644 --- a/drivers/usb/gadget/f_uvc.c +++ b/drivers/usb/gadget/f_uvc.c @@ -823,12 +823,12 @@ uvc_bind_config(struct usb_configuration *c, goto error; uvc_en_us_strings[UVC_STRING_ASSOCIATION_IDX].id = ret; uvc_iad.iFunction = ret; + uvc_control_intf.iInterface = ret; ret = usb_string_id(c->cdev); if (ret < 0) goto error; uvc_en_us_strings[UVC_STRING_CONTROL_IDX].id = ret; - uvc_control_intf.iInterface = ret; ret = usb_string_id(c->cdev); if (ret < 0) -- 1.7.3.4 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: the dreaded "needs XHCI_TRUST_TX_LENGTH quirk" returns
On Wed, Jul 25, 2012 at 10:46:37AM -0700, Sarah Sharp wrote:
> Hi Matthew! It helps if you Cc my email address in your mail.
> Otherwise it might get lost in a separate folder and ignored for a
> couple days.
I was attempting to follow the pattern you established with Gary when you
redirected his private mail to linux-usb. Now that I know your personal system
I'll do my best to go along with it to avoid any confusion.
> Ok, it looks like the same version of Etron host controller as Gary:
>
> 03:00.0 USB controller: Etron Technology, Inc. EJ168 USB 3.0 Host Controller
> (rev 01) (prog-if 30 [XHCI])
> 03:00.0 0c03: 1b6f:7023 (rev 01) (prog-if 30 [XHCI])
>
> Have you tried applying the patch I sent to Gary for testing? I think
> that will remove the messages.
The copy I found online did not apply cleanly due to some sort of formatting
woes. So I added the necessary additional line by hand to get it going and the
message did disappear from dmesg as we'd expect.
> I don't think it will corrupt the data. It will just slow down reading
> data from the card. But you have a point about the messages filling up
> dmesg. I'll send you a patch shortly that rate limits the warning
> messages.
I've seen cases where having too many printk's in the wrong places crashed my
system when I was writing kernel modules before. In any event this is a side
topic, and I extend my sincere thanks for helping to rate-limit the message,
this is a big help.
> The patch fixed Gary's printk warnings, but didn't fix his overall
> issue. I need to follow up on that.
>
> So, can you test with the patch that I sent Gary and make sure that the
> printks go away and USB devices work properly under the Etron host?
> Then revert the patch, apply the printk rate limiting patch I'll send
> you shortly, and make sure you only get the SHORT_TX quirk message once.
I think I'm in the same state as Gary only different. ;) I am getting weird
behavior with the quirk patch. The device popped up for about half a minute,
then went haywire and disappeared after the exfat FUSE FS tried to mount it
and begin reading the volume successfully for a short moment.
The exfat code seems unhappy because something triggered an obscure warning
which is probably not innocuous, because nobody else seemed to hit as the only
Google searches went to the source code (I saw the "fsync failed" below):
The one usage I could find in libexfat for exfat_fsync was for writing a
superblock. If that's failing I think we'll run into big problems. However
something from the FUSE layer might have triggered the fsync too possibly. I'd
need some help because I haven't coded up FUSE based stuff before.
http://exfat.googlecode.com/svn/trunk/libexfat/io.c
static int commit_super_block(const struct exfat* ef)
{
exfat_pwrite(ef->dev, ef->sb, sizeof(struct exfat_super_block), 0);
return exfat_fsync(ef->dev);
}
...
int exfat_fsync(struct exfat_dev* dev)
{
#ifdef USE_UBLIO
if (ublio_fsync(dev->ufh) != 0)
#else
if (fsync(dev->fd) != 0)
#endif
{
exfat_error("fsync failed");
return 1;
}
return 0;
}
I did not try the rate-limit yet, pending the outcome from the above topic.
> Sarah Sharp
Regards,
Matthew.
--
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: the dreaded "needs XHCI_TRUST_TX_LENGTH quirk" returns
Forgot to mention, I put a new log here with the latest behavior with the
patch:
http://www.mhcomputing.net/tmp/xhci-bug/dmesg-usb-3-port-quirk-patch-plugin.txt.gz
Regards,
Matthew.
On Wed, Jul 25, 2012 at 10:24:26PM -0700, Matthew Hall wrote:
> On Wed, Jul 25, 2012 at 10:46:37AM -0700, Sarah Sharp wrote:
> > Hi Matthew! It helps if you Cc my email address in your mail.
> > Otherwise it might get lost in a separate folder and ignored for a
> > couple days.
>
> I was attempting to follow the pattern you established with Gary when you
> redirected his private mail to linux-usb. Now that I know your personal
> system
> I'll do my best to go along with it to avoid any confusion.
>
> > Ok, it looks like the same version of Etron host controller as Gary:
> >
> > 03:00.0 USB controller: Etron Technology, Inc. EJ168 USB 3.0 Host
> > Controller (rev 01) (prog-if 30 [XHCI])
> > 03:00.0 0c03: 1b6f:7023 (rev 01) (prog-if 30 [XHCI])
> >
> > Have you tried applying the patch I sent to Gary for testing? I think
> > that will remove the messages.
>
> The copy I found online did not apply cleanly due to some sort of formatting
> woes. So I added the necessary additional line by hand to get it going and
> the
> message did disappear from dmesg as we'd expect.
>
> > I don't think it will corrupt the data. It will just slow down reading
> > data from the card. But you have a point about the messages filling up
> > dmesg. I'll send you a patch shortly that rate limits the warning
> > messages.
>
> I've seen cases where having too many printk's in the wrong places crashed my
> system when I was writing kernel modules before. In any event this is a side
> topic, and I extend my sincere thanks for helping to rate-limit the message,
> this is a big help.
>
> > The patch fixed Gary's printk warnings, but didn't fix his overall
> > issue. I need to follow up on that.
> >
> > So, can you test with the patch that I sent Gary and make sure that the
> > printks go away and USB devices work properly under the Etron host?
> > Then revert the patch, apply the printk rate limiting patch I'll send
> > you shortly, and make sure you only get the SHORT_TX quirk message once.
>
> I think I'm in the same state as Gary only different. ;) I am getting weird
> behavior with the quirk patch. The device popped up for about half a minute,
> then went haywire and disappeared after the exfat FUSE FS tried to mount it
> and begin reading the volume successfully for a short moment.
>
> The exfat code seems unhappy because something triggered an obscure warning
> which is probably not innocuous, because nobody else seemed to hit as the
> only
> Google searches went to the source code (I saw the "fsync failed" below):
>
> The one usage I could find in libexfat for exfat_fsync was for writing a
> superblock. If that's failing I think we'll run into big problems. However
> something from the FUSE layer might have triggered the fsync too possibly.
> I'd
> need some help because I haven't coded up FUSE based stuff before.
>
> http://exfat.googlecode.com/svn/trunk/libexfat/io.c
>
> static int commit_super_block(const struct exfat* ef)
> {
> exfat_pwrite(ef->dev, ef->sb, sizeof(struct exfat_super_block), 0);
> return exfat_fsync(ef->dev);
> }
>
> ...
>
> int exfat_fsync(struct exfat_dev* dev)
> {
> #ifdef USE_UBLIO
> if (ublio_fsync(dev->ufh) != 0)
> #else
> if (fsync(dev->fd) != 0)
> #endif
> {
> exfat_error("fsync failed");
> return 1;
> }
> return 0;
> }
>
> I did not try the rate-limit yet, pending the outcome from the above topic.
>
> > Sarah Sharp
>
> Regards,
> Matthew.
> --
> 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: usb : mass storage : short_not_ok for non usb3 udc
On Thu, Jul 26, 2012 at 2:33 AM, Alan Stern wrote: > On Wed, 25 Jul 2012, Paul Zimmerman wrote: > >> > From: Alan Stern [mailto:st...@rowland.harvard.edu] >> > Sent: Wednesday, July 25, 2012 12:48 PM >> > To: Paul Zimmerman >> > Cc: Rajaram R; Michal Nazarewicz; linux-usb@vger.kernel.org >> > Subject: RE: usb : mass storage : short_not_ok for non usb3 udc >> > >> > On Wed, 25 Jul 2012, Paul Zimmerman wrote: >> > >> > > > > > I don't understand this either. What's wrong with setting >> > > > > > short_not_ok while at SuperSpeed? It shouldn't force the use of a >> > > > bounce buffer. >> > > > > > >> > > > > >> > > > > I have just brought back some code removed by patch "usb: fix mass >> > > > > storage gadgets to work with Synopsys UDC". >> > > > >> > > > Maybe while bringing it back you can remove the checks for SuperSpeed. >> > > > Is there any reason to keep them? >> > > >> > > Hi Alan, >> > > >> > > The problem only arises because at super-speed the MaxPacket size is >> > > 1024, which is greater than the sector size of 512. So the whole point of >> > > the patch is to fix the SuperSpeed operation, while allowing high-speed >> > > devices to operate as they always did. >> > >> > Don't the mass-storage drivers already operate correctly at SuperSpeed? >> > If not, what goes wrong? >> > >> > Besides, how could the patch possibly affect SuperSpeed operation? >> > Everything it does is protected by >> > >> > if (!gadget_is_superspeed(gadget)) >> > >> > So I'm afraid I don't understand your point. >> >> Sorry for not being clear. The original patch: >> >> http://www.spinics.net/lists/linux-usb/msg52549.html >> >> was required to make mass-storage work with DWC3 at SuperSpeed. >> However, it apparently broke platforms like musb which depend on >> short-not-ok being set. The current patch fixes that, by setting >> short-not-ok if not running SuperSpeed. DWC3 will still work fine >> with this latest patch, since its problem was only with SuperSpeed. > > Okay, that's fine. But it doesn't answer my earlier question: Is there > really any need for the SuperSpeed checks in this patch? > > In other words, will DWC3 continue to work correctly if short_not_ok is > set? Yes, that was my question earlier to this patch. > > 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
[PATCH] usb:musb: Fix for Full Speed issue
After sending the USB Bus reset, Host waits for High Speed Chirps.
If the soft-disconnect and soft-connect happens during this chirp time,
then Host doesn't detect this disconnect.
Host treats this as Full Speed Device as there are no chirps.
To avoid this Full Speed Enumeration, soft-disconnect and soft-connect
should have a 500 mili-second gap when USB cable is connected.
Signed-off-by: Ajay Jawade
Acked-by: srinidhi kasagar
---
drivers/usb/musb/musb_gadget.c | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index f7194cf..801dbe6 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1743,6 +1743,7 @@ static int musb_gadget_pullup(struct usb_gadget *gadget,
int is_on)
{
struct musb *musb = gadget_to_musb(gadget);
unsigned long flags;
+ u8 devctl;
is_on = !!is_on;
@@ -1751,6 +1752,31 @@ static int musb_gadget_pullup(struct usb_gadget *gadget,
int is_on)
/* NOTE: this assumes we are sensing vbus; we'd rather
* not pullup unless the B-session is active.
*/
+
+ /* After sending the USB Bus reset, Host waits for
+* High Speed Chirps. If the soft-disconnect and soft-connect
+* happens during this chirp time, then Host doesn't
+* detect this disconnect. Host treats this as Full Speed
+* Device as there are no chirps. To avoid this Full Speed
+* Enumeration, soft-disconnect and soft-connect should have
+* a 500 mili-second delay when USB cable is connected.
+*/
+
+ if (is_on && (is_on != musb->softconnect)) {
+
+ /* USB cable presence is decided by reading the VBUS
+* Level bits of DevCtl register.
+*/
+
+ devctl = musb_readb(musb->mregs, MUSB_DEVCTL);
+ devctl = (devctl & MUSB_DEVCTL_VBUS) >> MUSB_DEVCTL_VBUS_SHIFT;
+
+ if (devctl != 0) {
+ /* USB Cable is connected. Delay the soft-connect */
+ msleep(500);
+ }
+ }
+
spin_lock_irqsave(&musb->lock, flags);
if (is_on != musb->softconnect) {
musb->softconnect = is_on;
--
1.7.4.3
--
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:musb: Fix for Full Speed issue
After sending the USB Bus reset, Host waits for High Speed Chirps.
If the soft-disconnect and soft-connect happens during this chirp time,
then Host doesn't detect this disconnect.
Host treats this as Full Speed Device as there are no chirps.
To avoid this Full Speed Enumeration, soft-disconnect and soft-connect
should have a 500 mili-second gap when USB cable is connected.
Signed-off-by: Ajay Jawade
Acked-by: srinidhi kasagar
---
drivers/usb/musb/musb_gadget.c | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index f7194cf..801dbe6 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1743,6 +1743,7 @@ static int musb_gadget_pullup(struct usb_gadget *gadget,
int is_on) {
struct musb *musb = gadget_to_musb(gadget);
unsigned long flags;
+ u8 devctl;
is_on = !!is_on;
@@ -1751,6 +1752,31 @@ static int musb_gadget_pullup(struct usb_gadget *gadget,
int is_on)
/* NOTE: this assumes we are sensing vbus; we'd rather
* not pullup unless the B-session is active.
*/
+
+ /* After sending the USB Bus reset, Host waits for
+* High Speed Chirps. If the soft-disconnect and soft-connect
+* happens during this chirp time, then Host doesn't
+* detect this disconnect. Host treats this as Full Speed
+* Device as there are no chirps. To avoid this Full Speed
+* Enumeration, soft-disconnect and soft-connect should have
+* a 500 mili-second delay when USB cable is connected.
+*/
+
+ if (is_on && (is_on != musb->softconnect)) {
+
+ /* USB cable presence is decided by reading the VBUS
+* Level bits of DevCtl register.
+*/
+
+ devctl = musb_readb(musb->mregs, MUSB_DEVCTL);
+ devctl = (devctl & MUSB_DEVCTL_VBUS) >> MUSB_DEVCTL_VBUS_SHIFT;
+
+ if (devctl != 0) {
+ /* USB Cable is connected. Delay the soft-connect */
+ msleep(500);
+ }
+ }
+
spin_lock_irqsave(&musb->lock, flags);
if (is_on != musb->softconnect) {
musb->softconnect = is_on;
--
1.7.4.3
--
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
