Re: ARM juno R2 board USB Issue (EHCI probe failed)

2016-09-27 Thread Vikas Sajjan
Adding USB mailing list.


On Tue, Sep 27, 2016 at 12:33 PM, Sajjan, Vikas C
<vikas.cha.saj...@hpe.com> wrote:
> Hi All,
>
> I working on ARM juno R2 board, with latest kernel 4.8.rc7 and I get below 
> USB EHCI probe error while booting with acpi=force.
>
> EFI stub: Booting Linux Kernel...
> ConvertPages: Incompatible memory types
> EFI stub: Using DTB from command line
> EFI stub: Exiting boot services and installing virtual address map...
> [0.00] Booting Linux on physical CPU 0x100
> [0.00] Linux version 4.8.0-rc7-00142-gb1f2beb (vikas@dctxvm241) (gcc 
> version 4.8.3 20140401 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2014.04 - 
> Linaro GCC 4.8-2014.04) ) #48 SMP PREEMPT Mon Sep 26 15:31:48 IST 2016
> [0.00] Boot CPU: AArch64 Processor [410fd033]
> [0.00] efi: Getting EFI parameters from FDT:
> [0.00] efi: EFI v2.50 by ARM Juno EFI Oct 15 2015 14:16:39
> [0.00] efi:  ACPI=0xfe75  ACPI 2.0=0xfe750014  PROP=0xfe794370
> [0.00] cma: Reserved 16 MiB at 0xfd40
> [0.00] ACPI: Early table checksum verification disabled
> [0.00] ACPI: RSDP 0xFE750014 24 (v02 ARMLTD)
> [0.00] ACPI: XSDT 0xFE7400E8 3C (v01 ARMLTD ARM-JUNO 
> 20140727  0113)
> [0.00] ACPI: FACP 0xFE72 00010C (v05 ARMLTD ARM-JUNO 
> 20140727 ARM  0099)
> [0.00] ACPI: DSDT 0xFE6F 000317 (v01 ARMLTD ARM-JUNO 
> 20140727 INTL 20140214)
> [0.00] ACPI: GTDT 0xFE71 60 (v02 ARMLTD ARM-JUNO 
> 20140727 ARM  0099)
> [0.00] ACPI: APIC 0xFE70 000224 (v01 ARMLTD ARM-JUNO 
> 20140727 ARM  0099)
> [0.00] psci: probing for conduit method from ACPI.
> [0.00] psci: PSCIv1.0 detected in firmware.
> [0.00] psci: Using standard PSCI v0.2 function IDs
> [0.00] psci: MIGRATE_INFO_TYPE not supported.
> [0.00] percpu: Embedded 21 pages/cpu @80097feb8000 s47488 r8192 
> d30336 u86016
> [0.00] Detected VIPT I-cache on CPU0
> [0.00] CPU features: enabling workaround for ARM erratum 845719
> [0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
> pages: 2060048
> [0.00] Kernel command line: dtb=board.dtb initrd=ramdisk.img 
> console=ttyAMA0,115200 acpi=force root=/dev/sda1
> [0.00] log_buf_len individual max cpu contribution: 4096 bytes
> [0.00] log_buf_len total cpu_extra contributions: 20480 bytes
> . .  . . . .  . .
> . .  . . . .  . .
> . .  . . . .  . .
> . .  . . . .  . .
> [1.223662] VFIO - User Level meta-driver version: 0.3
> [1.229335] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> [1.235882] ehci-pci: EHCI PCI platform driver
> [1.240359] ehci-platform: EHCI generic platform driver
> [1.245619] ehci-platform ARMH0D20:00: Error: DMA mask configuration failed
> [1.272491] ehci-platform: probe of ARMH0D20:00 failed with error -5
> [1.278876] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> [1.285071] ohci-pci: OHCI PCI platform driver
> [1.289548] ohci-platform: OHCI generic platform driver
> [1.294884] usbcore: registered new interface driver usb-storage
> [1.301231] mousedev: PS/2 mouse device common for all mice
> [1.307197] rtc-efi rtc-efi: rtc core: registered rtc-efi as rtc0
>
> But this error goes off, if I don't force ACPI booting, i.e., if I remove 
> acpi=force from kernel command line , USB is detected  and my RFS which is in 
> the usb drive, gets mounted successfully.
>
> Thanks and Regards
> Vikas Sajjan
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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 0/4] dts: Add usb2phy to Exynos 5250/5420

2014-05-19 Thread Vikas Sajjan
Based on 'for-next' branch of Kgene's linux-samsung tree.
These patches are as per discussions on the driver side patches
which have already been acked. [1]

Changes from v2:
- Addressed kukjin's comments to update DT binding documentation for 
sysreg.
- removed the version for each patch. Made all patches version as same.

Changes from v1:
 - Rebase on 'for-next' branch.
 - Removed 'phy-names' property as per discuusion in the driver patches. [1]

V1 of this series was the next version for earlier patch-series:
[PATCH v7 0/2] dts: Add usb2phy to Exynos 5250 [2]

Changes from v7 series:
 - Added patches to enable usb 2.0 support on exynos5420;
   which include dt nodes for usb2phy as well as ehci and ohci
   controllers.

Changes from v6:
 - Splitted the patch into two:
adding syscon nodes to Exynos5250 and Exynos5420 in first;
and phy entry change in the second.
 - Changed the name of phandle for usb2phy from 'usb2_phy_new'
   to 'usb2_phy_gen' indicating generic phy.
 - Using clock macros in dt entries.

[1] http://www.spinics.net/lists/linux-usb/msg106908.html
http://www.spinics.net/lists/linux-usb/msg106837.html
[2] http://www.spinics.net/lists/linux-usb/msg106427.html

Kamil Debski (1):
  ARM: dts: Add usb2phy to Exynos 5250

Vivek Gautam (3):
  ARM: dts: Add sysreg sytem controller node to exynos5250 and
exynos5420
  ARM: dts: Add usb2phy support on exynos5420
  ARM: dts: Add usb 2.0 support on exynos5420

 .../devicetree/bindings/arm/samsung/sysreg.txt |   11 -
 arch/arm/boot/dts/exynos5250.dtsi  |   27 
 arch/arm/boot/dts/exynos5420.dtsi  |   45 
 3 files changed, 81 insertions(+), 2 deletions(-)

-- 
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 V3 1/4] ARM: dts: Add sysreg sytem controller node to exynos5250 and exynos5420

2014-05-19 Thread Vikas Sajjan
From: Vivek Gautam gautam.vi...@samsung.com

This patch adds sysreg-syscon node to exynos5250 and exynos5420 device
tree, to access System Register's registers using syscon driver.

Signed-off-by: Kamil Debski k.deb...@samsung.com
[gautam.vi...@samsung.com: Split this syreg-syscon dts entry from
dts: Add usb2phy to Exynos 5250 patch]
[gautam.vi...@samsung.com: added similar syscon entry for exynos5420]
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
[vikas.saj...@samsung.com: updated the binding document]
Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
---
 .../devicetree/bindings/arm/samsung/sysreg.txt |   11 +--
 arch/arm/boot/dts/exynos5250.dtsi  |5 +
 arch/arm/boot/dts/exynos5420.dtsi  |5 +
 3 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt 
b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
index 0ab3251..4fced6e 100644
--- a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
@@ -1,8 +1,10 @@
 SAMSUNG S5P/Exynos SoC series System Registers (SYSREG)
 
 Properties:
- - compatible : should contain samsung,chip name-sysreg, syscon;
-   For Exynos4 SoC series it should be samsung,exynos4-sysreg, syscon;
+ - compatible : should contain two values. First value must be one from 
following list:
+   - samsung,exynos4-sysreg - for Exynos4 based SoCs,
+   - samsung,exynos5-sysreg - for Exynos5 based SoCs.
+   second value must be always syscon.
  - reg : offset and length of the register set.
 
 Example:
@@ -10,3 +12,8 @@ Example:
compatible = samsung,exynos4-sysreg, syscon;
reg = 0x1001 0x400;
};
+
+   syscon@1005 {
+   compatible = samsung,exynos5-sysreg, syscon;
+   reg = 0x1005 0x5000;
+   };
diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 68a3e6f..8e9b9a3 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -193,6 +193,11 @@
reg = 0x1004 0x5000;
};
 
+   sysreg_system_controller: syscon@1005 {
+   compatible = samsung,exynos5-sysreg, syscon;
+   reg = 0x1005 0x5000;
+   };
+
watchdog@101D {
compatible = samsung,exynos5250-wdt;
reg = 0x101D 0x100;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 13a083e..f9b051b 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -725,6 +725,11 @@
reg = 0x1004 0x5000;
};
 
+   sysreg_system_controller: syscon@1005 {
+   compatible = samsung,exynos5-sysreg, syscon;
+   reg = 0x1005 0x5000;
+   };
+
tmu_cpu0: tmu@1006 {
compatible = samsung,exynos5420-tmu;
reg = 0x1006 0x100;
-- 
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 V3 3/4] ARM: dts: Add usb2phy support on exynos5420

2014-05-19 Thread Vikas Sajjan
From: Vivek Gautam gautam.vi...@samsung.com

Add required device node for usb2phy to let enable USB 2.0
support.

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
 arch/arm/boot/dts/exynos5420.dtsi |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index f9b051b..2eb00cb 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -838,4 +838,14 @@
samsung,pmu-syscon = pmu_system_controller;
#phy-cells = 1;
};
+
+   usb2_phy: phy@1213 {
+   compatible = samsung,exynos5250-usb2-phy;
+   reg = 0x1213 0x100;
+   clocks = clock CLK_USBH20, clock CLK_SCLK_USBPHY300;
+   clock-names = phy, ref;
+   #phy-cells = 1;
+   samsung,sysreg-phandle = sysreg_system_controller;
+   samsung,pmureg-phandle = pmu_system_controller;
+   };
 };
-- 
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 V3 4/4] ARM: dts: Add usb 2.0 support on exynos5420

2014-05-19 Thread Vikas Sajjan
From: Vivek Gautam gautam.vi...@samsung.com

