Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp4600446ybi; Mon, 15 Jul 2019 11:31:30 -0700 (PDT) X-Google-Smtp-Source: APXvYqyaA0rJZUHhqboPlo1kNXsuq36eoTI6jvlm1yo8bmmewzApFkT0ylIQOIAYhGdR/LbFqU2E X-Received: by 2002:a17:90a:8c0c:: with SMTP id a12mr30784052pjo.67.1563215490437; Mon, 15 Jul 2019 11:31:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563215490; cv=none; d=google.com; s=arc-20160816; b=YHro3vzTe3rXl2nYDA5dJPIf8W8uvgDXANLNd2F6PxwY63TpEGtiyhLsfxHQ5j0I8D AQYhK7gjl5Boi4FIUuDV6EDXpe4dM9/PbFCOnviZJWFUlUEqofNpTujVyjZBuGxEU1ZF CLPgdny1aCZVm2nWh/da9U0xtMANqtAKr+PBllOo1gsMa2S5JDFqsQeW4z8/bfrDGIAI wxU3C4JnDZYJ0Hymb2XyGIXv8wU11nA9mjncEz91vuNHhR0WJ1GphjNmL+mSKXFDHLNc Q101RQc3LqP5zyRxXPXPtZkeheWSUrgNgMXgCLAdSPN+VxsoXjWJbXD2c3RYO8cJlpzP pEaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=0X1xWUDisNrQkHHS+wT5XXw2/LuKVAjvvac2sZ0xEs4=; b=wlbQcguvmCajYNG0OUhUAwDvxp+4RDacG46qisEVcnHhSvZd/MsNlZ5D6BY3zoQNfa XakihEHFW0dLCKptsyXxkaYxy7xH+Q0E6zCPYT9Ev5nMoWh4M7lqHuuPgbX3fEE7Jp4a RtNyp1IvJyKCrwKHaC/m5mktCsapYGibqzvdOekipIR/Xgwp5wPKReEDXX3iyMyf7+wu dDzyyDsEEUeAcFOJGn5LjpUTbWaWfMPjaxH6df/xuboJVtTyusaBih8sZElZG5Y/KfTY Cnje5gOUClcdGOmPlAtMFKpR5H0O5JWSdIFgJFaFOELY6eAFr/UTAbXXAA5rvqzlKyG5 CceQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=G8e2t3GU; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n12si18227647pgi.550.2019.07.15.11.31.14; Mon, 15 Jul 2019 11:31:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=G8e2t3GU; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729668AbfGOS3k (ORCPT + 99 others); Mon, 15 Jul 2019 14:29:40 -0400 Received: from mail-ed1-f66.google.com ([209.85.208.66]:42226 "EHLO mail-ed1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729413AbfGOS3j (ORCPT ); Mon, 15 Jul 2019 14:29:39 -0400 Received: by mail-ed1-f66.google.com with SMTP id v15so16443761eds.9; Mon, 15 Jul 2019 11:29:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0X1xWUDisNrQkHHS+wT5XXw2/LuKVAjvvac2sZ0xEs4=; b=G8e2t3GUyh4I/ptj2KFL+QUj+yO2aSKfbM/hyToU+aKZv0FfCThy0d6iDf8dnwe38x ue7OxrOy7/4tQZ//abWY75uFWXeStsqHJeV4tT1NOh4JSDeNEMx0pS7fMUFtQKuVu9qb 41xkyKf4NYdpKFVfFMVavWcJowFEXPUr6k9MKGrrtyTalbAv05gl/bf/ycyhEPPnBssb vcWvt/G9WjmPUwfYrXwkvxj0WGVFfQVd95ijnGaGSDfqqLGGNd7g8Gtw12RROjbS4LFp NY3xh6Ogg8HCHefeeMcLBDR7FyzdANmMKBncOVjufDUgKukDJL0TxKQjAVSfO5xu4MU7 qgPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0X1xWUDisNrQkHHS+wT5XXw2/LuKVAjvvac2sZ0xEs4=; b=gFy+7eOYBZaImknjKH6jWrmHPaRxi/kvoIrjVzeMij7vvJXjDOf3FjhIEAufQDTJDI xNUTyISQ3cNNUSweHwKUc5LbgBzfCijoNAUmI6ZR5gJYO0Zl/amnxngl1mDtRE6fKO3F uS388OvTZ9qx7LcMP94NqEQmwcPnMgqDnWdtCxjrz/MEMizeGlNqjnwLzCPsJ1sryGP0 1Ph65tot1WnkN7qzYmDPnafU7me86joYKNer3ywCuxQTjUsZ4G7iZ2O+NbPcyGyl/GYQ tfIFBzwCwPBwHJRlyI7NPdNDL1uHx/ERnkbpHsvLtTWX6ehw5mot/x37Ek6btu9USafA EMWA== X-Gm-Message-State: APjAAAW7W9R7/32oDU/8wIUuJWLQDuw06mnnfAsk4GNnUJGlSRdCMLf4 XIjKuG1/+5bdxChG2sPXt14qCczAQjPCDDs+eGs= X-Received: by 2002:a05:6402:145a:: with SMTP id d26mr24860170edx.10.1563215376896; Mon, 15 Jul 2019 11:29:36 -0700 (PDT) MIME-Version: 1.0 References: <20190627071726.30467-1-m.szyprowski@samsung.com> <7b9700b5-fe8b-8a15-e136-9a2afd1619ab@samsung.com> In-Reply-To: <7b9700b5-fe8b-8a15-e136-9a2afd1619ab@samsung.com> From: Anand Moon Date: Mon, 15 Jul 2019 23:59:26 +0530 Message-ID: Subject: Re: [PATCH 0/3] Fix USB3.0 DRD PHY calibration issues (DWC3/XHCI) on Exynos542x SoCs To: Marek Szyprowski Cc: Linux USB Mailing List , linux-samsung-soc@vger.kernel.org, Linux Kernel , Greg Kroah-Hartman , Mathias Nyman , Felipe Balbi , Bartlomiej Zolnierkiewicz , Krzysztof Kozlowski , Jochen Sprickerhof Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Marek, On Mon, 15 Jul 2019 at 17:49, Marek Szyprowski wrote: > > Hi Anand, > > On 2019-06-28 17:32, Anand Moon wrote: > > Hi Marek, > > > > On Thu, 27 Jun 2019 at 12:47, Marek Szyprowski wrote: > >> Dear All, > >> > >> Commit d8c80bb3b55b ("phy: exynos5-usbdrd: Calibrate LOS levels for > >> exynos5420/5800") added support for Exynos5 USB3.0 DRD PHY calibration, > >> what enabled proper Super-Speed enumeration of USB3.0 devices connected > >> to various Exynos5 SoCs. After some time it turned out that the mentioned > >> patch worked a bit by pure luck and covered only one use case (fresh > >> boot with all drivers compiled into the kernel). > >> > >> If drivers were compiled as modules, due to timing issue, it worked only > >> if XHCI-plat driver was loaded before the DWC3 driver: > >> https://patchwork.kernel.org/patch/10773947/ > >> > >> Also during the system suspend/resume cycle the calibration was not > >> performed at the proper time and resulted in switching USB 3.0 devices to > >> USB 2.0 high-speed compatibility mode. > >> > >> This patch addresses all those issues. Exynos5 USB3.0 DRD PHY calibration > >> is moved to the Exynos5 specific variant of the XHCI-plat driver, which > >> takes care of proper PHY calibration after XHCI core reset. This fixes > >> all known use cases (XHCI driver compiled as module and loaded on demand > >> as well as during system suspend/resume cycle). > >> > >> Here are the logs taken on Exynos5422-based Odroid HC1 board (with USB3.0 > >> RTL8153 LAN and USB3.0 JMicron SATA-USB bridge): > >> > > Thanks for these patch. I have tested on linux-next-20190626 > > > > *But hotpluging of usb device is not working on usb ports.* > > Well, this is a bit poor report. I've checked various USB 3.0 devices > with my XU4 board and didn't observe any issue with hotplug or > enumeration. Could you describe a bit more how to trigger the issue? > Sorry for the noise one of my usb 3.0 port on XU4 is not working somehow. I will re-test these patches again on current next and share my result. > > These patches fix the suspend/resume for XU4. > > But their is two issue. > > 1> On warm boot fails to reset the usb hub > > ------------------------------------------------------------------ > > [ 7.019896] usb 4-1.1: new SuperSpeed Gen 1 USB device number 3 > > using xhci-hcd > > [ 7.063032] usb 4-1.1: New USB device found, idVendor=152d, > > idProduct=0578, bcdDevice=63.01 > > [ 7.070484] usb 4-1.1: New USB device strings: Mfr=1, Product=2, > > SerialNumber=3 > > [ 7.077438] usb 4-1.1: Product: JMS567 > > [ 7.081749] usb 4-1.1: Manufacturer: JMicron > > [ 7.086028] usb 4-1.1: SerialNumber: DB12345678A3 > > [ 7.151572] scsi host0: uas > > [ 7.162765] scsi 0:0:0:0: Direct-Access KINGSTON SA400S37120G > > 6301 PQ: 0 ANSI: 6 > > [ 7.176231] sd 0:0:0:0: [sda] 234441648 512-byte logical blocks: > > (120 GB/112 GiB) > > [ 7.177550] sd 0:0:0:0: Attached scsi generic sg0 type 0 > > [ 7.183547] sd 0:0:0:0: [sda] 4096-byte physical blocks > > [ 7.201150] sd 0:0:0:0: [sda] Write Protect is off > > [ 7.204977] sd 0:0:0:0: [sda] Disabling FUA > > [ 7.209476] sd 0:0:0:0: [sda] Write cache: enabled, read cache: > > enabled, doesn't support DPO or FUA > > [ 7.219411] sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes > > not a multiple of physical block size (4096 bytes) > > [ 7.713603] sda: sda1 > > [ 7.736338] sd 0:0:0:0: [sda] Attached SCSI disk > > [ 11.372630] xhci-hcd exynos5-dwc3-xhci.5.auto: Timeout while > > waiting for setup device command > > [ 16.650624] xhci-hcd exynos5-dwc3-xhci.5.auto: Timeout while > > waiting for setup device command > > [ 16.870255] usb 6-1: device not accepting address 2, error -62 > > [ 22.171093] xhci-hcd exynos5-dwc3-xhci.5.auto: Timeout while > > waiting for setup device command > > [ 27.451021] xhci-hcd exynos5-dwc3-xhci.5.auto: Timeout while > > waiting for setup device command > > [ 27.669956] usb 6-1: device not accepting address 3, error -62 > > [ 27.711656] usb usb6-port1: attempt power cycle > > > > some how 12500000.phy do not de-register when we perform reboot. > > Sorry, but this is not related to PHY at all. If I get your log right, > you have external USB3->SATA bridge which fails to enumerate in your > case. Does it work right with other boards or vendor kernels? You > connect it to the XU4 onboard USB3.0 hub, which cannot be programmed or > controlled in any way, so I doubt we can do anything to fix your issue. > Sorry this issue is related to realtek ethernet driver r-8153 failed to register again after reboot. It's a know issue for long time as far as I know, I will double check this again. > > > [ 120.260813] shutdown[1]: All loop devices detached. > > [ 120.308592] sd 0:0:0:0: [sda] Synchronizing SCSI cache > > [ 120.425890] usb 4-1.1: reset SuperSpeed Gen 1 USB device number 3 > > using xhci-hcd > > [ 120.500085] wake enabled for irq 155 > > [ 120.592335] reboot: Restartin > > > > Attach are the reboot logs. > > [0] https://pastebin.com/a3d712q4 > > > > Second issue is the unbind on usb dwc3 fails. > > > > [root@archl-xu4m ~]# cd /sys/bus/platform/drivers/exynos5_usb3drd_phy/ > > [root@archl-xu4m exynos5_usb3drd_phy]# ls -la > > total 0 > > drwxr-xr-x 2 root root 0 Jun 28 14:08 . > > drwxr-xr-x 131 root root 0 Jun 28 14:08 .. > > lrwxrwxrwx 1 root root 0 Jun 28 14:11 12100000.phy -> > > ../../../../devices/platform/soc/12100000.phy > > lrwxrwxrwx 1 root root 0 Jun 28 14:11 12500000.phy -> > > ../../../../devices/platform/soc/12500000.phy > > --w------- 1 root root 4096 Jun 28 14:11 bind > > --w------- 1 root root 4096 Jun 28 14:08 uevent > > --w------- 1 root root 4096 Jun 28 14:11 unbind > > [root@archl-xu4m exynos5_usb3drd_phy]# > > [root@archl-xu4m exynos5_usb3drd_phy]# > > [root@archl-xu4m exynos5_usb3drd_phy]# echo 12500000.phy > unbind > > This is not dwc3 unbind, but USB3.0 DRD PHY unbind. This is somehow > expected as unbinding on fly a device, which provides resources to other > driver (in this case USB phys) causes various issues due to the Linux > kernel frameworks design. Please don't try such things, it won't work. > Exynos DRD PHY driver should be marked with suppress_bind flag to hide > bind/unbind attributes. > Ok thanks for your inputs and suggestion. > Best regards > -- > Marek Szyprowski, PhD > Samsung R&D Institute Poland > Best Regards -Anand