Re: [PATCH v2 0/2] ARM: shmobile: lager: USBHS callback elimination
On Fri, Jul 11, 2014 at 11:23:48AM -0500, Felipe Balbi wrote: On Fri, Jul 11, 2014 at 05:41:52PM +0200, Simon Horman wrote: On Fri, Jul 11, 2014 at 10:12:37AM -0500, Felipe Balbi wrote: On Fri, Jul 11, 2014 at 11:00:07AM +0200, Simon Horman wrote: [Cc Felipe Balbi] On Thu, Jul 10, 2014 at 01:20:34AM -0700, Kuninori Morimoto wrote: Hi Changes in v2: - move phy handle to struct usbhs_priv - add new default pipe type to driver - remove pipe type from Lager board code Ulrich Hecht (2): usb: renesas_usbhs: add R-Car Gen. 2 init and power control ARM: shmobile: lager: remove USBHS callbacks arch/arm/mach-shmobile/board-lager.c | 126 --- drivers/usb/renesas_usbhs/Makefile | 2 +- drivers/usb/renesas_usbhs/common.c | 66 -- drivers/usb/renesas_usbhs/common.h | 2 + drivers/usb/renesas_usbhs/rcar2.c| 76 + drivers/usb/renesas_usbhs/rcar2.h| 4 ++ include/linux/usb/renesas_usbhs.h| 6 ++ 7 files changed, 163 insertions(+), 119 deletions(-) create mode 100644 drivers/usb/renesas_usbhs/rcar2.c create mode 100644 drivers/usb/renesas_usbhs/rcar2.h For all patches Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com [snip] I tested these patches on Lager legacy, and these patches worked correctly. Tested-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com Hi, it seems that the 2nd patch should go through my renesas tree but it depends on the first patch which should be taken by Felipe Balbi (Cced). Felipe, is there any chance that you could take this for v3.16? I am quite happy to make a branch for you to pull for renesas_usbhs if this would make your life easier. you need to take both patches or just patch 1 ? Please just take patch 1. will do. Thanks. Ulrich, please repost patch #2 once patch #1 hits an rc release. -- 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
[GIT PULL] USB driver fixes for 3.16-rc5
The following changes since commit cd3de83f147601356395b57a8673e9c5ff1e59d1: Linux 3.16-rc4 (2014-07-06 12:37:51 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-3.16-rc5 for you to fetch changes up to eb82a3d846fab00c4b9ad6bbe5ade4fa5febc0af: phy: omap-usb2: Balance pm_runtime_enable() on probe failure and remove (2014-07-11 18:23:50 -0700) USB fixes for 3.16-rc5 Here are some small USB fixes, PHY driver fixes (they ended up in this tree for lack of somewhere else to put them), and some new USB device ids. Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org Andras Kovacs (1): USB: cp210x: add support for Corsair usb dongle Bernd Wachter (1): usb: option: Add ID for Telewell TW-LTE 4G v2 Bert Vermeulen (1): USB: ftdi_sio: Add extra PID. Greg Kroah-Hartman (1): Merge tag 'usb-serial-3.16-rc5' of git://git.kernel.org/.../johan/usb-serial into usb-linus Himangi Saraogi (1): phy: omap-usb2: fix devm_ioremap_resource error detection code Maxime Ripard (1): phy: sun4i: depend on RESET_CONTROLLER Michal Sojka (1): USB: serial: ftdi_sio: Add Infineon Triboard Roger Quadros (2): phy: core: Fix error path in phy_create() phy: omap-usb2: Balance pm_runtime_enable() on probe failure and remove Sjoerd Simons (1): drivers: phy: phy-samsung-usb2.c: Add missing MODULE_DEVICE_TABLE drivers/phy/Kconfig | 1 + drivers/phy/phy-core.c| 7 --- drivers/phy/phy-omap-usb2.c | 11 +++ drivers/phy/phy-samsung-usb2.c| 1 + drivers/usb/serial/cp210x.c | 1 + drivers/usb/serial/ftdi_sio.c | 5 - drivers/usb/serial/ftdi_sio_ids.h | 9 - drivers/usb/serial/option.c | 2 ++ 8 files changed, 28 insertions(+), 9 deletions(-) -- 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
ftdi_sio input hang with FT230X at high baud rate, binary data
I'm developing firmware for an embedded device which uses an FT230X. It sends somewhat bursty raw binary data to the host at 300 bps. Presently I'm not sending any data from the host back to the device, though I'll start doing that shortly. I'm finding that the input side of the ftdi_sio driver seems to get stuck after some seemingly random amount of data has been read. I'm putting the device in raw mode with just about everything disabled, and verifying that with stty: $ stty -a /dev/ttyUSB0 speed 300 baud; rows 0; columns 0; line = 0; intr = undef; quit = undef; erase = undef; kill = undef; eof = undef; eol = undef; eol2 = undef; swtch = undef; start = undef; stop = undef; susp = undef; rprnt = undef; werase = undef; lnext = undef; flush = undef; min = 1; time = 0; -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke When the input gets stuck, killing the program reading the input and starting it again resumes the data flow. This happens whether the program is cat, od, or my own program. At first I thought this was some data dependency, and that some received byte value was being treated as a special character, but I changed my firmware to just continuously send a 00 through ff sequence, and it usually manages tor read that entire sequence many times before the input gets stuck. Also, it doesn't get stuck at a consistent place in that sequence. When my firmware does send out 00 through ff at maximum rate, it usually takes longer for the input to get stuck than if I send the real application data, which is bursty. I've tried reducing the data rate to 150 or 100 bps, but the same thing happens. I'm reasonably convinced that the firmware on my embedded device isn't doing anything wrong, as its TxD line is still transmitting when the input gets stuck, and it has no feedback whatsoever indicating that the program on the host has been killed then restarted. It also seems to work fine on a Windows host for as long as I let it run. I'm running Fedora 20 64-bit with kernel 3.15.4-200. I don't expect anyone to debug this for me, but could use some advice on how I might go about debugging the problem if it is in the ftdi_sio driver. I've worked on other Linux device drivers, but not serial or USB drivers. Thanks! Eric -- 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: ftdi_sio input hang with FT230X at high baud rate, binary data
Eric Smith wrote: could use some advice on how I might go about debugging the problem if it is in the ftdi_sio driver. As a data point you could compare the userspace approach with libftdi1. //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: ftdi_sio input hang with FT230X at high baud rate, binary data
On Sat, Jul 12, 2014 at 5:33 PM, Peter Stuge pe...@stuge.se wrote: As a data point you could compare the userspace approach with libftdi1. Good idea! I've started working on that, though I can't seem to make it work at all yet. I'll keep beating on that. Meanwhile I noticed that with kernel 3.15.4 I am getting log messages when the ftdi_sio input gets stuck, which I didn't seem to get previously when I was using 3.14.4. Whenever it happens I get two messages: Jul 12 18:32:44 p1 kernel: ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32 Jul 12 18:32:44 p1 kernel: ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32 Any idea what can cause a urb stopped? Thanks! Eric -- 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: ftdi_sio input hang with FT230X at high baud rate, binary data
On Sat, Jul 12, 2014 at 6:37 PM, Eric Smith space...@gmail.com wrote: On Sat, Jul 12, 2014 at 5:33 PM, Peter Stuge pe...@stuge.se wrote: As a data point you could compare the userspace approach with libftdi1. Good idea! I've started working on that, though I can't seem to make it work at all yet. I'll keep beating on that. Giving up on libftdi1. It doesn't seem to work well at all, giving inconsistent and seemingly arbitrary errors: [eric@p1 libftdi1]$ sudo ./host unable to set baud rate: -2 (Setting new baudrate failed) [eric@p1 libftdi1]$ sudo ./host error reading FTDI: -8 (usb bulk read failed) [eric@p1 libftdi1]$ sudo ./host unable to open ftdi device: -6 (ftdi_usb_reset failed) [eric@p1 libftdi1]$ sudo ./host unable to open ftdi device: -6 (ftdi_usb_reset failed) [eric@p1 libftdi1]$ sudo ./host error reading FTDI: -7 (usb bulk read failed) [eric@p1 libftdi1]$ sudo ./host unable to set baud rate: -2 (Setting new baudrate failed) [eric@p1 libftdi1]$ sudo ./host unable to set baud rate: -2 (Setting new baudrate failed) [eric@p1 libftdi1]$ sudo ./host unable to open ftdi device: -6 (ftdi_usb_reset failed) [eric@p1 libftdi1]$ sudo ./host unable to open ftdi device: -6 (ftdi_usb_reset failed) [eric@p1 libftdi1]$ sudo ./host unable to open ftdi device: -6 (ftdi_usb_reset failed) [eric@p1 libftdi1]$ sudo ./host unable to open ftdi device: -6 (ftdi_usb_reset failed) [eric@p1 libftdi1]$ sudo ./host unable to set baud rate: -2 (Setting new baudrate failed) [eric@p1 libftdi1]$ sudo ./host error reading FTDI: -8 (usb bulk read failed) [eric@p1 libftdi1]$ sudo ./host error reading FTDI: -7 (usb bulk read failed) -- 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