Add required device node for ehci and ohci controllers to
enable USB 2.0 support.

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
 arch/arm/boot/dts/exynos5420.dtsi |   30 ++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 2eb00cb..921885a 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -839,6 +839,36 @@
#phy-cells = 1;
};
 
+   usbhost2: usb@1211 {
+   compatible = samsung,exynos4210-ehci;
+   reg = 0x1211 0x100;
+   interrupts = 0 71 0;
+
+   clocks = clock CLK_USBH20;
+   clock-names = usbhost;
+   #address-cells = 1;
+   #size-cells = 0;
+   port@0 {
+   reg = 0;
+   phys = usb2_phy 1;
+   };
+   };
+
+   usbhost1: usb@1212 {
+   compatible = samsung,exynos4210-ohci;
+   reg = 0x1212 0x100;
+   interrupts = 0 71 0;
+
+   clocks = clock CLK_USBH20;
+   clock-names = usbhost;
+   #address-cells = 1;
+   #size-cells = 0;
+   port@0 {
+   reg = 0;
+   phys = usb2_phy 1;
+   };
+   };
+
usb2_phy: phy@1213 {
compatible = samsung,exynos5250-usb2-phy;
reg = 0x1213 0x100;
-- 
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 V3 2/4] ARM: dts: Add usb2phy to Exynos 5250

2014-05-19 Thread Vikas Sajjan
From: Kamil Debski k.deb...@samsung.com

Add support to PHY of USB2 of the Exynos 5250 SoC.

Signed-off-by: Kamil Debski k.deb...@samsung.com
[gautam.vi...@samsung.com: Split the usb phy entries from
syscon entries from earlier patch: dts: Add usb2phy to Exynos 5250]
[gautam.vi...@samsung.com: Added phy entry for OHCI also along with EHCI]
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
 arch/arm/boot/dts/exynos5250.dtsi |   22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 8e9b9a3..cb29642 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -577,6 +577,12 @@
 
clocks = clock CLK_USB2;
clock-names = usbhost;
+   #address-cells = 1;
+   #size-cells = 0;
+   port@0 {
+   reg = 0;
+   phys = usb2_phy_gen 1;
+   };
};
 
usb@1212 {
@@ -586,6 +592,12 @@
 
clocks = clock CLK_USB2;
clock-names = usbhost;
+   #address-cells = 1;
+   #size-cells = 0;
+   port@0 {
+   reg = 0;
+   phys = usb2_phy_gen 1;
+   };
};
 
usb2_phy: usbphy@1213 {
@@ -603,6 +615,16 @@
};
};
 
+   usb2_phy_gen: phy@1213 {
+   compatible = samsung,exynos5250-usb2-phy;
+   reg = 0x1213 0x100;
+   clocks = clock CLK_USB2, clock CLK_FIN_PLL;
+   clock-names = phy, ref;
+   #phy-cells = 1;
+   samsung,sysreg-phandle = sysreg_system_controller;
+   samsung,pmureg-phandle = pmu_system_controller;
+   };
+
pwm: pwm@12dd {
compatible = samsung,exynos4210-pwm;
reg = 0x12dd 0x100;
-- 
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] USB: core: Add warm reset while reset-resuming SuperSpeed HUBs

2013-12-09 Thread Vikas Sajjan
Does warm reset while activating SuperSpeed HUBs if the hub activate type
is HUB_RESET_RESUME.

When we do Suspend-to-RAM with (any one of the 16, 32, 64 Jetflash) transcend
USB 3.0 device connected on 3.0 port, during resume I noticed that the
XHCI controller has moved to sometimes RECOVERY, POLLING or INACTIVE STATE.
This behaviour is inconsistent and the connection with connected USB 3.0 device
on 3.0 port was LOST.

Doing warm reset while activating SuperSpeed HUBs if the hub
activate type is HUB_RESET_RESUME, gets the connected device to the stable 
state.

Reviewed at https://chromium-review.googlesource.com/#/c/177132/

Tested on exynos5420 and exynos5250 with Transcend Jetflash USB 3.0 device 
(8564:1000)

rebased on Greg Kroah-Hartman's usb-next
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git

Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
---
 drivers/usb/core/hub.c |   41 +
 1 file changed, 25 insertions(+), 16 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index a7c04e2..d8432b0 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -993,6 +993,21 @@ int usb_remove_device(struct usb_device *udev)
return 0;
 }
 
+#define PORT_RESET_TRIES   5
+#define SET_ADDRESS_TRIES  2
+#define GET_DESCRIPTOR_TRIES   2
+#define SET_CONFIG_TRIES   (2 * (use_both_schemes + 1))
+#define USE_NEW_SCHEME(i)  ((i) / 2 == (int)old_scheme_first)
+
+#define HUB_ROOT_RESET_TIME50  /* times are in msec */
+#define HUB_SHORT_RESET_TIME   10
+#define HUB_BH_RESET_TIME  50
+#define HUB_LONG_RESET_TIME200
+#define HUB_RESET_TIMEOUT  800
+
+static int hub_port_reset(struct usb_hub *hub, int port1,
+   struct usb_device *udev, unsigned int delay, bool warm);
+
 enum hub_activation_type {
HUB_INIT, HUB_INIT2, HUB_INIT3, /* INITs must come first */
HUB_POST_RESET, HUB_RESUME, HUB_RESET_RESUME,
@@ -1093,6 +1108,16 @@ static void hub_activate(struct usb_hub *hub, enum 
hub_activation_type type)
u16 portstatus, portchange;
 
portstatus = portchange = 0;
+
+   /* Some connected devices might be still in unknown state even
+* after reset-resume, a WARM_RESET gets the connected device
+* to the normal state.
+*/
+   if (udev  hub_is_superspeed(hub-hdev) 
+   type == HUB_RESET_RESUME)
+   hub_port_reset(hub, port1, NULL,
+   HUB_BH_RESET_TIME, true);
+
status = hub_port_status(hub, port1, portstatus, portchange);
if (udev || (portstatus  USB_PORT_STAT_CONNECTION))
dev_dbg(hub-intfdev,
@@ -2510,22 +2535,6 @@ static unsigned hub_is_wusb(struct usb_hub *hub)
return hcd-wireless;
 }
 
-
-#define PORT_RESET_TRIES   5
-#define SET_ADDRESS_TRIES  2
-#define GET_DESCRIPTOR_TRIES   2
-#define SET_CONFIG_TRIES   (2 * (use_both_schemes + 1))
-#define USE_NEW_SCHEME(i)  ((i) / 2 == (int)old_scheme_first)
-
-#define HUB_ROOT_RESET_TIME50  /* times are in msec */
-#define HUB_SHORT_RESET_TIME   10
-#define HUB_BH_RESET_TIME  50
-#define HUB_LONG_RESET_TIME200
-#define HUB_RESET_TIMEOUT  800
-
-static int hub_port_reset(struct usb_hub *hub, int port1,
-   struct usb_device *udev, unsigned int delay, bool warm);
-
 /* Is a USB 3.0 port in the Inactive or Complinance Mode state?
  * Port worm reset is required to recover
  */
-- 
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


Re: [PATCH] USB: core: Add warm reset while reset-resuming SuperSpeed HUBs

2013-12-09 Thread Vikas Sajjan
Hi Sarah,

On Mon, Dec 9, 2013 at 11:54 PM, Sarah Sharp
sarah.a.sh...@linux.intel.com wrote:
 On Mon, Dec 09, 2013 at 10:24:52AM -0500, Alan Stern wrote:
 On Mon, 9 Dec 2013, Vikas Sajjan wrote:

  Does warm reset while activating SuperSpeed HUBs if the hub activate type
  is HUB_RESET_RESUME.
 
  When we do Suspend-to-RAM with (any one of the 16, 32, 64 Jetflash) 
  transcend
  USB 3.0 device connected on 3.0 port, during resume I noticed that the
  XHCI controller has moved to sometimes RECOVERY, POLLING or INACTIVE STATE.
  This behaviour is inconsistent and the connection with connected USB 3.0 
  device
  on 3.0 port was LOST.

 Does the device eventually re-connect on the USB port?  Or is warm reset
 necessary to make the device connect?

Yes, warm reset was necesssary, without which the device was NOT reconnecting.


 Does the xHCI register restore complete after resume from S3, or is
 power lost?  I'm trying to figure out whether xhci_reset is called
 before your issue is triggered.


The reason why I came up with this solution is during xhci_resume(),
it enters below condition and marks the reset_resume flag for the
ROOT_HUB as 1

/* If restore operation fails, re-initialize the HC during resume */
if ((temp  STS_SRE) || hibernated) {
/* Let the USB core know _both_ roothubs lost power. */
 usb_root_hub_lost_power(xhci-main_hcd-self.root_hub);
 usb_root_hub_lost_power(xhci-shared_hcd-self.root_hub);



  Doing warm reset while activating SuperSpeed HUBs if the hub
  activate type is HUB_RESET_RESUME, gets the connected device to the stable 
  state.
 
  Reviewed at https://chromium-review.googlesource.com/#/c/177132/
 
  Tested on exynos5420 and exynos5250 with Transcend Jetflash USB 3.0 device 
  (8564:1000)

 Is this issue specific to the particular USB device manufacturer
 (Transcend)?  Does the same device lose connection on resume from S3
 with other host controller vendors?  Have you seen this issue when the
 USB 3.0 device is behind a USB 3.0 hub?


This issue was specific to this paritcular make of Transcend.

we saw this on our chromebook. I did try Suspend-to-RAM with the same
device on Intel machine running Ubuntu.
It had worked fine without any issue.

Interestingly, if I connect with analyser, Suspend-to-RAM works fine
and USB re-enumerates successfully.
so connecting Suspend-to-RAM for debugging was not helping, as it works fine.
I did put prints in multiple places to get port status, and i see that
port is in sometimes RECOVERY, POLLING or In active STATE.
The behaviour was inconsistent.



 I ask because this sounds like a low-level link training issue that's
 specific to the exynos host or USB device.  I would rather track down
 which hardware is to blame than generically add a warm reset for all USB
 3.0 devices.

  rebased on Greg Kroah-Hartman's usb-next
  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
 
  Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
  ---
   drivers/usb/core/hub.c |   41 +
   1 file changed, 25 insertions(+), 16 deletions(-)
 
  diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
  index a7c04e2..d8432b0 100644
  --- a/drivers/usb/core/hub.c
  +++ b/drivers/usb/core/hub.c

  @@ -1093,6 +1108,16 @@ static void hub_activate(struct usb_hub *hub, enum 
  hub_activation_type type)
  u16 portstatus, portchange;
 
  portstatus = portchange = 0;
  +
  +   /* Some connected devices might be still in unknown state even
  +* after reset-resume, a WARM_RESET gets the connected device
  +* to the normal state.
  +*/
  +   if (udev  hub_is_superspeed(hub-hdev) 
  +   type == HUB_RESET_RESUME)
  +   hub_port_reset(hub, port1, NULL,
  +   HUB_BH_RESET_TIME, true);

 Please don't do this all the time to every attached port.  Do it only
 when it is really needed.

 Agreed.  Can we at least limit the warm reset to devices directly
 attached to roothubs?  You can also change this code to get the port
 status and only do the warm reset if the port link state is
 USB_SS_PORT_LS_POLLING, USB_SS_PORT_LS_RX_DETECT, or
 USB_SS_PORT_LS_SS_INACTIVE.

 Shouldn't you pass udev as the third argument?  If not, please explain
 why not.

 Finally, I don't see why you put this in hub_activate().  Isn't it more
 closely connected with the reset-resume procedure for the child device?

 Sarah Sharp
 --
 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] USB: core: Add warm reset while reset-resuming SuperSpeed HUBs

2013-12-09 Thread Vikas Sajjan
Hi Alan,

On Mon, Dec 9, 2013 at 8:54 PM, Alan Stern st...@rowland.harvard.edu wrote:
 On Mon, 9 Dec 2013, Vikas Sajjan wrote:

 Does warm reset while activating SuperSpeed HUBs if the hub activate type
 is HUB_RESET_RESUME.

 When we do Suspend-to-RAM with (any one of the 16, 32, 64 Jetflash) transcend
 USB 3.0 device connected on 3.0 port, during resume I noticed that the
 XHCI controller has moved to sometimes RECOVERY, POLLING or INACTIVE STATE.
 This behaviour is inconsistent and the connection with connected USB 3.0 
 device
 on 3.0 port was LOST.

 Doing warm reset while activating SuperSpeed HUBs if the hub
 activate type is HUB_RESET_RESUME, gets the connected device to the stable 
 state.

 Reviewed at https://chromium-review.googlesource.com/#/c/177132/

 Tested on exynos5420 and exynos5250 with Transcend Jetflash USB 3.0 device 
 (8564:1000)

 rebased on Greg Kroah-Hartman's usb-next
 git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git

 Signed-off-by: Vikas Sajjan vikas.saj...@samsung.com
 ---
  drivers/usb/core/hub.c |   41 +
  1 file changed, 25 insertions(+), 16 deletions(-)

 diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
 index a7c04e2..d8432b0 100644
 --- a/drivers/usb/core/hub.c
 +++ b/drivers/usb/core/hub.c

 @@ -1093,6 +1108,16 @@ static void hub_activate(struct usb_hub *hub, enum 
 hub_activation_type type)
   u16 portstatus, portchange;

   portstatus = portchange = 0;
 +
 + /* Some connected devices might be still in unknown state even
 +  * after reset-resume, a WARM_RESET gets the connected device
 +  * to the normal state.
 +  */
 + if (udev  hub_is_superspeed(hub-hdev) 
 + type == HUB_RESET_RESUME)
 + hub_port_reset(hub, port1, NULL,
 + HUB_BH_RESET_TIME, true);

 Please don't do this all the time to every attached port.  Do it only
 when it is really needed.

 Shouldn't you pass udev as the third argument?  If not, please explain
 why not.

yea, I have NOT tried passing udev as the third argument.



 Finally, I don't see why you put this in hub_activate().  Isn't it more
 closely connected with the reset-resume procedure for the child device?


I was trying to add a FIX in usb_port_resume(), but in our case we
have CONFIG_USB_DEFAULT_PERSIST disabled.

Interestingly, if I disable the CONFIG_USB_DEFAULT_PERSIST, then the
function usb_port_resume() will never be called and transcend Jetflash
device Suspend-to-RAM fails.

In normal scenario (ie., CONFIG_USB_DEFAULT_PERSIST=y) the sequence is:
===
Step 1: For Root HUB :
usb_resume_both() --- usb_resume_device() - generic_resume() --
hcd_bus_resume() -- xhci_bus_resume().
  |
  |--usb_resume_interface() ---
hub_reset_resume() --  xhci_update_hub_device()

Step 2:  For the Device connected
usb_resume_both() --- usb_resume_device() -
generic_resume()--usb_port_resume()--hub_port_logical_disconnect()
-- hub_port_disable() -- hub_usb3_port_disable().


In our scenario (ie., CONFIG_USB_DEFAULT_PERSIST=N) the sequence is:
===
Step 1: For Root HUB
usb_resume_both() --- usb_resume_device() - generic_resume() --
hcd_bus_resume() -- xhci_bus_resume().
  |
  |--usb_resume_interface() ---
hub_reset_resume() --  xhci_update_hub_device()

Step 2 :  Never occurs

So Suspend-to-RAM fails.

Hence i added a FIX in  hub_reset_resume().

Let me know if I am wrong.


 Alan Stern

 --
 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 v3 1/3] usb: dwc3: Add the suspend/resume functionality

