[PATCH v2 1/5] usb: phy: samsung: Introducing usb phy driver for hsotg

[Praveen Paneri]

This driver uses usb_phy interface to interact with s3c-hsotg. Supports
phy_init and phy_shutdown functions to enable/disable phy. Tested with
smdk6410 and smdkv310. More SoCs can be brought under later.

Signed-off-by: Praveen Paneri 
---
 .../devicetree/bindings/usb/samsung-usbphy.txt |9 +
 drivers/usb/phy/Kconfig|8 +
 drivers/usb/phy/Makefile   |1 +
 drivers/usb/phy/samsung_usbphy.c   |  355 
 drivers/usb/phy/samsung_usbphy.h   |   48 +++
 include/linux/platform_data/s3c-hsotg.h|5 +
 6 files changed, 426 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/samsung-usbphy.txt
 create mode 100644 drivers/usb/phy/samsung_usbphy.c
 create mode 100644 drivers/usb/phy/samsung_usbphy.h

diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt 
b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
new file mode 100644
index 000..fefd9c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
@@ -0,0 +1,9 @@
+* Samsung's usb phy transceiver
+
+The Samsung's phy transceiver is used for controlling usb otg phy for
+s3c-hsotg usb device controller.
+
+Required properties:
+- compatible : should be "samsung,exynos4210-usbphy"
+- reg : base physical address of the phy registers and length of memory mapped
+   region.
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index e7cf84f..d916477 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -15,3 +15,11 @@ config USB_ISP1301
 
  To compile this driver as a module, choose M here: the
  module will be called isp1301.
+
+config SAMSUNG_USBPHY
+   bool "Samsung USB PHY controller Driver"
+   depends on USB_S3C_HSOTG
+   select USB_OTG_UTILS
+   help
+ Enable this to support Samsung USB phy controller for samsung
+ SoCs.
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index eca095b..c5a483d 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -5,3 +5,4 @@
 ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG
 
 obj-$(CONFIG_USB_ISP1301)  += isp1301.o
