Re: [PATCH 2/4] usb: introduce usb force power off mechanism
On 2013年03月29日 22:11, Alan Stern wrote: On Fri, 29 Mar 2013, Lan Tianyu wrote: Actually, I exposed pm qos flags for usb port via dev_pm_qos_expose_flags(). It creates power/pm_qos_no_power_off under usb port sysfs directory. User can echo 0 pm_qos_no_power_off to power off the empty port. Before it's too late, we should consider changing the flag's name. Writing 0 to a file named pm_qos_no_power_off is a double negative, which is always awkward to think about. Instead, how about calling the file pm_qos_allow_power_off? Will the PM-QOS system allow something like that, i.e., something that is the opposite of a constraint? If not, how about naming it pm_qos_keep_power_on? This is PM core sysfs attribute and I am not sure that this can be changed. CC: Rafael. Alan Stern -- Best regards Tianyu Lan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] usb: introduce usb force power off mechanism
On 2013年03月30日 01:23, Alan Stern wrote: On Fri, 29 Mar 2013, Sarah Sharp wrote: However, what happens if you echo 0 to pm_qos_no_power_off, the power/control is set to auto, and there's a suspended USB device attached to the port with remote wakeup enabled? Will the port be powered off? I don't think it will with the current patchset, but I will have to double check. It shouldn't be, because remote wakeup is enabled. But what about the case where remote wakeup is disabled? Will writing a 0 to pm_qos_no_power_off cause the power to be turned off? Or what about the case where there's no device attached to the port? I guess both questions amount to the same thing: When the user writes to a pm_qos_* file, does the code call pm_runtime_idle? Usb port's initial usage count is 0. For port attached with usb port, when usb device is connected, the usb port's usage count is increased by one. During device's suspend, its usage count would be decreased to 0 and powered of only when remote wakeup disable, persist enable and PM Qos NO_POWER_OFF unsetting. During pm_qos_* file changing, pm_runtime_get_sync/put(port_dev) will be done in the dev_pm_qos_update_flags(). The port's usage count would be increased and decreased by 1. Whether the port's pm_runtime_idle would be called depends on port's usage count to be set to 0. If the usb port has already been powered off(port usage count is already set to 0), it would be powered on first and powered off depending the PM Qos NO_POWER_OFF flag value. If the usb port wasn't powered off, this mean the usb port didn't meet power off condition() and its usage count was still greater than 0 So during changing flag, only usage count was changed and no actual operation. For empty port, Only when PM Qos NO_POWER_OFF flag value is set to 0, the port will be power off. Alan Stern -- Best regards Tianyu Lan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] usb host: Faraday FUSBH200 HCD driver
FUSBH200 is an ehci-like controller with some differences.
First, register layout of FUSBH200 is incompatible with EHCI.
We use a quirk flag and modify struct ehci_regs with anonymous
union and struct to make sure driver of FUSBH200 and EHCI could
coexist. Furthermore, FUSBH200 is lack of siTDs which means iTDs
are used for both HS and FS ISO transfer.
Signed-off-by: Yuan-Hsin Chen yhc...@faraday-tech.com
---
Note that anonymous union and struct might not be supported
in earlier version of gcc
v2:
use ehci-platform.c
use anonymous union and struct
add is_fusbh200 to struct ehci_hcd
drivers/usb/host/Kconfig |9 ++
drivers/usb/host/ehci-fusbh200.c | 223 ++
drivers/usb/host/ehci-hcd.c | 18 +++-
drivers/usb/host/ehci-hub.c | 30 +++---
drivers/usb/host/ehci-mem.c |3 +-
drivers/usb/host/ehci-sched.c| 33 --
drivers/usb/host/ehci.h | 27 +-
include/linux/usb/ehci_def.h | 58 +++---
8 files changed, 351 insertions(+), 50 deletions(-)
create mode 100644 drivers/usb/host/ehci-fusbh200.c
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 3f1431d..42b8768 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -157,6 +157,15 @@ config USB_EHCI_HCD_OMAP
Enables support for the on-chip EHCI controller on
OMAP3 and later chips.
+config USB_EHCI_HCD_FUSBH200
+ bool Faraday FUSBH200 HCD support
+ depends on USB_EHCI_HCD ARCH_FARADAY
+ select USB_EHCI_ROOT_HUB_TT
+ default y
+ ---help---
+ The USB HCD Driver of Faraday FUSBH200 is designed to
+ meet USB2.0 EHCI specification with minor modification
+
config USB_EHCI_MSM
bool Support for MSM on-chip EHCI USB controller
depends on USB_EHCI_HCD ARCH_MSM
diff --git a/drivers/usb/host/ehci-fusbh200.c b/drivers/usb/host/ehci-fusbh200.c
new file mode 100644
index 000..1d5fd14
--- /dev/null
+++ b/drivers/usb/host/ehci-fusbh200.c
@@ -0,0 +1,223 @@
+/*
+ * ehci-fusbh200.c - driver for Faraday USB2.0 Host FUSBH200
+ *
+ * Copyright (c) 2013 Yuan-Hsin Chen yhchen@faraday-tech
+ * Copyright (c) 2013 Po-Yu Chuang ratbert.chu...@gmail.com
+ * Copyright (c) 2010-2012 Feng-Hsin Chiang john453@faraday-tech
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include linux/platform_device.h
+
+static const struct hc_driver ehci_fusbh200_hc_driver = {
+ .description= hcd_name,
+ .product_desc = Faraday USB2.0 Host Controller,
+ .hcd_priv_size = sizeof(struct ehci_hcd),
+
+ /*
+* generic hardware linkage
+*/
+ .irq= ehci_irq,
+ .flags = HCD_MEMORY | HCD_USB2,
+
+ /*
+* basic lifecycle operations
+*/
+ .reset = ehci_init,
+ .start = ehci_run,
+ .stop = ehci_stop,
+ .shutdown = ehci_shutdown,
+
+ /*
+* managing i/o requests and associated device resources
+*/
+ .urb_enqueue= ehci_urb_enqueue,
+ .urb_dequeue= ehci_urb_dequeue,
+ .endpoint_disable = ehci_endpoint_disable,
+ .endpoint_reset = ehci_endpoint_reset,
+
+ /*
+* scheduling support
+*/
+ .get_frame_number = ehci_get_frame,
+
+ /*
+* root hub support
+*/
+ .hub_status_data= ehci_hub_status_data,
+ .hub_control= ehci_hub_control,
+ .bus_suspend= ehci_bus_suspend,
+ .bus_resume = ehci_bus_resume,
+
+ .relinquish_port= ehci_relinquish_port,
+ .port_handed_over = ehci_port_handed_over,
+
+ .clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
+};
+
+void fusbh200_init(struct ehci_hcd *ehci)
+{
+ u32 reg;
+
+ reg = ehci_readl(ehci, ehci-regs-bmcsr);
+ reg |= BMCSR_INT_POLARITY;
+ reg = ~BMCSR_VBUS_OFF;
+ ehci_writel(ehci, reg, ehci-regs-bmcsr);
+
+ reg = ehci_readl(ehci, ehci-regs-bmier);
+ ehci_writel(ehci, reg | BMIER_OVC_EN | BMIER_VBUS_ERR_EN,
+ ehci-regs-bmier);
+}
+
+/**
+ * ehci_hcd_fusbh200_probe - initialize faraday
Re: [colord] [PATCH] xhci: Don't warn on empty ring for suspended devices.
On 21 March 2013 21:01, Stephen Hemminger step...@networkplumber.org wrote: I may go out on a limb and look at colord internals. Most likely it's not colord at all, but colord-sane. Old versions of color-sane did indeed poll libsane for scanners (libsane being a horrible, horrible API) but since the last half-dozen releases it's been rewritten to hopefully avoid polling like this. Richard. -- 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: EHCI: port power regression when canceling suspend-to-disk
Hi Alan, So either something more complicated is happening, or I messed up my bisection results. I'll retest the rev under suspicion and its parent and get back to you. Seems you were right: The revision I bisected to was not the culprit. It seems that there is some other factor involved that I'm not aware of, since all of the revisions I re-tested that were previously good, now tested as bad (including the 3.3 version I originally used as the base for my bisecting). In other words: bisecting seems useless, so I'll try to debug this as-is. Any suggestions on things to look at, perhaps? Gr. Matthijs -- 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: Driver for PL-2303 HX not working
Am 01.04.2013 01:10, schrieb Greg KH: On Sun, Mar 31, 2013 at 07:15:22PM +0200, Karsten Malcher wrote: Am 31.03.2013 18:58, schrieb Greg KH: On Sun, Mar 31, 2013 at 06:33:24PM +0200, Karsten Malcher wrote: Am 31.03.2013 17:50, schrieb Greg KH: On Sun, Mar 31, 2013 at 05:20:06PM +0200, Karsten Malcher wrote: Hello, I have a problem with the PL2303HX chip. Please refer to this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704242 Where can i address such a bug? How can i debug and help to solve the problem? Please provide the output of the kernel log when using this device on the 3.8 kernel release. thanks, greg k-h It seems that the driver is the same i am using in kernel 3.2.0-3. https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/usb/serial/pl2303.c?id=v3.8.5 So please don't be angry, but it's much effort of installing and compiling for the same result. The main problem is that there is no special output in the kernel messages with this PL-2303 HX chip. Exactly no message or error appears, the driver simply gives no data that arrives. Can you provide the output of 'lsusb -v' with the device plugged in? thanks, greg k-h Of course. First the overview over all devices: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 008: ID 058f:6254 Alcor Micro Corp. USB Hub Bus 003 Device 002: ID 04d9:1503 Holtek Semiconductor, Inc. Shortboard Lefty Bus 001 Device 009: ID 16c0:05dc VOTI shared ID for use with libusb Bus 001 Device 017: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Bus 001 Device 011: ID 058f:6366 Alcor Micro Corp. Multi Flash Reader The output of lsusb -v for the device: (Complete output attached as file) Bus 001 Device 017: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 Ok, this should be detected as a HX device by the driver. Can you do, as root, unplug the device and type: rmmod pl2303 dmesg -c modprobe pl2303 debug=1 plug the device in, and then send the output of 'dmesg' that gets sent? Results at the end of the mail. If still needed i can install Ubuntu on an free partition on another PC ? There is the possibility to upgrade to kernel 3.8.5. I really don't know why prolific decided to change their device, yet use the same device id, and not tell us how to talk to the device at all. I can't understand why a driver for Mac is provided and not for Linux. There are so much embedded systems running Linux needing a converter from RS232 to USB. The fact that this driver even works is pretty amazing at times... Yes - first i thought the hardware is broken. There is no error message and sometimes some bytes are received after connection. I checked the hardware on an PC running windows with the driver from Profilic - it works perfect. thanks, greg k-h Best regards Karsten Here the result for PL2303HX: [ 1626.798549] USB Serial support registered for pl2303 [ 1626.798620] usbcore: registered new interface driver pl2303 [ 1626.798625] pl2303: Prolific PL2303 USB to serial adaptor driver [ 1666.192803] usb 1-2.3: new full-speed USB device number 8 using ehci_hcd [ 1666.302378] usb 1-2.3: New USB device found, idVendor=067b, idProduct=2303 [ 1666.302389] usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 1666.302396] usb 1-2.3: Product: USB-Serial Controller [ 1666.302401] usb 1-2.3: Manufacturer: Prolific Technology Inc. [ 1666.302866] pl2303 1-2.3:1.0: pl2303 converter detected [ 1666.302881] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: device type: 2 [ 1666.303000] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xc0:0x1:0x8484:0x0 1 - 2 [ 1666.303121] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x40:0x1:0x404:0x0 0 [ 1666.303246] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xc0:0x1:0x8484:0x0 1 - 2 [ 1666.303371] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xc0:0x1:0x8383:0x0 1 - 0 [ 1666.303496] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xc0:0x1:0x8484:0x0 1 - 2 [ 1666.303620]
xHCI ShortPacket Correct Behaviour
With respect to latest xHCI spec : Revision 1.0 with errata to 8/14/12 Page 114: Note: Consider the case where there are multiple TDs posted for pipe for a single data transfer and a Short Packet or other condition on one TD means that the data transfer is terminated, and that the subsequent TDs associated with the data transfer are now invalid. The xHC may have read ahead on the Transfer Ring and cached the subsequent TDs. To ensure that xHC frees any cached information associated with a pipe in a timely manner (so that it can reuse the cache space for other pipes), software shall issue a Set TR Dequeue Pointer Command for the pipe when the data transfer is terminated, vs. waiting for the next data transfer to be ready before issuing the command. Note: If software issues a Set TR Dequeue Pointer Command that points to a TRB that had previously been partially completed TD, the xHC shall treat that TRB as the first TRB of the TD. i.e. any prior state associated with a partially completed TRB is lost. Looking at this description, I interpret that when the ShortPacket is received, xHC should stop executing the transfer and should wait for the driver for next command or doorbell. Page 130: Note: If the xHC receives a short packetShort Packet from a device, then it shall retire the current TD. If another TD is defined on the Transfer Ring, the xHC shall advance to it and begin IN transactions. Looking at this description, I interpret that when the ShortPacket is received, xHC should discard the current TD and start executing the next TD if available. Page 172: If a Short Packet is detected during the execution of a multi-TRB TD, the xHC shall advance to the first TRB of the next TD or the Enqueue Pointer (i.e.Cycle bit transition), whichever is encountered first. Looking at this description, I interpret that when the ShortPacket is received, xHC should discard the current TD and start executing the next TD if available. These descriptions are contradictory. Which is the correct xHCI behavior when ShortPacket is received? -Ankit -- 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 0/2] USB PM and PM QoS fixes (Re: gpf in pm_qos_remote_wakeup_show)
On Sunday, March 31, 2013 08:29:20 PM Linus Torvalds wrote: On Sun, Mar 31, 2013 at 3:56 PM, Rafael J. Wysocki r...@sisk.pl wrote: So, I have two patches (on top of the Linus' tree) that will follow shortly: Should I take these directly as patches, or expect them to show up in a pull soon (ie do you have or expect to have other things pending)? I'm going to send one more pull request with changes for 3.9 later this week and I'll include these two. Rafael -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux USB file storage gadget with new UDC
Hi,
Thanks. Working on this problem now. Another problem observed for
SCSI_READ_10 command, when reading from the SD card, the gadget driver
never sends the MBR address, the FAT boot record address, the start of FAT
address, and the start of FAT cluster address to the SD card driver.
The gadget doesn't make up addresses by itself. It always sends the
address the host tells it to send.
The
address sent by gadget driver is wrong.
Then the address sent by the host is wrong.
However, I suspect you are mistaken. In your usbmon trace earlier, the
very first READ(10) command had a logical block address of 0. That is
the address of the MBR. If the driver hadn't failed at that point, the
host would have gone on to ask for the address of the boot sector and
other things.
Yes, the very first READ(10) command has a logical block address of 0
(as shown below). I will generate the fresh usbmon trace the next
day, i do not have access to the platform now.
f59e13c0 3246885432 S Bo:2:046:1 -115 31 = 55534243 0c00 0010
8a28 0008 00
Here is the fresh usbmon trace. Four SCSI commands are shown. The
first SCSI_READ_10 command has LBA of 0. The second SCSI_READ_10
command has LBA of 0x00ed2900, which is wrong. Somehow, the first
SCSI_READ_10 command got the wrong data, i think. Isn't it?
f31a9740 4037054141 S Bo:2:071:1 -115 31 = 55534243 0c00 0010
8a28 0008 00
f31a9740 4037054176 C Bo:2:071:1 0 31
f4a555c0 4037054184 S Bi:2:071:1 -115 4096
f4a555c0 4037108430 C Bi:2:071:1 0 4096 = eb58904d 53444f53 352e3000
02402e11 0200 00f8 3f00ff00 0020
f31a9740 4037108476 S Bi:2:071:1 -115 13
f31a9740 4037114564 C Bi:2:071:1 0 13 = 55534253 0c00 00
f31a9740 4037114722 S Bo:2:071:1 -115 31 = 55534243 0d00
0600 00
f31a9740 4037114801 C Bo:2:071:1 0 31
f31a9740 4037114805 S Bi:2:071:1 -115 13
f31a9740 4037121303 C Bi:2:071:1 0 13 = 55534253 0d00 00
f31a9740 4037121388 S Bo:2:071:1 -115 31 = 55534243 0e00 0800
8a25 00
f31a9740 4037121550 C Bo:2:071:1 0 31
f4a552c0 4037121559 S Bi:2:071:1 -115 8
f4a552c0 4037127426 C Bi:2:071:1 0 8 = 00ed29c7 0200
f31a9740 4037127435 S Bi:2:071:1 -115 13
f31a9740 4037133064 C Bi:2:071:1 0 13 = 55534253 0e00 00
f31a9740 4037133100 S Bo:2:071:1 -115 31 = 55534243 0f00 0010
8a28 ed29 0008 00
f31a9740 4037133176 C Bo:2:071:1 0 31
f4a552c0 4037133184 S Bi:2:071:1 -115 4096
f4a552c0 4037184441 C Bi:2:071:1 0 4096 =
f31a9740 4037184453 S Bi:2:071:1 -115 13
f31a9740 4037190564 C Bi:2:071:1 0 13 = 55534253 0f00 00
Thanks,
victor
--
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 00/11] usb: dwc3/xhci/phy: Enable runtime power management
This patch-series enables runtime power management on xhci-plat, dwc3-core, dwc3-exynos as well as on Samsung's USB 2.0 type and USB 3.0 type PHYs. Based on 'next' branch of Felipe Balbi's USB tree. Changes from v2: - Using separate functions for USB PHY runtime power management, instead of using macros. - Adding 'pm_runtime_set_suspended()' api call in dwc3 core layer before enabling runtime pm. (Ideally, we should be explicitly make device 'suspended' or 'active' before enabling runtime pm on it). - Checking return code for 'put_sync' and 'get_sync' of USB-PHYs when waking up or suspending them from dwc3 core's runtime_pm callbacks. - Removed buggy pm_runtime_put() calls from driver's (xhci, dwc3 and PHY) remove functions. - Adding a patch to enable runtime power management of Samsung's USB 2.0 PHY (usb: phy: samsung: Enable runtime power management on usb2phy) Changes from v1: - Adding required PHY APIs to handle runtime power management instead of directly twiddling with phy-dev. - Handling runtime power management of usb PHYs in dwc3 core driver instead of in any glue layer. - Splitting the patch: [PATCH 4/4] usb: phy: samsung: Enable runtime power management on samsung-usb into required number to bifurcate functionality. Vivek Gautam (11): usb: phy: Add APIs for runtime power management USB: dwc3: Adjust runtime pm to allow autosuspend usb: dwc3: Enable runtime pm only after PHYs are initialized usb: dwc3: Add runtime power management callbacks usb: dwc3: exynos: Enable runtime power management usb: xhci: Enable runtime pm in xhci-plat usb: phy: samsung: Enable runtime power management on usb2phy usb: phy: samsung: Enable runtime power management on usb3phy usb: phy: samsung: Add support for external reference clock usb: phy: samsung: Add support for PHY ref_clk gpio usb: phy: samsung: Add support for PHY refclk switching drivers/usb/dwc3/core.c| 59 ++-- drivers/usb/dwc3/dwc3-exynos.c | 12 +++ drivers/usb/host/xhci-plat.c |6 ++ drivers/usb/phy/phy-samsung-usb.c | 26 +++ drivers/usb/phy/phy-samsung-usb.h |1 + drivers/usb/phy/phy-samsung-usb2.c |5 ++ drivers/usb/phy/phy-samsung-usb3.c | 119 +-- include/linux/usb/phy.h| 141 8 files changed, 358 insertions(+), 11 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 v3 06/11] usb: xhci: Enable runtime pm in xhci-plat
By enabling runtime pm in this driver allows users of xhci-plat to enter into runtime pm. This is not full runtime pm support (AKA xhci-plat doesn't actually power anything off when in runtime suspend mode) but, just basic enablement. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com CC: Doug Anderson diand...@chromium.org --- drivers/usb/host/xhci-plat.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c index df90fe5..b10573e 100644 --- a/drivers/usb/host/xhci-plat.c +++ b/drivers/usb/host/xhci-plat.c @@ -12,6 +12,7 @@ */ #include linux/platform_device.h +#include linux/pm_runtime.h #include linux/module.h #include linux/slab.h @@ -149,6 +150,9 @@ static int xhci_plat_probe(struct platform_device *pdev) if (ret) goto put_usb3_hcd; + pm_runtime_set_active(pdev-dev); + pm_runtime_enable(pdev-dev); + return 0; put_usb3_hcd: @@ -174,6 +178,8 @@ static int xhci_plat_remove(struct platform_device *dev) struct usb_hcd *hcd = platform_get_drvdata(dev); struct xhci_hcd *xhci = hcd_to_xhci(hcd); + pm_runtime_disable(dev-dev); + usb_remove_hcd(xhci-shared_hcd); usb_put_hcd(xhci-shared_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 07/11] usb: phy: samsung: Enable runtime power management on usb2phy
Enable autosuspending of Samsung usb2.0 PHY Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- drivers/usb/phy/phy-samsung-usb2.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/usb/phy/phy-samsung-usb2.c b/drivers/usb/phy/phy-samsung-usb2.c index 45ffe03..d378fe9 100644 --- a/drivers/usb/phy/phy-samsung-usb2.c +++ b/drivers/usb/phy/phy-samsung-usb2.c @@ -423,6 +423,9 @@ static int samsung_usb2phy_probe(struct platform_device *pdev) platform_set_drvdata(pdev, sphy); + pm_runtime_set_active(pdev-dev); + pm_runtime_enable(pdev-dev); + return usb_add_phy(sphy-phy, USB_PHY_TYPE_USB2); } @@ -432,6 +435,8 @@ static int samsung_usb2phy_remove(struct platform_device *pdev) usb_remove_phy(sphy-phy); + pm_runtime_disable(pdev-dev); + if (sphy-pmuregs) iounmap(sphy-pmuregs); if (sphy-sysreg) -- 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 09/11] usb: phy: samsung: Add support for external reference clock
The PHY controller can choose between ref_pad_clk (XusbXTI-external PLL),
or EXTREFCLK (XXTI-internal clock crystal) to generate the required clock.
Adding the provision for ref_pad_clk here.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/phy/phy-samsung-usb3.c | 46 +++
1 files changed, 40 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/phy/phy-samsung-usb3.c
b/drivers/usb/phy/phy-samsung-usb3.c
index a713585..8afef9d 100644
--- a/drivers/usb/phy/phy-samsung-usb3.c
+++ b/drivers/usb/phy/phy-samsung-usb3.c
@@ -33,7 +33,7 @@
/*
* Sets the phy clk as EXTREFCLK (XXTI) which is internal clock from clock
core.
*/
-static u32 samsung_usb3phy_set_refclk(struct samsung_usbphy *sphy)
+static u32 samsung_usb3phy_set_refclk_int(struct samsung_usbphy *sphy)
{
u32 reg;
u32 refclk;
@@ -66,7 +66,22 @@ static u32 samsung_usb3phy_set_refclk(struct samsung_usbphy
*sphy)
return reg;
}
-static int samsung_exynos5_usb3phy_enable(struct samsung_usbphy *sphy)
+/*
+ * Sets the phy clk as ref_pad_clk (XusbXTI) which is clock from external PLL.
+ */
+static u32 samsung_usb3phy_set_refclk_ext(void)
+{
+ u32 reg;
+
+ reg = PHYCLKRST_REFCLKSEL_PAD_REFCLK |
+ PHYCLKRST_FSEL_PAD_100MHZ |
+ PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF;
+
+ return reg;
+}
+
+static int samsung_exynos5_usb3phy_enable(struct samsung_usbphy *sphy,
+ bool use_ext_clk)
{
void __iomem *regs = sphy-regs;
u32 phyparam0;
@@ -81,7 +96,10 @@ static int samsung_exynos5_usb3phy_enable(struct
samsung_usbphy *sphy)
phyparam0 = readl(regs + EXYNOS5_DRD_PHYPARAM0);
/* Select PHY CLK source */
- phyparam0 = ~PHYPARAM0_REF_USE_PAD;
+ if (use_ext_clk)
+ phyparam0 |= PHYPARAM0_REF_USE_PAD;
+ else
+ phyparam0 = ~PHYPARAM0_REF_USE_PAD;
/* Set Loss-of-Signal Detector sensitivity */
phyparam0 = ~PHYPARAM0_REF_LOSLEVEL_MASK;
phyparam0 |= PHYPARAM0_REF_LOSLEVEL;
@@ -116,7 +134,10 @@ static int samsung_exynos5_usb3phy_enable(struct
samsung_usbphy *sphy)
/* UTMI Power Control */
writel(PHYUTMI_OTGDISABLE, regs + EXYNOS5_DRD_PHYUTMI);
- phyclkrst = samsung_usb3phy_set_refclk(sphy);
+ if (use_ext_clk)
+ phyclkrst = samsung_usb3phy_set_refclk_ext();
+ else
+ phyclkrst = samsung_usb3phy_set_refclk_int(sphy);
phyclkrst |= PHYCLKRST_PORTRESET |
/* Digital power supply in normal operating mode */
@@ -164,7 +185,7 @@ static void samsung_exynos5_usb3phy_disable(struct
samsung_usbphy *sphy)
writel(phytest, regs + EXYNOS5_DRD_PHYTEST);
}
-static int samsung_usb3phy_init(struct usb_phy *phy)
+static int samsung_exynos5_usb3phy_init(struct usb_phy *phy, bool use_ext_clk)
{
struct samsung_usbphy *sphy;
unsigned long flags;
@@ -188,7 +209,7 @@ static int samsung_usb3phy_init(struct usb_phy *phy)
samsung_usbphy_set_isolation(sphy, false);
/* Initialize usb phy registers */
- samsung_exynos5_usb3phy_enable(sphy);
+ samsung_exynos5_usb3phy_enable(sphy, use_ext_clk);
spin_unlock_irqrestore(sphy-lock, flags);
@@ -199,6 +220,19 @@ static int samsung_usb3phy_init(struct usb_phy *phy)
}
/*
+ * The function passed to the usb driver for phy initialization
+ */
+static int samsung_usb3phy_init(struct usb_phy *phy)
+{
+ /*
+* We start with using PHY refclk from external PLL,
+* once runtime suspend for the device is called this
+* will change to internal core clock
+*/
+ return samsung_exynos5_usb3phy_init(phy, true);
+}
+
+/*
* The function passed to the usb driver for phy shutdown
*/
static void samsung_usb3phy_shutdown(struct usb_phy *phy)
--
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 08/11] usb: phy: samsung: Enable runtime power management on usb3phy
Enable autosuspending of Samsung usb3.0 PHY Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- drivers/usb/phy/phy-samsung-usb3.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/usb/phy/phy-samsung-usb3.c b/drivers/usb/phy/phy-samsung-usb3.c index 54f6418..a713585 100644 --- a/drivers/usb/phy/phy-samsung-usb3.c +++ b/drivers/usb/phy/phy-samsung-usb3.c @@ -24,6 +24,7 @@ #include linux/err.h #include linux/io.h #include linux/of.h +#include linux/pm_runtime.h #include linux/usb/samsung_usb_phy.h #include linux/platform_data/samsung-usbphy.h @@ -287,6 +288,9 @@ static int samsung_usb3phy_probe(struct platform_device *pdev) platform_set_drvdata(pdev, sphy); + pm_runtime_set_active(pdev-dev); + pm_runtime_enable(pdev-dev); + return usb_add_phy(sphy-phy, USB_PHY_TYPE_USB3); } @@ -296,6 +300,8 @@ static int samsung_usb3phy_remove(struct platform_device *pdev) usb_remove_phy(sphy-phy); + pm_runtime_disable(pdev-dev); + if (sphy-pmuregs) iounmap(sphy-pmuregs); if (sphy-sysreg) -- 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 05/11] usb: dwc3: exynos: Enable runtime power management
Enabling runtime power management on dwc3-exynos
letting dwc3 controller to be autosuspended on exynos
platform when not in use.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/dwc3/dwc3-exynos.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index 1ea7bd8..1ae81a0 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -19,6 +19,7 @@
#include linux/platform_data/dwc3-exynos.h
#include linux/dma-mapping.h
#include linux/clk.h
+#include linux/pm_runtime.h
#include linux/usb/otg.h
#include linux/usb/nop-usb-xceiv.h
#include linux/of.h
@@ -138,6 +139,11 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
exynos-dev = dev;
exynos-clk = clk;
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+ pm_runtime_get_sync(dev);
+ pm_runtime_forbid(dev);
+
clk_prepare_enable(exynos-clk);
if (node) {
@@ -152,10 +158,14 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
goto err2;
}
+ pm_runtime_put_sync(dev);
+ pm_runtime_allow(dev);
+
return 0;
err2:
clk_disable_unprepare(clk);
+ pm_runtime_disable(dev);
err1:
return ret;
}
@@ -164,6 +174,8 @@ static int dwc3_exynos_remove(struct platform_device *pdev)
{
struct dwc3_exynos *exynos = platform_get_drvdata(pdev);
+ pm_runtime_disable(pdev-dev);
+
platform_device_unregister(exynos-usb2_phy);
platform_device_unregister(exynos-usb3_phy);
device_for_each_child(pdev-dev, NULL, dwc3_exynos_remove_child);
--
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 04/11] usb: dwc3: Add runtime power management callbacks
Right now it doesn't handle full runtime suspend/resume
functionality. However it allows to handle PHYs' sleep
and wakeup across runtime suspend/resume.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/usb/dwc3/core.c | 43 +++
1 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index e250828..65a3adf 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -745,11 +745,54 @@ static int dwc3_resume(struct device *dev)
return 0;
}
+#ifdef CONFIG_PM_RUNTIME
+static int dwc3_runtime_suspend(struct device *dev)
+{
+ struct dwc3 *dwc = dev_get_drvdata(dev);
+ int ret = 0;
+
+ ret = usb_phy_autopm_put_sync(dwc-usb2_phy);
+ if (ret)
+ dev_warn(dev, Can't autosuspend usb2-phy\n);
+
+ ret = usb_phy_autopm_put_sync(dwc-usb3_phy);
+ if (ret)
+ dev_warn(dev, Can't autosuspend usb3-phy\n);
+
+ return ret;
+}
+
+static int dwc3_runtime_resume(struct device *dev)
+{
+ struct dwc3 *dwc = dev_get_drvdata(dev);
+ int ret = 0;
+
+ ret = usb_phy_autopm_get_sync(dwc-usb2_phy);
+ if (ret) {
+ dev_err(dev, usb2-phy: get sync failed with err %d\n, ret);
+ return ret;
+ }
+
+ ret = usb_phy_autopm_get_sync(dwc-usb3_phy);
+ if (ret) {
+ dev_err(dev, usb3-phy: get sync failed with err %d\n, ret);
+ return ret;
+ }
+
+ return ret;
+}
+#else
+#define dwc3_runtime_suspend NULL
+#define dwc3_runtime_resumeNULL
+#endif
+
static const struct dev_pm_ops dwc3_dev_pm_ops = {
.prepare= dwc3_prepare,
.complete = dwc3_complete,
SET_SYSTEM_SLEEP_PM_OPS(dwc3_suspend, dwc3_resume)
+ SET_RUNTIME_PM_OPS(dwc3_runtime_suspend,
+ dwc3_runtime_resume, NULL)
};
#define DWC3_PM_OPS(dwc3_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
[PATCH v3 01/11] usb: phy: Add APIs for runtime power management
Adding APIs to handle runtime power management on PHY
devices. PHY consumers may need to wake-up/suspend PHYs
when they work across autosuspend.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
include/linux/usb/phy.h | 141 +++
1 files changed, 141 insertions(+), 0 deletions(-)
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 6b5978f..01bf9c1 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -297,4 +297,145 @@ static inline const char *usb_phy_type_string(enum
usb_phy_type type)
return UNKNOWN PHY TYPE;
}
}
+
+static inline void usb_phy_autopm_enable(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return;
+ }
+
+ pm_runtime_enable(x-dev);
+}
+
+static inline void usb_phy_autopm_disable(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return;
+ }
+
+ pm_runtime_disable(x-dev);
+}
+
+static inline int usb_phy_autopm_get(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return -ENODEV;
+ }
+
+ return pm_runtime_get(x-dev);
+}
+
+static inline int usb_phy_autopm_get_sync(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return -ENODEV;
+ }
+
+ return pm_runtime_get_sync(x-dev);
+}
+
+static inline int usb_phy_autopm_put(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return -ENODEV;
+ }
+
+ return pm_runtime_put(x-dev);
+}
+
+static inline int usb_phy_autopm_put_sync(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return -ENODEV;
+ }
+
+ return pm_runtime_put_sync(x-dev);
+}
+
+static inline void usb_phy_autopm_allow(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return;
+ }
+
+ pm_runtime_allow(x-dev);
+}
+
+static inline void usb_phy_autopm_forbid(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return;
+ }
+
+ pm_runtime_forbid(x-dev);
+}
+
+static inline int usb_phy_autopm_set_active(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return -ENODEV;
+ }
+
+ return pm_runtime_set_active(x-dev);
+}
+
+static inline void usb_phy_autopm_set_suspended(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return;
+ }
+
+ pm_runtime_set_suspended(x-dev);
+}
+
+static inline bool usb_phy_autopm_suspended(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return 0;
+ }
+
+ return pm_runtime_suspended(x-dev);
+}
+
+static inline bool usb_phy_autopm_active(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return 0;
+ }
+
+ return pm_runtime_active(x-dev);
+}
+
+static inline int usb_phy_autopm_suspend(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return -ENODEV;
+ }
+
+ return pm_runtime_suspend(x-dev);
+}
+
+static inline int usb_phy_autopm_resume(struct usb_phy *x)
+{
+ if (!x || !x-dev) {
+ dev_err(x-dev, no PHY or attached device available\n);
+ return -ENODEV;
+ }
+
+ return pm_runtime_resume(x-dev);
+}
+
#endif /* __LINUX_USB_PHY_H */
--
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 03/11] usb: dwc3: Enable runtime pm only after PHYs are initialized
Allow dwc3 to enable auto power management only after its PHYs are initialized so that any further PHY handling by dwc3's runtime power management callbacks is fine. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- drivers/usb/dwc3/core.c | 18 +- 1 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 3a6993c..e250828 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -491,15 +491,6 @@ static int dwc3_probe(struct platform_device *pdev) dwc-needs_fifo_resize = of_property_read_bool(node, tx-fifo-resize); - /* Setting device state as 'suspended' initially, -* to make sure we know device state prior to -* pm_runtime_enable -*/ - pm_runtime_set_suspended(dev); - pm_runtime_enable(dev); - pm_runtime_get_sync(dev); - pm_runtime_forbid(dev); - dwc3_cache_hwparams(dwc); ret = dwc3_alloc_event_buffers(dwc, DWC3_EVENT_BUFFERS_SIZE); @@ -521,6 +512,15 @@ static int dwc3_probe(struct platform_device *pdev) goto err1; } + /* Setting device state as 'suspended' initially, +* to make sure we know device state prior to +* pm_runtime_enable +*/ + pm_runtime_set_suspended(dev); + pm_runtime_enable(dev); + pm_runtime_get_sync(dev); + pm_runtime_forbid(dev); + if (IS_ENABLED(CONFIG_USB_DWC3_HOST)) mode = DWC3_MODE_HOST; else if (IS_ENABLED(CONFIG_USB_DWC3_GADGET)) -- 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 02/11] USB: dwc3: Adjust runtime pm to allow autosuspend
The current code in the dwc3 probe effectively disables runtime pm from ever working because it calls a get() that was never put() until device removal. Change the runtime pm code to match the standard formula and allow runtime pm to function. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com CC: Doug Anderson diand...@chromium.org --- drivers/usb/dwc3/core.c |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index e2325ad..3a6993c 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -491,6 +491,11 @@ static int dwc3_probe(struct platform_device *pdev) dwc-needs_fifo_resize = of_property_read_bool(node, tx-fifo-resize); + /* Setting device state as 'suspended' initially, +* to make sure we know device state prior to +* pm_runtime_enable +*/ + pm_runtime_set_suspended(dev); pm_runtime_enable(dev); pm_runtime_get_sync(dev); pm_runtime_forbid(dev); @@ -566,6 +571,7 @@ static int dwc3_probe(struct platform_device *pdev) goto err3; } + pm_runtime_put_sync(dev); pm_runtime_allow(dev); return 0; @@ -595,6 +601,7 @@ err1: err0: dwc3_free_event_buffers(dwc); + pm_runtime_disable(pdev-dev); return ret; } @@ -606,7 +613,6 @@ static int dwc3_remove(struct platform_device *pdev) usb_phy_set_suspend(dwc-usb2_phy, 1); usb_phy_set_suspend(dwc-usb3_phy, 1); - pm_runtime_put(pdev-dev); pm_runtime_disable(pdev-dev); dwc3_debugfs_exit(dwc); -- 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] drivers/usb/core: processing failure, maching resume condition with suspend condition
On Mon, 1 Apr 2013, Chen Gang wrote:
when suspend, it need check 'udev-actconfig'.
so when process failure, also need check it.
Signed-off-by: Chen Gang gang.c...@asianux.com
---
drivers/usb/core/driver.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
index eb1d00a..1a50003 100644
--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -1253,10 +1253,12 @@ static int usb_suspend_both(struct usb_device *udev,
pm_message_t msg)
/* If the suspend failed, resume interfaces that did get suspended */
if (status != 0) {
- msg.event ^= (PM_EVENT_SUSPEND | PM_EVENT_RESUME);
- while (++i n) {
- intf = udev-actconfig-interface[i];
- usb_resume_interface(udev, intf, msg, 0);
+ if (udev-actconfig) {
+ msg.event ^= (PM_EVENT_SUSPEND | PM_EVENT_RESUME);
+ while (++i n) {
+ intf = udev-actconfig-interface[i];
+ usb_resume_interface(udev, intf, msg, 0);
+ }
}
/* If the suspend succeeded then prevent any more URB submissions
Thanks for spotting this.
Acked-by: Alan Stern st...@rowland.harvard.edu
--
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: Linux USB file storage gadget with new UDC
On Mon, 1 Apr 2013, victor yeo wrote: Here is the fresh usbmon trace. Four SCSI commands are shown. The first SCSI_READ_10 command has LBA of 0. The second SCSI_READ_10 command has LBA of 0x00ed2900, which is wrong. Somehow, the first SCSI_READ_10 command got the wrong data, i think. Isn't it? It looks like the data is wrong, but I have no way of knowing what the data actually should be. Only you know that. f31a9740 4037054141 S Bo:2:071:1 -115 31 = 55534243 0c00 0010 8a28 0008 00 f31a9740 4037054176 C Bo:2:071:1 0 31 f4a555c0 4037054184 S Bi:2:071:1 -115 4096 f4a555c0 4037108430 C Bi:2:071:1 0 4096 = eb58904d 53444f53 352e3000 02402e11 0200 00f8 3f00ff00 0020 Is this different from what you have in the first 32 bytes of your backing file? If it is then your UDC driver is not sending the correct buffer data to the host. 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: EHCI: port power regression when canceling suspend-to-disk
On Mon, 1 Apr 2013, Matthijs Kooijman wrote: Hi Alan, So either something more complicated is happening, or I messed up my bisection results. I'll retest the rev under suspicion and its parent and get back to you. Seems you were right: The revision I bisected to was not the culprit. I have a healthy distrust for bisection results. More often than one would think, people end up at the wrong place. It seems that there is some other factor involved that I'm not aware of, since all of the revisions I re-tested that were previously good, now tested as bad (including the 3.3 version I originally used as the base for my bisecting). In other words: bisecting seems useless, so I'll try to debug this as-is. Any suggestions on things to look at, perhaps? What happens if you unplug all your USB devices from the docking station, so that its hub gets runtime suspended? Does it still disconnect? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] usb: introduce usb force power off mechanism
On Mon, 1 Apr 2013, Lan Tianyu wrote: On 2013年03月30日 01:23, Alan Stern wrote: On Fri, 29 Mar 2013, Sarah Sharp wrote: However, what happens if you echo 0 to pm_qos_no_power_off, the power/control is set to auto, and there's a suspended USB device attached to the port with remote wakeup enabled? Will the port be powered off? I don't think it will with the current patchset, but I will have to double check. It shouldn't be, because remote wakeup is enabled. But what about the case where remote wakeup is disabled? Will writing a 0 to pm_qos_no_power_off cause the power to be turned off? Or what about the case where there's no device attached to the port? I guess both questions amount to the same thing: When the user writes to a pm_qos_* file, does the code call pm_runtime_idle? Usb port's initial usage count is 0. For port attached with usb port, when usb device is connected, the usb port's usage count is increased by one. During device's suspend, its usage count would be decreased to 0 and powered of only when remote wakeup disable, persist enable and PM Qos NO_POWER_OFF unsetting. I already know all this. During pm_qos_* file changing, pm_runtime_get_sync/put(port_dev) will be done in the dev_pm_qos_update_flags(). The port's usage count would be increased and decreased by 1. Whether the port's pm_runtime_idle would be called depends on port's usage count to be set to 0. That answers my question. If the usb port has already been powered off(port usage count is already set to 0), it would be powered on first and powered off depending the PM Qos NO_POWER_OFF flag value. Obviously. If the usb port wasn't powered off, this mean the usb port didn't meet power off condition() and its usage count was still greater than 0 So during changing flag, only usage count was changed and no actual operation. No, because one of the power off conditions is that the NO_POWER_OFF flag must be clear. If that flag was set, the port won't be powered off even though the usage count is equal to 0. If the write to the pm_qos_* file then clears the flag, the port _will_ get powered off. For empty port, Only when PM Qos NO_POWER_OFF flag value is set to 0, the port will be power off. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/7] USB: EHCI: make ehci-spear a separate driver
On Sun, 31 Mar 2013, Arnd Bergmann wrote: On Saturday 30 March 2013, Arnd Bergmann wrote: In V3: -Detailed commit message added here about why this patch is required. -Eliminated ehci_spear_setup routine beacuse hcd registers directly setting in spear_ehci_hcd_drv_probe function. Fix the grammar, please. Done. I agree some of this is hardly legible. I realized later that the other patches have similarly screwed up changelogs. I'll send a new version once you've commented on v4, so in case there is anything else I missed I'm not spamming everyone another time. I still haven't checked the details of the last patch in the series (the OHCI changes). However, for patches 1/6 - 5/6: Acked-by: Alan Stern st...@rowland.harvard.edu -- 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 7/7] USB: OHCI: avoid conflicting platform drivers
On Sat, 30 Mar 2013, Arnd Bergmann wrote: I guess this means the onus is now on me to split up ohci-hcd into a central library and separate bus drivers, like ehci-hcd... The original plan in my teams was that Manjunath would do that after he was done with the simple conversion of the EHCI drivers. I think we can all agree now that it's better if you at least the groundwork instead. Yes, it would be better for me to prepare for the general split-up. Please let us know if you would like Manjunath to continue with splitting out the OHCI back-ends into separate drivers, or if you think that there is no point given the quality of the earlier patches. This is how people learn. After I have taken care of the initial steps and converted a couple of the drivers, Manjunath can work on the rest. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dummy-irq: introduce a dummy IRQ handler driver (was Re: gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-r
On Sun, Mar 31, 2013 at 9:55 PM, Jiri Kosina jkos...@suse.cz wrote: On Thu, 21 Mar 2013, Daniel Vetter wrote: Indeed, this is pretty useful and allowed me to quickly reproduce that phantom irq on my gm45. Thanks to module reloading we can even reset the kernel's irq disabling logic and so test different tricks quickly without rebooting. Really useful. Daniel, out of curiosity, have you been able to make some sense of the phantom legacy IRQs on GM45 systems, or are we just staying with my original bandaid (disabling GMBUS IRQs), declaring GM45 broken in this respect? I've played around with dummy-irq on my own gm45 and afaict every gmbus interrupt generates both an msi and a legacy pci interrupt when msi is enabled. Everything else (= other interrupt sources) seems to work as expected, and disabling msi also papers over the issue. There's also scary comments in our gm45 irq handler that we need msi to paper over some other races. So I've decided that I don't want to dwell any longer in this particular dungeon and that your bandaid (of just disabling this mess) is the real fix. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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: Driver for PL-2303 HX not working
On Mon, Apr 01, 2013 at 11:42:30AM +0200, Karsten Malcher wrote: Am 01.04.2013 01:10, schrieb Greg KH: On Sun, Mar 31, 2013 at 07:15:22PM +0200, Karsten Malcher wrote: Am 31.03.2013 18:58, schrieb Greg KH: On Sun, Mar 31, 2013 at 06:33:24PM +0200, Karsten Malcher wrote: Am 31.03.2013 17:50, schrieb Greg KH: On Sun, Mar 31, 2013 at 05:20:06PM +0200, Karsten Malcher wrote: Hello, I have a problem with the PL2303HX chip. Please refer to this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704242 Where can i address such a bug? How can i debug and help to solve the problem? Please provide the output of the kernel log when using this device on the 3.8 kernel release. thanks, greg k-h It seems that the driver is the same i am using in kernel 3.2.0-3. https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/usb/serial/pl2303.c?id=v3.8.5 So please don't be angry, but it's much effort of installing and compiling for the same result. The main problem is that there is no special output in the kernel messages with this PL-2303 HX chip. Exactly no message or error appears, the driver simply gives no data that arrives. Can you provide the output of 'lsusb -v' with the device plugged in? thanks, greg k-h Of course. First the overview over all devices: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 008: ID 058f:6254 Alcor Micro Corp. USB Hub Bus 003 Device 002: ID 04d9:1503 Holtek Semiconductor, Inc. Shortboard Lefty Bus 001 Device 009: ID 16c0:05dc VOTI shared ID for use with libusb Bus 001 Device 017: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Bus 001 Device 011: ID 058f:6366 Alcor Micro Corp. Multi Flash Reader The output of lsusb -v for the device: (Complete output attached as file) Bus 001 Device 017: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 Ok, this should be detected as a HX device by the driver. Can you do, as root, unplug the device and type: rmmod pl2303 dmesg -c modprobe pl2303 debug=1 plug the device in, and then send the output of 'dmesg' that gets sent? Results at the end of the mail. Thanks, that works. If still needed i can install Ubuntu on an free partition on another PC ? There is the possibility to upgrade to kernel 3.8.5. No need, this is due to this being a different type of device, the HX version. I really don't know why prolific decided to change their device, yet use the same device id, and not tell us how to talk to the device at all. I can't understand why a driver for Mac is provided and not for Linux. They (Prolific) relies on the in-kernel driver for Linux, which is fine, but they have never given us the specs to ensure we are doing the right thing, so it's not really fair. There are so much embedded systems running Linux needing a converter from RS232 to USB. Agreed. The fact that this driver even works is pretty amazing at times... Yes - first i thought the hardware is broken. There is no error message and sometimes some bytes are received after connection. I checked the hardware on an PC running windows with the driver from Profilic - it works perfect. thanks, greg k-h Best regards Karsten Here the result for PL2303HX: [ 1626.798549] USB Serial support registered for pl2303 [ 1626.798620] usbcore: registered new interface driver pl2303 [ 1626.798625] pl2303: Prolific PL2303 USB to serial adaptor driver [ 1666.192803] usb 1-2.3: new full-speed USB device number 8 using ehci_hcd [ 1666.302378] usb 1-2.3: New USB device found, idVendor=067b, idProduct=2303 [ 1666.302389] usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 1666.302396] usb 1-2.3: Product: USB-Serial Controller [ 1666.302401] usb 1-2.3: Manufacturer: Prolific Technology Inc. [ 1666.302866] pl2303 1-2.3:1.0: pl2303 converter detected [ 1666.302881] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: device type: 2 That's a crazy build system line :) Anyway, yes, the deviec is detected properly. [ 1666.303000] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xc0:0x1:0x8484:0x0 1 - 2 [ 1666.303121]
Re: Driver for PL-2303 HX not working
Am 01.04.2013 21:12, schrieb Greg KH: On Mon, Apr 01, 2013 at 11:42:30AM +0200, Karsten Malcher wrote: Am 01.04.2013 01:10, schrieb Greg KH: On Sun, Mar 31, 2013 at 07:15:22PM +0200, Karsten Malcher wrote: Am 31.03.2013 18:58, schrieb Greg KH: On Sun, Mar 31, 2013 at 06:33:24PM +0200, Karsten Malcher wrote: Am 31.03.2013 17:50, schrieb Greg KH: On Sun, Mar 31, 2013 at 05:20:06PM +0200, Karsten Malcher wrote: Hello, I have a problem with the PL2303HX chip. Please refer to this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704242 Where can i address such a bug? How can i debug and help to solve the problem? Please provide the output of the kernel log when using this device on the 3.8 kernel release. thanks, greg k-h It seems that the driver is the same i am using in kernel 3.2.0-3. https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/usb/serial/pl2303.c?id=v3.8.5 So please don't be angry, but it's much effort of installing and compiling for the same result. The main problem is that there is no special output in the kernel messages with this PL-2303 HX chip. Exactly no message or error appears, the driver simply gives no data that arrives. Can you provide the output of 'lsusb -v' with the device plugged in? thanks, greg k-h Of course. First the overview over all devices: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 008: ID 058f:6254 Alcor Micro Corp. USB Hub Bus 003 Device 002: ID 04d9:1503 Holtek Semiconductor, Inc. Shortboard Lefty Bus 001 Device 009: ID 16c0:05dc VOTI shared ID for use with libusb Bus 001 Device 017: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Bus 001 Device 011: ID 058f:6366 Alcor Micro Corp. Multi Flash Reader The output of lsusb -v for the device: (Complete output attached as file) Bus 001 Device 017: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 Ok, this should be detected as a HX device by the driver. Can you do, as root, unplug the device and type: rmmod pl2303 dmesg -c modprobe pl2303 debug=1 plug the device in, and then send the output of 'dmesg' that gets sent? Results at the end of the mail. Thanks, that works. If still needed i can install Ubuntu on an free partition on another PC ? There is the possibility to upgrade to kernel 3.8.5. No need, this is due to this being a different type of device, the HX version. I really don't know why prolific decided to change their device, yet use the same device id, and not tell us how to talk to the device at all. I can't understand why a driver for Mac is provided and not for Linux. They (Prolific) relies on the in-kernel driver for Linux, which is fine, but they have never given us the specs to ensure we are doing the right thing, so it's not really fair. There are so much embedded systems running Linux needing a converter from RS232 to USB. Agreed. The fact that this driver even works is pretty amazing at times... Yes - first i thought the hardware is broken. There is no error message and sometimes some bytes are received after connection. I checked the hardware on an PC running windows with the driver from Profilic - it works perfect. thanks, greg k-h Best regards Karsten Here the result for PL2303HX: [ 1626.798549] USB Serial support registered for pl2303 [ 1626.798620] usbcore: registered new interface driver pl2303 [ 1626.798625] pl2303: Prolific PL2303 USB to serial adaptor driver [ 1666.192803] usb 1-2.3: new full-speed USB device number 8 using ehci_hcd [ 1666.302378] usb 1-2.3: New USB device found, idVendor=067b, idProduct=2303 [ 1666.302389] usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 1666.302396] usb 1-2.3: Product: USB-Serial Controller [ 1666.302401] usb 1-2.3: Manufacturer: Prolific Technology Inc. [ 1666.302866] pl2303 1-2.3:1.0: pl2303 converter detected [ 1666.302881] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: device type: 2 That's a crazy build system line :) Yes. But the source seems not to be touched by Debian (attached). Anyway, yes, the deviec is detected properly. Yes. Everything looks normal, but received data is lost in hyperspace. :) [ 1666.303000] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c:
RE: cdc_acm device - unexpected characters sent to USB device
Hi, Oliver -Original Message- From: Oliver Neukum [mailto:oli...@neukum.org] Sent: Saturday, March 30, 2013 10:34 AM To: Mike Verstegen Cc: linux-usb@vger.kernel.org Subject: Re: cdc_acm device - unexpected characters sent to USB device On Saturday 30 March 2013 03:20:15 Mike Verstegen wrote: - Downloaded the source code for the cdc_acm driver. - Added a bunch of printk debug messages and stack_dumps to follow what's going on. - I rmmod'd the stock cdc_acm and insmod'd my instrumented module. - All the device enumeration works, right driver attached, etc. - Since the code works on Ubuntu 12.04/Linux 3.2, I grabbed the 3.2 cdc_acm code and compiled that module on the Centos 6 / Linux 3.6 platform. Using that 3.2 module instead of the 3.6 module did not make a difference. I reverted to the 3.6 module. - Turned on the debug file system with usbmon and watched the USB traffic. I can see that there are extra characters being sent on the USB interface. - To watch what's going on, on top of the printk's in the cdc_acm module, I've merged the output of usb mon (cat /sys/kernel/debug/usb/usbmon/3u | logger) and the output of the test application (scan_example /dev/ttyACM0 | logger -s) so I have a single stream of time correlated debug trail. - The spurious characters sent on the USB endpoint are x5E x40 x5E x40 x5E x40 x5E x40 x41 (in ASCII its ^@^@^@^@A ) which looks like some sort of probing or trying to get the attention of a modem These characters are sent immediately after the application's write() causes the 4 hello bytes to be sent to the end point. To clarify, is acm_tty_write() called with the additional bytes or isn't it? Regards Oliver Hi, Oliver Such a simple question you asked -- but it lead to a useful discovery. My logs show that acm_tty_write is called multiple times - The application opens the device and then calls write() to send the 4 byte message to the fd. This results in a call to acm_tty_write - From somewhere else, acm_tty_write is called several times, each with a count=1 and one of the offending characters noted above. To get find out where the unexpected calls to acm_tty_write were coming from, I added a dump_stack at the entry point to acm_tty_write. From those stack frames, I can see that the first acm_tty_write call is from my application, but the second and subsequent calls are from a kworker thread. So at this point, it doesn't look like a cdc_acm driver problem, but instead an unexpected call to acm_tty_write from another process. Having briefly looked the trace output of the kworker queue, it may a challenge to find out what thread in there is making this call. Thanks Mike-- 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 6/7] USB: EHCI: make ehci-msm a separate driver
Arnd Bergmann a...@arndb.de writes: On Friday 29 March 2013, Alan Stern wrote: On Thu, 28 Mar 2013, Arnd Bergmann wrote: This patch is good. However the ehci-msm driver itself is not. While checking through the code, I was struck by the fact that it never calls usb_add_hcd() or usb_remove_hcd(). Obviously the driver cannot work properly. In addition, it stores the PHY pointer in a global variable. (ehci-atmel does much the same thing for its clocks.) This means the driver cannot be used on a system having more than one EHCI controller. Maybe this doesn't matter, though. Maybe somebody would like to fix and test it... I'm not too surprised. The driver was added the last time that the MSM maintainers started a serious attempt to get a lot of their code mainlined, a little over two years ago. While there is some activity from Qualcomm in specific areas of the code every now and then, they literally have thousands of patches on top of the kernel that they use in actual products and I would not expect a mainline kernel to actually work on any recent Qualcomm hardware. As far as this patch goes, you can have an Acked-by: David Brown dav...@codeaurora.org for it. I'm hoping things are going to get better as far as people working on things. EHCI is definitely an important one to get working (as is SD), but we've got to get clocks and regulators working first. David -- sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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 v4 1/6] drivers: phy: add generic PHY framework
On 03/28/2013 06:43 AM, Kishon Vijay Abraham I wrote:
diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt
b/Documentation/devicetree/bindings/phy/phy-bindings.txt
new file mode 100644
index 000..35696b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
@@ -0,0 +1,76 @@
+This document explains only the dt data binding. For general information about
+PHY subsystem refer Documentation/phy.txt
+
+PHY device node
+===
+
+Optional Properties:
+#phy-cells:Number of cells in a PHY specifier; The meaning of all those
+ cells is defined by the binding for the phy node. However
+ in-order to return the correct PHY, the PHY susbsystem
+ requires the first cell always refers to the port.
+
+This property is optional because it is needed only for the case where a
+single IP implements multiple PHYs.
+
+For example:
+
+phys: phy {
+compatible = xxx;
+reg1 =...;
+reg2 =...;
+reg3 =...;
+.
+.
+#phy-cells =1;
+.
+.
+};
+
+That node describes an IP block that implements 3 different PHYs. In order to
+differentiate between these 3 PHYs, an additonal specifier should be given
+while trying to get a reference to it. (The PHY subsystem assumes the
+specifier is port id).
+
+PHY user node
+=
+
+Required Properties:
+phys : the phandle for the PHY device (used by the PHY subsystem)
+
+Optional properties:
+phy-names : the names of the PHY corresponding to the PHYs present in the
+ *phys* phandle
+
+example1:
+phys: phy {
+compatible = xxx;
+reg =...;
+.
+.
+phys =usb2_phy,usb3_phy;
+phy-names = usb2phy, usb3phy;
+.
+.
+};
+This node represents a controller that uses two PHYs one for usb2 and one for
+usb3. The controller driver can get the appropriate PHY either by using
+devm_of_phy_get/of_phy_get by passing the correct index or by using
+of_phy_get_byname/devm_of_phy_get_byname by passing the names given in
+*phy-names*.
+
+example2:
+phys: phy {
+compatible = xxx;
+reg =...;
+.
+.
+phys =phys 1;
+.
+.
+};
+
+This node represents a controller that uses one of the PHYs which is defined
+previously. Note that the phy handle has an additional specifier 1 to
+differentiate between the three PHYs. For this case, the controller driver
+should use of_phy_get_with_args/devm_of_phy_get_with_args.
This means a PHY user needs to know indexes at the PHY driver ?
I have been thinking of using this for an IP which has 4 video PHYs: 2 MIPI
CSI-2 and 2 MIPI DSI. The IP has just 2 registers, each of which is shared
between one MIPI CSI-2 DPHY and one MIPI DSI DPHY. So I thought about
creating
a single device node for this IP and using 4 indexes for the PHYs, e.g.
0...3.
Then users of each PHY type would use only indexes 0..1 (to select their
corresponding port).
However I fail to see how this could now be represented in the bindings.
I assume struct phy::type could be used to differentiate between CSI-2
and DSI.
And struct phy::port could be used to select specific CSI-2 or DSI channel
(0, 1). Ideally the phy users should not care about index of a PHY at
the PHY
device tree node. E.g. there are 2 MIPI CSI-2 receivers and each has only
one PHY assigned to it. I'm just wondering how the binding should look like,
so a PHY could be associated with a receiver automatically by the phy-core,
e.g.
/* DPHY IP node */
video-phy {
reg = 0x1000 8;
};
/* MIPI DSI nodes */
dsi_0 {
phys = video-phy 0;
};
dsi_1 {
phys = video-phy 1;
};
/* MIPI CSI-2 nodes */
csi_0 {
phys = video-phy 2;
};
csi_1 {
phys = video-phy 3;
};
I'm not sure if it is not an overkill to use this the PHY framework with
a device which has only 2 registers. Perhaps something less heavy could
be designed for it. However, if the PHY framework is commonly used there
should be no issue wrt enabling the whole big infrastructure for a simple
device like this.
Thanks,
Sylwester
--
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 v4 1/6] drivers: phy: add generic PHY framework
On 04/01/2013 04:27 PM, Sylwester Nawrocki wrote:
On 03/28/2013 06:43 AM, Kishon Vijay Abraham I wrote:
diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt
+example2:
+phys: phy {
+compatible = xxx;
+reg =...;
+.
+.
+phys =phys 1;
+.
+.
+};
+
+This node represents a controller that uses one of the PHYs which is defined
+previously. Note that the phy handle has an additional specifier 1 to
+differentiate between the three PHYs. For this case, the controller driver
+should use of_phy_get_with_args/devm_of_phy_get_with_args.
This means a PHY user needs to know indexes at the PHY driver ?
The client node's DT has to specify which of the provider's PHYs it
references, yes. Presumably the device driver for the client node knows
absolutely nothing about this.
I have been thinking of using this for an IP which has 4 video PHYs: 2 MIPI
CSI-2 and 2 MIPI DSI. The IP has just 2 registers, each of which is shared
between one MIPI CSI-2 DPHY and one MIPI DSI DPHY. So I thought about creating
a single device node for this IP and using 4 indexes for the PHYs, e.g. 0...3.
That sounds right.
Then users of each PHY type would use only indexes 0..1 (to select their
corresponding port).
I don't follow that. If the provider exports PHYs 0..3, then the client
nodes would refer to PHYS 0..3 not 0..1.
However I fail to see how this could now be represented in the bindings.
Exactly like the example you gave below, I would expect.
I assume struct phy::type could be used to differentiate between CSI-2 and
DSI.
And struct phy::port could be used to select specific CSI-2 or DSI channel
(0, 1). Ideally the phy users should not care about index of a PHY at the PHY
device tree node. E.g. there are 2 MIPI CSI-2 receivers and each has only
one PHY assigned to it. I'm just wondering how the binding should look like,
so a PHY could be associated with a receiver automatically by the phy-core,
e.g.
Details such as phy::type and phy::port sounds like internal driver
implementation details which would have no effect on the bindings.
/* DPHY IP node */
video-phy {
reg = 0x1000 8;
};
/* MIPI DSI nodes */
dsi_0 {
phys = video-phy 0;
};
dsi_1 {
phys = video-phy 1;
};
/* MIPI CSI-2 nodes */
csi_0 {
phys = video-phy 2;
};
csi_1 {
phys = video-phy 3;
};
That looks correct to me.
I'm not sure if it is not an overkill to use this the PHY framework with
a device which has only 2 registers. Perhaps something less heavy could
be designed for it. However, if the PHY framework is commonly used there
should be no issue wrt enabling the whole big infrastructure for a simple
device like this.
I don't think the number of registers should really makes any
difference; the whole point of the PHY framework is to decouple to
providers and consumers, so doing anything custom for special cases
would completely destroy the ability of the PHY framework to do that.
--
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] drivers/usb/core: processing failure, maching resume condition with suspend condition
On 2013年04月01日 22:58, Alan Stern wrote: Thanks for spotting this. Acked-by: Alan Stern st...@rowland.harvard.edu thank you too. -- Chen Gang Asianux Corporation -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] HID: ignore appledisplay devices
The usb/misc/appledisplay driver doesn't use the HID layer, so its devices
should be blacklisted in HID. With this patch, supported Apple displays are
automatically recognized as backlight devices.
Signed-off-by: Ben Jencks b...@bjencks.net
---
Sorry for the resend to linux-usb; this should have gone to linux-input in
the first place.
drivers/hid/hid-core.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index ceb3040..26b6158 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1951,6 +1951,11 @@ static const struct hid_device_id hid_ignore_list[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_24) },
{ HID_USB_DEVICE(USB_VENDOR_ID_AIRCABLE, USB_DEVICE_ID_AIRCABLE1) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ALCOR, USB_DEVICE_ID_ALCOR_USBRS232) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 0x9218) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 0x9219) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 0x921c) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 0x921d) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, 0x9236) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK, USB_DEVICE_ID_ASUSTEK_LCM)},
{ HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK, USB_DEVICE_ID_ASUSTEK_LCM2)},
{ HID_USB_DEVICE(USB_VENDOR_ID_AVERMEDIA, USB_DEVICE_ID_AVER_FM_MR800)
},
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] usb/misc/appledisplay: Add 24 LED Cinema display
Add the Apple 24 LED Cinema display to the supported devices.
Signed-off-by: Ben Jencks b...@bjencks.net
---
drivers/usb/misc/appledisplay.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/misc/appledisplay.c b/drivers/usb/misc/appledisplay.c
index 0fc6e5f..ba6a5d6 100644
--- a/drivers/usb/misc/appledisplay.c
+++ b/drivers/usb/misc/appledisplay.c
@@ -63,6 +63,7 @@ static const struct usb_device_id appledisplay_table[] = {
{ APPLEDISPLAY_DEVICE(0x9219) },
{ APPLEDISPLAY_DEVICE(0x921c) },
{ APPLEDISPLAY_DEVICE(0x921d) },
+ { APPLEDISPLAY_DEVICE(0x9236) },
/* Terminating entry */
{ }
--
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
