Re: [PATCH] fix the code style errors in sn9c102
On Sat, Apr 19, 2014 at 11:09 AM, Jinqiang Zeng jinqiangz...@gmail.com wrote: --- drivers/staging/media/sn9c102/sn9c102.h| 30 +- drivers/staging/media/sn9c102/sn9c102_core.c | 342 ++-- drivers/staging/media/sn9c102/sn9c102_devtable.h | 22 +- drivers/staging/media/sn9c102/sn9c102_hv7131d.c| 22 +- drivers/staging/media/sn9c102/sn9c102_hv7131r.c| 22 +- drivers/staging/media/sn9c102/sn9c102_mi0343.c | 30 +- drivers/staging/media/sn9c102/sn9c102_mi0360.c | 30 +- drivers/staging/media/sn9c102/sn9c102_ov7630.c | 22 +- drivers/staging/media/sn9c102/sn9c102_ov7660.c | 22 +- drivers/staging/media/sn9c1 Hi, Jinqiang, you just missed something. 1. a Signed-off-by line, if you use git, git-format-patch is a good tool.;-) 2. better add a module name in cover later, like this: sn9c102: fix the coding style errors 3. maybe some changelog is good, but for this patch, leaving it out is OK. You would better read the Documentation/SubmittingPatches . Thanks, Jianyu Zhan -- 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 OTG support on mx27pdk
On Wed, Apr 16, 2014 at 09:53:34AM -0300, Fabio Estevam wrote: On Wed, Apr 16, 2014 at 8:58 AM, Alexander Shiyan shc_w...@mail.ru wrote: I can tell immediately without further testing, this will not work without the USB support in the bootoader because we do not have DT support for ULPI. The generic nop usb phy should work just fine. I have tried Uwe's suggestion from a previous post and reverted: commit cd0b42c2a6d2a74244f0053f8960f5dad5842278 Author: Chris Ruehl chris.ru...@gtsys.com.hk Date: Fri Jan 10 13:51:30 2014 +0800 usb: chipidea: put hw_phymode_configure before ci_usb_phy_init hw_phymode_configure configures the PORTSC registers and allow the following phy_inits to operate on the right parameters. This fix a problem where the UPLI (ISP1504) could not be detected, because the Viewport was not available and read the viewport return 0's only. Signed-off-by: Chris Ruehl chris.ru...@gtsys.com.hk Signed-off-by: Peter Chen peter.c...@freescale.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org Then USB OTG port detected the USB pen driver fine: usbcore: registered new interface driver usb-storage 10024000.usb supply vbus not found, using dummy regulator ci_hdrc ci_hdrc.0: EHCI Host Controller ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1 ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00 hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected ... scsi 0:0:0:0: Direct-Access ChipsBnk Flash Disk 2.00 PQ: 0 ANSI: 2 sd 0:0:0:0: [sda] 1035200 512-byte logical blocks: (530 MB/505 MiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] No Caching mode page found sd 0:0:0:0: [sda] Assuming drive cache: write through sda: sda1 sd 0:0:0:0: [sda] Attached SCSI removable disk If I understand correctly commit cd0b42c2a was only needed because Chris was trying to add DT support for ULPI, which never got merged into mainline. If we use the generic nop usb phy instead, we should just revert this commit. Any objections? Yes, when this patch got reverted it will probably break usb support on mx6 machines. We have seen different behaviour on several mxc/mxs machines regarding the order of PORTSC and phy configuration. We will probably need to test all platforms before reordering this function call again and again for every machine using this driver. The below patch is intended to fix above issues for all platforms, I have tested it at imx6 platform, if possible, have a test at imx25/imx27 please. Peter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BBB gadgetfs freeze patch
I have the same problem but it did not occur when the usb cable was detached. -- 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 05/13] extcon: extcon-class: improve extcon client API
Hi, On Mon, Apr 14, 2014 at 01:46:16PM +0200, Robert Baldyga wrote: dev_info(pdev-dev, - OMAP USB OTG controller rev %d.%d (%s, id=%d, vbus=%d)\n, - (rev 4) 0xf, rev 0xf, config-extcon, otg_dev-id, + OMAP USB OTG controller rev %d.%d (id=%d, vbus=%d)\n, + (rev 4) 0xf, rev 0xf, otg_dev-id, otg_dev-vbus); This change is unrelated to the patch and not needed. A. -- 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
External hard drive connection issues with xHCI
Hi, I have an external hard drive (well, actually a case for an internal one, but this may not be relevant) that connects to the PC via USB3. However, I've been experiencing erratic behaviour with it. So far there have been two issues. One is that if I boot with the cable plugged in already, then it fails to mount the volume (or, indeed, report that it even exists). However, if I either remove the cable and replug it into another USB3 socket or if I plug it in only after it's done booting, then everything is fine and I can see and mount the volume. I'll attach the dmesg errors about it. The other issue is rather peculiar. When I get it mounted, doing certain I/O tasks (I'm testing with btrfs send/receive) results in the device disconnecting and unmounting (the key error seems to be xHCI xhci_drop_endpoint called with disabled ep 8801aced5d40). When it's connected through a USB2 port, I also get errors (reset high-speed USB device number 6 using ehci-pci), but they don't result in unmounting the volume. And if I do large file copying instead of btrfs send/receive, then everything works fine even when connected through USB3. I'll also attach the error logs in question. I also tested this with a separate USB2 cable, and the results are the same as when I use the USB3 cable but connect it to a USB2 port. I'm currently using kernel 3.10.11. Any ideas about what could be causing this behaviour with USB3? [0.921676] xhci_hcd :00:14.0: setting latency timer to 64 [0.921680] xhci_hcd :00:14.0: xHCI Host Controller [0.921687] xhci_hcd :00:14.0: new USB bus registered, assigned bus number 3 [0.921771] xhci_hcd :00:14.0: cache line size of 64 is not supported [0.921794] xhci_hcd :00:14.0: irq 43 for MSI/MSI-X [0.921843] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 [0.921845] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [0.921846] usb usb3: Product: xHCI Host Controller [0.921848] usb usb3: Manufacturer: Linux 3.11.10-7-desktop xhci_hcd [0.921849] usb usb3: SerialNumber: :00:14.0 [0.922074] xHCI xhci_add_endpoint called for root hub [0.922076] xHCI xhci_check_bandwidth called for root hub [0.922099] hub 3-0:1.0: USB hub found [0.922106] hub 3-0:1.0: 4 ports detected [0.923854] xhci_hcd :00:14.0: xHCI Host Controller [0.923858] xhci_hcd :00:14.0: new USB bus registered, assigned bus number 4 [0.923876] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003 [0.923878] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [0.923880] usb usb4: Product: xHCI Host Controller [0.923881] usb usb4: Manufacturer: Linux 3.11.10-7-desktop xhci_hcd [0.923882] usb usb4: SerialNumber: :00:14.0 [0.923956] xHCI xhci_add_endpoint called for root hub [0.923957] xHCI xhci_check_bandwidth called for root hub [0.923977] hub 4-0:1.0: USB hub found [0.923983] hub 4-0:1.0: 4 ports detected [1.294519] usb 3-4: new high-speed USB device number 2 using xhci_hcd [6.294532] xhci_hcd :00:14.0: Timeout while waiting for address device command [ 11.495571] xhci_hcd :00:14.0: Timeout while waiting for address device command [ 11.696552] usb 3-4: device not accepting address 2, error -62 [ 11.849577] usb 3-4: new high-speed USB device number 3 using xhci_hcd [ 16.849611] xhci_hcd :00:14.0: Timeout while waiting for address device command [ 22.050578] xhci_hcd :00:14.0: Timeout while waiting for address device command [ 22.251554] usb 3-4: device not accepting address 3, error -62 [ 22.404569] usb 3-4: new high-speed USB device number 4 using xhci_hcd [ 27.404495] xhci_hcd :00:14.0: Timeout while waiting for address device command [ 32.605405] xhci_hcd :00:14.0: Timeout while waiting for address device command [ 32.806420] usb 3-4: device not accepting address 4, error -62 [ 32.959422] usb 3-4: new high-speed USB device number 5 using xhci_hcd [ 37.959351] xhci_hcd :00:14.0: Timeout while waiting for address device command [ 43.160272] xhci_hcd :00:14.0: Timeout while waiting for address device command [ 43.361278] usb 3-4: device not accepting address 5, error -62 [ 43.361321] hub 3-0:1.0: unable to enumerate USB device on port 413:01:31 kernel: usb 4-4: new SuperSpeed USB device number 2 using xhci_hcd 13:01:31 kernel: usb 4-4: New USB device found, idVendor=05e3, idProduct=0731 13:01:31 kernel: usb 4-4: New USB device strings: Mfr=3, Product=4, SerialNumber=5 13:01:31 kernel: usb 4-4: Product: USB to S-ATA 13:01:31 kernel: usb 4-4: Manufacturer: Genesyslogic 13:01:31 kernel: usb 4-4: SerialNumber: 0497 13:01:32 mtp-probe[9781]: checking bus 4, device 2: /sys/devices/pci:00/:00:14.0/usb4/4-4 13:01:32 mtp-probe[9781]: bus: 4, device: 2 was not an MTP device 13:01:32 kernel: usb-storage 4-4:1.0: USB Mass Storage device detected 13:01:32 kernel: scsi6
Re: USB OTG support on mx27pdk
On Sat, Apr 19, 2014 at 4:32 AM, Peter Chen peter.c...@freescale.com wrote: The below patch is intended to fix above issues for all platforms, I have tested it at imx6 platform, if possible, have a test at imx25/imx27 please. I don't see any patch below, but anyway I have managed to fix the issue on mx27 at dts level. -- 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: External hard drive connection issues with xHCI
On Sat, 19 Apr 2014, Dainius (GreatEmerald) wrote: Hi, I have an external hard drive (well, actually a case for an internal one, but this may not be relevant) that connects to the PC via USB3. However, I've been experiencing erratic behaviour with it. So far there have been two issues. One is that if I boot with the cable plugged in already, then it fails to mount the volume (or, indeed, report that it even exists). However, if I either remove the cable and replug it into another USB3 socket or if I plug it in only after it's done booting, then everything is fine and I can see and mount the volume. I'll attach the dmesg errors about it. The other issue is rather peculiar. When I get it mounted, doing certain I/O tasks (I'm testing with btrfs send/receive) results in the device disconnecting and unmounting (the key error seems to be xHCI xhci_drop_endpoint called with disabled ep 8801aced5d40). When it's connected through a USB2 port, I also get errors (reset high-speed USB device number 6 using ehci-pci), but they don't result in unmounting the volume. And if I do large file copying instead of btrfs send/receive, then everything works fine even when connected through USB3. I'll also attach the error logs in question. I also tested this with a separate USB2 cable, and the results are the same as when I use the USB3 cable but connect it to a USB2 port. That's to be expected. More to the point would be to test with a USB-2 cable connected to a USB-3 port. I'm currently using kernel 3.10.11. You really should upgrade to 3.14. I don't know whether all the changes to xhci-hcd have been back-ported to the stable kernels. Any ideas about what could be causing this behaviour with USB3? Not much idea regarding the USB-3 problems. Under USB-2, you can try to find out the reason for the resets by collecting a usbmon trace. (It's probably the same as the reason for the USB-3 resets.) See the kernel source file Documentation/usb/usbmon.txt for instructions. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: USB OTG support on mx27pdk
-Original Message-
From: Fabio Estevam [mailto:feste...@gmail.com]
Sent: Sunday, April 20, 2014 1:10 AM
To: Chen Peter-B29397
Cc: Michael Grzeschik; Alexander Shiyan; linux-arm-
ker...@lists.infradead.org; linux-usb@vger.kernel.org; Sascha Hauer;
chris.ru...@gtsys.com.hk; Guo Shawn-R65073
Subject: Re: USB OTG support on mx27pdk
On Sat, Apr 19, 2014 at 4:32 AM, Peter Chen peter.c...@freescale.com
wrote:
The below patch is intended to fix above issues for all platforms,
I have tested it at imx6 platform, if possible, have a test at
imx25/imx27
please.
I don't see any patch below, but anyway I have managed to fix the
issue on mx27 at dts level.
https://github.com/hzpeterchen/linux-usb/commit/c1f42ea27ed3f5d988c63da7849d2e6b445b4fbc
Your problem is different with sasche's, which hang the system due to
no phy clk. The chris's patch should not cause the oops.
Peter
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h��� �G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�
Re: [PATCH 4/8] ARM: mvebu: Add USB3 UTMI support
Hi, On Fri, Apr 18, 2014 at 12:22:39PM +0200, Gregory CLEMENT wrote: The usb3-utmi registers allow to configure the internal USB PHY of the Armada 380/385 SoCs. A small initialization is needed to be able to use the USB3 ports. Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com looks like this should be a generic drivers/phy/phy-utmi.c driver -- balbi signature.asc Description: Digital signature
Re: USB OTG support on mx27pdk
Sun, 20 Apr 2014 00:48:28 + от Peter Chen peter.c...@freescale.com:
-Original Message-
From: Fabio Estevam [mailto:feste...@gmail.com]
Sent: Sunday, April 20, 2014 1:10 AM
To: Chen Peter-B29397
Cc: Michael Grzeschik; Alexander Shiyan; linux-arm-
ker...@lists.infradead.org; linux-usb@vger.kernel.org; Sascha Hauer;
chris.ru...@gtsys.com.hk; Guo Shawn-R65073
Subject: Re: USB OTG support on mx27pdk
On Sat, Apr 19, 2014 at 4:32 AM, Peter Chen peter.c...@freescale.com
wrote:
The below patch is intended to fix above issues for all platforms,
I have tested it at imx6 platform, if possible, have a test at
imx25/imx27
please.
I don't see any patch below, but anyway I have managed to fix the
issue on mx27 at dts level.
https://github.com/hzpeterchen/linux-usb/commit/c1f42ea27ed3f5d988c63da7849d2e6b445b4fbc
Your problem is different with sasche's, which hang the system due to
no phy clk. The chris's patch should not cause the oops.
For me, nothing has changed.
The driver works on i.MX27 PCM970 RDK with the patch as well as without it.
---
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h��� �G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�
