Re: [PATCH 1/8] usb/gadget: uvc: move descriptors to their only user

2013-11-29 Thread Andrzej Pietrasiewicz 

Hi Laurent, hi Michael,

W dniu 28.11.2013 22:59, Michael Grzeschik pisze:

On Thu, Nov 28, 2013 at 10:53:03PM +0100, Laurent Pinchart wrote:

On Thursday 28 November 2013 08:43:35 Andrzej Pietrasiewicz wrote:

A bunch of descriptors is defined in webcam.c. They are used only
by f_uvc. Move them to their only user.


The reason why descriptors are located in webcam.c and not f_uvc.c is that I
wanted to separate the code in a generic part (f_uvc.c) and an application-
specific part (webcam.c). This allows instantiating a UVC function with
different parameters, depending on the application, with minimum changes to
the code. webcam.c is merely sample code that shows how to instantiate a UVC
function. With this patch the list of formats and controls become hardcoded in
the function driver.

How could we solve this problem with configfs ?


I would suggest that we move away from static descriptor description to
dynamic description from the userspace. We need a similar mechanism like
in functionfs to describe the supported endpoints and their formats. As
this is limited by the application above anyway. Would this also be
possible by configfs?




What FunctionFS does is that it accepts a stream of bytes and parses it;
it is expected that the said stream has particular structure understood
by FunctionFS.

Taking exactly the same approach with configfs seems counterintuitive
to how configfs is meant to be used: we should be creating things
explicitly (and step by step) instead of passing a (long) string of bytes.
[BTW passing the descriptors by creating directories and writing to files
in configfs is the main idea behind FunctionFS 2 I talked about during
LinuxCon in New Orleans.]

That said, it is not unconceivable to achieve the same effect using the
proper configfs way. However, this calls for some thought.

How many descriptors are there?
How many resolutions is the webcam gadget meant to support?
The descriptors so far in webcam.c form some hierarchy. Is the hierarchy
always the same? What can change? What are mandatory parts and what is
optional?

From what it looks like there has to be a way to specify some
configuration data (descriptors) and to specify associations between
them, e.g. there are some descriptions of, say, three resolutions and they
need to be associated with some higher-level descriptors, but for different
USB speeds the choice of resolutions is different. There are also some
format descriptors (yuv, MJPEG), there is some control header and so on.

With configfs we basically have three options for the user to create
things:

1) create a directory (its contents is predefined and unchangeable
at runtime)
2) write to a file (a file has to exist and be a member of some
directory like 1) created  earlier)
3) create a symbolic link

Ad 1) This is used for example to create gadget's configurations,
to create gadget's functions and to create each gadget in the first
place
Ad 2) This is used for example to specify some parameters, like
MAC address or streaming_interval
Ad 3) This is used for assigning functions to configurations

What I can think of is that there is a predefined set of kinds
of descriptors we might want to create. It has to be this way,
since there has to be some configfs handling code specific to
each kind of directory/file/symbolic link we create.

For each descriptor the user creates a separate directory.
In the directory there are files which correspond to each
configurable member of the descriptor. What are configurable
members of possible descriptors?

Example

$ cd $CONFIGFS_ROOT/usb_gadget/g1/functions/uvc.1
(formats is a default group/directory so the user need not
create it)
$ cd formats
$ mkdir yuv
$ cd yuv
$ ls
guidFormat  bBitsPerPixel   bDefaultFrameIndex  bAspectRatioX
bAspectRatioY

(perhaps some more; I don't know what is constant and what can be set
by the user)

and there e.g.:
$ echo Y,U,V,2,0x00,0x00,0x10,0x00,0x80,0x00,0x00,0xaa,0x00,0x38,0x9b,0x71 \

guidFormat


(any better way to pass this kind of information?)

Then the user creates streaming classes (whatever they are):
(streaming_classes is a default group/directory so the user need not
create it)

$ cd $CONFIGFS_ROOT/usb_gadget/g1/functions/uvc.1
$ cd streaming_classes
$ mkdir fs hs ss
$ cd fs
$ ln -s $CONFIGFS_ROOT/usb_gadget/g1/functions/uvc.1/formats/yuv
$ ls
yuv - ../../formats/yuv

(and similar follows for high and super speeds)

$ find -ls $CONFIGFS_ROOT/usb_gadget/g1/functions/uvc.1

./trace
./streaming_interval
./streaming_maxpacket
./streaming_maxburst
./formats
./formats/yuv
./formats/yuv/guidFormat
./formats/yuv/bBitsPerPixel
./formats/yuv/bDefaultFrameIndex
./formats/yuv/bAspectRatioX
./formats/yuv/bAspectRatioY
./streaming_classes
./streaming_classes/fs
./streaming_classes/fs/yuv - ../../formats/yuv
./streaming_classes/hs
./streaming_classes/ss

and so on.

Does this look sane to you?

Some other questions and issues:

Can a uvc function be used more than once in a gadget?
That is,

RE: [PATCH 2/3 v2] usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag

2013-11-29 Thread Peter Chen 


Best regards,
Peter Chen


 -Original Message-
 From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
 ow...@vger.kernel.org] On Behalf Of Chris Ruehl
 Sent: Friday, November 29, 2013 3:20 PM
 To: alexander.shish...@linux.intel.com; gre...@linuxfoundation.org
 Cc: linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; Chris Ruehl
 Subject: [PATCH 2/3 v2] usb: chipidea: Fix Internal error: : 808 [#1] ARM
 related to STS flag
 
 usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag
 
 * init the sts flag to 0 (missed)
 * set the sts flag only if not 0
 
 Signed-off-by: Chris Ruehl chris.ru...@gtsys.com.hk
 ---
  drivers/usb/chipidea/core.c |8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
 index 5075407..1a6010e 100644
 --- a/drivers/usb/chipidea/core.c
 +++ b/drivers/usb/chipidea/core.c
 @@ -245,6 +245,8 @@ static void hw_phymode_configure(struct ci_hdrc *ci)
  {
   u32 portsc, lpm, sts = 0;
 
   switch (ci-platdata-phy_mode) {
   case USBPHY_INTERFACE_MODE_UTMI:
   portsc = PORTSC_PTS(PTS_UTMI);
 @@ -273,10 +275,12 @@ static void hw_phymode_configure(struct ci_hdrc *ci)
 
   if (ci-hw_bank.lpm) {
   hw_write(ci, OP_DEVLC, DEVLC_PTS(7) | DEVLC_PTW, lpm);
 - hw_write(ci, OP_DEVLC, DEVLC_STS, sts);
 + if (sts)
 + hw_write(ci, OP_DEVLC, DEVLC_STS, sts);
   } else {
   hw_write(ci, OP_PORTSC, PORTSC_PTS(7) | PORTSC_PTW, portsc);
 - hw_write(ci, OP_PORTSC, PORTSC_STS, sts);
 + if ( sts )
 + hw_write(ci, OP_PORTSC, PORTSC_STS, sts);
   }
  }
 
 --

Acked-by: Peter Chen peter.c...@freescale.com

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

RE: [PATCH 1/3 v2] usb: chipidea: Reallocate regmap only if lpm is detected

2013-11-29 Thread Peter Chen 

 

 -Original Message-
 From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
 ow...@vger.kernel.org] On Behalf Of Chris Ruehl
 Sent: Friday, November 29, 2013 3:20 PM
 To: alexander.shish...@linux.intel.com; gre...@linuxfoundation.org
 Cc: linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; Chris Ruehl
 Subject: [PATCH 1/3 v2] usb: chipidea: Reallocate regmap only if lpm is
 detected
 
 usb: chipidea: Reallocate regmap only if lpm is detected
 
 The regmap only needs to reallocate if the hw_read on the CAP register
 shows
 lpm is used. Therefore the if() statement check the change.
 
 Signed-off-by: Chris Ruehl chris.ru...@gtsys.com.hk
 ---
  drivers/usb/chipidea/core.c |3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
 index 5d8981c..5075407 100644
 --- a/drivers/usb/chipidea/core.c
 +++ b/drivers/usb/chipidea/core.c
 @@ -208,7 +208,8 @@ static int hw_device_init(struct ci_hdrc *ci, void
 __iomem *base)
   reg = hw_read(ci, CAP_HCCPARAMS, HCCPARAMS_LEN) 
   __ffs(HCCPARAMS_LEN);
   ci-hw_bank.lpm  = reg;
 - hw_alloc_regmap(ci, !!reg);
 + if (reg)
 + hw_alloc_regmap(ci, !!reg);
   ci-hw_bank.size = ci-hw_bank.op - ci-hw_bank.abs;
   ci-hw_bank.size += OP_LAST;
   ci-hw_bank.size /= sizeof(u32);
 --

Acked-by: Peter Chen peter.c...@freescale.com

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

RE: [PATCH v2 1/2] usb: chipidea: usbmisc: Add support for i.MX27/i.MX31 CPUs

2013-11-29 Thread Peter Chen 

 
 
 This adds i.MX27 and i.MX31 as the next user of the usbmisc driver.
 
 Signed-off-by: Alexander Shiyan shc_w...@mail.ru
 ---
  drivers/usb/chipidea/usbmisc_imx.c | 42
 ++
  1 file changed, 42 insertions(+)
 
 diff --git a/drivers/usb/chipidea/usbmisc_imx.c
 b/drivers/usb/chipidea/usbmisc_imx.c
 index 8a1094b..4381c5a6 100644
 --- a/drivers/usb/chipidea/usbmisc_imx.c
 +++ b/drivers/usb/chipidea/usbmisc_imx.c
 @@ -21,6 +21,10 @@
  #define MX25_USB_PHY_CTRL_OFFSET 0x08
  #define MX25_BM_EXTERNAL_VBUS_DIVIDERBIT(23)
 
 +#define MX27_H1_PM_BIT   BIT(8)
 +#define MX27_H2_PM_BIT   BIT(16)
 +#define MX27_OTG_PM_BIT  BIT(24)
 +
  #define MX53_USB_OTG_PHY_CTRL_0_OFFSET   0x08
  #define MX53_USB_UH2_CTRL_OFFSET 0x14
  #define MX53_USB_UH3_CTRL_OFFSET 0x18
 @@ -68,6 +72,36 @@ static int usbmisc_imx25_post(struct imx_usbmisc_data
 *data)
   return 0;
  }
 
 +static int usbmisc_imx27_init(struct imx_usbmisc_data *data)
 +{
 + unsigned long flags;
 + u32 val;
 +
 + switch (data-index) {
 + case 0:
 + val = MX27_OTG_PM_BIT;
 + break;
 + case 1:
 + val = MX27_H1_PM_BIT;
 + break;
 + case 2:
 + val = MX27_H2_PM_BIT;
 + break;
 + default:
 + return -EINVAL;
 + };
 +
 + spin_lock_irqsave(usbmisc-lock, flags);
 + if (data-disable_oc)
 + val = readl(usbmisc-base) | val;
 + else
 + val = readl(usbmisc-base)  ~val;
 + writel(val, usbmisc-base);
 + spin_unlock_irqrestore(usbmisc-lock, flags);
 +
 + return 0;
 +}
 +
  static int usbmisc_imx53_init(struct imx_usbmisc_data *data)
  {
   void __iomem *reg = NULL;
 @@ -128,6 +162,10 @@ static const struct usbmisc_ops imx25_usbmisc_ops =
 {
   .post = usbmisc_imx25_post,
  };
 
 +static const struct usbmisc_ops imx27_usbmisc_ops = {
 + .init = usbmisc_imx27_init,
 +};
 +
  static const struct usbmisc_ops imx53_usbmisc_ops = {
   .init = usbmisc_imx53_init,
  };
 @@ -162,6 +200,10 @@ static const struct of_device_id usbmisc_imx_dt_ids[]
 = {
   .data = imx25_usbmisc_ops,
   },
   {
 + .compatible = fsl,imx27-usbmisc,
 + .data = imx27_usbmisc_ops,
 + },
 + {
   .compatible = fsl,imx53-usbmisc,
   .data = imx53_usbmisc_ops,
   },
 --
Acked-by: Peter Chen peter.c...@freescale.com

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

RE: [PATCH v2 2/2] usb: chipidea: usbmisc: Add support for i.MX51 CPU

2013-11-29 Thread Peter Chen 

 
 This adds i.MX51 as the next user of the usbmisc driver.
 Functionality is similar to i.MX53, so at this stage simply
 reuse existing i.MX53 calls.
 
 Signed-off-by: Alexander Shiyan shc_w...@mail.ru
 ---
  drivers/usb/chipidea/usbmisc_imx.c | 4 
  1 file changed, 4 insertions(+)
 
 diff --git a/drivers/usb/chipidea/usbmisc_imx.c
 b/drivers/usb/chipidea/usbmisc_imx.c
 index 4381c5a6..cd061ab 100644
 --- a/drivers/usb/chipidea/usbmisc_imx.c
 +++ b/drivers/usb/chipidea/usbmisc_imx.c
 @@ -204,6 +204,10 @@ static const struct of_device_id usbmisc_imx_dt_ids[]
 = {
   .data = imx27_usbmisc_ops,
   },
   {
 + .compatible = fsl,imx51-usbmisc,
 + .data = imx53_usbmisc_ops,
 + },
 + {
   .compatible = fsl,imx53-usbmisc,
   .data = imx53_usbmisc_ops,
   },
 --

Acked-by: Peter Chen peter.c...@freescale.com

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

Re: [PATCH 2/3] usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag

2013-11-29 Thread Michael Grzeschik 
On Fri, Nov 29, 2013 at 10:07:49AM +0800, Chris Ruehl wrote:
 * init the sts flag to 0 (missed)
 * set the sts flag only if not 0
 
 Signed-off-by: Chris Ruehl chris.ru...@gtsys.com.hk
 ---
  drivers/usb/chipidea/core.c |8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
 index 5075407..1a6010e 100644
 --- a/drivers/usb/chipidea/core.c
 +++ b/drivers/usb/chipidea/core.c
 @@ -245,6 +245,8 @@ static void hw_phymode_configure(struct ci_hdrc *ci)
  {
   u32 portsc, lpm, sts;
  
 + sts = 0;
 +

This makes sense, but should be moved up to the
variable declartion:

-   u32 portsc, lpm, sts;
+   u32 portsc, lpm, sts = 0;

   switch (ci-platdata-phy_mode) {
   case USBPHY_INTERFACE_MODE_UTMI:
   portsc = PORTSC_PTS(PTS_UTMI);
 @@ -273,10 +275,12 @@ static void hw_phymode_configure(struct ci_hdrc *ci)
  
   if (ci-hw_bank.lpm) {
   hw_write(ci, OP_DEVLC, DEVLC_PTS(7) | DEVLC_PTW, lpm);
 - hw_write(ci, OP_DEVLC, DEVLC_STS, sts);
 + if (sts)
 + hw_write(ci, OP_DEVLC, DEVLC_STS, sts);

What is wrong with explicit setting DEVLC_STS to 0 if we
know that we don't use serial phy mode?

   } else {
   hw_write(ci, OP_PORTSC, PORTSC_PTS(7) | PORTSC_PTW, portsc);
 - hw_write(ci, OP_PORTSC, PORTSC_STS, sts);
 + if ( sts )
 + hw_write(ci, OP_PORTSC, PORTSC_STS, sts);
   }
  }

ditto

Regards,
Michael

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] ACPI / bind: Rework struct acpi_bus_type

2013-11-29 Thread Rafael J. Wysocki 
On Friday, November 29, 2013 09:55:07 AM Lan Tianyu wrote:
 On 2013年11月29日 08:37, Rafael J. Wysocki wrote:
  From: Rafael J. Wysocki rafael.j.wyso...@intel.com
  
  Replace the .find_device function pointer in struct acpi_bus_type
  with a new one, .find_copmanion, that is supposed to point to a
 -^
 A typo

Yeah, thanks!

  function returning struct acpi_device pointer (instead of an int)
  and takes one argument (instead of two).  This way the role of
  this callback is more clear and the implementation of it can
  be more straightforward.
  
  Update all of the users of struct acpi_bus_type (PCI, PNP/ACPI and
  USB) to reflect the structure change.
  
  Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
  ---
   drivers/acpi/glue.c |   12 +++-
   drivers/pci/pci-acpi.c  |   12 +++-
   drivers/pnp/pnpacpi/core.c  |   19 +--
   drivers/usb/core/usb-acpi.c |   40 
   include/acpi/acpi_bus.h |2 +-
   5 files changed, 36 insertions(+), 49 deletions(-)
  
  Index: linux-pm/include/acpi/acpi_bus.h
  ===
  --- linux-pm.orig/include/acpi/acpi_bus.h
  +++ linux-pm/include/acpi/acpi_bus.h
  @@ -414,7 +414,7 @@ struct acpi_bus_type {
  struct list_head list;
  const char *name;
  bool (*match)(struct device *dev);
  -   int (*find_device) (struct device *, acpi_handle *);
  +   struct acpi_device * (*find_companion)(struct device *);
  void (*setup)(struct device *);
  void (*cleanup)(struct device *);
   };
  Index: linux-pm/drivers/acpi/glue.c
  ===
  --- linux-pm.orig/drivers/acpi/glue.c
  +++ linux-pm/drivers/acpi/glue.c
  @@ -37,7 +37,7 @@ int register_acpi_bus_type(struct acpi_b
   {
  if (acpi_disabled)
  return -ENODEV;
  -   if (type  type-match  type-find_device) {
  +   if (type  type-match  type-find_companion) {
  down_write(bus_type_sem);
  list_add_tail(type-list, bus_type_list);
  up_write(bus_type_sem);
  @@ -302,17 +302,19 @@ EXPORT_SYMBOL_GPL(acpi_unbind_one);
   static int acpi_platform_notify(struct device *dev)
   {
  struct acpi_bus_type *type = acpi_get_bus_type(dev);
  -   acpi_handle handle;
  int ret;
   
  ret = acpi_bind_one(dev, NULL);
  if (ret  type) {
  -   ret = type-find_device(dev, handle);
  -   if (ret) {
  +   struct acpi_device *adev;
  +
  +   adev = type-find_companion(dev);
  +   if (!adev) {
  DBG(Unable to get handle for %s\n, dev_name(dev));
  +   ret = -ENODEV;
  goto out;
  }
  -   ret = acpi_bind_one(dev, handle);
  +   ret = acpi_bind_one(dev, adev-handle);
  if (ret)
  goto out;
  }
  Index: linux-pm/drivers/pci/pci-acpi.c
  ===
  --- linux-pm.orig/drivers/pci/pci-acpi.c
  +++ linux-pm/drivers/pci/pci-acpi.c
  @@ -306,10 +306,9 @@ void acpi_pci_remove_bus(struct pci_bus
   }
   
   /* ACPI bus type */
  -static int acpi_pci_find_device(struct device *dev, acpi_handle *handle)
  +static struct acpi_device *acpi_pci_find_companion(struct device *dev)
   {
  struct pci_dev *pci_dev = to_pci_dev(dev);
  -   struct acpi_device *adev;
  bool check_children;
  u64 addr;
   
  @@ -322,13 +321,8 @@ static int acpi_pci_find_device(struct d
  || pci_dev-hdr_type == PCI_HEADER_TYPE_CARDBUS;
  /* Please ref to ACPI spec for the syntax of _ADR */
  addr = (PCI_SLOT(pci_dev-devfn)  16) | PCI_FUNC(pci_dev-devfn);
  -   adev = acpi_find_child_device(ACPI_COMPANION(dev-parent), addr,
  +   return acpi_find_child_device(ACPI_COMPANION(dev-parent), addr,
check_children);
  -   if (adev) {
  -   *handle = adev-handle;
  -   return 0;
  -   }
  -   return -ENODEV;
   }
   
   static void pci_acpi_setup(struct device *dev)
  @@ -368,7 +362,7 @@ static bool pci_acpi_bus_match(struct de
   static struct acpi_bus_type acpi_pci_bus = {
  .name = PCI,
  .match = pci_acpi_bus_match,
  -   .find_device = acpi_pci_find_device,
  +   .find_companion = acpi_pci_find_companion,
  .setup = pci_acpi_setup,
  .cleanup = pci_acpi_cleanup,
   };
  Index: linux-pm/drivers/pnp/pnpacpi/core.c
  ===
  --- linux-pm.orig/drivers/pnp/pnpacpi/core.c
  +++ linux-pm/drivers/pnp/pnpacpi/core.c
  @@ -329,20 +329,11 @@ static int __init acpi_pnp_match(struct
   compare_pnp_id(pnp-id, acpi_device_hid(acpi));
   }
   
  -static int __init acpi_pnp_find_device(struct device *dev, acpi_handle * 
  handle)
  +static struct acpi_device * __init acpi_pnp_find_companion(struct device 
  *dev)

[PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

2013-11-29 Thread Roger Quadros 
With u-boot 2013.10, USB devices are sometimes not detected
on OMAP4 Panda. To make us independent of what bootloader does
with the USB Host module, we must RESET it to get it to a known
good state. This patch Soft RESETs the USB Host module.

Reported-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: sta...@vger.kernel.org # 3.10+
Signed-off-by: Roger Quadros rog...@ti.com
---
 drivers/mfd/omap-usb-host.c | 115 +---
 1 file changed, 109 insertions(+), 6 deletions(-)

diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 142650f..d4bd464 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -43,14 +43,18 @@
 /* UHH Register Set */
 #defineOMAP_UHH_REVISION   (0x00)
 #defineOMAP_UHH_SYSCONFIG  (0x10)
-#defineOMAP_UHH_SYSCONFIG_MIDLEMODE(1  12)
+#defineOMAP_UHH_SYSCONFIG_MIDLEMASK(3  12)
+#define OMAP_UHH_SYSCONFIG_MIDLESHIFT  (12)
 #defineOMAP_UHH_SYSCONFIG_CACTIVITY(1  8)
-#defineOMAP_UHH_SYSCONFIG_SIDLEMODE(1  3)
+#defineOMAP_UHH_SYSCONFIG_SIDLEMASK(3  3)
+#defineOMAP_UHH_SYSCONFIG_SIDLESHIFT   (3)
 #defineOMAP_UHH_SYSCONFIG_ENAWAKEUP(1  2)
 #defineOMAP_UHH_SYSCONFIG_SOFTRESET(1  1)
 #defineOMAP_UHH_SYSCONFIG_AUTOIDLE (1  0)
 
 #defineOMAP_UHH_SYSSTATUS  (0x14)
+#define OMAP_UHH_SYSSTATUS_RESETDONE   (1  0)
+
 #defineOMAP_UHH_HOSTCONFIG (0x40)
 #defineOMAP_UHH_HOSTCONFIG_ULPI_BYPASS (1  0)
 #defineOMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS  (1  0)
@@ -66,10 +70,10 @@
 #define OMAP4_UHH_HOSTCONFIG_APP_START_CLK (1  31)
 
 /* OMAP4-specific defines */
-#define OMAP4_UHH_SYSCONFIG_IDLEMODE_CLEAR (3  2)
-#define OMAP4_UHH_SYSCONFIG_NOIDLE (1  2)
-#define OMAP4_UHH_SYSCONFIG_STDBYMODE_CLEAR(3  4)
-#define OMAP4_UHH_SYSCONFIG_NOSTDBY(1  4)
+#define OMAP4_UHH_SYSCONFIG_MIDLEMASK  (3  2)
+#define OMAP4_UHH_SYSCONFIG_MIDLESHIFT (2)
+#define OMAP4_UHH_SYSCONFIG_SIDLEMASK  (3  4)
+#define OMAP4_UHH_SYSCONFIG_SIDLESHIFT (4)
 #define OMAP4_UHH_SYSCONFIG_SOFTRESET  (1  0)
 
 #define OMAP4_P1_MODE_CLEAR(3  16)
@@ -81,6 +85,12 @@
 
 #defineOMAP_UHH_DEBUG_CSR  (0x44)
 
+/* MIDLE modes */
+#define OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY (1)
+
+/* SIDLE modes */
+#define OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE(1)
+
 /* Values of UHH_REVISION - Note: these are not given in the TRM */
 #define OMAP_USBHS_REV10x0010  /* OMAP3 */
 #define OMAP_USBHS_REV20x50700100  /* OMAP4 */
@@ -474,6 +484,97 @@ static unsigned omap_usbhs_rev2_hostconfig(struct 
usbhs_hcd_omap *omap,
return reg;
 }
 
+static void omap_usbhs_rev1_reset(struct device *dev)
+{
+   struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
+   u32 reg;
+   unsigned long timeout;
+
+   reg = usbhs_read(omap-uhh_base, OMAP_UHH_SYSCONFIG);
+
+   /* Soft Reset */
+   usbhs_write(omap-uhh_base, OMAP_UHH_SYSCONFIG,
+   reg | OMAP_UHH_SYSCONFIG_SOFTRESET);
+
+   timeout = jiffies + msecs_to_jiffies(100);
+   while (!(usbhs_read(omap-uhh_base, OMAP_UHH_SYSSTATUS)
+OMAP_UHH_SYSSTATUS_RESETDONE)) {
+   cpu_relax();
+
+   if (time_after(jiffies, timeout)) {
+   dev_err(dev, Soft RESET operation timed out\n);
+   break;
+   }
+   }
+
+   /* Set No-Standby */
+   reg = ~OMAP_UHH_SYSCONFIG_MIDLEMASK;
+   reg |= OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY
+OMAP_UHH_SYSCONFIG_MIDLESHIFT;
+
+   /* Set No-Idle */
+   reg = ~OMAP_UHH_SYSCONFIG_SIDLEMASK;
+   reg |= OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE
+OMAP_UHH_SYSCONFIG_SIDLESHIFT;
+
+   usbhs_write(omap-uhh_base, OMAP_UHH_SYSCONFIG, reg);
+}
+
+static void omap_usbhs_rev2_reset(struct device *dev)
+{
+   struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
+   u32 reg;
+   unsigned long timeout;
+
+   reg = usbhs_read(omap-uhh_base, OMAP_UHH_SYSCONFIG);
+
+   /* Soft Reset */
+   usbhs_write(omap-uhh_base, OMAP_UHH_SYSCONFIG,
+   reg | OMAP4_UHH_SYSCONFIG_SOFTRESET);
+
+   /* OMAP4: Need to wait before SYSCONFIG can be accessed */
+   udelay(2);
+   timeout = jiffies + msecs_to_jiffies(100);
+
+   /* SOFTRESET bit clears when RESET completes */
+   while

[PATCH 0/1] mfd: omap-usb-host: Bug fix for 3.13 rc

2013-11-29 Thread Roger Quadros 
Hi,

This patch fixes USB device detection issues on OMAP4 Panda with
latest u-boot release v2013.10.

Please queue it for 3.13-rc cycle. Thanks.

cheers,
-roger

Roger Quadros (1):
  mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

 drivers/mfd/omap-usb-host.c | 115 +---
 1 file changed, 109 insertions(+), 6 deletions(-)

-- 
1.8.3.2

--
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 instabilities with Atheros AR9344

2013-11-29 Thread Kristian Evensen 
Hello,

I am currently working on an embedded project based on the Atheros
AR9344 SoC. As a prototype device, we are using the TP-Link TL-WDR4300
router (http://wiki.openwrt.org/toh/tp-link/tl-wdr4300) and latest
OpenWRT trunk. The kernel is 3.10.18.

We have over the last couple of weeks experienced a USB problem that
we have not been able to solve. The USB hub works fine most of the
time, but when event X happens, USB becomes unusable for extended
periods of time. We have to disable/enable the power on the USB port
(using GPIO) and then wait until a timeout expires/queue is flushed.

The devices we have been able to trigger event X with is different
3G/LTE modems. We have not been able to figure out exactly what
triggers the event, but it happens when we move into areas with poor
or no coverage and then move back into coverage. We see the error both
with QMI-modems (qmi_wwan driver), AT-modems (option_serial driver)
and WebUI-modems (cdc_ether driver). When looking in dmesg after this
event has happened, the following messages appear based on the modem
type:

QMI:
Thu Nov 21 09:44:53 2013 kern.err kernel: [  490.60] qmi_wwan
1-1.1.2:1.4: nonzero urb status received: -71
Thu Nov 21 09:44:53 2013 kern.err kernel: [  490.60] qmi_wwan
1-1.1.2:1.4: wdm_int_callback - 0 bytes

Serial:
[62979.28] option1 ttyUSB7: option_instat_callback: error -71

WebUI:
[ 1192.68] hub 1-1:1.0: cannot reset port 1 (err = -71)
[ 1192.69] hub 1-1:1.0: Cannot enable port 1.  Maybe the USB cable is bad?

The common denominator seems to be the -71 error code, which is a
generic Protocol Error if I have understood correctly. When I search
for this error code, it seems that most problems have been due to
power. However, this seems not be the issue here. The modems are
connected to an active hub and event X happens with only a single
modem connected, so it seems unlikely that it is power.

In order to rule out the TP-Link router, we have also tested with
another router based on the same SoC (Netgear WNDR4300). The same
issue is seen. We also made some tests on a device with a different
SoC (Raspberry Pi, BCM2835) and do not see this issue.

We have mostly focused on the QMI modems and when using dynamic
debugging, dmesg also contains these errors (repeated many times):
[ 1911.20] ehci-platform ehci-platform: detected XactErr len 0/1514 retry 26
[ 1911.20] ehci-platform ehci-platform: detected XactErr len 0/64 retry 14

Each packet is, as expected, retried 32 times. The data we sent when
these messages appeared was normal TCP traffic, which explains the
packet sizes. If we leave the router alone long enough, it is able to
restart the modems (they disconnect and then connect). However, this
can take many minutes (I guess the packet queue has to be flushed?),
and while this happens the USB hub is blocked (no traffic can pass
through it).

When running usbmon, we see the following around the time of the crash
(with QMI modem):

86abea80 1428742032 S Bi:1:115:7 -150 1514 
86abeb00 1428801536 C Bi:1:115:7 0 226 = 024b322c fd930250 f300
08004500 00d4bba7 4000fd06 08728027 245d2e0f
86abeb00 1428801554 S Bi:1:115:7 -150 1514 
84895c00 1428802518 S Bo:1:115:5 -150 66 = 0250f300 024b 322cfd93
08004500 00349c42 40003f06 e6772e0f e6768027
84895c00 1428802660 C Bo:1:115:5 0 66 
86abeb80 1428982112 C Bi:1:115:7 0 1354 = 024b322c fd930250 f300
08004500 053cbbaa 4000fd06 04078027 245d2e0f
86abeb80 1428982141 S Bi:1:115:7 -150 1514 
86abec00 1429021624 C Bi:1:115:7 0 226 = 024b322c fd930250 f300
08004500 00d4bbab 4000fd06 086e8027 245d2e0f
86abec00 1429021653 S Bi:1:115:7 -150 1514 
84895480 1429022660 S Bo:1:115:5 -150 66 = 0250f300 024b 322cfd93
08004500 00349c43 40003f06 e6762e0f e6768027
84895480 1429022746 C Bo:1:115:5 0 66 
86b1dc00 1430690752 C Ii:1:115:6 0:16 8 = a101 0400
86b03d80 1430690765 S Ci:1:115:0 s a1 01  0004 1000 4096 
86b1dc00 1430690787 S Ii:1:115:6 -150:16 64 
86b03d80 1430691369 C Ci:1:115:0 0 39 = 01260080 03010400 0024001a
001e0400 9f0c 1d0200db 0e110200 01050106
86abec80 1430896349 C Bi:1:115:7 -71 0
84895800 1431014639 S Bi:1:115:7 -150 1514 
86abed00 1431066817 C Bi:1:115:7 -71 0
84895480 1431184603 S Bi:1:115:7 -150 1514 
86abed80 1431307124 C Bi:1:115:7 -71 0
86b03c00 1431330567 S Co:1:115:0 s 21 00  0004 0012 18 = 0111
0301 0125 00100200 ff00
86b03c00 1431331498 C Co:1:115:0 0 18 
86b1dc00 1431332988 C Ii:1:115:6 0:16 8 = a101 0400
86b03d80 1431332996 S Ci:1:115:0 s a1 01  0004 1000 4096 
86b1dc00 1431333012 S Ii:1:115:6 -150:16 64 
86b03d80 1431333484 C Ci:1:115:0 0 58 = 01390080 03010200 0120002d
00020400  01020092 05110400 01006e05
86b03c00 1431346879 S Co:1:115:0 s 21 00  0004 000d 13 = 010c
0301 004d 00
86b03c00 1431347879 C Co:1:115:0 0 13 
86b1dc00 1431348994 C Ii:1:115:6 0:16 8 = a101 0400
86b03d80 1431349002 S Ci:1:115:0 s a1 01  0004 1000 4096 
86b1dc00 1431349021 S Ii:1:115:6 -150:16

RE: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

2013-11-29 Thread David Laight 
 From: Of Roger Quadros
 With u-boot 2013.10, USB devices are sometimes not detected
 on OMAP4 Panda. To make us independent of what bootloader does
 with the USB Host module, we must RESET it to get it to a known
 good state. This patch Soft RESETs the USB Host module.
...
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -43,14 +43,18 @@
  /* UHH Register Set */
  #define  OMAP_UHH_REVISION   (0x00)
  #define  OMAP_UHH_SYSCONFIG  (0x10)
 -#define  OMAP_UHH_SYSCONFIG_MIDLEMODE(1  12)
 +#define  OMAP_UHH_SYSCONFIG_MIDLEMASK(3  12)
 +#define OMAP_UHH_SYSCONFIG_MIDLESHIFT(12)

(tab/space issue)

Wouldn't it be clearer to define these in the opposite order with:
+#defineOMAP_UHH_SYSCONFIG_MIDLEMASK(3  
OMAP_UHH_SYSCONFIG_MIDLESHIFT)

... 
 +static void omap_usbhs_rev1_reset(struct device *dev)
 +{
 + struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
 + u32 reg;
 + unsigned long timeout;
 +
 + reg = usbhs_read(omap-uhh_base, OMAP_UHH_SYSCONFIG);
 +
 + /* Soft Reset */
 + usbhs_write(omap-uhh_base, OMAP_UHH_SYSCONFIG,
 + reg | OMAP_UHH_SYSCONFIG_SOFTRESET);
 +
 + timeout = jiffies + msecs_to_jiffies(100);
 + while (!(usbhs_read(omap-uhh_base, OMAP_UHH_SYSSTATUS)
 +  OMAP_UHH_SYSSTATUS_RESETDONE)) {
 + cpu_relax();
 +
 + if (time_after(jiffies, timeout)) {
 + dev_err(dev, Soft RESET operation timed out\n);
 + break;
 + }
 + }
 +
 + /* Set No-Standby */
 + reg = ~OMAP_UHH_SYSCONFIG_MIDLEMASK;
 + reg |= OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY
 +  OMAP_UHH_SYSCONFIG_MIDLESHIFT;
 +
 + /* Set No-Idle */
 + reg = ~OMAP_UHH_SYSCONFIG_SIDLEMASK;
 + reg |= OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE
 +  OMAP_UHH_SYSCONFIG_SIDLESHIFT;

Why not pass in the mask and value and avoid replicating the
entire function. I can't see any other significant differences,
the udelay(2) won't be significant.

I'm not sure of the context this code runs in, but if the reset
is likely to take a significant portion of the 100ms timeout
period, why not just sleep for a few ms between status polls.

David




--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 27/31] USB: EHCI: tegra: use reset framework

2013-11-29 Thread Thierry Reding 
On Fri, Nov 15, 2013 at 01:54:22PM -0700, Stephen Warren wrote:
 From: Stephen Warren swar...@nvidia.com
 
 Tegra's clock driver now provides an implementation of the common
 reset API (include/linux/reset.h). Use this instead of the old Tegra-
 specific API; that will soon be removed.
 
 Cc: tred...@nvidia.com
 Cc: pdeschrij...@nvidia.com
 Cc: linux-te...@vger.kernel.org
 Cc: linux-arm-ker...@lists.infradead.org
 Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
 Cc: Alan Stern st...@rowland.harvard.edu
 Cc: linux-usb@vger.kernel.org
 Signed-off-by: Stephen Warren swar...@nvidia.com
 ---
 This patch is part of a series with strong internal depdendencies. I'm
 looking for an ack so that I can take the entire series through the Tegra
 and arm-soc trees. The series will be part of a stable branch that can be
 merged into other subsystems if needed to avoid/resolve dependencies.
 ---
  drivers/usb/host/ehci-tegra.c | 14 +++---
  1 file changed, 11 insertions(+), 3 deletions(-)

Reviewed-by: Thierry Reding tred...@nvidia.com


pgpVJB4hRtMwz.pgp
Description: PGP signature

Re: USB instabilities with Atheros AR9344

2013-11-29 Thread Alan Stern 
On Fri, 29 Nov 2013, Kristian Evensen wrote:

 Hello,
 
 I am currently working on an embedded project based on the Atheros
 AR9344 SoC. As a prototype device, we are using the TP-Link TL-WDR4300
 router (http://wiki.openwrt.org/toh/tp-link/tl-wdr4300) and latest
 OpenWRT trunk. The kernel is 3.10.18.
 
 We have over the last couple of weeks experienced a USB problem that
 we have not been able to solve. The USB hub works fine most of the
 time, but when event X happens, USB becomes unusable for extended
 periods of time. We have to disable/enable the power on the USB port
 (using GPIO) and then wait until a timeout expires/queue is flushed.
 
 The devices we have been able to trigger event X with is different
 3G/LTE modems. We have not been able to figure out exactly what
 triggers the event, but it happens when we move into areas with poor
 or no coverage and then move back into coverage. We see the error both
 with QMI-modems (qmi_wwan driver), AT-modems (option_serial driver)
 and WebUI-modems (cdc_ether driver). When looking in dmesg after this
 event has happened, the following messages appear based on the modem
 type:
 
 QMI:
 Thu Nov 21 09:44:53 2013 kern.err kernel: [  490.60] qmi_wwan
 1-1.1.2:1.4: nonzero urb status received: -71
 Thu Nov 21 09:44:53 2013 kern.err kernel: [  490.60] qmi_wwan
 1-1.1.2:1.4: wdm_int_callback - 0 bytes
 
 Serial:
 [62979.28] option1 ttyUSB7: option_instat_callback: error -71
 
 WebUI:
 [ 1192.68] hub 1-1:1.0: cannot reset port 1 (err = -71)
 [ 1192.69] hub 1-1:1.0: Cannot enable port 1.  Maybe the USB cable is bad?
 
 The common denominator seems to be the -71 error code, which is a
 generic Protocol Error if I have understood correctly. When I search
 for this error code, it seems that most problems have been due to
 power. However, this seems not be the issue here. The modems are
 connected to an active hub and event X happens with only a single
 modem connected, so it seems unlikely that it is power.

The most common reason for -71 errors is that the device failed to send
a reply or handshake packet back to the host.  Generally this is caused
by a bug in the device's firmware (it can also be caused by unplugging
the USB cable, but obviously that didn't happen here).  Ideally, if you 
knew what caused the device to go into this buggy state, you could 
avoid the situation.

 My question is, has anyone experienced anything similar and know how
 to solve this problem, or have any ideas on how to proceed? Since the
 error seems to be independent of drivers, I guess it points to this
 being hardware related. Would for example reducing QH_XACTERR_MAX be a
 possible (temporary) solution,

It would not help.  Once the device stops replying to the host, it 
pretty much doesn't matter what you do on the host.  The only way to 
address the problem is to do some sort of error recovery on the device.

 or are there any ways to flush this
 queue once we see the error? The most critical part for us is that USB
 is blocked for such extended periods of time.

You could try doing a USB reset of the device.  Of course, this is 
likely to cause the device to lose all its settings, so it may end up 
being worse than the original problem.

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 instabilities with Atheros AR9344

2013-11-29 Thread Kristian Evensen 
Hi,

Thank you very much for the quick reply.

On Fri, Nov 29, 2013 at 4:13 PM, Alan Stern st...@rowland.harvard.edu wrote:
 The most common reason for -71 errors is that the device failed to send
 a reply or handshake packet back to the host.  Generally this is caused
 by a bug in the device's firmware (it can also be caused by unplugging
 the USB cable, but obviously that didn't happen here).  Ideally, if you
 knew what caused the device to go into this buggy state, you could
 avoid the situation.

Thanks for the pointer. I have to admit I am a little bit unsure about
what you refer to by device, do you mean the modem or the SoC USB hub?
As it seems like most of the retransmitted packets are the big ones
(1514 bytes), I guess it is the hub that does not ACK?

 It would not help.  Once the device stops replying to the host, it
 pretty much doesn't matter what you do on the host.  The only way to
 address the problem is to do some sort of error recovery on the device.

One interesting observations is that the modems seems to work fine
after this happens. They reattach to the network, switch between
UMTS/LTE and so forth.

 You could try doing a USB reset of the device.  Of course, this is
 likely to cause the device to lose all its settings, so it may end up
 being worse than the original problem.

Thanks, this is what we are currently experimenting with. Since it
seems to be a bug in the device, we made a quick hack where we monitor
the output from the kernel and reset USB as soon as -71 is seen. We
have also patched the qh_completions()-functions to drop packets where
qtd-length - QTD_LENGTH(token) == 0, to shorten the wait for the usb
reset to be detected. After a reset, the USB hub + modems work fine.

One thing I have noticed is that when this error occurs with
option_serial, a usb reset (by using gpio) is detected immediately.
This is not the case with qmi-modems, which use cdc_wdm, they hang
until packets on the queue have been retransmitted (and we have
disconnected the devices). Is this expected behavior?

Thanks again for the help!

-Kristian
--
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 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

2013-11-29 Thread Michael Trimarchi 
Hi Roger

On Fri, Nov 29, 2013 at 2:01 PM, Roger Quadros rog...@ti.com wrote:
 With u-boot 2013.10, USB devices are sometimes not detected
 on OMAP4 Panda. To make us independent of what bootloader does
 with the USB Host module, we must RESET it to get it to a known
 good state. This patch Soft RESETs the USB Host module.


Do you think that we need something similar of usb musb?
I have seen the OTG_SYSCONFIG is touched in uboot and
only readed in omap2430.c.

Michael

 Reported-by: Tomi Valkeinen tomi.valkei...@ti.com
 Cc: sta...@vger.kernel.org # 3.10+
 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  drivers/mfd/omap-usb-host.c | 115 
 +---
  1 file changed, 109 insertions(+), 6 deletions(-)

 diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
 index 142650f..d4bd464 100644
 --- a/drivers/mfd/omap-usb-host.c
 +++ b/drivers/mfd/omap-usb-host.c
 @@ -43,14 +43,18 @@
  /* UHH Register Set */
  #defineOMAP_UHH_REVISION   (0x00)
  #defineOMAP_UHH_SYSCONFIG  (0x10)
 -#defineOMAP_UHH_SYSCONFIG_MIDLEMODE(1  12)
 +#defineOMAP_UHH_SYSCONFIG_MIDLEMASK(3  12)
 +#define OMAP_UHH_SYSCONFIG_MIDLESHIFT  (12)
  #defineOMAP_UHH_SYSCONFIG_CACTIVITY(1  8)
 -#defineOMAP_UHH_SYSCONFIG_SIDLEMODE(1  3)
 +#defineOMAP_UHH_SYSCONFIG_SIDLEMASK(3  3)
 +#defineOMAP_UHH_SYSCONFIG_SIDLESHIFT   (3)
  #defineOMAP_UHH_SYSCONFIG_ENAWAKEUP(1  2)
  #defineOMAP_UHH_SYSCONFIG_SOFTRESET(1  1)
  #defineOMAP_UHH_SYSCONFIG_AUTOIDLE (1  0)

  #defineOMAP_UHH_SYSSTATUS  (0x14)
 +#define OMAP_UHH_SYSSTATUS_RESETDONE   (1  0)
 +
  #defineOMAP_UHH_HOSTCONFIG (0x40)
  #defineOMAP_UHH_HOSTCONFIG_ULPI_BYPASS (1  0)
  #defineOMAP_UHH_HOSTCONFIG_ULPI_P1_BYPASS  (1  0)
 @@ -66,10 +70,10 @@
  #define OMAP4_UHH_HOSTCONFIG_APP_START_CLK (1  31)

  /* OMAP4-specific defines */
 -#define OMAP4_UHH_SYSCONFIG_IDLEMODE_CLEAR (3  2)
 -#define OMAP4_UHH_SYSCONFIG_NOIDLE (1  2)
 -#define OMAP4_UHH_SYSCONFIG_STDBYMODE_CLEAR(3  4)
 -#define OMAP4_UHH_SYSCONFIG_NOSTDBY(1  4)
 +#define OMAP4_UHH_SYSCONFIG_MIDLEMASK  (3  2)
 +#define OMAP4_UHH_SYSCONFIG_MIDLESHIFT (2)
 +#define OMAP4_UHH_SYSCONFIG_SIDLEMASK  (3  4)
 +#define OMAP4_UHH_SYSCONFIG_SIDLESHIFT (4)
  #define OMAP4_UHH_SYSCONFIG_SOFTRESET  (1  0)

  #define OMAP4_P1_MODE_CLEAR(3  16)
 @@ -81,6 +85,12 @@

  #defineOMAP_UHH_DEBUG_CSR  (0x44)

 +/* MIDLE modes */
 +#define OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY (1)
 +
 +/* SIDLE modes */
 +#define OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE(1)
 +
  /* Values of UHH_REVISION - Note: these are not given in the TRM */
  #define OMAP_USBHS_REV10x0010  /* OMAP3 */
  #define OMAP_USBHS_REV20x50700100  /* OMAP4 */
 @@ -474,6 +484,97 @@ static unsigned omap_usbhs_rev2_hostconfig(struct 
 usbhs_hcd_omap *omap,
 return reg;
  }

 +static void omap_usbhs_rev1_reset(struct device *dev)
 +{
 +   struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
 +   u32 reg;
 +   unsigned long timeout;
 +
 +   reg = usbhs_read(omap-uhh_base, OMAP_UHH_SYSCONFIG);
 +
 +   /* Soft Reset */
 +   usbhs_write(omap-uhh_base, OMAP_UHH_SYSCONFIG,
 +   reg | OMAP_UHH_SYSCONFIG_SOFTRESET);
 +
 +   timeout = jiffies + msecs_to_jiffies(100);
 +   while (!(usbhs_read(omap-uhh_base, OMAP_UHH_SYSSTATUS)
 +OMAP_UHH_SYSSTATUS_RESETDONE)) {
 +   cpu_relax();
 +
 +   if (time_after(jiffies, timeout)) {
 +   dev_err(dev, Soft RESET operation timed out\n);
 +   break;
 +   }
 +   }
 +
 +   /* Set No-Standby */
 +   reg = ~OMAP_UHH_SYSCONFIG_MIDLEMASK;
 +   reg |= OMAP_UHH_SYSCONFIG_MIDLE_NOSTANDBY
 +OMAP_UHH_SYSCONFIG_MIDLESHIFT;
 +
 +   /* Set No-Idle */
 +   reg = ~OMAP_UHH_SYSCONFIG_SIDLEMASK;
 +   reg |= OMAP_UHH_SYSCONFIG_SIDLE_NOIDLE
 +OMAP_UHH_SYSCONFIG_SIDLESHIFT;
 +
 +   usbhs_write(omap-uhh_base, OMAP_UHH_SYSCONFIG, reg);
 +}
 +
 +static void omap_usbhs_rev2_reset(struct device *dev)
 +{
 +   struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
 +   u32 reg;
 +   unsigned long timeout;
 +
 +   reg = usbhs_read(omap-uhh_base, OMAP_UHH_SYSCONFIG);
 +
 +   /* Soft Reset */
 +

[PATCH] Added support for the Lenovo RD02-D400 USB Modem

2013-11-29 Thread david . cluytens 
From: David Cluytens david.cluytens_...@softathome.com

---
 drivers/usb/class/cdc-acm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 3e7560f..8ad4e94 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -1515,6 +1515,8 @@ static int acm_reset_resume(struct usb_interface *intf)
 
 static const struct usb_device_id acm_ids[] = {
/* quirky and broken devices */
+{ USB_DEVICE(0x17ef, 0x7000), /* Lenovo USB modem */
+.driver_info = NO_UNION_NORMAL, },/* has no union descriptor */
{ USB_DEVICE(0x0870, 0x0001), /* Metricom GS Modem */
.driver_info = NO_UNION_NORMAL, /* has no union descriptor */
},
-- 
1.8.4.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

some question about period scheduleing

2013-11-29 Thread vichy 
hi all:
My connection like below
ehci -- high speed hub - full speed device

I have some questions about period scheduling.
1. when creating  qh for full speed device,  why we set EHCI_TUNE_RL_TT.
isn't it possible the full speed device return NAK during transaction?
that mean once it react with NAK, the host will stop below transaction.
How could we make sure device never react with NAK?

2. I attach my mon log for your reference.
there is one thing I am curious
why below message 'E' mean in bulk/interrupt?
I have checked Document/usb/usbmon.txt but get nothing.

d8c32600 190047566 E Bi:1:006:2 -19 0
d8c32980 190062351 C Bi:1:006:2 -107 0
d8c32980 190062363 S Bi:1:006:2 -115 1025 
d8c32980 190072803 E Bi:1:006:2 -19 0
d71e1080 190087616 C Bi:1:006:2 -107 0
d71e1080 190087631 S Bi:1:006:2 -115 1025 
d71e1080 190098075 E Bi:1:006:2 -19 0
d8c32e80 190112778 C Ii:1:006:1 -107:1 0
d8c32e80 190112798 S Ii:1:006:1 -115:1 258 
d8c32e80 190112823 E Ii:1:006:1 -19 0

grateful to your help,
d8c1f900 174296127 S Ci:1:006:0 s 80 06 0100  0012 18 
d8c1f900 174324543 C Ci:1:006:0 0 18 = 12010002 ff010140 5c0abe22 12010102 0301
d8c32c80 174328283 S Ci:1:006:0 s 80 06 0600  000a 10 
d8c32c80 174379310 C Ci:1:006:0 -32 0
d8c32c80 174379388 S Ci:1:006:0 s 80 06 0600  000a 10 
d8c32c80 174430320 C Ci:1:006:0 -32 0
d8c32c80 174430384 S Ci:1:006:0 s 80 06 0600  000a 10 
d8c32c80 174479871 C Ci:1:006:0 -32 0
da681c00 174484791 S Ci:1:006:0 s 80 06 0200  0009 9 
da681c00 174520974 C Ci:1:006:0 0 9 = 0902da00 040100e0 00
da681c00 174521041 S Ci:1:006:0 s 80 06 0200  00da 218 
da681c00 174564730 C Ci:1:006:0 0 218 = 0902da00 040100e0 00090400 0003ff01 01000705 81031000 01070582 0241
d8c32680 174571894 S Ci:1:006:0 s 80 06 0300  00ff 255 
d8c32680 174613002 C Ci:1:006:0 0 4 = 04030904
d8c32680 174618720 S Ci:1:006:0 s 80 06 0302 0409 00ff 255 
d8c32680 174661979 C Ci:1:006:0 0 22 = 16034200 43004d00 32003000 37003000 32004100 3000
d8c32680 174662431 S Ci:1:006:0 s 80 06 0301 0409 00ff 255 
d8c32680 174704527 C Ci:1:006:0 0 28 = 1c034200 72006f00 61006400 63006f00 6d002000 43006f00 72007000
d8c32680 174704770 S Ci:1:006:0 s 80 06 0303 0409 00ff 255 
d8c32680 174746502 C Ci:1:006:0 0 26 = 1a033000 30003000 42003600 42004500 44003900 39003800 3600
d8c32680 174807834 S Co:1:006:0 s 00 09 0001   0
d8c32680 174834431 C Co:1:006:0 0 0
d8c32680 174870590 S Co:1:006:0 s 01 0b  0001  0
d8c32680 174897880 C Co:1:006:0 0 0
d8c32e80 174922305 S Ii:1:006:1 -115:1 258 
d8c32b80 174931010 S Ii:1:006:1 -115:1 258 
d8c32480 174931177 S Ii:1:006:1 -115:1 258 
d8c32300 174931267 S Ii:1:006:1 -115:1 258 
d8c32400 174931352 S Ii:1:006:1 -115:1 258 
d8c32f00 174931428 S Ii:1:006:1 -115:1 258 
d8c32e00 174931493 S Ii:1:006:1 -115:1 258 
d8c32a00 174931565 S Ii:1:006:1 -115:1 258 
d8c32280 174931652 S Bi:1:006:2 -115 1025 
d8c32a80 174942316 S Bi:1:006:2 -115 1025 
d8c32580 174953281 S Bi:1:006:2 -115 1025 
d8c32180 174964533 S Bi:1:006:2 -115 1025 
d8c32b00 174975493 S Bi:1:006:2 -115 1025 
d8c32080 174986576 S Bi:1:006:2 -115 1025 
d8c32780 174997454 S Bi:1:006:2 -115 1025 
d8c32f80 175008444 S Bi:1:006:2 -115 1025 
d8c32500 175019240 S Bi:1:006:2 -115 1025 
d8c32600 175030098 S Bi:1:006:2 -115 1025 
d8c32980 175040930 S Bi:1:006:2 -115 1025 
d71e1080 175051876 S Bi:1:006:2 -115 1025 
d71e1700 175062714 S Bi:1:006:4 -115 1025 
d71e1780 175073656 S Bi:1:006:4 -115 1025 
d8c32680 175330914 S Co:1:006:0 s 20 00   0003 3 = 030c00
d8c32680 175359355 C Co:1:006:0 0 3 
d8c32e80 175368360 C Ii:1:006:1 0:1 6 = 0e040103 0c00
d8c32e80 175369092 S Ii:1:006:1 -115:1 258 
d8c32680 175379837 S Co:1:006:0 s 20 00   0003 3 = 051000
d8c32680 175415382 C Co:1:006:0 0 3 
d8c32b80 175424464 C Ii:1:006:1 0:1 13 = 0e0b0105 1000fd03 40080001 00
d8c32b80 175427478 S Ii:1:006:1 -115:1 258 
d8c32680 175435384 S Co:1:006:0 s 20 00   000a 10 = 330c079b 06ff1400 0a00
d8c32680 175471360 C Co:1:006:0 0 10 
d8c32480 175480365 C Ii:1:006:1 0:1 6 = 0e040133 0c00
d8c32480 175480492 S Ii:1:006:1 -115:1 258 
d8c32680 175481017 S Co:1:006:0 s 20 00   0003 3 = 011000
d8c32680 175525553 C Co:1:006:0 0 3 
d8c32300 175534638 C Ii:1:006:1 0:1 14 = 0e0c0101 16b8 21060f00 0e41
d8c32300 175534750 S Ii:1:006:1 -115:1 258 
d8c32680 175535082 S Co:1:006:0 s 20 00   0003 3 = 091000
d8c32680 175579666 C Co:1:006:0 0 3 
d8c32400 175588769 C Ii:1:006:1 0:1 12 = 0e0a0109 10008699 ed6b0b00
d8c32400 175588874 S Ii:1:006:1 -115:1 258 
d8c32680 175589408 S Co:1:006:0 s 20 00   0003 3 = 021000
d8c32680 175635075 C Co:1:006:0 0 3 
d8c32f00 175644175 C Ii:1:006:1 0:1 70 = 0e440102 1000 ff03ccff efffcfff ec1ff20f e8fe3ff7 8fff1c00 61f7
d8c32f00 175644312 S Ii:1:006:1 -115:1 258 
d8c32680 175644670 S Co:1:006:0 s 20 00   0003 3 = 031000
d8c32680 175690521 C Co:1:006:0 0 3 
d8c32e00 175699606 C Ii:1:006:1 0:1 14 = 0e0c0103 1000bffe cffedbff

Re: [PATCH v3 12/16] usb/gadget: FunctionFS: add devices management code

2013-11-29 Thread Michal Nazarewicz 
Acked-by: Michal Nazarewicz min...@mina86.com

Only some small comments.

On Fri, Nov 22 2013, Andrzej Pietrasiewicz wrote:
 @@ -2465,6 +2474,209 @@ static int ffs_func_revmap_intf(struct ffs_function 
 *func, u8 intf)
  }
  
  
 +/* Devices management 
 ***/
 +
 +static LIST_HEAD(ffs_devices);
 +
 +void ffs_dev_lock(void)
 +{
 + mutex_lock(ffs_lock);
 +}
 +
 +void ffs_dev_unlock(void)
 +{
 + mutex_unlock(ffs_lock);
 +}

Perhaps it will be more efficient to have those as static inlines and
extern ffs_lock in header file instead?

 +
 +static struct ffs_dev *_ffs_find_dev(const char *name)
 +{
 + struct ffs_dev *dev;
 +
 + list_for_each_entry(dev, ffs_devices, entry) {
 + if (!dev-name || !name)
 + continue;
 + if (strcmp(dev-name, name) == 0)
 + return dev;
 + }
 + 
 + return NULL;
 +}
 +
 +/*
 + * ffs_lock must be taken by the caller of this function
 + */
 +static struct ffs_dev *ffs_find_dev(const char *name)
 +{
 + struct ffs_dev *dev;
 +
 + if (list_is_singular(ffs_devices)) {
 + dev = list_first_entry(ffs_devices, struct ffs_dev, entry);
 + if (dev-single)
 + return dev;

Wouldn't it be easier to do this check in _ffs_find_dev?  It is possible
to have non-singular list with some devs having dev-single set?
I don't think that it is since ffs_alloc_dev checks whether list is
singular with the only element having dev-single.

 + }
 +
 + return _ffs_find_dev(name);
 +}
 +
 +/*
 + * ffs_lock must be taken by the caller of this function
 + */
 +struct ffs_dev *ffs_alloc_dev(void)
 +{
 + struct ffs_dev *dev;
 + int ret;
 +
 + if (list_is_singular(ffs_devices)) {
 + dev = list_first_entry(ffs_devices, struct ffs_dev, entry);
 + if (dev-single)
 + return ERR_PTR(-EBUSY);
 + }

This condition is used for the second time, perhaps it would be better
to have a function:

static struct ffs_dev *ffs_get_single_dev(void) 
{
if (list_is_singular(ffs_devices)) {
dev = list_first_entry(ffs_devices, struct ffs_dev, entry);
if (dev-single)
return dev;
}
return NULL;
}

Then, ffs_find_dev would do:

dev = ffs_get_single_dev();
if (dev)
return dev;

And ffs_alloc_dev would do:

if (ffs_get_single_dev())
return ERR_PTR(-EBUSY);

This of course is mutually exclusive with my previous comment.  Also,
it's up to you, I don't have strong opinions.

 +
 + dev = kzalloc(sizeof(*dev), GFP_KERNEL);
 + if (!dev)
 + return ERR_PTR(-ENOMEM);
 +
 + if (list_empty(ffs_devices)) {
 + ret = functionfs_init();
 + if (ret) {
 + kfree(dev);
 + return ERR_PTR(ret);
 + }
 + }
 +
 + list_add(dev-entry, ffs_devices);
 +
 + return dev;
 +}
 +
 +/*
 + * ffs_lock must be taken by the caller of this function
 + * The caller is responsible for name being available whenever f_fs needs 
 it
 + */
 +int ffs_name_dev(struct ffs_dev *dev, const char *name)
 +{
 + struct ffs_dev *existing;
 +
 + existing = _ffs_find_dev(name);
 + if (existing)
 + return -EBUSY;
 + 
 + dev-name = name;
 +
 + return 0;
 +}
 +
 +/*
 + * ffs_lock must be taken by the caller of this function
 + */
 +int ffs_single_dev(struct ffs_dev *dev, bool single)
 +{
 + if (single  !list_is_singular(ffs_devices))
 + return -EBUSY;
 +
 + dev-single = single;
 +
 + return 0;
 +}
 +
 +/*
 + * ffs_lock must be taken by the caller of this function
 + */
 +void ffs_free_dev(struct ffs_dev *dev)
 +{
 + list_del(dev-entry);
 + if (list_empty(ffs_devices))
 + functionfs_cleanup();
 +
 + kfree(dev);

I'd free before functionfs_cleanup, but up to you.

 +}
 +
 +static void *ffs_acquire_dev(const char *dev_name)
 +{
 + struct ffs_dev *ffs_dev;
 +
 + ENTER();
 + ffs_dev_lock();
 +
 + ffs_dev = ffs_find_dev(dev_name);
 + if (!ffs_dev) {
 + ffs_dev = ERR_PTR(-ENODEV);
 + goto done;
 + }
 +
 + if (ffs_dev-mounted) {
 + ffs_dev = ERR_PTR(-EBUSY);
 + goto done;
 + }
 + ffs_dev-mounted = true;

This could be rewritten to avoid goto and in fact shorten the code:

if (!ffs_dev)
ffs_dev = ERR_PTR(-ENODEV);
else if (ffs_dev-mounted)
ffs_dev = ERR_PTR(-EBUSY);
else
ffs_dev-mounted = true;

 +
 +done:
 + ffs_dev_unlock();
 + return ffs_dev;
 +}
  /* Misc helper functions 
 /
  
  static int ffs_mutex_lock(struct mutex *mutex, unsigned nonblock)
 diff --git a/drivers/usb/gadget/g_ffs.c b/drivers/usb/gadget/g_ffs.c

Re: [PATCH 2/3 v2] usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag

2013-11-29 Thread Michael Grzeschik 
On Fri, Nov 29, 2013 at 03:19:45PM +0800, Chris Ruehl wrote:
 usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag
 
 * init the sts flag to 0 (missed)
 * set the sts flag only if not 0
 
 Signed-off-by: Chris Ruehl chris.ru...@gtsys.com.hk
 ---
  drivers/usb/chipidea/core.c |8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
 index 5075407..1a6010e 100644
 --- a/drivers/usb/chipidea/core.c
 +++ b/drivers/usb/chipidea/core.c
 @@ -245,6 +245,8 @@ static void hw_phymode_configure(struct ci_hdrc *ci)
  {
   u32 portsc, lpm, sts = 0;
  
   switch (ci-platdata-phy_mode) {
   case USBPHY_INTERFACE_MODE_UTMI:
   portsc = PORTSC_PTS(PTS_UTMI);
 @@ -273,10 +275,12 @@ static void hw_phymode_configure(struct ci_hdrc *ci)
  
   if (ci-hw_bank.lpm) {
   hw_write(ci, OP_DEVLC, DEVLC_PTS(7) | DEVLC_PTW, lpm);
 - hw_write(ci, OP_DEVLC, DEVLC_STS, sts);
 + if (sts)
 + hw_write(ci, OP_DEVLC, DEVLC_STS, sts);
   } else {
   hw_write(ci, OP_PORTSC, PORTSC_PTS(7) | PORTSC_PTW, portsc);
 - hw_write(ci, OP_PORTSC, PORTSC_STS, sts);
 + if ( sts )
 + hw_write(ci, OP_PORTSC, PORTSC_STS, sts);

The conditions coding style is broken.

   }
  }

Still don't get why a system with ehci compliant PORTSC register
should not want to have the sts bit _explicitly_ set to 0 if
we don't use serial phy mode. So NACK!

Michael

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: cdc-wdm: manage_power should always set needs_remote_wakeup

2013-11-29 Thread Bjørn Mork 
Cc: sta...@vger.kernel.org
Reported-by: Oliver Neukum oneu...@suse.de
Signed-off-by: Bjørn Mork bj...@mork.no
---
 drivers/usb/class/cdc-wdm.c |8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-wdm.c
index 4d387596f3f0..0b23a8639311 100644
--- a/drivers/usb/class/cdc-wdm.c
+++ b/drivers/usb/class/cdc-wdm.c
@@ -854,13 +854,11 @@ static int wdm_manage_power(struct usb_interface *intf, 
int on)
 {
/* need autopm_get/put here to ensure the usbcore sees the new value */
int rv = usb_autopm_get_interface(intf);
-   if (rv  0)
-   goto err;
 
intf-needs_remote_wakeup = on;
-   usb_autopm_put_interface(intf);
-err:
-   return rv;
+   if (!rv)
+   usb_autopm_put_interface(intf);
+   return 0;
 }
 
 static int wdm_probe(struct usb_interface *intf, const struct usb_device_id 
*id)
-- 
1.7.10.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: [PATCH] Added support for the Lenovo RD02-D400 USB Modem

2013-11-29 Thread Sergei Shtylyov 

Hello.

On 29-11-2013 19:46, david.cluyt...@gmail.com wrote:


From: David Cluytens david.cluytens_...@softathome.com



---
  drivers/usb/class/cdc-acm.c | 2 ++
  1 file changed, 2 insertions(+)



diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 3e7560f..8ad4e94 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -1515,6 +1515,8 @@ static int acm_reset_resume(struct usb_interface *intf)

  static const struct usb_device_id acm_ids[] = {
/* quirky and broken devices */
+{ USB_DEVICE(0x17ef, 0x7000), /* Lenovo USB modem */
+.driver_info = NO_UNION_NORMAL, },/* has no union descriptor */


   Indent with tab please, as below.


{ USB_DEVICE(0x0870, 0x0001), /* Metricom GS Modem */
.driver_info = NO_UNION_NORMAL, /* has no union descriptor */
},


WBR, Sergei

--
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 v1 1/2] lib/scatterlist: export sg_miter_skip()

2013-11-29 Thread Tejun Heo 
On Tue, Nov 26, 2013 at 12:43:37PM +0800, Ming Lei wrote:
 sg_copy_buffer() can't meet demand for some drrivers(such usb
 mass storage), so we have to use the sg_miter_* APIs to access
 sg buffer, then need export sg_miter_skip() for these drivers.
 
 The API is needed for converting to sg_miter_* APIs in USB storage
 driver for accessing sg buffer.
 
 Acked-by: Andrew Morton a...@linux-foundation.org
 Cc: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
 Cc: Tejun Heo t...@kernel.org
 Cc: Jens Axboe ax...@kernel.dk
 Signed-off-by: Ming Lei ming@canonical.com

Reviewed-by: Tejun Heo t...@kernel.org

I suppose this should go through -mm?

Thanks.

-- 
tejun
--
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 2/3 v2] usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag

2013-11-29 Thread Chris Ruehl 

On Saturday, November 30, 2013 02:28 AM, Michael Grzeschik wrote:

On Fri, Nov 29, 2013 at 03:19:45PM +0800, Chris Ruehl wrote:

usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag

* init the sts flag to 0 (missed)
* set the sts flag only if not 0

Signed-off-by: Chris Ruehlchris.ru...@gtsys.com.hk
---
  drivers/usb/chipidea/core.c |8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 5075407..1a6010e 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -245,6 +245,8 @@ static void hw_phymode_configure(struct ci_hdrc *ci)
  {
u32 portsc, lpm, sts = 0;

switch (ci-platdata-phy_mode) {
case USBPHY_INTERFACE_MODE_UTMI:
portsc = PORTSC_PTS(PTS_UTMI);
@@ -273,10 +275,12 @@ static void hw_phymode_configure(struct ci_hdrc *ci)

if (ci-hw_bank.lpm) {
hw_write(ci, OP_DEVLC, DEVLC_PTS(7) | DEVLC_PTW, lpm);
-   hw_write(ci, OP_DEVLC, DEVLC_STS, sts);
+   if (sts)
+   hw_write(ci, OP_DEVLC, DEVLC_STS, sts);
} else {
hw_write(ci, OP_PORTSC, PORTSC_PTS(7) | PORTSC_PTW, portsc);
-   hw_write(ci, OP_PORTSC, PORTSC_STS, sts);
+   if ( sts )
+   hw_write(ci, OP_PORTSC, PORTSC_STS, sts);


The conditions coding style is broken.


}
  }


Still don't get why a system with ehci compliant PORTSC register
should not want to have the sts bit _explicitly_ set to 0 if
we don't use serial phy mode. So NACK!

Michael


Michael,

I agree that this patch is not sufficient. I had a look in the reference manual 
for the imx27 and here:


Serial Transceiver Select—Read/Write. This register bit is used in conjunction 
with the configuration constant
VUSB_HS_PHY_SERIAL to control whether the parallel or serial transceiver 
interface is selected for FS and LS
operation. The Serial Interface Engine can be used in combination with the UTMI+ 
or ULPI physical interface to
provide FS/LS signaling instead of the parallel interface. If VUSB_HS_PHY_SERIAL 
is set for 0 or 1 then this

bit is read only. If VUSB_HS_PHY_SERIAL is 3 or 4 then this bit is read/write.
This bit has no effect unless Parallel Transceiver Select is set to UTMI+ or 
ULPI. The Serial/1.1 physical interface
will use the Serial Interface Engine for FS/LS signaling regardless of this bit 
value.
Note: This bit is reserved for future operation and is a placeholder adding 
dynamic use of the serial engine in

accord with UMTI+ and ULPI characterization logic.
This bit is not defined in the EHCI specification.


To make it short. In some VUSB_HS_PHY_SERIAL configurations the STS is a READ 
ONLY and should not be written. The current code (without my wrong patch) always 
write to the STS!

With the patch there was no write and no oops with Internal 808 ARM exception..

Let me rework it.

Regards
Chris
--
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 2/3 v2] usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag

2013-11-29 Thread Chris Ruehl 

On Saturday, November 30, 2013 02:28 AM, Michael Grzeschik wrote:

On Fri, Nov 29, 2013 at 03:19:45PM +0800, Chris Ruehl wrote:

usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag

* init the sts flag to 0 (missed)
* set the sts flag only if not 0

Signed-off-by: Chris Ruehlchris.ru...@gtsys.com.hk
---
  drivers/usb/chipidea/core.c |8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 5075407..1a6010e 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -245,6 +245,8 @@ static void hw_phymode_configure(struct ci_hdrc *ci)
  {
u32 portsc, lpm, sts = 0;

switch (ci-platdata-phy_mode) {
case USBPHY_INTERFACE_MODE_UTMI:
portsc = PORTSC_PTS(PTS_UTMI);
@@ -273,10 +275,12 @@ static void hw_phymode_configure(struct ci_hdrc *ci)

if (ci-hw_bank.lpm) {
hw_write(ci, OP_DEVLC, DEVLC_PTS(7) | DEVLC_PTW, lpm);
-   hw_write(ci, OP_DEVLC, DEVLC_STS, sts);
+   if (sts)
+   hw_write(ci, OP_DEVLC, DEVLC_STS, sts);
} else {
hw_write(ci, OP_PORTSC, PORTSC_PTS(7) | PORTSC_PTW, portsc);
-   hw_write(ci, OP_PORTSC, PORTSC_STS, sts);
+   if ( sts )
+   hw_write(ci, OP_PORTSC, PORTSC_STS, sts);


The conditions coding style is broken.


}
  }


Still don't get why a system with ehci compliant PORTSC register
should not want to have the sts bit _explicitly_ set to 0 if
we don't use serial phy mode. So NACK!

Michael


That's happen when I remove the if() statements and unconditional write the sts 
flag

[1.128482] ehci-mxc: Freescale On-Chip EHCI Host driver
[1.136702] usbcore: registered new interface driver usb-storage
[1.147594] imx_usb 10024000.usb: dummy supplies not allowed
[1.154803] Unhandled fault: external abort on non-linefetch (0x808) at 
0xf4424184

[1.162424] Internal error: : 808 [#1] ARM
[1.166548] Modules linked in:
[1.169670] CPU: 0 PID: 1 Comm: swapper Not tainted 
3.13.0-rc1-next-20131125-dirty #44

[1.177629] task: cf85 ti: cf852000 task.ti: cf852000
[1.183086] PC is at ci_hdrc_probe+0x250/0x630
[1.187582] LR is at console_unlock+0x2d4/0x30c
[1.192165] pc : [c025f7a8]lr : [c003ec50]psr: 6013


regards
Chris

--
GTSYS Limited RFID Technology
A01 24/F Gold King Industrial Bld
35-41 Tai Lin Pai Road, Kwai Chung, Hong Kong
Fax (852) 8167 4060 - Tel (852) 3598 9488

Disclaimer: http://www.gtsys.com.hk/email/classified.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 2/3 v2] usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag

2013-11-29 Thread Chris Ruehl 



On Saturday, November 30, 2013 02:28 AM, Michael Grzeschik wrote:

On Fri, Nov 29, 2013 at 03:19:45PM +0800, Chris Ruehl wrote:

usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag

* init the sts flag to 0 (missed)
* set the sts flag only if not 0

Signed-off-by: Chris Ruehlchris.ru...@gtsys.com.hk
---
  drivers/usb/chipidea/core.c |8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 5075407..1a6010e 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -245,6 +245,8 @@ static void hw_phymode_configure(struct ci_hdrc *ci)
  {
u32 portsc, lpm, sts = 0;

switch (ci-platdata-phy_mode) {
case USBPHY_INTERFACE_MODE_UTMI:
portsc = PORTSC_PTS(PTS_UTMI);
@@ -273,10 +275,12 @@ static void hw_phymode_configure(struct ci_hdrc *ci)

if (ci-hw_bank.lpm) {
hw_write(ci, OP_DEVLC, DEVLC_PTS(7) | DEVLC_PTW, lpm);
-   hw_write(ci, OP_DEVLC, DEVLC_STS, sts);
+   if (sts)
+   hw_write(ci, OP_DEVLC, DEVLC_STS, sts);
} else {
hw_write(ci, OP_PORTSC, PORTSC_PTS(7) | PORTSC_PTW, portsc);
-   hw_write(ci, OP_PORTSC, PORTSC_STS, sts);
+   if ( sts )
+   hw_write(ci, OP_PORTSC, PORTSC_STS, sts);


The conditions coding style is broken.


}
  }


Still don't get why a system with ehci compliant PORTSC register
should not want to have the sts bit _explicitly_ set to 0 if
we don't use serial phy mode. So NACK!

Michael



Guys,,, I must be blind

hw_write(ci, OP_PORTSC, PORTSC_STS, sts);
sts has a wrong value, its should be (sts  29) when sts = 1
same for lpm value (lpm  28)

Still needs to check the value of PTS, if PTS  1  or sts flag is read only.


if (ci-hw_bank.lpm) {
hw_write(ci, OP_DEVLC, DEVLC_PTS(7) | DEVLC_PTW, lpm);
if ( sts )
hw_write(ci, OP_DEVLC, DEVLC_STS, BIT(28));
else
hw_write(ci, OP_DEVLC, DEVLC_STS, ~BIT(28));
} else {
hw_write(ci, OP_PORTSC, PORTSC_PTS(7) | PORTSC_PTW, portsc);
if (((portsc  30)  0x3)  1) {   /* check if STS is read 
only */
if (sts) {
hw_write(ci, OP_PORTSC, PORTSC_STS, BIT(29));
}
else {
portsc = 
(ioread32(ci-hw_bank.regmap[OP_PORTSC])
 BIT(29));
if (portsc)  /* sts needs reset */
hw_write(ci, OP_PORTSC, PORTSC_STS,
~BIT(29));
}
}
}


With a write to an already sts = 0 my kernel oops 808. so check if the sts is 0 
and if 0 then no write.


Can someone have a look for the lpm stuff ?


Michael, thanks for the NOACK ;-) otherwise

Regards
Chris








--
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: net/usb/ax88179_178a driver broken in linux-3.12

2013-11-29 Thread Mark Lord 
On 13-11-19 08:44 AM, Mark Lord wrote:
 On 13-11-19 05:04 AM, David Laight wrote:

 Which changes did you revert?
 
 Just the bits that changed how the headroom/tailroom sizes
 were checked and adjusted.  See attachment for the revert patch
 I am using here.  My mailer unfortunately likes to mangle inline patches.
 
 =snip===
 Revert USB 3.0 network driver changes that break the adapter (lockups)
 in 3.12.  This just puts back the original code from previous kernels.
 
 Signed-off-by: Mark Lord ml...@pobox.com
 
 --- linux/drivers/net/usb/ax88179_178a.c.orig   2013-11-03 18:41:51.0 
 -0500
 +++ linux/drivers/net/usb/ax88179_178a.c2013-11-17 13:23:39.525734277 
 -0500
 @@ -1177,18 +1177,31 @@
 int frame_size = dev-maxpacket;
 int mss = skb_shinfo(skb)-gso_size;
 int headroom;
 +   int tailroom;
 
 tx_hdr1 = skb-len;
 tx_hdr2 = mss;
 if (((skb-len + 8) % frame_size) == 0)
 tx_hdr2 |= 0x80008000;  /* Enable padding */
 
 -   headroom = skb_headroom(skb) - 8;
 +   headroom = skb_headroom(skb);
 +   tailroom = skb_tailroom(skb);
 
 -   if ((skb_header_cloned(skb) || headroom  0) 
 -   pskb_expand_head(skb, headroom  0 ? 8 : 0, 0, GFP_ATOMIC)) {
 +   if (!skb_header_cloned(skb) 
 +   !skb_cloned(skb) 
 +   (headroom + tailroom) = 8) {
 +   if (headroom  8) {
 +   skb-data = memmove(skb-head + 8, skb-data, 
 skb-len);
 +   skb_set_tail_pointer(skb, skb-len);
 +   }
 +   } else {
 +   struct sk_buff *skb2;
 +
 +   skb2 = skb_copy_expand(skb, 8, 0, flags);
 dev_kfree_skb_any(skb);
 -   return NULL;
 +   skb = skb2;
 +   if (!skb)
 +   return NULL;
 }
 
 skb_push(skb, 4);
 


Two kernels later, and this regression has still not been fixed.

A simple revert, folks.
-- 
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3 v3] usb: chipidea: Reallocate regmap only if lpm is detected

2013-11-29 Thread Chris Ruehl 
usb: chipidea: Reallocate regmap only if lpm is detected

The regmap only needs to reallocate if the hw_read on the CAP register shows
lpm is used. Therefore the if() statement check the change.

Signed-off-by: Chris Ruehl chris.ru...@gtsys.com.hk
Acked-by: Peter Chen peter.c...@freescale.com
---
 drivers/usb/chipidea/core.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 5d8981c..5075407 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -208,7 +208,8 @@ static int hw_device_init(struct ci_hdrc *ci, void __iomem 
*base)
reg = hw_read(ci, CAP_HCCPARAMS, HCCPARAMS_LEN) 
__ffs(HCCPARAMS_LEN);
ci-hw_bank.lpm  = reg;
-   hw_alloc_regmap(ci, !!reg);
+   if (reg)
+   hw_alloc_regmap(ci, !!reg);
ci-hw_bank.size = ci-hw_bank.op - ci-hw_bank.abs;
ci-hw_bank.size += OP_LAST;
ci-hw_bank.size /= sizeof(u32);
-- 
1.7.10.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 v3] usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag

2013-11-29 Thread Chris Ruehl 
usb: chipidea: Fix Internal error: : 808 [#1] ARM related to STS flag

* init the sts flag to 0 (missed)
* Set PORTCS_STS only if VUSB_HS_PHY_TYPE  1
  otherwise the register is ReadOnly
* Set/Reset correct BIT(28)/BIT(29) for STS

Signed-off-by: Chris Ruehl chris.ru...@gtsys.com.hk
---
 drivers/usb/chipidea/core.c |   20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 5075407..2c634c1 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -243,7 +243,7 @@ static int hw_device_init(struct ci_hdrc *ci, void __iomem 
*base)
 
 static void hw_phymode_configure(struct ci_hdrc *ci)
 {
-   u32 portsc, lpm, sts;
+   u32 portsc, lpm, sts = 0;
 
switch (ci-platdata-phy_mode) {
case USBPHY_INTERFACE_MODE_UTMI:
@@ -273,10 +273,24 @@ static void hw_phymode_configure(struct ci_hdrc *ci)
 
if (ci-hw_bank.lpm) {
hw_write(ci, OP_DEVLC, DEVLC_PTS(7) | DEVLC_PTW, lpm);
-   hw_write(ci, OP_DEVLC, DEVLC_STS, sts);
+   if ( sts )
+   hw_write(ci, OP_DEVLC, DEVLC_STS, BIT(28));
+   else
+   hw_write(ci, OP_DEVLC, DEVLC_STS, ~BIT(28));
} else {
hw_write(ci, OP_PORTSC, PORTSC_PTS(7) | PORTSC_PTW, portsc);
-   hw_write(ci, OP_PORTSC, PORTSC_STS, sts);
+   if (((portsc  30)  0x3)  1) {
+   if (sts) {
+   hw_write(ci, OP_PORTSC, PORTSC_STS, BIT(29));
+   }
+   else {
+   portsc = 
(ioread32(ci-hw_bank.regmap[OP_PORTSC])
+PORTSC_STS);
+   if (portsc)
+   hw_write(ci, OP_PORTSC, PORTSC_STS,
+   ~BIT(29));
+   }
+   }
}
 }
 
-- 
1.7.10.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: [PATCH v2 1/2] usb: chipidea: usbmisc: Add support for i.MX27/i.MX31 CPUs

2013-11-29 Thread Chris Ruehl 



On Tuesday, November 26, 2013 11:36 PM, Alexander Shiyan wrote:

This adds i.MX27 and i.MX31 as the next user of the usbmisc driver.

Signed-off-by: Alexander Shiyanshc_w...@mail.ru
---
  drivers/usb/chipidea/usbmisc_imx.c | 42 ++
  1 file changed, 42 insertions(+)

diff --git a/drivers/usb/chipidea/usbmisc_imx.c 
b/drivers/usb/chipidea/usbmisc_imx.c
index 8a1094b..4381c5a6 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -21,6 +21,10 @@
  #define MX25_USB_PHY_CTRL_OFFSET  0x08
  #define MX25_BM_EXTERNAL_VBUS_DIVIDER BIT(23)

+#define MX27_H1_PM_BIT BIT(8)
+#define MX27_H2_PM_BIT BIT(16)
+#define MX27_OTG_PM_BITBIT(24)
+
  #define MX53_USB_OTG_PHY_CTRL_0_OFFSET0x08
  #define MX53_USB_UH2_CTRL_OFFSET  0x14
  #define MX53_USB_UH3_CTRL_OFFSET  0x18
@@ -68,6 +72,36 @@ static int usbmisc_imx25_post(struct imx_usbmisc_data *data)
return 0;
  }

+static int usbmisc_imx27_init(struct imx_usbmisc_data *data)
+{
+   unsigned long flags;
+   u32 val;
+
+   switch (data-index) {
+   case 0:
+   val = MX27_OTG_PM_BIT;
+   break;
+   case 1:
+   val = MX27_H1_PM_BIT;
+   break;
+   case 2:
+   val = MX27_H2_PM_BIT;
+   break;
+   default:
+   return -EINVAL;
+   };
+
+   spin_lock_irqsave(usbmisc-lock, flags);
+   if (data-disable_oc)
+   val = readl(usbmisc-base) | val;
+   else
+   val = readl(usbmisc-base)  ~val;
+   writel(val, usbmisc-base);
+   spin_unlock_irqrestore(usbmisc-lock, flags);
+
+   return 0;
+}
+
  static int usbmisc_imx53_init(struct imx_usbmisc_data *data)
  {
void __iomem *reg = NULL;
@@ -128,6 +162,10 @@ static const struct usbmisc_ops imx25_usbmisc_ops = {
.post = usbmisc_imx25_post,
  };

+static const struct usbmisc_ops imx27_usbmisc_ops = {
+   .init = usbmisc_imx27_init,
+};
+
  static const struct usbmisc_ops imx53_usbmisc_ops = {
.init = usbmisc_imx53_init,
  };
@@ -162,6 +200,10 @@ static const struct of_device_id usbmisc_imx_dt_ids[] = {
.data =imx25_usbmisc_ops,
},
{
+   .compatible = fsl,imx27-usbmisc,
+   .data =imx27_usbmisc_ops,
+   },
+   {
.compatible = fsl,imx53-usbmisc,
.data =imx53_usbmisc_ops,
},


Tested and works fine.

Acked-by: Chris Ruehl chris.ru...@gtsys.com.hk

Regards
Chris
--
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