2012-10-25 Thread Vikas Sajjan
Hi Felipe,

On 18 October 2012 22:59, Felipe Balbi ba...@ti.com wrote:
 Hi,

 On Thu, Oct 18, 2012 at 12:44:50PM -0400, Alan Stern wrote:
 On Thu, 18 Oct 2012, Sarah Sharp wrote:

  For system suspend while the DW3 hardware is in host mode, doesn't the
  USB core prevent drivers from submitting URBs just before the
  PCI/platform suspend is called?  Alan?

 Sure it does.

 ok great, so my concerns is limited to the gadget side ;-) I still want
 to see both sides tested, though.

 (sorry guys, but with DWC3 now passing full USB3 certification, I want
 to be very careful with patches I accept, specially related to PM ;-)

 --
 balbi

Will test both HOST and GADGET mode as per your suggestion and update you.

-- 
Thanks and Regards
 Vikas Sajjan
--
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 1/3] usb: dwc3: Add the suspend/resume functionality

2012-10-16 Thread Vikas Sajjan
Adds suspend and resume callbacks as part of the power management
support to DWC3 controller Driver.
This patch facilitates transition of DWC3 controller between D0 and D3
power states during suspend/resume cycles.

Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Vikas C Sajjan vikas.saj...@linaro.org
CC: Doug Anderson diand...@chromium.org
---
 drivers/usb/dwc3/core.c |   44 
 1 files changed, 44 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 5db4c76..9f35cf8 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -621,11 +621,55 @@ static int __devexit dwc3_remove(struct platform_device 
*pdev)
return 0;
 }
 
+#ifdef CONFIG_PM_SLEEP
+static int dwc3_resume(struct device *dev)
+{
+   struct dwc3 *dwc = dev_get_drvdata(dev);
+   int ret;
+
+   ret = dwc3_core_init(dwc);
+   if (ret  0)
+   return ret;
+
+   switch (dwc-mode) {
+   case DWC3_MODE_DEVICE:
+   dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
+   break;
+   case DWC3_MODE_HOST:
+   dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST);
+   break;
+   case DWC3_MODE_DRD:
+   dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
+   }
+
+   /* runtime set active to reflect active state. */
+   pm_runtime_disable(dev);
+   pm_runtime_set_active(dev);
+   pm_runtime_enable(dev);
+
+   return 0;
+}
+
+static int dwc3_suspend(struct device *dev)
+{
+   struct dwc3 *dwc = dev_get_drvdata(dev);
+
+   dwc3_core_exit(dwc);
+
+   return 0;
+}
+#endif /* CONFIG_PM_SLEEP */
+
+static const struct dev_pm_ops dwc3_pm_ops = {
+   SET_SYSTEM_SLEEP_PM_OPS(dwc3_suspend, dwc3_resume)
+};
+
 static struct platform_driver dwc3_driver = {
.probe  = dwc3_probe,
.remove = __devexit_p(dwc3_remove),
.driver = {
.name   = dwc3,
+   .pm = dwc3_pm_ops,
},
 };
 
-- 
1.7.6.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 v3 2/3] usb: xhci: Add the suspend/resume functionality

2012-10-16 Thread Vikas Sajjan
Adds power management support to XHCI platform driver.
This patch facilitates the transition of xHCI host controller
between S0 and S3/S4 power states, during suspend/resume cycles.

Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Vikas C Sajjan vikas.saj...@linaro.org
CC: Doug Anderson diand...@chromium.org
---
 drivers/usb/host/xhci-plat.c |   28 
 1 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index df90fe5..eaf3a07 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -185,11 +185,39 @@ static int xhci_plat_remove(struct platform_device *dev)
return 0;
 }
 
+#ifdef CONFIG_PM_SLEEP
+static int xhci_plat_suspend(struct device *dev)
+{
+   struct usb_hcd  *hcd= dev_get_drvdata(dev);
+   struct xhci_hcd *xhci   = hcd_to_xhci(hcd);
+
+   /* Make sure that the HCD Core has set state to HC_STATE_SUSPENDED */
+   if (hcd-state != HC_STATE_SUSPENDED ||
+   xhci-shared_hcd-state != HC_STATE_SUSPENDED)
+   return -EINVAL;
+
+   return xhci_suspend(xhci);
+}
+
+static int xhci_plat_resume(struct device *dev)
+{
+   struct usb_hcd  *hcd= dev_get_drvdata(dev);
+   struct xhci_hcd *xhci   = hcd_to_xhci(hcd);
+
+   return xhci_resume(xhci, 0);
+}
+#endif /* CONFIG_PM_SLEEP */
+
+static const struct dev_pm_ops xhci_plat_pm_ops = {
+   SET_SYSTEM_SLEEP_PM_OPS(xhci_plat_suspend, xhci_plat_resume)
+};
+
 static struct platform_driver usb_xhci_driver = {
.probe  = xhci_plat_probe,
.remove = xhci_plat_remove,
.driver = {
.name = xhci-hcd,
+   .pm = xhci_plat_pm_ops,
},
 };
 MODULE_ALIAS(platform:xhci-hcd);