+obj-$(CONFIG_SAMSUNG_USBPHY)   += samsung_usbphy.o
diff --git a/drivers/usb/phy/samsung_usbphy.c b/drivers/usb/phy/samsung_usbphy.c
new file mode 100644
index 000..8e9e772
--- /dev/null
+++ b/drivers/usb/phy/samsung_usbphy.c
@@ -0,0 +1,355 @@
+/* linux/drivers/usb/phy/samsung_usbphy.c
+ *
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ *  http://www.samsung.com
+ *
+ * Author: Praveen Paneri 
+ *
+ * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG controller
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "samsung_usbphy.h"
+
+enum samsung_cpu_type {
+   TYPE_S3C64XX,
+   TYPE_EXYNOS4210,
+};
+
+/*
+ * struct samsung_usbphy - transceiver driver state
+ * @phy: transceiver structure
+ * @plat: platform data
+ * @dev: The parent device supplied to the probe function
+ * @clk: usb phy clock
+ * @regs: usb phy register memory base
+ * @cpu_type: machine identifier
+ */
+struct samsung_usbphy {
+   struct usb_phy  phy;
+   struct s3c_usbphy_plat *plat;
+   struct device   *dev;
+   struct clk  *clk;
+   void __iomem*regs;
+   int cpu_type;
+};
+
+#define phy_to_sphy(x) container_of((x), struct samsung_usbphy, phy)
+
+/*
+ * Enables or disables the phy clock
+ * returns 0 on success else the error
+ */
+static int samsung_usbphy_clk_control(struct samsung_usbphy *sphy, bool on)
+{
+   if (on) {
+   if (!sphy->clk) {
+   sphy->clk = clk_get(sphy->dev, "otg");
+   if (IS_ERR(sphy->clk)) {
+   dev_err(sphy->dev, "Failed to get otg clock\n");
+   return PTR_ERR(sphy->clk);
+   }
+   }
+   clk_enable(sphy->clk);
+   } else {
+   clk_disable(sphy->clk);
+   clk_put(sphy->clk);
+   }
+
+   return 0;
+}
+
+/*
+ * Returns reference clock frequency
+ */
+static int samsung_usbphy_get_refclk_freq(struct samsung_usbphy *sph

[PATCH v2 2/5] usb: s3c-hsotg: Adding phy driver support

[Praveen Paneri]

Adding the transceiver to hsotg driver. Keeping the platform data
for continuing the smooth operation for boards which still uses it

Signed-off-by: Praveen Paneri 
---
 drivers/usb/gadget/s3c-hsotg.c |   38 --
 1 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index b13e0bb..f4ba9a3 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -32,6 +32,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -133,7 +134,9 @@ struct s3c_hsotg_ep {
  * struct s3c_hsotg - driver state.
  * @dev: The parent device supplied to the probe function
  * @driver: USB gadget driver
- * @plat: The platform specific configuration data.
+ * @phy: The otg phy transeiver structure for phy control.
+ * @plat: The platform specific configuration data. This can be removed once
+ * all SoCs support usb transceiver.
  * @regs: The memory area mapped for accessing registers.
  * @irq: The IRQ number we are using
  * @supplies: Definition of USB power supplies
@@ -153,6 +156,7 @@ struct s3c_hsotg_ep {
 struct s3c_hsotg {
struct device*dev;
struct usb_gadget_driver *driver;
+   struct usb_phy  *phy;
struct s3c_hsotg_plat*plat;
 
spinlock_t  lock;
@@ -2854,7 +2858,10 @@ static void s3c_hsotg_phy_enable(struct s3c_hsotg *hsotg)
struct platform_device *pdev = to_platform_device(hsotg->dev);
 
dev_dbg(hsotg->dev, "pdev 0x%p\n", pdev);
-   if (hsotg->plat->phy_init)
+
+   if (hsotg->phy)
+   usb_phy_init(hsotg->phy);
+   else if (hsotg->plat->phy_init)
hsotg->plat->phy_init(pdev, hsotg->plat->phy_type);
 }
 
@@ -2869,7 +2876,9 @@ static void s3c_hsotg_phy_disable(struct s3c_hsotg *hsotg)
 {
struct platform_device *pdev = to_platform_device(hsotg->dev);
 
-   if (hsotg->plat->phy_exit)
+   if (hsotg->phy)
+   usb_phy_shutdown(hsotg->phy);
+   else if (hsotg->plat->phy_exit)
hsotg->plat->phy_exit(pdev, hsotg->plat->phy_type);
 }
 
@@ -3493,6 +3502,7 @@ static void s3c_hsotg_release(struct device *dev)
 static int __devinit s3c_hsotg_probe(struct platform_device *pdev)
 {
struct s3c_hsotg_plat *plat = pdev->dev.platform_data;
+   struct usb_phy *phy;
struct device *dev = &pdev->dev;
struct s3c_hsotg_ep *eps;
struct s3c_hsotg *hsotg;
@@ -3501,20 +3511,25 @@ static int __devinit s3c_hsotg_probe(struct 
platform_device *pdev)
int ret;
int i;
 
-   plat = pdev->dev.platform_data;
-   if (!plat) {
-   dev_err(&pdev->dev, "no platform data defined\n");
-   return -EINVAL;
-   }
-
hsotg = devm_kzalloc(&pdev->dev, sizeof(struct s3c_hsotg), GFP_KERNEL);
if (!hsotg) {
dev_err(dev, "cannot get memory\n");
return -ENOMEM;
}
 
+   phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
+   if (!phy) {
+   /* Fallback for platform data */
+   plat = pdev->dev.platform_data;
+   if (!plat) {
+   dev_err(&pdev->dev, "no platform data or transceiver 
defined\n");
+   return -ENODEV;
+   } else
+   hsotg->plat = plat;
+   } else
+   hsotg->phy = phy;
+
hsotg->dev = dev;
-   hsotg->plat = plat;
 
hsotg->clk = clk_get(&pdev->dev, "otg");
if (IS_ERR(hsotg->clk)) {
@@ -3689,6 +3704,9 @@ static int __devexit s3c_hsotg_remove(struct 
platform_device *pdev)
s3c_hsotg_phy_disable(hsotg);
regulator_bulk_free(ARRAY_SIZE(hsotg->supplies), hsotg->supplies);
 
+   if (hsotg->phy)
+   devm_usb_put_phy(&pdev->dev, hsotg->phy);
+
clk_disable_unprepare(hsotg->clk);
clk_put(hsotg->clk);
 
-- 
1.7.1

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

[PATCH v2 3/5] ARM: S3C64XX: Removing old phy setup code

[Praveen Paneri]

This patch removes old phy code from platform side. 'setup-usb-phy.c'
will be used for providing transceiver platform data in next
patch. Not all of the platform data code is removed as there are others
making use of platform_data defined for hsotg. That can be removed once
all the SoCs start using the new transceiver for usb phy setup.

Signed-off-by: Praveen Paneri 
---
 arch/arm/mach-s3c64xx/mach-crag6410.c |2 -
 arch/arm/mach-s3c64xx/mach-smartq.c   |2 -
 arch/arm/mach-s3c64xx/mach-smdk6410.c |2 -
 arch/arm/mach-s3c64xx/setup-usb-phy.c |   79 -
 4 files changed, 0 insertions(+), 85 deletions(-)

diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c 
b/arch/arm/mach-s3c64xx/mach-crag6410.c
index 09cd812..3bb0327 100644
--- a/arch/arm/mach-s3c64xx/mach-crag6410.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
@@ -766,7 +766,6 @@ static const struct gpio_led_platform_data gpio_leds_pdata 
= {
.num_leds = ARRAY_SIZE(gpio_leds),
 };
 
-static struct s3c_hsotg_plat crag6410_hsotg_pdata;
 
 static void __init crag6410_machine_init(void)
 {
@@ -792,7 +791,6 @@ static void __init crag6410_machine_init(void)
s3c_i2c0_set_platdata(&i2c0_pdata);
s3c_i2c1_set_platdata(&i2c1_pdata);
s3c_fb_set_platdata(&crag6410_lcd_pdata);
-   s3c_hsotg_set_platdata(&crag6410_hsotg_pdata);
 
i2c_register_board_info(0, i2c_devs0, ARRAY_SIZE(i2c_devs0));
i2c_register_board_info(1, i2c_devs1, ARRAY_SIZE(i2c_devs1));
diff --git a/arch/arm/mach-s3c64xx/mach-smartq.c 
b/arch/arm/mach-s3c64xx/mach-smartq.c
index ceeb1de..3647202 100644
--- a/arch/arm/mach-s3c64xx/mach-smartq.c
+++ b/arch/arm/mach-s3c64xx/mach-smartq.c
@@ -187,7 +187,6 @@ static struct s3c_hwmon_pdata smartq_hwmon_pdata __initdata 
= {
},
 };
 
-static struct s3c_hsotg_plat smartq_hsotg_pdata;
 
 static int __init smartq_lcd_setup_gpio(void)
 {
@@ -385,7 +384,6 @@ void __init smartq_map_io(void)
 void __init smartq_machine_init(void)
 {
s3c_i2c0_set_platdata(NULL);
-   s3c_hsotg_set_platdata(&smartq_hsotg_pdata);
s3c_hwmon_set_platdata(&smartq_hwmon_pdata);
s3c_sdhci1_set_platdata(&smartq_internal_hsmmc_pdata);
s3c_sdhci2_set_platdata(&smartq_internal_hsmmc_pdata);
diff --git a/arch/arm/mach-s3c64xx/mach-smdk6410.c 
b/arch/arm/mach-s3c64xx/mach-smdk6410.c
index 0fe4f15..1a2db14 100644
--- a/arch/arm/mach-s3c64xx/mach-smdk6410.c
+++ b/arch/arm/mach-s3c64xx/mach-smdk6410.c
@@ -627,7 +627,6 @@ static struct platform_pwm_backlight_data smdk6410_bl_data 
= {
.pwm_id = 1,
 };
 
-static struct s3c_hsotg_plat smdk6410_hsotg_pdata;
 
 static void __init smdk6410_map_io(void)
 {
@@ -657,7 +656,6 @@ static void __init smdk6410_machine_init(void)
s3c_i2c0_set_platdata(NULL);
s3c_i2c1_set_platdata(NULL);
s3c_fb_set_platdata(&smdk6410_lcd_pdata);
-   s3c_hsotg_set_platdata(&smdk6410_hsotg_pdata);
 
samsung_keypad_set_platdata(&smdk6410_keypad_data);
 
diff --git a/arch/arm/mach-s3c64xx/setup-usb-phy.c 
b/arch/arm/mach-s3c64xx/setup-usb-phy.c
index f6757e0..7a09553 100644
--- a/arch/arm/mach-s3c64xx/setup-usb-phy.c
+++ b/arch/arm/mach-s3c64xx/setup-usb-phy.c
@@ -9,82 +9,3 @@
  *
  */
 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-static int s3c_usb_otgphy_init(struct platform_device *pdev)
-{
-   struct clk *xusbxti;
-   u32 phyclk;
-
-   writel(readl(S3C64XX_OTHERS) | S3C64XX_OTHERS_USBMASK, S3C64XX_OTHERS);
-
-   /* set clock frequency for PLL */
-   phyclk = readl(S3C_PHYCLK) & ~S3C_PHYCLK_CLKSEL_MASK;
-
-   xusbxti = clk_get(&pdev->dev, "xusbxti");
-   if (xusbxti && !IS_ERR(xusbxti)) {
-   switch (clk_get_rate(xusbxti)) {
-   case 12 * MHZ:
-   phyclk |= S3C_PHYCLK_CLKSEL_12M;
-   break;
-   case 24 * MHZ:
-   phyclk |= S3C_PHYCLK_CLKSEL_24M;
-   break;
-   default:
-   case 48 * MHZ:
-   /* default reference clock */
-   break;
-   }
-   clk_put(xusbxti);
-   }
-
-   /* TODO: select external clock/oscillator */
-   writel(phyclk | S3C_PHYCLK_CLK_FORCE, S3C_PHYCLK);
-
-   /* set to normal OTG PHY */
-   writel((readl(S3C_PHYPWR) & ~S3C_PHYPWR_NORMAL_MASK), S3C_PHYPWR);
-   mdelay(1);
-
-   /* reset OTG PHY and Link */
-   writel(S3C_RSTCON_PHY | S3C_RSTCON_HCLK | S3C_RSTCON_PHYCLK,
-   S3C_RSTCON);
-   udelay(20); /* at-least 10uS */
-   writel(0, S3C_RSTCON);
-
-   return 0;
-}
-
-static int s3c_usb_otgphy_exit(struct platform_device *pdev)
-{
-   writel((readl(S3C_PHYPWR) | S3C_PHYPWR_ANALOG_POWERDOWN |
-   S3C_PHYPWR_OTG_DISABLE), S3C_PHYPWR);
-
-   writel(readl(S3C64XX_OTHERS) & ~S3C64XX_OTHERS_USBMASK, S3C6

[PATCH v2 0/5] usb: phy: samsung: Introducing usb phy driver for samsung SoCs

[Praveen Paneri]

Changes from v1:
Rebased patches to latest usb-next branch
Changed the name 'sec_usbphy' to 'samsung_usbphy'

This patch set introduces a phy driver for samsung SoCs. It uses the existing
transceiver infrastructure to provide phy control functions. Use of this driver
can be extended for usb host phy as well. Over the period of time all the phy
related code for most of the samsung SoCs can be integrated here.
Removing the existing phy code from mach-s3c64xx but not from other machine 
code.This driver is tested with smdk6410 and Exynos4210(with DT).

Praveen Paneri (5):
  usb: phy: samsung: Introducing usb phy driver for hsotg
  usb: s3c-hsotg: Adding phy driver support
  ARM: S3C64XX: Removing old phy setup code
  ARM: S3C64XX: Enabling samsung_usbphy driver
  ARM: Exynos4210: Enabling samsung_usbphy driver

 .../devicetree/bindings/usb/samsung-usbphy.txt |9 +
 arch/arm/boot/dts/exynos4210.dtsi  |5 +
 arch/arm/mach-exynos/include/mach/map.h|1 +
 arch/arm/mach-exynos/mach-exynos4-dt.c |8 +
 arch/arm/mach-exynos/setup-usb-phy.c   |   13 +
 arch/arm/mach-s3c64xx/include/mach/map.h   |2 +
 arch/arm/mach-s3c64xx/mach-crag6410.c  |5 +-
 arch/arm/mach-s3c64xx/mach-smartq.c|6 +-
 arch/arm/mach-s3c64xx/mach-smdk6410.c  |5 +-
 arch/arm/mach-s3c64xx/setup-usb-phy.c  |   79 +
 arch/arm/plat-samsung/devs.c   |   32 ++
 arch/arm/plat-samsung/include/plat/devs.h  |1 +
 arch/arm/plat-samsung/include/plat/usb-phy.h   |1 +
 drivers/usb/gadget/s3c-hsotg.c |   38 ++-
 drivers/usb/phy/Kconfig|8 +
 drivers/usb/phy/Makefile   |1 +
 drivers/usb/phy/samsung_usbphy.c   |  355 
 drivers/usb/phy/samsung_usbphy.h   |   48 +++
 include/linux/platform_data/s3c-hsotg.h|5 +
 19 files changed, 534 insertions(+), 88 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/samsung-usbphy.txt
 create mode 100644 drivers/usb/phy/samsung_usbphy.c
 create mode 100644 drivers/usb/phy/samsung_usbphy.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

[PATCH v2 5/5] ARM: Exynos4210: Enabling samsung_usbphy driver

[Praveen Paneri]

Adding usbphy node for Exynos4210 along with the platform data.

Signed-off-by: Praveen Paneri 
---
 arch/arm/boot/dts/exynos4210.dtsi   |5 +
 arch/arm/mach-exynos/include/mach/map.h |1 +
 arch/arm/mach-exynos/mach-exynos4-dt.c  |8 
 arch/arm/mach-exynos/setup-usb-phy.c|   13 +
 4 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
b/arch/arm/boot/dts/exynos4210.dtsi
index 02891fe..e28cf10 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -62,6 +62,11 @@
interrupts = <0 44 0>, <0 45 0>;
};
 
+   usbphy@125B {
+   compatible = "samsung,exynos4210-usbphy";
+   reg = <0x125B 0x100>;
+   };
+
keypad@100A {
compatible = "samsung,s5pv210-keypad";
reg = <0x100A 0x100>;
diff --git a/arch/arm/mach-exynos/include/mach/map.h 
b/arch/arm/mach-exynos/include/mach/map.h
index c72b675..0625c0a 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -234,6 +234,7 @@
 #define S3C_PA_SPI1EXYNOS4_PA_SPI1
 #define S3C_PA_SPI2EXYNOS4_PA_SPI2
 #define S3C_PA_USB_HSOTG   EXYNOS4_PA_HSOTG
+#define S3C_PA_USB_PHY EXYNOS4_PA_HSPHY
 
 #define S5P_PA_EHCIEXYNOS4_PA_EHCI
 #define S5P_PA_FIMC0   EXYNOS4_PA_FIMC0
diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c 
b/arch/arm/mach-exynos/mach-exynos4-dt.c
index b2b5d5f..0f74438 100644
--- a/arch/arm/mach-exynos/mach-exynos4-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
@@ -13,6 +13,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -20,9 +21,14 @@
 
 #include 
 #include 
+#include 
 
 #include "common.h"
 
+static struct s3c_usbphy_plat exynos4_usbphy_pdata = {
+   .pmu_isolation = s5p_usb_phy_pmu_isolation,
+};
+
 /*
  * The following lookup table is used to override device names when devices
  * are registered from device tree. This is temporarily added to enable
@@ -63,6 +69,8 @@ static const struct of_dev_auxdata 
exynos4210_auxdata_lookup[] __initconst = {
"exynos4210-spi.2", NULL),
OF_DEV_AUXDATA("arm,pl330", EXYNOS4_PA_PDMA0, "dma-pl330.0", NULL),
OF_DEV_AUXDATA("arm,pl330", EXYNOS4_PA_PDMA1, "dma-pl330.1", NULL),
+   OF_DEV_AUXDATA("samsung,exynos4210-usbphy", EXYNOS4_PA_HSPHY,
+   "s3c-usbphy", &exynos4_usbphy_pdata),
{},
 };
 
diff --git a/arch/arm/mach-exynos/setup-usb-phy.c 
b/arch/arm/mach-exynos/setup-usb-phy.c
index b81cc56..1c62d20 100644
--- a/arch/arm/mach-exynos/setup-usb-phy.c
+++ b/arch/arm/mach-exynos/setup-usb-phy.c
@@ -221,3 +221,16 @@ int s5p_usb_phy_exit(struct platform_device *pdev, int 
type)
 
return -EINVAL;
 }
+
+void s5p_usb_phy_pmu_isolation(int on)
+{
+   if (on) {
+   writel(readl(S5P_USBDEVICE_PHY_CONTROL)
+   & ~S5P_USBDEVICE_PHY_ENABLE,
+   S5P_USBDEVICE_PHY_CONTROL);
+   } else {
+   writel(readl(S5P_USBDEVICE_PHY_CONTROL)
+   | S5P_USBDEVICE_PHY_ENABLE,
+   S5P_USBDEVICE_PHY_CONTROL);
+   }
+}
-- 
1.7.1

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

[PATCH v2 4/5] ARM: S3C64XX: Enabling samsung_usbphy driver

[Praveen Paneri]

Adding platform device for samsung_usbphy driver. Enabling it for
s3c64xx based machines using s3c-hsotg.

Signed-off-by: Praveen Paneri 
---
 arch/arm/mach-s3c64xx/include/mach/map.h |2 +
 arch/arm/mach-s3c64xx/mach-crag6410.c|3 ++
 arch/arm/mach-s3c64xx/mach-smartq.c  |4 +++
 arch/arm/mach-s3c64xx/mach-smdk6410.c|3 ++
 arch/arm/mach-s3c64xx/setup-usb-phy.c|   14 +++
 arch/arm/plat-samsung/devs.c |   32 ++
 arch/arm/plat-samsung/include/plat/devs.h|1 +
 arch/arm/plat-samsung/include/plat/usb-phy.h |1 +
 8 files changed, 60 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-s3c64xx/include/mach/map.h 
b/arch/arm/mach-s3c64xx/include/mach/map.h
index 8e2097b..dc482bb 100644
--- a/arch/arm/mach-s3c64xx/include/mach/map.h
+++ b/arch/arm/mach-s3c64xx/include/mach/map.h
@@ -65,6 +65,7 @@
 
 #define S3C64XX_PA_NAND(0x7020)
 #define S3C64XX_PA_FB  (0x7710)
+#define S3C64XX_PA_USB_HSPHY   (0x7C10)
 #define S3C64XX_PA_USB_HSOTG   (0x7C00)
 #define S3C64XX_PA_WATCHDOG(0x7E004000)
 #define S3C64XX_PA_RTC (0x7E005000)
@@ -113,6 +114,7 @@
 #define S3C_PA_FB  S3C64XX_PA_FB
 #define S3C_PA_USBHOST S3C64XX_PA_USBHOST
 #define S3C_PA_USB_HSOTG   S3C64XX_PA_USB_HSOTG
+#define S3C_PA_USB_PHY S3C64XX_PA_USB_HSPHY
 #define S3C_PA_RTC S3C64XX_PA_RTC
 #define S3C_PA_WDT S3C64XX_PA_WATCHDOG
 #define S3C_PA_SPI0S3C64XX_PA_SPI0
diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c 
b/arch/arm/mach-s3c64xx/mach-crag6410.c
index 3bb0327..05e6e14 100644
--- a/arch/arm/mach-s3c64xx/mach-crag6410.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
@@ -337,6 +337,7 @@ static struct platform_device wallvdd_device = {
 };
 
 static struct platform_device *crag6410_devices[] __initdata = {
+   &s3c_device_usbphy,
&s3c_device_hsmmc0,
&s3c_device_hsmmc2,
&s3c_device_i2c0,
@@ -766,6 +767,7 @@ static const struct gpio_led_platform_data gpio_leds_pdata 
= {
.num_leds = ARRAY_SIZE(gpio_leds),
 };
 
+static struct s3c_usbphy_plat crag6410_usbphy_pdata;
 
 static void __init crag6410_machine_init(void)
 {
@@ -791,6 +793,7 @@ static void __init crag6410_machine_init(void)
s3c_i2c0_set_platdata(&i2c0_pdata);
s3c_i2c1_set_platdata(&i2c1_pdata);
s3c_fb_set_platdata(&crag6410_lcd_pdata);
+   s3c_usbphy_set_platdata(&crag6410_usbphy_pdata);
 
i2c_register_board_info(0, i2c_devs0, ARRAY_SIZE(i2c_devs0));
i2c_register_board_info(1, i2c_devs1, ARRAY_SIZE(i2c_devs1));
diff --git a/arch/arm/mach-s3c64xx/mach-smartq.c 
b/arch/arm/mach-s3c64xx/mach-smartq.c
index 3647202..97751d5 100644
--- a/arch/arm/mach-s3c64xx/mach-smartq.c
+++ b/arch/arm/mach-s3c64xx/mach-smartq.c
@@ -235,6 +235,7 @@ static struct i2c_board_info smartq_i2c_devs[] __initdata = 
{
 };
 
 static struct platform_device *smartq_devices[] __initdata = {
+   &s3c_device_usbphy,
&s3c_device_hsmmc1, /* Init iNAND first, ... */
&s3c_device_hsmmc0, /* ... then the external SD card */
&s3c_device_hsmmc2,
@@ -381,9 +382,12 @@ void __init smartq_map_io(void)
smartq_lcd_mode_set();
 }
 
+static struct s3c_usbphy_plat smartq_usbphy_pdata;
+
 void __init smartq_machine_init(void)
 {
s3c_i2c0_set_platdata(NULL);
+   s3c_usbphy_set_platdata(&smartq_usbphy_pdata);
s3c_hwmon_set_platdata(&smartq_hwmon_pdata);
s3c_sdhci1_set_platdata(&smartq_internal_hsmmc_pdata);
s3c_sdhci2_set_platdata(&smartq_internal_hsmmc_pdata);
diff --git a/arch/arm/mach-s3c64xx/mach-smdk6410.c 
b/arch/arm/mach-s3c64xx/mach-smdk6410.c
index 1a2db14..e5c55ba 100644
--- a/arch/arm/mach-s3c64xx/mach-smdk6410.c
+++ b/arch/arm/mach-s3c64xx/mach-smdk6410.c
@@ -264,6 +264,7 @@ static struct samsung_keypad_platdata smdk6410_keypad_data 
__initdata = {
 static struct map_desc smdk6410_iodesc[] = {};
 
 static struct platform_device *smdk6410_devices[] __initdata = {
+   &s3c_device_usbphy,
 #ifdef CONFIG_SMDK6410_SD_CH0
&s3c_device_hsmmc0,
 #endif
@@ -627,6 +628,7 @@ static struct platform_pwm_backlight_data smdk6410_bl_data 
= {
.pwm_id = 1,
 };
 
+static struct s3c_usbphy_plat smdk6410_usbphy_pdata;
 
 static void __init smdk6410_map_io(void)
 {
@@ -656,6 +658,7 @@ static void __init smdk6410_machine_init(void)
s3c_i2c0_set_platdata(NULL);
s3c_i2c1_set_platdata(NULL);
s3c_fb_set_platdata(&smdk6410_lcd_pdata);
+   s3c_usbphy_set_platdata(&smdk6410_usbphy_pdata);
 
samsung_keypad_set_platdata(&smdk6410_keypad_data);
 
diff --git a/arch/arm/mach-s3c64xx/setup-usb-phy.c 
b/arch/arm/mach-s3c64xx/setup-usb-phy.c
index 7a09553..3aee778 100644
--- a/arch/arm/mach-s3c64xx/setup-usb-phy.c
+++ b/arch/arm/mach-s3c64xx/setup-usb-phy.c
@@ -9,3 +9,17 @@
  *
  */
 
+#include 
+#include 
+#include 
+
+void s5p_usb_phy_pmu_i

Re: [RFC ebeam PATCH v3 2/2] input: misc: New USB eBeam input driver.

[Yann Cantin]

Le 07/08/2012 03:43, Dmitry Torokhov a écrit :
> On Tue, Aug 07, 2012 at 02:56:40AM +0200, Yann Cantin wrote:
>> Hi,
>>
>> Le 06/08/2012 23:43, Greg KH a écrit :
>>> On Mon, Aug 06, 2012 at 11:21:44PM +0200, Yann Cantin wrote:

 Signed-off-by: Yann Cantin 
 ---
  drivers/input/misc/ebeam.c |  764 
 
  1 file changed, 764 insertions(+)
  create mode 100644 drivers/input/misc/ebeam.c
>>>
>>> What adds this file to the build?
>>  
>> Sorry, i don't get it : what do you mean ?
> 
> Greg meant that you forgot to include Makefile and Kconfig changes with
> this patch.
 
My bad. Looked twice and yet miss that...
Will be in v4. For info :

---
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 7c0f1ec..1e575e4 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -83,6 +83,22 @@ config INPUT_BMA150
  To compile this driver as a module, choose M here: the
  module will be called bma150.
 
+config INPUT_EBEAM_USB
+   tristate "USB eBeam driver"
+   depends on USB_ARCH_HAS_HCD
+   select USB
+   help
+ Say Y here if you have a USB eBeam pointing device and want to
+ use it without any proprietary user space tools.
+
+ Have a look at  for
+ a usage description and the required user-space tools.
+
+ Currently, only the Classic Projection model is supported.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ebeam.
+
 config INPUT_PCSPKR
tristate "PC Speaker support"
depends on PCSPKR_PLATFORM
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 83fe6f5..2aa9813 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_INPUT_CMA3000_I2C)   += 
cma3000_d0x_i2c.o
 obj-$(CONFIG_INPUT_COBALT_BTNS)+= cobalt_btns.o
 obj-$(CONFIG_INPUT_DA9052_ONKEY)   += da9052_onkey.o
 obj-$(CONFIG_INPUT_DM355EVM)   += dm355evm_keys.o
+obj-$(CONFIG_INPUT_EBEAM_USB)  += ebeam.o
 obj-$(CONFIG_INPUT_GP2A)   += gp2ap002a00f.o
 obj-$(CONFIG_INPUT_GPIO_TILT_POLLED)   += gpio_tilt_polled.o
 obj-$(CONFIG_HP_SDC_RTC)   += hp_sdc_rtc.o

-- 
Yann Cantin
A4FEB47F
--
--
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/5] usb: s3c-hsotg: Adding phy driver support

[Sachin Kamat]

Hi Praveen,

Some minor comments:

On 7 August 2012 12:58, Praveen Paneri  wrote:
> Adding the transceiver to hsotg driver. Keeping the platform data
> for continuing the smooth operation for boards which still uses it
>
> Signed-off-by: Praveen Paneri 
> ---
>  drivers/usb/gadget/s3c-hsotg.c |   38 --
>  1 files changed, 28 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
> index b13e0bb..f4ba9a3 100644
> --- a/drivers/usb/gadget/s3c-hsotg.c
> +++ b/drivers/usb/gadget/s3c-hsotg.c
> @@ -32,6 +32,7 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
>
>  #include 
> @@ -133,7 +134,9 @@ struct s3c_hsotg_ep {
>   * struct s3c_hsotg - driver state.
>   * @dev: The parent device supplied to the probe function
>   * @driver: USB gadget driver
> - * @plat: The platform specific configuration data.
> + * @phy: The otg phy transeiver structure for phy control.

s/transeiver/transceiver

> + * @plat: The platform specific configuration data. This can be removed once
> + * all SoCs support usb transceiver.
>   * @regs: The memory area mapped for accessing registers.
>   * @irq: The IRQ number we are using
>   * @supplies: Definition of USB power supplies
> @@ -153,6 +156,7 @@ struct s3c_hsotg_ep {
>  struct s3c_hsotg {
> struct device*dev;
> struct usb_gadget_driver *driver;
> +   struct usb_phy  *phy;
> struct s3c_hsotg_plat*plat;
>
> spinlock_t  lock;
> @@ -2854,7 +2858,10 @@ static void s3c_hsotg_phy_enable(struct s3c_hsotg 
> *hsotg)
> struct platform_device *pdev = to_platform_device(hsotg->dev);
>
> dev_dbg(hsotg->dev, "pdev 0x%p\n", pdev);
> -   if (hsotg->plat->phy_init)
> +
> +   if (hsotg->phy)
> +   usb_phy_init(hsotg->phy);
> +   else if (hsotg->plat->phy_init)
> hsotg->plat->phy_init(pdev, hsotg->plat->phy_type);
>  }
>
> @@ -2869,7 +2876,9 @@ static void s3c_hsotg_phy_disable(struct s3c_hsotg 
> *hsotg)
>  {
> struct platform_device *pdev = to_platform_device(hsotg->dev);
>
> -   if (hsotg->plat->phy_exit)
> +   if (hsotg->phy)
> +   usb_phy_shutdown(hsotg->phy);
> +   else if (hsotg->plat->phy_exit)
> hsotg->plat->phy_exit(pdev, hsotg->plat->phy_type);
>  }
>
> @@ -3493,6 +3502,7 @@ static void s3c_hsotg_release(struct device *dev)
>  static int __devinit s3c_hsotg_probe(struct platform_device *pdev)
>  {
> struct s3c_hsotg_plat *plat = pdev->dev.platform_data;
> +   struct usb_phy *phy;
> struct device *dev = &pdev->dev;
> struct s3c_hsotg_ep *eps;
> struct s3c_hsotg *hsotg;
> @@ -3501,20 +3511,25 @@ static int __devinit s3c_hsotg_probe(struct 
> platform_device *pdev)
> int ret;
> int i;
>
> -   plat = pdev->dev.platform_data;
> -   if (!plat) {
> -   dev_err(&pdev->dev, "no platform data defined\n");
> -   return -EINVAL;
> -   }
> -
> hsotg = devm_kzalloc(&pdev->dev, sizeof(struct s3c_hsotg), 
> GFP_KERNEL);
> if (!hsotg) {
> dev_err(dev, "cannot get memory\n");
> return -ENOMEM;
> }
>
> +   phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
> +   if (!phy) {
> +   /* Fallback for platform data */
> +   plat = pdev->dev.platform_data;
> +   if (!plat) {
> +   dev_err(&pdev->dev, "no platform data or transceiver 
> defined\n");
> +   return -ENODEV;
> +   } else
> +   hsotg->plat = plat;
> +   } else
> +   hsotg->phy = phy;

Braces needed around the above 2 else statements.
Please refer to: Documentation/CodingStyle


> +
> hsotg->dev = dev;
> -   hsotg->plat = plat;
>
> hsotg->clk = clk_get(&pdev->dev, "otg");
> if (IS_ERR(hsotg->clk)) {
> @@ -3689,6 +3704,9 @@ static int __devexit s3c_hsotg_remove(struct 
> platform_device *pdev)
> s3c_hsotg_phy_disable(hsotg);
> regulator_bulk_free(ARRAY_SIZE(hsotg->supplies), hsotg->supplies);
>
> +   if (hsotg->phy)
> +   devm_usb_put_phy(&pdev->dev, hsotg->phy);
> +
> clk_disable_unprepare(hsotg->clk);
> clk_put(hsotg->clk);
>
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
With best regards,
Sachin
--
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 ebeam PATCH v3 1/2] hid: Blacklist new eBeam classic device

[Yann Cantin]

Le 07/08/2012 03:45, Dmitry Torokhov a écrit :
> On Tue, Aug 07, 2012 at 03:21:45AM +0200, Yann Cantin wrote:
>> Le 07/08/2012 00:07, Dmitry Torokhov a écrit :
>>> On Monday, August 06, 2012 02:43:40 PM Greg KH wrote:
 On Mon, Aug 06, 2012 at 11:21:43PM +0200, Yann Cantin wrote:
> Signed-off-by: Yann Cantin 
> ---
>
>  drivers/hid/hid-core.c |3 +++
>  drivers/hid/hid-ids.h  |3 +++
>  2 files changed, 6 insertions(+)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 60ea284..b1ed8ee 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -1908,6 +1908,9 @@ static const struct hid_device_id hid_ignore_list[]
> = {> 
>   { HID_USB_DEVICE(USB_VENDOR_ID_DELORME, USB_DEVICE_ID_DELORME_EM_LT20)
>   },
>   { HID_USB_DEVICE(USB_VENDOR_ID_DREAM_CHEEKY, 0x0004) },
>   { HID_USB_DEVICE(USB_VENDOR_ID_DREAM_CHEEKY, 0x000a) },
>
> +#if defined(CONFIG_INPUT_EBEAM_USB)
> + { HID_USB_DEVICE(USB_VENDOR_ID_EFI, USB_DEVICE_ID_EFI_CLASSIC) },
> +#endif

 Why is this #if in here?  Just always do it, how could it not be
 defined?
>>>
>>> User might disable the driver and CONFIG_INPUT_EBEAM_USB will not be
>>> set. But I agree, since the device is unusable with generic HID driver
>>> there is no point in doing this conditionally.
>>
>> There's a closed-source user-space stack (libusb based daemon + xorg driver
>> + wine apps) provided for some distro (Ubuntu 10.04, works on mandriva 2010,
>> maybe others but break on recent xorg).
>>
>> I don't know exactly what to do : i don't want to break hypothetical support,
>> even proprietary.
>> Leaving the choice at kernel compile time seems to be safer, no ?
> 
> If they are using libusb that means that they use userspace solution and
> do not require HID or any other in-kernel driver. They should still be
> able to claim the port even if your driver is in use.

Ok, that solve one of my issue.
But if the driver isn't built, there will be absolutely no kernel support,
even basic hiddev/hidraw. Is there a kernel policy for that situation ?

-- 
Yann Cantin
A4FEB47F
--
--
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/5] usb: phy: samsung: Introducing usb phy driver for hsotg

[Heiko Stübner]

Am Dienstag, 7. August 2012, 09:28:40 schrieb Praveen Paneri:
> This driver uses usb_phy interface to interact with s3c-hsotg. Supports
> phy_init and phy_shutdown functions to enable/disable phy. Tested with
> smdk6410 and smdkv310. More SoCs can be brought under later.
>
> Signed-off-by: Praveen Paneri 
> ---
>  .../devicetree/bindings/usb/samsung-usbphy.txt |9 +
>  drivers/usb/phy/Kconfig|8 +
>  drivers/usb/phy/Makefile   |1 +
>  drivers/usb/phy/samsung_usbphy.c   |  355
>  drivers/usb/phy/samsung_usbphy.h   | 
>  48 +++
>  include/linux/platform_data/s3c-hsotg.h|5 +
>  6 files changed, 426 insertions(+), 0 deletions(-)
>  create mode 100644
> Documentation/devicetree/bindings/usb/samsung-usbphy.txt create mode
> 100644 drivers/usb/phy/samsung_usbphy.c
>  create mode 100644 drivers/usb/phy/samsung_usbphy.h
> 

[...]

> diff --git a/include/linux/platform_data/s3c-hsotg.h
> b/include/linux/platform_data/s3c-hsotg.h index 8b79e09..25ed31e 100644
> --- a/include/linux/platform_data/s3c-hsotg.h
> +++ b/include/linux/platform_data/s3c-hsotg.h
> @@ -35,6 +35,11 @@ struct s3c_hsotg_plat {
>   int (*phy_exit)(struct platform_device *pdev, int type);
>  };
> 
> +struct s3c_usbphy_plat {
> + void (*pmu_isolation)(int on);
> +};
> +
>  extern void s3c_hsotg_set_platdata(struct s3c_hsotg_plat *pd);
> +extern void s3c_usbphy_set_platdata(struct s3c_usbphy_plat *pd);
> 
>  #endif /* __LINUX_USB_S3C_HSOTG_H */

hmm, I'm not completely sure about this being in the s3c-hsotg header, as on 
s3c2443/2416/2450 it's the s3c-hsudc that will be (hopefully) using the phy in 
the future.


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

[PATCH v2] usb:musb:musb_host: Handle highmem in PIO mode

[Virupax Sadashivpetimath]

In case of USB bulk transfer, when himem page
is received, the usb_sg_init function sets the
urb transfer buffer to NULL. When such URB
transfer is handled, kernel crashes in PIO mode.
Handle this by mapping the highmem buffer in PIO mode.

Signed-off-by: Virupax Sadashivpetimath 

Signed-off-by: Praveena NADAHALLY 
Acked-by: Linus Walleij 
---
 drivers/usb/musb/musb_host.c |   98 +++--
 drivers/usb/musb/musb_host.h |3 +
 2 files changed, 96 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 4bb717d..199bf1a 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -813,9 +813,28 @@ static void musb_ep_program(struct musb *musb, u8 epnum,
if (load_count) {
/* PIO to load FIFO */
qh->segsize = load_count;
-   musb_write_fifo(hw_ep, load_count, buf);
+   if (!buf) {
+   sg_miter_start(&qh->sg_miter, urb->sg, 1,
+   SG_MITER_ATOMIC
+   | SG_MITER_FROM_SG);
+   if (!sg_miter_next(&qh->sg_miter)) {
+   dev_err(musb->controller,
+   "error: sg"
+   "list empty\n");
+   sg_miter_stop(&qh->sg_miter);
+   goto finish;
+   }
+   buf = qh->sg_miter.addr + urb->sg->offset +
+   urb->actual_length;
+   load_count = min_t(u32, load_count,
+   qh->sg_miter.length);
+   musb_write_fifo(hw_ep, load_count, buf);
+   qh->sg_miter.consumed = load_count;
+   sg_miter_stop(&qh->sg_miter);
+   } else
+   musb_write_fifo(hw_ep, load_count, buf);
}
-
+finish:
/* re-enable interrupt */
musb_writew(mbase, MUSB_INTRTXE, int_txe);
 
@@ -1116,6 +1135,7 @@ void musb_host_tx(struct musb *musb, u8 epnum)
void __iomem*mbase = musb->mregs;
struct dma_channel  *dma;
booltransfer_pending = false;
+   static bool use_sg;
 
musb_ep_select(mbase, epnum);
tx_csr = musb_readw(epio, MUSB_TXCSR);
@@ -1163,6 +1183,7 @@ void musb_host_tx(struct musb *musb, u8 epnum)
return;
}
 
+done:
if (status) {
if (dma_channel_status(dma) == MUSB_DMA_STATUS_BUSY) {
dma->status = MUSB_DMA_STATUS_CORE_ABORT;
@@ -1332,9 +1353,38 @@ void musb_host_tx(struct musb *musb, u8 epnum)
length = qh->maxpacket;
/* Unmap the buffer so that CPU can use it */
usb_hcd_unmap_urb_for_dma(musb_to_hcd(musb), urb);
-   musb_write_fifo(hw_ep, length, urb->transfer_buffer + offset);
+
+   /*
+* We need to map sg if the transfer_buffer is
+* NULL.
+*/
+   if (!urb->transfer_buffer)
+   use_sg = true;
+
+   if (use_sg) {
+   /* sg_miter_start is already done in musb_ep_program */
+   if (!sg_miter_next(&qh->sg_miter)) {
+   dev_err(musb->controller, "error: sg list empty\n");
+   sg_miter_stop(&qh->sg_miter);
+   status = -EINVAL;
+   goto done;
+   }
+   urb->transfer_buffer = qh->sg_miter.addr;
+   length = min_t(u32, length, qh->sg_miter.length);
+   musb_write_fifo(hw_ep, length, urb->transfer_buffer);
+   qh->sg_miter.consumed = length;
+   sg_miter_stop(&qh->sg_miter);
+   } else {
+   musb_write_fifo(hw_ep, length, urb->transfer_buffer + offset);
+   }
+
qh->segsize = length;
 
+   if (use_sg) {
+   if (offset + length >= urb->transfer_buffer_length)
+   use_sg = false;
+   }
+
musb_ep_select(mbase, epnum);
musb_writew(epio, MUSB_TXCSR,
MUSB_TXCSR_H_WZC_BITS | MUSB_TXCSR_TXPKTRDY);
@@ -1442,6 +1492,8 @@ void musb_host_rx(struct musb *musb, u8 epnum)
booldone = false;
u32 status;
struct dma_channel  *dma;
+   static bool use_sg;
+   unsigned int sg_flags = SG_MITER_ATOMIC | SG_MITER_TO_SG;
 
musb_ep_select(mbase, epnum);
 
@@ -1756,10 +1808,43 @@ void musb_host_rx(struct musb *musb, u8 epnum)
 #endif /* Mentor DMA */
 
if (!dma) {
+   unsigned int r

Re: [BUG] Kernel panic when try s3c-hsotg.c with kernel 3.5

[Lukasz Majewski]

On Tue, 07 Aug 2012 11:04:10 +0800
Peiyong Feng  wrote:

> 2012/8/6 Lukasz Majewski :
> > Hi,
> >
> >> Hi,
> >>
> >> On Mon, Aug 06, 2012 at 06:12:05PM +0800, Peiyong Feng wrote:
> >> > I got a kernel panic when try hsotg of ok6410 which is based on
> >> > s3c6410:
> > As you said, you are using the ok6410. And it is "based" on the
> > s3c6410 CPU. S3C6410 is a single core CPU. I assume that ok6410 is
> > also single core?
> yes
> >
> >> >
> >> >
> >> > cdc_acm: USB Abstract Control Model driver for USB modems and
> >> > ISDN adapters Unable to handle kernel NULL pointer dereference at
> >> > virtual address 0100
> >
> >> > pgd = c0004000
> >> > [0100] *pgd=
> >> > Internal error: Oops: 5 [#1] ARM
> >> > Modules linked in:
> >> > CPU: 0Not tainted  (3.5.0 #9)
> >> > PC is at s3c_hsotg_handle_outdone+0x44/0x158
> >> > LR is at s3c_hsotg_irq+0x75c/0x804
> >> > pc : []lr : []psr: 6193
> >> > sp : c782fd20  ip : 0029  fp : c13a1460
> >> > r10:   r9 : 0008  r8 : 00d0
> >> > r7 : c13a1400  r6 : 0002  r5 :   r4 : 00060002
> >> > r3 : 00d0  r2 :   r1 : 00080200  r0 : c13a1400
> >> > Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment
> >> > kernel Control: 00c5387d  Table: 50004008  DAC: 0017
> >> > Process swapper (pid: 1, stack limit = 0xc782e268)
> >> > Stack: (0xc782fd20 to 0xc783)
> >> > fd20: c13a1460 c0200f64  00060002  0002
> >> > c13a1400 0010 fd40:  c024061c 00060002 
> >> > 0002 0008 c782fda0 c139a5c0 fd60: c139a5c0 
> >> >  005a c04cc52c c04cc594 c04ea5fe c00565c0 fd80:
> >> >    c04cc52c c139a5c0 c04cc57c 
> >> > c04eb328 fda0: c04cc55c c04eb324 c04c44c0 c0056768 c04cc52c
> >> > c04cc57c  c0058d64 fdc0: 005a c04d7dd8 
> >> > c005617c 005a c000efbc c04eb350 0001 fde0: c782fe08
> >> > c000853c c036c540 6013  c782fe3c c04cc57c c04cc55c
> >> > fe00: 6013 c000dd80 c04cc57c c782c000  0001
> >> > 6013 c04cc52c fe20: c139a5c0 005a c04cc57c c04cc55c
> >> > 6013 c04c44c0 f601 c782fe50 fe40: c036c53c c036c540
> >> > 6013  c023fec0 c00574c8  c008b2dc fe60:
> >> > c023fec0   c13a1400 005a c139a5c0 c04cc52c
> >> > c0057960 fe80: 005a c13a1400 c04c44b8  c051d238
> >> > c049b0ec  c03688fc fea0: c7853e60 c13a1400 c7804f80
> >> >  c04c44f4 6013 c7855a80  fec0: c04e1bb4
> >> > c04c44c0 c04c44c0 c04e1bb4 c04e1bb4 c051d238 c049b0ec 
> >> > fee0: c04eb040 c020588c c04c44c0 c0204524 c04c44c0 c04c44f4
> >> > c04e1bb4 c02046ac ff00: c13a01e0 c0204738  c782ff18
> >> > c04e1bb4 c0202e30 c7803878 c7823700 ff20: c04dd1d0 c040b8d4
> >> > c04e1bb4 c04e1bb4 c04dd1d0 c0203600 c040b8d4 c01b8568 ff40:
> >> >   c04e1bb4 0007 c04eb040 c782e000 c04a65e0
> >> > c0204ce8 ff60:  c04a65d4 0007 c04eb040 c782e000
> >> > c0008628 c04c7ea0  ff80: 009c  c0625cf9
> >> > c0037178 0006 0006 c0461b84 c042cee8 ffa0: c04c7ea0
> >> > c04abdd4 c04a65d4 0007 c04eb040 009c c04841b0 c04a65e0
> >> > ffc0:  c048430c 0006 0006 c04841b0 
> >> >  c048421c ffe0: c000f08c 0013  
> >> >  c000f08c   []
> >> > (s3c_hsotg_handle_outdone+0x44/0x158) from []
> >> > (s3c_hsotg_irq+0x75c/0x804) []
> >> > (s3c_hsotg_irq+0x75c/0x804) from []
> >> > (handle_irq_event_percpu+0x50/0x1bc) []
> >> > (handle_irq_event_percpu+0x50/0x1bc) from []
> >> > (handle_irq_event+0x3c/0x5c) []
> >> > (handle_irq_event+0x3c/0x5c) from []
> >> > (handle_level_irq+0x8c/0x118) []
> >> > (handle_level_irq+0x8c/0x118) from []
> >> > (generic_handle_irq+0x38/0x44) []
> >> > (generic_handle_irq+0x38/0x44) from []
> >> > (handle_IRQ+0x30/0x84) [] (handle_IRQ+0x30/0x84) from
> >> > [] (vic_handle_irq+0x68/0xa8) []
> >> > (vic_handle_irq+0x68/0xa8) from []
> >> > (__irq_svc+0x40/0x60) Exception stack(0xc782fe08 to 0xc782fe50)
> >> > fe00: c04cc57c c782c000  0001 6013 c04cc52c fe20:
> >> > c139a5c0 005a c04cc57c c04cc55c 6013 c04c44c0 f601
> >> > c782fe50 fe40: c036c53c c036c540 6013  []
> >> > (__irq_svc+0x40/0x60) from []
> >> > (_raw_spin_unlock_irqrestore+0x10/0x14) []
> >> > (_raw_spin_unlock_irqrestore+0x10/0x14) from []
> >> > (__setup_irq+0x178/0x3f8) [] (__setup_irq+0x178/0x3f8)
> >> > from [] (request_threaded_irq+0xc4/0x12c) []
> >> > (request_threaded_irq+0xc4/0x12c) from []
> >> > (s3c_hsotg_probe+0x14c/0x700) []
> >> > (s3c_hsotg_probe+0x14c/0x700) from []
> >> > (platform_drv_probe+0x18/0x1c) []
> >> > (platform_drv_probe+0x18/0x1c) from []
> >> > (driver_probe_device+0x78/0x200) []
> >> > (driver_probe_device+0x78/0x200) from []
> >> > (__driver_attach+0x8c/0x90) []
> >> > (__driver_attach+0x8c/0x90) from []
> >> > (bus_for_each_dev+0x60/0x8c) []
> >> 

RE: [PATCH v2 0/5] usb: phy: samsung: Introducing usb phy driver for samsung SoCs

[Kukjin Kim]

Praveen Paneri wrote:
> 
> Changes from v1:
> Rebased patches to latest usb-next branch
> Changed the name 'sec_usbphy' to 'samsung_usbphy'
> 
Yes, looks better. But I'm not sure Felipe or Greg would prefer to use '_'
not '-'...you used samsung-usbphy as a name in your patch.

> This patch set introduces a phy driver for samsung SoCs. It uses the
> existing
> transceiver infrastructure to provide phy control functions. Use of this
> driver
> can be extended for usb host phy as well. Over the period of time all the
> phy
> related code for most of the samsung SoCs can be integrated here.
> Removing the existing phy code from mach-s3c64xx but not from other
> machine

Why? Is there any reason? After quick looking at your patches, seems this
can remove all of setup-usb-phy in arch/arm/ for Samsung stuff. In addition,
the isolation hook function also can be put in this by using platform_data
or dt parsing.

> code.This driver is tested with smdk6410 and Exynos4210(with DT).
> 
I and my colleague, Yulgon will comment on this series soon.

Thanks.

Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.


> Praveen Paneri (5):
>   usb: phy: samsung: Introducing usb phy driver for hsotg
>   usb: s3c-hsotg: Adding phy driver support
>   ARM: S3C64XX: Removing old phy setup code
>   ARM: S3C64XX: Enabling samsung_usbphy driver
>   ARM: Exynos4210: Enabling samsung_usbphy driver
> 
>  .../devicetree/bindings/usb/samsung-usbphy.txt |9 +
>  arch/arm/boot/dts/exynos4210.dtsi  |5 +
>  arch/arm/mach-exynos/include/mach/map.h|1 +
>  arch/arm/mach-exynos/mach-exynos4-dt.c |8 +
>  arch/arm/mach-exynos/setup-usb-phy.c   |   13 +
>  arch/arm/mach-s3c64xx/include/mach/map.h   |2 +
>  arch/arm/mach-s3c64xx/mach-crag6410.c  |5 +-
>  arch/arm/mach-s3c64xx/mach-smartq.c|6 +-
>  arch/arm/mach-s3c64xx/mach-smdk6410.c  |5 +-
>  arch/arm/mach-s3c64xx/setup-usb-phy.c  |   79 +
>  arch/arm/plat-samsung/devs.c   |   32 ++
>  arch/arm/plat-samsung/include/plat/devs.h  |1 +
>  arch/arm/plat-samsung/include/plat/usb-phy.h   |1 +
>  drivers/usb/gadget/s3c-hsotg.c |   38 ++-
>  drivers/usb/phy/Kconfig|8 +
>  drivers/usb/phy/Makefile   |1 +
>  drivers/usb/phy/samsung_usbphy.c   |  355

>  drivers/usb/phy/samsung_usbphy.h   |   48 +++
>  include/linux/platform_data/s3c-hsotg.h|5 +
>  19 files changed, 534 insertions(+), 88 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/usb/samsung-
> usbphy.txt
>  create mode 100644 drivers/usb/phy/samsung_usbphy.c
>  create mode 100644 drivers/usb/phy/samsung_usbphy.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: [PATCH] usb: host: mips: sead3: Update for EHCI register structure.

[Sergei Shtylyov]

Hello.

On 07.08.2012 2:29, Steven J. Hill wrote:


From: "Steven J. Hill" 



One line fix after 'struct ehci_regs' definition was changed
in commit a46af4ebf9ffec35eea0390e89935197b833dc61.


   Please also specify that commit's summary in parens.


Signed-off-by: Steven J. Hill 


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 v2 1/5] usb: phy: samsung: Introducing usb phy driver for hsotg

[Praveen Paneri]

On Tue, Aug 7, 2012 at 1:41 PM, Heiko Stübner  wrote:
> Am Dienstag, 7. August 2012, 09:28:40 schrieb Praveen Paneri:
>> This driver uses usb_phy interface to interact with s3c-hsotg. Supports
>> phy_init and phy_shutdown functions to enable/disable phy. Tested with
>> smdk6410 and smdkv310. More SoCs can be brought under later.
>>
>> Signed-off-by: Praveen Paneri 
>> ---
>>  .../devicetree/bindings/usb/samsung-usbphy.txt |9 +
>>  drivers/usb/phy/Kconfig|8 +
>>  drivers/usb/phy/Makefile   |1 +
>>  drivers/usb/phy/samsung_usbphy.c   |  355
>>  drivers/usb/phy/samsung_usbphy.h   |
>>  48 +++
>>  include/linux/platform_data/s3c-hsotg.h|5 +
>>  6 files changed, 426 insertions(+), 0 deletions(-)
>>  create mode 100644
>> Documentation/devicetree/bindings/usb/samsung-usbphy.txt create mode
>> 100644 drivers/usb/phy/samsung_usbphy.c
>>  create mode 100644 drivers/usb/phy/samsung_usbphy.h
>>
>
> [...]
>
>> diff --git a/include/linux/platform_data/s3c-hsotg.h
>> b/include/linux/platform_data/s3c-hsotg.h index 8b79e09..25ed31e 100644
>> --- a/include/linux/platform_data/s3c-hsotg.h
>> +++ b/include/linux/platform_data/s3c-hsotg.h
>> @@ -35,6 +35,11 @@ struct s3c_hsotg_plat {
>>   int (*phy_exit)(struct platform_device *pdev, int type);
>>  };
>>
>> +struct s3c_usbphy_plat {
>> + void (*pmu_isolation)(int on);
>> +};
>> +
>>  extern void s3c_hsotg_set_platdata(struct s3c_hsotg_plat *pd);
>> +extern void s3c_usbphy_set_platdata(struct s3c_usbphy_plat *pd);
>>
>>  #endif /* __LINUX_USB_S3C_HSOTG_H */
>
> hmm, I'm not completely sure about this being in the s3c-hsotg header, as on
> s3c2443/2416/2450 it's the s3c-hsudc that will be (hopefully) using the phy in
> the future.
Okay then I will make a new header file for this. Not only hsudc, we
intent to use it for usb host phy as well so it's a valid point.

Praveen
>
>
> Heiko
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> 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 v2 2/5] usb: s3c-hsotg: Adding phy driver support

[Praveen Paneri]

Thanks Sachin! Will incorporate.

On Tue, Aug 7, 2012 at 1:33 PM, Sachin Kamat  wrote:
> Hi Praveen,
>
> Some minor comments:
>
> On 7 August 2012 12:58, Praveen Paneri  wrote:
>> Adding the transceiver to hsotg driver. Keeping the platform data
>> for continuing the smooth operation for boards which still uses it
>>
>> Signed-off-by: Praveen Paneri 
>> ---
>>  drivers/usb/gadget/s3c-hsotg.c |   38 --
>>  1 files changed, 28 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
>> index b13e0bb..f4ba9a3 100644
>> --- a/drivers/usb/gadget/s3c-hsotg.c
>> +++ b/drivers/usb/gadget/s3c-hsotg.c
>> @@ -32,6 +32,7 @@
>>
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>
>>  #include 
>> @@ -133,7 +134,9 @@ struct s3c_hsotg_ep {
>>   * struct s3c_hsotg - driver state.
>>   * @dev: The parent device supplied to the probe function
>>   * @driver: USB gadget driver
>> - * @plat: The platform specific configuration data.
>> + * @phy: The otg phy transeiver structure for phy control.
>
> s/transeiver/transceiver
>
>> + * @plat: The platform specific configuration data. This can be removed once
>> + * all SoCs support usb transceiver.
>>   * @regs: The memory area mapped for accessing registers.
>>   * @irq: The IRQ number we are using
>>   * @supplies: Definition of USB power supplies
>> @@ -153,6 +156,7 @@ struct s3c_hsotg_ep {
>>  struct s3c_hsotg {
>> struct device*dev;
>> struct usb_gadget_driver *driver;
>> +   struct usb_phy  *phy;
>> struct s3c_hsotg_plat*plat;
>>
>> spinlock_t  lock;
>> @@ -2854,7 +2858,10 @@ static void s3c_hsotg_phy_enable(struct s3c_hsotg 
>> *hsotg)
>> struct platform_device *pdev = to_platform_device(hsotg->dev);
>>
>> dev_dbg(hsotg->dev, "pdev 0x%p\n", pdev);
>> -   if (hsotg->plat->phy_init)
>> +
>> +   if (hsotg->phy)
>> +   usb_phy_init(hsotg->phy);
>> +   else if (hsotg->plat->phy_init)
>> hsotg->plat->phy_init(pdev, hsotg->plat->phy_type);
>>  }
>>
>> @@ -2869,7 +2876,9 @@ static void s3c_hsotg_phy_disable(struct s3c_hsotg 
>> *hsotg)
>>  {
>> struct platform_device *pdev = to_platform_device(hsotg->dev);
>>
>> -   if (hsotg->plat->phy_exit)
>> +   if (hsotg->phy)
>> +   usb_phy_shutdown(hsotg->phy);
>> +   else if (hsotg->plat->phy_exit)
>> hsotg->plat->phy_exit(pdev, hsotg->plat->phy_type);
>>  }
>>
>> @@ -3493,6 +3502,7 @@ static void s3c_hsotg_release(struct device *dev)
>>  static int __devinit s3c_hsotg_probe(struct platform_device *pdev)
>>  {
>> struct s3c_hsotg_plat *plat = pdev->dev.platform_data;
>> +   struct usb_phy *phy;
>> struct device *dev = &pdev->dev;
>> struct s3c_hsotg_ep *eps;
>> struct s3c_hsotg *hsotg;
>> @@ -3501,20 +3511,25 @@ static int __devinit s3c_hsotg_probe(struct 
>> platform_device *pdev)
>> int ret;
>> int i;
>>
>> -   plat = pdev->dev.platform_data;
>> -   if (!plat) {
>> -   dev_err(&pdev->dev, "no platform data defined\n");
>> -   return -EINVAL;
>> -   }
>> -
>> hsotg = devm_kzalloc(&pdev->dev, sizeof(struct s3c_hsotg), 
>> GFP_KERNEL);
>> if (!hsotg) {
>> dev_err(dev, "cannot get memory\n");
>> return -ENOMEM;
>> }
>>
>> +   phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
>> +   if (!phy) {
>> +   /* Fallback for platform data */
>> +   plat = pdev->dev.platform_data;
>> +   if (!plat) {
>> +   dev_err(&pdev->dev, "no platform data or transceiver 
>> defined\n");
>> +   return -ENODEV;
>> +   } else
>> +   hsotg->plat = plat;
>> +   } else
>> +   hsotg->phy = phy;
>
> Braces needed around the above 2 else statements.
> Please refer to: Documentation/CodingStyle
>
>
>> +
>> hsotg->dev = dev;
>> -   hsotg->plat = plat;
>>
>> hsotg->clk = clk_get(&pdev->dev, "otg");
>> if (IS_ERR(hsotg->clk)) {
>> @@ -3689,6 +3704,9 @@ static int __devexit s3c_hsotg_remove(struct 
>> platform_device *pdev)
>> s3c_hsotg_phy_disable(hsotg);
>> regulator_bulk_free(ARRAY_SIZE(hsotg->supplies), hsotg->supplies);
>>
>> +   if (hsotg->phy)
>> +   devm_usb_put_phy(&pdev->dev, hsotg->phy);
>> +
>> clk_disable_unprepare(hsotg->clk);
>> clk_put(hsotg->clk);
>>
>> --
>> 1.7.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> With best regards,
> Sachin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@

Re: [PATCH v2 0/5] usb: phy: samsung: Introducing usb phy driver for samsung SoCs

[Praveen Paneri]

On Tue, Aug 7, 2012 at 3:30 PM, Kukjin Kim  wrote:
> Praveen Paneri wrote:
>>
>> Changes from v1:
>> Rebased patches to latest usb-next branch
>> Changed the name 'sec_usbphy' to 'samsung_usbphy'
>>
> Yes, looks better. But I'm not sure Felipe or Greg would prefer to use '_'
> not '-'...you used samsung-usbphy as a name in your patch.
Are you suggesting to change the name to 'samsung-usbphy' instead?
>
>> This patch set introduces a phy driver for samsung SoCs. It uses the
>> existing
>> transceiver infrastructure to provide phy control functions. Use of this
>> driver
>> can be extended for usb host phy as well. Over the period of time all the
>> phy
>> related code for most of the samsung SoCs can be integrated here.
>> Removing the existing phy code from mach-s3c64xx but not from other
>> machine
>
> Why? Is there any reason? After quick looking at your patches, seems this
> can remove all of setup-usb-phy in arch/arm/ for Samsung stuff. In addition,
> the isolation hook function also can be put in this by using platform_data
> or dt parsing.
No particular reason for it. Yes it can remove all of the setup-usbphy
code. I will send separate patches adding the support for other SoCs
and removing the phy related code from arch/arm.
>
>> code.This driver is tested with smdk6410 and Exynos4210(with DT).
>>
> I and my colleague, Yulgon will comment on this series soon.
That would be great. Will wait for that. You may use below patch to
add dt support for s3c-hsotg to test it on V310 board.

diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index e28cf10..de3cc78 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -67,6 +67,12 @@
reg = <0x125B 0x100>;
};

+   usbotg@1248 {
+   compatible = "samsung,exynos4210-hsotg";
+   reg = <0x1248 0x2>;
+   interrupts = <0 71 0>;
+   };
+
keypad@100A {
compatible = "samsung,s5pv210-keypad";
reg = <0x100A 0x100>;
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index f4ba9a3..79b77ff 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -3719,10 +3720,23 @@ static int __devexit s3c_hsotg_remove(struct
platform_device *pdev)
 #define s3c_hsotg_resume NULL
 #endif

+#ifdef CONFIG_OF
+static const struct of_device_id s3c_hsotg_dt_match[] = {
+   {
+   .compatible = "samsung,exynos4210-hsotg",
+   },
+   {},
+};
+MODULE_DEVICE_TABLE(of, s3c_usbphy_dt_match);
+#else
+#define s3c_hsotg_dt_match NULL
+#endif
+
 static struct platform_driver s3c_hsotg_driver = {
.driver = {
.name   = "s3c-hsotg",
.owner  = THIS_MODULE,
+   .of_match_table = s3c_hsotg_dt_match,
},
.probe  = s3c_hsotg_probe,
.remove = __devexit_p(s3c_hsotg_remove),

Thanks
Praveen
>
> Thanks.
>
> Best regards,
> Kgene.
> --
> Kukjin Kim , Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.
>
>
>> Praveen Paneri (5):
>>   usb: phy: samsung: Introducing usb phy driver for hsotg
>>   usb: s3c-hsotg: Adding phy driver support
>>   ARM: S3C64XX: Removing old phy setup code
>>   ARM: S3C64XX: Enabling samsung_usbphy driver
>>   ARM: Exynos4210: Enabling samsung_usbphy driver
>>
>>  .../devicetree/bindings/usb/samsung-usbphy.txt |9 +
>>  arch/arm/boot/dts/exynos4210.dtsi  |5 +
>>  arch/arm/mach-exynos/include/mach/map.h|1 +
>>  arch/arm/mach-exynos/mach-exynos4-dt.c |8 +
>>  arch/arm/mach-exynos/setup-usb-phy.c   |   13 +
>>  arch/arm/mach-s3c64xx/include/mach/map.h   |2 +
>>  arch/arm/mach-s3c64xx/mach-crag6410.c  |5 +-
>>  arch/arm/mach-s3c64xx/mach-smartq.c|6 +-
>>  arch/arm/mach-s3c64xx/mach-smdk6410.c  |5 +-
>>  arch/arm/mach-s3c64xx/setup-usb-phy.c  |   79 +
>>  arch/arm/plat-samsung/devs.c   |   32 ++
>>  arch/arm/plat-samsung/include/plat/devs.h  |1 +
>>  arch/arm/plat-samsung/include/plat/usb-phy.h   |1 +
>>  drivers/usb/gadget/s3c-hsotg.c |   38 ++-
>>  drivers/usb/phy/Kconfig|8 +
>>  drivers/usb/phy/Makefile   |1 +
>>  drivers/usb/phy/samsung_usbphy.c   |  355
> 
>>  drivers/usb/phy/samsung_usbphy.h   |   48 +++
>>  include/linux/platform_data/s3c-hsotg.h|5 +
>>  19 files changed, 534 insertions(+), 88 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/usb/samsung-
>> usbphy.txt
>>  create mode 100644 drivers/usb/phy/samsung_usbphy.c
>>  create mode 100644 drivers/

[PATCH] usb: musb: fix sparse warnings

[Felipe Balbi]

The following warnings are fixed:

drivers/usb/musb/musb_core.c:357:6: warning: symbol 'musb_otg_timer_func' was 
not declared. Should it be static?
drivers/usb/musb/musb_core.c:1339:27: warning: incorrect type in initializer 
(different address spaces)
drivers/usb/musb/musb_core.c:1339:27:expected void *mbase
drivers/usb/musb/musb_core.c:1339:27:got void [noderef] *mregs
drivers/usb/musb/musb_core.c:1347:17: warning: incorrect type in argument 1 
(different address spaces)
drivers/usb/musb/musb_core.c:1347:17:expected void [noderef] *addr
drivers/usb/musb/musb_core.c:1347:17:got void *mbase
drivers/usb/musb/musb_core.h:487:27: warning: incorrect type in initializer 
(different address spaces)
drivers/usb/musb/musb_core.h:487:27:expected void *mbase
drivers/usb/musb/musb_core.h:487:27:got void [noderef] *mregs
drivers/usb/musb/musb_core.h:491:26: warning: incorrect type in argument 1 
(different address spaces)
drivers/usb/musb/musb_core.h:491:26:expected void const [noderef] 
*addr
drivers/usb/musb/musb_core.h:491:26:got void *mbase
drivers/usb/musb/tusb6010.c:270:48: warning: incorrect type in argument 2 
(different address spaces)
drivers/usb/musb/tusb6010.c:270:48:expected void [noderef] *buf
drivers/usb/musb/tusb6010.c:270:48:got unsigned char [usertype] *[assigned] 
buf
drivers/usb/musb/tusb6010.c:164:32: warning: incorrect type in argument 1 
(different address spaces)
drivers/usb/musb/tusb6010.c:164:32:expected void *to
drivers/usb/musb/tusb6010.c:164:32:got void [noderef] *buf
drivers/usb/musb/tusb6010.c:172:24: warning: incorrect type in argument 1 
(different address spaces)
drivers/usb/musb/tusb6010.c:172:24:expected void *to
drivers/usb/musb/tusb6010.c:172:24:got void [noderef] *[assigned] buf

Signed-off-by: Felipe Balbi 
---
 drivers/usb/musb/musb_core.c | 4 ++--
 drivers/usb/musb/musb_core.h | 2 +-
 drivers/usb/musb/tusb6010.c  | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 69711e4..9bc4feab 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -354,7 +354,7 @@ void musb_load_testpacket(struct musb *musb)
 /*
  * Handles OTG hnp timeouts, such as b_ase0_brst
  */
-void musb_otg_timer_func(unsigned long data)
+static void musb_otg_timer_func(unsigned long data)
 {
struct musb *musb = (struct musb *)data;
unsigned long   flags;
@@ -1336,7 +1336,7 @@ static int __devinit ep_config_from_hw(struct musb *musb)
 {
u8 epnum = 0;
struct musb_hw_ep *hw_ep;
-   void *mbase = musb->mregs;
+   void __iomem *mbase = musb->mregs;
int ret = 0;
 
dev_dbg(musb->controller, "<== static silicon ep config\n");
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 586105b..8bb324d 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -484,7 +484,7 @@ static inline void musb_configure_ep0(struct musb *musb)
 static inline int musb_read_fifosize(struct musb *musb,
struct musb_hw_ep *hw_ep, u8 epnum)
 {
-   void *mbase = musb->mregs;
+   void __iomem *mbase = musb->mregs;
u8 reg = 0;
 
/* read from core using indexed model */
diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c
index 1a1bd9c..4073a6f 100644
--- a/drivers/usb/musb/tusb6010.c
+++ b/drivers/usb/musb/tusb6010.c
@@ -153,7 +153,7 @@ tusb_fifo_write_unaligned(void __iomem *fifo, const u8 
*buf, u16 len)
 }
 
 static inline void tusb_fifo_read_unaligned(void __iomem *fifo,
-   void __iomem *buf, u16 len)
+   void *buf, u16 len)
 {
u32 val;
int i;
-- 
1.7.12.rc0

--
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: host: xhci: sparse fixes

[Felipe Balbi]

drivers/usb/host/xhci.c:1826:14: warning: symbol 'xhci_get_block_size' was not 
declared. Should it be static?
drivers/usb/host/xhci.c:1844:14: warning: symbol 'xhci_get_largest_overhead' 
was not declared. Should it be static?
drivers/usb/host/xhci-ring.c:2304:36: warning: context imbalance in 
'handle_tx_event' - unexpected unlock
drivers/usb/host/xhci-hub.c:425:6: warning: symbol 'xhci_set_remote_wake_mask' 
was not declared. Should it be static?

Signed-off-by: Felipe Balbi 
---
 drivers/usb/host/xhci-hub.c  | 2 +-
 drivers/usb/host/xhci-ring.c | 2 ++
 drivers/usb/host/xhci.c  | 5 +++--
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 74bfc86..5575402 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -422,7 +422,7 @@ void xhci_set_link_state(struct xhci_hcd *xhci, __le32 
__iomem **port_array,
xhci_writel(xhci, temp, port_array[port_id]);
 }
 
-void xhci_set_remote_wake_mask(struct xhci_hcd *xhci,
+static void xhci_set_remote_wake_mask(struct xhci_hcd *xhci,
__le32 __iomem **port_array, int port_id, u16 wake_mask)
 {
u32 temp;
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 8275645..3bc1224 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1995,6 +1995,8 @@ static int process_bulk_intr_td(struct xhci_hcd *xhci, 
struct xhci_td *td,
  */
 static int handle_tx_event(struct xhci_hcd *xhci,
struct xhci_transfer_event *event)
+   __releases(&xhci->lock)
+   __acquires(&xhci->lock)
 {
struct xhci_virt_device *xdev;
struct xhci_virt_ep *ep;
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 7648b2d..081c49e 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1823,7 +1823,7 @@ static void xhci_finish_resource_reservation(struct 
xhci_hcd *xhci,
xhci->num_active_eps);
 }
 
-unsigned int xhci_get_block_size(struct usb_device *udev)
+static unsigned int xhci_get_block_size(struct usb_device *udev)
 {
switch (udev->speed) {
case USB_SPEED_LOW:
@@ -1841,7 +1841,8 @@ unsigned int xhci_get_block_size(struct usb_device *udev)
}
 }
 
-unsigned int xhci_get_largest_overhead(struct xhci_interval_bw *interval_bw)
+static unsigned int
+xhci_get_largest_overhead(struct xhci_interval_bw *interval_bw)
 {
if (interval_bw->overhead[LS_OVERHEAD_TYPE])
return LS_OVERHEAD;
-- 
1.7.12.rc0

--
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: Do we need asynchronous pm_runtime_get()? (was: Re: bisected regression ...)

[Rafael J. Wysocki]

On Tuesday, August 07, 2012, Ming Lei wrote:
> On Mon, Aug 6, 2012 at 10:47 PM, Alan Stern  wrote:
> > No, no, you have completely misunderstood the whole point of this
> > change.
> 
> Sorry, you are right. And the callback should be renamed as
> '.runtime_post_resume', which should do something I/O related in
> theory just after device becomes active.
> 
> >
> > The idea is for "func" to be called at a time when it is known that the
> > device is at full power.  That means it _has_ to be called after the
> > runtime_resume callback returns.
> 
> Yes, I agree, but I don't think it may make .runtime_post_resume
> not doable, do I?

No more device PM callbacks, please.

Besides, callbacks in struct dev_pm_ops are not only for drivers.

> > Also, "func" should not be stored in dev_pm_ops because it won't be a
> > read-only value.
> 
> Sorry, could you explain it in detail that why the 'func'
> has to switch to multiple functions dynamically? I understand
> one function is enough and sometimes it can be bypassed with
> one flag(such as, ignore_post_resume is introduced in dev_pm_info)
> set.  Also, the driver can store the device specific states
> in its own device instance to deal with different situations in the callback.
> 
> If the idea is doable, we can save one pointer in 'struct device',
> since the 'func' may not be used by more than 90% devices, also
> have document benefit, even may simplify implementation of the
> mechanism.

And how many struct device objects there are for the one extra pointer to
matter, let alone the fact that you want to replace it by one extra pointer
somewhere else?

Rafael
--
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/dwc3: Correct missed isoc when endpoint is busy

[Pratyush Anand]

When MISSED_ISOC is set, BUSY is also set. Since, we are handling
MISSED_ISOC as a separate case in third scenario, therefore handle only
BUSY but not MISSED_ISOC in second scenario.

Signed-off-by: Pratyush Anand 
---
 drivers/usb/dwc3/gadget.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 0ead4cd..800944f 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1139,7 +1139,8 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, 
struct dwc3_request *req)
 *core may not see the modified TRB(s).
 */
if (usb_endpoint_xfer_isoc(dep->endpoint.desc) &&
-   (dep->flags & DWC3_EP_BUSY)) {
+   (dep->flags & DWC3_EP_BUSY) &&
+   !(dep->flags & DWC3_EP_MISSED_ISOC)) {
WARN_ON_ONCE(!dep->resource_index);
ret = __dwc3_gadget_kick_transfer(dep, dep->resource_index,
false);
-- 
1.7.5.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: [PATH] usb:musb fix musb_start_urb Oops

[Felipe Balbi]

Hi,

On Tue, Aug 07, 2012 at 10:37:19AM +0800, yuzheng ma wrote:
> This path fix musb_start_urb oops
> 
> diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
> index e090c79..63303c7 100644
> --- a/drivers/usb/musb/musb_host.c
> +++ b/drivers/usb/musb/musb_host.c
> @@ -2045,7 +2045,7 @@ static int musb_urb_enqueue(
>  * we only have work to do in the former case.
>  */
> spin_lock_irqsave(&musb->lock, flags);
> -   if (hep->hcpriv) {
> +   if (hep->hcpriv || !next_urb(qh)) {
> /* some concurrent activity submitted another urb to hep...
>  * odd, rare, error prone, but legal.
>  */

patch is in wrong format. Please use git with git format-patch and git
send-email. It will generate the patch properly for you.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH RFC] usb: musb: use DMA mode 1 whenever possible

[Felipe Balbi]

Hi,

On Thu, Aug 02, 2012 at 11:11:40AM +0300, Roger Quadros wrote:
> Do not rely on any hints from gadget drivers and use DMA mode 1
> whenever we expect more data than the endpoint's packet size and
> have not yet received a short packet.
> 
> The last packet if short is always transferred using DMA mode 0.
> 
> This patch fixes USB throughput issues in mass storage mode for
> host to device transfers.
> 
> Signed-off-by: Roger Quadros 

unfortunately this doesn't apply. Can you rebase on my musb branch ?

thanks

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH RFC] usb: musb: use DMA mode 1 whenever possible

[Rajaram R]

Hi Robert/Felipie

On Thu, Aug 2, 2012 at 1:41 PM, Roger Quadros  wrote:
>
> Do not rely on any hints from gadget drivers and use DMA mode 1
> whenever we expect more data than the endpoint's packet size and
> have not yet received a short packet.
>
> The last packet if short is always transferred using DMA mode 0.
>
> This patch fixes USB throughput issues in mass storage mode for
> host to device transfers.
>
> Signed-off-by: Roger Quadros 
> ---
>  drivers/usb/musb/musb_gadget.c |   30 --
>  1 files changed, 4 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
> index f7194cf..9c94655 100644
> --- a/drivers/usb/musb/musb_gadget.c
> +++ b/drivers/usb/musb/musb_gadget.c
> @@ -707,12 +707,11 @@ static void rxstate(struct musb *musb, struct 
> musb_request *req)
> len = musb_readw(epio, MUSB_RXCOUNT);
>
> /*
> -* Enable Mode 1 on RX transfers only when short_not_ok flag
> -* is set. Currently short_not_ok flag is set only from
> -* file_storage and f_mass_storage drivers
> +*  use mode 1 only if we expect data larger than ep packet_sz
> +*  and we have not yet received a short packet
>  */
> -
> -   if (request->short_not_ok && len == musb_ep->packet_sz)
> +   if ((request->length - request->actual > musb_ep->packet_sz) 
> &&
> +   (len >= musb_ep->packet_sz))

If the request length is 512 it can go in mode. Please add that while pushing.


> use_mode_1 = 1;
> else
> use_mode_1 = 0;
> @@ -727,27 +726,6 @@ static void rxstate(struct musb *musb, struct 
> musb_request *req)
> c = musb->dma_controller;
> channel = musb_ep->dma;
>
> -   /* We use DMA Req mode 0 in rx_csr, and DMA controller operates in
> -* mode 0 only. So we do not get endpoint interrupts due to DMA
> -* completion. We only get interrupts from DMA controller.
> -*
> -* We could operate in DMA mode 1 if we knew the size of the tranfer
> -* in advance. For mass storage class, request->length = what the host
> -* sends, so that'd work.  But for pretty much everything else,
> -* request->length is routinely more than what the host sends. For
> -* most these gadgets, end of is signified either by a short packet,
> -* or filling the last byte of the buffer.  (Sending extra data in
> -* that last pckate should trigger an overflow fault.)  But in mode 1,
> -* we don't get DMA completion interrupt for short packets.
> -*
> -* Theoretically, we could enable DMAReq irq (MUSB_RXCSR_DMAMODE = 1),
> -* to get endpoint interrupt on every DMA req, but that didn't seem
> -* to work reliably.
> -*
> -* REVISIT an updated g_file_storage can set req->short_not_ok, which
> -* then becomes usable as a runtime "use mode 1" hint...
> -*/
> -
> /* Experimental: Mode1 works with mass 
> storage use cases */
> if (use_mode_1) {
> csr |= MUSB_RXCSR_AUTOCLEAR;
> --
> 1.7.4.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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 RFC] usb: musb: use DMA mode 1 whenever possible

[Rajaram R]

On Tue, Aug 7, 2012 at 5:26 PM, Rajaram R  wrote:
> Hi Robert/Felipie
>
> On Thu, Aug 2, 2012 at 1:41 PM, Roger Quadros  wrote:
>>
>> Do not rely on any hints from gadget drivers and use DMA mode 1
>> whenever we expect more data than the endpoint's packet size and
>> have not yet received a short packet.
>>
>> The last packet if short is always transferred using DMA mode 0.
>>
>> This patch fixes USB throughput issues in mass storage mode for
>> host to device transfers.
>>
>> Signed-off-by: Roger Quadros 
>> ---
>>  drivers/usb/musb/musb_gadget.c |   30 --
>>  1 files changed, 4 insertions(+), 26 deletions(-)
>>
>> diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
>> index f7194cf..9c94655 100644
>> --- a/drivers/usb/musb/musb_gadget.c
>> +++ b/drivers/usb/musb/musb_gadget.c
>> @@ -707,12 +707,11 @@ static void rxstate(struct musb *musb, struct 
>> musb_request *req)
>> len = musb_readw(epio, MUSB_RXCOUNT);
>>
>> /*
>> -* Enable Mode 1 on RX transfers only when short_not_ok flag
>> -* is set. Currently short_not_ok flag is set only from
>> -* file_storage and f_mass_storage drivers
>> +*  use mode 1 only if we expect data larger than ep 
>> packet_sz
>> +*  and we have not yet received a short packet
>>  */
>> -
>> -   if (request->short_not_ok && len == musb_ep->packet_sz)
>> +   if ((request->length - request->actual > musb_ep->packet_sz) 
>> &&
>> +   (len >= musb_ep->packet_sz))
>
> If the request length is 512 it can go in mode. Please add that while pushing.

If the request length is 512 it can go in mode1. Please add that while pushing.

>
>
>> use_mode_1 = 1;
>> else
>> use_mode_1 = 0;
>> @@ -727,27 +726,6 @@ static void rxstate(struct musb *musb, struct 
>> musb_request *req)
>> c = musb->dma_controller;
>> channel = musb_ep->dma;
>>
>> -   /* We use DMA Req mode 0 in rx_csr, and DMA controller operates in
>> -* mode 0 only. So we do not get endpoint interrupts due to DMA
>> -* completion. We only get interrupts from DMA controller.
>> -*
>> -* We could operate in DMA mode 1 if we knew the size of the tranfer
>> -* in advance. For mass storage class, request->length = what the 
>> host
>> -* sends, so that'd work.  But for pretty much everything else,
>> -* request->length is routinely more than what the host sends. For
>> -* most these gadgets, end of is signified either by a short packet,
>> -* or filling the last byte of the buffer.  (Sending extra data in
>> -* that last pckate should trigger an overflow fault.)  But in mode 
>> 1,
>> -* we don't get DMA completion interrupt for short packets.
>> -*
>> -* Theoretically, we could enable DMAReq irq (MUSB_RXCSR_DMAMODE = 
>> 1),
>> -* to get endpoint interrupt on every DMA req, but that didn't seem
>> -* to work reliably.
>> -*
>> -* REVISIT an updated g_file_storage can set req->short_not_ok, which
>> -* then becomes usable as a runtime "use mode 1" hint...
>> -*/
>> -
>> /* Experimental: Mode1 works with mass 
>> storage use cases */
>> if (use_mode_1) {
>> csr |= MUSB_RXCSR_AUTOCLEAR;
>> --
>> 1.7.4.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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 RFC] usb: musb: use DMA mode 1 whenever possible

[Roger Quadros]

Hi,

On 08/07/2012 02:57 PM, Rajaram R wrote:
> On Tue, Aug 7, 2012 at 5:26 PM, Rajaram R  
> wrote:
>> Hi Robert/Felipie
>>
>> On Thu, Aug 2, 2012 at 1:41 PM, Roger Quadros  wrote:
>>>
>>> Do not rely on any hints from gadget drivers and use DMA mode 1
>>> whenever we expect more data than the endpoint's packet size and
>>> have not yet received a short packet.
>>>
>>> The last packet if short is always transferred using DMA mode 0.
>>>
>>> This patch fixes USB throughput issues in mass storage mode for
>>> host to device transfers.
>>>
>>> Signed-off-by: Roger Quadros 
>>> ---
>>>  drivers/usb/musb/musb_gadget.c |   30 --
>>>  1 files changed, 4 insertions(+), 26 deletions(-)
>>>
>>> diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
>>> index f7194cf..9c94655 100644
>>> --- a/drivers/usb/musb/musb_gadget.c
>>> +++ b/drivers/usb/musb/musb_gadget.c
>>> @@ -707,12 +707,11 @@ static void rxstate(struct musb *musb, struct 
>>> musb_request *req)
>>> len = musb_readw(epio, MUSB_RXCOUNT);
>>>
>>> /*
>>> -* Enable Mode 1 on RX transfers only when short_not_ok flag
>>> -* is set. Currently short_not_ok flag is set only from
>>> -* file_storage and f_mass_storage drivers
>>> +*  use mode 1 only if we expect data larger than ep 
>>> packet_sz
>>> +*  and we have not yet received a short packet
>>>  */
>>> -
>>> -   if (request->short_not_ok && len == musb_ep->packet_sz)
>>> +   if ((request->length - request->actual > 
>>> musb_ep->packet_sz) &&
>>> +   (len >= musb_ep->packet_sz))
>>
>> If the request length is 512 it can go in mode. Please add that while 
>> pushing.
> 
> If the request length is 512 it can go in mode1. Please add that while 
> pushing.
> 

Do you mean that condition should be

if ((request->length - request->actual >= musb_ep->packet_sz) &&
(len >= musb_ep->packet_sz))
use_mode_1 = 1;
else
use_mode_1 = 0;

regards,
-roger
--
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: Do we need asynchronous pm_runtime_get()? (was: Re: bisected regression ...)

[Rafael J. Wysocki]

On Monday, August 06, 2012, Rafael J. Wysocki wrote:
> On Monday, August 06, 2012, Alan Stern wrote:
> > On Sun, 5 Aug 2012, Rafael J. Wysocki wrote:
> [...]
> > 
> > > What about the appended experimental patch?
> > 
> > For now, I think it would be best to start with a single func argument.  
> > If it turns out that anyone really needs to have two separate
> > arguments, the single-argument form can be reimplemented on top of the
> > two-argument form easily enough.
> 
> All right.
> 
> > > @@ -484,6 +484,15 @@ static int rpm_suspend(struct device *de
> > >   goto out;
> > >  }
> > >  
> > > +void rpm_queue_up_resume(struct device *dev)
> > > +{
> > > + dev->power.request = RPM_REQ_RESUME;
> > > + if (!dev->power.request_pending) {
> > > + dev->power.request_pending = true;
> > > + queue_work(pm_wq, &dev->power.work);
> > > + }
> > > +}
> > > +
> > >  /**
> > >   * rpm_resume - Carry out runtime resume of given device.
> > >   * @dev: Device to resume.
> > > @@ -524,7 +533,9 @@ static int rpm_resume(struct device *dev
> > >* rather than cancelling it now only to restart it again in the near
> > >* future.
> > >*/
> > > - dev->power.request = RPM_REQ_NONE;
> > > + if (dev->power.request != RPM_REQ_RESUME || !dev->power.func)
> > > + dev->power.request = RPM_REQ_NONE;
> > > +
> > >   if (!dev->power.timer_autosuspends)
> > >   pm_runtime_deactivate_timer(dev);
> > >  
> > > @@ -533,6 +544,12 @@ static int rpm_resume(struct device *dev
> > >   goto out;
> > >   }
> > >  
> > > + if (dev->power.func && (rpmflags & RPM_ASYNC)) {
> > > + rpm_queue_up_resume(dev);
> > > + retval = 0;
> > > + goto out;
> > > + }
> > > +
> > >   if (dev->power.runtime_status == RPM_RESUMING
> > >   || dev->power.runtime_status == RPM_SUSPENDING) {
> > >   DEFINE_WAIT(wait);
> > 
> > All those changes (and some of the following ones) are symptoms of a
> > basic mistake in this approach.
> 
> Every time you say something like this (i.e. liks someone who knows better)

s/liks/like/

> I kind of feel like being under attach, which I hope is not your intention.

s/attach/attack/

Two typos in one sentence, I guess it could have been worse ...

> Never mind. :-)
> 
> Those changes are there for different reasons rather unrelated to the way
> func() is being called, so let me explain.
> 
> First, rpm_queue_up_resume() is introduced, because the code it contains will
> have to be called in two different places.  At least I don't see how to avoid
> that without increasing the code complexity too much.
> 
> Second, the following change in rpm_resume()
> 
> - dev->power.request = RPM_REQ_NONE;
> + if (dev->power.request != RPM_REQ_RESUME || !dev->power.func)
> + dev->power.request = RPM_REQ_NONE;
> 
> is made to prevent rpm_resume() from canceling the execution of func() queued
> up by an earlier pm_runtime_get_and_call().  I believe it is necessary.
> 
> Finally, this change in rpm_resume():
>  
> + if (dev->power.func && (rpmflags & RPM_ASYNC)) {
> + rpm_queue_up_resume(dev);
> + retval = 0;
> + goto out;
> + }
> 
> is not strictly necessary if pm_runtime_get_and_call() is modified to run
> rpm_queue_up_resume() directly, like in the new version of the patch which is
> appended.  This reduces the number of checks overall, so perhaps it's better.
> 
> > The idea of this new feature is to
> > call "func" as soon as we know the device is at full power, no matter
> > how it got there.
> 
> Yes, it is so.
> 
> > That means we should call it near the end of
> > rpm_resume() (just before the rpm_idle() call), not from within
> > pm_runtime_work().
> > 
> > Doing it this way will be more efficient and (I think) will remove
> > some races.
> 
> Except that func() shouldn't be executed under dev->power.lock, which makes it
> rather difficult to call it from rpm_resume().  Or at least it seems so.
> 
> Moreover, it should be called after we've changed the status to RPM_ACTIVE
> _and_ dropped the lock.

So we could drop the lock right before returning, execute func() and acquire
the lock once again, but then func() might be executed by any thread that
happened to resume the device.  In that case the caller of
pm_runtime_get_and_call() would have to worry about locks that such threads
might acquire and it would have to make sure that func() didn't try to acquire
them too.  That may not be a big deal, but if func() is executed by
pm_runtime_work(), that issue simply goes away.

Then, however, there's another issue: what should happen if
pm_runtime_get_and_call() finds that it cannot execute func() right away,
so it queues up resume and the execution of it, in the meantime some other
thread resumes the device synchronously and pm_runtime_get_and_call() is
run again.  I think in that case func() should be executed synchronously
and the one waiting for execution should be canceled.  The alternative
would 

Re: [PATCH] usb/dwc3: Correct missed isoc when endpoint is busy

[Felipe Balbi]

Hi,

On Tue, Aug 07, 2012 at 04:54:18PM +0530, Pratyush Anand wrote:
> When MISSED_ISOC is set, BUSY is also set. Since, we are handling
> MISSED_ISOC as a separate case in third scenario, therefore handle only
> BUSY but not MISSED_ISOC in second scenario.
> 
> Signed-off-by: Pratyush Anand 
> ---
>  drivers/usb/dwc3/gadget.c |3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 0ead4cd..800944f 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -1139,7 +1139,8 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, 
> struct dwc3_request *req)
>*core may not see the modified TRB(s).
>*/
>   if (usb_endpoint_xfer_isoc(dep->endpoint.desc) &&
> - (dep->flags & DWC3_EP_BUSY)) {
> + (dep->flags & DWC3_EP_BUSY) &&
> + !(dep->flags & DWC3_EP_MISSED_ISOC)) {

what about inverting the cases then ? Moving missed_isoc before ep_busy?
Would that work ? I would be more comfortable with that, I guess.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] usb/dwc3: Correct missed isoc when endpoint is busy

[Pratyush Anand]

On 8/7/2012 5:54 PM, Felipe Balbi wrote:

Hi,

On Tue, Aug 07, 2012 at 04:54:18PM +0530, Pratyush Anand wrote:

When MISSED_ISOC is set, BUSY is also set. Since, we are handling
MISSED_ISOC as a separate case in third scenario, therefore handle only
BUSY but not MISSED_ISOC in second scenario.

Signed-off-by: Pratyush Anand 
---
  drivers/usb/dwc3/gadget.c |3 ++-
  1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 0ead4cd..800944f 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1139,7 +1139,8 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, 
struct dwc3_request *req)
 *core may not see the modified TRB(s).
 */
if (usb_endpoint_xfer_isoc(dep->endpoint.desc) &&
-   (dep->flags & DWC3_EP_BUSY)) {
+   (dep->flags & DWC3_EP_BUSY) &&
+   !(dep->flags & DWC3_EP_MISSED_ISOC)) {


what about inverting the cases then ? Moving missed_isoc before ep_busy?
Would that work ? I would be more comfortable with that, I guess.



Probably not. Even then (with inverted) case 2 (ie missed isoc) and case 
3 (ie ep busy) will be true, and both if loop will be executed.


If we keep 3rd case in else part of 2nd case, then we do not need to 
check an extra flag in second case. Let me know, it this is ok with you.


Regards
Pratyush


--
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/dwc3: Correct missed isoc when endpoint is busy

[Felipe Balbi]

On Tue, Aug 07, 2012 at 06:09:10PM +0530, Pratyush Anand wrote:
> On 8/7/2012 5:54 PM, Felipe Balbi wrote:
> >Hi,
> >
> >On Tue, Aug 07, 2012 at 04:54:18PM +0530, Pratyush Anand wrote:
> >>When MISSED_ISOC is set, BUSY is also set. Since, we are handling
> >>MISSED_ISOC as a separate case in third scenario, therefore handle only
> >>BUSY but not MISSED_ISOC in second scenario.
> >>
> >>Signed-off-by: Pratyush Anand 
> >>---
> >>  drivers/usb/dwc3/gadget.c |3 ++-
> >>  1 files changed, 2 insertions(+), 1 deletions(-)
> >>
> >>diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> >>index 0ead4cd..800944f 100644
> >>--- a/drivers/usb/dwc3/gadget.c
> >>+++ b/drivers/usb/dwc3/gadget.c
> >>@@ -1139,7 +1139,8 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep 
> >>*dep, struct dwc3_request *req)
> >> *core may not see the modified TRB(s).
> >> */
> >>if (usb_endpoint_xfer_isoc(dep->endpoint.desc) &&
> >>-   (dep->flags & DWC3_EP_BUSY)) {
> >>+   (dep->flags & DWC3_EP_BUSY) &&
> >>+   !(dep->flags & DWC3_EP_MISSED_ISOC)) {
> >
> >what about inverting the cases then ? Moving missed_isoc before ep_busy?
> >Would that work ? I would be more comfortable with that, I guess.
> >
> 
> Probably not. Even then (with inverted) case 2 (ie missed isoc) and
> case 3 (ie ep busy) will be true, and both if loop will be executed.
> 
> If we keep 3rd case in else part of 2nd case, then we do not need to
> check an extra flag in second case. Let me know, it this is ok with
> you.

aaa, indeed. I guess I'll apply this patch as is. For some reason I
thought we had return statements inside each if block. Oh well, getting
old I guess :-p

-- 
balbi


signature.asc
Description: Digital signature

[PATCH 1/2] usb: musb: use DMA mode 1 whenever possible

[Roger Quadros]

Do not rely on any hints from gadget drivers and use DMA mode 1
whenever we expect data of at least the endpoint's packet size and
have not yet received a short packet.

The last packet if short is always transferred using DMA mode 0.

This patch fixes USB throughput issues in mass storage mode for
host to device transfers.

Signed-off-by: Roger Quadros 
---
 drivers/usb/musb/musb_gadget.c |   30 --
 1 files changed, 4 insertions(+), 26 deletions(-)

diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 8d2cce1..5c4392b 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -707,12 +707,11 @@ static void rxstate(struct musb *musb, struct 
musb_request *req)
fifo_count = musb_readw(epio, MUSB_RXCOUNT);
 
/*
-* Enable Mode 1 on RX transfers only when short_not_ok flag
-* is set. Currently short_not_ok flag is set only from
-* file_storage and f_mass_storage drivers
+*  use mode 1 only if we expect data of at least ep packet_sz
+*  and have not yet received a short packet
 */
-
-   if (request->short_not_ok && fifo_count == musb_ep->packet_sz)
+   if ((request->length - request->actual >= musb_ep->packet_sz) &&
+   (fifo_count >= musb_ep->packet_sz))
use_mode_1 = 1;
else
use_mode_1 = 0;
@@ -727,27 +726,6 @@ static void rxstate(struct musb *musb, struct musb_request 
*req)
c = musb->dma_controller;
channel = musb_ep->dma;
 
-   /* We use DMA Req mode 0 in rx_csr, and DMA controller operates in
-* mode 0 only. So we do not get endpoint interrupts due to DMA
-* completion. We only get interrupts from DMA controller.
-*
-* We could operate in DMA mode 1 if we knew the size of the tranfer
-* in advance. For mass storage class, request->length = what the host
-* sends, so that'd work.  But for pretty much everything else,
-* request->length is routinely more than what the host sends. For
-* most these gadgets, end of is signified either by a short packet,
-* or filling the last byte of the buffer.  (Sending extra data in
-* that last pckate should trigger an overflow fault.)  But in mode 1,
-* we don't get DMA completion interrupt for short packets.
-*
-* Theoretically, we could enable DMAReq irq (MUSB_RXCSR_DMAMODE = 1),
-* to get endpoint interrupt on every DMA req, but that didn't seem
-* to work reliably.
-*
-* REVISIT an updated g_file_storage can set req->short_not_ok, which
-* then becomes usable as a runtime "use mode 1" hint...
-*/
-
/* Experimental: Mode1 works with mass storage 
use cases */
if (use_mode_1) {
csr |= MUSB_RXCSR_AUTOCLEAR;
-- 
1.7.4.1

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

[PATCH 2/2] usb: musb: Remove redundant if statement

[Roger Quadros]

Signed-off-by: Roger Quadros 
---
 drivers/usb/musb/musb_gadget.c |   34 +++---
 1 files changed, 15 insertions(+), 19 deletions(-)

diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 5c4392b..2bb50ca 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -722,6 +722,7 @@ static void rxstate(struct musb *musb, struct musb_request 
*req)
struct dma_controller   *c;
struct dma_channel  *channel;
int use_dma = 0;
+   int transfer_size;
 
c = musb->dma_controller;
channel = musb_ep->dma;
@@ -742,35 +743,30 @@ static void rxstate(struct musb *musb, struct 
musb_request *req)
csr | MUSB_RXCSR_DMAMODE);
musb_writew(epio, MUSB_RXCSR, csr);
 
+   transfer_size = min(request->length - 
request->actual,
+   channel->max_len);
+   musb_ep->dma->desired_mode = 1;
+
} else {
if (!musb_ep->hb_mult &&

musb_ep->hw_ep->rx_double_buffered)
csr |= MUSB_RXCSR_AUTOCLEAR;
csr |= MUSB_RXCSR_DMAENAB;
musb_writew(epio, MUSB_RXCSR, csr);
-   }
 
-   if (request->actual < request->length) {
-   int transfer_size = 0;
-   if (use_mode_1) {
-   transfer_size = 
min(request->length - request->actual,
-   
channel->max_len);
-   musb_ep->dma->desired_mode = 1;
-   } else {
-   transfer_size = 
min(request->length - request->actual,
+   transfer_size = min(request->length - 
request->actual,
(unsigned)fifo_count);
-   musb_ep->dma->desired_mode = 0;
-   }
-
-   use_dma = c->channel_program(
-   channel,
-   musb_ep->packet_sz,
-   channel->desired_mode,
-   request->dma
-   + request->actual,
-   transfer_size);
+   musb_ep->dma->desired_mode = 0;
}
 
+   use_dma = c->channel_program(
+   channel,
+   musb_ep->packet_sz,
+   channel->desired_mode,
+   request->dma
+   + request->actual,
+   transfer_size);
+
if (use_dma)
return;
}
-- 
1.7.4.1

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

Re: [PATCH 2/2] usb: musb: Remove redundant if statement

[Felipe Balbi]

On Tue, Aug 07, 2012 at 04:09:57PM +0300, Roger Quadros wrote:
> Signed-off-by: Roger Quadros 

a little pedantic, but I really need a commit log here ;-)

-- 
balbi


signature.asc
Description: Digital signature

[PATCH 2/2 v2] usb: musb: Remove redundant if statement

[Roger Quadros]

Remove unnecessary if condition. No change in logic.

Signed-off-by: Roger Quadros 
---
 drivers/usb/musb/musb_gadget.c |   34 +++---
 1 files changed, 15 insertions(+), 19 deletions(-)

diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index 5c4392b..2bb50ca 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -722,6 +722,7 @@ static void rxstate(struct musb *musb, struct musb_request 
*req)
struct dma_controller   *c;
struct dma_channel  *channel;
int use_dma = 0;
+   int transfer_size;
 
c = musb->dma_controller;
channel = musb_ep->dma;
@@ -742,35 +743,30 @@ static void rxstate(struct musb *musb, struct 
musb_request *req)
csr | MUSB_RXCSR_DMAMODE);
musb_writew(epio, MUSB_RXCSR, csr);
 
+   transfer_size = min(request->length - 
request->actual,
+   channel->max_len);
+   musb_ep->dma->desired_mode = 1;
+
} else {
if (!musb_ep->hb_mult &&

musb_ep->hw_ep->rx_double_buffered)
csr |= MUSB_RXCSR_AUTOCLEAR;
csr |= MUSB_RXCSR_DMAENAB;
musb_writew(epio, MUSB_RXCSR, csr);
-   }
 
-   if (request->actual < request->length) {
-   int transfer_size = 0;
-   if (use_mode_1) {
-   transfer_size = 
min(request->length - request->actual,
-   
channel->max_len);
-   musb_ep->dma->desired_mode = 1;
-   } else {
-   transfer_size = 
min(request->length - request->actual,
+   transfer_size = min(request->length - 
request->actual,
(unsigned)fifo_count);
-   musb_ep->dma->desired_mode = 0;
-   }
-
-   use_dma = c->channel_program(
-   channel,
-   musb_ep->packet_sz,
-   channel->desired_mode,
-   request->dma
-   + request->actual,
-   transfer_size);
+   musb_ep->dma->desired_mode = 0;
}
 
+   use_dma = c->channel_program(
+   channel,
+   musb_ep->packet_sz,
+   channel->desired_mode,
+   request->dma
+   + request->actual,
+   transfer_size);
+
if (use_dma)
return;
}
-- 
1.7.4.1

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

[no subject]

[pkondeti]

unsubscribe linux-usb

--
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:

[Pavan Kondeti]

On 8/7/2012 7:06 PM, pkond...@codeaurora.org wrote:
> unsubscribe linux-usb
> 

Sorry for the noise and spam :-( For some reason, I stopped receiving
emails from this list. I am suggested to re-subscribe to the list. I end
up sending unsubscribe request to wrong list. Every thing is good now.

Thanks,
Pavan

-- 
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.


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

[PATCH RFC] usb: musb: Prevent the masking of the return value

[Shubhrajyoti D]

Currently the errors returned by fifo_setup get masked
by EINVAL, propagate the same to the caller.

Signed-off-by: Shubhrajyoti D 
---
 drivers/usb/musb/musb_core.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 5760de9..cf22953 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1302,7 +1302,7 @@ done:
if (offset < 0) {
pr_debug("%s: mem overrun, ep %d\n",
musb_driver_name, epn);
-   return -EINVAL;
+   return offset;
}
epn++;
musb->nr_endpoints = max(epn, musb->nr_endpoints);
-- 
1.7.5.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 RFC] usb: musb: Free NIrq in a missing error path

[Shubhrajyoti D]

In one of the error paths the free of nIrq was missed.
Fix the same.

Signed-off-by: Shubhrajyoti D 
---
 drivers/usb/musb/musb_core.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index cf22953..d4504d5 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2034,7 +2034,7 @@ musb_init_controller(struct device *dev, int nIrq, void 
__iomem *ctrl)
 
}
if (status < 0)
-   goto fail3;
+   goto free_irq;
 
status = musb_init_debugfs(musb);
if (status < 0)
@@ -2066,12 +2066,12 @@ fail5:
musb_exit_debugfs(musb);
 
 fail4:
-   free_irq(musb->nIrq, musb);
if (!is_otg_enabled(musb) && is_host_enabled(musb))
usb_remove_hcd(musb_to_hcd(musb));
else
musb_gadget_cleanup(musb);
-
+free_irq:
+   free_irq(musb->nIrq, musb);
 fail3:
pm_runtime_put_sync(musb->controller);
 
-- 
1.7.5.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 RFC] usb: otg: Remove the unneeded NULL check

[Shubhrajyoti D]

The function usb_add_phy trusts the sanity of the caller.
Also it accesses x after the NULL check.
Remove the unneeded check.

Signed-off-by: Shubhrajyoti D 
---
 drivers/usb/otg/otg.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index 1bf60a2..a30c041 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
@@ -159,7 +159,7 @@ int usb_add_phy(struct usb_phy *x, enum usb_phy_type type)
unsigned long   flags;
struct usb_phy  *phy;
 
-   if (x && x->type != USB_PHY_TYPE_UNDEFINED) {
+   if (x->type != USB_PHY_TYPE_UNDEFINED) {
dev_err(x->dev, "not accepting initialized PHY %s\n", x->label);
return -EINVAL;
}
-- 
1.7.5.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 RFC] usb: musb: Make dma_controller_create __devinit

[Shubhrajyoti D]

dma_controller_create is called only from musb_init_controller
which is __devint so annotate dma_controller_create also with
__devint.

fixes the warn

WARNING: vmlinux.o(.devinit.text+0x6fa8): Section mismatch in reference from 
the function musb_init_controller() to the function 
.init.text:dma_controller_create()
The function __devinit musb_init_controller() references
a function __init dma_controller_create().
If dma_controller_create is only used by musb_init_controller then
annotate dma_controller_create with a matching annotation.

Signed-off-by: Shubhrajyoti D 
---
 drivers/usb/musb/cppi_dma.c  |2 +-
 drivers/usb/musb/musb_core.c |1 +
 drivers/usb/musb/musb_dma.h  |2 +-
 drivers/usb/musb/musbhsdma.c |2 +-
 drivers/usb/musb/tusb6010_omap.c |2 +-
 drivers/usb/musb/ux500_dma.c |2 +-
 6 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/musb/cppi_dma.c b/drivers/usb/musb/cppi_dma.c
index 8637c1f..e19da82 100644
--- a/drivers/usb/musb/cppi_dma.c
+++ b/drivers/usb/musb/cppi_dma.c
@@ -1316,7 +1316,7 @@ irqreturn_t cppi_interrupt(int irq, void *dev_id)
 }
 
 /* Instantiate a software object representing a DMA controller. */
-struct dma_controller *__init
+struct dma_controller *__devinit
 dma_controller_create(struct musb *musb, void __iomem *mregs)
 {
struct cppi *controller;
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 26f1bef..5760de9 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2066,6 +2066,7 @@ fail5:
musb_exit_debugfs(musb);
 
 fail4:
+   free_irq(musb->nIrq, musb);
if (!is_otg_enabled(musb) && is_host_enabled(musb))
usb_remove_hcd(musb_to_hcd(musb));
else
diff --git a/drivers/usb/musb/musb_dma.h b/drivers/usb/musb/musb_dma.h
index 3a97c4e..24d3921 100644
--- a/drivers/usb/musb/musb_dma.h
+++ b/drivers/usb/musb/musb_dma.h
@@ -178,7 +178,7 @@ struct dma_controller {
 extern void musb_dma_completion(struct musb *musb, u8 epnum, u8 transmit);
 
 
-extern struct dma_controller *__init
+extern struct dma_controller *__devinit
 dma_controller_create(struct musb *, void __iomem *);
 
 extern void dma_controller_destroy(struct dma_controller *);
diff --git a/drivers/usb/musb/musbhsdma.c b/drivers/usb/musb/musbhsdma.c
index 57a6085..444b9ee 100644
--- a/drivers/usb/musb/musbhsdma.c
+++ b/drivers/usb/musb/musbhsdma.c
@@ -380,7 +380,7 @@ void dma_controller_destroy(struct dma_controller *c)
kfree(controller);
 }
 
-struct dma_controller *__init
+struct dma_controller *__devinit
 dma_controller_create(struct musb *musb, void __iomem *base)
 {
struct musb_dma_controller *controller;
diff --git a/drivers/usb/musb/tusb6010_omap.c b/drivers/usb/musb/tusb6010_omap.c
index b67b4bc..53e2596 100644
--- a/drivers/usb/musb/tusb6010_omap.c
+++ b/drivers/usb/musb/tusb6010_omap.c
@@ -662,7 +662,7 @@ void dma_controller_destroy(struct dma_controller *c)
kfree(tusb_dma);
 }
 
-struct dma_controller *__init
+struct dma_controller *__devinit
 dma_controller_create(struct musb *musb, void __iomem *base)
 {
void __iomem*tbase = musb->ctrl_base;
diff --git a/drivers/usb/musb/ux500_dma.c b/drivers/usb/musb/ux500_dma.c
index d05c7fb..639d58e 100644
--- a/drivers/usb/musb/ux500_dma.c
+++ b/drivers/usb/musb/ux500_dma.c
@@ -364,7 +364,7 @@ void dma_controller_destroy(struct dma_controller *c)
kfree(controller);
 }
 
-struct dma_controller *__init
+struct dma_controller *__devinit
 dma_controller_create(struct musb *musb, void __iomem *base)
 {
struct ux500_dma_controller *controller;
-- 
1.7.5.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: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework

[Laurent Pinchart]

Hi Bhupesh,

Thank you for the patch.

On Tuesday 31 July 2012 06:24:51 Bhupesh Sharma wrote:
> This patch reworks the videobuffer management logic present in the UVC
> webcam gadget and ports it to use the "more apt" videobuf2 framework for
> video buffer management.
> 
> To support routing video data captured from a real V4L2 video capture
> device with a "zero copy" operation on videobuffers (as they pass from
> the V4L2 domain to UVC domain via a user-space application), we need to
> support USER_PTR IO method at the UVC gadget side.
> 
> So the V4L2 capture device driver can still continue to use MMAP IO
> method and now the user-space application can just pass a pointer to the
> video buffers being dequeued from the V4L2 device side while queueing them
> at the UVC gadget end. This ensures that we have a "zero-copy" design as
> the videobuffers pass from the V4L2 capture device to the UVC gadget.
> 
> Note that there will still be a need to apply UVC specific payload
> headers on top of each UVC payload data, which will still require a copy
> operation to be performed in the 'encode' routines of the UVC gadget.
> 
> This patch also addresses two issues found out while porting the UVC
> gadget to videobuf2 framework:
>   - In case the usb requests queued by the gadget get completed
> with a status of -ESHUTDOWN (disconnected from host), the
> queue of videobuf2 should be cancelled to ensure that the
> application space daemon is not left in a state waiting for
> a vb2 to be successfully absorbed at the USB side.
> 
>   - In case the underlying UDC has already returned -ESHUTDOWN
> as status of a queued request, it means that the video
> streaming endpoint is going to be disabled and hence the
> underlying UDC will giveback all queued requests with a status
> of -ESHUTDOWN. In such a case, the requests are not longer
> queued at the UDC end and it doesn't make sense to dequeue
> them again in uvc_video_enable(0).
> 
> Signed-off-by: Bhupesh Sharma 
> ---
>  drivers/usb/gadget/uvc_queue.c |  531 -
>  drivers/usb/gadget/uvc_queue.h |   25 +--
>  drivers/usb/gadget/uvc_v4l2.c  |   27 +--
>  drivers/usb/gadget/uvc_video.c |   28 ++-
>  4 files changed, 190 insertions(+), 421 deletions(-)

Shouldn't you select VIDEOBUF2_VMALLOC in Kconfig ? That was done in v1 but 
you seem to have dropped it here.

> diff --git a/drivers/usb/gadget/uvc_queue.c b/drivers/usb/gadget/uvc_queue.c
> index 104ae9c..bf6621b 100644
> --- a/drivers/usb/gadget/uvc_queue.c
> +++ b/drivers/usb/gadget/uvc_queue.c

[snip]

> @@ -484,9 +243,10 @@ static void uvc_queue_cancel(struct uvc_video_queue
> *queue, int disconnect) queue);
>   list_del(&buf->queue);
>   buf->state = UVC_BUF_STATE_ERROR;
> - wake_up(&buf->wait);
> + vb2_buffer_done(&buf->buf, VB2_BUF_STATE_ERROR);
>   }
> - /* This must be protected by the irqlock spinlock to avoid race
> + /*
> +  * This must be protected by the irqlock spinlock to avoid race
>* conditions between uvc_queue_buffer and the disconnection event that
>* could result in an interruptible wait in uvc_dequeue_buffer. Do not
>* blindly replace this logic by checking for the UVC_DEV_DISCONNECTED
> @@ -516,26 +276,34 @@ static void uvc_queue_cancel(struct uvc_video_queue
> *queue, int disconnect) */
>  static int uvc_queue_enable(struct uvc_video_queue *queue, int enable)
>  {
> - unsigned int i;
> + unsigned long flags;
>   int ret = 0;
> 
>   mutex_lock(&queue->mutex);
>   if (enable) {
> - if (uvc_queue_streaming(queue)) {
> - ret = -EBUSY;
> + ret = vb2_streamon(&queue->queue, queue->queue.type);
> + if (ret < 0)
>   goto done;
> - }
> - queue->sequence = 0;
> - queue->flags |= UVC_QUEUE_STREAMING;
> +
>   queue->buf_used = 0;
>   } else {
> - uvc_queue_cancel(queue, 0);
> - INIT_LIST_HEAD(&queue->mainqueue);
> + ret = vb2_streamoff(&queue->queue, queue->queue.type);
> + if (ret < 0)
> + goto done;
> +
> + spin_lock_irqsave(&queue->irqlock, flags);
> +
> + INIT_LIST_HEAD(&queue->irqqueue);
> 
> - for (i = 0; i < queue->count; ++i)
> - queue->buffer[i].state = UVC_BUF_STATE_IDLE;
> + /*
> +  * as the uvc queue is being disabled, clear any
> +  * DISCONNECTED flag which was set earlier, so that the
> +  * next qbuf from userspace does not fail with ENODEV.
> +  */

Please start the comment with a capital letter, spell UVC in capital, and fill 
the space up to 80 columns.

> + if (queue->flags & UVC_QUEUE_DISCONNECTED)
> + queue->flags &= ~U

RE: [PATCH V2 1/2] usb: gadget/uvc: Port UVC webcam gadget to use videobuf2 framework

[Bhupesh SHARMA]

Hi Laurent,

Thanks for your review.

> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
> Sent: Tuesday, August 07, 2012 8:23 PM
> To: Bhupesh SHARMA
> Cc: linux-usb@vger.kernel.org; ba...@ti.com
> Subject: Re: [PATCH V2 1/2] usb: gadget/uvc: Port UVC webcam gadget to
> use videobuf2 framework
> 
> Hi Bhupesh,
> 
> Thank you for the patch.
> 
> On Tuesday 31 July 2012 06:24:51 Bhupesh Sharma wrote:
> > This patch reworks the videobuffer management logic present in the
> UVC
> > webcam gadget and ports it to use the "more apt" videobuf2 framework
> for
> > video buffer management.
> >
> > To support routing video data captured from a real V4L2 video capture
> > device with a "zero copy" operation on videobuffers (as they pass
> from
> > the V4L2 domain to UVC domain via a user-space application), we need
> to
> > support USER_PTR IO method at the UVC gadget side.
> >
> > So the V4L2 capture device driver can still continue to use MMAP IO
> > method and now the user-space application can just pass a pointer to
> the
> > video buffers being dequeued from the V4L2 device side while queueing
> them
> > at the UVC gadget end. This ensures that we have a "zero-copy" design
> as
> > the videobuffers pass from the V4L2 capture device to the UVC gadget.
> >
> > Note that there will still be a need to apply UVC specific payload
> > headers on top of each UVC payload data, which will still require a
> copy
> > operation to be performed in the 'encode' routines of the UVC gadget.
> >
> > This patch also addresses two issues found out while porting the UVC
> > gadget to videobuf2 framework:
> > - In case the usb requests queued by the gadget get completed
> >   with a status of -ESHUTDOWN (disconnected from host), the
> >   queue of videobuf2 should be cancelled to ensure that the
> >   application space daemon is not left in a state waiting for
> >   a vb2 to be successfully absorbed at the USB side.
> >
> > - In case the underlying UDC has already returned -ESHUTDOWN
> >   as status of a queued request, it means that the video
> >   streaming endpoint is going to be disabled and hence the
> >   underlying UDC will giveback all queued requests with a status
> >   of -ESHUTDOWN. In such a case, the requests are not longer
> >   queued at the UDC end and it doesn't make sense to dequeue
> >   them again in uvc_video_enable(0).
> >
> > Signed-off-by: Bhupesh Sharma 
> > ---
> >  drivers/usb/gadget/uvc_queue.c |  531 --
> ---
> >  drivers/usb/gadget/uvc_queue.h |   25 +--
> >  drivers/usb/gadget/uvc_v4l2.c  |   27 +--
> >  drivers/usb/gadget/uvc_video.c |   28 ++-
> >  4 files changed, 190 insertions(+), 421 deletions(-)
> 
> Shouldn't you select VIDEOBUF2_VMALLOC in Kconfig ? That was done in v1
> but
> you seem to have dropped it here.

Oops. My Bad. Will add this in V3.
 
> > diff --git a/drivers/usb/gadget/uvc_queue.c
> b/drivers/usb/gadget/uvc_queue.c
> > index 104ae9c..bf6621b 100644
> > --- a/drivers/usb/gadget/uvc_queue.c
> > +++ b/drivers/usb/gadget/uvc_queue.c
> 
> [snip]
> 
> > @@ -484,9 +243,10 @@ static void uvc_queue_cancel(struct
> uvc_video_queue
> > *queue, int disconnect) queue);
> > list_del(&buf->queue);
> > buf->state = UVC_BUF_STATE_ERROR;
> > -   wake_up(&buf->wait);
> > +   vb2_buffer_done(&buf->buf, VB2_BUF_STATE_ERROR);
> > }
> > -   /* This must be protected by the irqlock spinlock to avoid race
> > +   /*
> > +* This must be protected by the irqlock spinlock to avoid race
> >  * conditions between uvc_queue_buffer and the disconnection
> event that
> >  * could result in an interruptible wait in uvc_dequeue_buffer.
> Do not
> >  * blindly replace this logic by checking for the
> UVC_DEV_DISCONNECTED
> > @@ -516,26 +276,34 @@ static void uvc_queue_cancel(struct
> uvc_video_queue
> > *queue, int disconnect) */
> >  static int uvc_queue_enable(struct uvc_video_queue *queue, int
> enable)
> >  {
> > -   unsigned int i;
> > +   unsigned long flags;
> > int ret = 0;
> >
> > mutex_lock(&queue->mutex);
> > if (enable) {
> > -   if (uvc_queue_streaming(queue)) {
> > -   ret = -EBUSY;
> > +   ret = vb2_streamon(&queue->queue, queue->queue.type);
> > +   if (ret < 0)
> > goto done;
> > -   }
> > -   queue->sequence = 0;
> > -   queue->flags |= UVC_QUEUE_STREAMING;
> > +
> > queue->buf_used = 0;
> > } else {
> > -   uvc_queue_cancel(queue, 0);
> > -   INIT_LIST_HEAD(&queue->mainqueue);
> > +   ret = vb2_streamoff(&queue->queue, queue->queue.type);
> > +   if (ret < 0)
> > +   goto done;
> > +
> > +   spin_lock_irqsave(&queue->irqlock, flags);
> > +
> > +   INIT_LIST_HEAD(&queue->irqqueue);
> >
> > -   for (i = 0; i < queue->count; ++i)
> > -  

Re: Do we need asynchronous pm_runtime_get()? (was: Re: bisected regression ...)

[Ming Lei]

On Tue, Aug 7, 2012 at 7:23 PM, Rafael J. Wysocki  wrote:
>> Yes, I agree, but I don't think it may make .runtime_post_resume
>> not doable, do I?
>
> No more device PM callbacks, please.

IMO, what the patch is doing is to introduce one callback which
is just called after .runtime_resume is completed, and you want
to move something out of previous .runtime_resume and do it
in another new callback to speedup resume, so it should be
reasonable to introduce the .runtime_post_resume callback in logic.

Also, the 'func' should be per driver, not per device since only one
'func' is enough for all same kind of devices driven by one same
driver.

> Besides, callbacks in struct dev_pm_ops are not only for drivers.

All the current 3 runtime callbacks are for devices. If you mean
they can be defined in bus/power_domain/device_type, .runtime_post_resume
still can be defined there too.

>
>> > Also, "func" should not be stored in dev_pm_ops because it won't be a
>> > read-only value.
>>
>> Sorry, could you explain it in detail that why the 'func'
>> has to switch to multiple functions dynamically? I understand
>> one function is enough and sometimes it can be bypassed with
>> one flag(such as, ignore_post_resume is introduced in dev_pm_info)
>> set.  Also, the driver can store the device specific states
>> in its own device instance to deal with different situations in the callback.
>>
>> If the idea is doable, we can save one pointer in 'struct device',
>> since the 'func' may not be used by more than 90% devices, also
>> have document benefit, even may simplify implementation of the
>> mechanism.
>
> And how many struct device objects there are for the one extra pointer to
> matter, let alone the fact that you want to replace it by one extra pointer
> somewhere else?

For example, in the pandaboard(one omap4 based small system), follows
the count of device instances:

 [root@root]#dmesg | grep device_add | wc -l
471

The above is just a simple configuration(no graphics, no video/video, only
console enabled) on Pandaboard.

If the callback may be defined in dev_pm_info, not only memory can be saved,
also there are other advantages described before.


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: Do we need asynchronous pm_runtime_get()? (was: Re: bisected regression ...)

[Alan Stern]

On Tue, 7 Aug 2012, Ming Lei wrote:

> On Tue, Aug 7, 2012 at 7:23 PM, Rafael J. Wysocki  wrote:
> >> Yes, I agree, but I don't think it may make .runtime_post_resume
> >> not doable, do I?
> >
> > No more device PM callbacks, please.
> 
> IMO, what the patch is doing is to introduce one callback which
> is just called after .runtime_resume is completed, and you want
> to move something out of previous .runtime_resume and do it
> in another new callback to speedup resume, so it should be
> reasonable to introduce the .runtime_post_resume callback in logic.

No, that's really not what the patch is doing.

The idea behind the new API is that "func" will be called as soon as we
know the device is at full power.  That could be after the next runtime
resume or it could be right away.  This is a one-time call; it should
not be made _every_ time the device resumes.

> Also, the 'func' should be per driver, not per device since only one
> 'func' is enough for all same kind of devices driven by one same
> driver.

But what if the subsystem defines its own dev_pm_info structure?  Then
the driver's dev_pm_info will be ignored by the runtime PM core.  All
the subsystems would have to be changed.

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: host: xhci: sparse fixes

[Sarah Sharp]

Thanks Felipe!  I'll send it off to Greg today.

Sarah Sharp

On Tue, Aug 07, 2012 at 02:10:03PM +0300, Felipe Balbi wrote:
> drivers/usb/host/xhci.c:1826:14: warning: symbol 'xhci_get_block_size' was 
> not declared. Should it be static?
> drivers/usb/host/xhci.c:1844:14: warning: symbol 'xhci_get_largest_overhead' 
> was not declared. Should it be static?
> drivers/usb/host/xhci-ring.c:2304:36: warning: context imbalance in 
> 'handle_tx_event' - unexpected unlock
> drivers/usb/host/xhci-hub.c:425:6: warning: symbol 
> 'xhci_set_remote_wake_mask' was not declared. Should it be static?
> 
> Signed-off-by: Felipe Balbi 
> ---
>  drivers/usb/host/xhci-hub.c  | 2 +-
>  drivers/usb/host/xhci-ring.c | 2 ++
>  drivers/usb/host/xhci.c  | 5 +++--
>  3 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
> index 74bfc86..5575402 100644
> --- a/drivers/usb/host/xhci-hub.c
> +++ b/drivers/usb/host/xhci-hub.c
> @@ -422,7 +422,7 @@ void xhci_set_link_state(struct xhci_hcd *xhci, __le32 
> __iomem **port_array,
>   xhci_writel(xhci, temp, port_array[port_id]);
>  }
>  
> -void xhci_set_remote_wake_mask(struct xhci_hcd *xhci,
> +static void xhci_set_remote_wake_mask(struct xhci_hcd *xhci,
>   __le32 __iomem **port_array, int port_id, u16 wake_mask)
>  {
>   u32 temp;
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index 8275645..3bc1224 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -1995,6 +1995,8 @@ static int process_bulk_intr_td(struct xhci_hcd *xhci, 
> struct xhci_td *td,
>   */
>  static int handle_tx_event(struct xhci_hcd *xhci,
>   struct xhci_transfer_event *event)
> + __releases(&xhci->lock)
> + __acquires(&xhci->lock)
>  {
>   struct xhci_virt_device *xdev;
>   struct xhci_virt_ep *ep;
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 7648b2d..081c49e 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -1823,7 +1823,7 @@ static void xhci_finish_resource_reservation(struct 
> xhci_hcd *xhci,
>   xhci->num_active_eps);
>  }
>  
> -unsigned int xhci_get_block_size(struct usb_device *udev)
> +static unsigned int xhci_get_block_size(struct usb_device *udev)
>  {
>   switch (udev->speed) {
>   case USB_SPEED_LOW:
> @@ -1841,7 +1841,8 @@ unsigned int xhci_get_block_size(struct usb_device 
> *udev)
>   }
>  }
>  
> -unsigned int xhci_get_largest_overhead(struct xhci_interval_bw *interval_bw)
> +static unsigned int
> +xhci_get_largest_overhead(struct xhci_interval_bw *interval_bw)
>  {
>   if (interval_bw->overhead[LS_OVERHEAD_TYPE])
>   return LS_OVERHEAD;
> -- 
> 1.7.12.rc0
> 
--
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: gadget: use native print_hex_dump_bytes()

[Andy Shevchenko]

Signed-off-by: Andy Shevchenko 
---
 drivers/usb/gadget/rndis.c |   22 ++
 1 file changed, 2 insertions(+), 20 deletions(-)

diff --git a/drivers/usb/gadget/rndis.c b/drivers/usb/gadget/rndis.c
index b35babe..e4192b8 100644
--- a/drivers/usb/gadget/rndis.c
+++ b/drivers/usb/gadget/rndis.c
@@ -863,26 +863,8 @@ int rndis_msg_parser(u8 configNr, u8 *buf)
 */
pr_warning("%s: unknown RNDIS message 0x%08X len %d\n",
__func__, MsgType, MsgLength);
-   {
-   unsigned i;
-   for (i = 0; i < MsgLength; i += 16) {
-   pr_debug("%03d: "
-   " %02x %02x %02x %02x"
-   " %02x %02x %02x %02x"
-   " %02x %02x %02x %02x"
-   " %02x %02x %02x %02x"
-   "\n",
-   i,
-   buf[i], buf [i+1],
-   buf[i+2], buf[i+3],
-   buf[i+4], buf [i+5],
-   buf[i+6], buf[i+7],
-   buf[i+8], buf [i+9],
-   buf[i+10], buf[i+11],
-   buf[i+12], buf [i+13],
-   buf[i+14], buf[i+15]);
-   }
-   }
+   print_hex_dump_bytes(__func__, DUMP_PREFIX_OFFSET,
+buf, MsgLength);
break;
}
 
-- 
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: Do we need asynchronous pm_runtime_get()? (was: Re: bisected regression ...)

[Ming Lei]

On Tue, Aug 7, 2012 at 11:42 PM, Alan Stern  wrote:
>
> No, that's really not what the patch is doing.
>
> The idea behind the new API is that "func" will be called as soon as we
> know the device is at full power.  That could be after the next runtime
> resume or it could be right away.  This is a one-time call; it should

IMO, in the both two cases, the 'func' should be very similar with
.runtime_post_resume from view of the caller because the caller
don't know what the power state of the device is now, so they may
always think the 'func' should do something similar done in
.runtime_post_resume.

Also .runtime_post_resume always knows the device's power state
is active, which is same with 'func'. In fact, it doesn't matter if the active
state is the 1st time or other times, does it?

> not be made _every_ time the device resumes.

Suppose the device is always resumed in the path(such as irq context),
the callback is still called every time.

If the .runtime_post_resume is to be a one-time call, that is easy to do it.
Also I am wondering why the callback shouldn't be called after resume
in sync context, and it may simplify implementation if the two contexts
(sync vs. async) are kept consistent.

>
>> Also, the 'func' should be per driver, not per device since only one
>> 'func' is enough for all same kind of devices driven by one same
>> driver.
>
> But what if the subsystem defines its own dev_pm_info structure?  Then
> the driver's dev_pm_info will be ignored by the runtime PM core.  All
> the subsystems would have to be changed.

Suppose .runtime_post_resume is introduced, the priority of
dev_pm_info for .runtime_post_resume callback can be changed to
adapt to the situation.


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: [BUG] Kernel panic when try s3c-hsotg.c with kernel 3.5

[Mark Brown]

On Mon, Aug 06, 2012 at 03:14:36PM +0200, Lukasz Majewski wrote:
> > On Mon, Aug 06, 2012 at 06:12:05PM +0800, Peiyong Feng wrote:
> > > I got a kernel panic when try hsotg of ok6410 which is based on
> > > s3c6410:

> As you said, you are using the ok6410. And it is "based" on the s3c6410
> CPU. S3C6410 is a single core CPU. I assume that ok6410 is also single
> core?

FWIW I think what the above means is "I am using the ok6410 board which
has a s3c6410 SoC on it".
--
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/2] usb: musb: use DMA mode 1 whenever possible

[Sergei Shtylyov]

Hello.

On 08/07/2012 05:09 PM, Roger Quadros wrote:

> Do not rely on any hints from gadget drivers and use DMA mode 1
> whenever we expect data of at least the endpoint's packet size and
> have not yet received a short packet.

> The last packet if short is always transferred using DMA mode 0.

> This patch fixes USB throughput issues in mass storage mode for
> host to device transfers.

> Signed-off-by: Roger Quadros 
> ---
>  drivers/usb/musb/musb_gadget.c |   30 --
>  1 files changed, 4 insertions(+), 26 deletions(-)

> diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
> index 8d2cce1..5c4392b 100644
> --- a/drivers/usb/musb/musb_gadget.c
> +++ b/drivers/usb/musb/musb_gadget.c
> @@ -707,12 +707,11 @@ static void rxstate(struct musb *musb, struct 
> musb_request *req)
>   fifo_count = musb_readw(epio, MUSB_RXCOUNT);
>  
>   /*
> -  * Enable Mode 1 on RX transfers only when short_not_ok flag
> -  * is set. Currently short_not_ok flag is set only from
> -  * file_storage and f_mass_storage drivers
> +  *  use mode 1 only if we expect data of at least ep packet_sz
> +  *  and have not yet received a short packet

   Why offset the comment text with 2 spaces?

>*/
> -
> - if (request->short_not_ok && fifo_count == musb_ep->packet_sz)
> + if ((request->length - request->actual >= musb_ep->packet_sz) &&
> + (fifo_count >= musb_ep->packet_sz))

   'fifo_count' shouldn't ever be > packet size (unless there's babble error??).

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 2/2] usb: musb: Remove redundant if statement

[Sergei Shtylyov]

Hello.

On 08/07/2012 05:09 PM, Roger Quadros wrote:

> Signed-off-by: Roger Quadros 
> ---
>  drivers/usb/musb/musb_gadget.c |   34 +++---
>  1 files changed, 15 insertions(+), 19 deletions(-)

> diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
> index 5c4392b..2bb50ca 100644
> --- a/drivers/usb/musb/musb_gadget.c
> +++ b/drivers/usb/musb/musb_gadget.c
[...]
> @@ -742,35 +743,30 @@ static void rxstate(struct musb *musb, struct 
> musb_request *req)
[...]
> + use_dma = c->channel_program(
> + channel,
> + musb_ep->packet_sz,
> + channel->desired_mode,
> + request->dma
> + + request->actual,

   There's enought space on the line to not break this expression.

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: Do we need asynchronous pm_runtime_get()? (was: Re: bisected regression ...)

[Alan Stern]

On Tue, 7 Aug 2012, Rafael J. Wysocki wrote:

> > > All those changes (and some of the following ones) are symptoms of a
> > > basic mistake in this approach.
> > 
> > Every time you say something like this (i.e. liks someone who knows better)
> 
> s/liks/like/
> 
> > I kind of feel like being under attach, which I hope is not your intention.
> 
> s/attach/attack/

Sorry; you're right.  It's all too easy to get very arrogant in email 
messages.  I'll try not to attack so strongly in the future.

> > > The idea of this new feature is to
> > > call "func" as soon as we know the device is at full power, no matter
> > > how it got there.
> > 
> > Yes, it is so.

Incidentally, that sentence is the justification for the invariance
condition mentioned later.  power.func should be called as soon as we
know the device is at full power; therefore when the status changes to
RPM_ACTIVE it should be called and then cleared (if it was set), and it
should never get set while the status is RPM_ACTIVE.  Therefore it
should never be true that power.func is set _and_ the status is
RPM_ACTIVE.

> > > That means we should call it near the end of
> > > rpm_resume() (just before the rpm_idle() call), not from within
> > > pm_runtime_work().
> > > 
> > > Doing it this way will be more efficient and (I think) will remove
> > > some races.
> > 
> > Except that func() shouldn't be executed under dev->power.lock, which makes 
> > it
> > rather difficult to call it from rpm_resume().  Or at least it seems so.
> > 
> > Moreover, it should be called after we've changed the status to RPM_ACTIVE
> > _and_ dropped the lock.
> 
> So we could drop the lock right before returning, execute func() and acquire
> the lock once again,

Yes; that's what I had in mind.  We already do something similar when 
calling pm_runtime_put(parent).

>  but then func() might be executed by any thread that
> happened to resume the device.  In that case the caller of
> pm_runtime_get_and_call() would have to worry about locks that such threads
> might acquire and it would have to make sure that func() didn't try to acquire
> them too.  That may not be a big deal, but if func() is executed by
> pm_runtime_work(), that issue simply goes away.

But then you have to worry about races between pm_runtime_resume() and
the workqueue.  If the device is resumed by some other thread, it
could be suspended again before "func" is called.

> Then, however, there's another issue: what should happen if
> pm_runtime_get_and_call() finds that it cannot execute func() right away,
> so it queues up resume and the execution of it, in the meantime some other
> thread resumes the device synchronously and pm_runtime_get_and_call() is
> run again.  I think in that case func() should be executed synchronously
> and the one waiting for execution should be canceled.  The alternative
> would be to return -EAGAIN from pm_runtime_get_and_call() and expect the
> caller to cope with that, which isn't too attractive.
> 
> This actually is analogous to the case when pm_runtime_get_and_call()
> sees that power.func is not NULL.  In my experimental patches it returned
> -EAGAIN in that case, but perhaps it's better to replace the existing
> power.func with the new one.  Then, by doing pm_runtime_get_and_call(dev, 
> NULL)
> we can ensure that either the previous func() has run already or it will never
> run, which may be useful.

A good point.  I agree that pm_runtime_get_and_call() should always 
overwrite the existing power.func value.

There are a couple of other issues remaining.

What's the best approach when disable_count > 0?  My feeling is that we
should still rely on power.runtime_status as the best approximation to
the device's state, so we shouldn't call "func" directly unless the
status is already RPM_ACTIVE.  If the status is something else, we
can't queue an async resume request.  So we just set power.func and
return.  Eventually the driver will either call pm_runtime_set_active()
or pm_runtime_enable() followed by pm_runtime_resume(), at which time
we would call power.func.

Also, what should happen when power.runtime_error is set?  The same as
when disable_depth > 0?

You mentioned that pm_runtime_disable() does a resume if there's a 
pending resume request.  I had forgotten about this.  It worries me, 
because subsystems use code sequences like this:

pm_runtime_disable(dev);
pm_runtime_set_active(dev);
pm_runtime_enable(dev);

in their system resume routines (in fact, we advise them to do so in
the Documentation file).  Now, it is unlikely for a resume request to
be pending during system sleep, but it doesn't seem to be impossible.  
When there is such a pending request, the pm_runtime_disable() call
will try to do a runtime resume at a time when the device has just been
restored to full power.  That's not good.

Probably this pattern occurs in few enough places that we could go
through and fix them all.  But how?  Should there be a new function:
pm_adjust_

Re: [PATCH] usb: host: mips: sead3: Update for EHCI register structure.

[Alan Stern]

On Mon, 6 Aug 2012, Steven J. Hill wrote:

> From: "Steven J. Hill" 
> 
> One line fix after 'struct ehci_regs' definition was changed
> in commit a46af4ebf9ffec35eea0390e89935197b833dc61.
> 
> Signed-off-by: Steven J. Hill 
> ---
>  drivers/usb/host/ehci-sead3.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/host/ehci-sead3.c b/drivers/usb/host/ehci-sead3.c
> index 58c96bd..0c9e43c 100644
> --- a/drivers/usb/host/ehci-sead3.c
> +++ b/drivers/usb/host/ehci-sead3.c
> @@ -40,7 +40,7 @@ static int ehci_sead3_setup(struct usb_hcd *hcd)
>   ehci->need_io_watchdog = 0;
>  
>   /* Set burst length to 16 words. */
> - ehci_writel(ehci, 0x1010, &ehci->regs->reserved[1]);
> + ehci_writel(ehci, 0x1010, &ehci->regs->reserved1[1]);
>  
>   return ret;
>  }

Acked-by: Alan Stern 

I never thought to check if any of the platform drivers were actually 
using these reserved memory addresses.

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: gadget: use native print_hex_dump_bytes()

[Michal Nazarewicz]

Andy Shevchenko  writes:

> Signed-off-by: Andy Shevchenko 

Obviously.

Acked-by: Michal Nazarewicz 

In addition, it also adds ACSII print out. :)

> ---
>  drivers/usb/gadget/rndis.c |   22 ++
>  1 file changed, 2 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/usb/gadget/rndis.c b/drivers/usb/gadget/rndis.c
> index b35babe..e4192b8 100644
> --- a/drivers/usb/gadget/rndis.c
> +++ b/drivers/usb/gadget/rndis.c
> @@ -863,26 +863,8 @@ int rndis_msg_parser(u8 configNr, u8 *buf)
>*/
>   pr_warning("%s: unknown RNDIS message 0x%08X len %d\n",
>   __func__, MsgType, MsgLength);
> - {
> - unsigned i;
> - for (i = 0; i < MsgLength; i += 16) {
> - pr_debug("%03d: "
> - " %02x %02x %02x %02x"
> - " %02x %02x %02x %02x"
> - " %02x %02x %02x %02x"
> - " %02x %02x %02x %02x"
> - "\n",
> - i,
> - buf[i], buf [i+1],
> - buf[i+2], buf[i+3],
> - buf[i+4], buf [i+5],
> - buf[i+6], buf[i+7],
> - buf[i+8], buf [i+9],
> - buf[i+10], buf[i+11],
> - buf[i+12], buf [i+13],
> - buf[i+14], buf[i+15]);
> - }
> - }
> + print_hex_dump_bytes(__func__, DUMP_PREFIX_OFFSET,
> +  buf, MsgLength);
>   break;
>   }

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--

pgpIIMEtWAhZt.pgp
Description: PGP signature

Re: [RFC][PATCH 4/4] usb: host: ohci-platform: add platform specific power callback

[Alan Stern]

On Mon, 6 Aug 2012, Kuninori Morimoto wrote:

> This patch enables to call platform specific power callback function.
> 
> Signed-off-by: Kuninori Morimoto 

For all four patches in this series:

Acked-by: 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 2/2] xhci: EHCI/XHCI ports switching on Intense-PC.

[Sarah Sharp]

Hi Denis,

I found a couple issues with your second patch.  There are non-PCI xHCI
host controllers, so we can't assume the xHCI host is a PCI host.  So
this code can't run in the generic xHCI shutdown method:

>  void xhci_shutdown(struct usb_hcd *hcd)
>  {
> + struct pci_dev *pdev;
> + const char *brd_name;
>   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> 
> + pdev = to_pci_dev(hcd->self.controller);
> +
> + if (usb_is_intel_switchable_xhci(pdev)) {
> + brd_name = dmi_get_system_info(DMI_BOARD_NAME);
> +
> + /* quirk for Compulab's Intense-PC board */
> + if (brd_name && strstr(brd_name, "Intense-PC"))
> + usb_disable_xhci_ports(pdev);
> + }
> +
>   spin_lock_irq(&xhci->lock);
>   xhci_halt(xhci);
>   spin_unlock_irq(&xhci->lock);

I think the to_pci_dev call will oops if this isn't a PCI host.  Plus,
I've found out from the BIOS and chipset folks that this quirk needs to
be more broadly applied.  I'll send you a revised patch.  Can you test
it and make sure it works for you?

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: Switch PPT ports to EHCI on shutdown.

[Sarah Sharp]

The Intel desktop boards DH77EB and DH77DF have a hardware issue that
can be worked around by BIOS.  If the USB ports are switched to xHCI on
shutdown, the xHCI host will send a spurious interrupt, which will wake
the system.  Some BIOS will work around this, but not all.

The bug can be avoided if the USB ports are switched back to EHCI on
shutdown.  The Intel Windows driver switches the ports back to EHCI, so
change the Linux xHCI driver to do the same.

Unfortunately, we can't tell the two effected boards apart from other
working motherboards, because the vendors will change the DMI strings
for the DH77EB and DH77DF boards to their own custom names.  One example
is Compulab's mini-desktop, the Intense-PC.  Instead, key off the
Panther Point xHCI host PCI vendor and device ID, and switch the ports
over for all PPT xHCI hosts.

The only impact this will have on non-effected boards is to add a couple
hundred milliseconds delay on boot when the BIOS has to switch the ports
over from EHCI to xHCI.

This patch should be backported to kernels as old as 3.0, that contain
the commit 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support
EHCI/xHCI port switching."

Signed-off-by: Sarah Sharp 
Reported-by: Denis Turischev 
Cc: sta...@vger.kernel.org
---
 drivers/usb/host/pci-quirks.c |7 +++
 drivers/usb/host/pci-quirks.h |1 +
 drivers/usb/host/xhci-pci.c   |9 +
 drivers/usb/host/xhci.c   |3 +++
 drivers/usb/host/xhci.h   |1 +
 5 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index df0828c..c5e9e4a 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -800,6 +800,13 @@ void usb_enable_xhci_ports(struct pci_dev *xhci_pdev)
 }
 EXPORT_SYMBOL_GPL(usb_enable_xhci_ports);
 
+void usb_disable_xhci_ports(struct pci_dev *xhci_pdev)
+{
+   pci_write_config_dword(xhci_pdev, USB_INTEL_USB3_PSSEN, 0x0);
+   pci_write_config_dword(xhci_pdev, USB_INTEL_XUSB2PR, 0x0);
+}
+EXPORT_SYMBOL_GPL(usb_disable_xhci_ports);
+
 /**
  * PCI Quirks for xHCI.
  *
diff --git a/drivers/usb/host/pci-quirks.h b/drivers/usb/host/pci-quirks.h
index b1002a8..ef004a5 100644
--- a/drivers/usb/host/pci-quirks.h
+++ b/drivers/usb/host/pci-quirks.h
@@ -10,6 +10,7 @@ void usb_amd_quirk_pll_disable(void);
 void usb_amd_quirk_pll_enable(void);
 bool usb_is_intel_switchable_xhci(struct pci_dev *pdev);
 void usb_enable_xhci_ports(struct pci_dev *xhci_pdev);
+void usb_disable_xhci_ports(struct pci_dev *xhci_pdev);
 #else
 static inline void usb_amd_quirk_pll_disable(void) {}
 static inline void usb_amd_quirk_pll_enable(void) {}
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 92eaff6..9bfd4ca11 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -94,6 +94,15 @@ static void xhci_pci_quirks(struct device *dev, struct 
xhci_hcd *xhci)
xhci->quirks |= XHCI_EP_LIMIT_QUIRK;
xhci->limit_active_eps = 64;
xhci->quirks |= XHCI_SW_BW_CHECKING;
+   /*
+* PPT desktop boards DH77EB and DH77DF will power back on after
+* a few seconds of being shutdown.  The fix for this is to
+* switch the ports from xHCI to EHCI on shutdown.  We can't use
+* DMI information to find those particular boards (since each
+* vendor will change the board name), so we have to key off all
+* PPT chipsets.
+*/
+   xhci->quirks |= XHCI_SPURIOUS_REBOOT;
}
if (pdev->vendor == PCI_VENDOR_ID_ETRON &&
pdev->device == PCI_DEVICE_ID_ASROCK_P67) {
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 95394e5..81aa10c 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -659,6 +659,9 @@ void xhci_shutdown(struct usb_hcd *hcd)
 {
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
 
+   if (xhci->quirks && XHCI_SPURIOUS_REBOOT)
+   usb_disable_xhci_ports(to_pci_dev(hcd->self.controller));
+
spin_lock_irq(&xhci->lock);
xhci_halt(xhci);
spin_unlock_irq(&xhci->lock);
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 96f49db..c713256 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1494,6 +1494,7 @@ struct xhci_hcd {
 #define XHCI_TRUST_TX_LENGTH   (1 << 10)
 #define XHCI_LPM_SUPPORT   (1 << 11)
 #define XHCI_INTEL_HOST(1 << 12)
+#define XHCI_SPURIOUS_REBOOT   (1 << 13)
unsigned intnum_active_eps;
unsigned intlimit_active_eps;
/* There are two roothubs to keep track of bus suspend info for */
-- 
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 v2] usb:musb:musb_host: Handle highmem in PIO mode

[Alan Stern]

On Tue, 7 Aug 2012, Virupax Sadashivpetimath wrote:

> In case of USB bulk transfer, when himem page
> is received, the usb_sg_init function sets the
> urb transfer buffer to NULL. When such URB
> transfer is handled, kernel crashes in PIO mode.
> Handle this by mapping the highmem buffer in PIO mode.

...

> @@ -1332,9 +1353,38 @@ void musb_host_tx(struct musb *musb, u8 epnum)
>   length = qh->maxpacket;
>   /* Unmap the buffer so that CPU can use it */
>   usb_hcd_unmap_urb_for_dma(musb_to_hcd(musb), urb);
> - musb_write_fifo(hw_ep, length, urb->transfer_buffer + offset);
> +
> + /*
> +  * We need to map sg if the transfer_buffer is
> +  * NULL.
> +  */
> + if (!urb->transfer_buffer)
> + use_sg = true;

Here you test urb->transfer_buffer.

> + if (use_sg) {
> + /* sg_miter_start is already done in musb_ep_program */
> + if (!sg_miter_next(&qh->sg_miter)) {
> + dev_err(musb->controller, "error: sg list empty\n");
> + sg_miter_stop(&qh->sg_miter);
> + status = -EINVAL;
> + goto done;
> + }
> + urb->transfer_buffer = qh->sg_miter.addr;

And here you set it.  As a result, on the next iteration of this
routine the test above won't work right.  (This function gets invoked
once for each entry in the sg list, right?)

Is there any reason to set urb->transfer_buffer here?  You could just
use qh->sg_miter.addr directly in the musb_write_fifo() call two lines
below.

> + length = min_t(u32, length, qh->sg_miter.length);
> + musb_write_fifo(hw_ep, length, urb->transfer_buffer);
> + qh->sg_miter.consumed = length;
> + sg_miter_stop(&qh->sg_miter);
> + } else {
> + musb_write_fifo(hw_ep, length, urb->transfer_buffer + offset);
> + }

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: Backfilling USB-3 support into the 2.6.27.7 kernel

[Sarah Sharp]

On Tue, Aug 07, 2012 at 05:44:34PM +, Ian Atkin wrote:
> Hi,
> 
> Don't know if this is the right place to ask about USB 3 support and legacy 
> kernels, so apologies in advance if it is not. I have an ageing Linux 
> environment based on the OpenSuse 2.6.27.7 kernel. This environment is an OEM 
> environment which we occasionally have to back-fill support into (new AHCI 
> drivers for example[1])  to get new hardware supported.
> 
> The Intel xhCI (USB3) controller problem has now hit us with this 
> environment, and I'm unsure whether support can be added for this old kernel 
> is going to be possible. Upgrading the kernel will also take us out of OEM 
> support.
> 
> Does anyone have any pointers on what we can do here? If a kernel upgrade is 
> the only way to go, resulting in us falling out of OEM support, then so be 
> it. But before going down that route, I'd thought I'd ask...

It's going to be pretty hard to port all 1000+ xHCI patches to the
2.6.27 kernel.  I had to touch parts of the USB core as well as adding
the drivers, so can't just take the xHCI driver files alone.

I would strongly recommend you just upgrade your kernel.

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

Re: Backfilling USB-3 support into the 2.6.27.7 kernel

[Greg KH]

On Tue, Aug 07, 2012 at 10:49:00AM -0700, Sarah Sharp wrote:
> On Tue, Aug 07, 2012 at 05:44:34PM +, Ian Atkin wrote:
> > Hi,
> > 
> > Don't know if this is the right place to ask about USB 3 support and
> > legacy kernels, so apologies in advance if it is not. I have an
> > ageing Linux environment based on the OpenSuse 2.6.27.7 kernel. This
> > environment is an OEM environment which we occasionally have to
> > back-fill support into (new AHCI drivers for example[1])  to get new
> > hardware supported.
> > 
> > The Intel xhCI (USB3) controller problem has now hit us with this
> > environment, and I'm unsure whether support can be added for this
> > old kernel is going to be possible. Upgrading the kernel will also
> > take us out of OEM support.
> > 
> > Does anyone have any pointers on what we can do here? If a kernel
> > upgrade is the only way to go, resulting in us falling out of OEM
> > support, then so be it. But before going down that route, I'd
> > thought I'd ask...
> 
> It's going to be pretty hard to port all 1000+ xHCI patches to the
> 2.6.27 kernel.  I had to touch parts of the USB core as well as adding
> the drivers, so can't just take the xHCI driver files alone.
> 
> I would strongly recommend you just upgrade your kernel.

As someone who ended up doing the backport for USB3 to the 2.6.32 kernel
(an even newer one than 2.6.27), I completely agree with Sarah here.
It's a _very_ difficult task, and in the end, you have a kernel that no
one will support (company or community), and does not even work for some
corner cases.

Just upgrade to a newer kernel version, it's the only way to reliably
get this working properly.

And what OEM is based on an unsupported openSUSE kernel?  That seems
pretty crazy.

Good luck,

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: Backfilling USB-3 support into the 2.6.27.7 kernel

[Ian Atkin]

Hi Greg and Sarah,

First, thank you both for replying so promptly. I'm still here at work hunched 
over my keyboard (surrounded by new hardware) wondering what to do.. ;-)

[Sarah said...]
>It's going to be pretty hard to port all 1000+ xHCI patches to the
>2.6.27 kernel.  I had to touch parts of the USB core as well as adding
>the drivers, so can't just take the xHCI driver files alone.

[Greg said]
>It's a _very_ difficult task, and in the end, you have a kernel that no one 
>will
>support (company or community), and does not even work for some corner cases.

Well that convinces me! Thanks for steering me off this awful path early. In a 
way, I'm relieved. Btw, the OEM is Symantec. I do petition for better Linux 
support, but I think my use cases aren't very mainstream so they aren't too 
compelling. USB3 support however, I do however consider to be a no brainer 
considering it's potential.

Kind Regards,
Ian./

-Original Message-
From: Greg KH [mailto:gre...@linuxfoundation.org]
Sent: 07 August 2012 19:07
To: Ian Atkin
Cc: Sarah Sharp; 'linux-usb@vger.kernel.org'
Subject: Re: Backfilling USB-3 support into the 2.6.27.7 kernel

On Tue, Aug 07, 2012 at 10:49:00AM -0700, Sarah Sharp wrote:
> On Tue, Aug 07, 2012 at 05:44:34PM +, Ian Atkin wrote:
> > Hi,
> >
> > Don't know if this is the right place to ask about USB 3 support and
> > legacy kernels, so apologies in advance if it is not. I have an
> > ageing Linux environment based on the OpenSuse 2.6.27.7 kernel. This
> > environment is an OEM environment which we occasionally have to
> > back-fill support into (new AHCI drivers for example[1])  to get new
> > hardware supported.
> >
> > The Intel xhCI (USB3) controller problem has now hit us with this
> > environment, and I'm unsure whether support can be added for this
> > old kernel is going to be possible. Upgrading the kernel will also
> > take us out of OEM support.
> >
> > Does anyone have any pointers on what we can do here? If a kernel
> > upgrade is the only way to go, resulting in us falling out of OEM
> > support, then so be it. But before going down that route, I'd
> > thought I'd ask...
>
> It's going to be pretty hard to port all 1000+ xHCI patches to the
> 2.6.27 kernel.  I had to touch parts of the USB core as well as adding
> the drivers, so can't just take the xHCI driver files alone.
>
> I would strongly recommend you just upgrade your kernel.

As someone who ended up doing the backport for USB3 to the 2.6.32 kernel (an 
even newer one than 2.6.27), I completely agree with Sarah here.
It's a _very_ difficult task, and in the end, you have a kernel that no one 
will support (company or community), and does not even work for some corner 
cases.

Just upgrade to a newer kernel version, it's the only way to reliably get this 
working properly.

And what OEM is based on an unsupported openSUSE kernel?  That seems pretty 
crazy.

Good luck,

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: Continuous stream of small bulk transfers hangs on OHCI-based system

[Alan Stern]

On Mon, 6 Aug 2012, Tomas Sokorai wrote:

> Ding, Ding, Ding!, we have a winner :-)
> I did an ugly check:
> 
>   if (ohci->ed_rm_list)
>   finish_unlinks (ohci, ohci_frame_no(ohci));
>   if ((ints & OHCI_INTR_SF) != 0
>   && !ohci->ed_rm_list
>   && !ohci->ed_to_check
>   && ohci->rh_state == OHCI_RH_RUNNING)
>   ohci_writel (ohci, OHCI_INTR_SF, ®s->intrdisable);
>   else if ((ints & OHCI_INTR_SF) != 0
>   && ohci->ed_rm_list
>   && !ohci->ed_to_check
>   && ohci->rh_state == OHCI_RH_RUNNING)
>   ohci_warn(ohci,"SF intr should have been disabled, but 
> ed_rm_list is
> not empty\n");
>   spin_unlock (&ohci->lock);
> 
> Result: The ed_rm_list definitely stays not null forever after the hang.
> 
> This non-empty ed_rm_list condition is raised even when not hung at
> quite a rate, but after its hung, this lovely message does a while(1)
> dmesg benchmark :-)

It's normal to see this happen during ordinary use, although perhaps 
your rate is higher than it should be.  Anyway, the next step is to 
look inside finish_unlinks() in ohci-q.c to figure out what's going 
wrong.

I don't have time today to look further into this, but I'll get back to 
you later.

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: Do we need asynchronous pm_runtime_get()? (was: Re: bisected regression ...)

[Rafael J. Wysocki]

On Tuesday, August 07, 2012, Ming Lei wrote:
> On Tue, Aug 7, 2012 at 7:23 PM, Rafael J. Wysocki  wrote:
> >> Yes, I agree, but I don't think it may make .runtime_post_resume
> >> not doable, do I?
> >
> > No more device PM callbacks, please.
> 
> IMO, what the patch is doing is to introduce one callback which
> is just called after .runtime_resume is completed,

No, it is not a callback.  It is a function to be run _once_ when the device is
known to be active.  It is not a member of a data type or anything like this.

It's kind of disappointing that you don't see a difference between that and a
callback.

> and you want to move something out of previous .runtime_resume

No, I don't.  Where did you get that idea from?

> and do it in another new callback to speedup resume,

No, not to speed up resume.  The idea is to allow drivers to run something
when the resume is complete, so that they don't have to implement a "resume
detection" logic or use .runtime_resume() to run things that don't belong
there.

> so it should be reasonable to introduce the .runtime_post_resume callback in
> logic.

No.  This doesn't have anything to do with callbacks!

If you want a new callback, you should specify what the role of this callback
is, otherwise it is not well defined.  I this case, though, what the role of
func() is depends on the caller and most likely every driver would use it
for something different.  So no, I don't see how it can be a callback.

> Also, the 'func' should be per driver, not per device since only one
> 'func' is enough for all same kind of devices driven by one same
> driver.

It isn't per device!  It is per _caller_.  The fact that the pointer is
stored _temporarily_ in struct device doesn't mean that it is per device
and that it is a callback.  From the struct device point of view it is _data_,
not a member function.

> > Besides, callbacks in struct dev_pm_ops are not only for drivers.
> 
> All the current 3 runtime callbacks are for devices. If you mean
> they can be defined in bus/power_domain/device_type, .runtime_post_resume
> still can be defined there too.

No, it wouldn't make _any_ _sense_ there, because its role there cannot be
defined in any sane way.

> >> > Also, "func" should not be stored in dev_pm_ops because it won't be a
> >> > read-only value.
> >>
> >> Sorry, could you explain it in detail that why the 'func'
> >> has to switch to multiple functions dynamically? I understand
> >> one function is enough and sometimes it can be bypassed with
> >> one flag(such as, ignore_post_resume is introduced in dev_pm_info)
> >> set.  Also, the driver can store the device specific states
> >> in its own device instance to deal with different situations in the 
> >> callback.
> >>
> >> If the idea is doable, we can save one pointer in 'struct device',
> >> since the 'func' may not be used by more than 90% devices, also
> >> have document benefit, even may simplify implementation of the
> >> mechanism.
> >
> > And how many struct device objects there are for the one extra pointer to
> > matter, let alone the fact that you want to replace it by one extra pointer
> > somewhere else?
> 
> For example, in the pandaboard(one omap4 based small system), follows
> the count of device instances:
> 
>  [root@root]#dmesg | grep device_add | wc -l
> 471
> 
> The above is just a simple configuration(no graphics, no video/video, only
> console enabled) on Pandaboard.
> 
> If the callback may be defined in dev_pm_info,

I guess you mean struct dev_pm_ops, right?

> not only memory can be saved, also there are other advantages described
> before.

So now please count how many struct dev_pm_ops objects there are on that system
and compute the differece.  And please note that drivers that don't use
struct dev_pm_ops for power management will do that in the future.

Also please note that the caller of pm_runtime_get_and_call() need not be
a driver, at least in theory.

Thanks,
Rafael
--
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: Do we need asynchronous pm_runtime_get()? (was: Re: bisected regression ...)

[Rafael J. Wysocki]

On Tuesday, August 07, 2012, Ming Lei wrote:
> On Tue, Aug 7, 2012 at 11:42 PM, Alan Stern  wrote:
> >
> > No, that's really not what the patch is doing.
> >
> > The idea behind the new API is that "func" will be called as soon as we
> > know the device is at full power.  That could be after the next runtime
> > resume or it could be right away.  This is a one-time call; it should
> 
> IMO, in the both two cases, the 'func' should be very similar with
> .runtime_post_resume from view of the caller because the caller
> don't know what the power state of the device is now, so they may
> always think the 'func' should do something similar done in
> .runtime_post_resume.
> 
> Also .runtime_post_resume always knows the device's power state
> is active, which is same with 'func'. In fact, it doesn't matter if the active
> state is the 1st time or other times, does it?

What Alan wanted to say, I think, was that .runtime_post_resume() would have
to be always identical, where func() need not be always the same function.
Moreover, .runtime_post_resume() would _always_ be run after a device resume,
while func() is run only _once_.

> > not be made _every_ time the device resumes.
> 
> Suppose the device is always resumed in the path(such as irq context),
> the callback is still called every time.

Yes, but what if you have _two_ code paths and you want to call different
code as func() in each of them?

> If the .runtime_post_resume is to be a one-time call, that is easy to do it.

No, it isn't.

> Also I am wondering why the callback shouldn't be called after resume
> in sync context, and it may simplify implementation if the two contexts
> (sync vs. async) are kept consistent.

I have no idea what you're talking about.

We actually have a callback that is run every time a device is resumed.
It is called .runtime_idle().  Does it help, though?  No, it doesn't.

> >> Also, the 'func' should be per driver, not per device since only one
> >> 'func' is enough for all same kind of devices driven by one same
> >> driver.
> >
> > But what if the subsystem defines its own dev_pm_info structure?  Then
> > the driver's dev_pm_info will be ignored by the runtime PM core.  All
> > the subsystems would have to be changed.
> 
> Suppose .runtime_post_resume is introduced,

It is not going to be introduced, period.

Thanks,
Rafael
--
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: Do we need asynchronous pm_runtime_get()? (was: Re: bisected regression ...)

[Rafael J. Wysocki]

On Tuesday, August 07, 2012, Alan Stern wrote:
> On Tue, 7 Aug 2012, Rafael J. Wysocki wrote:
> 
> > > > All those changes (and some of the following ones) are symptoms of a
> > > > basic mistake in this approach.
> > > 
> > > Every time you say something like this (i.e. liks someone who knows 
> > > better)
> > 
> > s/liks/like/
> > 
> > > I kind of feel like being under attach, which I hope is not your 
> > > intention.
> > 
> > s/attach/attack/
> 
> Sorry; you're right.  It's all too easy to get very arrogant in email 
> messages.  I'll try not to attack so strongly in the future.

Thanks!

> > > > The idea of this new feature is to
> > > > call "func" as soon as we know the device is at full power, no matter
> > > > how it got there.
> > > 
> > > Yes, it is so.
> 
> Incidentally, that sentence is the justification for the invariance
> condition mentioned later.

:-)

> power.func should be called as soon as we
> know the device is at full power; therefore when the status changes to
> RPM_ACTIVE it should be called and then cleared (if it was set), and it
> should never get set while the status is RPM_ACTIVE.  Therefore it
> should never be true that power.func is set _and_ the status is
> RPM_ACTIVE.

I guess with the patch I've just sent:

http://marc.info/?l=linux-pm&m=134437366811066&w=4

it's almost the case, except when a synchronous resume happens before the work
item scheduled by __pm_runtime_get_and_call() is run.  However, I don't think
it is a problem in that case, because the device won't be suspended before the
execution of that work item starts (rpm_check_suspend_allowed() will see that
power.request_pending is set and that power.request is RPM_REQ_RESUME, so it
will return -EAGAIN).

> > > > That means we should call it near the end of
> > > > rpm_resume() (just before the rpm_idle() call), not from within
> > > > pm_runtime_work().
> > > > 
> > > > Doing it this way will be more efficient and (I think) will remove
> > > > some races.
> > > 
> > > Except that func() shouldn't be executed under dev->power.lock, which 
> > > makes it
> > > rather difficult to call it from rpm_resume().  Or at least it seems so.
> > > 
> > > Moreover, it should be called after we've changed the status to RPM_ACTIVE
> > > _and_ dropped the lock.
> > 
> > So we could drop the lock right before returning, execute func() and acquire
> > the lock once again,
> 
> Yes; that's what I had in mind.  We already do something similar when 
> calling pm_runtime_put(parent).

Yes, we do.  However, I still don't think it's really safe to call func()
from rpm_resume(), because it may be run synchronously from a context
quite unrelated to the caller of __pm_runtime_get_and_call() (for example,
from the pm_runtime_barrier() in __device_suspend()).

> >  but then func() might be executed by any thread that
> > happened to resume the device.  In that case the caller of
> > pm_runtime_get_and_call() would have to worry about locks that such threads
> > might acquire and it would have to make sure that func() didn't try to 
> > acquire
> > them too.  That may not be a big deal, but if func() is executed by
> > pm_runtime_work(), that issue simply goes away.
> 
> But then you have to worry about races between pm_runtime_resume() and
> the workqueue.  If the device is resumed by some other thread, it
> could be suspended again before "func" is called.

No, it can't, if the device's usage count is incremented before dropping
power.lock after rpm_resume(dev, 0) has returned.

> > Then, however, there's another issue: what should happen if
> > pm_runtime_get_and_call() finds that it cannot execute func() right away,
> > so it queues up resume and the execution of it, in the meantime some other
> > thread resumes the device synchronously and pm_runtime_get_and_call() is
> > run again.  I think in that case func() should be executed synchronously
> > and the one waiting for execution should be canceled.  The alternative
> > would be to return -EAGAIN from pm_runtime_get_and_call() and expect the
> > caller to cope with that, which isn't too attractive.
> > 
> > This actually is analogous to the case when pm_runtime_get_and_call()
> > sees that power.func is not NULL.  In my experimental patches it returned
> > -EAGAIN in that case, but perhaps it's better to replace the existing
> > power.func with the new one.  Then, by doing pm_runtime_get_and_call(dev, 
> > NULL)
> > we can ensure that either the previous func() has run already or it will 
> > never
> > run, which may be useful.
> 
> A good point.  I agree that pm_runtime_get_and_call() should always 
> overwrite the existing power.func value.
> 
> There are a couple of other issues remaining.
> 
> What's the best approach when disable_count > 0?  My feeling is that we
> should still rely on power.runtime_status as the best approximation to
> the device's state, so we shouldn't call "func" directly unless the
> status is already RPM_ACTIVE.

Well, that's one possibility.  In that cas

[PATCH] cdc-phonet: Don't leak in usbpn_open

[Jesper Juhl]

We allocate memory for 'req' with usb_alloc_urb() and then test
'if (!req || rx_submit(pnd, req, GFP_KERNEL | __GFP_COLD))'.
If we enter that branch due to '!req' then there is no problem. But if
we enter the branch due to 'req' being != 0 and the 'rx_submit()' call
being false, then we'll leak the memory we allocated.
Deal with the leak by always calling 'usb_free_urb(req)' when entering
the branch. If 'req' happens to be 0 then the call is harmless, if it
is not 0 then we free the memory we allocated but don't need.

Signed-off-by: Jesper Juhl 
---
 drivers/net/usb/cdc-phonet.c | 1 +
 1 file changed, 1 insertion(+)

  Only compile tested due to lack of hardware.

diff --git a/drivers/net/usb/cdc-phonet.c b/drivers/net/usb/cdc-phonet.c
index 6461004..7d78669 100644
--- a/drivers/net/usb/cdc-phonet.c
+++ b/drivers/net/usb/cdc-phonet.c
@@ -232,6 +232,7 @@ static int usbpn_open(struct net_device *dev)
struct urb *req = usb_alloc_urb(0, GFP_KERNEL);
 
if (!req || rx_submit(pnd, req, GFP_KERNEL | __GFP_COLD)) {
+   usb_free_urb(req);
usbpn_close(dev);
return -ENOMEM;
}
-- 
1.7.11.4


-- 
Jesper Juhlhttp://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.

--
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: [GIT PULL] usb: fixes for v3.6-rc1

[Greg KH]

On Fri, Aug 03, 2012 at 12:17:03PM +0300, Felipe Balbi wrote:
> Hi Greg,
> 
> here's a small set of fixes for v3.6-rc1. They're all on MUSB drivers
> and are quite simple. Let me know if you want me to change anythying.
> 
> cheers
> 
> The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee:
> 
>   Linux 3.6-rc1 (2012-08-02 16:38:10 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> tags/fixes-for-v3.6-rc1

Pulled and pushed out, 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: [PATCH 7/26] USB:support the new interfaces of Huawei Data Card devices in option driver

[g...@kroah.com]

On Thu, Jul 26, 2012 at 08:44:33AM +, Fangxiaozhi (Franko) wrote:
> From: fangxiaozhi  
> 1. This patch is based on the kernel of 3.5
> 2. In this patch, we add new micro for matching the series USB devices with 
> vendor ID and interface information.
> 3. In this patch, we add new declarations into option.c to support the new 
> interfaces of Huawei Data Card devices. And at the same time, remove the 
> redundant declarations from option.c.
> Signed-off-by: fangxiaozhi 
>  ---

Where are the other patches in this series?

Also, this patch does not apply to 3.6-rc1, please redo it.

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: [PATCH 1/8] USB:support the new interfaces of Huawei Data Card devices in option driver

[g...@kroah.com]

On Wed, Aug 01, 2012 at 02:05:18AM +, Fangxiaozhi (Franko) wrote:
> From: fangxiaozhi  
> 1. This patch is based on the kernel of 3.5 
> 2. In this patch, we add new micro for matching the series USB devices with 
> vendor ID and interface information.
> 3. In this patch, we add new declarations into option.c to support the new 
> interfaces of Huawei Data Card devices. And at the same time, remove the 
> redundant declarations from option.c.
> Signed-off-by: fangxiaozhi 
>  ---

You say this is patch 1 of 8, where are the other 8 patches?

confused,

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: usb device getting disconnected

[Sadasivan Shaiju]

Hi  Alen/Peter ,

I  do  get  the  following error   while   the  system  is  up  and
running  .  Basically  the  USB  device   get  disconnected  .  Any
insight  into  the  problem ?


[160549.977172] hub 2-1:1.0: state 7 ports 6 chg  evt 0010^M
[160549.977275] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
1^M
[160549.977400] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
2^M
[160549.977524] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
3^M
[160549.977528] hub 2-1:1.0: port 4, status 0100, change 0001, 12 Mb/s^M
[160549.977650] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
4^M
[160549.977652] usb 2-1.4: USB disconnect, address 3^M
[160549.977654] usb 2-1.4: unregistering device^M
[160549.977656] usb 2-1.4: unregistering interface 2-1.4:1.0^M
[160549.92] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
5^M
[160549.977897] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
6^M
[160549.978020] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
7^M
[160549.978146] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
8^M
[160549.978269] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
9^M
[160549.978394] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
10^M
[160549.978519] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
11^M
[160549.978644] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
12^M
[160549.978770] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
13^M
[160549.978894] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
14^M
[160549.979018] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
15^M
[160549.979144] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
16^M
[160549.979269] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
17^M
[160549.979393] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
18^M
[160549.979517] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
19^M
[160549.979642] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
20^M
[160549.979768] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
21^M
[160549.979892] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
22^M
[160549.980016] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
23^M
[160549.980142] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
24^M
[160549.980266] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
25^M
[160549.980391] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
26^M
[160549.980516] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
27^M


Regards,
Shaiju.


-Original Message-
From: Alan Stern [mailto:st...@rowland.harvard.edu]
Sent: Sunday, July 29, 2012 2:54 PM
To: shaiju shaiju
Cc: 'Sadasivan Shaiju'; 'Peter Chen'; 'USB list'
Subject: RE: usb device getting disconnected and connect back again.

On Sun, 29 Jul 2012, shaiju shaiju wrote:

> Hi  Alen,
>
> This  error  is  intermittent  .  It  doesn't  happen  always .

Then there may not be any way to determine the cause.  Perhaps the
firmware in the USB device intermittently crashes.

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: Continuous stream of small bulk transfers hangs on OHCI-based system

[Tomas Sokorai]

On Tue, Aug 7, 2012 at 3:42 PM, Alan Stern  wrote:
>
> I don't have time today to look further into this, but I'll get back to
> you later.

No hurries, in fact I was gathering a bit more info about this behavior.
I dumped the ed_rm_list when it is hung, and we have only one element
that's unkillable:

[ 1108.841482] ohci_hcd :00:04.0: ed_rm_list, ed 8800c781f140
state 0x1 type bulk; next ed 
[ 1108.841489] ohci_hcd :00:04.0:   info 08405103 MAX=64 DQ SKIP
EP=2-IN DEV=3
[ 1108.841494] ohci_hcd :00:04.0:   tds: head c78261e0 DATA0 tail
c78261e0 (not listing)

Also, there's only one non-empty ed_rm_list "pass" after the
finish_unlinks between SR intr disables, when not hung.

-- 
Tomas J. Sokorai Sch.
--
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 device getting disconnected

[Peter Chen]

> [160549.977524] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
> 3^M
> [160549.977528] hub 2-1:1.0: port 4, status 0100, change 0001, 12 Mb/s^M
> [160549.977650] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
> 4^M
> [160549.977652] usb 2-1.4: USB disconnect, address 3^M
> [160549.977654] usb 2-1.4: unregistering device^M
> [160549.977656] usb 2-1.4: unregistering interface 2-1.4:1.0^M
> [160549.92] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
> 5^M
> [160549.977897] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
> 6^M
> [160549.978020] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
> 7^M
> [160549.978146] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
> 8^M
> [160549.978269] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
> 9^M
> [160549.978394] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
> 10^M
> [160549.978519] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
> 11^M
> [160549.978644] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
> 12^M
> [160549.978770] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
> 13^M
> [160549.978894] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
> 14^M
> [160549.979018] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
> 15^M
> [160549.979144] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
> 16^M
> [160549.979269] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
> 17^M
> [160549.979393] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
> 18^M
> [160549.979517] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
> 19^M
> [160549.979642] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
> 20^M
> [160549.979768] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
> 21^M
> [160549.979892] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
> 22^M
> [160549.980016] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
> 23^M
> [160549.980142] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
> 24^M
> [160549.980266] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
> 25^M
> [160549.980391] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
> 26^M
> [160549.980516] ehci_hcd :00:1d.0: detected XactErr len 0/4096 retry
> 27^M
>
>
> Regards,
> Shaiju.
>
>
> -Original Message-
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: Sunday, July 29, 2012 2:54 PM
> To: shaiju shaiju
> Cc: 'Sadasivan Shaiju'; 'Peter Chen'; 'USB list'
> Subject: RE: usb device getting disconnected and connect back again.
>
> On Sun, 29 Jul 2012, shaiju shaiju wrote:
>
>> Hi  Alen,
>>
>> This  error  is  intermittent  .  It  doesn't  happen  always .
>
> Then there may not be any way to determine the cause.  Perhaps the
> firmware in the USB device intermittently crashes.
>
If the host has some errors, such like the PHY work abnormal, it will also
occur errors like this. It is hard to debug your problem, I suggestion try more
boards and do more tests to see if it is single board issue or the
issues for all
boards.



> 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 3/8] serial: vt8500: Add devicetree support for vt8500-serial

[Tony Prisk]

Signed-off-by: Tony Prisk 
---
 drivers/tty/serial/vt8500_serial.c |7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/tty/serial/vt8500_serial.c 
b/drivers/tty/serial/vt8500_serial.c
index 2be006f..a7f58c9 100644
--- a/drivers/tty/serial/vt8500_serial.c
+++ b/drivers/tty/serial/vt8500_serial.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * UART Register offsets
@@ -603,12 +604,18 @@ static int __devexit vt8500_serial_remove(struct 
platform_device *pdev)
return 0;
 }
 
+static const struct of_device_id wmt_dt_ids[] = {
+   { .compatible = "via,vt8500-uart", },
+   {}
+};
+
 static struct platform_driver vt8500_platform_driver = {
.probe  = vt8500_serial_probe,
.remove = __devexit_p(vt8500_serial_remove),
.driver = {
.name = "vt8500_serial",
.owner = THIS_MODULE,
+   .of_match_table = of_match_ptr(wmt_dt_ids),
},
 };
 
-- 
1.7.9.5

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

[PATCH 0/8] *** ARM: Update arch-vt8500 to Devicetree ***

[Tony Prisk]

This patchset updates arch-vt8500 to devicetree and removes all the old-style
code. Support for WM8650 has also been added.

Example dts/dtsi files are given for the three currently supported models.

Major changes:

GPIO code has been converted to a platform_device and rewritten as WM8505
support was broken. Add support for WM8650 gpio controller.

UHCI support was missing. Added this as a generic non-pci uhci controller as
it doesn't require anything special. Should be usable by any system that doesn't
have special requirements to get the UHCI controller working.

Framebuffer code patched to support WM8650. The bindings for this are of concern
but there doesn't seem to be a formalized binding yet. This patch is based off
Sascha Hauer's current patch on the dri-devel mailing list and should be easily
patched out when its finalized.

Patchset based on Arnd's arm-soc/for-next branch.


Could I get this reviewed, hopefully for inclusion into v3.7.

Regards
Tony Prisk


Tony Prisk (8):
  arm: vt8500: Add device tree files for VIA/Wondermedia SoC's
  rtc: vt8500: Add devicetree support for vt8500-rtc
  serial: vt8500: Add devicetree support for vt8500-serial
  usb: vt8500: Add devicetree support for vt8500-ehci and -uhci.
  video: vt8500: Add devicetree support for vt8500-fb and wm8505-fb
  arm: vt8500: Update arch-vt8500 to devicetree support.
  arm: vt8500: doc: Add device tree bindings for arch-vt8500 devices
  ARM: vt8500: gpio: Devicetree support for arch-vt8500

 Documentation/devicetree/bindings/arm/vt8500.txt   |   15 +
 .../bindings/arm/vt8500/via,vt8500-intc.txt|   16 +
 .../bindings/arm/vt8500/via,vt8500-pmc.txt |   13 +
 .../bindings/arm/vt8500/via,vt8500-timer.txt   |   15 +
 .../devicetree/bindings/gpio/gpio_vt8500.txt   |   24 ++
 .../devicetree/bindings/rtc/via,vt8500-rtc.txt |   15 +
 .../bindings/tty/serial/via,vt8500-uart.txt|   15 +
 .../devicetree/bindings/usb/platform-uhci.txt  |   15 +
 .../devicetree/bindings/usb/via,vt8500-ehci.txt|   15 +
 .../devicetree/bindings/vendor-prefixes.txt|2 +
 .../devicetree/bindings/video/via,vt8500-fb.txt|   46 +++
 .../devicetree/bindings/video/wm,prizm-ge-rops.txt |   13 +
 .../devicetree/bindings/video/wm,wm8505-fb.txt |   20 ++
 arch/arm/Kconfig   |2 +
 arch/arm/boot/dts/vt8500.dtsi  |   99 ++
 arch/arm/boot/dts/vt8500_ref.dts   |   31 ++
 arch/arm/boot/dts/wm8505.dtsi  |  125 
 arch/arm/boot/dts/wm8505_ref.dts   |   31 ++
 arch/arm/boot/dts/wm8650.dtsi  |   95 ++
 arch/arm/boot/dts/wm8650_ref.dts   |   31 ++
 arch/arm/mach-vt8500/Kconfig   |   72 +
 arch/arm/mach-vt8500/Makefile  |9 +-
 arch/arm/mach-vt8500/bv07.c|   80 -
 arch/arm/mach-vt8500/common.h  |   25 ++
 arch/arm/mach-vt8500/devices-vt8500.c  |   91 --
 arch/arm/mach-vt8500/devices-wm8505.c  |   99 --
 arch/arm/mach-vt8500/devices.c |  270 -
 arch/arm/mach-vt8500/devices.h |   88 --
 arch/arm/mach-vt8500/gpio.c|  240 ---
 arch/arm/mach-vt8500/include/mach/restart.h|4 +-
 arch/arm/mach-vt8500/include/mach/vt8500_irqs.h|   88 --
 arch/arm/mach-vt8500/include/mach/vt8500_regs.h|   79 -
 arch/arm/mach-vt8500/include/mach/wm8505_irqs.h|  115 ---
 arch/arm/mach-vt8500/include/mach/wm8505_regs.h|   78 -
 arch/arm/mach-vt8500/irq.c |  160 +-
 arch/arm/mach-vt8500/restart.c |   54 
 arch/arm/mach-vt8500/timer.c   |   56 +++-
 arch/arm/mach-vt8500/vt8500.c  |  192 
 arch/arm/mach-vt8500/wm8505_7in.c  |   79 -
 drivers/gpio/Kconfig   |6 +
 drivers/gpio/Makefile  |1 +
 drivers/gpio/gpio-vt8500.c |  318 
 drivers/rtc/rtc-vt8500.c   |7 +
 drivers/tty/serial/vt8500_serial.c |7 +
 drivers/usb/host/Kconfig   |4 +-
 drivers/usb/host/ehci-vt8500.c |   24 +-
 drivers/usb/host/uhci-hcd.c|5 +
 drivers/usb/host/uhci-platform.c   |  166 ++
 drivers/video/Kconfig  |6 +-
 drivers/video/vt8500lcdfb.c|   77 -
 drivers/video/wm8505fb.c   |   95 +-
 drivers/video/wmt_ge_rops.c|7 +
 52 files changed, 1674 insertions(+), 1566 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/vt8500.txt
 create mode 100644 
Documentation/devicetr

[PATCH 4/8] usb: vt8500: Add devicetree support for vt8500-ehci and -uhci.

[Tony Prisk]

Add devicetree support for vt8500-ehci.
Convert vt8500-uhci to a generic non-pci platform-uhci with
device tree support.

Signed-off-by: Tony Prisk 
---
 drivers/usb/host/Kconfig |4 +-
 drivers/usb/host/ehci-vt8500.c   |   24 --
 drivers/usb/host/uhci-hcd.c  |5 ++
 drivers/usb/host/uhci-platform.c |  166 ++
 4 files changed, 191 insertions(+), 8 deletions(-)
 create mode 100644 drivers/usb/host/uhci-platform.c

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index dcfaaa9..d7a6b10 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -450,7 +450,7 @@ config USB_OHCI_LITTLE_ENDIAN
 
 config USB_UHCI_HCD
tristate "UHCI HCD (most Intel and VIA) support"
-   depends on USB && (PCI || SPARC_LEON)
+   depends on USB && (PCI || SPARC_LEON || ARCH_VT8500)
---help---
  The Universal Host Controller Interface is a standard by Intel for
  accessing the USB hardware in the PC (which is also called the USB
@@ -468,7 +468,7 @@ config USB_UHCI_HCD
 config USB_UHCI_SUPPORT_NON_PCI_HC
bool
depends on USB_UHCI_HCD
-   default y if SPARC_LEON
+   default y if (SPARC_LEON  || ARCH_VT8500)
 
 config USB_UHCI_BIG_ENDIAN_MMIO
bool
diff --git a/drivers/usb/host/ehci-vt8500.c b/drivers/usb/host/ehci-vt8500.c
index c1eda73..52e9f92 100644
--- a/drivers/usb/host/ehci-vt8500.c
+++ b/drivers/usb/host/ehci-vt8500.c
@@ -16,6 +16,7 @@
  *
  */
 
+#include 
 #include 
 
 static int ehci_update_device(struct usb_hcd *hcd, struct usb_device *udev)
@@ -84,20 +85,23 @@ static const struct hc_driver vt8500_ehci_hc_driver = {
.clear_tt_buffer_complete   = ehci_clear_tt_buffer_complete,
 };
 
+static u64 wmt_ehci_dma_mask = DMA_BIT_MASK(32);
+
 static int vt8500_ehci_drv_probe(struct platform_device *pdev)
 {
struct usb_hcd *hcd;
struct ehci_hcd *ehci;
struct resource *res;
+   int irq;
int ret;
 
if (usb_disabled())
return -ENODEV;
 
-   if (pdev->resource[1].flags != IORESOURCE_IRQ) {
-   pr_debug("resource[1] is not IORESOURCE_IRQ");
-   return -ENOMEM;
-   }
+   /* devicetree created devices don't specify a dma mask */
+   if (!pdev->dev.dma_mask)
+   pdev->dev.dma_mask = &wmt_ehci_dma_mask;
+
hcd = usb_create_hcd(&vt8500_ehci_hc_driver, &pdev->dev, "VT8500");
if (!hcd)
return -ENOMEM;
@@ -134,8 +138,9 @@ static int vt8500_ehci_drv_probe(struct platform_device 
*pdev)
 
ehci_reset(ehci);
 
-   ret = usb_add_hcd(hcd, pdev->resource[1].start,
- IRQF_SHARED);
+   irq = platform_get_irq(pdev, 0);
+
+   ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret == 0) {
platform_set_drvdata(pdev, hcd);
return ret;
@@ -162,6 +167,11 @@ static int vt8500_ehci_drv_remove(struct platform_device 
*pdev)
return 0;
 }
 
+static const struct of_device_id vt8500_ehci_ids[] = {
+   { .compatible = "via,vt8500-ehci", },
+   {}
+};
+
 static struct platform_driver vt8500_ehci_driver = {
.probe  = vt8500_ehci_drv_probe,
.remove = vt8500_ehci_drv_remove,
@@ -169,7 +179,9 @@ static struct platform_driver vt8500_ehci_driver = {
.driver = {
.name   = "vt8500-ehci",
.owner  = THIS_MODULE,
+   .of_match_table = of_match_ptr(vt8500_ehci_ids),
}
 };
 
 MODULE_ALIAS("platform:vt8500-ehci");
+MODULE_DEVICE_TABLE(of, vt8500_ehci_ids);
diff --git a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c
index e4db350..5da5c99 100644
--- a/drivers/usb/host/uhci-hcd.c
+++ b/drivers/usb/host/uhci-hcd.c
@@ -846,6 +846,11 @@ static const char hcd_name[] = "uhci_hcd";
 #define PLATFORM_DRIVERuhci_grlib_driver
 #endif
 
+#ifdef CONFIG_ARCH_VT8500
+#include "uhci-platform.c"
+#define PLATFORM_DRIVERuhci_platform_driver
+#endif
+
 #if !defined(PCI_DRIVER) && !defined(PLATFORM_DRIVER)
 #error "missing bus glue for uhci-hcd"
 #endif
diff --git a/drivers/usb/host/uhci-platform.c b/drivers/usb/host/uhci-platform.c
new file mode 100644
index 000..1d7e522
--- /dev/null
+++ b/drivers/usb/host/uhci-platform.c
@@ -0,0 +1,166 @@
+/*
+ * Generic UHCI HCD (Host Controller Driver) for Platform Devices
+ *
+ * Copyright (c) 2011 Tony Prisk 
+ *
+ * This file is based on uhci-grlib.c
+ * (C) Copyright 2004-2007 Alan Stern, st...@rowland.harvard.edu
+ */
+
+#include 
+#include 
+
+static int uhci_platform_init(struct usb_hcd *hcd)
+{
+   struct uhci_hcd *uhci = hcd_to_uhci(hcd);
+
+   uhci->rh_numports = uhci_count_ports(hcd);
+
+   /* Set up pointers to to generic functions */
+   uhci->reset_hc = uhci_generic_reset_hc;
+   uhci->check_and_reset_hc = uhci_generic_check_and_reset_hc;
+
+   /* No special actions need to be taken for the fun

[PATCH 8/8] ARM: vt8500: gpio: Devicetree support for arch-vt8500

[Tony Prisk]

Converted the existing arch-vt8500 gpio to a platform_device.
Added support for WM8505 and WM8650 GPIO controllers.

Signed-off-by: Tony Prisk 
---
 drivers/gpio/Kconfig   |6 +
 drivers/gpio/Makefile  |1 +
 drivers/gpio/gpio-vt8500.c |  318 
 3 files changed, 325 insertions(+)
 create mode 100644 drivers/gpio/gpio-vt8500.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 542f0c0..3c8897a 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -183,6 +183,12 @@ config GPIO_STA2X11
  Say yes here to support the STA2x11/ConneXt GPIO device.
  The GPIO module has 128 GPIO pins with alternate functions.
 
+config GPIO_VT8500
+   bool "VIA/Wondermedia SoC GPIO Support"
+   depends on ARCH_VT8500
+   help
+ Say yes here to support the VT8500/WM8505/WM8650 GPIO controller.
+
 config GPIO_XILINX
bool "Xilinx GPIO support"
depends on PPC_OF || MICROBLAZE
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 0f55662..2c014b9 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_GPIO_TPS65912)   += gpio-tps65912.o
 obj-$(CONFIG_GPIO_TWL4030) += gpio-twl4030.o
 obj-$(CONFIG_GPIO_UCB1400) += gpio-ucb1400.o
 obj-$(CONFIG_GPIO_VR41XX)  += gpio-vr41xx.o
+obj-$(CONFIG_GPIO_VT8500)  += gpio-vt8500.o
 obj-$(CONFIG_GPIO_VX855)   += gpio-vx855.o
 obj-$(CONFIG_GPIO_WM831X)  += gpio-wm831x.o
 obj-$(CONFIG_GPIO_WM8350)  += gpio-wm8350.o
diff --git a/drivers/gpio/gpio-vt8500.c b/drivers/gpio/gpio-vt8500.c
new file mode 100644
index 000..3306634
--- /dev/null
+++ b/drivers/gpio/gpio-vt8500.c
@@ -0,0 +1,318 @@
+/* linux/arch/arm/mach-vt8500/gpio.c
+ *
+ * Copyright (C) 2012 Tony Prisk 
+ * Based on gpio.c:
+ * - Copyright (C) 2010 Alexey Charkov 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+   We handle GPIOs by bank, each bank containing up to 32 GPIOs covered
+   by one set of registers (although not all may be valid).
+
+   Because different SoC's have different register offsets, we pass the
+   register offsets as data in vt8500_gpio_dt_ids[].
+*/
+
+struct vt8500_gpio_bank_regs {
+   int en;
+   int dir;
+   int data_out;
+   int data_in;
+   int ngpio;
+};
+
+struct vt8500_gpio_data {
+   unsigned intnum_banks;
+   struct vt8500_gpio_bank_regsbanks[];
+};
+
+#define VT8500_BANK(__en, __dir, __out, __in, __ngpio) \
+{  \
+   .en = __en, \
+   .dir = __dir,   \
+   .data_out = __out,  \
+   .data_in = __in,\
+   .ngpio = __ngpio,   \
+}
+
+static struct vt8500_gpio_data vt8500_data = {
+   .num_banks  = 7,
+   .banks  = {
+   VT8500_BANK(0x00, 0x20, 0x40, 0x60, 26),
+   VT8500_BANK(0x04, 0x24, 0x44, 0x64, 28),
+   VT8500_BANK(0x08, 0x28, 0x48, 0x68, 31),
+   VT8500_BANK(0x0C, 0x2C, 0x4C, 0x6C, 19),
+   VT8500_BANK(0x10, 0x30, 0x50, 0x70, 19),
+   VT8500_BANK(0x14, 0x34, 0x54, 0x74, 23),
+   VT8500_BANK(-1, 0x3C, 0x5C, 0x7C, 9),/* external gpio */
+   },
+};
+
+static struct vt8500_gpio_data wm8505_data = {
+   .num_banks  = 10,
+   .banks  = {
+   VT8500_BANK(0x40, 0x68, 0x90, 0xB8, 8),
+   VT8500_BANK(0x44, 0x6C, 0x94, 0xBC, 32),
+   VT8500_BANK(0x48, 0x70, 0x98, 0xC0, 6),
+   VT8500_BANK(0x4C, 0x74, 0x9C, 0xC4, 16),
+   VT8500_BANK(0x50, 0x78, 0xA0, 0xC8, 25),
+   VT8500_BANK(0x54, 0x7C, 0xA4, 0xCC, 5),
+   VT8500_BANK(0x58, 0x80, 0xA8, 0xD0, 5),
+   VT8500_BANK(0x5C, 0x84, 0xAC, 0xD4, 12),
+   VT8500_BANK(0x60, 0x88, 0xB0, 0xD8, 16),
+   VT8500_BANK(0x64, 0x8C, 0xB4, 0xDC, 22),
+   },
+};
+
+/*
+ * No information about which bits are valid so we just make
+ * them all available until its figured out.
+ */
+static struct vt8500_gpio_data wm8650_data = {
+   .num_banks  = 9,
+   .banks  = {
+   VT8500_BANK(0x40, 0x80, 0xC0, 0x00, 32),
+   VT8500_BANK(

[PATCH 7/8] arm: vt8500: doc: Add device tree bindings for arch-vt8500 devices

[Tony Prisk]

Bindings for gpio, interrupt controller, power management controller,
timer, realtime clock, serial uart, ehci and uhci controllers and
framebuffer controllers used on the arch-vt8500 platform.

Framebuffer binding also specifies a 'display' node which is required
for determining the lcd panel data.

Signed-off-by: Tony Prisk 
---
 Documentation/devicetree/bindings/arm/vt8500.txt   |   15 +++
 .../bindings/arm/vt8500/via,vt8500-intc.txt|   16 +++
 .../bindings/arm/vt8500/via,vt8500-pmc.txt |   13 ++
 .../bindings/arm/vt8500/via,vt8500-timer.txt   |   15 +++
 .../devicetree/bindings/gpio/gpio_vt8500.txt   |   24 ++
 .../devicetree/bindings/rtc/via,vt8500-rtc.txt |   15 +++
 .../bindings/tty/serial/via,vt8500-uart.txt|   15 +++
 .../devicetree/bindings/usb/platform-uhci.txt  |   15 +++
 .../devicetree/bindings/usb/via,vt8500-ehci.txt|   15 +++
 .../devicetree/bindings/vendor-prefixes.txt|2 +
 .../devicetree/bindings/video/via,vt8500-fb.txt|   46 
 .../devicetree/bindings/video/wm,prizm-ge-rops.txt |   13 ++
 .../devicetree/bindings/video/wm,wm8505-fb.txt |   20 +
 13 files changed, 224 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/vt8500.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/vt8500/via,vt8500-intc.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/vt8500/via,vt8500-pmc.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/vt8500/via,vt8500-timer.txt
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio_vt8500.txt
 create mode 100644 Documentation/devicetree/bindings/rtc/via,vt8500-rtc.txt
 create mode 100644 
Documentation/devicetree/bindings/tty/serial/via,vt8500-uart.txt
 create mode 100644 Documentation/devicetree/bindings/usb/platform-uhci.txt
 create mode 100644 Documentation/devicetree/bindings/usb/via,vt8500-ehci.txt
 create mode 100644 Documentation/devicetree/bindings/video/via,vt8500-fb.txt
 create mode 100644 Documentation/devicetree/bindings/video/wm,prizm-ge-rops.txt
 create mode 100644 Documentation/devicetree/bindings/video/wm,wm8505-fb.txt

diff --git a/Documentation/devicetree/bindings/arm/vt8500.txt 
b/Documentation/devicetree/bindings/arm/vt8500.txt
new file mode 100644
index 000..1b3b187
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/vt8500.txt
@@ -0,0 +1,15 @@
+VIA/Wondermedia VT8500 Platforms Device Tree Bindings
+---
+
+Boards with the VIA VT8500 SoC shall have the following properties:
+Required root node property:
+compatible = "via,vt8500";
+
+Boards with the Wondermedia WM8505 SoC shall have the following properties:
+Required root node property:
+compatible = "wm,wm8505";
+
+Boards with the Wondermedia WM8650 SoC shall have the following properties:
+Required root node property:
+compatible = "wm,wm8650";
+
diff --git a/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-intc.txt 
b/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-intc.txt
new file mode 100644
index 000..0a4ce10
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-intc.txt
@@ -0,0 +1,16 @@
+VIA/Wondermedia VT8500 Interrupt Controller
+-
+
+Required properties:
+- compatible : "via,vt8500-intc"
+- reg : Should contain 1 register ranges(address and length)
+- #interrupt-cells : should be <1>
+
+Example:
+
+   intc: interrupt-controller@d814 {
+   compatible = "via,vt8500-intc";
+   interrupt-controller;
+   reg = <0xd814 0x1>;
+   #interrupt-cells = <1>;
+   };
diff --git a/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-pmc.txt 
b/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-pmc.txt
new file mode 100644
index 000..521b9c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-pmc.txt
@@ -0,0 +1,13 @@
+VIA/Wondermedia VT8500 Power Management Controller
+-
+
+Required properties:
+- compatible : "via,vt8500-pmc"
+- reg : Should contain 1 register ranges(address and length)
+
+Example:
+
+   pmc@d813 {
+   compatible = "via,vt8500-pmc";
+   reg = <0xd813 0x1000>;
+   };
diff --git a/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-timer.txt 
b/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-timer.txt
new file mode 100644
index 000..901c73f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-timer.txt
@@ -0,0 +1,15 @@
+VIA/Wondermedia VT8500 Timer
+-
+
+Required properties:
+- compatible : "via,vt8500-timer"
+- reg : Should contain 1 register ranges(address and length)
+- interrupts : interrupt for the timer
+
+Example:
+
+   timer@d8130100 {
+   compatible 

[PATCH 5/8] video: vt8500: Add devicetree support for vt8500-fb and wm8505-fb

[Tony Prisk]

Update vt8500-fb, wm8505-fb and wmt-ge-rops to support device
tree bindings.
Small change in wm8505-fb.c to support WM8650 framebuffer color
format.

Signed-off-by: Tony Prisk 
---
 drivers/video/Kconfig   |6 +--
 drivers/video/vt8500lcdfb.c |   77 ++-
 drivers/video/wm8505fb.c|   95 ---
 drivers/video/wmt_ge_rops.c |7 
 4 files changed, 158 insertions(+), 27 deletions(-)

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 0217f74..b66d951 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1788,7 +1788,7 @@ config FB_AU1200
 
 config FB_VT8500
bool "VT8500 LCD Driver"
-   depends on (FB = y) && ARM && ARCH_VT8500 && VTWM_VERSION_VT8500
+   depends on (FB = y) && ARM && ARCH_VT8500
select FB_WMT_GE_ROPS
select FB_SYS_IMAGEBLIT
help
@@ -1797,11 +1797,11 @@ config FB_VT8500
 
 config FB_WM8505
bool "WM8505 frame buffer support"
-   depends on (FB = y) && ARM && ARCH_VT8500 && VTWM_VERSION_WM8505
+   depends on (FB = y) && ARM && ARCH_VT8500
select FB_WMT_GE_ROPS
select FB_SYS_IMAGEBLIT
help
- This is the framebuffer driver for WonderMedia WM8505
+ This is the framebuffer driver for WonderMedia WM8505/WM8650
  integrated LCD controller.
 
 source "drivers/video/geode/Kconfig"
diff --git a/drivers/video/vt8500lcdfb.c b/drivers/video/vt8500lcdfb.c
index 2a5fe6e..5fb3a56 100644
--- a/drivers/video/vt8500lcdfb.c
+++ b/drivers/video/vt8500lcdfb.c
@@ -35,6 +35,13 @@
 #include "vt8500lcdfb.h"
 #include "wmt_ge_rops.h"
 
+#ifdef CONFIG_OF
+#include 
+#include 
+#include 
+#endif
+
+
 #define to_vt8500lcd_info(__info) container_of(__info, \
struct vt8500lcd_info, fb)
 
@@ -270,15 +277,21 @@ static int __devinit vt8500lcd_probe(struct 
platform_device *pdev)
 {
struct vt8500lcd_info *fbi;
struct resource *res;
-   struct vt8500fb_platform_data *pdata = pdev->dev.platform_data;
void *addr;
int irq, ret;
 
+   struct fb_videomode of_mode;
+   struct device_node  *np;
+   u32 bpp;
+   dma_addr_t fb_mem_phys;
+   unsigned long fb_mem_len;
+   void *fb_mem_virt;
+
ret = -ENOMEM;
fbi = NULL;
 
-   fbi = kzalloc(sizeof(struct vt8500lcd_info) + sizeof(u32) * 16,
-   GFP_KERNEL);
+   fbi = devm_kzalloc(&pdev->dev, sizeof(struct vt8500lcd_info)
+   + sizeof(u32) * 16, GFP_KERNEL);
if (!fbi) {
dev_err(&pdev->dev, "Failed to initialize framebuffer 
device\n");
ret = -ENOMEM;
@@ -333,9 +346,45 @@ static int __devinit vt8500lcd_probe(struct 
platform_device *pdev)
goto failed_free_res;
}
 
-   fbi->fb.fix.smem_start  = pdata->video_mem_phys;
-   fbi->fb.fix.smem_len= pdata->video_mem_len;
-   fbi->fb.screen_base = pdata->video_mem_virt;
+   np = of_find_node_by_name(NULL, "display");
+   if (!np) {
+   pr_err("%s: No display description in Device Tree\n", __func__);
+   ret = -EINVAL;
+   goto failed_free_res;
+   }
+
+   /*
+* This code is copied from Sascha Hauer's of_videomode helper
+* and can be replaced with a call to the helper once mainlined
+*/
+   ret = 0;
+   ret |= of_property_read_u32(np, "xres", &of_mode.xres);
+   ret |= of_property_read_u32(np, "yres", &of_mode.yres);
+   ret |= of_property_read_u32(np, "left-margin", &of_mode.left_margin);
+   ret |= of_property_read_u32(np, "right-margin", &of_mode.right_margin);
+   ret |= of_property_read_u32(np, "hsync-len", &of_mode.hsync_len);
+   ret |= of_property_read_u32(np, "upper-margin", &of_mode.upper_margin);
+   ret |= of_property_read_u32(np, "lower-margin", &of_mode.lower_margin);
+   ret |= of_property_read_u32(np, "vsync-len", &of_mode.vsync_len);
+   ret |= of_property_read_u32(np, "bpp", &bpp);
+   if (ret) {
+   pr_err("%s: Unable to read display properties\n", __func__);
+   goto failed_free_res;
+   }
+   of_mode.vmode = FB_VMODE_NONINTERLACED;
+
+   /* try allocating the framebuffer */
+   fb_mem_len = of_mode.xres * of_mode.yres * 2 * (bpp / 8);
+   fb_mem_virt = dma_alloc_coherent(&pdev->dev, fb_mem_len, &fb_mem_phys,
+   GFP_KERNEL);
+   if (!fb_mem_virt) {
+   pr_err("%s: Failed to allocate framebuffer\n",__func__);
+   return -ENOMEM;
+   };
+
+   fbi->fb.fix.smem_start  = fb_mem_phys;
+   fbi->fb.fix.smem_len= fb_mem_len;
+   fbi->fb.screen_base = fb_mem_virt;
 
fbi->palette_size   = PAGE_ALIGN(512);
fbi->palette_cpu= dma_alloc_coherent(&pdev->dev,
@@ -3

[PATCH 2/8] rtc: vt8500: Add devicetree support for vt8500-rtc

[Tony Prisk]

Signed-off-by: Tony Prisk 
---
 drivers/rtc/rtc-vt8500.c |7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/rtc/rtc-vt8500.c b/drivers/rtc/rtc-vt8500.c
index 9e94fb1..7364564 100644
--- a/drivers/rtc/rtc-vt8500.c
+++ b/drivers/rtc/rtc-vt8500.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Register definitions
@@ -302,12 +303,18 @@ static int __devexit vt8500_rtc_remove(struct 
platform_device *pdev)
return 0;
 }
 
+static const struct of_device_id wmt_dt_ids[] = {
+   { .compatible = "via,vt8500-rtc", },
+   {}
+};
+
 static struct platform_driver vt8500_rtc_driver = {
.probe  = vt8500_rtc_probe,
.remove = __devexit_p(vt8500_rtc_remove),
.driver = {
.name   = "vt8500-rtc",
.owner  = THIS_MODULE,
+   .of_match_table = of_match_ptr(wmt_dt_ids),
},
 };
 
-- 
1.7.9.5

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

[PATCH 1/8] arm: vt8500: Add device tree files for VIA/Wondermedia SoC's

[Tony Prisk]

Add device tree files for VT8500, WM8505 and WM8650 SoC's and
reference boards.

Signed-off-by: Tony Prisk 
---
 arch/arm/boot/dts/vt8500.dtsi|   99 ++
 arch/arm/boot/dts/vt8500_ref.dts |   31 ++
 arch/arm/boot/dts/wm8505.dtsi|  125 ++
 arch/arm/boot/dts/wm8505_ref.dts |   31 ++
 arch/arm/boot/dts/wm8650.dtsi|   95 +
 arch/arm/boot/dts/wm8650_ref.dts |   31 ++
 6 files changed, 412 insertions(+)
 create mode 100644 arch/arm/boot/dts/vt8500.dtsi
 create mode 100644 arch/arm/boot/dts/vt8500_ref.dts
 create mode 100644 arch/arm/boot/dts/wm8505.dtsi
 create mode 100644 arch/arm/boot/dts/wm8505_ref.dts
 create mode 100644 arch/arm/boot/dts/wm8650.dtsi
 create mode 100644 arch/arm/boot/dts/wm8650_ref.dts

diff --git a/arch/arm/boot/dts/vt8500.dtsi b/arch/arm/boot/dts/vt8500.dtsi
new file mode 100644
index 000..7a2fe0e
--- /dev/null
+++ b/arch/arm/boot/dts/vt8500.dtsi
@@ -0,0 +1,99 @@
+/*
+ * vt8500.dtsi - Device tree file for VIA VT8500 SoC
+ *
+ * Copyright (C) 2012 Tony Prisk 
+ *
+ * Licensed under GPLv2 or later
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+   compatible = "via,vt8500";
+
+   soc {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "simple-bus";
+   ranges;
+   interrupt-parent = <&intc>;
+
+   intc: interrupt-controller@d814 {
+   compatible = "via,vt8500-intc";
+   interrupt-controller;
+   reg = <0xd814 0x1>;
+   #interrupt-cells = <1>;
+   };
+
+   gpio: gpio-controller@d811 {
+   compatible = "via,vt8500-gpio";
+   gpio-controller;
+   reg = <0xd811 0x1>;
+   #gpio-cells = <3>;
+   };
+
+   pmc@d813 {
+   compatible = "via,vt8500-pmc";
+   reg = <0xd813 0x1000>;
+   };
+
+   timer@d8130100 {
+   compatible = "via,vt8500-timer";
+   reg = <0xd8130100 0x28>;
+   interrupts = <36>;
+   };
+
+   ehci@d8007900 {
+   compatible = "via,vt8500-ehci";
+   reg = <0xd8007900 0x200>;
+   interrupts = <43>;
+   };
+
+   uhci@d8007b00 {
+   compatible = "platform-uhci";
+   reg = <0xd8007b00 0x200>;
+   interrupts = <43>;
+   };
+
+   fb@d800e400 {
+   compatible = "via,vt8500-fb";
+   reg = <0xd800e400 0x400>;
+   interrupts = <12>;
+   };
+
+   ge_rops@d8050400 {
+   compatible = "wm,prizm-ge-rops";
+   reg = <0xd8050400 0x100>;
+   };
+
+   uart@d820 {
+   compatible = "via,vt8500-uart";
+   reg = <0xd820 0x1040>;
+   interrupts = <32>;
+   };
+
+   uart@d82b {
+   compatible = "via,vt8500-uart";
+   reg = <0xd82b 0x1040>;
+   interrupts = <33>;
+   };
+
+   uart@d821 {
+   compatible = "via,vt8500-uart";
+   reg = <0xd821 0x1040>;
+   interrupts = <47>;
+   };
+
+   uart@d82c {
+   compatible = "via,vt8500-uart";
+   reg = <0xd82c 0x1040>;
+   interrupts = <50>;
+   };
+
+   rtc@d810 {
+   compatible = "via,vt8500-rtc";
+   reg = <0xd810 0x1>;
+   interrupts = <48>;
+   };
+   };
+};
diff --git a/arch/arm/boot/dts/vt8500_ref.dts b/arch/arm/boot/dts/vt8500_ref.dts
new file mode 100644
index 000..ba5a6af
--- /dev/null
+++ b/arch/arm/boot/dts/vt8500_ref.dts
@@ -0,0 +1,31 @@
+/*
+ * vt8500_ref.dts - Device tree file for Benign BV07 Netbook
+ *
+ * Copyright (C) 2012 Tony Prisk 
+ *
+ * Licensed under GPLv2 or later
+ */
+
+/dts-v1/;
+/include/ "vt8500.dtsi"
+
+/ {
+   model = "Benign BV07 Netbook";
+
+   /*
+* Display node is based on Sascha Hauer's patch on dri-devel.
+* Added a bpp property to calculate the size of the framebuffer
+* until the binding is formalized.
+*/
+   display {
+   xres = <800>;
+   yres = <480>;
+   left-margin = <88>;
+   right-margin = <40>;
+   hsync-len = <0>;
+   upper-margin = <32>;
+   

Re: Do we need asynchronous pm_runtime_get()? (was: Re: bisected regression ...)

[Ming Lei]

On Wed, Aug 8, 2012 at 4:45 AM, Rafael J. Wysocki  wrote:
> On Tuesday, August 07, 2012, Ming Lei wrote:
>> On Tue, Aug 7, 2012 at 7:23 PM, Rafael J. Wysocki  wrote:
>> >> Yes, I agree, but I don't think it may make .runtime_post_resume
>> >> not doable, do I?
>> >
>> > No more device PM callbacks, please.
>>
>> IMO, what the patch is doing is to introduce one callback which
>> is just called after .runtime_resume is completed,
>
> No, it is not a callback.  It is a function to be run _once_ when the device 
> is
> known to be active.  It is not a member of a data type or anything like this.

Looks it was said by Alan, not me, :-)

"The documentation should explain that in some ways, "func" is like a
workqueue callback routine:".

See http://marc.info/?l=linux-usb&m=134426838507799&w=2

>
> It's kind of disappointing that you don't see a difference between that and a
> callback.
>
>> and you want to move something out of previous .runtime_resume
>
> No, I don't.  Where did you get that idea from?

If so, I am wondering why the 'func' can't be called in .runtime_resume
directly, and follow the below inside caller at the same time?

 if (device is active or disabled)
  call func(device).

>
>> and do it in another new callback to speedup resume,
>
> No, not to speed up resume.  The idea is to allow drivers to run something
> when the resume is complete, so that they don't have to implement a "resume
> detection" logic or use .runtime_resume() to run things that don't belong
> there.

Looks it was said by you, :-)

"Unless your _driver_ callback is actually executed from within a PM domain
callback, for example, and something else may be waiting for it to complete,
so your data processing is adding latencies to some other threads.  I'm not
making that up, by the way, that really can happen."

See http://marc.info/?l=linux-pm&m=134394271517527&w=2

Alan also said "Okay, those are valid reasons" for the idea. Except for
this one, I don't see other obvious advantages about the patch.

>
>> so it should be reasonable to introduce the .runtime_post_resume callback in
>> logic.
>
> No.  This doesn't have anything to do with callbacks!
>
> If you want a new callback, you should specify what the role of this callback
> is, otherwise it is not well defined.  I this case, though, what the role of
> func() is depends on the caller and most likely every driver would use it
> for something different.  So no, I don't see how it can be a callback.
>
>> Also, the 'func' should be per driver, not per device since only one
>> 'func' is enough for all same kind of devices driven by one same
>> driver.
>
> It isn't per device!  It is per _caller_.  The fact that the pointer is
> stored _temporarily_ in struct device doesn't mean that it is per device
> and that it is a callback.  From the struct device point of view it is _data_,
> not a member function.

The fact is that it will become per-device one you store it in 'struct device'.

Suppose one driver may drive 1 same devices, the same data will be
stored inside all the 1 device instances, it is a good way to do it?

Not mention 90% devices mayn't use the _temporarily_ data at all.

>
>> > Besides, callbacks in struct dev_pm_ops are not only for drivers.
>>
>> All the current 3 runtime callbacks are for devices. If you mean
>> they can be defined in bus/power_domain/device_type, .runtime_post_resume
>> still can be defined there too.
>
> No, it wouldn't make _any_ _sense_ there, because its role there cannot be
> defined in any sane way.
>
>> >> > Also, "func" should not be stored in dev_pm_ops because it won't be a
>> >> > read-only value.
>> >>
>> >> Sorry, could you explain it in detail that why the 'func'
>> >> has to switch to multiple functions dynamically? I understand
>> >> one function is enough and sometimes it can be bypassed with
>> >> one flag(such as, ignore_post_resume is introduced in dev_pm_info)
>> >> set.  Also, the driver can store the device specific states
>> >> in its own device instance to deal with different situations in the 
>> >> callback.
>> >>
>> >> If the idea is doable, we can save one pointer in 'struct device',
>> >> since the 'func' may not be used by more than 90% devices, also
>> >> have document benefit, even may simplify implementation of the
>> >> mechanism.
>> >
>> > And how many struct device objects there are for the one extra pointer to
>> > matter, let alone the fact that you want to replace it by one extra pointer
>> > somewhere else?
>>
>> For example, in the pandaboard(one omap4 based small system), follows
>> the count of device instances:
>>
>>  [root@root]#dmesg | grep device_add | wc -l
>> 471
>>
>> The above is just a simple configuration(no graphics, no video/video, only
>> console enabled) on Pandaboard.
>>
>> If the callback may be defined in dev_pm_info,
>
> I guess you mean struct dev_pm_ops, right?

Sorry, it is a typo.

>
>> not only memory can be saved, also the

Re: 答复: [PATCH 1/8] USB:support the new interfaces of Huawei Data Card devices in option driver

[g...@kroah.com]

On Wed, Aug 08, 2012 at 01:57:06AM +, Fangxiaozhi (Franko) wrote:
> Dear Greg：
>
> Sorry, this email has included the whole patch. 1/8, I mean that it is submit 
> at Aug. 1st.

No, please don't put the date in the Subject:, that's what the normal
Date field in the email is for :)

> By the way, this patch is not applied to 3.6-rc1, so I have to redo it
> again based on 3.6-rc1, right?

Yes please do so.

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: Kernel Oops while disconnecting USB peripheral (always)

[Sarbojit Ganguly]

Sorry guys I was away due to personal emergency, however now I am back
and will check the reply ASAP.

On 28 July 2012 21:49, Alan Stern  wrote:
> On Sat, 28 Jul 2012, Daniel Mack wrote:
>
>> Hmm, interesting. Thanks for sharing this. I personally never saw this
>> bug kicking in, but if I understand your findings correctly, we would
>> need something like the following patch for snd-usb and the storage driver?
>>
>> Sarbojit, could you give this a test and see whether your kernel still
>> crashes in any of the two drivers?
>
>
>> --- a/drivers/usb/storage/usb.c
>> +++ b/drivers/usb/storage/usb.c
>> @@ -1025,9 +1025,14 @@ void usb_stor_disconnect(struct usb_interface *intf)
>>  {
>> struct us_data *us = usb_get_intfdata(intf);
>>
>> +   if (!us)
>> +   return;
>
> This can never happen.  The disconnect routine gets called only once,
> so us will not be NULL.
>
>> +
>> US_DEBUGP("storage_disconnect() called\n");
>> quiesce_and_remove_host(us);
>> release_everything(us);
>> +
>> +   usb_set_intfdata(intf, NULL);
>>  }
>>  EXPORT_SYMBOL_GPL(usb_stor_disconnect);
>
> Alan Stern
>



-- 
Regards,
Sarbojit
--
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/2] drivers/mmc/host/vub300.c: add missing usb_free_urb

[Chris Ball]

Hi Julia,

On Tue, Jul 24 2012, Julia Lawall wrote:
> From: Julia Lawall 
>
> Add missing usb_free_urb on failure path after usb_alloc_urb.

Thanks, pushed to mmc-next for 3.7.

- Chris.
-- 
Chris Ball  
One Laptop Per Child
--
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: [BUG] Kernel panic when try s3c-hsotg.c with kernel 3.5

[Peiyong Feng]

2012/8/7 Lukasz Majewski :
> On Tue, 07 Aug 2012 11:04:10 +0800
> Peiyong Feng  wrote:
>
>> 2012/8/6 Lukasz Majewski :
>> > Hi,
>> >
>> >> Hi,
>> >>
>> >> On Mon, Aug 06, 2012 at 06:12:05PM +0800, Peiyong Feng wrote:
>> >> > I got a kernel panic when try hsotg of ok6410 which is based on
>> >> > s3c6410:
>> > As you said, you are using the ok6410. And it is "based" on the
>> > s3c6410 CPU. S3C6410 is a single core CPU. I assume that ok6410 is
>> > also single core?
>> yes
>> >
>> >> >
>> >> >
>> >> > cdc_acm: USB Abstract Control Model driver for USB modems and
>> >> > ISDN adapters Unable to handle kernel NULL pointer dereference at
>> >> > virtual address 0100
>> >
>> >> > pgd = c0004000
>> >> > [0100] *pgd=
>> >> > Internal error: Oops: 5 [#1] ARM
>> >> > Modules linked in:
>> >> > CPU: 0Not tainted  (3.5.0 #9)
>> >> > PC is at s3c_hsotg_handle_outdone+0x44/0x158
>> >> > LR is at s3c_hsotg_irq+0x75c/0x804
>> >> > pc : []lr : []psr: 6193
>> >> > sp : c782fd20  ip : 0029  fp : c13a1460
>> >> > r10:   r9 : 0008  r8 : 00d0
>> >> > r7 : c13a1400  r6 : 0002  r5 :   r4 : 00060002
>> >> > r3 : 00d0  r2 :   r1 : 00080200  r0 : c13a1400
>> >> > Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment
>> >> > kernel Control: 00c5387d  Table: 50004008  DAC: 0017
>> >> > Process swapper (pid: 1, stack limit = 0xc782e268)
>> >> > Stack: (0xc782fd20 to 0xc783)
>> >> > fd20: c13a1460 c0200f64  00060002  0002
>> >> > c13a1400 0010 fd40:  c024061c 00060002 
>> >> > 0002 0008 c782fda0 c139a5c0 fd60: c139a5c0 
>> >> >  005a c04cc52c c04cc594 c04ea5fe c00565c0 fd80:
>> >> >    c04cc52c c139a5c0 c04cc57c 
>> >> > c04eb328 fda0: c04cc55c c04eb324 c04c44c0 c0056768 c04cc52c
>> >> > c04cc57c  c0058d64 fdc0: 005a c04d7dd8 
>> >> > c005617c 005a c000efbc c04eb350 0001 fde0: c782fe08
>> >> > c000853c c036c540 6013  c782fe3c c04cc57c c04cc55c
>> >> > fe00: 6013 c000dd80 c04cc57c c782c000  0001
>> >> > 6013 c04cc52c fe20: c139a5c0 005a c04cc57c c04cc55c
>> >> > 6013 c04c44c0 f601 c782fe50 fe40: c036c53c c036c540
>> >> > 6013  c023fec0 c00574c8  c008b2dc fe60:
>> >> > c023fec0   c13a1400 005a c139a5c0 c04cc52c
>> >> > c0057960 fe80: 005a c13a1400 c04c44b8  c051d238
>> >> > c049b0ec  c03688fc fea0: c7853e60 c13a1400 c7804f80
>> >> >  c04c44f4 6013 c7855a80  fec0: c04e1bb4
>> >> > c04c44c0 c04c44c0 c04e1bb4 c04e1bb4 c051d238 c049b0ec 
>> >> > fee0: c04eb040 c020588c c04c44c0 c0204524 c04c44c0 c04c44f4
>> >> > c04e1bb4 c02046ac ff00: c13a01e0 c0204738  c782ff18
>> >> > c04e1bb4 c0202e30 c7803878 c7823700 ff20: c04dd1d0 c040b8d4
>> >> > c04e1bb4 c04e1bb4 c04dd1d0 c0203600 c040b8d4 c01b8568 ff40:
>> >> >   c04e1bb4 0007 c04eb040 c782e000 c04a65e0
>> >> > c0204ce8 ff60:  c04a65d4 0007 c04eb040 c782e000
>> >> > c0008628 c04c7ea0  ff80: 009c  c0625cf9
>> >> > c0037178 0006 0006 c0461b84 c042cee8 ffa0: c04c7ea0
>> >> > c04abdd4 c04a65d4 0007 c04eb040 009c c04841b0 c04a65e0
>> >> > ffc0:  c048430c 0006 0006 c04841b0 
>> >> >  c048421c ffe0: c000f08c 0013  
>> >> >  c000f08c   []
>> >> > (s3c_hsotg_handle_outdone+0x44/0x158) from []
>> >> > (s3c_hsotg_irq+0x75c/0x804) []
>> >> > (s3c_hsotg_irq+0x75c/0x804) from []
>> >> > (handle_irq_event_percpu+0x50/0x1bc) []
>> >> > (handle_irq_event_percpu+0x50/0x1bc) from []
>> >> > (handle_irq_event+0x3c/0x5c) []
>> >> > (handle_irq_event+0x3c/0x5c) from []
>> >> > (handle_level_irq+0x8c/0x118) []
>> >> > (handle_level_irq+0x8c/0x118) from []
>> >> > (generic_handle_irq+0x38/0x44) []
>> >> > (generic_handle_irq+0x38/0x44) from []
>> >> > (handle_IRQ+0x30/0x84) [] (handle_IRQ+0x30/0x84) from
>> >> > [] (vic_handle_irq+0x68/0xa8) []
>> >> > (vic_handle_irq+0x68/0xa8) from []
>> >> > (__irq_svc+0x40/0x60) Exception stack(0xc782fe08 to 0xc782fe50)
>> >> > fe00: c04cc57c c782c000  0001 6013 c04cc52c fe20:
>> >> > c139a5c0 005a c04cc57c c04cc55c 6013 c04c44c0 f601
>> >> > c782fe50 fe40: c036c53c c036c540 6013  []
>> >> > (__irq_svc+0x40/0x60) from []
>> >> > (_raw_spin_unlock_irqrestore+0x10/0x14) []
>> >> > (_raw_spin_unlock_irqrestore+0x10/0x14) from []
>> >> > (__setup_irq+0x178/0x3f8) [] (__setup_irq+0x178/0x3f8)
>> >> > from [] (request_threaded_irq+0xc4/0x12c) []
>> >> > (request_threaded_irq+0xc4/0x12c) from []
>> >> > (s3c_hsotg_probe+0x14c/0x700) []
>> >> > (s3c_hsotg_probe+0x14c/0x700) from []
>> >> > (platform_drv_probe+0x18/0x1c) []
>> >> > (platform_drv_probe+0x18/0x1c) from []
>> >> > (driver_probe_device+0x78/0x200) []
>> >> > (driver_probe_device+0x78/0x200) from [

Re: [PATCH v2] can: kvaser_usb: Add support for Kvaser CAN/USB devices

[Olivier Sobrie]

Hi Oliver,

On Mon, Aug 06, 2012 at 10:10:43AM +0200, Oliver Neukum wrote:
> On Monday 06 August 2012 07:21:29 Olivier Sobrie wrote:
> > This driver provides support for several Kvaser CAN/USB devices.
> > Such kind of devices supports up to three can network interfaces.
> > 
> > It has been tested with a Kvaser USB Leaf Light (one network interface)
> > connected to a pch_can interface.
> > The firmware version of the Kvaser device was 2.5.205.
> 
> > +static netdev_tx_t kvaser_usb_start_xmit(struct sk_buff *skb,
> > +struct net_device *netdev)
> > +{
> > +   struct kvaser_usb_net_priv *priv = netdev_priv(netdev);
> > +   struct kvaser_usb *dev = priv->dev;
> > +   struct net_device_stats *stats = &netdev->stats;
> > +   struct can_frame *cf = (struct can_frame *)skb->data;
> > +   struct kvaser_usb_tx_urb_context *context = NULL;
> > +   struct urb *urb;
> > +   void *buf;
> > +   struct kvaser_msg *msg;
> > +   int i, err;
> > +   int ret = NETDEV_TX_OK;
> > +
> > +   if (can_dropped_invalid_skb(netdev, skb))
> > +   return NETDEV_TX_OK;
> > +
> > +   urb = usb_alloc_urb(0, GFP_ATOMIC);
> > +   if (!urb) {
> > +   netdev_err(netdev, "No memory left for URBs\n");
> > +   stats->tx_dropped++;
> > +   dev_kfree_skb(skb);
> > +   return NETDEV_TX_OK;
> > +   }
> > +
> > +   buf = usb_alloc_coherent(dev->udev, sizeof(struct kvaser_msg),
> > +GFP_ATOMIC, &urb->transfer_dma);
> 
> usb_alloc_coherent() as a rule only makes sense if you reuse the buffer
> and in some cases not even then. Please use a simple kmalloc()

Ok thanks. I'll change it.

> 
> > +   if (!buf) {
> > +   netdev_err(netdev, "No memory left for USB buffer\n");
> > +   stats->tx_dropped++;
> > +   dev_kfree_skb(skb);
> > +   goto nobufmem;
> > +   }
> > +
> > +   msg = (struct kvaser_msg *)buf;
> > +   msg->len = MSG_HEADER_LEN + sizeof(struct kvaser_msg_tx_can);
> > +   msg->u.tx_can.flags = 0;
> > +   msg->u.tx_can.channel = priv->channel;
> > +
> > +   if (cf->can_id & CAN_EFF_FLAG) {
> > +   msg->id = CMD_TX_EXT_MESSAGE;
> > +   msg->u.tx_can.msg[0] = (cf->can_id >> 24) & 0x1f;
> > +   msg->u.tx_can.msg[1] = (cf->can_id >> 18) & 0x3f;
> > +   msg->u.tx_can.msg[2] = (cf->can_id >> 14) & 0x0f;
> > +   msg->u.tx_can.msg[3] = (cf->can_id >> 6) & 0xff;
> > +   msg->u.tx_can.msg[4] = cf->can_id & 0x3f;
> > +   } else {
> > +   msg->id = CMD_TX_STD_MESSAGE;
> > +   msg->u.tx_can.msg[0] = (cf->can_id >> 6) & 0x1f;
> > +   msg->u.tx_can.msg[1] = cf->can_id & 0x3f;
> > +   }
> > +
> > +   msg->u.tx_can.msg[5] = cf->can_dlc;
> > +   memcpy(&msg->u.tx_can.msg[6], cf->data, cf->can_dlc);
> > +
> > +   if (cf->can_id & CAN_RTR_FLAG)
> > +   msg->u.tx_can.flags |= MSG_FLAG_REMOTE_FRAME;
> > +
> > +   for (i = 0; i < ARRAY_SIZE(priv->tx_contexts); i++) {
> > +   if (priv->tx_contexts[i].echo_index == MAX_TX_URBS) {
> > +   context = &priv->tx_contexts[i];
> > +   break;
> > +   }
> > +   }
> > +
> > +   if (!context) {
> > +   netdev_warn(netdev, "cannot find free context\n");
> > +   ret =  NETDEV_TX_BUSY;
> > +   goto releasebuf;
> > +   }
> > +
> > +   context->priv = priv;
> > +   context->echo_index = i;
> > +   context->dlc = cf->can_dlc;
> > +
> > +   msg->u.tx_can.tid = context->echo_index;
> > +
> > +   usb_fill_bulk_urb(urb, dev->udev,
> > + usb_sndbulkpipe(dev->udev,
> > + dev->bulk_out->bEndpointAddress),
> > + buf, msg->len,
> > + kvaser_usb_write_bulk_callback, context);
> > +   urb->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
> > +   usb_anchor_urb(urb, &priv->tx_submitted);
> > +
> > +   can_put_echo_skb(skb, netdev, context->echo_index);
> > +
> > +   atomic_inc(&priv->active_tx_urbs);
> > +
> > +   if (atomic_read(&priv->active_tx_urbs) >= MAX_TX_URBS)
> > +   netif_stop_queue(netdev);
> > +
> > +   err = usb_submit_urb(urb, GFP_ATOMIC);
> > +   if (unlikely(err)) {
> > +   can_free_echo_skb(netdev, context->echo_index);
> > +
> > +   atomic_dec(&priv->active_tx_urbs);
> > +   usb_unanchor_urb(urb);
> > +
> > +   stats->tx_dropped++;
> > +
> > +   if (err == -ENODEV)
> > +   netif_device_detach(netdev);
> > +   else
> > +   netdev_warn(netdev, "Failed tx_urb %d\n", err);
> > +
> > +   goto releasebuf;
> > +   }
> > +
> > +   netdev->trans_start = jiffies;
> > +
> > +   usb_free_urb(urb);
> > +
> > +   return NETDEV_TX_OK;
> > +
> > +releasebuf:
> > +   usb_free_coherent(dev->udev, sizeof(struct kvaser_msg),
> > + buf, urb->transfer_dma);
> > +nobufmem:
> > +   usb_free_urb(urb);
> > +   return ret;
> > +}
> 
> > +static int kvaser_usb_init_one(stru

Re: [PATCH 1/2] usb: musb: use DMA mode 1 whenever possible

[Rajaram R]

On Tue, Aug 7, 2012 at 6:39 PM, Roger Quadros  wrote:
> Do not rely on any hints from gadget drivers and use DMA mode 1
> whenever we expect data of at least the endpoint's packet size and
> have not yet received a short packet.

Could you please let us know what all combination this was tested ?
What will happen if the request length is 513 ?

>
> The last packet if short is always transferred using DMA mode 0.
>
> This patch fixes USB throughput issues in mass storage mode for
> host to device transfers.
>
> Signed-off-by: Roger Quadros 
> ---
>  drivers/usb/musb/musb_gadget.c |   30 --
>  1 files changed, 4 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
> index 8d2cce1..5c4392b 100644
> --- a/drivers/usb/musb/musb_gadget.c
> +++ b/drivers/usb/musb/musb_gadget.c
> @@ -707,12 +707,11 @@ static void rxstate(struct musb *musb, struct 
> musb_request *req)
> fifo_count = musb_readw(epio, MUSB_RXCOUNT);
>
> /*
> -* Enable Mode 1 on RX transfers only when short_not_ok flag
> -* is set. Currently short_not_ok flag is set only from
> -* file_storage and f_mass_storage drivers
> +*  use mode 1 only if we expect data of at least ep packet_sz
> +*  and have not yet received a short packet
>  */
> -
> -   if (request->short_not_ok && fifo_count == musb_ep->packet_sz)
> +   if ((request->length - request->actual >= musb_ep->packet_sz) 
> &&
> +   (fifo_count >= musb_ep->packet_sz))
> use_mode_1 = 1;
> else
> use_mode_1 = 0;
> @@ -727,27 +726,6 @@ static void rxstate(struct musb *musb, struct 
> musb_request *req)
> c = musb->dma_controller;
> channel = musb_ep->dma;
>
> -   /* We use DMA Req mode 0 in rx_csr, and DMA controller operates in
> -* mode 0 only. So we do not get endpoint interrupts due to DMA
> -* completion. We only get interrupts from DMA controller.
> -*
> -* We could operate in DMA mode 1 if we knew the size of the tranfer
> -* in advance. For mass storage class, request->length = what the host
> -* sends, so that'd work.  But for pretty much everything else,
> -* request->length is routinely more than what the host sends. For
> -* most these gadgets, end of is signified either by a short packet,
> -* or filling the last byte of the buffer.  (Sending extra data in
> -* that last pckate should trigger an overflow fault.)  But in mode 1,
> -* we don't get DMA completion interrupt for short packets.
> -*
> -* Theoretically, we could enable DMAReq irq (MUSB_RXCSR_DMAMODE = 1),
> -* to get endpoint interrupt on every DMA req, but that didn't seem
> -* to work reliably.
> -*
> -* REVISIT an updated g_file_storage can set req->short_not_ok, which
> -* then becomes usable as a runtime "use mode 1" hint...
> -*/
> -
> /* Experimental: Mode1 works with mass 
> storage use cases */
> if (use_mode_1) {
> csr |= MUSB_RXCSR_AUTOCLEAR;
> --
> 1.7.4.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [BUG] Kernel panic when try s3c-hsotg.c with kernel 3.5

[Lukasz Majewski]

Dear Peiyong Feng,

> > Please enable the debug at s3c-hsotg.c driver and then paste the
> > dmesg/debug output.  
> I have defined DEGUG in s3c-hsotg.c

Thank you for 2.6.36 log.
I'd also need the log from 3.6-rc1 kernel with DEBUG enabled.

-- 
Best regards,

Lukasz Majewski

Samsung Poland R&D Center | Linux Platform Group
--
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] can: kvaser_usb: Add support for Kvaser CAN/USB devices

[Olivier Sobrie]

Hi Wolfgang,

On Tue, Aug 07, 2012 at 08:26:38AM +0200, Wolfgang Grandegger wrote:
> On 08/06/2012 07:21 AM, Olivier Sobrie wrote:
> > This driver provides support for several Kvaser CAN/USB devices.
> > Such kind of devices supports up to three can network interfaces.
> 
> s/can/CAN/
> 
> > It has been tested with a Kvaser USB Leaf Light (one network interface)
> > connected to a pch_can interface.
> > The firmware version of the Kvaser device was 2.5.205.
> > 
> > List of Kvaser devices supported by the driver:
> >   - Kvaser Leaf prototype (P010v2 and v3)
> >   - Kvaser Leaf Light (P010v3)
> >   - Kvaser Leaf Professional HS
> >   - Kvaser Leaf SemiPro HS
> >   - Kvaser Leaf Professional LS
> >   - Kvaser Leaf Professional SWC
> >   - Kvaser Leaf Professional LIN
> >   - Kvaser Leaf SemiPro LS
> >   - Kvaser Leaf SemiPro SWC
> >   - Kvaser Memorator II, Prototype
> >   - Kvaser Memorator II HS/HS
> >   - Kvaser USBcan Professional HS/HS
> >   - Kvaser Leaf Light GI
> >   - Kvaser Leaf Professional HS (OBD-II connector)
> >   - Kvaser Memorator Professional HS/LS
> >   - Kvaser Leaf Light "China"
> >   - Kvaser BlackBird SemiPro
> >   - Kvaser OEM Mercury
> >   - Kvaser OEM Leaf
> >   - Kvaser USBcan R
> 
> Impressive list! What CAN controllers are used inside the devices? SJA1000?

I took this list from the Kvaser driver. However I only have a Kvaser
Leaf Light device thus I'm not sure it will work with other ones.
If you prefer I can only let Kvaser Leaf Light instead of the full list.
In my device it looks to be a Renesas M16C controller.

> 
> > Signed-off-by: Olivier Sobrie 
> > ---
> > Changes since v1:
> >   - added copyrights
> >   - kvaser_usb.h merged into kvaser.c
> >   - added kvaser_usb_get_endpoints to find eindpoints instead of
> > hardcoding their address
> >   - some cleanup and comestic changes
> >   - fixed issues with errors handling
> >   - fixed restart-ms == 0 case
> >   - removed do_get_berr_counter method since the hardware doens't return
> > good values for txerr and rxerr.
> > 
> > If someone in the linux-usb mailing can review it, it would be nice.
> > 
> > Concerning the errors, it behaves like that now:
> > 
> > 1) Short-circuit CAN-H and CAN-L and restart-ms = 0
> > 
> > t0: short-circuit + 'cansend can1 123#112233'
> > 
> >   can1  208C  [8] 00 0C 90 00 00 00 00 00   ERRORFRAME
> > controller-problem{rx-error-warning,tx-error-warning}
> > protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
> > bus-error
> >   can1  208C  [8] 00 30 90 00 00 00 00 00   ERRORFRAME
> > controller-problem{rx-error-passive,tx-error-passive}
> > protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
> > bus-error
> >   can1  20C8  [8] 00 00 90 00 00 00 00 00   ERRORFRAME
> > protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
> > bus-off
> > bus-error
> > 
> > t1: remove short-circuit + 'ip link set can1 type can restart'
> > 
> >   can1  2100  [8] 00 00 00 00 00 00 00 00   ERRORFRAME
> > restarted-after-bus-off
> >   can1  2004  [8] 00 0C 00 00 00 00 00 00   ERRORFRAME
> > controller-problem{rx-error-warning,tx-error-warning}
> 
> Why do we get the last error message? Maybe the firmware does it that
> way (going down passive->warning->active).

It goes in that order: warning -> passive -> bus off -> warning
-> passive -> ...

> 
> > 2) Short-circuit CAN-H and CAN-L and restart-ms = 100
> > 
> > t0: short-circuit + cansend can1 123#112233
> > 
> >   can1  208C  [8] 00 0C 90 00 00 00 00 00   ERRORFRAME
> > controller-problem{rx-error-warning,tx-error-warning}
> > protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
> > bus-error
> >   can1  208C  [8] 00 30 90 00 00 00 00 00   ERRORFRAME
> > controller-problem{rx-error-passive,tx-error-passive}
> > protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
> > bus-error
> >   can1  20C8  [8] 00 00 90 00 00 00 00 00   ERRORFRAME
> > protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
> > bus-off
> > bus-error
> >   can1  218C  [8] 00 0C 90 00 00 00 00 00   ERRORFRAME
> > controller-problem{rx-error-warning,tx-error-warning}
> > protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
> > bus-error
> > restarted-after-bus-off
> >   can1  208C  [8] 00 0C 90 00 00 00 00 00   ERRORFRAME
> > controller-problem{rx-error-warning,tx-error-warning}
> > protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
> > bus-error
> >   can1  208C  [8] 00 30 90 00 00 00 00 00   ERRORFRAME
> > controller-problem{rx-error-passive,tx-error-passive}
> > protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
> > bus-error
> >   can1  20C8  [8] 00 00 90 00 00 00 00 00   ERRORFRAME
> > protocol-violation{{tx-recessive-bit-error,error-on-tx}{}}
> > bus-off
> > bus-error
> >   ...
> > 
> >   can1  218C  [8] 00 0C 90 00 00 00 00 00   ERRORFRAME
> >  

RE: [PATCH v2] usb:musb:musb_host: Handle highmem in PIO mode

[Virupax SADASHIVPETIMATH]

> -Original Message-
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: Tuesday, August 07, 2012 11:17 PM
> To: Virupax SADASHIVPETIMATH
> Cc: ba...@ti.com; gre...@linuxfoundation.org; linux-usb@vger.kernel.org; 
> linux-
> ker...@vger.kernel.org; linus.wall...@linaro.org; Praveena NADAHALLY; Rajaram
> REGUPATHY; Vikrant BAPAT
> Subject: Re: [PATCH v2] usb:musb:musb_host: Handle highmem in PIO mode
> 
> 
> > +*/
> > +   if (!urb->transfer_buffer)
> > +   use_sg = true;
> 
> Here you test urb->transfer_buffer.

I will make the test as 
if (!use_sg && !urb->transfer_buffer)
use_sg = true;

> > +   if (use_sg) {
> > +   /* sg_miter_start is already done in musb_ep_program */
> > +   if (!sg_miter_next(&qh->sg_miter)) {
> > +   dev_err(musb->controller, "error: sg list empty\n");
> > +   sg_miter_stop(&qh->sg_miter);
> > +   status = -EINVAL;
> > +   goto done;
> > +   }
> > +   urb->transfer_buffer = qh->sg_miter.addr;
> 
> And here you set it.  As a result, on the next iteration of this
> routine the test above won't work right.  (This function gets invoked
> once for each entry in the sg list, right?)
> 
> Is there any reason to set urb->transfer_buffer here?  You could just
> use qh->sg_miter.addr directly in the musb_write_fifo() call two lines
> below.

I will change it. 

Thanks 
Virupax S 


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

[PATCH v3] usb:musb:musb_host: Handle highmem in PIO mode

[Virupax Sadashivpetimath]

In case of USB bulk transfer, when himem page
is received, the usb_sg_init function sets the
urb transfer buffer to NULL. When such URB
transfer is handled, kernel crashes in PIO mode.
Handle this by mapping the highmem buffer in PIO mode.

Signed-off-by: Virupax Sadashivpetimath 

Signed-off-by: Praveena NADAHALLY 
Acked-by: Linus Walleij 
---
 drivers/usb/musb/musb_host.c |   97 +++--
 drivers/usb/musb/musb_host.h |3 +
 2 files changed, 95 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 4bb717d..3ba9a4b 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -813,9 +813,28 @@ static void musb_ep_program(struct musb *musb, u8 epnum,
if (load_count) {
/* PIO to load FIFO */
qh->segsize = load_count;
-   musb_write_fifo(hw_ep, load_count, buf);
+   if (!buf) {
+   sg_miter_start(&qh->sg_miter, urb->sg, 1,
+   SG_MITER_ATOMIC
+   | SG_MITER_FROM_SG);
+   if (!sg_miter_next(&qh->sg_miter)) {
+   dev_err(musb->controller,
+   "error: sg"
+   "list empty\n");
+   sg_miter_stop(&qh->sg_miter);
+   goto finish;
+   }
+   buf = qh->sg_miter.addr + urb->sg->offset +
+   urb->actual_length;
+   load_count = min_t(u32, load_count,
+   qh->sg_miter.length);
+   musb_write_fifo(hw_ep, load_count, buf);
+   qh->sg_miter.consumed = load_count;
+   sg_miter_stop(&qh->sg_miter);
+   } else
+   musb_write_fifo(hw_ep, load_count, buf);
}
-
+finish:
/* re-enable interrupt */
musb_writew(mbase, MUSB_INTRTXE, int_txe);
 
@@ -1116,6 +1135,7 @@ void musb_host_tx(struct musb *musb, u8 epnum)
void __iomem*mbase = musb->mregs;
struct dma_channel  *dma;
booltransfer_pending = false;
+   static bool use_sg;
 
musb_ep_select(mbase, epnum);
tx_csr = musb_readw(epio, MUSB_TXCSR);
@@ -1163,6 +1183,7 @@ void musb_host_tx(struct musb *musb, u8 epnum)
return;
}
 
+done:
if (status) {
if (dma_channel_status(dma) == MUSB_DMA_STATUS_BUSY) {
dma->status = MUSB_DMA_STATUS_CORE_ABORT;
@@ -1332,9 +1353,37 @@ void musb_host_tx(struct musb *musb, u8 epnum)
length = qh->maxpacket;
/* Unmap the buffer so that CPU can use it */
usb_hcd_unmap_urb_for_dma(musb_to_hcd(musb), urb);
-   musb_write_fifo(hw_ep, length, urb->transfer_buffer + offset);
+
+   /*
+* We need to map sg if the transfer_buffer is
+* NULL.
+*/
+   if (!use_sg && !urb->transfer_buffer)
+   use_sg = true;
+
+   if (use_sg) {
+   /* sg_miter_start is already done in musb_ep_program */
+   if (!sg_miter_next(&qh->sg_miter)) {
+   dev_err(musb->controller, "error: sg list empty\n");
+   sg_miter_stop(&qh->sg_miter);
+   status = -EINVAL;
+   goto done;
+   }
+   length = min_t(u32, length, qh->sg_miter.length);
+   musb_write_fifo(hw_ep, length, qh->sg_miter.addr);
+   qh->sg_miter.consumed = length;
+   sg_miter_stop(&qh->sg_miter);
+   } else {
+   musb_write_fifo(hw_ep, length, urb->transfer_buffer + offset);
+   }
+
qh->segsize = length;
 
+   if (use_sg) {
+   if (offset + length >= urb->transfer_buffer_length)
+   use_sg = false;
+   }
+
musb_ep_select(mbase, epnum);
musb_writew(epio, MUSB_TXCSR,
MUSB_TXCSR_H_WZC_BITS | MUSB_TXCSR_TXPKTRDY);
@@ -1442,6 +1491,8 @@ void musb_host_rx(struct musb *musb, u8 epnum)
booldone = false;
u32 status;
struct dma_channel  *dma;
+   static bool use_sg;
+   unsigned int sg_flags = SG_MITER_ATOMIC | SG_MITER_TO_SG;
 
musb_ep_select(mbase, epnum);
 
@@ -1756,10 +1807,43 @@ void musb_host_rx(struct musb *musb, u8 epnum)
 #endif /* Mentor DMA */
 
if (!dma) {
+   unsigned int received_len;
+
/* Unmap th

Re: [BUG] Kernel panic when try s3c-hsotg.c with kernel 3.5

[Peiyong Feng]

2012/8/8 Lukasz Majewski :
> Dear Peiyong Feng,
>
>> > Please enable the debug at s3c-hsotg.c driver and then paste the
>> > dmesg/debug output.
>> I have defined DEGUG in s3c-hsotg.c
>
> Thank you for 2.6.36 log.
> I'd also need the log from 3.6-rc1 kernel with DEBUG enabled.
I have made a define like:
#define DEBUG
in s3c-hsotg.c of 3.6-rc1 kernel and the patch:
==
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index b13e0bb..b35d275 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -36,6 +36,7 @@

 #include 

+#define DEBUG
 #include "s3c-hsotg.h"

 #define DMA_ADDR_INVALID (~((dma_addr_t)0))
=-

And the output is just the same as I have posted.

If that is not the way you want, please let me know.


>
> --
> Best regards,
>
> Lukasz Majewski
>
> Samsung Poland R&D Center | Linux Platform Group
--
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