Re: Ehci-hcd kernel driver and ALi chipset doesn't work.
Ok, i'm testing with power cord plugged, this cable capture power from ps/2 port to give it to the cardbus, but i have the same problem. Here is the error in dmesg (i have turned off the verbose debug of usb module) usb 7-3: new high speed USB device using ehci_hcd and address 2 usb 7-3: device descriptor read/64, error -71 usb 7-3: device descriptor read/64, error -71 usb 7-3: new high speed USB device using ehci_hcd and address 3 usb 7-3: device descriptor read/64, error -32 usb 7-3: device descriptor read/all, error -71 usb 7-3: new high speed USB device using ehci_hcd and address 4 usb 7-3: device descriptor read/8, error -71 usb 7-3: device descriptor read/8, error -71 usb 7-3: new high speed USB device using ehci_hcd and address 5 usb 7-3: device not accepting address 5, error -71 Like you can see nothing seems changed. Here you are, my lspci output: 00:00.0 Host bridge: Intel Corporation 82830 830 Chipset Host Bridge (rev 02) 00:01.0 PCI bridge: Intel Corporation 82830 830 Chipset AGP Bridge (rev 02) 00:1d.0 USB Controller: Intel Corporation 82801CA/CAM USB Controller #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801CA/CAM USB Controller #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801CA/CAM USB Controller #3 (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 41) 00:1f.0 ISA bridge: Intel Corporation 82801CAM ISA Bridge (LPC) (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801CAM IDE U100 Controller (rev 01) 00:1f.3 SMBus: Intel Corporation 82801CA/CAM SMBus Controller (rev 01) 00:1f.5 Multimedia audio controller: Intel Corporation 82801CA/CAM AC'97 Audio Controller (rev 01) 01:00.0 VGA compatible controller: S3 Inc. SuperSavage IX/C SDR (rev 05) 02:00.0 CardBus bridge: Texas Instruments PCI1420 PC card Cardbus Controller 02:00.1 CardBus bridge: Texas Instruments PCI1420 PC card Cardbus Controller 02:02.0 Communication controller: Agere Systems WinModem 56k (rev 01) 02:08.0 Ethernet controller: Intel Corporation 82801CAM (ICH3) PRO/100 VE (LOM) Ethernet Controller (rev 41) 07:00.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) 07:00.1 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) 07:00.2 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) 07:00.3 USB Controller: ALi Corporation USB 2.0 Controller (rev 01) 07:00.4 FireWire (IEEE 1394): ALi Corporation M5253 P1394 OHCI 1.1 Controller More detailed 00:00.0 Host bridge: Intel Corporation 82830 830 Chipset Host Bridge (rev 02) Subsystem: IBM ThinkPad A/T/X Series Flags: bus master, fast devsel, latency 0 Memory at d000 (32-bit, prefetchable) [size=256M] Capabilities: [40] Vendor Specific Information Capabilities: [a0] AGP version 2.0 00:01.0 PCI bridge: Intel Corporation 82830 830 Chipset AGP Bridge (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, fast devsel, latency 96 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 Memory behind bridge: c010-c01f Prefetchable memory behind bridge: e000-ebff 00:1d.0 USB Controller: Intel Corporation 82801CA/CAM USB Controller #1 (rev 01) (prog-if 00 [UHCI]) Subsystem: IBM ThinkPad A/T/X Series Flags: bus master, medium devsel, latency 0, IRQ 11 I/O ports at 1800 [size=32] 00:1d.1 USB Controller: Intel Corporation 82801CA/CAM USB Controller #2 (rev 01) (prog-if 00 [UHCI]) Subsystem: IBM ThinkPad A/T/X Series Flags: bus master, medium devsel, latency 0, IRQ 11 I/O ports at 1820 [size=32] 00:1d.2 USB Controller: Intel Corporation 82801CA/CAM USB Controller #3 (rev 01) (prog-if 00 [UHCI]) Subsystem: IBM ThinkPad A/T/X Series Flags: bus master, medium devsel, latency 0, IRQ 11 I/O ports at 1840 [size=32] 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 41) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=08, sec-latency=64 I/O behind bridge: 2000-6fff Memory behind bridge: c020-cfff Prefetchable memory behind bridge: f000-f7ff 00:1f.0 ISA bridge: Intel Corporation 82801CAM ISA Bridge (LPC) (rev 01) Flags: bus master, medium devsel, latency 0 00:1f.1 IDE interface: Intel Corporation 82801CAM IDE U100 Controller (rev 01) (prog-if 8a [Master SecP PriP]) Subsystem: IBM ThinkPad A/T/X Series Flags: bus master, medium devsel, latency 0, IRQ 11 I/O ports at 01f0 [size=8] I/O ports at 03f4 [size=1] I/O ports at 0170 [size=8] I/O ports at 0374 [size=1] I/O ports at 1860 [size=16] Memory at 50001000 (32-bit, non-prefetchable) [size=1K] 00:1f.3 SMBus: Intel Corporation 82801CA/CAM SMBus Controller (rev 01) Subsystem: IBM ThinkPad A/T/X Series Flags: medium devsel, IRQ 5 I/O ports at 1880 [size=32
Re: Ehci-hcd kernel driver and ALi chipset doesn't work.
--- David Brownell <[EMAIL PROTECTED]> wrote: > So ... did you verify that not using the external > power > supply *was* causing the problem? > ... > > In this case I can only report what I observed: > that > EHCI in a CardBus format needed extra power. > ... I have attached the power supply but nonthing seems change. ... > > isn't possible to add a feauture to ehci module to > > auto select lower speed if there isn't enought > power > > to reach th HighSpeed mode? > .. > If that really *is* the solution to your problem, > I'd > be very surprised if the manufacturer of your card > did > not provide stern warnings about using the external > power > supply all over the box and throughout the printed > documentation. This isn't a solution this is a workaround. If you buy an Usb2 card and to do something with that yuo must use it at Usb1.1, i don't think that can be called "a solution". > > This isn't a software issue at all. Maybe how we cant validate it? Bye, Topo ___ L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
"Buggy kernel device driver?" for Super Top M6116 SATA Bridge (14cd:6116)
Hi folks. When I run "hdparm -N /dev/sdb" on my cheapo usb-connect sata bridge (Super Top M6116 SATA Bridge , device id 14cd:6116), it returns: /dev/sdb: max sectors = 1953525168/1(1953525168?), HPA setting seems invalid (buggy kernel device driver?) FWIW, I'm running Debian Testing - I originally saw with error with the supplied kernel (3.11.8) but I've compiled and installed a vanilla 3.13.0-rc2 (from kernel.org) and the message is the same. Also, the drive in the enclosure seems to be working perfectly, and it's a Toshiba MQ01ABD100. "lsusb -vd 14cd:6116" returns: Bus 004 Device 004: ID 14cd:6116 Super Top M6116 SATA Bridge Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x14cd Super Top idProduct 0x6116 M6116 SATA Bridge bcdDevice2.20 I've seen other mails which talk about these Super Top controllers being quite fundamentally broken. Is there any benefit in trying to debug/understand this error further/fix the driver, or should I just pitch it in to the nearest trash-can and replace it with something less borked? If this isn't the correct mailing list for this enquiry, please let me know. With kind regards, Jaime -- 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
Linux xHCI driver problems
Dear Sarah, We noticed a couple of problems with the Linux xHCI driver: 1. There is a problem with URB cancellation for USB 2.0 device on USB 3.0 host. When we disable our device, we cancel all pending URBs by calling ioctl with the request code of USBDEVFS_DISCARDURB. When we re-enable our device, we submit new URBs, but when we try to reap them, the program hangs (not every time, but pretty often). The same code works if the device is plugged into the EHCI port, and we also don't see any hanging with xHCI host if we don't do URB cancellation, but have our device terminate URBs by sending zero-length packets instead. 2. Clear Halt of EP does not reset the Sequence number if the device is a USB 3.0 device, while it seems that clear halt properly resets the toggle bits if the device is 2.0 even on an xHCI host. Thank you Yuliya -- 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 xHCI driver problems (reset ep)
Hi Sarah, >> 2. Clear Halt of EP > > Also note that the xHCI hardware will only allow the Reset Endpoint to > complete if the endpoint was actually halted due to a stall, babble, > transfer error, etc. It won't reset the endpoint toggles or sequence > number at arbitrary points, so we can't reset the endpoint after a new > alternate interface setting is installed. I checked the xHCI spec and your guess was correct. I was seeing the following message from the xHCI driver: [57322.699369] xhci_hcd :04:00.0: Endpoint 0x1 not halted, refusing to reset. However, it is not obvious from the spec whether the OS driver should gate the reset endpoint command to the hardware or whether the hardware can still receive it and choose to ignore it. I ran this particular test with an Intel xHCI host. I found that my Macbook (which also uses an Intel host, I believe) seems to send the clear halt / reset ep command to the hardware as I clearly see the sequence number reset. Furthermore, what is interesting is that when we do IOCTL_USB_CLEAR_HALT over USBDEVFS on Linux, the ClearFeature(ENDPOINT_HALT) is still sent to the device over EP0 for the endpoint in question. However, the xHCI driver does not reset the toggle bit (for USB2 device) or sequence number (for USB3 device). This seems a bit incongruent. Finally, the Linux EHCI driver (perhaps the spec is different) acts differently in that both the ClearFeature is sent as well as the toggle bits are reset. Our device goes through a software-directed firmware reset which clears the device-side toggle bits (or sequence numbers). The endpoint is not halted though. Therefore, we want a clean way to reset the toggle bits (or sequence numbers) on the host without having to reconnect to the device. For USB2 (EHCI) we have always related on ClearFeature(ENDPOINT_HALT). Do you have any suggestions, or for the sake of interoperability and consistency, do you think it might be a good idea to just pass the reset ep command down to the hardware and let it decide what to do? Thanks, Yuliya -- 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 xHCI driver problems (reset ep)
Hi Alan, Thank you for the suggestion. We independently ended up with the same workaround, but still weren't happy with it. The problem is we don't want to relinquish access to the device, but to do set-interface, you have to do release interface, and t's a little strange that you are releasing access to the device just to keep using it. While it is unlikely that we will have some other process come in and grab the interface, it still just strikes us as unclean. Yuliya On Wed, Oct 3, 2012 at 8:13 AM, Alan Stern wrote: > On Tue, 2 Oct 2012, Yuliya T wrote: > >> Our device goes through a software-directed firmware reset which >> clears the device-side toggle bits (or sequence numbers). The >> endpoint is not halted though. Therefore, we want a clean way to >> reset the toggle bits (or sequence numbers) on the host without having >> to reconnect to the device. For USB2 (EHCI) we have always related on >> ClearFeature(ENDPOINT_HALT). Do you have any suggestions, or for the >> sake of interoperability and consistency, do you think it might be a >> good idea to just pass the reset ep command down to the hardware and >> let it decide what to do? > > How about doing a Set-Interface or Set-Configuration instead? > > 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: Linux xHCI driver problems (reset ep)
Hi Alan and Sarah, I confirmed that simply calling usb_set_altinterface (which via libusb calls the kernel function usb_set_interface) does correctly clear the toggle bits for USB2 or sequence number for USB3 on an XHCI host controller, even when the alternate interface setting is the same as the previous setting sent to the device. I also agree that if an update is made to usb_reset_endpoint is ideal. That way, Linux would be more consistent with Windows and Darwin. Calling usb_clear_halt will send the control transfer to the device and clear the appropriate toggle/sequence number on the host via the call to usb_reset_endpoint that is embedded within usb_clear_halt. Thanks all, Yuliya On Mon, Oct 15, 2012 at 1:25 PM, Alan Stern wrote: > On Mon, 15 Oct 2012, Sarah Sharp wrote: > >> I double checked, and calling usb_set_interface for the same alternate >> setting that is currently installed will cause the xHCI driver to drop >> and re-add the current endpoints. This should cause the toggle to be >> reset for the endpoints. >> >> I suppose the xHCI driver could do the same thing internally: if >> usb_reset_endpoint() is called with an endpoint that isn't halted, we >> could issue a Configure Endpoint command to drop and re-add the >> endpoint. But we would need to make sure the bandwidth mutex is held, >> and I would have to look at whether it would be safe to add mutex >> locking calls in usb_hcd_reset_endpoint(). > > Probably the best way for xhci-hcd to implement usb_reset_endpoint is > to issue a Configure Endpoint command unconditionally. > > Yes, usb_hcd_reset_endpoint is always supposed to be called in process > context, although this doesn't seem to be documented anywhere. > > 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: Sequence number not incremented for large control transfer
Hi Sarah, Wanted to check back on this previous report: is this a fundamental bug in the hardware or can there be a workaround in the XHCI driver to support this? I did find that if the control transfers are 512B in length (instead of 1024, 2048, or 4096), the host controller doesn't fail for these transactions. Thanks. Yuliya On Tue, Oct 2, 2012 at 5:23 PM, Yuliya T wrote: > We ran into a problem when using ASMedia Technology Inc. ASM1042 > SuperSpeed USB Host Controller (integrated on the desktop's > motherboard) with Linux xHCI driver. The host is sending the > SuperSpeed device a large control transfer (>512B) that requires > multiple OUT transactions. The first OUT Txn is acknowledged, but > then the subsequent one is sent by the host with the same sequence > number. I am attaching a protocol analysis trace (taken with the > Beagle 5000 SuperSpeed Protocol Analyzer) that illustrates the > problem. It can be opened with the Total Phase Data Center software: > http://www.totalphase.com/products/data_center/ > > The same interaction with the same device works with an Intel xHCI host. > > We are not sure if this is a low-level bug with the ASMedia host or if > there is some setup/workaround that can be done within the Linux xHCI > driver to fix this problem. -- 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 xHCI driver problems (URB cancellation)
Hi Sarah, Were you able to look into this more? Of the few problems that I've encountered and reported thus far, this one seems the most critical. Please also note that I see this URB cancellation problem even on the Intel host controller (not just the ASMedia one for which I have kernel debugging turned on). Thanks, Yuliya On Tue, Oct 2, 2012 at 5:09 PM, Yuliya T wrote: > Hi Sarah, > >>> Re: URB Cancellation for USB 2.0 device on xHCI host >> >> Which host controller are you running under? Please send the output of >> `sudo lspci -vvv` and `sudo lspci -vvv -n`. > > I have a "ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller." > >> Also, which version of libusb are you using? Is it libusb or libusb-x? > > I am using libusb but that is only to open the device. After that, > all the URB management for the EP that is having problems is done > directly through the ioctls. Sorry if this wasn't clear from before. > >> What kind of endpoints are being used by your device? There was a >> problem with the bulk continuation flag under USB 3.0 devices, but I'm >> not sure if that was fixed in libusb/libusbx yet. > > They are bulk endpoints, but as I mentioned before, the device is a > USB 2.0 device, simply attached to a USB 3.0 capable port (xHCI port). > The same code has no problem on the Linux EHCI stack, or on Windows > or OS X. > >> Which kernel version are you using? Have you tested with the latest >> stable kernel (currently 3.5.4)? If so, can you recompile your kernel >> with CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING and send me the >> dmesg from one of the runs when the program hangs? > > See attached. The dmesg_while_hanging is when the usermode app in the > host has hung. Then, in the same session I kill the process and took > another dmesg dump (dmesg_after_kill). Therefore, there is overlap > between the two dmesg dump files. > > Please let me know if you have any further suggestions on how to track > this down. > > Thanks, > Yuliya -- 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: UAS errors with Jmicron
2014-08-04 20:07 GMT+02:00 Hans de Goede : > Hi Laszlo, > > On 08/03/2014 12:40 AM, Laszlo T. wrote: >>>>>>> *) usb devices return different descriptors at different speeds >>>>>> >>>>>> All tests were on usb2. >>>>>> I don't have usb3 ports but I will try that at weekend. >>>>>> >>>>>> I'm curious now, am I the first one who has ever tested uas on usb2? >>>>> >>>>> Ni, I've tested it myself too, including running an entire distro >>>>> with gnome3 from an uas disk. >>>>> >>>>> I'll also do some more tests with mkfs.ext4 with my uas disk enclosures >>>>> as that seems to trigger things for you. But for me so far using usb2 is >>>>> not a problem. >>>>> >>>>> Regards, >>>>> >>>>> Hans >>>> >>>> It looks stable with >>>> can_queue = 65536 and qdepth = 32 >>>> on usb2. >>> >>> That is good to hear. >>> >>>> Please share you result when you have chance to test with your enclosure. >>> >>> I've tested 2 different uas enclosures with 3 different disks on usb2, >>> running mkfs.ext4 on a single partition spanning the entire disk, and >>> I could not reproduce, so this seems to be specific to the jmicron >>> chipset your using. Still there is little in harm in just always reducing >>> the usb2 qdepth to 32, that should be plenty to keep things close to maximum >>> possible throughput on usb2. >>> >>> I'll write a patch for this and I'll Cc. you on the patch. >> >> Thank you. >> >> I could tested the device on USB 3.0 with an unpatched 3.15.5 kernel >> and unfortunately it failed with the usual error. >> >> >> lsusb on usb3 >> >> Bus 002 Device 002: ID 152d:0567 JMicron Technology Corp. / JMicron >> USA Technology Corp. >> Device Descriptor: >> bLength18 >> bDescriptorType 1 >> bcdUSB 2.10 > > Thanks for the log, but this indicates that the device is still > connected at usb-2 speed, so either you did not use an > usb-3 cable, or the port you used was not superspeed > capable (or it ended up falling back to usb-2 for some > other reason). > > And since this is an otherwise unmodified kernel, that > explains why you get the old troublesome behavior in this > case. > > When connected over USB-3 I would expect this to read: > > bcdUSB 3.00 > > > Another way to check the speed is to do lsusb: > > [hans@shalem ~]$ lsusb > Bus 009 Device 002: ID 045b:021f Hitachi, Ltd > Bus 009 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub > Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > > Note how the "Hitachi, Ltd" device is on the same Bus as the > "Linux Foundation 3.0 root hub" > > If that is not the case for a device, then it is not connected > over USB-3. > > Regards, > > Hans Hello, I bought a new desktop machine. So I have finally USB3.0. I tried with different USB 3.0 cables and different USB3.0 ports but I still get the 'bcdUSB 2.10'. Maybe this is another bug. On 3.14 + FUA disabler patch: [ 130.576495] usb 1-4: new high-speed USB device number 5 using xhci_hcd [ 130.789822] usb 1-4: New USB device found, idVendor=152d, idProduct=0567 [ 130.789827] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 130.789830] usb 1-4: Product: USB to ATA/ATAPI Bridge [ 130.789832] usb 1-4: Manufacturer: JMicron [ 130.789834] usb 1-4: SerialNumber: 74D781114413108 [ 130.808397] usb-storage 1-4:1.0: USB Mass Storage device detected [ 130.808467] usb-storage 1-4:1.0: Quirks match for vid 152d pid 0567: 100 [ 130.808499] scsi6 : usb-storage 1-4:1.0 [ 130.808551] usbcore: registered new interface driver usb-storage [ 131.808755] scsi 6:0:0:0: Direct-Access JMicron Generic 0114 PQ: 0 ANSI: 6 [ 131.808986] sd 6:0:0:0: Attached scsi generic sg2 type 0 [ 131.809895] sd 6:0:0:0: [sdc] Spinning up disk... [ 132.812230] ready [ 135.824326] sd 6:0:0:0: [sdc] 976773168 512-byte logical blocks: (500 GB/465 GiB) [ 135.824605] sd 6:0:0:0: [sdc] Write Protect is off [ 135.824607] sd 6:0:0:0: [sdc] Mode Sense: 47 00 10 08 [ 135.824862] sd 6:0:0:0: [sdc] Disabling FUA [ 135.824863] sd 6:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 135.825651] sd 6:0:0:0: [sdc] Disabling FUA [ 135.857366] sdc: sdc1 sdc2 [ 135.858448] sd 6:0:0:0: [sdc] Disabling FUA [ 135.858450] sd 6:0:0:0: [sdc]
UAS errors with Jmicron
Hello, I have some problems with Jmicron JMS567 (Sata 6 Gb/s -> USB3.0) mobile rack. I tried on different kernels: 3.15.5 3.16.rc6 I got the following errors when I ran a mkfs.ext4 command and then the device disappeared. Jul 26 19:54:37 debian kernel: [ 118.060026] usb 8-3: new high-speed USB device number 2 using ehci-pci Jul 26 19:54:37 debian kernel: [ 118.245208] usb 8-3: New USB device found, idVendor=152d, idProduct=0567 Jul 26 19:54:37 debian kernel: [ 118.245210] usb 8-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Jul 26 19:54:37 debian kernel: [ 118.245212] usb 8-3: Product: USB to ATA/ATAPI Bridge Jul 26 19:54:37 debian kernel: [ 118.245213] usb 8-3: Manufacturer: JMicron Jul 26 19:54:37 debian kernel: [ 118.245215] usb 8-3: SerialNumber: 74D781114413108 Jul 26 19:54:37 debian mtp-probe: checking bus 8, device 2: "/sys/devices/pci:00/: 00:1d.7/usb8/8-3" Jul 26 19:54:37 debian mtp-probe: bus: 8, device: 2 was not an MTP device Jul 26 19:54:37 debian kernel: [ 118.257932] usbcore: registered new interface driver usb-storage Jul 26 19:54:37 debian kernel: [ 118.259053] scsi6 : uas Jul 26 19:54:37 debian kernel: [ 118.259178] usbcore: registered new interface driver uas Jul 26 19:54:37 debian kernel: [ 118.259720] scsi 6:0:0:0: Direct-Access JMicron Generic 0114 PQ: 0 ANSI: 6 Jul 26 19:54:37 debian kernel: [ 118.260863] sd 6:0:0:0: Attached scsi generic sg2 type 0 Jul 26 19:54:37 debian kernel: [ 118.261217] sd 6:0:0:0: [sdc] Spinning up disk... Jul 26 19:54:39 debian kernel: [ 119.264049] ..ready Jul 26 19:54:39 debian kernel: [ 120.268470] sd 6:0:0:0: [sdc] 976773168 512-byte logical blocks: (500 GB/465 GiB) Jul 26 19:54:39 debian kernel: [ 120.268472] sd 6:0:0:0: [sdc] 4096-byte physical blocks Jul 26 19:54:39 debian kernel: [ 120.269468] sd 6:0:0:0: [sdc] Write Protect is off Jul 26 19:54:39 debian kernel: [ 120.269968] sd 6:0:0:0: [sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA Jul 26 19:54:39 debian kernel: [ 120.290104] sdc: sdc1 sdc2 Jul 26 19:54:39 debian kernel: [ 120.292356] sd 6:0:0:0: [sdc] Attached SCSI disk Jul 26 19:56:15 debian kernel: [ 216.611696] usb 8-3: USB disconnect, device number 2 Jul 26 19:56:15 debian kernel: [ 216.611697] sd 6:0:0:0: [sdc] uas_submit_sense_urb 8800ca32ac80 tag 112, inflight: s-st a-out a-cmd s-cmd Jul 26 19:56:15 debian kernel: [ 216.611700] scsi host6: sense urb submission error -19 stream 0 Jul 26 19:56:15 debian kernel: [ 216.612035] sd 6:0:0:0: [sdc] uas_cmd_cmplt 8800ca2f2240 tag 39, inflight: CMD Jul 26 19:56:15 debian kernel: [ 216.612120] sd 6:0:0:0: [sdc] uas_cmd_cmplt 8800ca2f20c0 tag 40, inflight: CMD Jul 26 19:56:15 debian kernel: [ 216.612185] sd 6:0:0:0: [sdc] uas_cmd_cmplt 8800ca300dc0 tag 41, inflight: CMD Jul 26 19:56:15 debian kernel: [ 216.612248] sd 6:0:0:0: [sdc] uas_cmd_cmplt 8800ca300c40 tag 42, inflight: CMD Jul 26 19:56:15 debian kernel: [ 216.612315] sd 6:0:0:0: [sdc] uas_cmd_cmplt 8800ca300ac0 tag 43, inflight: CMD Jul 26 19:56:15 debian kernel: [ 216.612377] sd 6:0:0:0: [sdc] uas_cmd_cmplt 8800ca300940 tag 44, inflight: CMD Jul 26 19:56:15 debian kernel: [ 216.612441] sd 6:0:0:0: [sdc] uas_cmd_cmplt 8800ca3007c0 tag 45, inflight: CMD Jul 26 19:56:15 debian kernel: [ 216.612504] sd 6:0:0:0: [sdc] uas_cmd_cmplt 8800ca300640 tag 46, inflight: CMD Jul 26 19:56:15 debian kernel: [ 216.612570] sd 6:0:0:0: [sdc] uas_cmd_cmplt 8800ca3004c0 tag 47, inflight: CMD Jul 26 19:56:15 debian kernel: [ 216.612633] sd 6:0:0:0: [sdc] uas_cmd_cmplt 8800ca300340 tag 48, inflight: CMD ... Jul 26 19:56:15 debian kernel: [ 216.625366] sd 6:0:0:0: [sdc] uas_zap_dead 8800ca3277c0 tag 105, inflight: CMD abort Jul 26 19:56:15 debian kernel: [ 216.625368] sd 6:0:0:0: [sdc] abort completed Jul 26 19:56:15 debian kernel: [ 216.625370] sd 6:0:0:0: [sdc] uas_zap_dead 8800ca327640 tag 106, inflight: CMD abort Jul 26 19:56:15 debian kernel: [ 216.625371] sd 6:0:0:0: [sdc] abort completed Jul 26 19:56:15 debian kernel: [ 216.625373] sd 6:0:0:0: [sdc] uas_zap_dead 8800ca3274c0 tag 107, inflight: CMD abort Jul 26 19:56:15 debian kernel: [ 216.625375] sd 6:0:0:0: [sdc] abort completed Jul 26 19:56:15 debian kernel: [ 216.625377] sd 6:0:0:0: [sdc] uas_zap_dead 8800ca327340 tag 108, inflight: CMD abort Jul 26 19:56:15 debian kernel: [ 216.625378] sd 6:0:0:0: [sdc] abort completed Jul 26 19:56:15 debian kernel: [ 216.625380] sd 6:0:0:0: [sdc] uas_zap_dead 8800ca3271c0 tag 109, inflight: CMD abort Jul 26 19:56:15 debian kernel: [ 216.625382] sd 6:0:0:0: [sdc] abort completed Jul 26 19:56:15 debian kernel: [ 216.625384] sd 6:0:0:0: [sdc] uas_zap_dead 8800ca327040 tag 110, inflight: CMD abort Jul 26 19:56:15 debian kernel: [ 216.625385] sd 6:0:0:0: [sdc] abort completed Jul 26 19:56:15 debian kernel: [ 216.625387] sd 6:0:0:0: [sdc] uas_zap_dead 8800ca32ae00 tag 111, inflight: CMD abort Jul 26 1
Re: UAS errors with Jmicron
I have some problems with Jmicron JMS567 (Sata 6 Gb/s -> USB3.0) >>> mobile rack. I tried on different kernels: 3.15.5 3.16.rc6 I got the following errors when I ran a mkfs.ext4 command and then >>> the device disappeared. Jul 26 19:54:37 debian kernel: [ 118.060026] usb 8-3: new >>> high-speed USB device number 2 using ehci-pci >>> >>> Hans, shouldn't we default to usb-storage rather than uas if the >>> device >>> supports both and isn't connected at SuperSpeed? >> >> We would give up command tagging needlessly. > > Right, that is what I was about to say. For testing purposes > I've a Fedora rawhide install a ssd in a usb3 uas 2.5" enclosure, > and it is much faster with uas in usb2 ports too. > > It looks like the device disconnects as soon as we start using > multiple requests at once (it seems to disconnect immediately > after the basic probing). > > This could be a power issue. Laszlo, what sort of drive is in the > mobile rack, and how is it powered ? > I don't think it is a power issue. I'm using on desktop PC on usb2 port with just a simple cable but the disk (WD5000LPVX) only consumes 1.4 Watts (read/write) and it is stable on Windows. And I found an interesting thing: it is also stable with NTFS file system under Linux even on 3.14 kernel (that does not contain the 'usb-storage/SCSI: Add broken_fua blacklist flag' patch https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg30073.html ). Br, Laszlo -- 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: UAS errors with Jmicron
> Laszlo, you can try specifying the "quirks=152d:0567:u" module > parameter for usb-storage. I don't know if that will help, but it > might. > >> What can the problem be? > > There's no way to tell from just this information. > Unfortunately it did not help. Is there any other information you need? Br, Laszlo -- 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: UAS errors with Jmicron
Hello, >> I don't think it is a power issue. >> I'm using on desktop PC on usb2 port with just a simple cable but the >> disk (WD5000LPVX) only consumes 1.4 Watts (read/write) and it is >> stable on Windows. > > http://www.wdc.com/wdproducts/library/SpecSheet/ENG/2879-771437.pdf > > Says it uses 1.4 Watts "average", it has a rated peak power > consumption of 1A, and a USB2 port can deliver only 0.5 A, so > its rate maximum is twice as much as the USB2 port's maximum. I think that peak only can happens when the disk starts. > Disconnection issues like you are seeing are typical for drawing > too much power from the port. Using uas as the dmesg shows you > are will allow us to send more commands to the disk at once > (which is a good thing, it is faster) and as such will increase > power consumption. Maybe the too much commands freeze the chip. > > Does the enclosure you are using have the option to provide > external power, and have you tested things that way ? > Unfortunately no option for that: http://www.delock.com/produkte/G_42523/merkmale/1.html?setLanguage=en Today I wanted to buy a USB Y cable to double the available power but I didn't have luck with local shops. I need more time to exclude the possibility of this power issue. (But I have to say again, it is stable on Windows.) Br, Laszlo -- 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: UAS errors with Jmicron
> > A usbmon trace might be useful. See Documentation/usb/usbmon.txt in > the kernel source for instructions. > > Alan Stern > Hello, I ran some commands and recorded them: -checking with cfdisk -mounting the ntfs partition -some reading on it -unmounting -and the unsuccessful ext4 filesystem creating http://pastebin.com/xmKnwPF5 Br, Laszlo -- 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: UAS errors with Jmicron
>> > Disconnection issues like you are seeing are typical for drawing >> > too much power from the port. Using uas as the dmesg shows you >> > are will allow us to send more commands to the disk at once >> > (which is a good thing, it is faster) and as such will increase >> > power consumption. >> >> Maybe the too much commands freeze the chip. > > That is a testable hypothesis. > This patch shows how to manipulate that number. > You can play with the number to see whether there's > a critical value. I tested with lot of values. I'm not totally sure but it looks the 31 is max number where it is still stable to create an ext4 filesystem. Br, Laszlo -- 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: UAS errors with Jmicron
2014-07-31 9:54 GMT+02:00 Oliver Neukum : > On Thu, 2014-07-31 at 00:39 +0200, Laszlo T. wrote: >> >> > Disconnection issues like you are seeing are typical for drawing >> >> > too much power from the port. Using uas as the dmesg shows you >> >> > are will allow us to send more commands to the disk at once >> >> > (which is a good thing, it is faster) and as such will increase >> >> > power consumption. >> >> >> >> Maybe the too much commands freeze the chip. >> > >> > That is a testable hypothesis. >> > This patch shows how to manipulate that number. >> > You can play with the number to see whether there's >> > a critical value. >> >> I tested with lot of values. I'm not totally sure but it looks the 31 >> is max number where it is still stable to create an ext4 filesystem. > > So we have a number. What is unclear to me from the available > information is whether we are dealing with a limitation of the > drive or of the enclosure. > Did you happen to test the enclosure with another drive? > Unfortunately I don't have another notebook disk but I can use without the enclosure in the PC if it helps something. I guess this number could be the NCQ queue depth. Br, Laszlo -- 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: UAS errors with Jmicron
2014-07-31 12:53 GMT+02:00 Hans de Goede : > Hi, > > On 07/31/2014 12:39 AM, Laszlo T. wrote: >>>>> Disconnection issues like you are seeing are typical for drawing >>>>> too much power from the port. Using uas as the dmesg shows you >>>>> are will allow us to send more commands to the disk at once >>>>> (which is a good thing, it is faster) and as such will increase >>>>> power consumption. >>>> >>>> Maybe the too much commands freeze the chip. >>> >>> That is a testable hypothesis. >>> This patch shows how to manipulate that number. >>> You can play with the number to see whether there's >>> a critical value. >> >> I tested with lot of values. I'm not totally sure but it looks the 31 >> is max number where it is still stable to create an ext4 filesystem. > > Thanks, that is good to know. Can you try the following patch instead > of changing can_queue ? : > > diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c > index 511b229..6cdc1b9 100644 > --- a/drivers/usb/storage/uas.c > +++ b/drivers/usb/storage/uas.c > @@ -1033,6 +1033,7 @@ static int uas_configure_endpoints(struct uas_dev_info > *devinfo) > 3, 256, GFP_NOIO); > if (devinfo->qdepth < 0) > return devinfo->qdepth; > + devinfo->qdepth = 32; > devinfo->use_streams = 1; > } > > > Note that the 32 rather then 31 is on purpose. There is 1 stream reserved > for non tagged commands, so under normal use a can_queue of 31 will cause > streams 2-32 to be used (stream addresses start at 1 not 0). > > And can you please also do (with the device plugged in): > > sudo lsusb -v &> lsusb.log and attach lsusb.log to your next mail? > > Then assuming my alternative patch works, I'll write a patch to allow > overriding max qdepth from a quirk + a quirk for your enclosure. Thank you, I will try it tonight. I've already sent the output of lsusb in my first email: https://www.mail-archive.com/linux-usb@vger.kernel.org/msg46005.html But I send a new one if you would like it. Br, Laszlo -- 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: UAS errors with Jmicron
I tested with lot of values. I'm not totally sure but it looks the 31 is max number where it is still stable to create an ext4 filesystem. >>> >>> Thanks, that is good to know. Can you try the following patch instead >>> of changing can_queue ? : >>> >>> diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c >>> index 511b229..6cdc1b9 100644 >>> --- a/drivers/usb/storage/uas.c >>> +++ b/drivers/usb/storage/uas.c >>> @@ -1033,6 +1033,7 @@ static int uas_configure_endpoints(struct >>> uas_dev_info *devinfo) >>> 3, 256, GFP_NOIO); >>> if (devinfo->qdepth < 0) >>> return devinfo->qdepth; >>> + devinfo->qdepth = 32; >>> devinfo->use_streams = 1; >>> } >>> >>> >>> Note that the 32 rather then 31 is on purpose. There is 1 stream reserved >>> for non tagged commands, so under normal use a can_queue of 31 will cause >>> streams 2-32 to be used (stream addresses start at 1 not 0). >>> >>> And can you please also do (with the device plugged in): >>> >>> sudo lsusb -v &> lsusb.log and attach lsusb.log to your next mail? >>> >>> Then assuming my alternative patch works, I'll write a patch to allow >>> overriding max qdepth from a quirk + a quirk for your enclosure. >> >> Thank you, I will try it tonight. >> I've already sent the output of lsusb in my first email: >> https://www.mail-archive.com/linux-usb@vger.kernel.org/msg46005.html > > Ah, I forgot about that one. That one however seems to be with the > device plugged into a usb-2 port, do you have a machine with a usb-3 > port and if so can you do the lsusb with the device plugged into > a usb-3 port (*) ? > > This also raises the question if you've been doing your testing where > using 31 seems to fix things with the device plugged into a usb-2 or a > usb-3 port ? > > Note that my patch won't do anything for the device plugged into > an usb-2 port, in that case you need to change the qdepth = 256 a > few lines higher to qdepth = 32. > > If you've access to both usb-2 and usb-3 ports, it would be good if you > could test with both, and let us know if you you need qdepth = 32 to fix > things in both cases. > > I've just re-read the uas spec and it does not say anything about how to > determine the uas bridge's max qdepth when running in usb-2, so maybe > rather then making this a quirk we need to play it safe and change > the qdepth = 256 to qdepth = 32 unconditionally. In usb-3 mode most > bridges don't seem to support more then 16 or 32 as qdepth, chances > are that for some implementations the same applies to usb-2 mode. > > Given the relative low speed of the usb-2 bus a qdepth of 32 or even > 16 should be more then enough to get most of the benefits of tcq. > > Regards, > > Hans > > > *) usb devices return different descriptors at different speeds All tests were on usb2. I don't have usb3 ports but I will try that at weekend. I'm curious now, am I the first one who has ever tested uas on usb2? Br, Laszlo -- 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: UAS errors with Jmicron
2014-07-31 16:16 GMT+02:00 Hans de Goede : > Hi, > > On 07/31/2014 03:51 PM, Laszlo T. wrote: >>>>>> >>>>>> I tested with lot of values. I'm not totally sure but it looks the 31 >>>>>> is max number where it is still stable to create an ext4 filesystem. >>>>> >>>>> Thanks, that is good to know. Can you try the following patch instead >>>>> of changing can_queue ? : >>>>> >>>>> diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c >>>>> index 511b229..6cdc1b9 100644 >>>>> --- a/drivers/usb/storage/uas.c >>>>> +++ b/drivers/usb/storage/uas.c >>>>> @@ -1033,6 +1033,7 @@ static int uas_configure_endpoints(struct >>>>> uas_dev_info *devinfo) >>>>> 3, 256, GFP_NOIO); >>>>> if (devinfo->qdepth < 0) >>>>> return devinfo->qdepth; >>>>> + devinfo->qdepth = 32; >>>>> devinfo->use_streams = 1; >>>>> } >>>>> >>>>> >>>>> Note that the 32 rather then 31 is on purpose. There is 1 stream reserved >>>>> for non tagged commands, so under normal use a can_queue of 31 will cause >>>>> streams 2-32 to be used (stream addresses start at 1 not 0). >>>>> >>>>> And can you please also do (with the device plugged in): >>>>> >>>>> sudo lsusb -v &> lsusb.log and attach lsusb.log to your next mail? >>>>> >>>>> Then assuming my alternative patch works, I'll write a patch to allow >>>>> overriding max qdepth from a quirk + a quirk for your enclosure. >>>> >>>> Thank you, I will try it tonight. >>>> I've already sent the output of lsusb in my first email: >>>> https://www.mail-archive.com/linux-usb@vger.kernel.org/msg46005.html >>> >>> Ah, I forgot about that one. That one however seems to be with the >>> device plugged into a usb-2 port, do you have a machine with a usb-3 >>> port and if so can you do the lsusb with the device plugged into >>> a usb-3 port (*) ? >>> >>> This also raises the question if you've been doing your testing where >>> using 31 seems to fix things with the device plugged into a usb-2 or a >>> usb-3 port ? >>> >>> Note that my patch won't do anything for the device plugged into >>> an usb-2 port, in that case you need to change the qdepth = 256 a >>> few lines higher to qdepth = 32. >>> >>> If you've access to both usb-2 and usb-3 ports, it would be good if you >>> could test with both, and let us know if you you need qdepth = 32 to fix >>> things in both cases. >>> >>> I've just re-read the uas spec and it does not say anything about how to >>> determine the uas bridge's max qdepth when running in usb-2, so maybe >>> rather then making this a quirk we need to play it safe and change >>> the qdepth = 256 to qdepth = 32 unconditionally. In usb-3 mode most >>> bridges don't seem to support more then 16 or 32 as qdepth, chances >>> are that for some implementations the same applies to usb-2 mode. >>> >>> Given the relative low speed of the usb-2 bus a qdepth of 32 or even >>> 16 should be more then enough to get most of the benefits of tcq. >>> >>> Regards, >>> >>> Hans >>> >>> >>> *) usb devices return different descriptors at different speeds >> >> All tests were on usb2. >> I don't have usb3 ports but I will try that at weekend. >> >> I'm curious now, am I the first one who has ever tested uas on usb2? > > Ni, I've tested it myself too, including running an entire distro > with gnome3 from an uas disk. > > I'll also do some more tests with mkfs.ext4 with my uas disk enclosures > as that seems to trigger things for you. But for me so far using usb2 is > not a problem. > > Regards, > > Hans It looks stable with can_queue = 65536 and qdepth = 32 on usb2. Please share you result when you have chance to test with your enclosure. Br, Laszlo -- 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: UAS errors with Jmicron
> *) usb devices return different descriptors at different speeds All tests were on usb2. I don't have usb3 ports but I will try that at weekend. I'm curious now, am I the first one who has ever tested uas on usb2? >>> >>> Ni, I've tested it myself too, including running an entire distro >>> with gnome3 from an uas disk. >>> >>> I'll also do some more tests with mkfs.ext4 with my uas disk enclosures >>> as that seems to trigger things for you. But for me so far using usb2 is >>> not a problem. >>> >>> Regards, >>> >>> Hans >> >> It looks stable with >> can_queue = 65536 and qdepth = 32 >> on usb2. > > That is good to hear. > >> Please share you result when you have chance to test with your enclosure. > > I've tested 2 different uas enclosures with 3 different disks on usb2, > running mkfs.ext4 on a single partition spanning the entire disk, and > I could not reproduce, so this seems to be specific to the jmicron > chipset your using. Still there is little in harm in just always reducing > the usb2 qdepth to 32, that should be plenty to keep things close to maximum > possible throughput on usb2. > > I'll write a patch for this and I'll Cc. you on the patch. Thank you. I could tested the device on USB 3.0 with an unpatched 3.15.5 kernel and unfortunately it failed with the usual error. lsusb on usb3 Bus 002 Device 002: ID 152d:0567 JMicron Technology Corp. / JMicron USA Technology Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x152d JMicron Technology Corp. / JMicron USA Technology Corp. idProduct 0x0567 bcdDevice1.14 iManufacturer 1 JMicron iProduct2 USB to ATA/ATAPI Bridge iSerial 3 74D781114413108 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 85 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 USB Mass Storage bmAttributes 0xc0 Self Powered MaxPower 30mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 6 MSC Bulk-Only Transport Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 1 bNumEndpoints 4 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 98 iInterface 10 MSC USB Attached SCSI Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Command pipe (0x01) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Status pipe (0x02) Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Data-in pipe (0x03) Endpoint Descriptor:
USB kernel debug
I sent a message to the group yesterday, but I suspect it was too big for it's own good and didn't make it to the list. I'm attempting to debug a USB problem where multiple UVC camera causes the USB driver to crash and shut down. All *HCI devices stop working. I managed to get a USB serial port up and running on my laptop and connect it to an old machine with a built in serial port, as an attempt to get KGDB running, but alas, KGDB does not recognize /dev/ttyUSB0 as a valid device. It looks like KGDB does not support the EHCI debug cable anymore, although a crossover cable is available if that becomes an option. Can someone in the group advise me on how to debug this issue? I was hoping to get a back trace for you guys... Thanks, Brian -- 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 kernel debug
Thanks for replying Alan. I really appreciate it. You asked what I was hoping to do. I have a six camera system that crashes regularly forcing a reboot. I'm hoping to get more stability. It's possible that the failure is software and not hardware or kernel, but at any rate I'd like to know what the issue really is. Will this cable work for HCI debug? http://www.datapro.net/products/usb-3-0-super-speed-a-a-debugging-cable.html Will any crossover cable work? I thought HCI debug had disappeared from the kernel because there is no option under debugging to enable the HCI debugger like there is for kbd and serial. Sorry the dmesg was so verbose. I've been experimenting with the hardware and was able to isolate the failure to a single port. Changing cameras or hubs didn't make a difference. At the moment (with kernel 3.5.2) This particular right side xHCI port will not accept the USB hub. Here is the output of dmesg for the port when the HUB is plugged in. Note: the cameras are enabled when I plug it in, but shutting them off or leaving the hub disconnected does not make any difference. The hub is not working. [ 4855.820204] usb 1-1: new high-speed USB device number 46 using xhci_hcd [ 4855.964916] usb 1-1: New USB device found, idVendor=05e3, idProduct=0610 [ 4855.964919] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 4855.964920] usb 1-1: Product: USB2.0 Hub [ 4855.964921] usb 1-1: Manufacturer: GenesysLogic [ 4855.965769] hub 1-1:1.0: USB hub found [ 4855.966348] hub 1-1:1.0: 4 ports detected [ 4858.173486] usb 2-1: Device not responding to setup address. [ 4858.383424] usb 2-1: Device not responding to setup address. [ 4858.590051] usb 2-1: device not accepting address 19, error -71 What can I do from here, without kgdb access? Thanks again, Brian On 05/16/16 12:52, Alan Stern wrote: > On Mon, 16 May 2016, Brian T. McKee wrote: > >> I sent a message to the group yesterday, but I suspect it was too big >> for it's own good and didn't make it to the list. > It did; I saw it. > >> I'm attempting to debug a USB problem where multiple UVC camera causes >> the USB driver to crash and shut down. All *HCI devices stop working. > If you could post a dmesg log showing how this happens, it might help. > >> I managed to get a USB serial port up and running on my laptop and >> connect it to an old machine with a built in serial port, as an attempt >> to get KGDB running, but alas, KGDB does not recognize /dev/ttyUSB0 as a >> valid device. >> >> It looks like KGDB does not support the EHCI debug cable anymore, > It should. If it doesn't, it's a regression. > >> although a crossover cable is available if that becomes an option. >> >> Can someone in the group advise me on how to debug this issue? I was >> hoping to get a back trace for you guys... > Have you considered logging in over the network? > > What exactly do you want to learn? kgdb may not be the best way of > learning it. > > The log in your previous message wasn't very intelligible. You had too > many debug options turned on, which is almost as bad as not having > enough. > > 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 kernel debug
boxdrv(O) joydev hid_logitech_hidpp uvcvideo videobuf2_vmalloc ftdi_sio videobuf2_memops videobuf2_v4l2 hid_logitech_dj usbserial videodev videobuf2_core btusb btrtl btbcm btintel bluetooth snd_hda_codec_hdmi nvidia_drm(PO) nvidia_modeset(PO) nvidia(PO) arc4 iwlmvm asus_nb_wmi asus_wmi sparse_keymap mac80211 snd_hda_codec_realtek snd_hda_codec_generic drm_kms_helper snd_hda_intel snd_hda_codec syscopyarea sysfillrect snd_hda_core sysimgblt fb_sys_fops snd_pcm drm snd_timer iwlwifi coretemp snd hwmon soundcore efi_pstore r8169 cfg80211 x86_pkg_temp_thermal mii i2c_i801 lpc_ich efivars wmi efivarfs [last unloaded: xhci_hcd] [ 8071.052404] CPU: 7 PID: 9330 Comm: modprobe Tainted: PW O 4.5.2-gentoo #1 [ 8071.052404] Hardware name: ASUSTeK COMPUTER INC. G751JL/G751JL, BIOS G751JL.204 08/01/2015 [ 8071.052405] task: 8803f03fa040 ti: 880340908000 task.ti: 880340908000 [ 8071.052406] RIP: 0010:[] [] free_msi_irqs+0x3d/0x15e [ 8071.052408] RSP: 0018:88034090bae0 EFLAGS: 00010282 [ 8071.052409] RAX: 88046d71cc00 RBX: 88046e329000 RCX: 88046e400100 [ 8071.052409] RDX: RSI: 001a RDI: [ 8071.052410] RBP: 88007d4862c0 R08: 88046e48 R09: fffa [ 8071.052411] R10: R11: 000122a5 R12: [ 8071.052412] R13: 88046e329270 R14: 0001 R15: ffe4 [ 8071.052413] FS: 7f347e43b700() GS:88047f1c() knlGS: [ 8071.052413] CS: 0010 DS: ES: CR0: 80050033 [ 8071.052414] CR2: 7fff2c09afb0 CR3: 00045c546000 CR4: 001406e0 [ 8071.052415] Stack: [ 8071.052415] 88046e329000 88042dd81d40 ffe4 00ff [ 8071.052417] 812c82ac 008688046e329098 88033fce6000 88033fce6230 [ 8071.052418] 88033fce6000 88033fce6230 88033fce6000 88046e329000 [ 8071.052420] Call Trace: [ 8071.052421] [] ? pci_enable_msi_range+0x254/0x2e0 [ 8071.052423] [] ? xhci_run+0x3d9/0x632 [xhci_hcd] [ 8071.052425] [] ? usb_add_hcd+0x47c/0x7da [ 8071.052426] [] ? usb_hcd_pci_probe+0x27b/0x39b [ 8071.052427] [] ? kernfs_add_one+0x11c/0x130 [ 8071.052429] [] ? xhci_pci_probe+0x22/0x182 [xhci_pci] [ 8071.052431] [] ? pci_device_probe+0x7e/0xe7 [ 8071.052432] [] ? driver_probe_device+0x10d/0x24d [ 8071.052433] [] ? __driver_attach+0x53/0x73 [ 8071.052434] [] ? driver_probe_device+0x24d/0x24d [ 8071.052435] [] ? bus_for_each_dev+0x61/0x78 [ 8071.052436] [] ? bus_add_driver+0xe4/0x1d7 [ 8071.052437] [] ? 0xa001e000 [ 8071.052438] [] ? driver_register+0x83/0xbb [ 8071.052438] [] ? 0xa001e000 [ 8071.052439] [] ? do_one_initcall+0xe2/0x15f [ 8071.052441] [] ? do_init_module+0x51/0x1b2 [ 8071.052442] [] ? load_module+0x1807/0x1c35 [ 8071.052443] [] ? copy_module_from_fd+0x7f/0xd8 [ 8071.052445] [] ? SyS_finit_module+0x51/0x5c [ 8071.052446] [] ? SyS_finit_module+0x51/0x5c [ 8071.052448] [] ? entry_SYSCALL_64_fastpath+0x16/0x6e [ 8071.052448] Code: af 70 02 00 00 4c 39 ed 74 2e 83 7d 10 00 74 22 45 31 e4 44 3b 65 14 73 19 8b 7d 10 44 01 e7 e8 44 05 de ff 48 83 78 68 00 74 02 <0f> 0b 41 ff c4 eb e1 48 8b 6d 00 eb cd 48 8b 83 68 02 00 00 48 [ 8071.052466] RIP [] free_msi_irqs+0x3d/0x15e [ 8071.052467] RSP [ 8071.052468] ---[ end trace 61566651c88f6b62 ]--- If you think of any more information I should look at, just mention it. Thanks. Brian On 05/16/16 12:52, Alan Stern wrote: > On Mon, 16 May 2016, Brian T. McKee wrote: > >> I sent a message to the group yesterday, but I suspect it was too big >> for it's own good and didn't make it to the list. > It did; I saw it. > >> I'm attempting to debug a USB problem where multiple UVC camera causes >> the USB driver to crash and shut down. All *HCI devices stop working. > If you could post a dmesg log showing how this happens, it might help. > >> I managed to get a USB serial port up and running on my laptop and >> connect it to an old machine with a built in serial port, as an attempt >> to get KGDB running, but alas, KGDB does not recognize /dev/ttyUSB0 as a >> valid device. >> >> It looks like KGDB does not support the EHCI debug cable anymore, > It should. If it doesn't, it's a regression. > >> although a crossover cable is available if that becomes an option. >> >> Can someone in the group advise me on how to debug this issue? I was >> hoping to get a back trace for you guys... > Have you considered logging in over the network? > > What exactly do you want to learn? kgdb may not be the best way of > learning it. > > The log in your previous message wasn't very intelligible. You had too > many debug options turned on, which is almost as bad as not having > enough. > > 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 kernel debug
Thanks Greg. It is a powered USB hub. The supplies have 2.5 amps to spread across three cameras. One of the hub's ports uses laptop power, but I'm not using that port. The USB 3.0 spec (according to wikipedia) requires that each port be capable of delivering 900 mA, so those power supplies seem a bit low (needs 200mA more). But I strongly doubt the cameras are pulling 900mA since they also work with USB 2.0 ports which specifies a much smaller current. I can measure it if I play with a soldering iron, but I'd rather not risk damaging a camera. I'm still trying to isolate the bad behavior to a single cause. I can still get good captures, albeit randomly after many crashes and segfaults of gstreamer. On 05/16/16 14:20, Greg KH wrote: > On Mon, May 16, 2016 at 02:09:03PM -0700, Brian T. McKee wrote: >> I just noticed that timing matters. If I bring the USB devices up one at >> a time, with lots of time between power ups, things seem to initialize >> better. And there are two ports that won't work much at all and two that >> work until this failure occurs. > Sounds like a power-draw issue, have you checked to ensure that you > aren't just pulling too much power? > > If you use a powered hub, all is good, right? I'd strongly just > recommend doing that. > > good luck! > > greg k-h -- 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 kernel debug
Here's another crash. I include discovery of the hubs, cameras and even the logitech keyboard and mouse wireless dongle. [ 2158.726264] usb 1-1: new full-speed USB device number 48 using xhci_hcd [ 2158.893384] usb 1-1: New USB device found, idVendor=046d, idProduct=c52b [ 2158.893386] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 2158.893387] usb 1-1: Product: USB Receiver [ 2158.893388] usb 1-1: Manufacturer: Logitech [ 2158.903489] logitech-djreceiver 0003:046D:C52B.001E: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-:00:14.0-1/input2 [ 2159.016089] input: Logitech M185 as /devices/pci:00/:00:14.0/usb1/1-1/1-1:1.2/0003:046D:C52B.001E/0003:046D:4008.001F/input/input48 [ 2159.016251] logitech-hidpp-device 0003:046D:4008.001F: input,hidraw1: USB HID v1.11 Mouse [Logitech M185] on usb-:00:14.0-1:1 [ 2159.020395] input: Logitech K270 as /devices/pci:00/:00:14.0/usb1/1-1/1-1:1.2/0003:046D:C52B.001E/0003:046D:4003.0020/input/input49 [ 2159.020477] logitech-hidpp-device 0003:046D:4003.0020: input,hidraw2: USB HID v1.11 Keyboard [Logitech K270] on usb-:00:14.0-1:2 [ 2161.362220] usb 1-4: new full-speed USB device number 49 using xhci_hcd [ 2161.531773] usb 1-4: New USB device found, idVendor=0403, idProduct=6001 [ 2161.531776] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 2161.531777] usb 1-4: Product: FT232R USB UART [ 2161.531778] usb 1-4: Manufacturer: FTDI [ 2161.531779] usb 1-4: SerialNumber: A5026SVG [ 2161.534527] ftdi_sio 1-4:1.0: FTDI USB Serial Device converter detected [ 2161.534555] usb 1-4: Detected FT232RL [ 2161.534693] usb 1-4: FTDI USB Serial Device converter now attached to ttyUSB0 [ 2166.918358] usb 2-5: new SuperSpeed USB device number 51 using xhci_hcd [ 2166.931989] usb 2-5: New USB device found, idVendor=05e3, idProduct=0616 [ 2166.931991] usb 2-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 2166.931993] usb 2-5: Product: USB3.0 Hub [ 2166.931994] usb 2-5: Manufacturer: GenesysLogic [ 2166.934945] hub 2-5:1.0: USB hub found [ 2166.935296] hub 2-5:1.0: 4 ports detected [ 2166.964195] usb 1-3: new high-speed USB device number 50 using xhci_hcd [ 2167.133745] usb 1-3: New USB device found, idVendor=05e3, idProduct=0610 [ 2167.133747] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 2167.133748] usb 1-3: Product: USB2.0 Hub [ 2167.133749] usb 1-3: Manufacturer: GenesysLogic [ 2167.134603] hub 1-3:1.0: USB hub found [ 2167.135113] hub 1-3:1.0: 4 ports detected [ 2168.893351] usb 2-2: new SuperSpeed USB device number 52 using xhci_hcd [ 2168.907015] usb 2-2: New USB device found, idVendor=05e3, idProduct=0616 [ 2168.907016] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 2168.907018] usb 2-2: Product: USB3.0 Hub [ 2168.907019] usb 2-2: Manufacturer: GenesysLogic [ 2168.909379] hub 2-2:1.0: USB hub found [ 2168.909642] hub 2-2:1.0: 4 ports detected [ 2168.960206] usb 1-2: new high-speed USB device number 57 using xhci_hcd [ 2169.129804] usb 1-2: New USB device found, idVendor=05e3, idProduct=0610 [ 2169.129806] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 2169.129808] usb 1-2: Product: USB2.0 Hub [ 2169.129809] usb 1-2: Manufacturer: GenesysLogic [ 2169.130662] hub 1-2:1.0: USB hub found [ 2169.131176] hub 1-2:1.0: 4 ports detected [ 2183.067332] usb 2-2.4: new SuperSpeed USB device number 53 using xhci_hcd [ 2183.078706] usb 2-2.4: LPM exit latency is zeroed, disabling LPM. [ 2183.079448] usb 2-2.4: New USB device found, idVendor=2560, idProduct=c112 [ 2183.079450] usb 2-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 2183.079451] usb 2-2.4: Product: See3CAM_11CUG [ 2183.079452] usb 2-2.4: Manufacturer: e-con Systems [ 2183.079453] usb 2-2.4: SerialNumber: 36145500 [ 2183.080210] uvcvideo: Found UVC 1.00 device See3CAM_11CUG (2560:c112) [ 2183.081248] uvcvideo 2-2.4:1.0: Entity type for entity Extension 3 was not initialized! [ 2183.081251] uvcvideo 2-2.4:1.0: Entity type for entity Processing 2 was not initialized! [ 2183.081252] uvcvideo 2-2.4:1.0: Entity type for entity Camera 1 was not initialized! [ 2183.081319] input: See3CAM_11CUG as /devices/pci:00/:00:14.0/usb2/2-2/2-2.4/2-2.4:1.0/input/input50 [ 2184.058638] hid-generic 0003:2560:C112.0021: hiddev0,hidraw3: USB HID v1.11 Device [e-con Systems See3CAM_11CUG] on usb-:00:14.0-2.4/input2 [ 2186.591331] usb 2-2.3: new SuperSpeed USB device number 54 using xhci_hcd [ 2186.602753] usb 2-2.3: LPM exit latency is zeroed, disabling LPM. [ 2186.603504] usb 2-2.3: New USB device found, idVendor=2560, idProduct=c112 [ 2186.603506] usb 2-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 2186.603507] usb 2-2.3: Product: See3CAM_11CUG [ 2186.603508] usb 2-2.3: Manufacturer: e-con Systems [ 2186.603509] usb 2-2.3: SerialNumber: 18045300 [ 2186.604288] uvcvideo: Found UVC 1.00 device See3CAM_11CUG (2560:c112) [ 2186.605335] uvcvideo 2-2.3:1.0
Re: USB kernel debug
Can you make a recommendation? Is there one you trust? On 05/16/16 16:19, Greg KH wrote: > On Mon, May 16, 2016 at 03:49:55PM -0700, Brian T. McKee wrote: >> Thanks Greg. It is a powered USB hub. The supplies have 2.5 amps to >> spread across three cameras. One of the hub's ports uses laptop power, >> but I'm not using that port. >> The USB 3.0 spec (according to wikipedia) requires that each port be >> capable of delivering 900 mA, so those power supplies seem a bit low >> (needs 200mA more). But I strongly doubt the cameras are pulling 900mA >> since they also work with USB 2.0 ports which specifies a much smaller >> current. I can measure it if I play with a soldering iron, but I'd >> rather not risk damaging a camera. > USB hubs suck rocks, I would strongly recommend getting another one that > you "know" will provide enough power to your devices. I've worked > with enough different ones to know that if there is a chance the power > drain can be exceeded, it will be. > > good luck! > > greg k-h -- 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 kernel debug
On 05/16/16 17:56, Greg KH wrote: > I recommend any of the hubs recommended here: > http://thewirecutter.com/reviews/best-usb-hubs/ > > Thanks Greg. I'm using the Sabrent HB-UMP3 which I would hope is related to or derived from the Sabrent they mention in thewirecutter article. -- 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 kernel debug
Hi Greg and Alan, I just booted windows 10 to see if it can handle the setup and it can't. The cameras lock up in similar ways to linux. A few frames display and then they lock up. It looks like some kind of hardware failure. I'm going to take another machine with four USB 3.0 ports on it and see if I can get it to work on there to see if it's my laptop that died, the USB hubs or the cameras. Sorry to hassle you guys. On 05/16/16 17:56, Greg KH wrote: > A: No. > Q: Should I include quotations after my reply? > > http://daringfireball.net/2007/07/on_top > > On Mon, May 16, 2016 at 04:58:46PM -0700, Brian T. McKee wrote: >> Can you make a recommendation? Is there one you trust? > I recommend any of the hubs recommended here: > http://thewirecutter.com/reviews/best-usb-hubs/ > > and have both the 7 and 10 port recommendations. > > hope this helps, > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: storage: onetouch: Fixed two space related coding style issues
This patch fixes checkpatch.pl warning in file onetouch.c
Signed-off-by: Tapan Prakash T
---
drivers/usb/storage/onetouch.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/storage/onetouch.c b/drivers/usb/storage/onetouch.c
index acc3d03..9097bd4 100644
--- a/drivers/usb/storage/onetouch.c
+++ b/drivers/usb/storage/onetouch.c
@@ -69,7 +69,7 @@ struct usb_onetouch {
vendorName, productName, useProtocol, useTransport, \
initFunction, flags) \
{ USB_DEVICE_VER(id_vendor, id_product, bcdDeviceMin, bcdDeviceMax), \
- .driver_info = (flags) }
+.driver_info = (flags) }
static struct usb_device_id onetouch_usb_ids[] = {
# include "unusual_onetouch.h"
@@ -125,7 +125,7 @@ static void usb_onetouch_irq(struct urb *urb)
input_sync(dev);
resubmit:
- retval = usb_submit_urb (urb, GFP_ATOMIC);
+ retval = usb_submit_urb(urb, GFP_ATOMIC);
if (retval)
dev_err(&dev->dev, "can't resubmit intr, %s-%s/input0, "
"retval %d\n", onetouch->udev->bus->bus_name,
--
1.9.1
--
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
unable to handle kernel NULL pointer dereference at usb_audio_probe
[ 21.434822] BUG: unable to handle kernel NULL pointer dereference at 0014 [ 21.435516] IP: [] usb_audio_probe+0x2ca/0x9a0 [snd_usb_audio] I have a PreSonus AudioBox iTwo causing this issue. I updated from torvalds git yesterday dmesg.output Description: Binary data
Re: unable to handle kernel NULL pointer dereference at usb_audio_probe
Ok looks like this fixed the dmesg bug report, and the hardware does now show up in relevant software, but it does not actually work. arecord reports this $ arecord -f cd -D plughw:2,0 -d 20 test.wav arecord: main:722: audio open error: No such device Which does make sense if the extra NULL check in the patch now never passes, media_snd_device_create is never reached. On Thu, Mar 24, 2016 at 1:45 PM, Greg KH wrote: > On Thu, Mar 24, 2016 at 01:34:32PM +, Ian T. Jacobsen wrote: >> [ 21.434822] BUG: unable to handle kernel NULL pointer dereference at >> 0014 [ 21.435516] IP: [] >> usb_audio_probe+0x2ca/0x9a0 [snd_usb_audio] >> >> I have a PreSonus AudioBox iTwo causing this issue. >> I updated from torvalds git yesterday > > A patch has been sent to the sound mailing list for this: > > http://lkml.kernel.org/g/1458045306-4170-1-git-send-email-nicsta...@gmail.com > > It solved the issue for me, please let the developers of it know if it > didn't work for you. > > thanks, > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: phy: msm: Move mach depndend code to platform data
From: "Ivan T. Ivanov"
This patch fix compilation error and is an intermediate step
before the addition of DeviceTree support for newer targets.
Fix suggested here: https://lkml.org/lkml/2013/6/19/381
Cc: David Brown
Cc: Daniel Walker
Cc: Bryan Huntsman
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Signed-off-by: Ivan T. Ivanov
---
arch/arm/mach-msm/board-msm7x30.c | 35 +++
arch/arm/mach-msm/board-qsd8x50.c | 34 +++
drivers/usb/phy/phy-msm-usb.c | 55 ++---
include/linux/usb/msm_hsusb.h |2 ++
4 files changed, 85 insertions(+), 41 deletions(-)
diff --git a/arch/arm/mach-msm/board-msm7x30.c
b/arch/arm/mach-msm/board-msm7x30.c
index db3d8c0..4df7daa 100644
--- a/arch/arm/mach-msm/board-msm7x30.c
+++ b/arch/arm/mach-msm/board-msm7x30.c
@@ -31,6 +31,7 @@
#include
#include
+#include
#include
#include
@@ -61,10 +62,44 @@ static int hsusb_phy_init_seq[] = {
-1
};
+static int hsusb_phy_link_clk_reset(struct clk *link_clk, bool assert)
+{
+ int ret;
+
+ if (assert) {
+ ret = clk_reset(link_clk, CLK_RESET_ASSERT);
+ if (ret)
+ pr_err("usb hs_clk assert failed\n");
+ } else {
+ ret = clk_reset(link_clk, CLK_RESET_DEASSERT);
+ if (ret)
+ pr_err("usb hs_clk deassert failed\n");
+ }
+ return ret;
+}
+
+static int hsusb_phy_clk_reset(struct clk *phy_clk)
+{
+ int ret;
+
+ ret = clk_reset(phy_clk, CLK_RESET_ASSERT);
+ if (ret) {
+ pr_err("usb phy clk assert failed\n");
+ return ret;
+ }
+ usleep_range(1, 12000);
+ ret = clk_reset(phy_clk, CLK_RESET_DEASSERT);
+ if (ret)
+ pr_err("usb phy clk deassert failed\n");
+ return ret;
+}
+
static struct msm_otg_platform_data msm_otg_pdata = {
.phy_init_seq = hsusb_phy_init_seq,
.mode = USB_PERIPHERAL,
.otg_control= OTG_PHY_CONTROL,
+ .phy_link_clk_reset = hsusb_phy_link_clk_reset,
+ .phy_phy_clk_reset = hsusb_phy_clk_reset,
};
struct msm_gpiomux_config msm_gpiomux_configs[GPIOMUX_NGPIOS] = {
diff --git a/arch/arm/mach-msm/board-qsd8x50.c
b/arch/arm/mach-msm/board-qsd8x50.c
index f14a73d..d3d92ab 100644
--- a/arch/arm/mach-msm/board-qsd8x50.c
+++ b/arch/arm/mach-msm/board-qsd8x50.c
@@ -82,10 +82,44 @@ static int hsusb_phy_init_seq[] = {
-1
};
+static int hsusb_phy_link_clk_reset(struct clk *link_clk, bool assert)
+{
+ int ret;
+
+ if (assert) {
+ ret = clk_reset(link_clk, CLK_RESET_ASSERT);
+ if (ret)
+ pr_err("usb hs_clk assert failed\n");
+ } else {
+ ret = clk_reset(link_clk, CLK_RESET_DEASSERT);
+ if (ret)
+ pr_err("usb hs_clk deassert failed\n");
+ }
+ return ret;
+}
+
+static int hsusb_phy_clk_reset(struct clk *phy_clk)
+{
+ int ret;
+
+ ret = clk_reset(phy_clk, CLK_RESET_ASSERT);
+ if (ret) {
+ pr_err("usb phy clk assert failed\n");
+ return ret;
+ }
+ usleep_range(1, 12000);
+ ret = clk_reset(phy_clk, CLK_RESET_DEASSERT);
+ if (ret)
+ pr_err("usb phy clk deassert failed\n");
+ return ret;
+}
+
static struct msm_otg_platform_data msm_otg_pdata = {
.phy_init_seq = hsusb_phy_init_seq,
.mode = USB_PERIPHERAL,
.otg_control= OTG_PHY_CONTROL,
+ .phy_link_clk_reset = hsusb_phy_link_clk_reset,
+ .phy_phy_clk_reset = hsusb_phy_clk_reset,
};
static struct platform_device *devices[] __initdata = {
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index d08f334..ab1b880 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -40,8 +40,6 @@
#include
#include
-#include
-
#define MSM_USB_BASE (motg->regs)
#define DRIVER_NAME"msm_otg"
@@ -306,51 +304,20 @@ static void ulpi_init(struct msm_otg *motg)
}
}
-static int msm_otg_link_clk_reset(struct msm_otg *motg, bool assert)
-{
- int ret;
-
- if (assert) {
- ret = clk_reset(motg->clk, CLK_RESET_ASSERT);
- if (ret)
- dev_err(motg->phy.dev, "usb hs_clk assert failed\n");
- } else {
- ret = clk_reset(motg->clk, CLK_RESET_DEASSERT);
- if (ret)
- dev_err(motg->phy.dev, "usb hs_clk deassert failed\n");
- }
- return ret;
-}
-
-static int msm_otg_ph
[PATCH 7/7] usb: phy: msm: Lindent the code
From: "Ivan T. Ivanov"
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-usb@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/phy/phy-msm-usb.c | 99 ++---
1 file changed, 52 insertions(+), 47 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 6d05085..111f454 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -45,18 +45,18 @@
#define ULPI_IO_TIMEOUT_USEC (10 * 1000)
-#define USB_PHY_3P3_VOL_MIN305 /* uV */
-#define USB_PHY_3P3_VOL_MAX330 /* uV */
+#define USB_PHY_3P3_VOL_MIN305 /* uV */
+#define USB_PHY_3P3_VOL_MAX330 /* uV */
#define USB_PHY_3P3_HPM_LOAD 5 /* uA */
#define USB_PHY_3P3_LPM_LOAD 4000/* uA */
-#define USB_PHY_1P8_VOL_MIN180 /* uV */
-#define USB_PHY_1P8_VOL_MAX180 /* uV */
+#define USB_PHY_1P8_VOL_MIN180 /* uV */
+#define USB_PHY_1P8_VOL_MAX180 /* uV */
#define USB_PHY_1P8_HPM_LOAD 5 /* uA */
#define USB_PHY_1P8_LPM_LOAD 4000/* uA */
-#define USB_PHY_VDD_DIG_VOL_MIN100 /* uV */
-#define USB_PHY_VDD_DIG_VOL_MAX132 /* uV */
+#define USB_PHY_VDD_DIG_VOL_MIN100 /* uV */
+#define USB_PHY_VDD_DIG_VOL_MAX132 /* uV */
static int msm_hsusb_init_vddcx(struct msm_otg *motg, int init)
{
@@ -64,8 +64,8 @@ static int msm_hsusb_init_vddcx(struct msm_otg *motg, int
init)
if (init) {
ret = regulator_set_voltage(motg->vddcx,
- USB_PHY_VDD_DIG_VOL_MIN,
- USB_PHY_VDD_DIG_VOL_MAX);
+ USB_PHY_VDD_DIG_VOL_MIN,
+ USB_PHY_VDD_DIG_VOL_MAX);
if (ret) {
dev_err(motg->phy.dev, "Cannot set vddcx voltage\n");
return ret;
@@ -73,15 +73,17 @@ static int msm_hsusb_init_vddcx(struct msm_otg *motg, int
init)
ret = regulator_enable(motg->vddcx);
if (ret)
- dev_err(motg->phy.dev, "unable to enable hsusb
vddcx\n");
+ dev_err(motg->phy.dev,
+ "unable to enable hsusb vddcx\n");
} else {
ret = regulator_set_voltage(motg->vddcx, 0,
- USB_PHY_VDD_DIG_VOL_MAX);
+ USB_PHY_VDD_DIG_VOL_MAX);
if (ret)
dev_err(motg->phy.dev, "Cannot set vddcx voltage\n");
ret = regulator_disable(motg->vddcx);
if (ret)
- dev_err(motg->phy.dev, "unable to disable hsusb
vddcx\n");
+ dev_err(motg->phy.dev,
+ "unable to disable hsusb vddcx\n");
}
return ret;
@@ -93,26 +95,28 @@ static int msm_hsusb_ldo_init(struct msm_otg *motg, int
init)
if (init) {
rc = regulator_set_voltage(motg->v3p3, USB_PHY_3P3_VOL_MIN,
- USB_PHY_3P3_VOL_MAX);
+ USB_PHY_3P3_VOL_MAX);
if (rc) {
dev_err(motg->phy.dev, "Cannot set v3p3 voltage\n");
return rc;
}
rc = regulator_enable(motg->v3p3);
if (rc) {
- dev_err(motg->phy.dev, "unable to enable the hsusb
3p3\n");
+ dev_err(motg->phy.dev,
+ "unable to enable the hsusb 3p3\n");
return rc;
}
rc = regulator_set_voltage(motg->v1p8, USB_PHY_1P8_VOL_MIN,
- USB_PHY_1P8_VOL_MAX);
+ USB_PHY_1P8_VOL_MAX);
if (rc) {
dev_err(motg->phy.dev, "Cannot set v1p8 voltage\n");
goto disable_3p3;
}
rc = regulator_enable(motg->v1p8);
if (rc) {
- dev_err(motg->phy.dev, "unable to enable the hsusb
1p8\n");
+ dev_err(motg->phy.dev,
+ "unable to enable the hsusb 1p8\n");
goto disable_3p3;
}
@@ -156,26 +160,26 @@ static int msm_hsusb_ldo_set_mode(struct msm_otg *motg,
int on)
if (on) {
ret = regulator_set_optimum_mode(motg->v1p8,
- USB_PHY_1P8_HPM_LOAD);
+USB_PHY_1P8_HPM_LOAD);
[PATCH 6/7] usb: phy: msm: Fix WARNING: Prefer seq_puts to seq_printf
From: "Ivan T. Ivanov"
This fixes checkpatch.pl warnings.
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-usb@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/phy/phy-msm-usb.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 41938e6..6d05085 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -1204,13 +1204,13 @@ static int msm_otg_mode_show(struct seq_file *s, void
*unused)
switch (otg->phy->state) {
case OTG_STATE_A_HOST:
- seq_printf(s, "host\n");
+ seq_puts(s, "host\n");
break;
case OTG_STATE_B_PERIPHERAL:
- seq_printf(s, "peripheral\n");
+ seq_puts(s, "peripheral\n");
break;
default:
- seq_printf(s, "none\n");
+ seq_puts(s, "none\n");
break;
}
--
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 3/7] usb: phy: msm: Move regulator usage to managed resource allocation
From: "Ivan T. Ivanov"
This patch move global regulators variables to driver state
structire and move allocation of the regulators to be devm managed.
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-usb@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/phy/phy-msm-usb.c | 111 +++--
include/linux/usb/msm_hsusb.h |3 ++
2 files changed, 53 insertions(+), 61 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index cc37f5e..8289270 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -58,47 +58,32 @@
#define USB_PHY_VDD_DIG_VOL_MIN100 /* uV */
#define USB_PHY_VDD_DIG_VOL_MAX132 /* uV */
-static struct regulator *hsusb_3p3;
-static struct regulator *hsusb_1p8;
-static struct regulator *hsusb_vddcx;
-
static int msm_hsusb_init_vddcx(struct msm_otg *motg, int init)
{
int ret = 0;
if (init) {
- hsusb_vddcx = regulator_get(motg->phy.dev, "HSUSB_VDDCX");
- if (IS_ERR(hsusb_vddcx)) {
- dev_err(motg->phy.dev, "unable to get hsusb vddcx\n");
- return PTR_ERR(hsusb_vddcx);
- }
-
- ret = regulator_set_voltage(hsusb_vddcx,
+ ret = regulator_set_voltage(motg->vddcx,
USB_PHY_VDD_DIG_VOL_MIN,
USB_PHY_VDD_DIG_VOL_MAX);
if (ret) {
dev_err(motg->phy.dev, "unable to set the voltage "
"for hsusb vddcx\n");
- regulator_put(hsusb_vddcx);
return ret;
}
- ret = regulator_enable(hsusb_vddcx);
- if (ret) {
+ ret = regulator_enable(motg->vddcx);
+ if (ret)
dev_err(motg->phy.dev, "unable to enable hsusb
vddcx\n");
- regulator_put(hsusb_vddcx);
- }
} else {
- ret = regulator_set_voltage(hsusb_vddcx, 0,
+ ret = regulator_set_voltage(motg->vddcx, 0,
USB_PHY_VDD_DIG_VOL_MAX);
if (ret)
dev_err(motg->phy.dev, "unable to set the voltage "
"for hsusb vddcx\n");
- ret = regulator_disable(hsusb_vddcx);
+ ret = regulator_disable(motg->vddcx);
if (ret)
dev_err(motg->phy.dev, "unable to disable hsusb
vddcx\n");
-
- regulator_put(hsusb_vddcx);
}
return ret;
@@ -109,59 +94,44 @@ static int msm_hsusb_ldo_init(struct msm_otg *motg, int
init)
int rc = 0;
if (init) {
- hsusb_3p3 = regulator_get(motg->phy.dev, "HSUSB_3p3");
- if (IS_ERR(hsusb_3p3)) {
- dev_err(motg->phy.dev, "unable to get hsusb 3p3\n");
- return PTR_ERR(hsusb_3p3);
- }
-
- rc = regulator_set_voltage(hsusb_3p3, USB_PHY_3P3_VOL_MIN,
+ rc = regulator_set_voltage(motg->v3p3, USB_PHY_3P3_VOL_MIN,
USB_PHY_3P3_VOL_MAX);
if (rc) {
dev_err(motg->phy.dev, "unable to set voltage level "
"for hsusb 3p3\n");
- goto put_3p3;
+ return rc;
}
- rc = regulator_enable(hsusb_3p3);
+ rc = regulator_enable(motg->v3p3);
if (rc) {
dev_err(motg->phy.dev, "unable to enable the hsusb
3p3\n");
- goto put_3p3;
- }
- hsusb_1p8 = regulator_get(motg->phy.dev, "HSUSB_1p8");
- if (IS_ERR(hsusb_1p8)) {
- dev_err(motg->phy.dev, "unable to get hsusb 1p8\n");
- rc = PTR_ERR(hsusb_1p8);
- goto disable_3p3;
+ return rc;
}
- rc = regulator_set_voltage(hsusb_1p8, USB_PHY_1P8_VOL_MIN,
+
+ rc = regulator_set_voltage(motg->v1p8, USB_PHY_1P8_VOL_MIN,
USB_PHY_1P8_VOL_MAX);
if (rc) {
dev_err(motg->phy.dev, "unable to set voltage level "
"for hsusb 1p8\n");
- goto put_1p8;
+ goto disable_3p3;
}
- rc = regulator_enable(hsusb_1p8);
+ rc = regulator_enable(motg->
[PATCH 5/7] usb: phy: msm: Fix WARNING: quoted string split across lines
From: "Ivan T. Ivanov"
This fixes checkpatch.pl warnings.
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-usb@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/phy/phy-msm-usb.c | 33 +++--
1 file changed, 11 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 0e7d7ab..41938e6 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -67,8 +67,7 @@ static int msm_hsusb_init_vddcx(struct msm_otg *motg, int
init)
USB_PHY_VDD_DIG_VOL_MIN,
USB_PHY_VDD_DIG_VOL_MAX);
if (ret) {
- dev_err(motg->phy.dev, "unable to set the voltage "
- "for hsusb vddcx\n");
+ dev_err(motg->phy.dev, "Cannot set vddcx voltage\n");
return ret;
}
@@ -79,8 +78,7 @@ static int msm_hsusb_init_vddcx(struct msm_otg *motg, int
init)
ret = regulator_set_voltage(motg->vddcx, 0,
USB_PHY_VDD_DIG_VOL_MAX);
if (ret)
- dev_err(motg->phy.dev, "unable to set the voltage "
- "for hsusb vddcx\n");
+ dev_err(motg->phy.dev, "Cannot set vddcx voltage\n");
ret = regulator_disable(motg->vddcx);
if (ret)
dev_err(motg->phy.dev, "unable to disable hsusb
vddcx\n");
@@ -97,8 +95,7 @@ static int msm_hsusb_ldo_init(struct msm_otg *motg, int init)
rc = regulator_set_voltage(motg->v3p3, USB_PHY_3P3_VOL_MIN,
USB_PHY_3P3_VOL_MAX);
if (rc) {
- dev_err(motg->phy.dev, "unable to set voltage level "
- "for hsusb 3p3\n");
+ dev_err(motg->phy.dev, "Cannot set v3p3 voltage\n");
return rc;
}
rc = regulator_enable(motg->v3p3);
@@ -110,8 +107,7 @@ static int msm_hsusb_ldo_init(struct msm_otg *motg, int
init)
rc = regulator_set_voltage(motg->v1p8, USB_PHY_1P8_VOL_MIN,
USB_PHY_1P8_VOL_MAX);
if (rc) {
- dev_err(motg->phy.dev, "unable to set voltage level "
- "for hsusb 1p8\n");
+ dev_err(motg->phy.dev, "Cannot set v1p8 voltage\n");
goto disable_3p3;
}
rc = regulator_enable(motg->v1p8);
@@ -144,8 +140,7 @@ static int msm_hsusb_config_vddcx(struct msm_otg *motg, int
high)
ret = regulator_set_voltage(motg->vddcx, min_vol, max_vol);
if (ret) {
- pr_err("%s: unable to set the voltage for regulator "
- "HSUSB_VDDCX\n", __func__);
+ dev_err(motg->phy.dev, "Cannot set vddcx voltage\n");
return ret;
}
@@ -163,15 +158,13 @@ static int msm_hsusb_ldo_set_mode(struct msm_otg *motg,
int on)
ret = regulator_set_optimum_mode(motg->v1p8,
USB_PHY_1P8_HPM_LOAD);
if (ret < 0) {
- pr_err("%s: Unable to set HPM of the regulator "
- "HSUSB_1p8\n", __func__);
+ pr_err("Could not set HPM for v1p8\n");
return ret;
}
ret = regulator_set_optimum_mode(motg->v3p3,
USB_PHY_3P3_HPM_LOAD);
if (ret < 0) {
- pr_err("%s: Unable to set HPM of the regulator "
- "HSUSB_3p3\n", __func__);
+ pr_err("Could not set HPM for v3p3\n");
regulator_set_optimum_mode(motg->v1p8,
USB_PHY_1P8_LPM_LOAD);
return ret;
@@ -180,13 +173,11 @@ static int msm_hsusb_ldo_set_mode(struct msm_otg *motg,
int on)
ret = regulator_set_optimum_mode(motg->v1p8,
USB_PHY_1P8_LPM_LOAD);
if (ret < 0)
- pr_err("%s: Unable to set LPM of the regulator "
- "HSUSB_1p8\n", __func__);
+ pr_err("Could not set LPM for v1p8\n");
ret = regulator_set_optimum_mode(motg->v3p3,
USB_PHY_3P3_LPM_LOAD);
[PATCH 2/7] usb: phy: msm: Migrate to Managed Device Resource allocation
From: "Ivan T. Ivanov"
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-usb@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/phy/phy-msm-usb.c | 78 +++--
1 file changed, 20 insertions(+), 58 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index ab1b880..cc37f5e 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -1397,13 +1397,14 @@ static int __init msm_otg_probe(struct platform_device
*pdev)
return -ENODEV;
}
- motg = kzalloc(sizeof(struct msm_otg), GFP_KERNEL);
+ motg = devm_kzalloc(&pdev->dev, sizeof(*motg), GFP_KERNEL);
if (!motg) {
dev_err(&pdev->dev, "unable to allocate msm_otg\n");
return -ENOMEM;
}
- motg->phy.otg = kzalloc(sizeof(struct usb_otg), GFP_KERNEL);
+ motg->phy.otg = devm_kzalloc(&pdev->dev, sizeof(*motg->phy.otg),
+GFP_KERNEL);
if (!motg->phy.otg) {
dev_err(&pdev->dev, "unable to allocate msm_otg\n");
return -ENOMEM;
@@ -1413,18 +1414,16 @@ static int __init msm_otg_probe(struct platform_device
*pdev)
phy = &motg->phy;
phy->dev = &pdev->dev;
- motg->phy_reset_clk = clk_get(&pdev->dev, "usb_phy_clk");
+ motg->phy_reset_clk = devm_clk_get(&pdev->dev, "usb_phy_clk");
if (IS_ERR(motg->phy_reset_clk)) {
dev_err(&pdev->dev, "failed to get usb_phy_clk\n");
- ret = PTR_ERR(motg->phy_reset_clk);
- goto free_motg;
+ return PTR_ERR(motg->phy_reset_clk);
}
- motg->clk = clk_get(&pdev->dev, "usb_hs_clk");
+ motg->clk = devm_clk_get(&pdev->dev, "usb_hs_clk");
if (IS_ERR(motg->clk)) {
dev_err(&pdev->dev, "failed to get usb_hs_clk\n");
- ret = PTR_ERR(motg->clk);
- goto put_phy_reset_clk;
+ return PTR_ERR(motg->clk);
}
clk_set_rate(motg->clk, 6000);
@@ -1436,21 +1435,19 @@ static int __init msm_otg_probe(struct platform_device
*pdev)
* on pclk source
*/
if (motg->pdata->pclk_src_name) {
- motg->pclk_src = clk_get(&pdev->dev,
+ motg->pclk_src = devm_clk_get(&pdev->dev,
motg->pdata->pclk_src_name);
if (IS_ERR(motg->pclk_src))
- goto put_clk;
+ return PTR_ERR(motg->pclk_src);
clk_set_rate(motg->pclk_src, INT_MAX);
clk_prepare_enable(motg->pclk_src);
} else
motg->pclk_src = ERR_PTR(-ENOENT);
-
- motg->pclk = clk_get(&pdev->dev, "usb_hs_pclk");
+ motg->pclk = devm_clk_get(&pdev->dev, "usb_hs_pclk");
if (IS_ERR(motg->pclk)) {
dev_err(&pdev->dev, "failed to get usb_hs_pclk\n");
- ret = PTR_ERR(motg->pclk);
- goto put_pclk_src;
+ return PTR_ERR(motg->pclk);
}
/*
@@ -1458,30 +1455,27 @@ static int __init msm_otg_probe(struct platform_device
*pdev)
* clock is introduced to remove the dependency on AXI
* bus frequency.
*/
- motg->core_clk = clk_get(&pdev->dev, "usb_hs_core_clk");
+ motg->core_clk = devm_clk_get(&pdev->dev, "usb_hs_core_clk");
if (IS_ERR(motg->core_clk))
motg->core_clk = NULL;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(&pdev->dev, "failed to get platform resource mem\n");
- ret = -ENODEV;
- goto put_core_clk;
+ return -ENODEV;
}
- motg->regs = ioremap(res->start, resource_size(res));
+ motg->regs = devm_ioremap_resource(&pdev->dev, res);
if (!motg->regs) {
dev_err(&pdev->dev, "ioremap failed\n");
- ret = -ENOMEM;
- goto put_core_clk;
+ return PTR_ERR(motg->regs);
}
dev_info(&pdev->dev, "OTG regs = %p\n", motg->regs);
motg->irq = platform_get_irq(pdev, 0);
- if (!motg->irq) {
+ if (motg->irq < 0) {
dev_err(&pdev->dev, "platform_get_irq failed\n");
- ret = -ENODEV;
- goto free_regs;
+ return motg->irq;
}
clk_prepare_enabl
[PATCH 4/7] usb: phy: msm: Remove unnecessarily check for valid regulators.
From: "Ivan T. Ivanov"
Whether regulators are available or not is checked at driver
probe. If they are not available driver will refuse to load,
so no need to check them again.
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-usb@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/phy/phy-msm-usb.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 8289270..0e7d7ab 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -159,16 +159,6 @@ static int msm_hsusb_ldo_set_mode(struct msm_otg *motg,
int on)
{
int ret = 0;
- if (!motg->v1p8 || IS_ERR(motg->v1p8)) {
- pr_err("%s: HSUSB_1p8 is not initialized\n", __func__);
- return -ENODEV;
- }
-
- if (!motg->v3p3 || IS_ERR(motg->v3p3)) {
- pr_err("%s: HSUSB_3p3 is not initialized\n", __func__);
- return -ENODEV;
- }
-
if (on) {
ret = regulator_set_optimum_mode(motg->v1p8,
USB_PHY_1P8_HPM_LOAD);
--
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 v2 2/7] usb: phy: msm: Migrate to Managed Device Resource allocation
From: "Ivan T. Ivanov"
Use managed device resources to clean up the probe/remove
and get DT support for free.
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/phy/phy-msm-usb.c | 78 +++--
1 file changed, 20 insertions(+), 58 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index ab1b880..cc37f5e 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -1397,13 +1397,14 @@ static int __init msm_otg_probe(struct platform_device
*pdev)
return -ENODEV;
}
- motg = kzalloc(sizeof(struct msm_otg), GFP_KERNEL);
+ motg = devm_kzalloc(&pdev->dev, sizeof(*motg), GFP_KERNEL);
if (!motg) {
dev_err(&pdev->dev, "unable to allocate msm_otg\n");
return -ENOMEM;
}
- motg->phy.otg = kzalloc(sizeof(struct usb_otg), GFP_KERNEL);
+ motg->phy.otg = devm_kzalloc(&pdev->dev, sizeof(*motg->phy.otg),
+GFP_KERNEL);
if (!motg->phy.otg) {
dev_err(&pdev->dev, "unable to allocate msm_otg\n");
return -ENOMEM;
@@ -1413,18 +1414,16 @@ static int __init msm_otg_probe(struct platform_device
*pdev)
phy = &motg->phy;
phy->dev = &pdev->dev;
- motg->phy_reset_clk = clk_get(&pdev->dev, "usb_phy_clk");
+ motg->phy_reset_clk = devm_clk_get(&pdev->dev, "usb_phy_clk");
if (IS_ERR(motg->phy_reset_clk)) {
dev_err(&pdev->dev, "failed to get usb_phy_clk\n");
- ret = PTR_ERR(motg->phy_reset_clk);
- goto free_motg;
+ return PTR_ERR(motg->phy_reset_clk);
}
- motg->clk = clk_get(&pdev->dev, "usb_hs_clk");
+ motg->clk = devm_clk_get(&pdev->dev, "usb_hs_clk");
if (IS_ERR(motg->clk)) {
dev_err(&pdev->dev, "failed to get usb_hs_clk\n");
- ret = PTR_ERR(motg->clk);
- goto put_phy_reset_clk;
+ return PTR_ERR(motg->clk);
}
clk_set_rate(motg->clk, 6000);
@@ -1436,21 +1435,19 @@ static int __init msm_otg_probe(struct platform_device
*pdev)
* on pclk source
*/
if (motg->pdata->pclk_src_name) {
- motg->pclk_src = clk_get(&pdev->dev,
+ motg->pclk_src = devm_clk_get(&pdev->dev,
motg->pdata->pclk_src_name);
if (IS_ERR(motg->pclk_src))
- goto put_clk;
+ return PTR_ERR(motg->pclk_src);
clk_set_rate(motg->pclk_src, INT_MAX);
clk_prepare_enable(motg->pclk_src);
} else
motg->pclk_src = ERR_PTR(-ENOENT);
-
- motg->pclk = clk_get(&pdev->dev, "usb_hs_pclk");
+ motg->pclk = devm_clk_get(&pdev->dev, "usb_hs_pclk");
if (IS_ERR(motg->pclk)) {
dev_err(&pdev->dev, "failed to get usb_hs_pclk\n");
- ret = PTR_ERR(motg->pclk);
- goto put_pclk_src;
+ return PTR_ERR(motg->pclk);
}
/*
@@ -1458,30 +1455,27 @@ static int __init msm_otg_probe(struct platform_device
*pdev)
* clock is introduced to remove the dependency on AXI
* bus frequency.
*/
- motg->core_clk = clk_get(&pdev->dev, "usb_hs_core_clk");
+ motg->core_clk = devm_clk_get(&pdev->dev, "usb_hs_core_clk");
if (IS_ERR(motg->core_clk))
motg->core_clk = NULL;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(&pdev->dev, "failed to get platform resource mem\n");
- ret = -ENODEV;
- goto put_core_clk;
+ return -ENODEV;
}
- motg->regs = ioremap(res->start, resource_size(res));
+ motg->regs = devm_ioremap_resource(&pdev->dev, res);
if (!motg->regs) {
dev_err(&pdev->dev, "ioremap failed\n");
- ret = -ENOMEM;
- goto put_core_clk;
+ return PTR_ERR(motg->regs);
}
dev_info(&pdev->dev, "OTG regs = %p\n", motg->regs);
motg->irq = platform_get_irq(pdev, 0);
- if (!motg->irq) {
+ if (motg->irq < 0) {
dev_err(&pdev->dev, "platform_get_irq failed\n");
- ret = -ENODEV;
- goto free_regs;
+ return motg->irq;
}
clk_prepare_enabl
[PATCH v2 7/7] usb: phy: msm: Lindent the code
From: "Ivan T. Ivanov"
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/phy/phy-msm-usb.c | 99 ++---
1 file changed, 52 insertions(+), 47 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 6d05085..111f454 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -45,18 +45,18 @@
#define ULPI_IO_TIMEOUT_USEC (10 * 1000)
-#define USB_PHY_3P3_VOL_MIN305 /* uV */
-#define USB_PHY_3P3_VOL_MAX330 /* uV */
+#define USB_PHY_3P3_VOL_MIN305 /* uV */
+#define USB_PHY_3P3_VOL_MAX330 /* uV */
#define USB_PHY_3P3_HPM_LOAD 5 /* uA */
#define USB_PHY_3P3_LPM_LOAD 4000/* uA */
-#define USB_PHY_1P8_VOL_MIN180 /* uV */
-#define USB_PHY_1P8_VOL_MAX180 /* uV */
+#define USB_PHY_1P8_VOL_MIN180 /* uV */
+#define USB_PHY_1P8_VOL_MAX180 /* uV */
#define USB_PHY_1P8_HPM_LOAD 5 /* uA */
#define USB_PHY_1P8_LPM_LOAD 4000/* uA */
-#define USB_PHY_VDD_DIG_VOL_MIN100 /* uV */
-#define USB_PHY_VDD_DIG_VOL_MAX132 /* uV */
+#define USB_PHY_VDD_DIG_VOL_MIN100 /* uV */
+#define USB_PHY_VDD_DIG_VOL_MAX132 /* uV */
static int msm_hsusb_init_vddcx(struct msm_otg *motg, int init)
{
@@ -64,8 +64,8 @@ static int msm_hsusb_init_vddcx(struct msm_otg *motg, int
init)
if (init) {
ret = regulator_set_voltage(motg->vddcx,
- USB_PHY_VDD_DIG_VOL_MIN,
- USB_PHY_VDD_DIG_VOL_MAX);
+ USB_PHY_VDD_DIG_VOL_MIN,
+ USB_PHY_VDD_DIG_VOL_MAX);
if (ret) {
dev_err(motg->phy.dev, "Cannot set vddcx voltage\n");
return ret;
@@ -73,15 +73,17 @@ static int msm_hsusb_init_vddcx(struct msm_otg *motg, int
init)
ret = regulator_enable(motg->vddcx);
if (ret)
- dev_err(motg->phy.dev, "unable to enable hsusb
vddcx\n");
+ dev_err(motg->phy.dev,
+ "unable to enable hsusb vddcx\n");
} else {
ret = regulator_set_voltage(motg->vddcx, 0,
- USB_PHY_VDD_DIG_VOL_MAX);
+ USB_PHY_VDD_DIG_VOL_MAX);
if (ret)
dev_err(motg->phy.dev, "Cannot set vddcx voltage\n");
ret = regulator_disable(motg->vddcx);
if (ret)
- dev_err(motg->phy.dev, "unable to disable hsusb
vddcx\n");
+ dev_err(motg->phy.dev,
+ "unable to disable hsusb vddcx\n");
}
return ret;
@@ -93,26 +95,28 @@ static int msm_hsusb_ldo_init(struct msm_otg *motg, int
init)
if (init) {
rc = regulator_set_voltage(motg->v3p3, USB_PHY_3P3_VOL_MIN,
- USB_PHY_3P3_VOL_MAX);
+ USB_PHY_3P3_VOL_MAX);
if (rc) {
dev_err(motg->phy.dev, "Cannot set v3p3 voltage\n");
return rc;
}
rc = regulator_enable(motg->v3p3);
if (rc) {
- dev_err(motg->phy.dev, "unable to enable the hsusb
3p3\n");
+ dev_err(motg->phy.dev,
+ "unable to enable the hsusb 3p3\n");
return rc;
}
rc = regulator_set_voltage(motg->v1p8, USB_PHY_1P8_VOL_MIN,
- USB_PHY_1P8_VOL_MAX);
+ USB_PHY_1P8_VOL_MAX);
if (rc) {
dev_err(motg->phy.dev, "Cannot set v1p8 voltage\n");
goto disable_3p3;
}
rc = regulator_enable(motg->v1p8);
if (rc) {
- dev_err(motg->phy.dev, "unable to enable the hsusb
1p8\n");
+ dev_err(motg->phy.dev,
+ "unable to enable the hsusb 1p8\n");
goto disable_3p3;
}
@@ -156,26 +160,26 @@ static int msm_hsusb_ldo_set_mode(struct msm_otg *motg,
int on)
if (on) {
ret = regulator_set_optimum_mode(motg->v1p8,
- USB_PHY_1P8_HPM_LOAD);
+USB_PHY_1P8_HPM_LOAD);
if (ret < 0) {
pr_err("Could not set HPM for v1p8\n");
return ret;
}
[PATCH v2 4/7] usb: phy: msm: Remove unnecessarily check for valid regulators.
From: "Ivan T. Ivanov"
Whether regulators are available or not is checked at driver
probe. If they are not available driver will refuse to load,
so no need to check them again.
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/phy/phy-msm-usb.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 8289270..0e7d7ab 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -159,16 +159,6 @@ static int msm_hsusb_ldo_set_mode(struct msm_otg *motg,
int on)
{
int ret = 0;
- if (!motg->v1p8 || IS_ERR(motg->v1p8)) {
- pr_err("%s: HSUSB_1p8 is not initialized\n", __func__);
- return -ENODEV;
- }
-
- if (!motg->v3p3 || IS_ERR(motg->v3p3)) {
- pr_err("%s: HSUSB_3p3 is not initialized\n", __func__);
- return -ENODEV;
- }
-
if (on) {
ret = regulator_set_optimum_mode(motg->v1p8,
USB_PHY_1P8_HPM_LOAD);
--
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 v2 0/7] usb: phy: msm: Fixes and cleanups
From: "Ivan T. Ivanov" Changes since first version. * Extend commit messages a little bit. Following patches make initial cleanup of usb phy found in the Qualcomm chipsets. Changes include: * Build time error fix. * Move driver to Managed Device Resource allocation. * Checkpatch warnings and error fixes * Removed usage of global regulators variables. Ivan T. Ivanov (7): usb: phy: msm: Move mach depndend code to platform data usb: phy: msm: Migrate to Managed Device Resource allocation usb: phy: msm: Move regulator usage to managed resource allocation usb: phy: msm: Remove unnecessarily check for valid regulators. usb: phy: msm: Fix WARNING: quoted string split across lines usb: phy: msm: Fix WARNING: Prefer seq_puts to seq_printf usb: phy: msm: Lindent the code arch/arm/mach-msm/board-msm7x30.c | 35 arch/arm/mach-msm/board-qsd8x50.c | 34 drivers/usb/phy/phy-msm-usb.c | 384 ++--- include/linux/usb/msm_hsusb.h |5 + 4 files changed, 220 insertions(+), 238 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/7] usb: phy: msm: Move regulator usage to managed resource allocation
From: "Ivan T. Ivanov"
This patch move global regulators variables to driver state
structire and move allocation of the regulators to be devm managed.
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/phy/phy-msm-usb.c | 111 +++--
include/linux/usb/msm_hsusb.h |3 ++
2 files changed, 53 insertions(+), 61 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index cc37f5e..8289270 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -58,47 +58,32 @@
#define USB_PHY_VDD_DIG_VOL_MIN100 /* uV */
#define USB_PHY_VDD_DIG_VOL_MAX132 /* uV */
-static struct regulator *hsusb_3p3;
-static struct regulator *hsusb_1p8;
-static struct regulator *hsusb_vddcx;
-
static int msm_hsusb_init_vddcx(struct msm_otg *motg, int init)
{
int ret = 0;
if (init) {
- hsusb_vddcx = regulator_get(motg->phy.dev, "HSUSB_VDDCX");
- if (IS_ERR(hsusb_vddcx)) {
- dev_err(motg->phy.dev, "unable to get hsusb vddcx\n");
- return PTR_ERR(hsusb_vddcx);
- }
-
- ret = regulator_set_voltage(hsusb_vddcx,
+ ret = regulator_set_voltage(motg->vddcx,
USB_PHY_VDD_DIG_VOL_MIN,
USB_PHY_VDD_DIG_VOL_MAX);
if (ret) {
dev_err(motg->phy.dev, "unable to set the voltage "
"for hsusb vddcx\n");
- regulator_put(hsusb_vddcx);
return ret;
}
- ret = regulator_enable(hsusb_vddcx);
- if (ret) {
+ ret = regulator_enable(motg->vddcx);
+ if (ret)
dev_err(motg->phy.dev, "unable to enable hsusb
vddcx\n");
- regulator_put(hsusb_vddcx);
- }
} else {
- ret = regulator_set_voltage(hsusb_vddcx, 0,
+ ret = regulator_set_voltage(motg->vddcx, 0,
USB_PHY_VDD_DIG_VOL_MAX);
if (ret)
dev_err(motg->phy.dev, "unable to set the voltage "
"for hsusb vddcx\n");
- ret = regulator_disable(hsusb_vddcx);
+ ret = regulator_disable(motg->vddcx);
if (ret)
dev_err(motg->phy.dev, "unable to disable hsusb
vddcx\n");
-
- regulator_put(hsusb_vddcx);
}
return ret;
@@ -109,59 +94,44 @@ static int msm_hsusb_ldo_init(struct msm_otg *motg, int
init)
int rc = 0;
if (init) {
- hsusb_3p3 = regulator_get(motg->phy.dev, "HSUSB_3p3");
- if (IS_ERR(hsusb_3p3)) {
- dev_err(motg->phy.dev, "unable to get hsusb 3p3\n");
- return PTR_ERR(hsusb_3p3);
- }
-
- rc = regulator_set_voltage(hsusb_3p3, USB_PHY_3P3_VOL_MIN,
+ rc = regulator_set_voltage(motg->v3p3, USB_PHY_3P3_VOL_MIN,
USB_PHY_3P3_VOL_MAX);
if (rc) {
dev_err(motg->phy.dev, "unable to set voltage level "
"for hsusb 3p3\n");
- goto put_3p3;
+ return rc;
}
- rc = regulator_enable(hsusb_3p3);
+ rc = regulator_enable(motg->v3p3);
if (rc) {
dev_err(motg->phy.dev, "unable to enable the hsusb
3p3\n");
- goto put_3p3;
- }
- hsusb_1p8 = regulator_get(motg->phy.dev, "HSUSB_1p8");
- if (IS_ERR(hsusb_1p8)) {
- dev_err(motg->phy.dev, "unable to get hsusb 1p8\n");
- rc = PTR_ERR(hsusb_1p8);
- goto disable_3p3;
+ return rc;
}
- rc = regulator_set_voltage(hsusb_1p8, USB_PHY_1P8_VOL_MIN,
+
+ rc = regulator_set_voltage(motg->v1p8, USB_PHY_1P8_VOL_MIN,
USB_PHY_1P8_VOL_MAX);
if (rc) {
dev_err(motg->phy.dev, "unable to set voltage level "
"for hsusb 1p8\n");
- goto put_1p8;
+ goto disable_3p3;
}
- rc = regulator_enable(hsusb_1p8);
+ rc = regulator_enable(motg->v1p8);
if (rc) {
dev_err(motg->phy.dev, "una
[PATCH v2 5/7] usb: phy: msm: Fix WARNING: quoted string split across lines
From: "Ivan T. Ivanov"
This fixes checkpatch.pl warnings.
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/phy/phy-msm-usb.c | 33 +++--
1 file changed, 11 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 0e7d7ab..41938e6 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -67,8 +67,7 @@ static int msm_hsusb_init_vddcx(struct msm_otg *motg, int
init)
USB_PHY_VDD_DIG_VOL_MIN,
USB_PHY_VDD_DIG_VOL_MAX);
if (ret) {
- dev_err(motg->phy.dev, "unable to set the voltage "
- "for hsusb vddcx\n");
+ dev_err(motg->phy.dev, "Cannot set vddcx voltage\n");
return ret;
}
@@ -79,8 +78,7 @@ static int msm_hsusb_init_vddcx(struct msm_otg *motg, int
init)
ret = regulator_set_voltage(motg->vddcx, 0,
USB_PHY_VDD_DIG_VOL_MAX);
if (ret)
- dev_err(motg->phy.dev, "unable to set the voltage "
- "for hsusb vddcx\n");
+ dev_err(motg->phy.dev, "Cannot set vddcx voltage\n");
ret = regulator_disable(motg->vddcx);
if (ret)
dev_err(motg->phy.dev, "unable to disable hsusb
vddcx\n");
@@ -97,8 +95,7 @@ static int msm_hsusb_ldo_init(struct msm_otg *motg, int init)
rc = regulator_set_voltage(motg->v3p3, USB_PHY_3P3_VOL_MIN,
USB_PHY_3P3_VOL_MAX);
if (rc) {
- dev_err(motg->phy.dev, "unable to set voltage level "
- "for hsusb 3p3\n");
+ dev_err(motg->phy.dev, "Cannot set v3p3 voltage\n");
return rc;
}
rc = regulator_enable(motg->v3p3);
@@ -110,8 +107,7 @@ static int msm_hsusb_ldo_init(struct msm_otg *motg, int
init)
rc = regulator_set_voltage(motg->v1p8, USB_PHY_1P8_VOL_MIN,
USB_PHY_1P8_VOL_MAX);
if (rc) {
- dev_err(motg->phy.dev, "unable to set voltage level "
- "for hsusb 1p8\n");
+ dev_err(motg->phy.dev, "Cannot set v1p8 voltage\n");
goto disable_3p3;
}
rc = regulator_enable(motg->v1p8);
@@ -144,8 +140,7 @@ static int msm_hsusb_config_vddcx(struct msm_otg *motg, int
high)
ret = regulator_set_voltage(motg->vddcx, min_vol, max_vol);
if (ret) {
- pr_err("%s: unable to set the voltage for regulator "
- "HSUSB_VDDCX\n", __func__);
+ dev_err(motg->phy.dev, "Cannot set vddcx voltage\n");
return ret;
}
@@ -163,15 +158,13 @@ static int msm_hsusb_ldo_set_mode(struct msm_otg *motg,
int on)
ret = regulator_set_optimum_mode(motg->v1p8,
USB_PHY_1P8_HPM_LOAD);
if (ret < 0) {
- pr_err("%s: Unable to set HPM of the regulator "
- "HSUSB_1p8\n", __func__);
+ pr_err("Could not set HPM for v1p8\n");
return ret;
}
ret = regulator_set_optimum_mode(motg->v3p3,
USB_PHY_3P3_HPM_LOAD);
if (ret < 0) {
- pr_err("%s: Unable to set HPM of the regulator "
- "HSUSB_3p3\n", __func__);
+ pr_err("Could not set HPM for v3p3\n");
regulator_set_optimum_mode(motg->v1p8,
USB_PHY_1P8_LPM_LOAD);
return ret;
@@ -180,13 +173,11 @@ static int msm_hsusb_ldo_set_mode(struct msm_otg *motg,
int on)
ret = regulator_set_optimum_mode(motg->v1p8,
USB_PHY_1P8_LPM_LOAD);
if (ret < 0)
- pr_err("%s: Unable to set LPM of the regulator "
- "HSUSB_1p8\n", __func__);
+ pr_err("Could not set LPM for v1p8\n");
ret = regulator_set_optimum_mode(motg->v3p3,
USB_PHY_3P3_LPM_LOAD);
if (ret < 0)
- pr_err("%s: Unable to set LPM of the regulator "
-
[PATCH v2 6/7] usb: phy: msm: Fix WARNING: Prefer seq_puts to seq_printf
From: "Ivan T. Ivanov"
This fixes checkpatch.pl warnings.
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/phy/phy-msm-usb.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 41938e6..6d05085 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -1204,13 +1204,13 @@ static int msm_otg_mode_show(struct seq_file *s, void
*unused)
switch (otg->phy->state) {
case OTG_STATE_A_HOST:
- seq_printf(s, "host\n");
+ seq_puts(s, "host\n");
break;
case OTG_STATE_B_PERIPHERAL:
- seq_printf(s, "peripheral\n");
+ seq_puts(s, "peripheral\n");
break;
default:
- seq_printf(s, "none\n");
+ seq_puts(s, "none\n");
break;
}
--
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 v2 1/7] usb: phy: msm: Move mach depndend code to platform data
From: "Ivan T. Ivanov"
This patch fix compilation error and is an intermediate step
before the addition of DeviceTree support for newer targets.
Fix suggested here: https://lkml.org/lkml/2013/6/19/381
Cc: David Brown
Cc: Daniel Walker
Cc: Bryan Huntsman
Cc: Stephen Boyd
Signed-off-by: Ivan T. Ivanov
---
arch/arm/mach-msm/board-msm7x30.c | 35 +++
arch/arm/mach-msm/board-qsd8x50.c | 34 +++
drivers/usb/phy/phy-msm-usb.c | 55 ++---
include/linux/usb/msm_hsusb.h |2 ++
4 files changed, 85 insertions(+), 41 deletions(-)
diff --git a/arch/arm/mach-msm/board-msm7x30.c
b/arch/arm/mach-msm/board-msm7x30.c
index db3d8c0..4df7daa 100644
--- a/arch/arm/mach-msm/board-msm7x30.c
+++ b/arch/arm/mach-msm/board-msm7x30.c
@@ -31,6 +31,7 @@
#include
#include
+#include
#include
#include
@@ -61,10 +62,44 @@ static int hsusb_phy_init_seq[] = {
-1
};
+static int hsusb_phy_link_clk_reset(struct clk *link_clk, bool assert)
+{
+ int ret;
+
+ if (assert) {
+ ret = clk_reset(link_clk, CLK_RESET_ASSERT);
+ if (ret)
+ pr_err("usb hs_clk assert failed\n");
+ } else {
+ ret = clk_reset(link_clk, CLK_RESET_DEASSERT);
+ if (ret)
+ pr_err("usb hs_clk deassert failed\n");
+ }
+ return ret;
+}
+
+static int hsusb_phy_clk_reset(struct clk *phy_clk)
+{
+ int ret;
+
+ ret = clk_reset(phy_clk, CLK_RESET_ASSERT);
+ if (ret) {
+ pr_err("usb phy clk assert failed\n");
+ return ret;
+ }
+ usleep_range(1, 12000);
+ ret = clk_reset(phy_clk, CLK_RESET_DEASSERT);
+ if (ret)
+ pr_err("usb phy clk deassert failed\n");
+ return ret;
+}
+
static struct msm_otg_platform_data msm_otg_pdata = {
.phy_init_seq = hsusb_phy_init_seq,
.mode = USB_PERIPHERAL,
.otg_control= OTG_PHY_CONTROL,
+ .phy_link_clk_reset = hsusb_phy_link_clk_reset,
+ .phy_phy_clk_reset = hsusb_phy_clk_reset,
};
struct msm_gpiomux_config msm_gpiomux_configs[GPIOMUX_NGPIOS] = {
diff --git a/arch/arm/mach-msm/board-qsd8x50.c
b/arch/arm/mach-msm/board-qsd8x50.c
index f14a73d..d3d92ab 100644
--- a/arch/arm/mach-msm/board-qsd8x50.c
+++ b/arch/arm/mach-msm/board-qsd8x50.c
@@ -82,10 +82,44 @@ static int hsusb_phy_init_seq[] = {
-1
};
+static int hsusb_phy_link_clk_reset(struct clk *link_clk, bool assert)
+{
+ int ret;
+
+ if (assert) {
+ ret = clk_reset(link_clk, CLK_RESET_ASSERT);
+ if (ret)
+ pr_err("usb hs_clk assert failed\n");
+ } else {
+ ret = clk_reset(link_clk, CLK_RESET_DEASSERT);
+ if (ret)
+ pr_err("usb hs_clk deassert failed\n");
+ }
+ return ret;
+}
+
+static int hsusb_phy_clk_reset(struct clk *phy_clk)
+{
+ int ret;
+
+ ret = clk_reset(phy_clk, CLK_RESET_ASSERT);
+ if (ret) {
+ pr_err("usb phy clk assert failed\n");
+ return ret;
+ }
+ usleep_range(1, 12000);
+ ret = clk_reset(phy_clk, CLK_RESET_DEASSERT);
+ if (ret)
+ pr_err("usb phy clk deassert failed\n");
+ return ret;
+}
+
static struct msm_otg_platform_data msm_otg_pdata = {
.phy_init_seq = hsusb_phy_init_seq,
.mode = USB_PERIPHERAL,
.otg_control= OTG_PHY_CONTROL,
+ .phy_link_clk_reset = hsusb_phy_link_clk_reset,
+ .phy_phy_clk_reset = hsusb_phy_clk_reset,
};
static struct platform_device *devices[] __initdata = {
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index d08f334..ab1b880 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -40,8 +40,6 @@
#include
#include
-#include
-
#define MSM_USB_BASE (motg->regs)
#define DRIVER_NAME"msm_otg"
@@ -306,51 +304,20 @@ static void ulpi_init(struct msm_otg *motg)
}
}
-static int msm_otg_link_clk_reset(struct msm_otg *motg, bool assert)
-{
- int ret;
-
- if (assert) {
- ret = clk_reset(motg->clk, CLK_RESET_ASSERT);
- if (ret)
- dev_err(motg->phy.dev, "usb hs_clk assert failed\n");
- } else {
- ret = clk_reset(motg->clk, CLK_RESET_DEASSERT);
- if (ret)
- dev_err(motg->phy.dev, "usb hs_clk deassert failed\n");
- }
- return ret;
-}
-
-static int msm_otg_phy_clk_reset(struct msm_otg *motg)
-{
- int ret;
-
- ret = clk_reset(motg->phy_reset_clk, CLK_RESET_ASSERT);
- if (ret)
Re: [PATCH v2 0/7] usb: phy: msm: Fixes and cleanups
Hi Felipe, On Tue, 2013-07-09 at 18:47 +0300, Ivan T. Ivanov wrote: > From: "Ivan T. Ivanov" > > Changes since first version. > * Extend commit messages a little bit. > > Following patches make initial cleanup of usb phy found in the Qualcomm > chipsets. Changes include: > * Build time error fix. > * Move driver to Managed Device Resource allocation. > * Checkpatch warnings and error fixes > * Removed usage of global regulators variables. > > Ivan T. Ivanov (7): > usb: phy: msm: Move mach depndend code to platform data > usb: phy: msm: Migrate to Managed Device Resource allocation > usb: phy: msm: Move regulator usage to managed resource allocation > usb: phy: msm: Remove unnecessarily check for valid regulators. > usb: phy: msm: Fix WARNING: quoted string split across lines > usb: phy: msm: Fix WARNING: Prefer seq_puts to seq_printf > usb: phy: msm: Lindent the code Could you take a look at these patches, please. I would like to clean up this driver and add support for controllers which can be found in new MSM8974 chipsets. If there is something, which you would like to see improved in this driver, please let me know. Regards, Ivan > > arch/arm/mach-msm/board-msm7x30.c | 35 > arch/arm/mach-msm/board-qsd8x50.c | 34 > drivers/usb/phy/phy-msm-usb.c | 384 > ++--- > include/linux/usb/msm_hsusb.h |5 + > 4 files changed, 220 insertions(+), 238 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
Re: [PATCH 7/7] usb: phy: msm: Lindent the code
Hi,
On Wed, 2013-07-24 at 15:22 +0300, Felipe Balbi wrote:
> On Mon, Jun 24, 2013 at 06:27:44PM +0300, Ivan T. Ivanov wrote:
> > From: "Ivan T. Ivanov"
> >
> > Cc: Felipe Balbi
> > Cc: Greg Kroah-Hartman
> > Cc: linux-usb@vger.kernel.org
> > Cc: linux-ker...@vger.kernel.org
> >
> > Signed-off-by: Ivan T. Ivanov
>
> I really don't like blind Lindent patches... sometimes it makes things
> even worse.
It is not exactly blindly. I have removed some of the changes in the
platform_driver structure.
>
> > ---
> > drivers/usb/phy/phy-msm-usb.c | 99
> > ++---
> > 1 file changed, 52 insertions(+), 47 deletions(-)
> >
> > diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
> > index 6d05085..111f454 100644
> > --- a/drivers/usb/phy/phy-msm-usb.c
> > +++ b/drivers/usb/phy/phy-msm-usb.c
> > @@ -64,8 +64,8 @@ static int msm_hsusb_init_vddcx(struct msm_otg *motg, int
> > init)
> >
> > if (init) {
> > ret = regulator_set_voltage(motg->vddcx,
> > - USB_PHY_VDD_DIG_VOL_MIN,
> > - USB_PHY_VDD_DIG_VOL_MAX);
> > + USB_PHY_VDD_DIG_VOL_MIN,
> > + USB_PHY_VDD_DIG_VOL_MAX);
>
> like here, what's the point ?
It makes indentation the same like the majority of the code.
I could drop this patch if you like.
Thanks,
Ivan
>
--
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 2/7] usb: phy: msm: Migrate to Managed Device Resource allocation
Hi,
On Wed, 2013-07-24 at 15:38 +0300, Felipe Balbi wrote:
> Hi,
>
> On Tue, Jul 09, 2013 at 06:47:08PM +0300, Ivan T. Ivanov wrote:
> > From: "Ivan T. Ivanov"
> >
> > Use managed device resources to clean up the probe/remove
> > and get DT support for free.
> >
> > Signed-off-by: Ivan T. Ivanov
> > ---
> > drivers/usb/phy/phy-msm-usb.c | 78
> > +++--
> > 1 file changed, 20 insertions(+), 58 deletions(-)
> >
> > diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
> > index ab1b880..cc37f5e 100644
> > --- a/drivers/usb/phy/phy-msm-usb.c
> > +++ b/drivers/usb/phy/phy-msm-usb.c
> > @@ -1458,30 +1455,27 @@ static int __init msm_otg_probe(struct
> > platform_device *pdev)
> > * clock is introduced to remove the dependency on AXI
> > * bus frequency.
> > */
> > - motg->core_clk = clk_get(&pdev->dev, "usb_hs_core_clk");
> > + motg->core_clk = devm_clk_get(&pdev->dev, "usb_hs_core_clk");
> > if (IS_ERR(motg->core_clk))
> > motg->core_clk = NULL;
> >
> > res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > if (!res) {
>
> no need to check for the resource when using devm_ioremap_resource()
>
> > dev_err(&pdev->dev, "failed to get platform resource mem\n");
> > - ret = -ENODEV;
> > - goto put_core_clk;
> > + return -ENODEV;
> > }
> >
> > - motg->regs = ioremap(res->start, resource_size(res));
> > + motg->regs = devm_ioremap_resource(&pdev->dev, res);
> > if (!motg->regs) {
> > dev_err(&pdev->dev, "ioremap failed\n");
>
> don't print error messages when using devm_ioremap_resource()
Will fix these places and re-send,
Thank you,
Ivan
--
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 3/7] usb: phy: msm: Move regulator usage to managed resource allocation
On Wed, 2013-07-24 at 15:39 +0300, Felipe Balbi wrote: > On Tue, Jul 09, 2013 at 06:47:09PM +0300, Ivan T. Ivanov wrote: > > From: "Ivan T. Ivanov" > > > > This patch move global regulators variables to driver state > > structire and move allocation of the regulators to be devm managed. > > split into two patches please. One for moving the global regulators into > your structure and a separate patch to move to devm_* > Ok, will do and resend. Ivan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: dwc3: core: modify IO memory resource after deferred probe completes
From: "Ivan T. Ivanov"
When deferred probe happens driver will try to ioremap multiple times
and will fail. Memory resource.start variable is a global variable,
modifications in this field will be accumulated on every probe.
Fix this by moving the above operations after driver hold all
required PHY's.
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/dwc3/core.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 607bef8..50c833f 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -384,21 +384,6 @@ static int dwc3_probe(struct platform_device *pdev)
dev_err(dev, "missing memory resource\n");
return -ENODEV;
}
- dwc->xhci_resources[0].start = res->start;
- dwc->xhci_resources[0].end = dwc->xhci_resources[0].start +
- DWC3_XHCI_REGS_END;
- dwc->xhci_resources[0].flags = res->flags;
- dwc->xhci_resources[0].name = res->name;
-
- res->start += DWC3_GLOBALS_REGS_START;
-
-/*
- * Request memory region but exclude xHCI regs,
- * since it will be requested by the xhci-plat driver.
- */
- regs = devm_ioremap_resource(dev, res);
- if (IS_ERR(regs))
- return PTR_ERR(regs);
if (node) {
dwc->maximum_speed = of_usb_get_maximum_speed(node);
@@ -452,6 +437,22 @@ static int dwc3_probe(struct platform_device *pdev)
return -EPROBE_DEFER;
}
+ dwc->xhci_resources[0].start = res->start;
+ dwc->xhci_resources[0].end = dwc->xhci_resources[0].start +
+ DWC3_XHCI_REGS_END;
+ dwc->xhci_resources[0].flags = res->flags;
+ dwc->xhci_resources[0].name = res->name;
+
+ res->start += DWC3_GLOBALS_REGS_START;
+
+/*
+ * Request memory region but exclude xHCI regs,
+ * since it will be requested by the xhci-plat driver.
+ */
+ regs = devm_ioremap_resource(dev, res);
+ if (IS_ERR(regs))
+ return PTR_ERR(regs);
+
usb_phy_set_suspend(dwc->usb2_phy, 0);
usb_phy_set_suspend(dwc->usb3_phy, 0);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc3: core: modify IO memory resource after deferred probe completes
On Thu, 2013-07-25 at 21:21 +0400, Sergei Shtylyov wrote: > On 07/25/2013 08:26 PM, Ivan T. Ivanov wrote: > > > From: "Ivan T. Ivanov" > > > When deferred probe happens driver will try to ioremap multiple times > > and will fail. Memory resource.start variable is a global variable, > > modifications in this field will be accumulated on every probe. > > Fix this by moving the above operations after driver hold all > > required PHY's. > Forgot to mention, generated on top of Felipe's 'testing' branch. > > Signed-off-by: Ivan T. Ivanov > > --- > > drivers/usb/dwc3/core.c | 31 --- > > 1 file changed, 16 insertions(+), 15 deletions(-) > > > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c > > index 607bef8..50c833f 100644 > > --- a/drivers/usb/dwc3/core.c > > +++ b/drivers/usb/dwc3/core.c > [...] > > @@ -452,6 +437,22 @@ static int dwc3_probe(struct platform_device *pdev) > > return -EPROBE_DEFER; > > } > > > > + dwc->xhci_resources[0].start = res->start; > > + dwc->xhci_resources[0].end = dwc->xhci_resources[0].start + > > + DWC3_XHCI_REGS_END; > > + dwc->xhci_resources[0].flags = res->flags; > > + dwc->xhci_resources[0].name = res->name; > > + > > + res->start += DWC3_GLOBALS_REGS_START; > > + > > +/* > > + * Request memory region but exclude xHCI regs, > > + * since it will be requested by the xhci-plat driver. > > + */ > > Please remove an extra space after a tab on each comment line. > It seems like a good time to do it, while you're moving this code. > Ok. Regards, Ivan > > + regs = devm_ioremap_resource(dev, res); > > + if (IS_ERR(regs)) > > + return PTR_ERR(regs); > > + > > WBR, Sergei > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] usb: dwc3: core: modify IO memory resource after deferred probe completes
Hi,
On Fri, 2013-07-26 at 02:06 +, Paul Zimmerman wrote:
> > From: Felipe Balbi [mailto:ba...@ti.com]
> > Sent: Thursday, July 25, 2013 1:52 PM
> >
> > On Thu, Jul 25, 2013 at 07:46:58PM +, Paul Zimmerman wrote:
> > > > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> > > > index 607bef8..50c833f 100644
> > > > --- a/drivers/usb/dwc3/core.c
> > > > +++ b/drivers/usb/dwc3/core.c
> > > > @@ -384,21 +384,6 @@ static int dwc3_probe(struct platform_device *pdev)
> > > > dev_err(dev, "missing memory resource\n");
> > > > return -ENODEV;
> > > > }
> > > > - dwc->xhci_resources[0].start = res->start;
> > > > - dwc->xhci_resources[0].end = dwc->xhci_resources[0].start +
> > > > - DWC3_XHCI_REGS_END;
> > > > - dwc->xhci_resources[0].flags = res->flags;
> > > > - dwc->xhci_resources[0].name = res->name;
> > > > -
> > > > - res->start += DWC3_GLOBALS_REGS_START;
> > > > -
> > > > -/*
> > > > - * Request memory region but exclude xHCI regs,
> > > > - * since it will be requested by the xhci-plat driver.
> > > > - */
> > > > - regs = devm_ioremap_resource(dev, res);
> > > > - if (IS_ERR(regs))
> > > > - return PTR_ERR(regs);
> > > >
> > > > if (node) {
> > > > dwc->maximum_speed = of_usb_get_maximum_speed(node);
> > > > @@ -452,6 +437,22 @@ static int dwc3_probe(struct platform_device *pdev)
> > > > return -EPROBE_DEFER;
> > > > }
> > > >
> > > > + dwc->xhci_resources[0].start = res->start;
> > > > + dwc->xhci_resources[0].end = dwc->xhci_resources[0].start +
> > > > + DWC3_XHCI_REGS_END;
> > > > + dwc->xhci_resources[0].flags = res->flags;
> > > > + dwc->xhci_resources[0].name = res->name;
> > > > +
> > > > + res->start += DWC3_GLOBALS_REGS_START;
> > >
> > > Ick. The driver is modifying the struct resource passed to it by the
> >
> > heh...
> >
> > > platform code? That seems like a layering violation, and is fragile as
> > > hell. In addition to this bug, what would happen if the struct resource
> > > was declared 'const'?
> >
> > nothing would happen if it was declared const since platform_add_device
> > makes a copy of what was declared, and that's always non-const.
>
> OK.
>
> > Also, this is not *modifying* what was passed, just skipping the xHCI
> > address space so we don't request_mem_region() an area we won't really
> > handle and prevent xhci-hcd.ko from probing.
>
> Hmm? platform_get_resource() returns a pointer to an entry in the
> platform_device's resource[] array. And "res->start +=" modifies the
> entry pointed at. If it didn't, the bug fixed by this patch wouldn't
> have happened.
>
> Are you sure this code will work OK if you build the driver as a module,
> modprobe it, rmmod it, and then modprobe it again? Seems like it won't,
> unless the dev->resource[] array gets reinitialized in between somehow.
In addition, I think driver is wasting memory, because on every probe
it will reallocate driver state variable. This also happens in several
other drivers which are using deferred probe.
Regards,
Ivan
>
> All this assumes I'm reading the code correctly, of course. If I'm not,
> then never mind :)
>
--
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 3/7] usb: phy: msm: Move regulator usage to managed resource allocation
Hi Felipe, On Thu, 2013-07-25 at 16:43 +0300, Ivan T. Ivanov wrote: > On Wed, 2013-07-24 at 15:39 +0300, Felipe Balbi wrote: > > On Tue, Jul 09, 2013 at 06:47:09PM +0300, Ivan T. Ivanov wrote: > > > From: "Ivan T. Ivanov" > > > > > > This patch move global regulators variables to driver state > > > structire and move allocation of the regulators to be devm managed. > > > > split into two patches please. One for moving the global regulators into > > your structure and a separate patch to move to devm_* > > Would you accept patch which convert all resources allocation to devm_ variants in single patch or you prefer separate patches for memory, clocks, regulators and irq? Regards, Ivan > > Ok, will do and resend. > > Ivan > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- 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 3/7] usb: phy: msm: Move regulator usage to managed resource allocation
On Fri, 2013-07-26 at 23:28 +0300, Felipe Balbi wrote: > On Fri, Jul 26, 2013 at 03:31:34PM +0300, Ivan T. Ivanov wrote: > > > > Hi Felipe, > > > > On Thu, 2013-07-25 at 16:43 +0300, Ivan T. Ivanov wrote: > > > On Wed, 2013-07-24 at 15:39 +0300, Felipe Balbi wrote: > > > > On Tue, Jul 09, 2013 at 06:47:09PM +0300, Ivan T. Ivanov wrote: > > > > > From: "Ivan T. Ivanov" > > > > > > > > > > This patch move global regulators variables to driver state > > > > > structire and move allocation of the regulators to be devm managed. > > > > > > > > split into two patches please. One for moving the global regulators into > > > > your structure and a separate patch to move to devm_* > > > > > > > > Would you accept patch which convert all resources allocation to devm_ > > variants in single patch or you prefer separate patches for memory, > > clocks, regulators and irq? > > devm_* all over the place should be fine ;-) > Thanks, it is coming. Regards, Ivan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/6] usb: phy: msm: move global regulators variables to driver state
From: "Ivan T. Ivanov"
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/phy/phy-msm-usb.c | 82 -
include/linux/usb/msm_hsusb.h |3 ++
2 files changed, 42 insertions(+), 43 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 7b74b26..6cc4801c 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -58,47 +58,43 @@
#define USB_PHY_VDD_DIG_VOL_MIN100 /* uV */
#define USB_PHY_VDD_DIG_VOL_MAX132 /* uV */
-static struct regulator *hsusb_3p3;
-static struct regulator *hsusb_1p8;
-static struct regulator *hsusb_vddcx;
-
static int msm_hsusb_init_vddcx(struct msm_otg *motg, int init)
{
int ret = 0;
if (init) {
- hsusb_vddcx = regulator_get(motg->phy.dev, "HSUSB_VDDCX");
- if (IS_ERR(hsusb_vddcx)) {
+ motg->vddcx = regulator_get(motg->phy.dev, "HSUSB_VDDCX");
+ if (IS_ERR(motg->vddcx)) {
dev_err(motg->phy.dev, "unable to get hsusb vddcx\n");
- return PTR_ERR(hsusb_vddcx);
+ return PTR_ERR(motg->vddcx);
}
- ret = regulator_set_voltage(hsusb_vddcx,
+ ret = regulator_set_voltage(motg->vddcx,
USB_PHY_VDD_DIG_VOL_MIN,
USB_PHY_VDD_DIG_VOL_MAX);
if (ret) {
dev_err(motg->phy.dev, "unable to set the voltage "
"for hsusb vddcx\n");
- regulator_put(hsusb_vddcx);
+ regulator_put(motg->vddcx);
return ret;
}
- ret = regulator_enable(hsusb_vddcx);
+ ret = regulator_enable(motg->vddcx);
if (ret) {
dev_err(motg->phy.dev, "unable to enable hsusb
vddcx\n");
- regulator_put(hsusb_vddcx);
+ regulator_put(motg->vddcx);
}
} else {
- ret = regulator_set_voltage(hsusb_vddcx, 0,
+ ret = regulator_set_voltage(motg->vddcx, 0,
USB_PHY_VDD_DIG_VOL_MAX);
if (ret)
dev_err(motg->phy.dev, "unable to set the voltage "
"for hsusb vddcx\n");
- ret = regulator_disable(hsusb_vddcx);
+ ret = regulator_disable(motg->vddcx);
if (ret)
dev_err(motg->phy.dev, "unable to disable hsusb
vddcx\n");
- regulator_put(hsusb_vddcx);
+ regulator_put(motg->vddcx);
}
return ret;
@@ -109,38 +105,38 @@ static int msm_hsusb_ldo_init(struct msm_otg *motg, int
init)
int rc = 0;
if (init) {
- hsusb_3p3 = regulator_get(motg->phy.dev, "HSUSB_3p3");
- if (IS_ERR(hsusb_3p3)) {
+ motg->v3p3 = regulator_get(motg->phy.dev, "HSUSB_3p3");
+ if (IS_ERR(motg->v3p3)) {
dev_err(motg->phy.dev, "unable to get hsusb 3p3\n");
- return PTR_ERR(hsusb_3p3);
+ return PTR_ERR(motg->v3p3);
}
- rc = regulator_set_voltage(hsusb_3p3, USB_PHY_3P3_VOL_MIN,
+ rc = regulator_set_voltage(motg->v3p3, USB_PHY_3P3_VOL_MIN,
USB_PHY_3P3_VOL_MAX);
if (rc) {
dev_err(motg->phy.dev, "unable to set voltage level "
"for hsusb 3p3\n");
goto put_3p3;
}
- rc = regulator_enable(hsusb_3p3);
+ rc = regulator_enable(motg->v3p3);
if (rc) {
dev_err(motg->phy.dev, "unable to enable the hsusb
3p3\n");
goto put_3p3;
}
- hsusb_1p8 = regulator_get(motg->phy.dev, "HSUSB_1p8");
- if (IS_ERR(hsusb_1p8)) {
+ motg->v1p8 = regulator_get(motg->phy.dev, "HSUSB_1p8");
+ if (IS_ERR(motg->v1p8)) {
dev_err(motg->phy.dev, "unable to get hsusb 1p8\n");
- rc = PTR_ERR(hsusb_1p8);
+ rc = PTR_ERR(motg->v1p8);
goto disable_3p3;
}
- rc = regulator_set_voltage(hsusb_1p8, USB_PHY_1P8_VOL_MIN,
+ rc = regulator_set_voltage(motg->v1p8, USB_PHY_1P8_VOL_MIN,
USB_PHY_1P8_VOL_MA
[PATCH v2 4/6] usb: phy: msm: Remove unnecessarily check for valid regulators.
From: "Ivan T. Ivanov"
Whether regulators are available or not is checked at driver
probe. If they are not available driver will refuse to load,
so no need to check them again.
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/phy/phy-msm-usb.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index c72f7c1..0e93dbc 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -159,16 +159,6 @@ static int msm_hsusb_ldo_set_mode(struct msm_otg *motg,
int on)
{
int ret = 0;
- if (!motg->v1p8 || IS_ERR(motg->v1p8)) {
- pr_err("%s: HSUSB_1p8 is not initialized\n", __func__);
- return -ENODEV;
- }
-
- if (!motg->v3p3 || IS_ERR(motg->v3p3)) {
- pr_err("%s: HSUSB_3p3 is not initialized\n", __func__);
- return -ENODEV;
- }
-
if (on) {
ret = regulator_set_optimum_mode(motg->v1p8,
USB_PHY_1P8_HPM_LOAD);
--
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 v2 0/6] usb: phy: msm: Fixes and cleanups
From: "Ivan T. Ivanov" v2 -- * Fix compilation issue in patch 1 * Separate regulator changes * Merge devm_ related changes to one commit * Drop Lindent patch v1 -- Following patches make initial cleanup of usb phy found in the Qualcomm chipsets. Changes include: * Build time error fix. * Move driver to Managed Device Resource allocation. * Checkpatch warnings and error fixes * Removed usage of global regulators variables. Ivan T. Ivanov (6): usb: phy: msm: Move mach depndend code to platform data usb: phy: msm: move global regulators variables to driver state usb: phy: msm: Migrate to Managed Device Resource allocation usb: phy: msm: Remove unnecessarily check for valid regulators. usb: phy: msm: Fix WARNING: quoted string split across lines usb: phy: msm: Fix WARNING: Prefer seq_puts to seq_printf arch/arm/mach-msm/board-msm7x30.c | 35 arch/arm/mach-msm/board-qsd8x50.c | 35 drivers/usb/phy/phy-msm-usb.c | 342 + include/linux/usb/msm_hsusb.h |6 + 4 files changed, 198 insertions(+), 220 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/6] usb: phy: msm: Fix WARNING: quoted string split across lines
From: "Ivan T. Ivanov"
This fixes checkpatch.pl warnings.
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/phy/phy-msm-usb.c | 33 +++--
1 file changed, 11 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 0e93dbc..118bd0a 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -67,8 +67,7 @@ static int msm_hsusb_init_vddcx(struct msm_otg *motg, int
init)
USB_PHY_VDD_DIG_VOL_MIN,
USB_PHY_VDD_DIG_VOL_MAX);
if (ret) {
- dev_err(motg->phy.dev, "unable to set the voltage "
- "for hsusb vddcx\n");
+ dev_err(motg->phy.dev, "Cannot set vddcx voltage\n");
return ret;
}
@@ -79,8 +78,7 @@ static int msm_hsusb_init_vddcx(struct msm_otg *motg, int
init)
ret = regulator_set_voltage(motg->vddcx, 0,
USB_PHY_VDD_DIG_VOL_MAX);
if (ret)
- dev_err(motg->phy.dev, "unable to set the voltage "
- "for hsusb vddcx\n");
+ dev_err(motg->phy.dev, "Cannot set vddcx voltage\n");
ret = regulator_disable(motg->vddcx);
if (ret)
dev_err(motg->phy.dev, "unable to disable hsusb
vddcx\n");
@@ -97,8 +95,7 @@ static int msm_hsusb_ldo_init(struct msm_otg *motg, int init)
rc = regulator_set_voltage(motg->v3p3, USB_PHY_3P3_VOL_MIN,
USB_PHY_3P3_VOL_MAX);
if (rc) {
- dev_err(motg->phy.dev, "unable to set voltage level "
- "for hsusb 3p3\n");
+ dev_err(motg->phy.dev, "Cannot set v3p3 voltage\n");
goto exit;
}
rc = regulator_enable(motg->v3p3);
@@ -109,8 +106,7 @@ static int msm_hsusb_ldo_init(struct msm_otg *motg, int
init)
rc = regulator_set_voltage(motg->v1p8, USB_PHY_1P8_VOL_MIN,
USB_PHY_1P8_VOL_MAX);
if (rc) {
- dev_err(motg->phy.dev, "unable to set voltage level "
- "for hsusb 1p8\n");
+ dev_err(motg->phy.dev, "Cannot set v1p8 voltage\n");
goto disable_3p3;
}
rc = regulator_enable(motg->v1p8);
@@ -144,8 +140,7 @@ static int msm_hsusb_config_vddcx(struct msm_otg *motg, int
high)
ret = regulator_set_voltage(motg->vddcx, min_vol, max_vol);
if (ret) {
- pr_err("%s: unable to set the voltage for regulator "
- "HSUSB_VDDCX\n", __func__);
+ dev_err(motg->phy.dev, "Cannot set vddcx voltage\n");
return ret;
}
@@ -163,15 +158,13 @@ static int msm_hsusb_ldo_set_mode(struct msm_otg *motg,
int on)
ret = regulator_set_optimum_mode(motg->v1p8,
USB_PHY_1P8_HPM_LOAD);
if (ret < 0) {
- pr_err("%s: Unable to set HPM of the regulator "
- "HSUSB_1p8\n", __func__);
+ pr_err("Could not set HPM for v1p8\n");
return ret;
}
ret = regulator_set_optimum_mode(motg->v3p3,
USB_PHY_3P3_HPM_LOAD);
if (ret < 0) {
- pr_err("%s: Unable to set HPM of the regulator "
- "HSUSB_3p3\n", __func__);
+ pr_err("Could not set HPM for v3p3\n");
regulator_set_optimum_mode(motg->v1p8,
USB_PHY_1P8_LPM_LOAD);
return ret;
@@ -180,13 +173,11 @@ static int msm_hsusb_ldo_set_mode(struct msm_otg *motg,
int on)
ret = regulator_set_optimum_mode(motg->v1p8,
USB_PHY_1P8_LPM_LOAD);
if (ret < 0)
- pr_err("%s: Unable to set LPM of the regulator "
- "HSUSB_1p8\n", __func__);
+ pr_err("Could not set LPM for v1p8\n");
ret = regulator_set_optimum_mode(motg->v3p3,
USB_PHY_3P3_LPM_LOAD);
if (ret < 0)
- pr_err("%s: Unable to set LPM of the regulator "
-
[PATCH v2 3/6] usb: phy: msm: Migrate to Managed Device Resource allocation
From: "Ivan T. Ivanov"
Move memory, regulators, clocks and irq allocation to
devm_* variants. Properly check for valid clk handles.
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/phy/phy-msm-usb.c | 188 -
1 file changed, 71 insertions(+), 117 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 6cc4801c..c72f7c1 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -63,27 +63,18 @@ static int msm_hsusb_init_vddcx(struct msm_otg *motg, int
init)
int ret = 0;
if (init) {
- motg->vddcx = regulator_get(motg->phy.dev, "HSUSB_VDDCX");
- if (IS_ERR(motg->vddcx)) {
- dev_err(motg->phy.dev, "unable to get hsusb vddcx\n");
- return PTR_ERR(motg->vddcx);
- }
-
ret = regulator_set_voltage(motg->vddcx,
USB_PHY_VDD_DIG_VOL_MIN,
USB_PHY_VDD_DIG_VOL_MAX);
if (ret) {
dev_err(motg->phy.dev, "unable to set the voltage "
"for hsusb vddcx\n");
- regulator_put(motg->vddcx);
return ret;
}
ret = regulator_enable(motg->vddcx);
- if (ret) {
+ if (ret)
dev_err(motg->phy.dev, "unable to enable hsusb
vddcx\n");
- regulator_put(motg->vddcx);
- }
} else {
ret = regulator_set_voltage(motg->vddcx, 0,
USB_PHY_VDD_DIG_VOL_MAX);
@@ -93,8 +84,6 @@ static int msm_hsusb_init_vddcx(struct msm_otg *motg, int
init)
ret = regulator_disable(motg->vddcx);
if (ret)
dev_err(motg->phy.dev, "unable to disable hsusb
vddcx\n");
-
- regulator_put(motg->vddcx);
}
return ret;
@@ -105,53 +94,38 @@ static int msm_hsusb_ldo_init(struct msm_otg *motg, int
init)
int rc = 0;
if (init) {
- motg->v3p3 = regulator_get(motg->phy.dev, "HSUSB_3p3");
- if (IS_ERR(motg->v3p3)) {
- dev_err(motg->phy.dev, "unable to get hsusb 3p3\n");
- return PTR_ERR(motg->v3p3);
- }
-
rc = regulator_set_voltage(motg->v3p3, USB_PHY_3P3_VOL_MIN,
USB_PHY_3P3_VOL_MAX);
if (rc) {
dev_err(motg->phy.dev, "unable to set voltage level "
"for hsusb 3p3\n");
- goto put_3p3;
+ goto exit;
}
rc = regulator_enable(motg->v3p3);
if (rc) {
dev_err(motg->phy.dev, "unable to enable the hsusb
3p3\n");
- goto put_3p3;
- }
- motg->v1p8 = regulator_get(motg->phy.dev, "HSUSB_1p8");
- if (IS_ERR(motg->v1p8)) {
- dev_err(motg->phy.dev, "unable to get hsusb 1p8\n");
- rc = PTR_ERR(motg->v1p8);
- goto disable_3p3;
+ goto exit;
}
rc = regulator_set_voltage(motg->v1p8, USB_PHY_1P8_VOL_MIN,
USB_PHY_1P8_VOL_MAX);
if (rc) {
dev_err(motg->phy.dev, "unable to set voltage level "
"for hsusb 1p8\n");
- goto put_1p8;
+ goto disable_3p3;
}
rc = regulator_enable(motg->v1p8);
if (rc) {
dev_err(motg->phy.dev, "unable to enable the hsusb
1p8\n");
- goto put_1p8;
+ goto disable_3p3;
}
return 0;
}
regulator_disable(motg->v1p8);
-put_1p8:
- regulator_put(motg->v1p8);
disable_3p3:
regulator_disable(motg->v3p3);
-put_3p3:
- regulator_put(motg->v3p3);
+exit:
return rc;
}
@@ -479,7 +453,7 @@ static int msm_otg_suspend(struct msm_otg *motg)
clk_disable_unprepare(motg->pclk);
clk_disable_unprepare(motg->clk);
- if (motg->core_clk)
+ if (!IS_ERR(motg->core_clk))
clk_disable_unprepare(motg->core_clk);
if (!IS_ERR(motg->pclk_src))
@@ -519,7 +493,7 @@ static int msm_otg_resume(struct msm_otg *motg)
clk_prepare_enable(motg->pclk);
[PATCH v2 6/6] usb: phy: msm: Fix WARNING: Prefer seq_puts to seq_printf
From: "Ivan T. Ivanov"
This fixes checkpatch.pl warnings.
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/phy/phy-msm-usb.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 118bd0a..e370435 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -1204,13 +1204,13 @@ static int msm_otg_mode_show(struct seq_file *s, void
*unused)
switch (otg->phy->state) {
case OTG_STATE_A_HOST:
- seq_printf(s, "host\n");
+ seq_puts(s, "host\n");
break;
case OTG_STATE_B_PERIPHERAL:
- seq_printf(s, "peripheral\n");
+ seq_puts(s, "peripheral\n");
break;
default:
- seq_printf(s, "none\n");
+ seq_puts(s, "none\n");
break;
}
--
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 v2 1/6] usb: phy: msm: Move mach depndend code to platform data
From: "Ivan T. Ivanov"
This patch fix compilation error and is an intermediate step
before the addition of DeviceTree support for newer targets.
Fix suggested here: https://lkml.org/lkml/2013/6/19/381
Cc: David Brown
Cc: Daniel Walker
Cc: Bryan Huntsman
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Signed-off-by: Ivan T. Ivanov
---
arch/arm/mach-msm/board-msm7x30.c | 35 +++
arch/arm/mach-msm/board-qsd8x50.c | 35 +++
drivers/usb/phy/phy-msm-usb.c | 55 ++---
include/linux/usb/msm_hsusb.h |3 ++
4 files changed, 87 insertions(+), 41 deletions(-)
diff --git a/arch/arm/mach-msm/board-msm7x30.c
b/arch/arm/mach-msm/board-msm7x30.c
index db3d8c0..6b35953 100644
--- a/arch/arm/mach-msm/board-msm7x30.c
+++ b/arch/arm/mach-msm/board-msm7x30.c
@@ -31,6 +31,7 @@
#include
#include
+#include
#include
#include
@@ -61,10 +62,44 @@ static int hsusb_phy_init_seq[] = {
-1
};
+static int hsusb_link_clk_reset(struct clk *link_clk, bool assert)
+{
+ int ret;
+
+ if (assert) {
+ ret = clk_reset(link_clk, CLK_RESET_ASSERT);
+ if (ret)
+ pr_err("usb hs_clk assert failed\n");
+ } else {
+ ret = clk_reset(link_clk, CLK_RESET_DEASSERT);
+ if (ret)
+ pr_err("usb hs_clk deassert failed\n");
+ }
+ return ret;
+}
+
+static int hsusb_phy_clk_reset(struct clk *phy_clk)
+{
+ int ret;
+
+ ret = clk_reset(phy_clk, CLK_RESET_ASSERT);
+ if (ret) {
+ pr_err("usb phy clk assert failed\n");
+ return ret;
+ }
+ usleep_range(1, 12000);
+ ret = clk_reset(phy_clk, CLK_RESET_DEASSERT);
+ if (ret)
+ pr_err("usb phy clk deassert failed\n");
+ return ret;
+}
+
static struct msm_otg_platform_data msm_otg_pdata = {
.phy_init_seq = hsusb_phy_init_seq,
.mode = USB_PERIPHERAL,
.otg_control= OTG_PHY_CONTROL,
+ .link_clk_reset = hsusb_link_clk_reset,
+ .phy_clk_reset = hsusb_phy_clk_reset,
};
struct msm_gpiomux_config msm_gpiomux_configs[GPIOMUX_NGPIOS] = {
diff --git a/arch/arm/mach-msm/board-qsd8x50.c
b/arch/arm/mach-msm/board-qsd8x50.c
index f14a73d..eb013f7 100644
--- a/arch/arm/mach-msm/board-qsd8x50.c
+++ b/arch/arm/mach-msm/board-qsd8x50.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include "devices.h"
@@ -82,10 +83,44 @@ static int hsusb_phy_init_seq[] = {
-1
};
+static int hsusb_link_clk_reset(struct clk *link_clk, bool assert)
+{
+ int ret;
+
+ if (assert) {
+ ret = clk_reset(link_clk, CLK_RESET_ASSERT);
+ if (ret)
+ pr_err("usb hs_clk assert failed\n");
+ } else {
+ ret = clk_reset(link_clk, CLK_RESET_DEASSERT);
+ if (ret)
+ pr_err("usb hs_clk deassert failed\n");
+ }
+ return ret;
+}
+
+static int hsusb_phy_clk_reset(struct clk *phy_clk)
+{
+ int ret;
+
+ ret = clk_reset(phy_clk, CLK_RESET_ASSERT);
+ if (ret) {
+ pr_err("usb phy clk assert failed\n");
+ return ret;
+ }
+ usleep_range(1, 12000);
+ ret = clk_reset(phy_clk, CLK_RESET_DEASSERT);
+ if (ret)
+ pr_err("usb phy clk deassert failed\n");
+ return ret;
+}
+
static struct msm_otg_platform_data msm_otg_pdata = {
.phy_init_seq = hsusb_phy_init_seq,
.mode = USB_PERIPHERAL,
.otg_control= OTG_PHY_CONTROL,
+ .link_clk_reset = hsusb_link_clk_reset,
+ .phy_clk_reset = hsusb_phy_clk_reset,
};
static struct platform_device *devices[] __initdata = {
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index d08f334..7b74b26 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -40,8 +40,6 @@
#include
#include
-#include
-
#define MSM_USB_BASE (motg->regs)
#define DRIVER_NAME"msm_otg"
@@ -306,51 +304,20 @@ static void ulpi_init(struct msm_otg *motg)
}
}
-static int msm_otg_link_clk_reset(struct msm_otg *motg, bool assert)
-{
- int ret;
-
- if (assert) {
- ret = clk_reset(motg->clk, CLK_RESET_ASSERT);
- if (ret)
- dev_err(motg->phy.dev, "usb hs_clk assert failed\n");
- } else {
- ret = clk_reset(motg->clk, CLK_RESET_DEASSERT);
- if (ret)
- dev_err(motg->phy.dev, "usb hs_clk deass
[PATCH v2] usb: dwc3: core: modify IO memory resource after deferred probe completes
From: "Ivan T. Ivanov"
When deferred probe happens driver will try to ioremap multiple times
and will fail. Memory resource.start variable is a global variable,
modifications in this field will be accumulated on every probe.
Fix this by moving the above operations after driver hold all
required PHY's.
Signed-off-by: Ivan T. Ivanov
---
Felipe, Paul if you get better solution please go ahead and ignore
this patch.
v2 - inline comments
drivers/usb/dwc3/core.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 607bef8..c257117 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -384,21 +384,6 @@ static int dwc3_probe(struct platform_device *pdev)
dev_err(dev, "missing memory resource\n");
return -ENODEV;
}
- dwc->xhci_resources[0].start = res->start;
- dwc->xhci_resources[0].end = dwc->xhci_resources[0].start +
- DWC3_XHCI_REGS_END;
- dwc->xhci_resources[0].flags = res->flags;
- dwc->xhci_resources[0].name = res->name;
-
- res->start += DWC3_GLOBALS_REGS_START;
-
-/*
- * Request memory region but exclude xHCI regs,
- * since it will be requested by the xhci-plat driver.
- */
- regs = devm_ioremap_resource(dev, res);
- if (IS_ERR(regs))
- return PTR_ERR(regs);
if (node) {
dwc->maximum_speed = of_usb_get_maximum_speed(node);
@@ -452,6 +437,22 @@ static int dwc3_probe(struct platform_device *pdev)
return -EPROBE_DEFER;
}
+ dwc->xhci_resources[0].start = res->start;
+ dwc->xhci_resources[0].end = dwc->xhci_resources[0].start +
+ DWC3_XHCI_REGS_END;
+ dwc->xhci_resources[0].flags = res->flags;
+ dwc->xhci_resources[0].name = res->name;
+
+ res->start += DWC3_GLOBALS_REGS_START;
+
+ /*
+* Request memory region but exclude xHCI regs,
+* since it will be requested by the xhci-plat driver.
+*/
+ regs = devm_ioremap_resource(dev, res);
+ if (IS_ERR(regs))
+ return PTR_ERR(regs);
+
usb_phy_set_suspend(dwc->usb2_phy, 0);
usb_phy_set_suspend(dwc->usb3_phy, 0);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] usb: phy: msm: Move mach depndend code to platform data
Hi,
> > Cc: Bryan Huntsman
> > Cc: Felipe Balbi
> > Cc: Greg Kroah-Hartman
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-ker...@vger.kernel.org
> > Cc: linux-usb@vger.kernel.org
> >
> > Signed-off-by: Ivan T. Ivanov
> > ---
> > arch/arm/mach-msm/board-msm7x30.c | 35 +++
> > arch/arm/mach-msm/board-qsd8x50.c | 35 +++
>
> I need acks for these.
>
> > drivers/usb/phy/phy-msm-usb.c | 55
> > ++---
> > include/linux/usb/msm_hsusb.h |3 ++
> > 4 files changed, 87 insertions(+), 41 deletions(-)
> >
> > diff --git a/arch/arm/mach-msm/board-msm7x30.c
> > b/arch/arm/mach-msm/board-msm7x30.c
> > index db3d8c0..6b35953 100644
> > --- a/arch/arm/mach-msm/board-msm7x30.c
> > +++ b/arch/arm/mach-msm/board-msm7x30.c
> > @@ -31,6 +31,7 @@
> > #include
> >
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -61,10 +62,44 @@ static int hsusb_phy_init_seq[] = {
> > -1
> > };
> >
> > +static int hsusb_link_clk_reset(struct clk *link_clk, bool assert)
>
> looks like you should be using the reset controller framework ?
> (drivers/reset)
Probably, but there still nothing in place in the msm,
which provide this functionality. I am looking it to
right now.
Regards,
Ivan
--
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
[RFC 0/2] DWC3 USB support for Qualcomm platform
From: "Ivan T. Ivanov" Hi, These patches add basic support for USB3.0 controllers found on MSM platforms. First patch add 2 USB PHY drivers and second one add support for Qualcomm wrapper IP over DWC3 controller. Patches are just skeletons, no power management. DWC3 IP in MSM also support OTG but right now I am not sure how to add support for it. Probably OTG have to be instantiated from core dwc3 driver, but usually PHY drivers are those which create OTG instance. Generated on top of Felipe 'testing' branch. Regards, Ivan Ivan T. Ivanov (2): usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core usb: dwc3: Add Qualcomm DWC3 glue layer driver .../devicetree/bindings/usb/msm-ssusb.txt | 88 + drivers/usb/dwc3/Kconfig |8 + drivers/usb/dwc3/Makefile |1 + drivers/usb/dwc3/dwc3-msm.c| 175 + drivers/usb/phy/Kconfig| 11 + drivers/usb/phy/Makefile |2 + drivers/usb/phy/phy-msm-dwc3-usb2.c| 342 + drivers/usb/phy/phy-msm-dwc3-usb3.c| 389 8 files changed, 1016 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt create mode 100644 drivers/usb/dwc3/dwc3-msm.c create mode 100644 drivers/usb/phy/phy-msm-dwc3-usb2.c create mode 100644 drivers/usb/phy/phy-msm-dwc3-usb3.c -- 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
[RFC 2/2] usb: dwc3: Add Qualcomm DWC3 glue layer driver
From: "Ivan T. Ivanov"
Signed-off-by: Ivan T. Ivanov
---
.../devicetree/bindings/usb/msm-ssusb.txt | 39 +
drivers/usb/dwc3/Kconfig |8 +
drivers/usb/dwc3/Makefile |1 +
drivers/usb/dwc3/dwc3-msm.c| 175
4 files changed, 223 insertions(+)
create mode 100644 drivers/usb/dwc3/dwc3-msm.c
diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt
b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
index 550b496..313ae0d 100644
--- a/Documentation/devicetree/bindings/usb/msm-ssusb.txt
+++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
@@ -22,6 +22,23 @@ Required "supply-name" examples are:
"v1p8" : 1.8v supply for SS-PHY
"vddcx" : vdd supply for SS-PHY digital circuit operation
+Required properties :
+- compatible : should be "qcom,dwc-usb3-msm"
+- reg : offset and length of the register set in the memory map
+ offset and length of the TCSR register for routing USB
+ signals to either picoPHY0 or picoPHY1.
+- clocks = <&usb30_master_cxc>, <&sys_noc_usb3_axi_cxc>, <&usb30_sleep_cxc>,
<&usb30_mock_utmi_cxc>;
+- clock-names = "core_clk", "iface_clk", "sleep_clk", "utmi_clk";
+
+Optional properties :
+- gdsc-supply : phandle to the globally distributed switch controller
+ regulator node to the USB controller.
+
+Sub nodes:
+- Sub node for "DWC3- USB3 controller".
+ This sub node is required property for device node. The properties of this
subnode
+ are specified in dwc3.txt.
+
Example device nodes:
dwc3_usb2: phy@f92f8800 {
@@ -47,3 +64,25 @@ Example device nodes:
vddcx-supply = <&supply>;
v1p8-supply = <&supply>;
};
+
+ usb@fd4ab000 {
+ compatible = "qcom,dwc-usb3-msm";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0xfd4ab000 0x4>;
+
+ clocks = <&usb30_master_cxc>, <&sys_noc_usb3_axi_cxc>,
<&usb30_sleep_cxc>, <&usb30_mock_utmi_cxc>;
+ clock-names = "core_clk", "iface_clk", "sleep_clk", "utmi_clk";
+
+ gdsc-supply = <&supply>;
+ ranges;
+
+ dwc3@f920 {
+ compatible = "snps,dwc3";
+ reg = <0xf920 0xcd00>;
+ interrupts = <0 131 0>;
+ interrupt-names = "irq";
+ usb-phy = <&dwc3_usb2>, <&dwc3_usb3>;
+ tx-fifo-resize;
+ };
+ };
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 3e225d5..e2032c4 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -70,6 +70,14 @@ config USB_DWC3_PCI
One such PCIe-based platform is Synopsys' PCIe HAPS model of
this IP.
+config USB_DWC3_MSM
+ tristate "Qualcomm MSM/APQ Platforms"
+ default USB_DWC3
+ select USB_MSM_DWC3_PHYS
+ help
+ Recent Qualcomm SoCs ship with one DesignWare Core USB3 IP inside,
+ say 'Y' or 'M' if you have one such device.
+
comment "Debugging features"
config USB_DWC3_DEBUG
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index dd17601..5226681 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -32,3 +32,4 @@ endif
obj-$(CONFIG_USB_DWC3_OMAP)+= dwc3-omap.o
obj-$(CONFIG_USB_DWC3_EXYNOS) += dwc3-exynos.o
obj-$(CONFIG_USB_DWC3_PCI) += dwc3-pci.o
+obj-$(CONFIG_USB_DWC3_MSM) += dwc3-msm.o
diff --git a/drivers/usb/dwc3/dwc3-msm.c b/drivers/usb/dwc3/dwc3-msm.c
new file mode 100644
index 000..e509abc
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-msm.c
@@ -0,0 +1,175 @@
+/* Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ */
+#undef CONFIG_REGULATOR
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct dwc3_msm {
+ struct device *dev;
+ void __iomem*base;
+
+ struct clk *core_clk;
+ struct clk
[RFC 1/2] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core
From: "Ivan T. Ivanov"
Signed-off-by: Ivan T. Ivanov
---
.../devicetree/bindings/usb/msm-ssusb.txt | 49 +++
drivers/usb/phy/Kconfig| 11 +
drivers/usb/phy/Makefile |2 +
drivers/usb/phy/phy-msm-dwc3-usb2.c| 342 +
drivers/usb/phy/phy-msm-dwc3-usb3.c| 389
5 files changed, 793 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt
create mode 100644 drivers/usb/phy/phy-msm-dwc3-usb2.c
create mode 100644 drivers/usb/phy/phy-msm-dwc3-usb3.c
diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt
b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
new file mode 100644
index 000..550b496
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
@@ -0,0 +1,49 @@
+MSM SuperSpeed USB3.0 SoC controllers
+
+Required properities :
+- compatible sould be "qcom,dwc3-usb2";
+- reg : offset and length of the register set in the memory map
+- clocks: <&cxo>, <&usb2a_phy_sleep_cxc>;
+- clock-names: "xo", "sleep_a_clk";
+-supply: phandle to the regulator device tree node
+Required "supply-name" examples are:
+ "v1p8" : 1.8v supply for HSPHY
+ "v3p3" : 3.3v supply for HSPHY
+ "vbus" : vbus supply for host mode
+ "vddcx" : vdd supply for HS-PHY digital circuit operation
+
+Required properities :
+- compatible sould be "qcom,dwc3-usb3";
+- reg : offset and length of the register set in the memory map
+- clocks: <&cxo>, <&usb30_mock_utmi_cxc>;
+- clock-names: "xo", "ref_clk";
+-supply: phandle to the regulator device tree node
+Required "supply-name" examples are:
+ "v1p8" : 1.8v supply for SS-PHY
+ "vddcx" : vdd supply for SS-PHY digital circuit operation
+
+Example device nodes:
+
+ dwc3_usb2: phy@f92f8800 {
+ compatible = "qcom,dwc3-usb2";
+ reg = <0xf92f8800 0x30>;
+
+ clocks = <&cxo>, <&usb2a_phy_sleep_cxc>;
+ clock-names = "xo", "sleep_a_clk";
+
+ vbus-supply = <&supply>;
+ vddcx-supply = <&supply>;
+ v1p8-supply = <&supply>;
+ v3p3-supply = <&supply>;
+ };
+
+ dwc3_usb3: phy@f92f8830 {
+ compatible = "qcom,dwc3-usb3";
+ reg = <0xf92f8830 0x30>;
+
+ clocks = <&cxo>, <&usb30_mock_utmi_cxc>;
+ clock-names = "xo", "ref_clk";
+
+ vddcx-supply = <&supply>;
+ v1p8-supply = <&supply>;
+ };
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 5443958..40e83b5 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -202,6 +202,17 @@ config USB_RCAR_PHY
To compile this driver as a module, choose M here: the
module will be called phy-rcar-usb.
+config USB_MSM_DWC3_PHYS
+ tristate "Qualcomm DWC3 USB controller PHY's support"
+ depends on (USB || USB_GADGET) && ARCH_MSM
+ select USB_PHY
+ help
+ Enable this to support the USB PHY transceivers on MSM chips with
+ DWC3 USB core. It handles PHY initialization, clock management
+ required after resetting the hardware and power management.
+ This driver is required even for peripheral only or host only
+ mode configurations.
+
config USB_ULPI
bool "Generic ULPI Transceiver Driver"
depends on ARM
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 98730ca..53355ec 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -24,6 +24,8 @@ obj-$(CONFIG_USB_EHCI_TEGRA) += phy-tegra-usb.o
obj-$(CONFIG_USB_GPIO_VBUS)+= phy-gpio-vbus-usb.o
obj-$(CONFIG_USB_ISP1301) += phy-isp1301.o
obj-$(CONFIG_USB_MSM_OTG) += phy-msm-usb.o
+obj-$(CONFIG_USB_MSM_DWC3_PHYS)+= phy-msm-dwc3-usb2.o
+obj-$(CONFIG_USB_MSM_DWC3_PHYS)+= phy-msm-dwc3-usb3.o
obj-$(CONFIG_USB_MV_OTG) += phy-mv-usb.o
obj-$(CONFIG_USB_MXS_PHY) += phy-mxs-usb.o
obj-$(CONFIG_USB_RCAR_PHY) += phy-rcar-usb.o
diff --git a/drivers/usb/phy/phy-msm-dwc3-usb2.c
b/drivers/usb/phy/phy-msm-dwc3-usb2.c
new file mode 100644
index 000..174c72c
--- /dev/null
+++ b/drivers/usb/phy/phy-msm-dwc3-usb2.c
@@ -0,0 +1,342 @@
+/* Copyright (c) 2013, Code Aurora Forum. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 a
Re: [RFC 1/2] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core
Hi,
On Tue, 2013-08-06 at 13:12 +0100, Pawel Moll wrote:
> On Tue, 2013-08-06 at 12:53 +0100, Ivan T. Ivanov wrote:
> > From: "Ivan T. Ivanov"
> >
> > Signed-off-by: Ivan T. Ivanov
>
> I am sure that the information in the subject is more than enough for
> you, but would you care to give some more background for the commit log?
> Where can we find such controllers? What is DWC3 core? Is it
> Qualcomm-specific block, or does it come from one of the IP providers
> like Synopsys or Cadence?
>
You are right, I have to add more info here. DesignWare USB Core could
also be found in TI OMAP's and Samasung SoC's, at least. And it is
IP from Synopsys. Usually SoC vendors wrap it with additional logic,
which provides required clocks and power supplies.
> > .../devicetree/bindings/usb/msm-ssusb.txt | 49 +++
> > drivers/usb/phy/Kconfig| 11 +
> > drivers/usb/phy/Makefile |2 +
> > drivers/usb/phy/phy-msm-dwc3-usb2.c| 342 +
> > drivers/usb/phy/phy-msm-dwc3-usb3.c| 389
> >
> > 5 files changed, 793 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > create mode 100644 drivers/usb/phy/phy-msm-dwc3-usb2.c
> > create mode 100644 drivers/usb/phy/phy-msm-dwc3-usb3.c
> >
> > diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > new file mode 100644
> > index 000..550b496
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > @@ -0,0 +1,49 @@
> > +MSM SuperSpeed USB3.0 SoC controllers
>
> I understand that the device always come in doublets? As in: are nodes
> for both USB2 and 3 always required?
The core dwc3 driver expects 2 USB PHY interfaces, so both nodes
are mandatory.
>
> > +Required properities :
> > +- compatible sould be "qcom,dwc3-usb2";
> > +- reg : offset and length of the register set in the memory map
> > +- clocks: <&cxo>, <&usb2a_phy_sleep_cxc>;
> > +- clock-names: "xo", "sleep_a_clk";
> > +-supply: phandle to the regulator device tree node
> > +Required "supply-name" examples are:
>
> So required or examples? ;-)
It should be Required, will fix this.
>
> > + "v1p8" : 1.8v supply for HSPHY
> > + "v3p3" : 3.3v supply for HSPHY
> > + "vbus" : vbus supply for host mode
> > + "vddcx" : vdd supply for HS-PHY digital circuit operation
> >
> > +Required properities :
> > +- compatible sould be "qcom,dwc3-usb3";
> > +- reg : offset and length of the register set in the memory map
> > +- clocks: <&cxo>, <&usb30_mock_utmi_cxc>;
> > +- clock-names: "xo", "ref_clk";
> > +-supply: phandle to the regulator device tree node
> > +Required "supply-name" examples are:
> > + "v1p8" : 1.8v supply for SS-PHY
> > + "vddcx" : vdd supply for SS-PHY digital circuit operation
> > +
> > +Example device nodes:
> > +
> > + dwc3_usb2: phy@f92f8800 {
> > + compatible = "qcom,dwc3-usb2";
> > + reg = <0xf92f8800 0x30>;
> > +
> > + clocks = <&cxo>, <&usb2a_phy_sleep_cxc>;
> > + clock-names = "xo", "sleep_a_clk";
> > +
> > + vbus-supply = <&supply>;
> > + vddcx-supply = <&supply>;
> > + v1p8-supply = <&supply>;
> > + v3p3-supply = <&supply>;
> > + };
> > +
> > + dwc3_usb3: phy@f92f8830 {
> > + compatible = "qcom,dwc3-usb3";
> > + reg = <0xf92f8830 0x30>;
> > +
> > + clocks = <&cxo>, <&usb30_mock_utmi_cxc>;
> > + clock-names = "xo", "ref_clk";
> > +
> > + vddcx-supply = <&supply>;
> > + v1p8-supply = <&supply>;
> > + };
>
> Note that I had a look at the bindings only - I don't feel competent to
> review the drivers/usb part of the patch...
Sure, thank you.
Ivan
>
> Thanks!
>
> Pawel
--
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: [RFC 2/2] usb: dwc3: Add Qualcomm DWC3 glue layer driver
On Tue, 2013-08-06 at 13:21 +0100, Pawel Moll wrote:
> On Tue, 2013-08-06 at 12:53 +0100, Ivan T. Ivanov wrote:
> > From: "Ivan T. Ivanov"
> >
> > Signed-off-by: Ivan T. Ivanov
>
> The same comment as for the RFC 1/2 here...
Will fix this.
>
> > .../devicetree/bindings/usb/msm-ssusb.txt | 39 +
> > drivers/usb/dwc3/Kconfig |8 +
> > drivers/usb/dwc3/Makefile |1 +
> > drivers/usb/dwc3/dwc3-msm.c| 175
> >
> > 4 files changed, 223 insertions(+)
> > create mode 100644 drivers/usb/dwc3/dwc3-msm.c
> >
> > diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > index 550b496..313ae0d 100644
> > --- a/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > +++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > @@ -22,6 +22,23 @@ Required "supply-name" examples are:
> > "v1p8" : 1.8v supply for SS-PHY
> > "vddcx" : vdd supply for SS-PHY digital circuit operation
> >
> > +Required properties :
> > +- compatible : should be "qcom,dwc-usb3-msm"
> > +- reg : offset and length of the register set in the memory map
> > + offset and length of the TCSR register for routing USB
> > + signals to either picoPHY0 or picoPHY1.
> > +- clocks = <&usb30_master_cxc>, <&sys_noc_usb3_axi_cxc>,
> > <&usb30_sleep_cxc>, <&usb30_mock_utmi_cxc>;
> > +- clock-names = "core_clk", "iface_clk", "sleep_clk", "utmi_clk";
> > +
> > +Optional properties :
> > +- gdsc-supply : phandle to the globally distributed switch controller
> > + regulator node to the USB controller.
> > +
> > +Sub nodes:
> > +- Sub node for "DWC3- USB3 controller".
> > + This sub node is required property for device node. The properties of
> > this subnode
> > + are specified in dwc3.txt.
>
> Ah, this answers one of my questions - DWC3 comes from Synopsys.
Yes, sorry.
>
> > Example device nodes:
> >
> > dwc3_usb2: phy@f92f8800 {
> > @@ -47,3 +64,25 @@ Example device nodes:
> > vddcx-supply = <&supply>;
> > v1p8-supply = <&supply>;
> > };
> > +
> > + usb@fd4ab000 {
> > + compatible = "qcom,dwc-usb3-msm";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + reg = <0xfd4ab000 0x4>;
> > +
> > + clocks = <&usb30_master_cxc>, <&sys_noc_usb3_axi_cxc>,
> > <&usb30_sleep_cxc>, <&usb30_mock_utmi_cxc>;
> > + clock-names = "core_clk", "iface_clk", "sleep_clk", "utmi_clk";
> > +
> > + gdsc-supply = <&supply>;
> > + ranges;
> > +
> > + dwc3@f920 {
> > + compatible = "snps,dwc3";
>
> Note that the Documentation/devicetree/bindings/usb/dwc3.txt is
> mentioning "synopsys,dwc3" (which is clearly in opposition to the
> vendor-prefixes.txt file) and this compatible value is used in the
> drivers/usb/dwc3/core.c and omap5.dtsi. Unless it has been already fixed
> recently, could you take care of that?
Yes, it is fixed already. Patch is in linux-next
"usb: dwc3: core: switch to snps,dwc3"
>
> > + reg = <0xf920 0xcd00>;
> > + interrupts = <0 131 0>;
> > + interrupt-names = "irq";
> > + usb-phy = <&dwc3_usb2>, <&dwc3_usb3>;
> > + tx-fifo-resize;
> > + };
> > + };
>
> And now I'm really confused... Maybe it's just lack of documentation...
>
> How does the "qcom,dwc-usb3-msm" relate to "qcom,dwc-usb3"?
Not sure from where you get this "qcom,dwc-usb3", but now I think
that "qcom,dwc-usb3" should be enough for compatible.
Thanks,
Ivan
>
> Paweł
--
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: [RFC 1/2] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core
Hi,
On Tue, 2013-08-06 at 15:03 +0100, Mark Rutland wrote:
> On Tue, Aug 06, 2013 at 12:53:10PM +0100, Ivan T. Ivanov wrote:
> > From: "Ivan T. Ivanov"
> >
> > Signed-off-by: Ivan T. Ivanov
> > ---
> > .../devicetree/bindings/usb/msm-ssusb.txt | 49 +++
> > drivers/usb/phy/Kconfig| 11 +
> > drivers/usb/phy/Makefile |2 +
> > drivers/usb/phy/phy-msm-dwc3-usb2.c| 342 +
> > drivers/usb/phy/phy-msm-dwc3-usb3.c| 389
> >
> > 5 files changed, 793 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > create mode 100644 drivers/usb/phy/phy-msm-dwc3-usb2.c
> > create mode 100644 drivers/usb/phy/phy-msm-dwc3-usb3.c
> >
> > diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > new file mode 100644
> > index 000..550b496
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > @@ -0,0 +1,49 @@
> > +MSM SuperSpeed USB3.0 SoC controllers
> > +
> > +Required properities :
> > +- compatible sould be "qcom,dwc3-usb2";
> > +- reg : offset and length of the register set in the memory map
> > +- clocks: <&cxo>, <&usb2a_phy_sleep_cxc>;
>
> Huh? That doesn't describe what these are. These would be better
> explained with a reference to clock-names and a basic description as to
> what the input's called, what it drives, etc, as you've done done for
> the *-supply properties.
Ok, I will fix this.
>
> > +- clock-names: "xo", "sleep_a_clk";
> > +-supply: phandle to the regulator device tree node
> > +Required "supply-name" examples are:
> > + "v1p8" : 1.8v supply for HSPHY
> > + "v3p3" : 3.3v supply for HSPHY
> > + "vbus" : vbus supply for host mode
> > + "vddcx" : vdd supply for HS-PHY digital circuit operation
> > +
> > +Required properities :
> > +- compatible sould be "qcom,dwc3-usb3";
> > +- reg : offset and length of the register set in the memory map
> > +- clocks: <&cxo>, <&usb30_mock_utmi_cxc>;
>
> Similarly, this doesn't describe what the clocks are.
Understood.
>
> > +- clock-names: "xo", "ref_clk";
> > +-supply: phandle to the regulator device tree node
> > +Required "supply-name" examples are:
> > + "v1p8" : 1.8v supply for SS-PHY
> > + "vddcx" : vdd supply for SS-PHY digital circuit operation
> > +
> > +Example device nodes:
> > +
> > + dwc3_usb2: phy@f92f8800 {
> > + compatible = "qcom,dwc3-usb2";
> > + reg = <0xf92f8800 0x30>;
> > +
> > + clocks = <&cxo>, <&usb2a_phy_sleep_cxc>;
> > + clock-names = "xo", "sleep_a_clk";
> > +
> > + vbus-supply = <&supply>;
> > + vddcx-supply = <&supply>;
> > + v1p8-supply = <&supply>;
> > + v3p3-supply = <&supply>;
> > + };
> > +
> > + dwc3_usb3: phy@f92f8830 {
> > + compatible = "qcom,dwc3-usb3";
> > + reg = <0xf92f8830 0x30>;
> > +
> > + clocks = <&cxo>, <&usb30_mock_utmi_cxc>;
> > + clock-names = "xo", "ref_clk";
> > +
> > + vddcx-supply = <&supply>;
> > + v1p8-supply = <&supply>;
> > + };
>
>
> Those regster banks look suspiciously close. Are these the same IP
> block? Can they ever appear separately?
>
They are part of the wrapper Qualcomm logic around Synopsys USB3 core.
In this sense they are part of the one IP, I believe. Manage them from
separate drivers simplify code.
> Do the drivers not trample each other when messing with shared clocks
> and regulators?
>
Regulators and clocks have reference counting, right?, so this should
be safe. Even if they are part of the one driver, clocks and regulators
could be switched off only if both PHY's do not use them.
Thanks,
Ivan
> Thanks,
> Mark.
--
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: [RFC 2/2] usb: dwc3: Add Qualcomm DWC3 glue layer driver
Hi, On Tue, 2013-08-06 at 15:07 +0100, Mark Rutland wrote: > On Tue, Aug 06, 2013 at 12:53:11PM +0100, Ivan T. Ivanov wrote: > > From: "Ivan T. Ivanov" > > What does the "glue layer" do? Is it an actual piece of hardware, or > just some platform-specific code? > It is hardware layer around Synopsys DesignWare USB3 core. The term 'glue layer' is what is used in TI OMAP's and Samsung Exynos drivers implementations. > > > > Signed-off-by: Ivan T. Ivanov > > --- > > .../devicetree/bindings/usb/msm-ssusb.txt | 39 + > > drivers/usb/dwc3/Kconfig |8 + > > drivers/usb/dwc3/Makefile |1 + > > drivers/usb/dwc3/dwc3-msm.c| 175 > > > > 4 files changed, 223 insertions(+) > > create mode 100644 drivers/usb/dwc3/dwc3-msm.c > > > > diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt > > b/Documentation/devicetree/bindings/usb/msm-ssusb.txt > > index 550b496..313ae0d 100644 > > --- a/Documentation/devicetree/bindings/usb/msm-ssusb.txt > > +++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt > > @@ -22,6 +22,23 @@ Required "supply-name" examples are: > > "v1p8" : 1.8v supply for SS-PHY > > "vddcx" : vdd supply for SS-PHY digital circuit operation > > > > +Required properties : > > +- compatible : should be "qcom,dwc-usb3-msm" > > +- reg : offset and length of the register set in the memory map > > + offset and length of the TCSR register for routing USB > > + signals to either picoPHY0 or picoPHY1. > > +- clocks = <&usb30_master_cxc>, <&sys_noc_usb3_axi_cxc>, > > <&usb30_sleep_cxc>, <&usb30_mock_utmi_cxc>; > > Similarly to my comment on patch 1, these need to be described better. Sure, will fix this. Thanks, Ivan > > Thanks, > Mark. -- 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: [RFC 2/2] usb: dwc3: Add Qualcomm DWC3 glue layer driver
On Tue, 2013-08-06 at 16:15 +0100, Pawel Moll wrote: > On Tue, 2013-08-06 at 14:46 +0100, Ivan T. Ivanov wrote: > > > > + reg = <0xf920 0xcd00>; > > > > + interrupts = <0 131 0>; > > > > + interrupt-names = "irq"; > > > > + usb-phy = <&dwc3_usb2>, <&dwc3_usb3>; > > > > + tx-fifo-resize; > > > > + }; > > > > + }; > > > > > > And now I'm really confused... Maybe it's just lack of documentation... > > > > > > How does the "qcom,dwc-usb3-msm" relate to "qcom,dwc-usb3"? > > > > Not sure from where you get this "qcom,dwc-usb3", but now I think > > that "qcom,dwc-usb3" should be enough for compatible. > > The other patch introduces "qcom,dwc3-usb3" compatible value... Oh, of course. Intention was that "qcom,dwc-usb3" will handle SS-PHY, while "qcom,dwc-usb2" will handle HS-PHY. Probably it will better if I rename them to "qcom,dwc-ssphy" and "qcom,dwc-hsphy". Regards, Ivan > > Paweł -- 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
[RFC PATCH v2 3/3] usb: dwc3: Add Qualcomm DWC3 glue layer driver
From: "Ivan T. Ivanov"
DWC3 glue layer is hardware layer around Synopsys DesignWare
USB3 core. Its purpose is to supply Synopsys IP with required
clocks, voltages and interface it with the rest of the SoC.
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/dwc3/Kconfig|8 ++
drivers/usb/dwc3/Makefile |1 +
drivers/usb/dwc3/dwc3-msm.c | 174 +++
3 files changed, 183 insertions(+)
create mode 100644 drivers/usb/dwc3/dwc3-msm.c
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 3e225d5..e2032c4 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -70,6 +70,14 @@ config USB_DWC3_PCI
One such PCIe-based platform is Synopsys' PCIe HAPS model of
this IP.
+config USB_DWC3_MSM
+ tristate "Qualcomm MSM/APQ Platforms"
+ default USB_DWC3
+ select USB_MSM_DWC3_PHYS
+ help
+ Recent Qualcomm SoCs ship with one DesignWare Core USB3 IP inside,
+ say 'Y' or 'M' if you have one such device.
+
comment "Debugging features"
config USB_DWC3_DEBUG
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index dd17601..5226681 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -32,3 +32,4 @@ endif
obj-$(CONFIG_USB_DWC3_OMAP)+= dwc3-omap.o
obj-$(CONFIG_USB_DWC3_EXYNOS) += dwc3-exynos.o
obj-$(CONFIG_USB_DWC3_PCI) += dwc3-pci.o
+obj-$(CONFIG_USB_DWC3_MSM) += dwc3-msm.o
diff --git a/drivers/usb/dwc3/dwc3-msm.c b/drivers/usb/dwc3/dwc3-msm.c
new file mode 100644
index 000..f442249
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-msm.c
@@ -0,0 +1,174 @@
+/* Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct dwc3_msm {
+ struct device *dev;
+ void __iomem*base;
+
+ struct clk *core_clk;
+ struct clk *iface_clk;
+ struct clk *sleep_clk;
+ struct clk *utmi_clk;
+
+ struct regulator*gdsc;
+};
+
+static int dwc3_msm_probe(struct platform_device *pdev)
+{
+ struct device_node *node = pdev->dev.of_node;
+ struct dwc3_msm *mdwc;
+ struct resource *res;
+ void __iomem *tcsr;
+ int ret = 0;
+
+ dev_info(&pdev->dev, "MSM DWC3\n");
+
+ mdwc = devm_kzalloc(&pdev->dev, sizeof(*mdwc), GFP_KERNEL);
+ if (!mdwc) {
+ dev_err(&pdev->dev, "not enough memory\n");
+ return -ENOMEM;
+ }
+
+ platform_set_drvdata(pdev, mdwc);
+ mdwc->dev = &pdev->dev;
+
+ mdwc->gdsc = devm_regulator_get(mdwc->dev, "gdsc");
+
+ mdwc->core_clk = devm_clk_get(&pdev->dev, "core_clk");
+ if (IS_ERR(mdwc->core_clk)) {
+ dev_err(&pdev->dev, "failed to get core_clk\n");
+ return PTR_ERR(mdwc->core_clk);
+ }
+
+ mdwc->iface_clk = devm_clk_get(&pdev->dev, "iface_clk");
+ if (IS_ERR(mdwc->iface_clk)) {
+ dev_err(&pdev->dev, "failed to get iface_clk\n");
+ return PTR_ERR(mdwc->iface_clk);
+ }
+
+ mdwc->sleep_clk = devm_clk_get(&pdev->dev, "sleep_clk");
+ if (IS_ERR(mdwc->sleep_clk)) {
+ dev_err(&pdev->dev, "failed to get sleep_clk\n");
+ return PTR_ERR(mdwc->sleep_clk);
+ }
+
+ mdwc->utmi_clk = devm_clk_get(&pdev->dev, "utmi_clk");
+ if (IS_ERR(mdwc->utmi_clk)) {
+ dev_err(&pdev->dev, "failed to get utmi_clk\n");
+ return PTR_ERR(mdwc->utmi_clk);
+ }
+
+ if (!IS_ERR(mdwc->gdsc)) {
+ ret = regulator_enable(mdwc->gdsc);
+ if (ret)
+ dev_err(mdwc->dev, "unable to enable usb3 gdsc\n");
+ }
+
+ /*
+* DWC3 Core requires its CORE CLK (aka master / bus clk) to
+* run at 125Mhz in SSUSB mode and >60MHZ for HSUSB mode.
+*/
+ clk_set_rate(mdwc->core_clk, 12500);
+ clk_prepare_enable(mdwc->core_clk);
+ clk_prepare_enable(mdwc->iface_clk);
+
[RFC PATCH v2 0/3] DWC3 USB support for Qualcomm platform
From: "Ivan T. Ivanov" Hi, These patches add basic support for USB3.0 controllers found on MSM platforms. USB3.0 core is based on Synopsys DesignWare SuperSpeed IP. Changes since first version: * Split devicetree bindings description file to separate patch * Address comments for device bindings description * Fix typo in 'gdsc' requlator name. With fake regulators and clocks support drivers could be successfully loaded, but nothing more, of course. Generated on top of Felipe 'testing' branch. Regards, Ivan Ivan T. Ivanov (3): usb: dwc3: msm: Add device tree binding information usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core usb: dwc3: Add Qualcomm DWC3 glue layer driver .../devicetree/bindings/usb/msm-ssusb.txt | 101 + drivers/usb/dwc3/Kconfig |8 + drivers/usb/dwc3/Makefile |1 + drivers/usb/dwc3/dwc3-msm.c| 174 + drivers/usb/phy/Kconfig| 11 + drivers/usb/phy/Makefile |2 + drivers/usb/phy/phy-msm-dwc3-hs.c | 340 + drivers/usb/phy/phy-msm-dwc3-ss.c | 387 8 files changed, 1024 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt create mode 100644 drivers/usb/dwc3/dwc3-msm.c create mode 100644 drivers/usb/phy/phy-msm-dwc3-hs.c create mode 100644 drivers/usb/phy/phy-msm-dwc3-ss.c -- 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
[RFC PATCH v2 1/3] usb: dwc3: msm: Add device tree binding information
From: "Ivan T. Ivanov"
MSM USB3.0 core wrapper consist of USB3.0 IP (SNPS)
and HS, SS PHY's controll and configuration registers.
It could operate in device mode (SS, HS, FS) and host
mode (SS, HS, FS, LS).
Signed-off-by: Ivan T. Ivanov
---
.../devicetree/bindings/usb/msm-ssusb.txt | 101
1 file changed, 101 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt
diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt
b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
new file mode 100644
index 000..7a97163
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
@@ -0,0 +1,101 @@
+MSM SuperSpeed DWC3 USB SoC controller
+
+Required properities :
+- compatible : sould be "qcom,dwc3-hsphy";
+- reg : offset and length of the register set in the memory map
+- clocks : phandles to clock instances of the device tree nodes
+- clock-names :
+ "xo" : External reference clock 19 MHz
+ "sleep_a_clk" : Sleep clock, used when USB3 core goes into low
+ power mode (U3).
+-supply : phandle to the regulator device tree node
+Required "supply-name" are:
+ "v1p8" : 1.8v supply for HSPHY
+ "v3p3" : 3.3v supply for HSPHY
+ "vbus" : vbus supply for host mode
+ "vddcx" : vdd supply for HS-PHY digital circuit operation
+
+Required properities :
+- compatible : sould be "qcom,dwc3-ssphy";
+- reg : offset and length of the register set in the memory map
+- clocks : phandles to clock instances of the device tree nodes
+- clock-names :
+ "xo" : External reference clock 19 MHz
+ "ref_clk" : Reference clock - used in host mode.
+-supply : phandle to the regulator device tree node
+Required "supply-name" are:
+ "v1p8" : 1.8v supply for SS-PHY
+ "vddcx" : vdd supply for SS-PHY digital circuit operation
+
+Required properties :
+- compatible : should be "qcom,dwc3"
+- reg : offset and length of the register set in the memory map
+ offset and length of the TCSR register for routing USB
+ signals to either picoPHY0 or picoPHY1.
+- clocks : phandles to clock instances of the device tree nodes
+- clock-names :
+ "core_clk" : Master/Core clock, have to be >= 125 MHz for SS
+ operation and >= 60MHz for HS operation
+ "iface_clk" : System bus AXI clock
+ "sleep_clk" : Sleep clock, used when USB3 core goes into low
+ power mode (U3).
+ "utmi_clk" : Generated by HS-PHY. Used to clock the low power
+ parts of thr HS Link layer.
+
+Optional properties :
+- gdsc-supply : phandle to the globally distributed switch controller
+ regulator node to the USB controller.
+
+Sub nodes:
+- Sub node for "DWC3 USB3 controller".
+ This sub node is required property for device node. The properties
+ of this subnode are specified in dwc3.txt.
+
+Example device nodes:
+
+ dwc3_hsphy: phy@f92f8800 {
+ compatible = "qcom,dwc3-hsphy";
+ reg = <0xf92f8800 0x30>;
+
+ clocks = <&cxo>, <&usb2a_phy_sleep_cxc>;
+ clock-names = "xo", "sleep_a_clk";
+
+ vbus-supply = <&supply>;
+ vddcx-supply = <&supply>;
+ v1p8-supply = <&supply>;
+ v3p3-supply = <&supply>;
+ };
+
+ dwc3_ssphy: phy@f92f8830 {
+ compatible = "qcom,dwc3-ssphy";
+ reg = <0xf92f8830 0x30>;
+
+ clocks = <&cxo>, <&usb30_mock_utmi_cxc>;
+ clock-names = "xo", "ref_clk";
+
+ vddcx-supply = <&supply>;
+ v1p8-supply = <&supply>;
+ };
+
+ usb@fd4ab000 {
+ compatible = "qcom,dwc3";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0xfd4ab000 0x4>;
+
+ clocks = <&usb30_master_cxc>, <&sys_noc_usb3_axi_cxc>,
+ <&usb30_sleep_cxc>, <&usb30_mock_utmi_cxc>;
+ clock-names = "core_clk", "iface_clk", "sleep_clk", "utmi_clk";
+
+ gdsc-supply = <&supply>;
+ ranges;
+
+ dwc3@f920 {
+ compatible = "snps,dwc3";
+ reg = <0xf920 0xcd00>;
+ interrupts = <0 131 0>;
+ interrupt-names = "irq";
+ usb-phy = <&dwc3_hsphy>, <&dwc3_ssphy>;
+ tx-fifo-resize;
+ };
+ };
--
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
[RFC PATCH v2 2/3] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core
From: "Ivan T. Ivanov"
These drivers handles control and configuration of the HS
and SS USB PHY transceivers. They are part of the driver
which manage Synopsys DesignWare USB3 controller stack
inside Qualcomm SoC's.
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/phy/Kconfig | 11 ++
drivers/usb/phy/Makefile |2 +
drivers/usb/phy/phy-msm-dwc3-hs.c | 340
drivers/usb/phy/phy-msm-dwc3-ss.c | 387 +
4 files changed, 740 insertions(+)
create mode 100644 drivers/usb/phy/phy-msm-dwc3-hs.c
create mode 100644 drivers/usb/phy/phy-msm-dwc3-ss.c
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 5443958..40e83b5 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -202,6 +202,17 @@ config USB_RCAR_PHY
To compile this driver as a module, choose M here: the
module will be called phy-rcar-usb.
+config USB_MSM_DWC3_PHYS
+ tristate "Qualcomm DWC3 USB controller PHY's support"
+ depends on (USB || USB_GADGET) && ARCH_MSM
+ select USB_PHY
+ help
+ Enable this to support the USB PHY transceivers on MSM chips with
+ DWC3 USB core. It handles PHY initialization, clock management
+ required after resetting the hardware and power management.
+ This driver is required even for peripheral only or host only
+ mode configurations.
+
config USB_ULPI
bool "Generic ULPI Transceiver Driver"
depends on ARM
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 98730ca..ddaa11c 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -24,6 +24,8 @@ obj-$(CONFIG_USB_EHCI_TEGRA) += phy-tegra-usb.o
obj-$(CONFIG_USB_GPIO_VBUS)+= phy-gpio-vbus-usb.o
obj-$(CONFIG_USB_ISP1301) += phy-isp1301.o
obj-$(CONFIG_USB_MSM_OTG) += phy-msm-usb.o
+obj-$(CONFIG_USB_MSM_DWC3_PHYS)+= phy-msm-dwc3-hs.o
+obj-$(CONFIG_USB_MSM_DWC3_PHYS)+= phy-msm-dwc3-ss.o
obj-$(CONFIG_USB_MV_OTG) += phy-mv-usb.o
obj-$(CONFIG_USB_MXS_PHY) += phy-mxs-usb.o
obj-$(CONFIG_USB_RCAR_PHY) += phy-rcar-usb.o
diff --git a/drivers/usb/phy/phy-msm-dwc3-hs.c
b/drivers/usb/phy/phy-msm-dwc3-hs.c
new file mode 100644
index 000..d91c595
--- /dev/null
+++ b/drivers/usb/phy/phy-msm-dwc3-hs.c
@@ -0,0 +1,340 @@
+/* Copyright (c) 2013, Code Aurora Forum. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * USB QSCRATCH Hardware registers
+ */
+#define QSCRATCH_CTRL_REG (0x04)
+#define QSCRATCH_GENERAL_CFG (0x08)
+#define PHY_CTRL_REG (0x10)
+#define PARAMETER_OVERRIDE_X_REG (0x14)
+#define CHARGING_DET_CTRL_REG (0x18)
+#define CHARGING_DET_OUTPUT_REG(0x1c)
+#define ALT_INTERRUPT_EN_REG (0x20)
+#define PHY_IRQ_STAT_REG (0x24)
+#define CGCTL_REG (0x28)
+
+#define PHY_3P3_VOL_MIN305 /* uV */
+#define PHY_3P3_VOL_MAX330 /* uV */
+#define PHY_3P3_HPM_LOAD 16000 /* uA */
+
+#define PHY_1P8_VOL_MIN180 /* uV */
+#define PHY_1P8_VOL_MAX180 /* uV */
+#define PHY_1P8_HPM_LOAD 19000 /* uA */
+
+/* TODO: these are suspicious */
+#define USB_VDDCX_NO 1 /* uV */
+#define USB_VDDCX_MIN 5 /* uV */
+#define USB_VDDCX_MAX 7 /* uV */
+
+struct msm_dwc3_hs_phy {
+ struct usb_phy phy;
+ void __iomem*base;
+ struct device *dev;
+
+ struct clk *xo_clk;
+ struct clk *sleep_a_clk;
+
+ struct regulator*v3p3;
+ struct regulator*v1p8;
+ struct regulator*vddcx;
+ struct regulator*vbus;
+};
+
+#definephy_to_dwc3_phy(x) container_of((x), struct
msm_dwc3_hs_phy, phy)
+
+
+/**
+ *
+ * Write register with debug info.
+ *
+ * @base - DWC3 base virtual address.
Re: [RFC PATCH v2 3/3] usb: dwc3: Add Qualcomm DWC3 glue layer driver
Hi, On Fri, 2013-08-09 at 16:32 +0300, Felipe Balbi wrote: > On Fri, Aug 09, 2013 at 12:53:47PM +0300, Ivan T. Ivanov wrote: > > From: "Ivan T. Ivanov" > > > > DWC3 glue layer is hardware layer around Synopsys DesignWare > > USB3 core. Its purpose is to supply Synopsys IP with required > > clocks, voltages and interface it with the rest of the SoC. > > > > Signed-off-by: Ivan T. Ivanov > > same comments from previous version. > Sorry, I have somehow missed Your email. I will address them shortly. Regard, Ivan -- 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: [RFC 2/2] usb: dwc3: Add Qualcomm DWC3 glue layer driver
Hi,
On Fri, 2013-08-09 at 16:23 +0300, Felipe Balbi wrote:
> Hi,
>
> On Tue, Aug 06, 2013 at 02:53:11PM +0300, Ivan T. Ivanov wrote:
> > diff --git a/drivers/usb/dwc3/dwc3-msm.c b/drivers/usb/dwc3/dwc3-msm.c
> > new file mode 100644
> > index 000..e509abc
> > --- /dev/null
> > +++ b/drivers/usb/dwc3/dwc3-msm.c
> > @@ -0,0 +1,175 @@
> > +#undef CONFIG_REGULATOR
>
> why ??
>
1. This shows that driver is still not fully tested
Regulators support is still missing in the MSM
2. Helps me to load driver successfully.
> > +static int dwc3_msm_probe(struct platform_device *pdev)
> > +{
> > + struct device_node *node = pdev->dev.of_node;
> > + struct dwc3_msm *mdwc;
> > + struct resource *res;
> > + void __iomem *tcsr;
> > + int ret = 0;
> > +
> > + dev_info(&pdev->dev, "MSM DWC3\n");
>
> please don't. This is hardly necessary.
Sure, this will be removed.
>
> > + mdwc = devm_kzalloc(&pdev->dev, sizeof(*mdwc), GFP_KERNEL);
> > + if (!mdwc) {
> > + dev_err(&pdev->dev, "not enough memory\n");
>
> this message isn't needed either
ok.
>
> > + /*
> > +* DWC3 Core requires its CORE CLK (aka master / bus clk) to
> > +* run at 125Mhz in SSUSB mode and >60MHZ for HSUSB mode.
> > +*/
> > + clk_set_rate(mdwc->core_clk, 12500);
>
> if this is dwc3's core clock, why don't we teach dwc3.ko about this
> requirement ? Just make sure to have it optional, since x86 and OMAP
> wouldn't need direct fiddling with the clocks.
I have to check whether DWC3 core or Qcom wrapper requires this clock.
>
> > + clk_prepare_enable(mdwc->core_clk);
> > + clk_prepare_enable(mdwc->iface_clk);
> > + clk_prepare_enable(mdwc->sleep_clk);
> > + clk_prepare_enable(mdwc->utmi_clk);
>
> do you really need to enable your clocks here ? Why don't you enable
> them on runtime_resume and disable on runtime_suspend ?
I will like to make it working first and then will improve
power management.
>
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + tcsr = devm_ioremap_resource(&pdev->dev, res);
> > + if (!tcsr) {
> > + dev_dbg(&pdev->dev, "tcsr ioremap failed\n");
>
> no need to ioremap, also you're likely leaking clocks and regulators
> enabled here.
>
> Make sure to have something like:
>
> if (!tcsr)
> goto err_disable_clocks;
>
> /* TODO This has to be revised */\
>
> [...]
>
Sure.
> > + } else {
> > + /* TODO: This has to be revised */
> > +
> > + /* Enable USB3 on the primary USB port. */
> > + writel_relaxed(0x1, tcsr);
> > + /*
> > +* Ensure that TCSR write is completed before
> > +* USB registers initialization.
> > +*/
> > + mb();
>
> why don't you use writel() instead. It will add the memory barrier for
> you.
Ok.
Thanks
Ivan
--
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 3/6] usb: phy: msm: Migrate to Managed Device Resource allocation
Hi,
On Mon, 2013-07-29 at 15:25 +0300, Felipe Balbi wrote:
> Hi,
>
> On Mon, Jul 29, 2013 at 10:04:21AM +0300, Ivan T. Ivanov wrote:
> > motg->irq = platform_get_irq(pdev, 0);
> > - if (!motg->irq) {
> > + if (motg->irq < 0) {
>
> looks like this particular hunk isn't part of $subject.
>
Indeed. Will remove it.
Thanks,
Ivan
--
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: [RFC PATCH v2 1/3] usb: dwc3: msm: Add device tree binding information
Hi,
On Fri, 2013-08-09 at 10:31 -0500, Kumar Gala wrote:
> On Aug 9, 2013, at 4:53 AM, Ivan T. Ivanov wrote:
>
> > From: "Ivan T. Ivanov"
> >
> > MSM USB3.0 core wrapper consist of USB3.0 IP (SNPS)
>
> probably good to spell out Synopsys rather than SNPS
I could make it look like this? Synopsys (SNPS)
>
> > and HS, SS PHY's controll and configuration registers.
> >
> > It could operate in device mode (SS, HS, FS) and host
> > mode (SS, HS, FS, LS).
> >
> > Signed-off-by: Ivan T. Ivanov
> > ---
> > .../devicetree/bindings/usb/msm-ssusb.txt | 101
> >
> > 1 file changed, 101 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt
> >
> > diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > new file mode 100644
> > index 000..7a97163
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
> > @@ -0,0 +1,101 @@
> > +MSM SuperSpeed DWC3 USB SoC controller
> > +
>
> We should have a heading here like:
>
> DWC3 Highspeed USB PHY
Ok, I will add these headings.
>
> > +Required properities :
> > +- compatible : sould be "qcom,dwc3-hsphy";
> > +- reg : offset and length of the register set in the memory map
> > +- clocks : phandles to clock instances of the device tree nodes
> > +- clock-names :
> > + "xo" : External reference clock 19 MHz
> > + "sleep_a_clk" : Sleep clock, used when USB3 core goes into low
> > + power mode (U3).
> > +-supply : phandle to the regulator device tree node
> > +Required "supply-name" are:
> > + "v1p8" : 1.8v supply for HSPHY
> > + "v3p3" : 3.3v supply for HSPHY
> > + "vbus" : vbus supply for host mode
> > + "vddcx" : vdd supply for HS-PHY digital circuit operation
> > +
>
> DWC3 Superspeed USB PHY
>
> > +Required properities :
> > +- compatible : sould be "qcom,dwc3-ssphy";
> > +- reg : offset and length of the register set in the memory map
> > +- clocks : phandles to clock instances of the device tree nodes
> > +- clock-names :
> > + "xo" : External reference clock 19 MHz
> > + "ref_clk" : Reference clock - used in host mode.
> > +-supply : phandle to the regulator device tree node
> > +Required "supply-name" are:
> > + "v1p8" : 1.8v supply for SS-PHY
> > + "vddcx" : vdd supply for SS-PHY digital circuit operation
> > +
>
> DWC3 controller
>
> > +Required properties :
> > +- compatible : should be "qcom,dwc3"
> > +- reg : offset and length of the register set in the memory map
> > + offset and length of the TCSR register for routing USB
> > + signals to either picoPHY0 or picoPHY1.
> > +- clocks : phandles to clock instances of the device tree nodes
> > +- clock-names :
> > + "core_clk" : Master/Core clock, have to be >= 125 MHz for SS
> > + operation and >= 60MHz for HS operation
> > + "iface_clk" : System bus AXI clock
> > + "sleep_clk" : Sleep clock, used when USB3 core goes into low
> > + power mode (U3).
> > + "utmi_clk" : Generated by HS-PHY. Used to clock the low power
> > + parts of thr HS Link layer.
> > +
> > +Optional properties :
> > +- gdsc-supply : phandle to the globally distributed switch controller
> > + regulator node to the USB controller.
> > +
> > +Sub nodes:
> > +- Sub node for "DWC3 USB3 controller".
> > + This sub node is required property for device node. The properties
> > + of this subnode are specified in dwc3.txt.
>
> Is tx-fifo-resize required for qcom,dwc3? if so we should call that out in
> the binding.
It looks like this is used in apq8084.dtsi (codeaurora repo)
>
> > +
> > +Example device nodes:
> > +
> > + dwc3_hsphy: phy@f92f8800 {
> > + compatible = "qcom,dwc3-hsphy";
> > + reg = <0xf92f8800 0x30>;
> > +
> > + clocks = <&cxo>, <&usb2a_phy_sleep_cxc>;
> > + clock-names = "xo", "sleep_a_clk";
> > +
> > + vbus-supply = <&supply>;
> > + vddcx-supply = <&supply>;
> > + v1p8-supply = <&supply>;
> > + v3p3-supply = <&supply>;
> > + };
&g
Re: [RFC PATCH v2 1/3] usb: dwc3: msm: Add device tree binding information
Hi, On Mon, 2013-08-12 at 13:04 -0500, Felipe Balbi wrote: > On Fri, Aug 09, 2013 at 10:31:58AM -0500, Kumar Gala wrote: > > > > On Aug 9, 2013, at 4:53 AM, Ivan T. Ivanov wrote: > > > > > From: "Ivan T. Ivanov" > > > > > > MSM USB3.0 core wrapper consist of USB3.0 IP (SNPS) > > > > probably good to spell out Synopsys rather than SNPS > > Synopsys (the company) has always used snps in their bindings though. > > > > +Required properities : > > > +- compatible : sould be "qcom,dwc3-hsphy"; > > > +- reg : offset and length of the register set in the memory map > > > +- clocks : phandles to clock instances of the device tree nodes > > > +- clock-names : > > > + "xo" : External reference clock 19 MHz > > > + "sleep_a_clk" : Sleep clock, used when USB3 core goes into low > > > + power mode (U3). > > > +-supply : phandle to the regulator device tree node > > > +Required "supply-name" are: > > > + "v1p8" : 1.8v supply for HSPHY > > > + "v3p3" : 3.3v supply for HSPHY > > > + "vbus" : vbus supply for host mode > > > + "vddcx" : vdd supply for HS-PHY digital circuit operation > > I believe these regulators belong to the PHY, not DWC3. Please write a > PHY driver. > There is already usb phy drivers for these?? [PATCH v2 2/3] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core > > > +Required properities : > > > +- compatible : sould be "qcom,dwc3-ssphy"; > > > +- reg : offset and length of the register set in the memory map > > > +- clocks : phandles to clock instances of the device tree nodes > > > +- clock-names : > > > + "xo" : External reference clock 19 MHz > > > + "ref_clk" : Reference clock - used in host mode. > > > +-supply : phandle to the regulator device tree node > > > +Required "supply-name" are: > > > + "v1p8" : 1.8v supply for SS-PHY > > > + "vddcx" : vdd supply for SS-PHY digital circuit operation > > likewise, these regulators should be moved to the PHY driver. > > > > +Required properties : > > > +- compatible : should be "qcom,dwc3" > > > +- reg : offset and length of the register set in the memory map > > > + offset and length of the TCSR register for routing USB > > > + signals to either picoPHY0 or picoPHY1. > > > +- clocks : phandles to clock instances of the device tree nodes > > > +- clock-names : > > > + "core_clk" : Master/Core clock, have to be >= 125 MHz for SS > > > + operation and >= 60MHz for HS operation > > > + "iface_clk" : System bus AXI clock > > > + "sleep_clk" : Sleep clock, used when USB3 core goes into low > > > + power mode (U3). > > > + "utmi_clk" : Generated by HS-PHY. Used to clock the low power > > > + parts of thr HS Link layer. > > > + > > > +Optional properties : > > > +- gdsc-supply : phandle to the globally distributed switch controller > > > + regulator node to the USB controller. > > > + > > > +Sub nodes: > > > +- Sub node for "DWC3 USB3 controller". > > > + This sub node is required property for device node. The properties > > > + of this subnode are specified in dwc3.txt. > > > > Is tx-fifo-resize required for qcom,dwc3? if so we should call that > > out in the binding. > > AFAICT that's only needed for OMAP5 ES1.0. Unless Qualcomm also screwed > up default TX FIFO sizes :-p Or it is intentional? :-) Look at [1] dwc3@f920 Ivan [1] https://www.codeaurora.org/cgit/quic/la/kernel/msm/tree/arch/arm/boot/dts/apq8084.dtsi?h=msm-3.4 > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 1/3] usb: dwc3: msm: Add device tree binding information
Hi, On Tue, 2013-08-13 at 13:57 -0600, Stephen Warren wrote: > On 08/09/2013 03:53 AM, Ivan T. Ivanov wrote: > > From: "Ivan T. Ivanov" > > > > MSM USB3.0 core wrapper consist of USB3.0 IP (SNPS) > > and HS, SS PHY's controll and configuration registers. > > s/controll/control/ > Thanks. > > It could operate in device mode (SS, HS, FS) and host > > mode (SS, HS, FS, LS). > > > diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt > > b/Documentation/devicetree/bindings/usb/msm-ssusb.txt > > > +MSM SuperSpeed DWC3 USB SoC controller > > + > > +Required properities : > > +- compatible : sould be "qcom,dwc3-hsphy"; > ... > > +Required properities : > > +- compatible : sould be "qcom,dwc3-ssphy"; > > I would expect different compatible values to be documented in different > files. It is easy to see connection between them when they are in one file. Drivers are useless without each other. > > > +Optional properties : > > +- gdsc-supply : phandle to the globally distributed switch controller > > + regulator node to the USB controller. > > Which of the 3 compatible values that were described above is that > property optional for? "qcom,dwc3". I will make this more explicit. > > > +Sub nodes: > > +- Sub node for "DWC3 USB3 controller". > > + This sub node is required property for device node. The properties > > + of this subnode are specified in dwc3.txt. > > Why not represent the PHY and USB controller as separate top-level > nodes? They can point at each-other with phandles if they need to know > each-others' identity. "qcom,dwc3" (glue layer) driver have to be loaded before "snps,dwc3", actual USB3 IP. "qcom,dwc3" provide required clocks and power supplies to the USB3 IP core. Regards, Ivan -- 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: [RFC 2/2] usb: dwc3: Add Qualcomm DWC3 glue layer driver
Hi,
On Mon, 2013-08-12 at 13:24 -0500, Felipe Balbi wrote:
> On Fri, Aug 09, 2013 at 07:09:18PM +0300, Ivan T. Ivanov wrote:
> > Hi,
> >
> > On Fri, 2013-08-09 at 16:23 +0300, Felipe Balbi wrote:
> > > Hi,
> > >
> > > On Tue, Aug 06, 2013 at 02:53:11PM +0300, Ivan T. Ivanov wrote:
> > > > diff --git a/drivers/usb/dwc3/dwc3-msm.c b/drivers/usb/dwc3/dwc3-msm.c
> > > > new file mode 100644
> > > > index 000..e509abc
> > > > --- /dev/null
> > > > +++ b/drivers/usb/dwc3/dwc3-msm.c
> > > > @@ -0,0 +1,175 @@
> > > > +#undef CONFIG_REGULATOR
> > >
> > > why ??
> > >
> >
> > 1. This shows that driver is still not fully tested
> >Regulators support is still missing in the MSM
> > 2. Helps me to load driver successfully.
>
> Then remove all the regulator-related code from this.
I would like to keep them. I will just remove #undef line.
Code will continue to build fine. And once regulators drivers
are upstreamed this driver 'will not' require further
modifications.
>
> > > > + clk_prepare_enable(mdwc->core_clk);
> > > > + clk_prepare_enable(mdwc->iface_clk);
> > > > + clk_prepare_enable(mdwc->sleep_clk);
> > > > + clk_prepare_enable(mdwc->utmi_clk);
> > >
> > > do you really need to enable your clocks here ? Why don't you enable
> > > them on runtime_resume and disable on runtime_suspend ?
> >
> > I will like to make it working first and then will improve
> > power management.
>
> alright, makes sense.
>
> > > > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > > > + tcsr = devm_ioremap_resource(&pdev->dev, res);
> > > > + if (!tcsr) {
> > > > + dev_dbg(&pdev->dev, "tcsr ioremap failed\n");
> > >
> > > no need to ioremap, also you're likely leaking clocks and regulators
> > > enabled here.
> > >
> > > Make sure to have something like:
> > >
> > > if (!tcsr)
> > > goto err_disable_clocks;
> > >
> > > /* TODO This has to be revised */\
> > >
> > > [...]
> > >
> >
> > Sure.
>
> just to make it clear, I meant to say that you don't need to print the
> error message :-)
Yes. I got it.
Regards,
Ivan
--
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: [RFC 2/2] usb: dwc3: Add Qualcomm DWC3 glue layer driver
Hi, On Fri, 2013-08-09 at 16:23 +0300, Felipe Balbi wrote: > > > + /* > > +* DWC3 Core requires its CORE CLK (aka master / bus clk) to > > +* run at 125Mhz in SSUSB mode and >60MHZ for HSUSB mode. > > +*/ > > + clk_set_rate(mdwc->core_clk, 12500); > > if this is dwc3's core clock, why don't we teach dwc3.ko about this > requirement ? Just make sure to have it optional, since x86 and OMAP > wouldn't need direct fiddling with the clocks. I believe this is Qualcomm specific requirement. Something is modified inside DWC in respect of the clocks. I will like to keep this here, in the glue layer driver. Regards, Ivan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/3] usb: dwc3: Add Qualcomm DWC3 glue layer driver
From: "Ivan T. Ivanov"
DWC3 glue layer is hardware layer around Synopsys DesignWare
USB3 core. Its purpose is to supply Synopsys IP with required
clocks, voltages and interface it with the rest of the SoC.
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/dwc3/Kconfig|8 ++
drivers/usb/dwc3/Makefile |1 +
drivers/usb/dwc3/dwc3-msm.c | 169 +++
3 files changed, 178 insertions(+)
create mode 100644 drivers/usb/dwc3/dwc3-msm.c
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index f969ea2..d845966 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -71,6 +71,14 @@ config USB_DWC3_PCI
One such PCIe-based platform is Synopsys' PCIe HAPS model of
this IP.
+config USB_DWC3_MSM
+ tristate "Qualcomm MSM/APQ Platforms"
+ default USB_DWC3
+ select USB_MSM_DWC3_PHYS
+ help
+ Recent Qualcomm SoCs ship with one DesignWare Core USB3 IP inside,
+ say 'Y' or 'M' if you have one such device.
+
comment "Debugging features"
config USB_DWC3_DEBUG
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index dd17601..5226681 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -32,3 +32,4 @@ endif
obj-$(CONFIG_USB_DWC3_OMAP)+= dwc3-omap.o
obj-$(CONFIG_USB_DWC3_EXYNOS) += dwc3-exynos.o
obj-$(CONFIG_USB_DWC3_PCI) += dwc3-pci.o
+obj-$(CONFIG_USB_DWC3_MSM) += dwc3-msm.o
diff --git a/drivers/usb/dwc3/dwc3-msm.c b/drivers/usb/dwc3/dwc3-msm.c
new file mode 100644
index 000..5fb0a19
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-msm.c
@@ -0,0 +1,169 @@
+/* Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct dwc3_msm {
+ struct device *dev;
+ void __iomem*base;
+
+ struct clk *core_clk;
+ struct clk *iface_clk;
+ struct clk *sleep_clk;
+ struct clk *utmi_clk;
+
+ struct regulator*gdsc;
+};
+
+static int dwc3_msm_probe(struct platform_device *pdev)
+{
+ struct device_node *node = pdev->dev.of_node;
+ struct dwc3_msm *mdwc;
+ struct resource *res;
+ void __iomem *tcsr;
+ int ret = 0;
+
+ mdwc = devm_kzalloc(&pdev->dev, sizeof(*mdwc), GFP_KERNEL);
+ if (!mdwc)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, mdwc);
+ mdwc->dev = &pdev->dev;
+
+ mdwc->gdsc = devm_regulator_get(mdwc->dev, "gdsc");
+
+ mdwc->core_clk = devm_clk_get(&pdev->dev, "core_clk");
+ if (IS_ERR(mdwc->core_clk)) {
+ dev_err(&pdev->dev, "failed to get core_clk\n");
+ return PTR_ERR(mdwc->core_clk);
+ }
+
+ mdwc->iface_clk = devm_clk_get(&pdev->dev, "iface_clk");
+ if (IS_ERR(mdwc->iface_clk)) {
+ dev_err(&pdev->dev, "failed to get iface_clk\n");
+ return PTR_ERR(mdwc->iface_clk);
+ }
+
+ mdwc->sleep_clk = devm_clk_get(&pdev->dev, "sleep_clk");
+ if (IS_ERR(mdwc->sleep_clk)) {
+ dev_err(&pdev->dev, "failed to get sleep_clk\n");
+ return PTR_ERR(mdwc->sleep_clk);
+ }
+
+ mdwc->utmi_clk = devm_clk_get(&pdev->dev, "utmi_clk");
+ if (IS_ERR(mdwc->utmi_clk)) {
+ dev_err(&pdev->dev, "failed to get utmi_clk\n");
+ return PTR_ERR(mdwc->utmi_clk);
+ }
+
+ if (!IS_ERR(mdwc->gdsc)) {
+ ret = regulator_enable(mdwc->gdsc);
+ if (ret)
+ dev_err(mdwc->dev, "cannot enable usb3 gdsc\n");
+ }
+
+ /*
+* DWC3 Core requires its CORE CLK (aka master / bus clk) to
+* run at 125Mhz in SSUSB mode and >60MHZ for HSUSB mode.
+*/
+ clk_set_rate(mdwc->core_clk, 12500);
+ clk_prepare_enable(mdwc->core_clk);
+ clk_prepare_enable(mdwc->iface_clk);
+ clk_prepare_enable(mdwc->sleep_clk);
+ clk_prepare_enable(mdwc->utmi_clk);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0
[PATCH v3 1/3] usb: dwc3: msm: Add device tree binding information
From: "Ivan T. Ivanov"
MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys
(SNPS) and HS, SS PHY's control and configuration registers.
It could operate in device mode (SS, HS, FS) and host
mode (SS, HS, FS, LS).
Signed-off-by: Ivan T. Ivanov
---
.../devicetree/bindings/usb/msm-ssusb.txt | 108
1 file changed, 108 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt
diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt
b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
new file mode 100644
index 000..43c73d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
@@ -0,0 +1,108 @@
+MSM SuperSpeed DWC3 USB SoC controller
+
+
+DWC3 Highspeed USB PHY
+==
+Required properities :
+- compatible : sould be "qcom,dwc3-hsphy";
+- reg : offset and length of the register set in the memory map
+- clocks : phandles to clock instances of the device tree nodes
+- clock-names :
+ "xo" : External reference clock 19 MHz
+ "sleep_a_clk" : Sleep clock, used when USB3 core goes into low
+ power mode (U3).
+-supply : phandle to the regulator device tree node
+Required "supply-name" are:
+ "v1p8" : 1.8v supply for HSPHY
+ "v3p3" : 3.3v supply for HSPHY
+ "vbus" : vbus supply for host mode
+ "vddcx" : vdd supply for HS-PHY digital circuit operation
+
+DWC3 Superspeed USB PHY
+===
+Required properities :
+- compatible : sould be "qcom,dwc3-ssphy";
+- reg : offset and length of the register set in the memory map
+- clocks : phandles to clock instances of the device tree nodes
+- clock-names :
+ "xo" : External reference clock 19 MHz
+ "ref_clk" : Reference clock - used in host mode.
+-supply : phandle to the regulator device tree node
+Required "supply-name" are:
+ "v1p8" : 1.8v supply for SS-PHY
+ "vddcx" : vdd supply for SS-PHY digital circuit operation
+
+DWC3 controller wrapper
+===
+Required properties :
+- compatible : should be "qcom,dwc3"
+- reg : offset and length of the register set in the memory map
+ offset and length of the TCSR register for routing USB
+ signals to either picoPHY0 or picoPHY1.
+- clocks : phandles to clock instances of the device tree nodes
+- clock-names :
+ "core_clk" : Master/Core clock, have to be >= 125 MHz for SS
+ operation and >= 60MHz for HS operation
+ "iface_clk" : System bus AXI clock
+ "sleep_clk" : Sleep clock, used when USB3 core goes into low
+ power mode (U3).
+ "utmi_clk" : Generated by HS-PHY. Used to clock the low power
+ parts of thr HS Link layer.
+Optional properties :
+- gdsc-supply : phandle to the globally distributed switch controller
+ regulator node to the USB controller.
+
+
+Sub nodes:
+==
+- Sub node for "DWC3 USB3 controller".
+ This sub node is required property for device node. The properties
+ of this subnode are specified in dwc3.txt.
+
+Example device nodes:
+
+ dwc3_hsphy: phy@f92f8800 {
+ compatible = "qcom,dwc3-hsphy";
+ reg = <0xf92f8800 0x30>;
+
+ clocks = <&cxo>, <&usb2a_phy_sleep_cxc>;
+ clock-names = "xo", "sleep_a_clk";
+
+ vbus-supply = <&supply>;
+ vddcx-supply = <&supply>;
+ v1p8-supply = <&supply>;
+ v3p3-supply = <&supply>;
+ };
+
+ dwc3_ssphy: phy@f92f8830 {
+ compatible = "qcom,dwc3-ssphy";
+ reg = <0xf92f8830 0x30>;
+
+ clocks = <&cxo>, <&usb30_mock_utmi_cxc>;
+ clock-names = "xo", "ref_clk";
+
+ vddcx-supply = <&supply>;
+ v1p8-supply = <&supply>;
+ };
+
+ usb@fd4ab000 {
+ compatible = "qcom,dwc3";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0xfd4ab000 0x4>;
+
+ clocks = <&usb30_master_cxc>, <&sys_noc_usb3_axi_cxc>,
+ <&usb30_sleep_cxc>, <&usb30_mock_utmi_cxc>;
+ clock-names = "core_clk", "iface_clk", "sleep_clk", "utmi_clk";
+
+ gdsc-supply = <&supply>;
+
+ ranges;
+ dwc3@f920 {
+ compatible = "snps,dwc3";
+ reg = <0xf920 0xcd00>;
+ interrupts = <0 131 0>;
+ usb-phy = <&dwc3_hsphy>, <&dwc3_ssphy>;
+ tx-fifo-resize;
+ };
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/3] DWC3 USB support for Qualcomm platform
From: "Ivan T. Ivanov" Hi, These patches add basic support for USB3.0 controllers found on MSM platforms. USB3.0 core is based on Synopsys DesignWare SuperSpeed IP. Changes since v2: * Several improvements in devicetree bindings description * Disable regulators in glue layer if there is error during ioremap. Changes since first version: * Split devicetree bindings description file to separate patch * Address comments for device bindings description * Fix typo in 'gdsc' requlator name. Generated on top of Felipe 'testing' branch. Regards, Ivan Ivan T. Ivanov (3): usb: dwc3: msm: Add device tree binding information usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core usb: dwc3: Add Qualcomm DWC3 glue layer driver .../devicetree/bindings/usb/msm-ssusb.txt | 108 ++ drivers/usb/dwc3/Kconfig |8 + drivers/usb/dwc3/Makefile |1 + drivers/usb/dwc3/dwc3-msm.c| 169 + drivers/usb/phy/Kconfig| 11 + drivers/usb/phy/Makefile |2 + drivers/usb/phy/phy-msm-dwc3-hs.c | 336 + drivers/usb/phy/phy-msm-dwc3-ss.c | 383 8 files changed, 1018 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt create mode 100644 drivers/usb/dwc3/dwc3-msm.c create mode 100644 drivers/usb/phy/phy-msm-dwc3-hs.c create mode 100644 drivers/usb/phy/phy-msm-dwc3-ss.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/3] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core
From: "Ivan T. Ivanov"
These drivers handles control and configuration of the HS
and SS USB PHY transceivers. They are part of the driver
which manage Synopsys DesignWare USB3 controller stack
inside Qualcomm SoC's.
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/phy/Kconfig | 11 ++
drivers/usb/phy/Makefile |2 +
drivers/usb/phy/phy-msm-dwc3-hs.c | 336
drivers/usb/phy/phy-msm-dwc3-ss.c | 383 +
4 files changed, 732 insertions(+)
create mode 100644 drivers/usb/phy/phy-msm-dwc3-hs.c
create mode 100644 drivers/usb/phy/phy-msm-dwc3-ss.c
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 5443958..40e83b5 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -202,6 +202,17 @@ config USB_RCAR_PHY
To compile this driver as a module, choose M here: the
module will be called phy-rcar-usb.
+config USB_MSM_DWC3_PHYS
+ tristate "Qualcomm DWC3 USB controller PHY's support"
+ depends on (USB || USB_GADGET) && ARCH_MSM
+ select USB_PHY
+ help
+ Enable this to support the USB PHY transceivers on MSM chips with
+ DWC3 USB core. It handles PHY initialization, clock management
+ required after resetting the hardware and power management.
+ This driver is required even for peripheral only or host only
+ mode configurations.
+
config USB_ULPI
bool "Generic ULPI Transceiver Driver"
depends on ARM
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 98730ca..ddaa11c 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -24,6 +24,8 @@ obj-$(CONFIG_USB_EHCI_TEGRA) += phy-tegra-usb.o
obj-$(CONFIG_USB_GPIO_VBUS)+= phy-gpio-vbus-usb.o
obj-$(CONFIG_USB_ISP1301) += phy-isp1301.o
obj-$(CONFIG_USB_MSM_OTG) += phy-msm-usb.o
+obj-$(CONFIG_USB_MSM_DWC3_PHYS)+= phy-msm-dwc3-hs.o
+obj-$(CONFIG_USB_MSM_DWC3_PHYS)+= phy-msm-dwc3-ss.o
obj-$(CONFIG_USB_MV_OTG) += phy-mv-usb.o
obj-$(CONFIG_USB_MXS_PHY) += phy-mxs-usb.o
obj-$(CONFIG_USB_RCAR_PHY) += phy-rcar-usb.o
diff --git a/drivers/usb/phy/phy-msm-dwc3-hs.c
b/drivers/usb/phy/phy-msm-dwc3-hs.c
new file mode 100644
index 000..465a8f5
--- /dev/null
+++ b/drivers/usb/phy/phy-msm-dwc3-hs.c
@@ -0,0 +1,336 @@
+/* Copyright (c) 2013, Code Aurora Forum. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * USB QSCRATCH Hardware registers
+ */
+#define QSCRATCH_CTRL_REG (0x04)
+#define QSCRATCH_GENERAL_CFG (0x08)
+#define PHY_CTRL_REG (0x10)
+#define PARAMETER_OVERRIDE_X_REG (0x14)
+#define CHARGING_DET_CTRL_REG (0x18)
+#define CHARGING_DET_OUTPUT_REG(0x1c)
+#define ALT_INTERRUPT_EN_REG (0x20)
+#define PHY_IRQ_STAT_REG (0x24)
+#define CGCTL_REG (0x28)
+
+#define PHY_3P3_VOL_MIN305 /* uV */
+#define PHY_3P3_VOL_MAX330 /* uV */
+#define PHY_3P3_HPM_LOAD 16000 /* uA */
+
+#define PHY_1P8_VOL_MIN180 /* uV */
+#define PHY_1P8_VOL_MAX180 /* uV */
+#define PHY_1P8_HPM_LOAD 19000 /* uA */
+
+/* TODO: these are suspicious */
+#define USB_VDDCX_NO 1 /* uV */
+#define USB_VDDCX_MIN 5 /* uV */
+#define USB_VDDCX_MAX 7 /* uV */
+
+struct msm_dwc3_hs_phy {
+ struct usb_phy phy;
+ void __iomem*base;
+ struct device *dev;
+
+ struct clk *xo_clk;
+ struct clk *sleep_a_clk;
+
+ struct regulator*v3p3;
+ struct regulator*v1p8;
+ struct regulator*vddcx;
+ struct regulator*vbus;
+};
+
+#definephy_to_dwc3_phy(x) container_of((x), struct
msm_dwc3_hs_phy, phy)
+
+
+/**
+ *
+ * Write register with debug info.
+ *
+ * @base - DWC3 base virtual address.
Re: [PATCH v3 2/3] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core
Hi,
On Wed, 2013-08-14 at 09:20 -0500, Josh Cartwright wrote:
> On Wed, Aug 14, 2013 at 03:59:42PM +0300, Ivan T. Ivanov wrote:
> > From: "Ivan T. Ivanov"
> >
> > These drivers handles control and configuration of the HS
> > and SS USB PHY transceivers. They are part of the driver
> > which manage Synopsys DesignWare USB3 controller stack
> > inside Qualcomm SoC's.
> >
> > Signed-off-by: Ivan T. Ivanov
> > ---
> [..]
> > diff --git a/drivers/usb/phy/phy-msm-dwc3-hs.c
> > b/drivers/usb/phy/phy-msm-dwc3-hs.c
> > new file mode 100644
> > index 000..465a8f5
> > --- /dev/null
> > +++ b/drivers/usb/phy/phy-msm-dwc3-hs.c
> [..]
> > +
> > +struct msm_dwc3_hs_phy {
> > + struct usb_phy phy;
> > + void __iomem*base;
> > + struct device *dev;
> > +
> > + struct clk *xo_clk;
> > + struct clk *sleep_a_clk;
> > +
> > + struct regulator*v3p3;
> > + struct regulator*v1p8;
> > + struct regulator*vddcx;
> > + struct regulator*vbus;
> > +};
> > +
> > +#definephy_to_dwc3_phy(x) container_of((x), struct
> > msm_dwc3_hs_phy, phy)
> > +
> > +
> > +/**
> > + *
> > + * Write register with debug info.
>
> what debug info?
Will fix this. It was left from the earliest versions of the functions.
>
> > + *
> > + * @base - DWC3 base virtual address.
> > + * @offset - register offset.
> > + * @val - value to write.
> > + *
> > + */
> > +static inline void msm_dwc3_hs_write(void *base, u32 offset, u32 val)
>
> You've dropped __iomem here; have you run through sparse?
Obviously not :-). Thanks for noticing this.
>
> > +{
> > + iowrite32(val, base + offset);
> > +}
> > +
> > +/**
> > + * Write register and read back masked value to confirm it is written
> > + *
> > + * @base - DWC3 base virtual address.
> > + * @offset - register offset.
> > + * @mask - register bitmask specifying what should be updated
> > + * @val - value to write.
> > + *
> > + */
> > +static inline void msm_dwc3_hs_write_readback(void *base, u32 offset,
> > + const u32 mask, u32 val)
> > +{
>
> Same comment here.
Will be fixed in next version.
Thanks,
Ivan
--
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 3/3] usb: dwc3: Add Qualcomm DWC3 glue layer driver
On Wed, 2013-08-14 at 09:06 -0700, Stephen Boyd wrote:
> On 08/14/13 05:59, Ivan T. Ivanov wrote:
> > +}
> > +
> > +static const struct of_device_id of_dwc3_matach[] = {
>
> match? Maybe you can make it all one line too { .compatible = "qcom,dwc3" }
>
Thanks. Will do.
Ivan
> > + {
> > + .compatible = "qcom,dwc3",
> > + },
> > + { },
> > +};
> > +MODULE_DEVICE_TABLE(of, of_dwc3_matach);
> > +
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] usb: dwc3: msm: Add device tree binding information
Hi, On Fri, 2013-08-16 at 16:44 -0600, Stephen Warren wrote: > On 08/14/2013 06:59 AM, Ivan T. Ivanov wrote: > > From: "Ivan T. Ivanov" > > > > MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys > > (SNPS) and HS, SS PHY's control and configuration registers. > > > > It could operate in device mode (SS, HS, FS) and host > > mode (SS, HS, FS, LS). > > > diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt > > b/Documentation/devicetree/bindings/usb/msm-ssusb.txt > > > +- clock-names : > ... > > + "sleep_a_clk" : Sleep clock, used when USB3 core goes into low > ... > > + "ref_clk" : Reference clock - used in host mode. > ... > > + "core_clk" : Master/Core clock, have to be >= 125 MHz for SS > ... > > + "iface_clk" : System bus AXI clock > > + "sleep_clk" : Sleep clock, used when USB3 core goes into low > ... > > + "utmi_clk" : Generated by HS-PHY. Used to clock the low power > > I think it makes sense to remove "_clk" from all those names, unless the > HW documentation really talks about a clock named e.g. iface_clk yet > some other clock names in the documentation don't have the "_clk" > suffix, e.g. the "xo I didn't quote. >From limited information that I have, I could not say how clock inputs are named from the controller perspective, but I agree that "_clk" suffix looks redundant. Side question: if for example label in controller says "UTMI", should I also use capital letters for the resource or this could be "utmi"? > > > +Sub nodes: > > +== > > That section title is the same style as all the other section title, so > it's no obvious that this is a sub-node for the controller wrapper. > Instead, I would suggest something more like: > > Required child nodes: > > > +- Sub node for "DWC3 USB3 controller". > > Then you can drop that since it's obvious. > > > + This sub node is required property for device node. The properties > > + of this subnode are specified in dwc3.txt. > > That doesn't really say much. How about. > > -- > A child node must exist to represent the core DWC3 IP block. The name of > the node is not important. The content of the node is defined in dwc3.txt. > -- Thanks, I will use your suggestion. Regards, Ivan -- 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 v4 0/3] DWC3 USB support for Qualcomm platform
From: "Ivan T. Ivanov" Hi, Here is fourth version of MSM USB3 drivers patches. Changes since v3: * Remove "_clk" suffix from clock names * Clarify required child node for qcom,dwc3 * Fix comments in functions headers * Use dbg instead err in drivers probe functions. Changes since v2: * Several improvements in devicetree bindings description * Disable regulators in glue layer if there is error during ioremap. Changes since first version: * Split devicetree bindings description file to separate patch * Address comments for device bindings description * Fix typo in 'gdsc' requlator name. These patches add basic support for USB3.0 controllers found on MSM platforms. USB3.0 core is based on Synopsys DesignWare SuperSpeed IP. Generated on top of Felipe 'testing' branch. Ivan T. Ivanov (3): usb: dwc3: msm: Add device tree binding information usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core usb: dwc3: Add Qualcomm DWC3 glue layer driver .../devicetree/bindings/usb/msm-ssusb.txt | 104 ++ drivers/usb/dwc3/Kconfig |8 + drivers/usb/dwc3/Makefile |1 + drivers/usb/dwc3/dwc3-msm.c| 167 + drivers/usb/phy/Kconfig| 11 + drivers/usb/phy/Makefile |2 + drivers/usb/phy/phy-msm-dwc3-hs.c | 327 + drivers/usb/phy/phy-msm-dwc3-ss.c | 374 8 files changed, 994 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt create mode 100644 drivers/usb/dwc3/dwc3-msm.c create mode 100644 drivers/usb/phy/phy-msm-dwc3-hs.c create mode 100644 drivers/usb/phy/phy-msm-dwc3-ss.c -- 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 v4 1/3] usb: dwc3: msm: Add device tree binding information
From: "Ivan T. Ivanov"
MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys
(SNPS) and HS, SS PHY's control and configuration registers.
It could operate in device mode (SS, HS, FS) and host
mode (SS, HS, FS, LS).
Signed-off-by: Ivan T. Ivanov
---
.../devicetree/bindings/usb/msm-ssusb.txt | 104
1 file changed, 104 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/msm-ssusb.txt
diff --git a/Documentation/devicetree/bindings/usb/msm-ssusb.txt
b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
new file mode 100644
index 000..cacbd3b
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/msm-ssusb.txt
@@ -0,0 +1,104 @@
+MSM SuperSpeed DWC3 USB SoC controller
+
+
+DWC3 Highspeed USB PHY
+==
+Required properities :
+- compatible : sould be "qcom,dwc3-hsphy";
+- reg : offset and length of the register set in the memory map
+- clocks : phandles to clock instances of the device tree nodes
+- clock-names :
+ "xo" : External reference clock 19 MHz
+ "sleep_a" : Sleep clock, used when USB3 core goes into low
+ power mode (U3).
+-supply : phandle to the regulator device tree node
+Required "supply-name" are:
+ "v1p8" : 1.8v supply for HSPHY
+ "v3p3" : 3.3v supply for HSPHY
+ "vbus" : vbus supply for host mode
+ "vddcx" : vdd supply for HS-PHY digital circuit operation
+
+DWC3 Superspeed USB PHY
+===
+Required properities :
+- compatible : sould be "qcom,dwc3-ssphy";
+- reg : offset and length of the register set in the memory map
+- clocks : phandles to clock instances of the device tree nodes
+- clock-names :
+ "xo" : External reference clock 19 MHz
+ "ref" : Reference clock - used in host mode.
+-supply : phandle to the regulator device tree node
+Required "supply-name" are:
+ "v1p8" : 1.8v supply for SS-PHY
+ "vddcx" : vdd supply for SS-PHY digital circuit operation
+
+DWC3 controller wrapper
+===
+Required properties :
+- compatible : should be "qcom,dwc3"
+- reg : offset and length of the register set in the memory map
+ offset and length of the TCSR register for routing USB
+ signals to either picoPHY0 or picoPHY1.
+- clocks : phandles to clock instances of the device tree nodes
+- clock-names :
+ "core" : Master/Core clock, have to be >= 125 MHz for SS
+ operation and >= 60MHz for HS operation
+ "iface" : System bus AXI clock
+ "sleep" : Sleep clock, used when USB3 core goes into low
+ power mode (U3).
+ "utmi" : Generated by HS-PHY. Used to clock the low power
+ parts of thr HS Link layer.
+Optional properties :
+- gdsc-supply : phandle to the globally distributed switch controller
+ regulator node to the USB controller.
+Required child node:
+A child node must exist to represent the core DWC3 IP block. The name of
+the node is not important. The content of the node is defined in dwc3.txt.
+
+Example device nodes:
+
+ dwc3_hsphy: phy@f92f8800 {
+ compatible = "qcom,dwc3-hsphy";
+ reg = <0xf92f8800 0x30>;
+
+ clocks = <&cxo>, <&usb2a_phy_sleep_cxc>;
+ clock-names = "xo", "sleep_a";
+
+ vbus-supply = <&supply>;
+ vddcx-supply = <&supply>;
+ v1p8-supply = <&supply>;
+ v3p3-supply = <&supply>;
+ };
+
+ dwc3_ssphy: phy@f92f8830 {
+ compatible = "qcom,dwc3-ssphy";
+ reg = <0xf92f8830 0x30>;
+
+ clocks = <&cxo>, <&usb30_mock_utmi_cxc>;
+ clock-names = "xo", "ref";
+
+ vddcx-supply = <&supply>;
+ v1p8-supply = <&supply>;
+ };
+
+ usb@fd4ab000 {
+ compatible = "qcom,dwc3";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0xfd4ab000 0x4>;
+
+ clocks = <&usb30_master_cxc>, <&sys_noc_usb3_axi_cxc>,
+ <&usb30_sleep_cxc>, <&usb30_mock_utmi_cxc>;
+ clock-names = "core", "iface", "sleep", "utmi";
+
+ gdsc-supply = <&supply>;
+
+ ranges;
+ dwc3@f920 {
+ compatible = "snps,dwc3";
+ reg = <0xf920 0xcd00>;
+ interrupts = <0 131 0>;
+ usb-phy = <&dwc3_hsphy>, <&dwc3_ssphy>;
+ tx-fifo-resize;
+ };
+ };
--
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 v4 3/3] usb: dwc3: Add Qualcomm DWC3 glue layer driver
From: "Ivan T. Ivanov"
DWC3 glue layer is hardware layer around Synopsys DesignWare
USB3 core. Its purpose is to supply Synopsys IP with required
clocks, voltages and interface it with the rest of the SoC.
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/dwc3/Kconfig|8 +++
drivers/usb/dwc3/Makefile |1 +
drivers/usb/dwc3/dwc3-msm.c | 167 +++
3 files changed, 176 insertions(+)
create mode 100644 drivers/usb/dwc3/dwc3-msm.c
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index f969ea2..d845966 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -71,6 +71,14 @@ config USB_DWC3_PCI
One such PCIe-based platform is Synopsys' PCIe HAPS model of
this IP.
+config USB_DWC3_MSM
+ tristate "Qualcomm MSM/APQ Platforms"
+ default USB_DWC3
+ select USB_MSM_DWC3_PHYS
+ help
+ Recent Qualcomm SoCs ship with one DesignWare Core USB3 IP inside,
+ say 'Y' or 'M' if you have one such device.
+
comment "Debugging features"
config USB_DWC3_DEBUG
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index dd17601..5226681 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -32,3 +32,4 @@ endif
obj-$(CONFIG_USB_DWC3_OMAP)+= dwc3-omap.o
obj-$(CONFIG_USB_DWC3_EXYNOS) += dwc3-exynos.o
obj-$(CONFIG_USB_DWC3_PCI) += dwc3-pci.o
+obj-$(CONFIG_USB_DWC3_MSM) += dwc3-msm.o
diff --git a/drivers/usb/dwc3/dwc3-msm.c b/drivers/usb/dwc3/dwc3-msm.c
new file mode 100644
index 000..361076c
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-msm.c
@@ -0,0 +1,167 @@
+/* Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct dwc3_msm {
+ struct device *dev;
+
+ struct clk *core_clk;
+ struct clk *iface_clk;
+ struct clk *sleep_clk;
+ struct clk *utmi_clk;
+
+ struct regulator*gdsc;
+};
+
+static int dwc3_msm_probe(struct platform_device *pdev)
+{
+ struct device_node *node = pdev->dev.of_node;
+ struct dwc3_msm *mdwc;
+ struct resource *res;
+ void __iomem *tcsr;
+ int ret = 0;
+
+ mdwc = devm_kzalloc(&pdev->dev, sizeof(*mdwc), GFP_KERNEL);
+ if (!mdwc)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, mdwc);
+ mdwc->dev = &pdev->dev;
+
+ mdwc->gdsc = devm_regulator_get(mdwc->dev, "gdsc");
+
+ mdwc->core_clk = devm_clk_get(&pdev->dev, "core");
+ if (IS_ERR(mdwc->core_clk)) {
+ dev_dbg(&pdev->dev, "failed to get core clock\n");
+ return PTR_ERR(mdwc->core_clk);
+ }
+
+ mdwc->iface_clk = devm_clk_get(&pdev->dev, "iface");
+ if (IS_ERR(mdwc->iface_clk)) {
+ dev_dbg(&pdev->dev, "failed to get iface clock\n");
+ return PTR_ERR(mdwc->iface_clk);
+ }
+
+ mdwc->sleep_clk = devm_clk_get(&pdev->dev, "sleep ");
+ if (IS_ERR(mdwc->sleep_clk)) {
+ dev_dbg(&pdev->dev, "failed to get sleep clock\n");
+ return PTR_ERR(mdwc->sleep_clk);
+ }
+
+ mdwc->utmi_clk = devm_clk_get(&pdev->dev, "utmi");
+ if (IS_ERR(mdwc->utmi_clk)) {
+ dev_dbg(&pdev->dev, "failed to get utmi clock\n");
+ return PTR_ERR(mdwc->utmi_clk);
+ }
+
+ if (!IS_ERR(mdwc->gdsc)) {
+ ret = regulator_enable(mdwc->gdsc);
+ if (ret)
+ dev_err(mdwc->dev, "cannot enable usb3 gdsc\n");
+ }
+
+ /*
+* DWC3 Core requires its CORE CLK (aka master / bus clk) to
+* run at 125Mhz in SSUSB mode and >60MHZ for HSUSB mode.
+*/
+ clk_set_rate(mdwc->core_clk, 12500);
+ clk_prepare_enable(mdwc->core_clk);
+ clk_prepare_enable(mdwc->iface_clk);
+ clk_prepare_enable(mdwc->sleep_clk);
+ clk_prepare_enable(mdwc->utmi_clk);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ tcsr = devm_ioremap_resource(&
[PATCH v4 2/3] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core
From: "Ivan T. Ivanov"
These drivers handles control and configuration of the HS
and SS USB PHY transceivers. They are part of the driver
which manage Synopsys DesignWare USB3 controller stack
inside Qualcomm SoC's.
Signed-off-by: Ivan T. Ivanov
---
drivers/usb/phy/Kconfig | 11 ++
drivers/usb/phy/Makefile |2 +
drivers/usb/phy/phy-msm-dwc3-hs.c | 327
drivers/usb/phy/phy-msm-dwc3-ss.c | 374 +
4 files changed, 714 insertions(+)
create mode 100644 drivers/usb/phy/phy-msm-dwc3-hs.c
create mode 100644 drivers/usb/phy/phy-msm-dwc3-ss.c
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index d5589f9..c525835 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -214,6 +214,17 @@ config USB_RCAR_PHY
To compile this driver as a module, choose M here: the
module will be called phy-rcar-usb.
+config USB_MSM_DWC3_PHYS
+ tristate "Qualcomm DWC3 USB controller PHY's support"
+ depends on (USB || USB_GADGET) && ARCH_MSM
+ select USB_PHY
+ help
+ Enable this to support the USB PHY transceivers on MSM chips with
+ DWC3 USB core. It handles PHY initialization, clock management
+ required after resetting the hardware and power management.
+ This driver is required even for peripheral only or host only
+ mode configurations.
+
config USB_ULPI
bool "Generic ULPI Transceiver Driver"
depends on ARM
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 2135e85..8f2dd94 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -26,6 +26,8 @@ obj-$(CONFIG_USB_EHCI_TEGRA) += phy-tegra-usb.o
obj-$(CONFIG_USB_GPIO_VBUS)+= phy-gpio-vbus-usb.o
obj-$(CONFIG_USB_ISP1301) += phy-isp1301.o
obj-$(CONFIG_USB_MSM_OTG) += phy-msm-usb.o
+obj-$(CONFIG_USB_MSM_DWC3_PHYS)+= phy-msm-dwc3-hs.o
+obj-$(CONFIG_USB_MSM_DWC3_PHYS)+= phy-msm-dwc3-ss.o
obj-$(CONFIG_USB_MV_OTG) += phy-mv-usb.o
obj-$(CONFIG_USB_MXS_PHY) += phy-mxs-usb.o
obj-$(CONFIG_USB_RCAR_PHY) += phy-rcar-usb.o
diff --git a/drivers/usb/phy/phy-msm-dwc3-hs.c
b/drivers/usb/phy/phy-msm-dwc3-hs.c
new file mode 100644
index 000..840e766
--- /dev/null
+++ b/drivers/usb/phy/phy-msm-dwc3-hs.c
@@ -0,0 +1,327 @@
+/* Copyright (c) 2013, Code Aurora Forum. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * USB QSCRATCH Hardware registers
+ */
+#define QSCRATCH_CTRL_REG (0x04)
+#define QSCRATCH_GENERAL_CFG (0x08)
+#define PHY_CTRL_REG (0x10)
+#define PARAMETER_OVERRIDE_X_REG (0x14)
+#define CHARGING_DET_CTRL_REG (0x18)
+#define CHARGING_DET_OUTPUT_REG(0x1c)
+#define ALT_INTERRUPT_EN_REG (0x20)
+#define PHY_IRQ_STAT_REG (0x24)
+#define CGCTL_REG (0x28)
+
+#define PHY_3P3_VOL_MIN305 /* uV */
+#define PHY_3P3_VOL_MAX330 /* uV */
+#define PHY_3P3_HPM_LOAD 16000 /* uA */
+
+#define PHY_1P8_VOL_MIN180 /* uV */
+#define PHY_1P8_VOL_MAX180 /* uV */
+#define PHY_1P8_HPM_LOAD 19000 /* uA */
+
+/* TODO: these are suspicious */
+#define USB_VDDCX_NO 1 /* uV */
+#define USB_VDDCX_MIN 5 /* uV */
+#define USB_VDDCX_MAX 7 /* uV */
+
+struct msm_dwc3_hs_phy {
+ struct usb_phy phy;
+ void __iomem*base;
+ struct device *dev;
+
+ struct clk *xo_clk;
+ struct clk *sleep_a_clk;
+
+ struct regulator*v3p3;
+ struct regulator*v1p8;
+ struct regulator*vddcx;
+ struct regulator*vbus;
+};
+
+#definephy_to_dwc3_phy(x) container_of((x), struct
msm_dwc3_hs_phy, phy)
+
+
+/**
+ * Write register.
+ *
+ * @base - MSM DWC3 PHY base virtual address.
+ * @offset - register offset.
+ * @val - value to write.
+ */
+static inline void msm_dwc3_hs_write(void __iomem *base, u32 offset, u32 val)
+{
+ iowrite32(val, base + offset);
+}
+
+/**
+ * Write register and read back masked value t
Re: [PATCH v4 2/3] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core
Hi, On Tue, 2013-08-20 at 07:29 -0500, Felipe Balbi wrote: > Hi, > > On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote: > > From: "Ivan T. Ivanov" > > > > These drivers handles control and configuration of the HS > > and SS USB PHY transceivers. They are part of the driver > > which manage Synopsys DesignWare USB3 controller stack > > inside Qualcomm SoC's. > > > > Signed-off-by: Ivan T. Ivanov > > --- > > drivers/usb/phy/Kconfig | 11 ++ > > drivers/usb/phy/Makefile |2 + > > drivers/usb/phy/phy-msm-dwc3-hs.c | 327 > > drivers/usb/phy/phy-msm-dwc3-ss.c | 374 > > + > > please rename these PHY drivers, they have nothing to do with DWC3. PHYs > don't care about the USB controller. I think they are SNPS DesignWare PHY's, additionally wrapped with Qualcomm logic. I could substitute "dwc3" with just "dw", which will be more correct. Regards, Ivan -- 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 2/3] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core
Hi, On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote: > Hi, > > On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote: > > > On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote: > > > > From: "Ivan T. Ivanov" > > > > > > > > These drivers handles control and configuration of the HS > > > > and SS USB PHY transceivers. They are part of the driver > > > > which manage Synopsys DesignWare USB3 controller stack > > > > inside Qualcomm SoC's. > > > > > > > > Signed-off-by: Ivan T. Ivanov > > > > --- > > > > drivers/usb/phy/Kconfig | 11 ++ > > > > drivers/usb/phy/Makefile |2 + > > > > drivers/usb/phy/phy-msm-dwc3-hs.c | 327 > > > > > > > > drivers/usb/phy/phy-msm-dwc3-ss.c | 374 > > > > + > > > > > > please rename these PHY drivers, they have nothing to do with DWC3. PHYs > > > don't care about the USB controller. > > > > I think they are SNPS DesignWare PHY's, additionally > > wrapped with Qualcomm logic. I could substitute "dwc3" > > with just "dw", which will be more correct. > > alright, thank you. Let's add Paul to the loop since he might have very > good insight in the synopsys PHYs. > > mental note: if any other platform shows up with Synopsys PHY, ask them > to use this driver instead :-) I really doubt that this will bi possible. Control of the PHY's is not directly trough ULPI, UTMI or PIPE3 interfaces, but trough QSCRATCH registers, which of course is highly Qualcomm specific. Regards, Ivan -- 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 2/3] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core
Hi, On Tue, 2013-08-20 at 09:33 -0500, Felipe Balbi wrote: > On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote: > > Hi, > > > > On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote: > > > Hi, > > > > > > On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote: > > > > > On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote: > > > > > > From: "Ivan T. Ivanov" > > > > > > > > > > > > These drivers handles control and configuration of the HS > > > > > > and SS USB PHY transceivers. They are part of the driver > > > > > > which manage Synopsys DesignWare USB3 controller stack > > > > > > inside Qualcomm SoC's. > > > > > > > > > > > > Signed-off-by: Ivan T. Ivanov > > > > > > --- > > > > > > drivers/usb/phy/Kconfig | 11 ++ > > > > > > drivers/usb/phy/Makefile |2 + > > > > > > drivers/usb/phy/phy-msm-dwc3-hs.c | 327 > > > > > > > > > > > > drivers/usb/phy/phy-msm-dwc3-ss.c | 374 > > > > > > + > > > > > > > > > > please rename these PHY drivers, they have nothing to do with DWC3. > > > > > PHYs > > > > > don't care about the USB controller. > > > > > > > > I think they are SNPS DesignWare PHY's, additionally > > > > wrapped with Qualcomm logic. I could substitute "dwc3" > > > > with just "dw", which will be more correct. > > > > > > alright, thank you. Let's add Paul to the loop since he might have very > > > good insight in the synopsys PHYs. > > > > > > mental note: if any other platform shows up with Synopsys PHY, ask them > > > to use this driver instead :-) > > > > I really doubt that this will bi possible. Control of the PHY's is > > not directly trough ULPI, UTMI or PIPE3 interfaces, but trough > > QSCRATCH registers, which of course is highly Qualcomm specific. > > isn't it a memory mapped IP ? doesn't synopsys provide their own set of > registers ? >From what I see it is not directly mapped. How QSCRATCH write and reads transactions are translated to DW IP is unclear to me. Ivan -- 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 2/3] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DWC3 core
On Tue, 2013-08-20 at 10:01 -0500, Kumar Gala wrote: > On Aug 20, 2013, at 9:54 AM, Ivan T. Ivanov wrote: > > > > > Hi, > > > > On Tue, 2013-08-20 at 09:33 -0500, Felipe Balbi wrote: > >> On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote: > >>> Hi, > >>> > >>> On Tue, 2013-08-20 at 08:37 -0500, Felipe Balbi wrote: > >>>> Hi, > >>>> > >>>> On Tue, Aug 20, 2013 at 04:32:23PM +0300, Ivan T. Ivanov wrote: > >>>>>> On Tue, Aug 20, 2013 at 12:56:04PM +0300, Ivan T. Ivanov wrote: > >>>>>>> From: "Ivan T. Ivanov" > >>>>>>> > >>>>>>> These drivers handles control and configuration of the HS > >>>>>>> and SS USB PHY transceivers. They are part of the driver > >>>>>>> which manage Synopsys DesignWare USB3 controller stack > >>>>>>> inside Qualcomm SoC's. > >>>>>>> > >>>>>>> Signed-off-by: Ivan T. Ivanov > >>>>>>> --- > >>>>>>> drivers/usb/phy/Kconfig | 11 ++ > >>>>>>> drivers/usb/phy/Makefile |2 + > >>>>>>> drivers/usb/phy/phy-msm-dwc3-hs.c | 327 > >>>>>>> > >>>>>>> drivers/usb/phy/phy-msm-dwc3-ss.c | 374 > >>>>>>> + > >>>>>> > >>>>>> please rename these PHY drivers, they have nothing to do with DWC3. > >>>>>> PHYs > >>>>>> don't care about the USB controller. > >>>>> > >>>>> I think they are SNPS DesignWare PHY's, additionally > >>>>> wrapped with Qualcomm logic. I could substitute "dwc3" > >>>>> with just "dw", which will be more correct. > >>>> > >>>> alright, thank you. Let's add Paul to the loop since he might have very > >>>> good insight in the synopsys PHYs. > >>>> > >>>> mental note: if any other platform shows up with Synopsys PHY, ask them > >>>> to use this driver instead :-) > >>> > >>> I really doubt that this will bi possible. Control of the PHY's is > >>> not directly trough ULPI, UTMI or PIPE3 interfaces, but trough > >>> QSCRATCH registers, which of course is highly Qualcomm specific. > >> > >> isn't it a memory mapped IP ? doesn't synopsys provide their own set of > >> registers ? > > > > From what I see it is not directly mapped. How QSCRATCH write and > > reads transactions are translated to DW IP is unclear to me. > > > I think the question is how does SW access them? "USB QSCRATCH Hardware registers" don't ask me what is this :-) or like Pawel says: "it depends on the SOC" . Ivan > > - k > -- 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