-- 
1.7.6.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 v3 3/3] exynos5: usb: dwc3: Add suspend/resume functionality

2012-10-16 Thread Vikas Sajjan
Adds suspend and resume callbacks to exynos dwc3 driver as part of
power management support.
This change does gating of dwc3 clock during suspend/resume cycles.

Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Vikas C Sajjan vikas.saj...@linaro.org
CC: Doug Anderson diand...@chromium.org
---
 drivers/usb/dwc3/dwc3-exynos.c |   31 +++
 1 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index ca65978..8623b70 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -15,6 +15,7 @@
 #include linux/module.h
 #include linux/kernel.h
 #include linux/slab.h
+#include linux/pm_runtime.h
 #include linux/platform_device.h
 #include linux/platform_data/dwc3-exynos.h
 #include linux/dma-mapping.h
@@ -200,11 +201,41 @@ static int __devexit dwc3_exynos_remove(struct 
platform_device *pdev)
return 0;
 }
 
+#ifdef CONFIG_PM_SLEEP
+static int dwc3_exynos_suspend(struct device *dev)
+{
+   struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+
+   clk_disable(exynos-clk);
+
+   return 0;
+}
+
+static int dwc3_exynos_resume(struct device *dev)
+{
+   struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+
+   clk_enable(exynos-clk);
+
+   /* runtime set active to reflect active state. */
+   pm_runtime_disable(dev);
+   pm_runtime_set_active(dev);
+   pm_runtime_enable(dev);
+
+   return 0;
+}
+#endif /* CONFIG_PM_SLEEP */
+
+static const struct dev_pm_ops dwc3_exynos_pm_ops = {
+   SET_SYSTEM_SLEEP_PM_OPS(dwc3_exynos_suspend, dwc3_exynos_resume)
+};
+
 static struct platform_driver dwc3_exynos_driver = {
.probe  = dwc3_exynos_probe,
.remove = __devexit_p(dwc3_exynos_remove),
.driver = {
.name   = exynos-dwc3,
+   .pm = dwc3_exynos_pm_ops,
},
 };
 
-- 
1.7.6.5

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


Re: [PATCH v3 1/3] usb: dwc3: Add the suspend/resume functionality

2012-10-16 Thread Vikas Sajjan
Hi Felipe,

On 16 October 2012 15:36, Felipe Balbi ba...@ti.com wrote:
 Hi,

 On Tue, Oct 16, 2012 at 03:15:36PM +0530, Vikas Sajjan wrote:
 Adds suspend and resume callbacks as part of the power management
 support to DWC3 controller Driver.
 This patch facilitates transition of DWC3 controller between D0 and D3
 power states during suspend/resume cycles.

 Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
 Signed-off-by: Vikas C Sajjan vikas.saj...@linaro.org
 CC: Doug Anderson diand...@chromium.org
 ---
  drivers/usb/dwc3/core.c |   44 
  1 files changed, 44 insertions(+), 0 deletions(-)

 diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
 index 5db4c76..9f35cf8 100644
 --- a/drivers/usb/dwc3/core.c
 +++ b/drivers/usb/dwc3/core.c
 @@ -621,11 +621,55 @@ static int __devexit dwc3_remove(struct 
 platform_device *pdev)
   return 0;
  }

 +#ifdef CONFIG_PM_SLEEP
 +static int dwc3_resume(struct device *dev)
 +{
 + struct dwc3 *dwc = dev_get_drvdata(dev);
 + int ret;
 +
 + ret = dwc3_core_init(dwc);
 + if (ret  0)
 + return ret;
 +
 + switch (dwc-mode) {
 + case DWC3_MODE_DEVICE:
 + dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
 + break;
 + case DWC3_MODE_HOST:
 + dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST);
 + break;
 + case DWC3_MODE_DRD:
 + dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
 + }
 +
 + /* runtime set active to reflect active state. */
 + pm_runtime_disable(dev);
 + pm_runtime_set_active(dev);
 + pm_runtime_enable(dev);
 +
 + return 0;
 +}
 +
 +static int dwc3_suspend(struct device *dev)
 +{
 + struct dwc3 *dwc = dev_get_drvdata(dev);
 +

 there is one check you need to do here. If you are playing the
 peripheral role, you can't allow suspend unless link is in U3 or you're
 not enumerated.

 Have you tested running 'echo mem  /sys/power/state' on your device
 while you're transferring data in a USB session with the Host ?

we have tested only when DWC3 is in HOST mode.

 I'll ask again, how was this tested ? What did you actually run (which
 commands, which use cases have you validated) ? I'm not asking only
 which platform you used, I need to know how you exercised this feature,
 how did you trigger suspend/resume, in which conditions (enumerated ?
 bus suspended ? no cable attached ?), etc.

1) We have tested by connecting a USB Mouse, USB 2.0 Mass Storage Device and
USB 3.0 Mass Storage Device on a SS hub connected on USB 3.0 port to
Exynos5250 board, in which DWC3 is configured for HOST mode.

2) We tested by running  command
echo +20   /sys/class/rtc/rtc0/wakealarmecho mem  /sys/power/state

 cheers

 --
 balbi



-- 
Thanks and Regards
 Vikas Sajjan
--
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 0/3] USB: dwc3: Add suspend/resume support

2012-10-13 Thread Vikas Sajjan
Changes from v1:
 - Reverted back the code movements in core.c and also reverted 
dwc3_core_reset() 
 - Removed the pdata dependency for phy init and exit from dwc3-exynos.c 

Based on 'usb-next' of greg's tree.
Tested USB detection and enumeration across multiple cycles of
suspend/resume using 2.0 and 3.0 devices on D-link SS hub.

Vikas Sajjan (3):
  usb: dwc3: Add the suspend/resume functionality
  usb: xhci: Add the suspend/resume functionality
  exynos5: usb: dwc3: Add the suspend/resume functionality

 drivers/usb/dwc3/core.c|   54 
 drivers/usb/dwc3/dwc3-exynos.c |   39 
 drivers/usb/host/xhci-plat.c   |   33 
 3 files changed, 126 insertions(+), 0 deletions(-)

-- 
1.7.6.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 v2 1/3] usb: dwc3: Add the suspend/resume functionality

2012-10-13 Thread Vikas Sajjan
Adding the suspend and resume funtionality to DWC3 core.

Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Vikas C Sajjan vikas.saj...@linaro.org
CC: Doug Anderson diand...@chromium.org
---
 drivers/usb/dwc3/core.c |   54 +++
 1 files changed, 54 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b415c0c..0699061 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -622,11 +622,65 @@ static int __devexit dwc3_remove(struct platform_device 
*pdev)
return 0;
 }
 
+#ifdef CONFIG_PM
+static int dwc3_resume(struct device *dev)
+{
+   struct dwc3 *dwc = dev_get_drvdata(dev);
+   int ret;
+
+   usb_phy_init(dwc-usb2_phy);
+   usb_phy_init(dwc-usb3_phy);
+
+   ret = dwc3_event_buffers_setup(dwc);
+   if (ret  0)
+   return ret;
+
+   switch (dwc-mode) {
+   case DWC3_MODE_DEVICE:
+   dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
+   break;
+   case DWC3_MODE_HOST:
+   dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST);
+   break;
+   case DWC3_MODE_DRD:
+   dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
+   }
+
+   /* runtime set active to reflect active state. */
+   pm_runtime_disable(dev);
+   pm_runtime_set_active(dev);
+   pm_runtime_enable(dev);
+
+   return 0;
+}
+
+static int dwc3_suspend(struct device *dev)
+{
+   struct dwc3 *dwc = dev_get_drvdata(dev);
+
+   dwc3_event_buffers_cleanup(dwc);
+
+   usb_phy_shutdown(dwc-usb2_phy);
+   usb_phy_shutdown(dwc-usb3_phy);
+
+   return 0;
+}
+
+static const struct dev_pm_ops dwc3_pm_ops = {
+   .suspend= dwc3_suspend,
+   .resume = dwc3_resume,
+};
+#define DWC3_PM_OPS (dwc3_pm_ops)
+#else
+#define DWC3_PM_OPS NULL
+#endif /* CONFIG_PM */
+
 static struct platform_driver dwc3_driver = {
.probe  = dwc3_probe,
.remove = __devexit_p(dwc3_remove),
.driver = {
.name   = dwc3,
+   .pm = DWC3_PM_OPS,
},
 };
 
-- 
1.7.6.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 v2 2/3] usb: xhci: Add the suspend/resume functionality

2012-10-13 Thread Vikas Sajjan
Adding the suspend and resume functionality for the XHCI driver

Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Vikas C Sajjan vikas.saj...@linaro.org
CC: Doug Anderson diand...@chromium.org
---
 drivers/usb/host/xhci-plat.c |   33 +
 1 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index df90fe5..15c7c89 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -185,11 +185,44 @@ static int xhci_plat_remove(struct platform_device *dev)
return 0;
 }
 
+#ifdef CONFIG_PM
+static int xhci_plat_suspend(struct device *dev)
+{
+   struct usb_hcd  *hcd= dev_get_drvdata(dev);
+   struct xhci_hcd *xhci   = hcd_to_xhci(hcd);
+
+   /* Make sure that the HCD Core has set state to HC_STATE_SUSPENDED */
+   if (hcd-state != HC_STATE_SUSPENDED ||
+   xhci-shared_hcd-state != HC_STATE_SUSPENDED)
+   return -EINVAL;
+
+   return xhci_suspend(xhci);
+}
+
+static int xhci_plat_resume(struct device *dev)
+{
+   struct usb_hcd  *hcdi   = dev_get_drvdata(dev);
+   struct xhci_hcd *xhci   = hcd_to_xhci(hcd);
+
+   return xhci_resume(xhci, 0);
+}
+
+static const struct dev_pm_ops xhci_plat_pm_ops = {
+   .suspend= xhci_plat_suspend,
+   .resume = xhci_plat_resume,
+};
+
+#define XHCI_PLAT_PM_OPS(xhci_plat_pm_ops)
+#else
+#define XHCI_PLAT_PM_OPSNULL
+#endif
+
 static struct platform_driver usb_xhci_driver = {
.probe  = xhci_plat_probe,
.remove = xhci_plat_remove,
.driver = {
.name = xhci-hcd,
+   .pm = XHCI_PLAT_PM_OPS,
},
 };
 MODULE_ALIAS(platform:xhci-hcd);
-- 
1.7.6.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 v2 3/3] exynos5: usb: dwc3: Add the suspend/resume functionality

2012-10-13 Thread Vikas Sajjan
Adding the suspend and resume functionality to exynos dwc3 driver

Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Vikas C Sajjan vikas.saj...@linaro.org
CC: Doug Anderson diand...@chromium.org
---
 drivers/usb/dwc3/dwc3-exynos.c |   39 +++
 1 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index ca65978..2781301 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -15,6 +15,7 @@
 #include linux/module.h
 #include linux/kernel.h
 #include linux/slab.h
+#include linux/pm_runtime.h
 #include linux/platform_device.h
 #include linux/platform_data/dwc3-exynos.h
 #include linux/dma-mapping.h
@@ -200,11 +201,49 @@ static int __devexit dwc3_exynos_remove(struct 
platform_device *pdev)
return 0;
 }
 
+#ifdef CONFIG_PM
+static int dwc3_exynos_suspend(struct device *dev)
+{
+   struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+
+   BUG_ON(!exynos);
+
+   clk_disable(exynos-clk);
+
+   return 0;
+}
+
+static int dwc3_exynos_resume(struct device *dev)
+{
+   struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+
+   BUG_ON(!exynos);
+
+   clk_enable(exynos-clk);
+
+   /* runtime set active to reflect active state. */
+   pm_runtime_disable(dev);
+   pm_runtime_set_active(dev);
+   pm_runtime_enable(dev);
+
+   return 0;
+}
+
+static const struct dev_pm_ops dwc3_exynos_pm_ops = {
+   .suspend= dwc3_exynos_suspend,
+   .resume = dwc3_exynos_resume,
+};
+#define DWC3_EXYNOS_DEV_PM_OPS  (dwc3_exynos_pm_ops)
+#else
+#define DWC3_EXYNOS_DEV_PM_OPS  NULL
+#endif /* CONFIG_PM */
+
 static struct platform_driver dwc3_exynos_driver = {
.probe  = dwc3_exynos_probe,
.remove = __devexit_p(dwc3_exynos_remove),
.driver = {
.name   = exynos-dwc3,
+   .pm = DWC3_EXYNOS_DEV_PM_OPS,
},
 };
 
-- 
1.7.6.5

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


Re: [PATCH 1/3] usb: dwc3: Add the suspend/resume functionality

2012-10-12 Thread Vikas Sajjan
Hi Felipe,

On 11 October 2012 13:17, Felipe Balbi ba...@ti.com wrote:

 Hi,

 On Wed, Oct 10, 2012 at 07:35:47PM +0530, Vikas C Sajjan wrote:
  From: Vikas Sajjan vikas.saj...@linaro.org
 
  Adding the suspend and resume funtionality to DWC3 core.
 
  Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
  Signed-off-by: Vikas C Sajjan vikas.saj...@linaro.org
  CC: Doug Anderson diand...@chromium.org
  ---
   drivers/usb/dwc3/core.c |  268
  +-
   1 files changed, 169 insertions(+), 99 deletions(-)
 
  diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
  index b415c0c..58b51e1 100644
  --- a/drivers/usb/dwc3/core.c
  +++ b/drivers/usb/dwc3/core.c
  @@ -70,51 +70,20 @@ MODULE_PARM_DESC(maximum_speed, Maximum supported
  speed.);
 
   static DECLARE_BITMAP(dwc3_devs, DWC3_DEVS_POSSIBLE);
 
  -int dwc3_get_device_id(void)
  -{
  - int id;
  -
  -again:
  - id = find_first_zero_bit(dwc3_devs, DWC3_DEVS_POSSIBLE);
  - if (id  DWC3_DEVS_POSSIBLE) {
  - int old;
  -
  - old = test_and_set_bit(id, dwc3_devs);
  - if (old)
  - goto again;
  - } else {
  - pr_err(dwc3: no space for new device\n);
  - id = -ENOMEM;
  - }
  -
  - return id;
  -}
  -EXPORT_SYMBOL_GPL(dwc3_get_device_id);
  -
  -void dwc3_put_device_id(int id)
  -{
  - int ret;
  -
  - if (id  0)
  - return;
  -
  - ret = test_bit(id, dwc3_devs);
  - WARN(!ret, dwc3: ID %d not in use\n, id);
  - smp_mb__before_clear_bit();
  - clear_bit(id, dwc3_devs);
  -}
  -EXPORT_SYMBOL_GPL(dwc3_put_device_id);
  -
  -void dwc3_set_mode(struct dwc3 *dwc, u32 mode)

 why are you even moving all this code around ? Doesn't look necessary.

  +static void __devinit dwc3_cache_hwparams(struct dwc3 *dwc)
   {
  - u32 reg;
  + struct dwc3_hwparams*parms = dwc-hwparams;
 
  - reg = dwc3_readl(dwc-regs, DWC3_GCTL);
  - reg = ~(DWC3_GCTL_PRTCAPDIR(DWC3_GCTL_PRTCAP_OTG));
  - reg |= DWC3_GCTL_PRTCAPDIR(mode);
  - dwc3_writel(dwc-regs, DWC3_GCTL, reg);
  + parms-hwparams0 = dwc3_readl(dwc-regs, DWC3_GHWPARAMS0);
  + parms-hwparams1 = dwc3_readl(dwc-regs, DWC3_GHWPARAMS1);
  + parms-hwparams2 = dwc3_readl(dwc-regs, DWC3_GHWPARAMS2);
  + parms-hwparams3 = dwc3_readl(dwc-regs, DWC3_GHWPARAMS3);
  + parms-hwparams4 = dwc3_readl(dwc-regs, DWC3_GHWPARAMS4);
  + parms-hwparams5 = dwc3_readl(dwc-regs, DWC3_GHWPARAMS5);
  + parms-hwparams6 = dwc3_readl(dwc-regs, DWC3_GHWPARAMS6);
  + parms-hwparams7 = dwc3_readl(dwc-regs, DWC3_GHWPARAMS7);
  + parms-hwparams8 = dwc3_readl(dwc-regs, DWC3_GHWPARAMS8);
   }
  -
   /**
* dwc3_core_soft_reset - Issues core soft reset and PHY reset
* @dwc: pointer to our context structure
  @@ -160,6 +129,102 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
dwc3_writel(dwc-regs, DWC3_GCTL, reg);
   }
 
  +static int dwc3_core_reset(struct dwc3 *dwc)

 this looks unnecessary.

dwc3_core_reset() function is added to avoid the code duplication, and
can be reused both in probe and resume.
  +{
  + unsigned long   timeout;
  + u32 reg;
  +
  + /* issue device SoftReset too */
  + timeout = jiffies + msecs_to_jiffies(500);
  + dwc3_writel(dwc-regs, DWC3_DCTL, DWC3_DCTL_CSFTRST);
  + do {
  + reg = dwc3_readl(dwc-regs, DWC3_DCTL);
  + if (!(reg  DWC3_DCTL_CSFTRST))
  + break;
  +
  + if (time_after(jiffies, timeout)) {
  + dev_err(dwc-dev, Reset Timed Out\n);
  + return -ETIMEDOUT;
  + }
  +
  + cpu_relax();
  + } while (true);
  +
  + dwc3_core_soft_reset(dwc);
  +
  + dwc3_cache_hwparams(dwc);
  +
  + reg = dwc3_readl(dwc-regs, DWC3_GCTL);
  + reg = ~DWC3_GCTL_SCALEDOWN_MASK;
  + reg = ~DWC3_GCTL_DISSCRAMBLE;
  +
  + switch (DWC3_GHWPARAMS1_EN_PWROPT(dwc-hwparams.hwparams1)) {
  + case DWC3_GHWPARAMS1_EN_PWROPT_CLK:
  + reg = ~DWC3_GCTL_DSBLCLKGTNG;
  + break;
  + default:
  + dev_dbg(dwc-dev, No power optimization available\n);
  + }
  +
  + /*
  +  * WORKAROUND: DWC3 revisions 1.90a have a bug
  +  * where the device can fail to connect at SuperSpeed
  +  * and falls back to high-speed mode which causes
  +  * the device to enter a Connect/Disconnect loop
  +  */
  + if (dwc-revision  DWC3_REVISION_190A)
  + reg |= DWC3_GCTL_U2RSTECN;
  +
  + dwc3_writel(dwc-regs, DWC3_GCTL, reg);
  +
  + return 0;
  +}
  +
  +int dwc3_get_device_id(void)
  +{
  + int id;
  +
  +again:
  + id = find_first_zero_bit(dwc3_devs, DWC3_DEVS_POSSIBLE);
  + if (id  DWC3_DEVS_POSSIBLE) {
  + int old;
  +
  + old = test_and_set_bit(id, dwc3_devs

Re: [PATCH 1/3] usb: dwc3: Add the suspend/resume functionality

2012-10-12 Thread Vikas Sajjan
Hi kishon,

On 12 October 2012 16:27, kishon kis...@ti.com wrote:
 Hi,


 On Wednesday 10 October 2012 07:35 PM, Vikas C Sajjan wrote:

 From: Vikas Sajjan vikas.saj...@linaro.org

 Adding the suspend and resume funtionality to DWC3 core.

 Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
 Signed-off-by: Vikas C Sajjan vikas.saj...@linaro.org
 CC: Doug Anderson diand...@chromium.org
 ---
   drivers/usb/dwc3/core.c |  268
 +-
   1 files changed, 169 insertions(+), 99 deletions(-)

 diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
 index b415c0c..58b51e1 100644
 --- a/drivers/usb/dwc3/core.c
 +++ b/drivers/usb/dwc3/core.c

 @@ -70,51 +70,20 @@ MODULE_PARM_DESC(maximum_speed, Maximum supported
 speed.);

   static DECLARE_BITMAP(dwc3_devs, DWC3_DEVS_POSSIBLE);

 -int dwc3_get_device_id(void)
 -{
 -   int id;
 -
 -again:
 -   id = find_first_zero_bit(dwc3_devs, DWC3_DEVS_POSSIBLE);
 -   if (id  DWC3_DEVS_POSSIBLE) {
 -   int old;
 -
 -   old = test_and_set_bit(id, dwc3_devs);
 -   if (old)
 -   goto again;
 -   } else {
 -   pr_err(dwc3: no space for new device\n);
 -   id = -ENOMEM;
 -   }
 -
 -   return id;
 -}
 -EXPORT_SYMBOL_GPL(dwc3_get_device_id);
 -
 -void dwc3_put_device_id(int id)
 -{
 -   int ret;
 -
 -   if (id  0)
 -   return;
 -
 -   ret = test_bit(id, dwc3_devs);
 -   WARN(!ret, dwc3: ID %d not in use\n, id);
 -   smp_mb__before_clear_bit();
 -   clear_bit(id, dwc3_devs);
 -}
 -EXPORT_SYMBOL_GPL(dwc3_put_device_id);
 -
 -void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
 +static void __devinit dwc3_cache_hwparams(struct dwc3 *dwc)
   {
 -   u32 reg;
 +   struct dwc3_hwparams*parms = dwc-hwparams;

 -   reg = dwc3_readl(dwc-regs, DWC3_GCTL);
 -   reg = ~(DWC3_GCTL_PRTCAPDIR(DWC3_GCTL_PRTCAP_OTG));
 -   reg |= DWC3_GCTL_PRTCAPDIR(mode);
 -   dwc3_writel(dwc-regs, DWC3_GCTL, reg);
 +   parms-hwparams0 = dwc3_readl(dwc-regs, DWC3_GHWPARAMS0);
 +   parms-hwparams1 = dwc3_readl(dwc-regs, DWC3_GHWPARAMS1);
 +   parms-hwparams2 = dwc3_readl(dwc-regs, DWC3_GHWPARAMS2);
 +   parms-hwparams3 = dwc3_readl(dwc-regs, DWC3_GHWPARAMS3);
 +   parms-hwparams4 = dwc3_readl(dwc-regs, DWC3_GHWPARAMS4);
 +   parms-hwparams5 = dwc3_readl(dwc-regs, DWC3_GHWPARAMS5);
 +   parms-hwparams6 = dwc3_readl(dwc-regs, DWC3_GHWPARAMS6);
 +   parms-hwparams7 = dwc3_readl(dwc-regs, DWC3_GHWPARAMS7);
 +   parms-hwparams8 = dwc3_readl(dwc-regs, DWC3_GHWPARAMS8);
   }
 -
   /**
* dwc3_core_soft_reset - Issues core soft reset and PHY reset
* @dwc: pointer to our context structure
 @@ -160,6 +129,102 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
 dwc3_writel(dwc-regs, DWC3_GCTL, reg);
   }

 +static int dwc3_core_reset(struct dwc3 *dwc)
 +{
 +   unsigned long   timeout;
 +   u32 reg;
 +
 +   /* issue device SoftReset too */
 +   timeout = jiffies + msecs_to_jiffies(500);
 +   dwc3_writel(dwc-regs, DWC3_DCTL, DWC3_DCTL_CSFTRST);
 +   do {
 +   reg = dwc3_readl(dwc-regs, DWC3_DCTL);
 +   if (!(reg  DWC3_DCTL_CSFTRST))
 +   break;
 +
 +   if (time_after(jiffies, timeout)) {
 +   dev_err(dwc-dev, Reset Timed Out\n);
 +   return -ETIMEDOUT;
 +   }
 +
 +   cpu_relax();
 +   } while (true);
 +
 +   dwc3_core_soft_reset(dwc);
 +
 +   dwc3_cache_hwparams(dwc);
 +
 +   reg = dwc3_readl(dwc-regs, DWC3_GCTL);
 +   reg = ~DWC3_GCTL_SCALEDOWN_MASK;
 +   reg = ~DWC3_GCTL_DISSCRAMBLE;
 +
 +   switch (DWC3_GHWPARAMS1_EN_PWROPT(dwc-hwparams.hwparams1)) {
 +   case DWC3_GHWPARAMS1_EN_PWROPT_CLK:
 +   reg = ~DWC3_GCTL_DSBLCLKGTNG;
 +   break;
 +   default:
 +   dev_dbg(dwc-dev, No power optimization available\n);
 +   }
 +
 +   /*

 +* WORKAROUND: DWC3 revisions 1.90a have a bug
 +* where the device can fail to connect at SuperSpeed
 +* and falls back to high-speed mode which causes
 +* the device to enter a Connect/Disconnect loop
 +*/
 +   if (dwc-revision  DWC3_REVISION_190A)
 +   reg |= DWC3_GCTL_U2RSTECN;
 +
 +   dwc3_writel(dwc-regs, DWC3_GCTL, reg);
 +
 +   return 0;
 +}
 +
 +int dwc3_get_device_id(void)
 +{
 +   int id;
 +
 +again:
 +   id = find_first_zero_bit(dwc3_devs, DWC3_DEVS_POSSIBLE);
 +   if (id  DWC3_DEVS_POSSIBLE) {
 +   int old;
 +
 +   old = test_and_set_bit(id, dwc3_devs);
 +   if (old)
 +   goto again;
 +   } else {
 +   pr_err(dwc3: no space for new device\n);
 +   id = -ENOMEM;
 +   }
 +
 +   return id

Re: Re: Re: 3.0 device attached to USB 3.0 hub port doesn't respond address device command after resume

2012-08-21 Thread VIKAS SAJJAN C

Hi All,

I was using the SS hub by VIA Labs,inc.

what I found is that, there is a firmware update available for this SS HUB.

When i went through the Release Notes, they say 
USB 3.0: 
Resolved issue with Intel USB 3.0 Host where devices were occasionally not 
properly re-enumerated after resuming from S3/S4, warm-boot, or cold boot

http://www.via-labs.com/en/downloads/documents/VL810-Firmware-V9.5-Release-Note.pdf

I upgraded the firmware with their tool 
(http://www.via-labs.com/en/support/downloads.jsp),  with that , this case USB 
3.0 Device on SS hub on 3.0 port gets resolved.

Thanks and Regards
Vikas Sajjan

--- Original Message ---
Sender : VIKAS SAJJAN Cvikas.saj...@samsung.com  Technical 
Manager/SISO-Solution 1/Samsung Electronics
Date   : Aug 20, 2012 15:53 (GMT+09:00)
Title  : Re: Re: 3.0 device attached to USB 3.0 hub port doesn't respond 
address device command after resume
To : Andiry Xuand...@gmail.com  elric...@gmail.com  
linux-usb@vger.kernel.org  sarah.a.sh...@linux.intel.com  


Hi ,

if i disconnect the hub, after the timeout error , i get these errors...

[  295.496749] hub 4-1:1.0: cannot reset port 3 (err = -71)
[  301.507153] xhci-hcd xhci-hcd: xHCI host not responding to stop endpoint 
command.
[  301.513153] xhci-hcd xhci-hcd: Assuming host is dying, halting host.
[  301.539664] xhci-hcd xhci-hcd: HC died; cleaning up
[  301.543196] hub 4-1:1.0: cannot reset port 3 (err = -110)
[  301.548456] hub 4-1:1.0: cannot reset port 3 (err = -19)
[  301.553888] PM: resume of devices complete after 159484.626 msecs
[  301.560084] PM: Finishing wakeup.
[  301.563121] Restarting tasks ...
[  301.566756] usb 3-1: USB disconnect, device number 2
[  301.586698] usb 4-1: USB disconnect, device number 2
[  301.596611] done.
[  301.601652] usb 4-1.3: USB disconnect, device number 3
localhost user #
localhost user #

After this 3.0 port becomes DEAD, it does not detect any attach /detach.  

even i tired with another hub, same is the issue...

all the cases of suspend / resume works except this case, by that i mean

1. USB 3.0 Device on 3.0 port - Works fine. 
2. USB 3.0 Device on 2.0 port - Works fine.
3. USB 2.0 Device on 3.0 port - Works fine.
4. USB 2.0 Device on 2.0 port - Works fine.
5. USB 2.0 Device on SS hub on 3.0 port - Works fine.
6. USB 2.0 Device on 2.0 hub on 3.0 port - Works fine. 
7. USB 3.0 Device on 2.0 hub on 3.0 port - Works fine.
8. USB 3.0 Device on SS hub on 2.0 port - Works fine.
9. USB 3.0 Device on SS hub on 3.0 port - FAILS. 
 
Regards
Vikas Sajjan

--- Original Message ---
Sender : Andiry Xuand...@gmail.com 
Date   : Aug 18, 2012 21:54 (GMT+09:00)
Title  : Re: 3.0 device attached to USB 3.0 hub port doesn't respond address
 device command after resume

On Sat, Aug 18, 2012 at 7:41 PM, VIKAS SAJJAN C
vikas.saj...@samsung.com wrote:

 Hi All,

 we have added Suspend / resume code for DWC USB 3  controller and xhic-plat.c 
 on 3.4 kernel.

 the scenario when i have Corsair 3.0 USB device sitting on VIA 3.0 SS hub 
 connected to 3.0 port,

 after resume , i get these error

  176.942208] xhci-hcd xhci-hcd: Timeout while waiting for address device 
 command
 [  202.152208] xhci-hcd xhci-hcd: Timeout while waiting for address device 
 command
 [  202.362207] usb 4-1.1: device not accepting address 3, error -62
 [  227.437201] xhci-hcd xhci-hcd: Timeout while waiting for address device 
 command
 [  252.647205] xhci-hcd xhci-hcd: Timeout while waiting for address device 
 command
 [  252.857201] usb 4-1.1: device not accepting address 3, error -62
 [  277.932206] xhci-hcd xhci-hcd: Timeout while waiting for address device 
 command
 [  303.142208] xhci-hcd xhci-hcd: Timeout while waiting for address device 
 command
 [  303.352202] usb 4-1.1: device not accepting address 3, error -62

 i was referring this
 http://www.spinics.net/lists/linux-usb/msg58474.html . but then i found that 
 i already have this patch. ( USB: Set hub depth after USB3 hub reset )


What happen if you remove the hub or try a different hub?

Thanks,
Andiry

 Regards
 Vikas Sajjan


[PATCH] usb: dwc3: debugfs: fixes debugfs regdump returning all zeros

2012-08-21 Thread Vikas Sajjan
Even though the mem region is requested from the Globals address
space (DWC3_GLOBALS_REGS_START), the offsets are given from the
starting of the xHCI address space.

By subtracting DWC3_GLOBALS_REGS_START from the offset ( as done in
dwc3_readl() and dwc3_writel() ) resolves the issue.

Signed-off-by: Vikas C Sajjan vikas.saj...@samsung.com
---
 drivers/usb/dwc3/debugfs.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
index d4a30f1..51c55bb 100644
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
@@ -56,7 +56,7 @@
 #define dump_register(nm)  \
 {  \
.name   = __stringify(nm),  \
-   .offset = DWC3_ ##nm,   \
+   .offset = DWC3_ ##nm - DWC3_GLOBALS_REGS_START  \
 }
 
 static const struct debugfs_reg32 dwc3_regs[] = {
-- 
1.7.0.4

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


Re: Re: 3.0 device attached to USB 3.0 hub port doesn't respond address device command after resume

2012-08-20 Thread VIKAS SAJJAN C

Hi ,

if i disconnect the hub, after the timeout error , i get these errors...

[  295.496749] hub 4-1:1.0: cannot reset port 3 (err = -71)
[  301.507153] xhci-hcd xhci-hcd: xHCI host not responding to stop endpoint 
command.
[  301.513153] xhci-hcd xhci-hcd: Assuming host is dying, halting host.
[  301.539664] xhci-hcd xhci-hcd: HC died; cleaning up
[  301.543196] hub 4-1:1.0: cannot reset port 3 (err = -110)
[  301.548456] hub 4-1:1.0: cannot reset port 3 (err = -19)
[  301.553888] PM: resume of devices complete after 159484.626 msecs
[  301.560084] PM: Finishing wakeup.
[  301.563121] Restarting tasks ...
[  301.566756] usb 3-1: USB disconnect, device number 2
[  301.586698] usb 4-1: USB disconnect, device number 2
[  301.596611] done.
[  301.601652] usb 4-1.3: USB disconnect, device number 3
localhost user #
localhost user #

After this 3.0 port becomes DEAD, it does not detect any attach /detach.  

even i tired with another hub, same is the issue...

all the cases of suspend / resume works except this case, by that i mean

1. USB 3.0 Device on 3.0 port - Works fine. 
2. USB 3.0 Device on 2.0 port - Works fine.
3. USB 2.0 Device on 3.0 port - Works fine.
4. USB 2.0 Device on 2.0 port - Works fine.
5. USB 2.0 Device on SS hub on 3.0 port - Works fine.
6. USB 2.0 Device on 2.0 hub on 3.0 port - Works fine. 
7. USB 3.0 Device on 2.0 hub on 3.0 port - Works fine.
8. USB 3.0 Device on SS hub on 2.0 port - Works fine.
9. USB 3.0 Device on SS hub on 3.0 port - FAILS. 
 
Regards
Vikas Sajjan

--- Original Message ---
Sender : Andiry Xuand...@gmail.com 
Date   : Aug 18, 2012 21:54 (GMT+09:00)
Title  : Re: 3.0 device attached to USB 3.0 hub port doesn't respond address
 device command after resume

On Sat, Aug 18, 2012 at 7:41 PM, VIKAS SAJJAN C
vikas.saj...@samsung.com wrote:

 Hi All,

 we have added Suspend / resume code for DWC USB 3  controller and xhic-plat.c 
 on 3.4 kernel.

 the scenario when i have Corsair 3.0 USB device sitting on VIA 3.0 SS hub 
 connected to 3.0 port,

 after resume , i get these error

  176.942208] xhci-hcd xhci-hcd: Timeout while waiting for address device 
 command
 [  202.152208] xhci-hcd xhci-hcd: Timeout while waiting for address device 
 command
 [  202.362207] usb 4-1.1: device not accepting address 3, error -62
 [  227.437201] xhci-hcd xhci-hcd: Timeout while waiting for address device 
 command
 [  252.647205] xhci-hcd xhci-hcd: Timeout while waiting for address device 
 command
 [  252.857201] usb 4-1.1: device not accepting address 3, error -62
 [  277.932206] xhci-hcd xhci-hcd: Timeout while waiting for address device 
 command
 [  303.142208] xhci-hcd xhci-hcd: Timeout while waiting for address device 
 command
 [  303.352202] usb 4-1.1: device not accepting address 3, error -62

 i was referring this
 http://www.spinics.net/lists/linux-usb/msg58474.html . but then i found that 
 i already have this patch. ( USB: Set hub depth after USB3 hub reset )


What happen if you remove the hub or try a different hub?

Thanks,
Andiry

 Regards
 Vikas Sajjan
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±ºÆâžØ^n‡r¡ö¦zË�ëh™¨è­Ú¢ø®G«�éh®(­éšŽŠÝ¢j�ú¶m§ÿï�êäz¹Þ–Šàþf£¢·hšˆ§~ˆmš

XHCI mem clean up Crash on 3.4 kernel

2012-08-01 Thread VIKAS SAJJAN C
Hi All,

I am working on linux kernel 3.4.
we have added suspend / resume functionality for USB XHCI stack.

But during xhci_resume() i get crash prints as below and USB 3.0 port becomes 
dead after that.
  
55.611666] __dma_free_remap: trying to free invalid coherent area: f0012000
[   55.618694] [80015f54] (unwind_backtrace+0x0/0x128) from [804f5554] 
(dump_stack+0x20/0x24)
[   55.627287] [804f5554] (dump_stack+0x20/0x24) from [8001a4e4] 
(arm_dma_free+0x98/0xe8)
[   55.635541] [8001a4e4] (arm_dma_free+0x98/0xe8) from [800e2ee8] 
(pool_free_page+0x5c/0x90)
[   55.644126] [800e2ee8] (pool_free_page+0x5c/0x90) from [800e2f94] 
(dma_pool_destroy+0x78/0xa0)
[   55.653155] [800e2f94] (dma_pool_destroy+0x78/0xa0) from [80321c98] 
(xhci_mem_cleanup+0xd0/0x3b0)
[   55.662268] [80321c98] (xhci_mem_cleanup+0xd0/0x3b0) from [8031c410] 
(xhci_resume+0x24c/0x304)
[   55.671208] [8031c410] (xhci_resume+0x24c/0x304) from [8032831c] 
(xhci_plat_resume+0x44/0x58)
[   55.680067] [8032831c] (xhci_plat_resume+0x44/0x58) from [802b6258] 
(platform_pm_resume+0x50/0x64)
[   55.689350] [802b6258] (platform_pm_resume+0x50/0x64) from [802bb0bc] 
(dpm_run_callback+0x54/0x8c)
[   55.698642] [802bb0bc] (dpm_run_callback+0x54/0x8c) from [802bbc84] 
(device_resume+0x150/0x1ac)
[   55.707663] [802bbc84] (device_resume+0x150/0x1ac) from [802bc63c] 
(dpm_resume+0x108/0x240)
[   55.716343] [802bc63c] (dpm_resume+0x108/0x240) from [802bc954] 
(dpm_resume_end+0x1c/0x28)
[   55.724942] [802bc954] (dpm_resume_end+0x1c/0x28) from [800614a0] 
(suspend_devices_and_enter+0x284/0x330)
[   55.734832] [800614a0] (suspend_devices_and_enter+0x284/0x330) from 
[800616a0] (pm_suspend+0x154/0x228)
[   55.744560] [800616a0] (pm_suspend+0x154/0x228) from [8006064c] 
(state_store+0xa0/0xc8)
[   55.752967] [8006064c] (state_store+0xa0/0xc8) from [802117ec] 
(kobj_attr_store+0x1c/0x28)
[   55.761480] [802117ec] (kobj_attr_store+0x1c/0x28) from [80141b9c] 
(sysfs_write_file+0x118/0x14c)
[   55.770685] [80141b9c] (sysfs_write_file+0x118/0x14c) from [800eb010] 
(vfs_write+0xc4/0x140)
[   55.779446] [800eb010] (vfs_write+0xc4/0x140) from [800eb28c] 
(sys_write+0x4c/0x78)
[   55.787432] [800eb28c] (sys_write+0x4c/0x78) from [8000e7c0] 
(ret_fast_syscall+0x0/0x30)

Have i missed anything...please help.

please find the patch attached for Suspend/Resume.

Just for experimental purpose, I tried calling xhci_mem_cleanup() just at the 
end of xhci_mem_init()

but stangely there also i get error..

4.897143] [803218b8] (xhci_mem_cleanup+0x250/0x2f4) from [803223d4] 
(xhci_mem_init+0xa78/0xad8)
[4.906342] [803223d4] (xhci_mem_init+0xa78/0xad8) from [8031b770] 
(xhci_init+0x58/0x64)
[4.914761] [8031b770] (xhci_init+0x58/0x64) from [8031f514] 
(xhci_gen_setup+0x244/0x26c)
[4.923267] [8031f514] (xhci_gen_setup+0x244/0x26c) from [80327d90] 
(xhci_plat_setup+0x1c/0x24)
[4.932295] [80327d90] (xhci_plat_setup+0x1c/0x24) from [802f9ed8] 
(usb_add_hcd+0x1c8/0x64c)
[4.941061] [802f9ed8] (usb_add_hcd+0x1c8/0x64c) from [80327cb4] 
(xhci_plat_probe+0x12c/0x1ec)
[4.950002] [80327cb4] (xhci_plat_probe+0x12c/0x1ec) from [802b614c] 
(platform_drv_probe+0x24/0x28)
[4.959377] [802b614c] (platform_drv_probe+0x24/0x28) from [802b4b14] 
(driver_probe_device+0x158/0x370)
[4.969097] [802b4b14] (driver_probe_device+0x158/0x370) from [802b4d9c] 
(__driver_attach+0x70/0x94)
[4.978559] [802b4d9c] (__driver_attach+0x70/0x94) from [802b2ea4] 
(bus_for_each_dev+0x60/0x9c)
[4.987586] [802b2ea4] (bus_for_each_dev+0x60/0x9c) from [802b44bc] 
(driver_attach+0x28/0x30)
[4.996440] [802b44bc] (driver_attach+0x28/0x30) from [802b3fdc] 
(bus_add_driver+0xe4/0x268)
[5.005207] [802b3fdc] (bus_add_driver+0xe4/0x268) from [802b533c] 
(driver_register+0xac/0x138)
[5.014234] [802b533c] (driver_register+0xac/0x138) from [802b6468] 
(platform_driver_register+0x54/0x68)
[5.024042] [802b6468] (platform_driver_register+0x54/0x68) from 
[80327db4] (xhci_register_plat+0x1c/0x24)
[5.034024] [80327db4] (xhci_register_plat+0x1c/0x24) from [8072e0a4] 
(xhci_hcd_init+0x10/0x30)
[5.043052] [8072e0a4] (xhci_hcd_init+0x10/0x30) from [8000869c] 
(do_one_initcall+0xa0/0x170)
[5.051904] [8000869c] (do_one_initcall+0xa0/0x170) from [80711a48] 
(kernel_init+0xf8/0x1b4)
[5.060672] [80711a48] (kernel_init+0xf8/0x1b4) from [8000fa48] 
(kernel_thread_exit+0x0/0x8)


How i wonder where is the problem in xhci_mem_cleanup()...

Regards
Vikas Sajjan



USB_S2R.patch
Description: Binary data


usb 2.0 device connected on Super Speed HUB on USB 3.0 Port throws error during enumeration on 3.4 kernel.

2012-07-13 Thread VIKAS SAJJAN C
Hi ,
I am working on 3.4 kernel , when i try to connect a USB 2.0 device on Super 
Speed HUB , i get following error.

usb 3-1.1: Device not responding to set address.
usb 3-1.1: device not accepting address 3, error -71

any inputs will be of great help.

Thanks and Regards
Vikas Sajjan

Re: Re: usb 2.0 device connected on Super Speed HUB on USB 3.0 Port throws error during enumeration on 3.4 kernel.

2012-07-13 Thread VIKAS SAJJAN C
Hi Andiry,


1. xHCI root hub --- SS hub --- some other USB 2.0 devices  
   - I tired with 2 more usb 2.0 devices , same error comes.

2. xHCI root hub --- some other SS hub or HS hub  --- the same USB2.0 device
-- i connected xHCI root hub --HS hub-- the same 2.0 device , it works 
fine.

  I dont have another SS hub to check with.

please find the attachement fot the log.

Regards
Vikas Sajjan

--- Original Message ---
Sender : Andiry Xuandiry...@amd.com 
Date   : Jul 13, 2012 17:11 (GMT+09:00)
Title  : Re: usb 2.0 device connected on Super Speed HUB on USB 3.0 Port throws
 error during enumeration on 3.4 kernel.

On 07/13/2012 03:50 PM, VIKAS SAJJAN C wrote:
 Hi Andiry,

 Thanks for the reply.

 If I connect the USB 2.0 Device directly to the USB 3.0 Port (without the SS 
 Hub ), it works fine.
 It even works fine if i connect the same USB 2.0 Device through a SS Hub 
 connected to USB 2.0 port (EHCI root hub).

 the Problem comes if i connect the same USB 2.0 Device through a SS Hub 
 connected to USB 3.0 port (XHCI root hub).


When a SS hub is connected to EHCI, it just works like a HS hub. No 
address device command is issued.

Can you post the output of lsusb - and lspci -vvnn?

And what occurs with the following two scnearios:

1. xHCI root hub --- SS hub --- some other USB 2.0 devices
2. xHCI root hub --- some other SS hub or HS hub  --- the same USB2.0 device

Thanks,
Andiry



 --- Original Message ---
 Sender : Andiry Xuandiry...@amd.com
 Date   : Jul 13, 2012 16:29 (GMT+09:00)
 Title  : Re: usb 2.0 device connected on Super Speed HUB on USB 3.0 Port 
 throws
   error during enumeration on 3.4 kernel.

 On 07/13/2012 02:49 PM, VIKAS SAJJAN C wrote:
 Hi ,
 I am working on 3.4 kernel , when i try to connect a USB 2.0 device on Super 
 Speed HUB , i get following error.

 usb 3-1.1: Device not responding to set address.
 usb 3-1.1: device not accepting address 3, error -71

 any inputs will be of great help.

 Thanks and Regards
 Vikas Sajjan¢éì¹»®Þ~º¶¬–+-±éݶ¥Šw®žË›±Êâmébžìn±¸§¶›¡Ü¨}©ž²Æ 
 zÚj:+v‰¨¾«‘êçzZ+€Ê+zf£¢·hšˆ§~†­†Ûiÿûàz¹®w¥¢¸?™¨è­Ú¢)ߢf

 The address command is rejected by the device. What happens if you plug
 the device to EHCI controller or to xHCI root hub (without the SS hub)?

 Thanks,
 Andiry





lsusb.txt
Description: Binary data


Re: Re: usb 2.0 device connected on Super Speed HUB on USB 3.0 Port throws error during enumeration on 3.4 kernel.

2012-07-13 Thread VIKAS SAJJAN C

I tested same USB 2.0 device on a linux machine running 3.2.19 kernel 
connecting through same VIA SS hub.
it works fine.  
now i wonder where is the issue in my 3.4.0 kernel. is it in my exynos driver 
or usb core...

--- Original Message ---
Sender : Elric Fuelric...@gmail.com 
Date   : Jul 13, 2012 18:59 (GMT+09:00)
Title  : Re: usb 2.0 device connected on Super Speed HUB on USB 3.0 Port throws
 error during enumeration on 3.4 kernel.

2012/7/13 Andiry Xu andiry...@amd.com:
 On 07/13/2012 04:57 PM, VIKAS SAJJAN C wrote:

 Hi Andiry,


 1. xHCI root hub --- SS hub --- some other USB 2.0 devices
 - I tired with 2 more usb 2.0 devices , same error comes.

 2. xHCI root hub --- some other SS hub or HS hub  --- the same USB2.0
 device
 -- i connected xHCI root hub --HS hub--  the same 2.0 device , it
 works fine.

I dont have another SS hub to check with.


 SO that sounds like a hub issue.

I think it seems like the hub is broken.




 please find the attachement fot the log.


 It's a VIA USB3.0 hub. I've not used it before but I heard it has several
 issues. So the easiest solution is to use another SS hub which passes USB-IF
 certification.

Umm, Until now no one pass the USB-IF due to the Forum isn't ready
for usb 3.0 hub.



 Thanks,
 Andiry


 --- Original Message ---
 Sender : Andiry Xuandiry...@amd.com
 Date   : Jul 13, 2012 17:11 (GMT+09:00)
 Title  : Re: usb 2.0 device connected on Super Speed HUB on USB 3.0 Port
 throws
   error during enumeration on 3.4 kernel.

 On 07/13/2012 03:50 PM, VIKAS SAJJAN C wrote:

 Hi Andiry,

 Thanks for the reply.

 If I connect the USB 2.0 Device directly to the USB 3.0 Port (without the
 SS Hub ), it works fine.
 It even works fine if i connect the same USB 2.0 Device through a SS Hub
 connected to USB 2.0 port (EHCI root hub).

 the Problem comes if i connect the same USB 2.0 Device through a SS Hub
 connected to USB 3.0 port (XHCI root hub).


 When a SS hub is connected to EHCI, it just works like a HS hub. No
 address device command is issued.

 Can you post the output of lsusb - and lspci -vvnn?

 And what occurs with the following two scnearios:

 1. xHCI root hub --- SS hub --- some other USB 2.0 devices
 2. xHCI root hub --- some other SS hub or HS hub  --- the same USB2.0
 device

 Thanks,
 Andiry



 --- Original Message ---
 Sender : Andiry Xuandiry...@amd.com
 Date   : Jul 13, 2012 16:29 (GMT+09:00)
 Title  : Re: usb 2.0 device connected on Super Speed HUB on USB 3.0 Port
 throws
error during enumeration on 3.4 kernel.

 On 07/13/2012 02:49 PM, VIKAS SAJJAN C wrote:

 Hi ,
 I am working on 3.4 kernel , when i try to connect a USB 2.0 device on
 Super Speed HUB , i get following error.

 usb 3-1.1: Device not responding to set address.
 usb 3-1.1: device not accepting address 3, error -71

 any inputs will be of great help.

 Thanks and Regards
 Vikas Sajjan ¢éì¹» ®Þ~º¶ ¬–+-±éݶ ¥Šw®žË›±Êâmébžìn±¸§¶ ›¡Ü¨}©ž²Æ
 zÚj:+v‰¨¾ «‘êçzZ+€Ê+zf£¢·hšˆ§~†­†Ûiÿûàz¹ ®w¥¢¸?™¨è­Ú¢)ߢ f


 The address command is rejected by the device. What happens if you plug
 the device to EHCI controller or to xHCI root hub (without the SS hub)?

 Thanks,
 Andiry





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