Re: [PATCH] usb: dwc3: gadget: don't remove the request if bus-expired
Hi, Zeng Tao writes: > We have already returned EAGAIN for bus-expiry, and it's designed to > start with a future Frame number and start the transfer again. So we > should not remove the request for that case. > > Signed-off-by: Zeng Tao Do we need a Fixes tag here? How about Cc stable? Can you share tracepoints exposing the problem? thanks -- balbi signature.asc Description: PGP signature
Re: [PATCH] usb: dwc2: gadget: Fix Remote Wakeup interrupt bit clearing
Hi,
Minas Harutyunyan writes:
> Hi Greg, Filipe,
>
> On 12/12/2018 4:44 PM, Minas Harutyunyan wrote:
>> To clear GINTSTS2_WKUP_ALERT_INT bit in GINTSTS2 register
>> require to write 1. This bit is implemented as "Write to clear".
>>
>> Fixes: 187c5298a122 ("usb: dwc2: gadget: Add handler for WkupAlert
>> interrupt")
>>
>> Signed-off-by: Minas Harutyunyan
>> ---
>> drivers/usb/dwc2/gadget.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
>> index 68ad75a7460d..55ef3cc2701b 100644
>> --- a/drivers/usb/dwc2/gadget.c
>> +++ b/drivers/usb/dwc2/gadget.c
>> @@ -261,7 +261,7 @@ static void dwc2_gadget_wkup_alert_handler(struct
>> dwc2_hsotg *hsotg)
>>
>> if (gintsts2 & GINTSTS2_WKUP_ALERT_INT) {
>> dev_dbg(hsotg->dev, "%s: Wkup_Alert_Int\n", __func__);
>> -dwc2_clear_bit(hsotg, GINTSTS2, GINTSTS2_WKUP_ALERT_INT);
>> +dwc2_set_bit(hsotg, GINTSTS2, GINTSTS2_WKUP_ALERT_INT);
>> dwc2_set_bit(hsotg, DCTL, DCTL_RMTWKUPSIG);
>> }
>> }
>>
>
> Sorry for last minute fix of this stupid bug.
> Please get this commit together with "usb: dwc2: gadget: Fix WkupAlert
> interrupt handler."
And where is that?
--
balbi
signature.asc
Description: PGP signature
[PATCH] usb: dwc3: gadget: synchronize_irq dwc irq in suspend
From: Bo He We see dwc3 endpoint stopped by unwanted irq during suspend resume test, which is caused dwc3 ep can't be started with error "No Resource". Here, add synchronize_irq before suspend to sync the pending IRQ handlers complete. Signed-off-by: Bo He Signed-off-by: Yu Wang Signed-off-by: Felipe Balbi --- drivers/usb/dwc3/gadget.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 07bd31bb2f8a..851fd44d56ad 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -3379,6 +3379,8 @@ int dwc3_gadget_suspend(struct dwc3 *dwc) dwc3_disconnect_gadget(dwc); __dwc3_gadget_stop(dwc); + synchronize_irq(dwc->irq_gadget); + return 0; } -- 2.20.1
Re: [PATCH] usb: dwc2: gadget: Fix Remote Wakeup interrupt bit clearing
Hi Filipe,
On 1/14/2019 12:15 PM, Felipe Balbi wrote:
>
> Hi,
>
> Minas Harutyunyan writes:
>> Hi Greg, Filipe,
>>
>> On 12/12/2018 4:44 PM, Minas Harutyunyan wrote:
>>> To clear GINTSTS2_WKUP_ALERT_INT bit in GINTSTS2 register
>>> require to write 1. This bit is implemented as "Write to clear".
>>>
>>> Fixes: 187c5298a122 ("usb: dwc2: gadget: Add handler for WkupAlert
>>> interrupt")
>>>
>>> Signed-off-by: Minas Harutyunyan
>>> ---
>>>drivers/usb/dwc2/gadget.c | 2 +-
>>>1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
>>> index 68ad75a7460d..55ef3cc2701b 100644
>>> --- a/drivers/usb/dwc2/gadget.c
>>> +++ b/drivers/usb/dwc2/gadget.c
>>> @@ -261,7 +261,7 @@ static void dwc2_gadget_wkup_alert_handler(struct
>>> dwc2_hsotg *hsotg)
>>>
>>> if (gintsts2 & GINTSTS2_WKUP_ALERT_INT) {
>>> dev_dbg(hsotg->dev, "%s: Wkup_Alert_Int\n", __func__);
>>> - dwc2_clear_bit(hsotg, GINTSTS2, GINTSTS2_WKUP_ALERT_INT);
>>> + dwc2_set_bit(hsotg, GINTSTS2, GINTSTS2_WKUP_ALERT_INT);
>>> dwc2_set_bit(hsotg, DCTL, DCTL_RMTWKUPSIG);
>>> }
>>>}
>>>
>>
>> Sorry for last minute fix of this stupid bug.
>> Please get this commit together with "usb: dwc2: gadget: Fix WkupAlert
>> interrupt handler."
>
> And where is that?
>
You mean where is "usb: dwc2: gadget: Fix WkupAlert interrupt handler."
commit? If yes, then that commit id is
d64bc8ee92856e39b3150d93e244ca8239ae6ada
Thanks,
Minas
Re: [PATCH] usb: dwc2: gadget: Fix Remote Wakeup interrupt bit clearing
Hi,
Minas Harutyunyan writes:
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 68ad75a7460d..55ef3cc2701b 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -261,7 +261,7 @@ static void dwc2_gadget_wkup_alert_handler(struct
dwc2_hsotg *hsotg)
if (gintsts2 & GINTSTS2_WKUP_ALERT_INT) {
dev_dbg(hsotg->dev, "%s: Wkup_Alert_Int\n", __func__);
- dwc2_clear_bit(hsotg, GINTSTS2, GINTSTS2_WKUP_ALERT_INT);
+ dwc2_set_bit(hsotg, GINTSTS2, GINTSTS2_WKUP_ALERT_INT);
dwc2_set_bit(hsotg, DCTL, DCTL_RMTWKUPSIG);
}
}
>>>
>>> Sorry for last minute fix of this stupid bug.
>>> Please get this commit together with "usb: dwc2: gadget: Fix WkupAlert
>>> interrupt handler."
>>
>> And where is that?
>>
> You mean where is "usb: dwc2: gadget: Fix WkupAlert interrupt handler."
> commit? If yes, then that commit id is
> d64bc8ee92856e39b3150d93e244ca8239ae6ada
oh, already upstream. Good. Thanks
--
balbi
signature.asc
Description: PGP signature
Re: Wake usb-serial device and disable autosuspend after probing
On Fri, Jan 11, 2019 at 10:13:28AM +, Karoly Pados wrote: > As the next step I'm going to prepare a patch to fix this buggy > interaction with PM. Assuming GPIO pin state is not lost in suspend > (I'll test this explicitly later), which of the following two ways is > the preferred solution? > - Call autopm_get in gpio_request and autopm_put in gpio_free, kind of > like how the existing code calls autopm_get in port open, or... > - Sandwich all gpio-related code (get, set, _*multiple, > direction_input, etc.) between pairs of autopm_get and autopm_put. The second, more fine-grained option is preferred. No need to keep the device resumed if all you want to do is set a pin state and leave it at that, for example. Looks like you may get away with only adding calls to ftdi_set_cbus_pins() and ftdi_read_cbus_pins(). Would be good to keep the fix minimal so we can backport it to stable too. > If pin state is lost in suspend, then obviously I'll have to go with > the first solution. Right, but then we'd have bigger problems with restoring the state on resume. It'd be good to confirm this isn't the case. Thanks, Johan
Re: USB-C storage device not detected on USB 3.1 Gen 2 host when plugged in after boot
On Fr, 2019-01-11 at 19:49 +0100, Jan-Marek Glogowski wrote: > > Yup, but the device is just detected if its plugged in on boot / module load. > I now have recompiled 5.0-rc1 with xhci as a module. First of all, is this a regression? Did earlier kernels work? > > If I plug the device after the module is loaded, I get no messages in dmesg. > No devices shows up > If I rmmod xhci_pci + modprobe xhci_pci the device is correctly enumerated > and works. > If I re-plug the device again it also doesn't show up again until module > "reload". > > The attached dmesg is from a boot with the device plugged in. > > I had some talk with Greg on #kernelnewbies and he suspected a broken port. > > I have no idea if a port can enumerate but not hotplug. > > I meanwhile switched to some other HW (Acer n4660g), which shows the same > problem. OK, then we need logs of the failure case. A usbmon trace and dmesg with debugging enabled echo "module xhci_hcd +mfp" > /sys/kernel/debug/dynamic_debug/control echo "module xhci_pci +mfp" > /sys/kernel/debug/dynamic_debug/control echo "module usbcore +mfp" > /sys/kernel/debug/dynamic_debug/control Regards Oliver
Re: Magewell Gen 2935:0001 USB annoyances
Em Mon, 14 Jan 2019 13:10:25 +0800 Kai Hendry escreveu: > Archlinux user here. It doesn't matter whether I'm running LTS kernel > 4.19.14-1-lts or 4.20.1.arch1-1, I get these very annoying USB issues with my > Magewell XI100DUSB-HDMI. Most of the time it doesn't work. I seemingly have > better chances of getting it working after a reboot. > > I don't know if this is a UVC issue or a USB issue on my Gen8 Thinkpad T480s. > All I can say for a fact is that plugging this device into my Macbook Pro > running MacOS via a USB-C dongle, is more reliable. I've had the same "plug > in" issues admittedly on previous Thinkpad hardware and kernel versions. > > Another annoying aspect, is that it also seems to drop USB speeds when hot > plugging. I need USB 3 else it won't be able to get 60fps at 1080p. (adding c/c to linux-usb) If the image is not compressed, a 640x480 image with 16 bits per pixel and 30 frames per second eats 60% of the USB 2.0 maximum number of ISOC frames with em28xx driver[1]. [1] The actual value is driver/device specific, as it depends on the maximum frame size. So, I'm pretty sure that you won't be able to get 60fps at 1080p if it doesn't enable USB 3.0 SuperSpeed mode. That's said, it is up to the USB stack to detect the device as an USB 3.0. If this is not working well, it could either be a hardware problem or some issue at the USB host driver. > https://s.natalian.org/2019-01-14/1547438681_2548x1398.png > > It's a crazy ritual with accompanying dance when I get USB3 and my > /dev/video2 actually working. > > This is what dmesg looks like when it's flailing. > > [ 71.896534] usb 2-2: Disable of device-initiated U1 failed. > [ 71.900554] usb 2-2: Disable of device-initiated U2 failed. > [ 71.909474] usb 2-2: Set SEL for device-initiated U1 failed. > [ 72.691371] usb 2-2: USB disconnect, device number 6 > [ 73.041273] usb 1-2: new high-speed USB device number 10 using xhci_hcd > [ 73.620177] usb 1-2: New USB device found, idVendor=2935, idProduct=0001, > bcdDevice= 0.00 > [ 73.620180] usb 1-2: New USB device strings: Mfr=1, Product=2, > SerialNumber=3 > [ 73.620182] usb 1-2: Product: XI100DUSB-HDMI > [ 73.620183] usb 1-2: Manufacturer: Magewell > [ 73.620185] usb 1-2: SerialNumber: C021150326019 > [ 76.920993] usb 2-2: Set SEL for device-initiated U2 failed. Everything here happens at USB host driver and USB subsystem. > [ 76.923341] uvcvideo: Found UVC 1.00 device XI100DUSB-HDMI (2935:0001) > [ 76.925324] uvcvideo 1-2:1.0: Entity type for entity Processing 2 was not > initialized! > [ 76.925327] uvcvideo 1-2:1.0: Entity type for entity Camera 1 was not > initialized! The above is at uvcvideo, and seems OK to my eyes. > [ 76.925413] input: XI100DUSB-HDMI: XI100DUSB-HDMI as > /devices/pci:00/:00:14.0/usb1/1-2/1-2:1.0/input/input25 > [ 76.928710] usbhid 1-2:1.4: couldn't find an input interrupt endpoint This is related to input/evdev probing. Also unrelated to media. > [ 91.516482] usb 1-2: USB disconnect, device number 10 This is also at USB subsystem. Usually, it indicates a bad contact at the USB cable. > Is there any workarounds or ideas to make my capture device less annoying? > Thank you in advance, I would try to buy a high quality USB 3.0 cable, and see if things improve. You should remember that a USB 3.0 data transfer will use higher frequency signals, making the cable more susceptible to interference. So, a cable with a good shield can make a difference, specially if you're passing it close to other cables. Thanks, Mauro
Re: getting around "Max number of devices this xHCI host supports is 32" limit
On Sun, Jan 13, 2019 at 07:14:23PM -0800, Marc MERLIN wrote: > On Mon, Dec 31, 2018 at 12:34:31PM -0500, Alan Stern wrote: > > > Just a small addition, many Intel xHCI controllers now support 64 devices. > > > > > > It's possible to get the max device slots xHCI hardware supports from a > > > xHC register. > > > (bits 7:0 of the HCSPARAMS1 capability register) > > > > > > This can be found from debugfs, but it's not very practical: > > > > > > mount -t debugfs none /sys/kernel/debug/ > > > grep HCSPARAMS1 /sys/kernel/debug/usb/xhci/\:00\:14.0/reg-cap > > > HCSPARAMS1 = 0x1a000840 > > > > > > We only care about bits 7:0, by ignoring the other bits we get 0x0040, > > > which is 64 in decimal. > > > > > > So this xHCI supports 64 device slots. > > > > The limits that Marc encountered were on both the number of device > > slots and the number of endpoint slots. In his case, each device has 3 > > endpoints. > > For my own education, I was using USB/Serial converters and raw USB > (android fastboot). > Are there USB devices that only use 2 or 1 endpoint instead of 3 or > more? Yes, there are USB-serial devices which use only two bulk endpoints (e.g. ftdi, I think also cp210x, possibly others). There are even devices that mux up to 16 ports over just three endpoints (e.g. some Moxa devices handled by the mxuport driver). Johan
[PATCH] USB: serial: ftdi_sio: Fix GPIO not working in autosuspend
There is a bug in the current GPIO code for ftdi_sio: it failed to take USB
autosuspend into account. If the device is in autosuspend, calls to
usb_control_msg() fail with -EHOSTUNREACH. Because the standard value for
autosuspend timeout is usually 2-5 seconds, this made it almost impossible
to use the GPIOs on machines that have USB autosuspend enabled. This patch
fixes the issue by acquiring a PM lock on the device for the duration of
the USB transfers. Tested on an FT231X device.
Signed-off-by: Karoly Pados
---
Please consider backporting to 4.20.x, otherwise the GPIO driver is not
really usable for anybody with USB autosuspend enabled (eg. many laptops),
at least not without manual configuration.
drivers/usb/serial/ftdi_sio.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 1ab2a6191013..01813dce37f2 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1783,6 +1783,13 @@ static int ftdi_set_bitmode(struct usb_serial_port
*port, u8 mode)
int result;
u16 val;
+ result = usb_autopm_get_interface(port->serial->interface);
+ if (result) {
+ dev_err(&port->serial->interface->dev,
+ "Failed to wake device from autosuspend.\n");
+ return result;
+ }
+
val = (mode << 8) | (priv->gpio_output << 4) | priv->gpio_value;
result = usb_control_msg(serial->dev,
usb_sndctrlpipe(serial->dev, 0),
@@ -1795,6 +1802,8 @@ static int ftdi_set_bitmode(struct usb_serial_port *port,
u8 mode)
val, result);
}
+ usb_autopm_put_interface(port->serial->interface);
+
return result;
}
@@ -1846,9 +1855,18 @@ static int ftdi_read_cbus_pins(struct usb_serial_port
*port)
unsigned char *buf;
int result;
+ result = usb_autopm_get_interface(port->serial->interface);
+ if (result) {
+ dev_err(&port->serial->interface->dev,
+ "Failed to wake device from autosuspend.\n");
+ return result;
+ }
+
buf = kmalloc(1, GFP_KERNEL);
- if (!buf)
+ if (!buf) {
+ usb_autopm_put_interface(port->serial->interface);
return -ENOMEM;
+ }
result = usb_control_msg(serial->dev,
usb_rcvctrlpipe(serial->dev, 0),
@@ -1863,6 +1881,7 @@ static int ftdi_read_cbus_pins(struct usb_serial_port
*port)
}
kfree(buf);
+ usb_autopm_put_interface(port->serial->interface);
return result;
}
--
2.20.1
Re: [PATCH] USB: serial: ftdi_sio: Fix GPIO not working in autosuspend
On Mon, Jan 14, 2019 at 01:30:03PM +0100, Karoly Pados wrote:
> There is a bug in the current GPIO code for ftdi_sio: it failed to take USB
> autosuspend into account. If the device is in autosuspend, calls to
> usb_control_msg() fail with -EHOSTUNREACH. Because the standard value for
> autosuspend timeout is usually 2-5 seconds, this made it almost impossible
> to use the GPIOs on machines that have USB autosuspend enabled. This patch
> fixes the issue by acquiring a PM lock on the device for the duration of
> the USB transfers. Tested on an FT231X device.
>
> Signed-off-by: Karoly Pados
> ---
> Please consider backporting to 4.20.x, otherwise the GPIO driver is not
> really usable for anybody with USB autosuspend enabled (eg. many laptops),
> at least not without manual configuration.
>
> drivers/usb/serial/ftdi_sio.c | 21 -
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
> index 1ab2a6191013..01813dce37f2 100644
> --- a/drivers/usb/serial/ftdi_sio.c
> +++ b/drivers/usb/serial/ftdi_sio.c
> @@ -1783,6 +1783,13 @@ static int ftdi_set_bitmode(struct usb_serial_port
> *port, u8 mode)
> int result;
> u16 val;
>
> + result = usb_autopm_get_interface(port->serial->interface);
Both of the functions where you add autopm calls already have a local
variable for port->serial.
> + if (result) {
> + dev_err(&port->serial->interface->dev,
> + "Failed to wake device from autosuspend.\n");
And we tend not to log errors for these calls.
> + return result;
> + }
I replaced and port->serial with serial and dropped the dev_err:s before
applying for -rc3 with a Fixes and CC-stable tag.
Thanks,
Johan
Re: USB-C storage device not detected on USB 3.1 Gen 2 host when plugged in after boot
Am 14.01.19 um 11:48 schrieb Oliver Neukum: > On Fr, 2019-01-11 at 19:49 +0100, Jan-Marek Glogowski wrote: >> >> Yup, but the device is just detected if its plugged in on boot / module load. >> I now have recompiled 5.0-rc1 with xhci as a module. > > First of all, is this a regression? Did earlier kernels work? No. I tried 4.4.169, 4.15.0-43, 4.20.0 and finally 5.0.0-rc1. The device actually manages to show up very, very seldomly after plugging in late. I saw it twice when rebooting and re-plugging it a few times, during all my test with different hardware and different Linux versions. >> If I plug the device after the module is loaded, I get no messages in dmesg. >> No devices shows up >> If I rmmod xhci_pci + modprobe xhci_pci the device is correctly enumerated >> and works. >> If I re-plug the device again it also doesn't show up again until module >> "reload". >> >> The attached dmesg is from a boot with the device plugged in. >> >> I had some talk with Greg on #kernelnewbies and he suspected a broken port. >> >> I have no idea if a port can enumerate but not hotplug. >> >> I meanwhile switched to some other HW (Acer n4660g), which shows the same >> problem. So as the ultimate test I had Windows 10 installed on my previous test machine and both USB-C ports worked as expected. > OK, then we need logs of the failure case. A usbmon trace and dmesg > with debugging enabled > > echo "module xhci_hcd +mfp" > /sys/kernel/debug/dynamic_debug/control > echo "module xhci_pci +mfp" > /sys/kernel/debug/dynamic_debug/control > echo "module usbcore +mfp" > /sys/kernel/debug/dynamic_debug/control I realized that the USB bus logging is actually calm after boot with my device plugged, the huge amount of traffic on the USB bus isn't normal and it's somehow started by my device. So I actually booted with "log_buf_len=8M xhci_hcd.dyndbg=+mfp xhci_pci.dyndbg=+mfp usbcore.dyndbg=+mfp" What I did was: * boot with device plugged in - everything is "calm" * modprobe usbmon * cat /sys/kernel/debug/usb/usbmon/0u > /tmp/usbmon-boot.log * unplug the device - wait a bit * re-plug the device - wait a bit (bus goes crazy) * unplug-the device - bus keeps crazy * Ctrl+C cat * dmesg > /tmp/dmesg-boot.log Regards, Jan-Marek dmesg-boot.log.xz Description: application/xz usbmon-boot.log.xz Description: application/xz
Re: getting around "Max number of devices this xHCI host supports is 32" limit
On Mon, 14 Jan 2019, Johan Hovold wrote: > On Sun, Jan 13, 2019 at 07:14:23PM -0800, Marc MERLIN wrote: > > On Mon, Dec 31, 2018 at 12:34:31PM -0500, Alan Stern wrote: > > > > Just a small addition, many Intel xHCI controllers now support 64 > > > > devices. > > > > > > > > It's possible to get the max device slots xHCI hardware supports from a > > > > xHC register. > > > > (bits 7:0 of the HCSPARAMS1 capability register) > > > > > > > > This can be found from debugfs, but it's not very practical: > > > > > > > > mount -t debugfs none /sys/kernel/debug/ > > > > grep HCSPARAMS1 /sys/kernel/debug/usb/xhci/\:00\:14.0/reg-cap > > > > HCSPARAMS1 = 0x1a000840 > > > > > > > > We only care about bits 7:0, by ignoring the other bits we get > > > > 0x0040, > > > > which is 64 in decimal. > > > > > > > > So this xHCI supports 64 device slots. > > > > > > The limits that Marc encountered were on both the number of device > > > slots and the number of endpoint slots. In his case, each device has 3 > > > endpoints. > > > > For my own education, I was using USB/Serial converters and raw USB > > (android fastboot). > > Are there USB devices that only use 2 or 1 endpoint instead of 3 or > > more? > > Yes, there are USB-serial devices which use only two bulk endpoints > (e.g. ftdi, I think also cp210x, possibly others). There are even > devices that mux up to 16 ports over just three endpoints (e.g. some > Moxa devices handled by the mxuport driver). You're forgetting to count ep0. In theory it's possible to have an HID device with only two endpoints (ep0 and intr-IN). However I don't know if any devices like that actually exist. Alan Stern
Re: [PATCH] USB: serial: ftdi_sio: Fix GPIO not working in autosuspend
On Mon, Jan 14, 2019 at 02:48:21PM +0100, Johan Hovold wrote: > On Mon, Jan 14, 2019 at 01:30:03PM +0100, Karoly Pados wrote: > > There is a bug in the current GPIO code for ftdi_sio: it failed to take USB > > autosuspend into account. If the device is in autosuspend, calls to > > usb_control_msg() fail with -EHOSTUNREACH. Because the standard value for > > autosuspend timeout is usually 2-5 seconds, this made it almost impossible > > to use the GPIOs on machines that have USB autosuspend enabled. This patch > > fixes the issue by acquiring a PM lock on the device for the duration of > > the USB transfers. Tested on an FT231X device. > > > > Signed-off-by: Karoly Pados Do you intend to send a corresponding fix for cp210x as well? Thanks, Johan
Re: [PATCH v5 4/6] usb: gadget: add mechanism to specify an explicit status stage
On Mon, 14 Jan 2019, Paul Elder wrote: > > > > Can you check your uvc > > > > changes using dummy_hcd with the patch below? > > > > > > I'm not sure what to make of the test results. I get the same results > > > with or without the patch. Which I guess makes sense... in dummy_queue, > > > this is getting hit when the uvc function driver tries to complete the > > > delayed status: > > > > > > req = usb_request_to_dummy_request(_req); > > > if (!_req || !list_empty(&req->queue) || !_req->complete) > > > return -EINVAL; > > > > > > So the delayed/explicit status stage is never completed, afaict. > > > > I presume you are hitting the !list_empty(&req->queue) test, yes? The > > other two tests are trivial. > > Yes, that is what's happening. > > > Triggering the !list_empty() test means the request has already been > > submitted and not yet completed. This probably indicates there is a > > bug in the uvc function driver code. > > The uvc function driver works with musb, though :/ > > I compared the sequence of calls to the uvc setup, completion handler, > and status stage sending, and for some reason dummy_hcd, after an OUT > setup-completion-status sequence, calls a completion-status-completion > sequence, and then goes on the the next request. musb simply goes on to > the next request after the setup-completion-status sequence. I don't quite understand. There's a control-OUT transfer, the setup, data, and status transactions all complete normally, and then what happens? What do you mean by "a completion-status-completion sequence"? A more detailed description would help. > I commented out the paranoia block in dummy_timer, and dummy_hcd still > does the extra completion, but it doesn't error out anymore. I doubt > that's the/a solution though, especially since I get: > > [ 22.616577] uvcvideo: Failed to query (129) UVC probe control : -75 (exp. > 26). > [ 22.624481] uvcvideo: Failed to initialize the device (-5). > > Not sure if that's a result of dummy_hcd not supporting isochronous > transfers or not. > > I'm not sure where to continue investigating :/ Perhaps removing the "#if 0" protecting the dev_dbg line in dummy_queue() would provide some helpful output. Another thing to check would be if the "implement an emulated single-request FIFO" in dummy_queue() is causing trouble. There's no harm in replacing the long "if" condition with "if (0)". Alan Stern
Re: getting around "Max number of devices this xHCI host supports is 32" limit
On Mon, Jan 14, 2019 at 10:12:09AM -0500, Alan Stern wrote: > On Mon, 14 Jan 2019, Johan Hovold wrote: > > > On Sun, Jan 13, 2019 at 07:14:23PM -0800, Marc MERLIN wrote: > > > On Mon, Dec 31, 2018 at 12:34:31PM -0500, Alan Stern wrote: > > > > > Just a small addition, many Intel xHCI controllers now support 64 > > > > > devices. > > > > > > > > > > It's possible to get the max device slots xHCI hardware supports from > > > > > a xHC register. > > > > > (bits 7:0 of the HCSPARAMS1 capability register) > > > > > > > > > > This can be found from debugfs, but it's not very practical: > > > > > > > > > > mount -t debugfs none /sys/kernel/debug/ > > > > > grep HCSPARAMS1 /sys/kernel/debug/usb/xhci/\:00\:14.0/reg-cap > > > > > HCSPARAMS1 = 0x1a000840 > > > > > > > > > > We only care about bits 7:0, by ignoring the other bits we get > > > > > 0x0040, > > > > > which is 64 in decimal. > > > > > > > > > > So this xHCI supports 64 device slots. > > > > > > > > The limits that Marc encountered were on both the number of device > > > > slots and the number of endpoint slots. In his case, each device has 3 > > > > endpoints. > > > > > > For my own education, I was using USB/Serial converters and raw USB > > > (android fastboot). > > > Are there USB devices that only use 2 or 1 endpoint instead of 3 or > > > more? > > > > Yes, there are USB-serial devices which use only two bulk endpoints > > (e.g. ftdi, I think also cp210x, possibly others). There are even > > devices that mux up to 16 ports over just three endpoints (e.g. some > > Moxa devices handled by the mxuport driver). > > You're forgetting to count ep0. Indeed, and the question doesn't appear to be how to maximise the number of USB serial ports as I first read it either. Sorry about the noise. Johan
[PATCH v2 0/6] MSM8998 basic USB support
This series provides basic USB support for MSM8998. Currently missing is wiring up the Type-C detection logic so that the controller can correctly switch between host and peripheral modes. Work to implement that is ongoing, and expected to appear soon in followup patches. Also missing is Display Port (DP) support which apparently is different from sdm845 and needs additional investigation. v2: -Fixed typo in QUSB2 bindings changes -Split out bindings changes -Fixed dual lane support in QMP to reflect Doug's updates -Dropped the clock fixes which were accepted Jeffrey Hugo (6): clk: qcom: Add missing freq for usb30_master_clk on 8998 clk: qcom: Skip halt checks on gcc_usb3_phy_pipe_clk for 8998 phy: qcom-qusb2: Add QUSB2 PHY support for msm8998 phy: qcom-qmp: Add QMP V3 USB3 PHY support for msm8998 usb: dwc3: qcom: Add support for MSM8998 arm64: dts: qcom: msm8998: Add USB-related nodes .../devicetree/bindings/phy/qcom-qmp-phy.txt | 5 + .../devicetree/bindings/phy/qcom-qusb2-phy.txt | 1 + .../devicetree/bindings/usb/qcom,dwc3.txt | 1 + arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi | 22 arch/arm64/boot/dts/qcom/msm8998.dtsi | 90 + drivers/clk/qcom/gcc-msm8998.c | 3 +- drivers/phy/qualcomm/phy-qcom-qmp.c| 142 + drivers/phy/qualcomm/phy-qcom-qmp.h| 4 + drivers/phy/qualcomm/phy-qcom-qusb2.c | 41 ++ drivers/usb/dwc3/dwc3-qcom.c | 1 + 10 files changed, 309 insertions(+), 1 deletion(-) -- Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH v2 2/6] dt-bindings: usb: Add support for msm8998
msm8998 USB has a dwc3 controller just like the existing sdm845 support Signed-off-by: Jeffrey Hugo --- Documentation/devicetree/bindings/usb/qcom,dwc3.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt index 95afdcf..cb695aa 100644 --- a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt @@ -4,6 +4,7 @@ Required properties: - compatible: Compatible list, contains "qcom,dwc3" "qcom,msm8996-dwc3" for msm8996 SOC. + "qcom,msm8998-dwc3" for msm8998 SOC. "qcom,sdm845-dwc3" for sdm845 SOC. - reg: Offset and length of register set for QSCRATCH wrapper - power-domains: specifies a phandle to PM domain provider node -- Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH v2 1/6] dt-bindings: phy-qcom: Add support for msm8998 usb
USB on msm8998 utilizes the QUSB2 and QMP phys, similar to sdm845. Signed-off-by: Jeffrey Hugo --- Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt | 5 + Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt | 1 + 2 files changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt index 41a1074..6061b6f 100644 --- a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt +++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt @@ -9,6 +9,7 @@ Required properties: "qcom,ipq8074-qmp-pcie-phy" for PCIe phy on IPQ8074 "qcom,msm8996-qmp-pcie-phy" for 14nm PCIe phy on msm8996, "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996, + "qcom,msm8998-qmp-usb3-phy" for USB3 QMP V3 phy on msm8998, "qcom,sdm845-qmp-usb3-phy" for USB3 QMP V3 phy on sdm845, "qcom,sdm845-qmp-usb3-uni-phy" for USB3 QMP V3 UNI phy on sdm845, "qcom,sdm845-qmp-ufs-phy" for UFS QMP phy on sdm845. @@ -42,6 +43,8 @@ Required properties: "aux", "cfg_ahb", "ref". For "qcom,msm8996-qmp-usb3-phy" must contain: "aux", "cfg_ahb", "ref". + For "qcom,msm8998-qmp-usb3-phy" must contain: + "aux", "cfg_ahb", "ref". For "qcom,sdm845-qmp-usb3-phy" must contain: "aux", "cfg_ahb", "ref", "com_aux". For "qcom,sdm845-qmp-usb3-uni-phy" must contain: @@ -60,6 +63,8 @@ Required properties: For "qcom,msm8996-qmp-pcie-phy" must contain: "phy", "common", "cfg". For "qcom,msm8996-qmp-usb3-phy" must contain +"phy", "common". + For "qcom,msm8998-qmp-usb3-phy" must contain "phy", "common". For "qcom,sdm845-qmp-usb3-phy" must contain: "phy", "common". diff --git a/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt index 03025d9..fe29f9e 100644 --- a/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt +++ b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt @@ -6,6 +6,7 @@ QUSB2 controller supports LS/FS/HS usb connectivity on Qualcomm chipsets. Required properties: - compatible: compatible list, contains "qcom,msm8996-qusb2-phy" for 14nm PHY on msm8996, + "qcom,msm8998-qusb2-phy" for 10nm PHY on msm8998, "qcom,sdm845-qusb2-phy" for 10nm PHY on sdm845. - reg: offset and length of the PHY register set. -- Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH v2 3/6] phy: qcom-qusb2: Add QUSB2 PHY support for msm8998
MSM8998 contains one QUSB2 PHY which is very similar to the existing
sdm845 support.
Signed-off-by: Jeffrey Hugo
---
drivers/phy/qualcomm/phy-qcom-qusb2.c | 41 +++
1 file changed, 41 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c
b/drivers/phy/qualcomm/phy-qcom-qusb2.c
index 9177989f..e5e4f36 100644
--- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
+++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
@@ -152,6 +152,32 @@ enum qusb2phy_reg_layout {
QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_PWR_CTRL, 0x00),
};
+static const unsigned int msm8998_regs_layout[] = {
+ [QUSB2PHY_PLL_CORE_INPUT_OVERRIDE] = 0xa8,
+ [QUSB2PHY_PLL_STATUS] = 0x1a0,
+ [QUSB2PHY_PORT_TUNE1] = 0x23c,
+ [QUSB2PHY_PORT_TUNE2] = 0x240,
+ [QUSB2PHY_PORT_TUNE3] = 0x244,
+ [QUSB2PHY_PORT_TUNE4] = 0x248,
+ [QUSB2PHY_PORT_TEST1] = 0x24c,
+ [QUSB2PHY_PORT_TEST2] = 0x250,
+ [QUSB2PHY_PORT_POWERDOWN] = 0x210,
+ [QUSB2PHY_INTR_CTRL] = 0x22c,
+};
+
+static const struct qusb2_phy_init_tbl msm8998_init_tbl[] = {
+ QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_ANALOG_CONTROLS_TWO, 0x13),
+ QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_CLOCK_INVERTERS, 0x7c),
+ QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_CMODE, 0x80),
+ QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_LOCK_DELAY, 0x0a),
+
+ QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE1, 0xa5),
+ QUSB2_PHY_INIT_CFG_L(QUSB2PHY_PORT_TUNE2, 0x09),
+
+ QUSB2_PHY_INIT_CFG(QUSB2PHY_PLL_DIGITAL_TIMERS_TWO, 0x19),
+};
+
+
static const unsigned int sdm845_regs_layout[] = {
[QUSB2PHY_PLL_CORE_INPUT_OVERRIDE] = 0xa8,
[QUSB2PHY_PLL_STATUS] = 0x1a0,
@@ -221,6 +247,18 @@ struct qusb2_phy_cfg {
.autoresume_en = BIT(3),
};
+static const struct qusb2_phy_cfg msm8998_phy_cfg = {
+ .tbl= msm8998_init_tbl,
+ .tbl_num= ARRAY_SIZE(msm8998_init_tbl),
+ .regs = msm8998_regs_layout,
+
+ .disable_ctrl = POWER_DOWN,
+ .mask_core_ready = CORE_READY_STATUS,
+ .has_pll_override = true,
+ .autoresume_en = BIT(0),
+ .update_tune1_with_efuse = true,
+};
+
static const struct qusb2_phy_cfg sdm845_phy_cfg = {
.tbl= sdm845_init_tbl,
.tbl_num= ARRAY_SIZE(sdm845_init_tbl),
@@ -734,6 +772,9 @@ static int qusb2_phy_exit(struct phy *phy)
.compatible = "qcom,msm8996-qusb2-phy",
.data = &msm8996_phy_cfg,
}, {
+ .compatible = "qcom,msm8998-qusb2-phy",
+ .data = &msm8998_phy_cfg,
+ }, {
.compatible = "qcom,sdm845-qusb2-phy",
.data = &sdm845_phy_cfg,
},
--
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH v2 4/6] phy: qcom-qmp: Add QMP V3 USB3 PHY support for msm8998
MSM8998 contains a single QMP v3 USB3 phy similar to the existing sdm845
support.
Signed-off-by: Jeffrey Hugo
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 140
drivers/phy/qualcomm/phy-qcom-qmp.h | 4 ++
2 files changed, 144 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index b400681..daf7515 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -687,6 +687,116 @@ enum qphy_reg_layout {
QMP_PHY_INIT_CFG(QPHY_V3_PCS_MULTI_LANE_CTRL1, 0x02),
};
+static const struct qmp_phy_init_tbl msm8998_usb3_serdes_tbl[] = {
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_CLK_SELECT, 0x30),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_BIAS_EN_CLKBUFLR_EN, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_SYSCLK_EN_SEL, 0x14),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_SYS_CLK_CTRL, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_RESETSM_CNTRL2, 0x08),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_CMN_CONFIG, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_SVS_MODE_CLK_SEL, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_HSCLK_SEL, 0x80),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_DEC_START_MODE0, 0x82),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_DIV_FRAC_START1_MODE0, 0xab),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_DIV_FRAC_START2_MODE0, 0xea),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_DIV_FRAC_START3_MODE0, 0x02),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_CP_CTRL_MODE0, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_RCTRL_MODE0, 0x16),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_CCTRL_MODE0, 0x36),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN1_MODE0, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN0_MODE0, 0x3f),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE2_MODE0, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE1_MODE0, 0xc9),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_CORECLK_DIV_MODE0, 0x0a),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP3_MODE0, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP2_MODE0, 0x34),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP1_MODE0, 0x15),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP_EN, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_CORE_CLK_EN, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP_CFG, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_MAP, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_BG_TIMER, 0x0a),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_IVCO, 0x07),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_INITVAL, 0x80),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_CMN_MODE, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_SSC_EN_CENTER, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_SSC_PER1, 0x31),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_SSC_PER2, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_SSC_ADJ_PER1, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_SSC_ADJ_PER2, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_SSC_STEP_SIZE1, 0x85),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_SSC_STEP_SIZE2, 0x07),
+};
+
+static const struct qmp_phy_init_tbl msm8998_usb3_tx_tbl[] = {
+ QMP_PHY_INIT_CFG(QSERDES_V3_TX_HIGHZ_DRVR_EN, 0x10),
+ QMP_PHY_INIT_CFG(QSERDES_V3_TX_RCV_DETECT_LVL_2, 0x12),
+ QMP_PHY_INIT_CFG(QSERDES_V3_TX_LANE_MODE_1, 0x16),
+ QMP_PHY_INIT_CFG(QSERDES_V3_TX_RES_CODE_LANE_OFFSET_TX, 0x00),
+};
+
+static const struct qmp_phy_init_tbl msm8998_usb3_rx_tbl[] = {
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_FASTLOCK_FO_GAIN, 0x0b),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_EQU_ADAPTOR_CNTRL2, 0x0f),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_EQU_ADAPTOR_CNTRL3, 0x4e),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_EQU_ADAPTOR_CNTRL4, 0x18),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_EQ_OFFSET_ADAPTOR_CNTRL1, 0x07),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_OFFSET_ADAPTOR_CNTRL2, 0x80),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_SIGDET_CNTRL, 0x43),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_SIGDET_DEGLITCH_CNTRL, 0x1c),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_SO_SATURATION_AND_ENABLE, 0x75),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_FASTLOCK_COUNT_LOW, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_FASTLOCK_COUNT_HIGH, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_PI_CONTROLS, 0x80),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_FO_GAIN, 0x0a),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_SO_GAIN, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_SIGDET_ENABLES, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_VGA_CAL_CNTRL2, 0x03),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_MODE_00, 0x05),
+};
+
+static const struct qmp_phy_init_tbl msm8998_usb3_pcs_tbl[] = {
+ QMP_PHY_INIT_CFG(QPHY_V3_PCS_FLL_CNTRL2, 0x83),
+ QMP_PHY_INIT_CFG(QPHY_V3_PCS_FLL_CNT_VAL_L, 0x09),
+ QMP_PHY_INIT_CFG(QPHY_V3_PCS_FLL_CNT_VAL_H_TOL, 0xa2),
+ QMP_PHY_INIT_CFG(QPHY_V3_PCS_FLL_MAN_CODE, 0x40),
+ QMP_PHY_INIT_CFG(QPHY_V3_PCS_FLL_CNTRL1, 0x02),
+ QMP_PHY_INIT_CFG(QPHY_V3_PCS_LOCK_DETECT_CONF
[PATCH v2 5/6] usb: dwc3: qcom: Add support for MSM8998
Add a MSM8998 specific DT compatible so that we can properly bind to the
device and enable the USB controller.
Signed-off-by: Jeffrey Hugo
---
drivers/usb/dwc3/dwc3-qcom.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
index a6d0203..184df4d 100644
--- a/drivers/usb/dwc3/dwc3-qcom.c
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -595,6 +595,7 @@ static int __maybe_unused dwc3_qcom_runtime_resume(struct
device *dev)
static const struct of_device_id dwc3_qcom_of_match[] = {
{ .compatible = "qcom,dwc3" },
{ .compatible = "qcom,msm8996-dwc3" },
+ { .compatible = "qcom,msm8998-dwc3" },
{ .compatible = "qcom,sdm845-dwc3" },
{ }
};
--
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH v2 6/6] arm64: dts: qcom: msm8998: Add USB-related nodes
Add nodes for USB and related PHYs.
Signed-off-by: Jeffrey Hugo
---
arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi | 22
arch/arm64/boot/dts/qcom/msm8998.dtsi | 92 +++
2 files changed, 114 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
b/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
index 50e9033..dc703fc 100644
--- a/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
@@ -257,3 +257,25 @@
pinctrl-0 = <&sdc2_clk_on &sdc2_cmd_on &sdc2_data_on &sdc2_cd_on>;
pinctrl-1 = <&sdc2_clk_off &sdc2_cmd_off &sdc2_data_off &sdc2_cd_off>;
};
+
+&usb1 {
+ status = "okay";
+};
+
+&usb1_dwc3 {
+ dr_mode = "host"; /* Force to host until we have Type-C hooked up */
+};
+
+&usb1_hsphy {
+ status = "okay";
+
+ vdda-pll-supply = <&vreg_l12a_1p8>;
+ vdda-phy-dpdm-supply = <&vreg_l24a_3p075>;
+};
+
+&usb1_qmpphy {
+ status = "okay";
+
+ vdda-phy-supply = <&vreg_l1a_0p875>;
+ vdda-pll-supply = <&vreg_l2a_1p2>;
+};
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi
b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index 8d41b69..706b303 100644
--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -540,6 +540,11 @@
reg = <0x78 0x621c>;
#address-cells = <1>;
#size-cells = <1>;
+
+ qusb2_hstx_trim: hstx-trim@423a {
+ reg = <0x423a 0x1>;
+ bits = <0 4>;
+ };
};
gcc: clock-controller@10 {
@@ -607,6 +612,93 @@
#mbox-cells = <1>;
};
+ usb1: usb@a8f8800 {
+ compatible = "qcom,msm8998-dwc3", "qcom,dwc3";
+ reg = <0xa8f8800 0x400>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ clocks = <&gcc GCC_CFG_NOC_USB3_AXI_CLK>,
+<&gcc GCC_USB30_MASTER_CLK>,
+<&gcc GCC_AGGRE1_USB3_AXI_CLK>,
+<&gcc GCC_USB30_MOCK_UTMI_CLK>,
+<&gcc GCC_USB30_SLEEP_CLK>;
+ clock-names = "cfg_noc", "core", "iface", "mock_utmi",
+ "sleep";
+
+ assigned-clocks = <&gcc GCC_USB30_MOCK_UTMI_CLK>,
+ <&gcc GCC_USB30_MASTER_CLK>;
+ assigned-clock-rates = <1920>, <12000>;
+
+ interrupts = ,
+;
+ interrupt-names = "hs_phy_irq", "ss_phy_irq";
+
+ power-domains = <&gcc USB_30_GDSC>;
+
+ resets = <&gcc GCC_USB_30_BCR>;
+
+ usb1_dwc3: dwc3@a80 {
+ compatible = "snps,dwc3";
+ reg = <0xa80 0xcd00>;
+ interrupts = ;
+ snps,dis_u2_susphy_quirk;
+ snps,dis_enblslpm_quirk;
+ phys = <&usb1_hsphy>, <&usb1_ssphy>;
+ phy-names = "usb2-phy", "usb3-phy";
+ snps,has-lpm-erratum;
+ snps,hird-threshold = /bits/ 8 <0x10>;
+ };
+ };
+
+ usb1_qmpphy: phy@c01 {
+ compatible = "qcom,msm8998-qmp-usb3-phy";
+ reg = <0xc01 0x18c>;
+ status = "disabled";
+ #clock-cells = <1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ clocks = <&gcc GCC_USB3_PHY_AUX_CLK>,
+<&gcc GCC_USB_PHY_CFG_AHB2PHY_CLK>,
+<&gcc GCC_USB3_CLKREF_CLK>;
+ clock-names = "aux", "cfg_ahb", "ref";
+
+ resets = <&gcc GCC_USB3_PHY_BCR>,
+<&gcc GCC_USB3PHY_PHY_BCR>;
+ reset-names = "phy", "common";
+
+ usb1_ssphy: lane@c010200 {
+ reg = <0xc010200 0x128>,
+ <0xc010400 0x200>,
+ <0xc010c00 0x20c>,
+ <0xc010600 0x128>,
+ <0xc010800 0x200>;
+ #phy-cells = <0>;
+ clocks = <&gcc GCC_USB3_PHY_PIPE_CLK>;
+ clock-names = "pipe0";
+
[PATCH] USB: serial: cp210x: Fix GPIO in autosuspend
Current GPIO code in cp210x fails to take USB autosuspend into account,
making it practically impossible to use GPIOs with autosuspend enabled
without user configuration. Fix this like for ftdi_sio in a previous patch.
Tested on a CP2102N.
Signed-off-by: Karoly Pados
---
drivers/usb/serial/cp210x.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index c0777a374a88..8f974eabce63 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -598,9 +598,15 @@ static int cp210x_read_vendor_block(struct usb_serial
*serial, u8 type, u16 val,
void *dmabuf;
int result;
+ result = usb_autopm_get_interface(serial->interface);
+ if (result)
+ return result;
+
dmabuf = kmalloc(bufsize, GFP_KERNEL);
- if (!dmabuf)
+ if (!dmabuf) {
+ usb_autopm_put_interface(serial->interface);
return -ENOMEM;
+ }
result = usb_control_msg(serial->dev, usb_rcvctrlpipe(serial->dev, 0),
CP210X_VENDOR_SPECIFIC, type, val,
@@ -618,6 +624,7 @@ static int cp210x_read_vendor_block(struct usb_serial
*serial, u8 type, u16 val,
}
kfree(dmabuf);
+ usb_autopm_put_interface(serial->interface);
return result;
}
@@ -702,9 +709,15 @@ static int cp210x_write_vendor_block(struct usb_serial
*serial, u8 type,
void *dmabuf;
int result;
+ result = usb_autopm_get_interface(serial->interface);
+ if (result)
+ return result;
+
dmabuf = kmemdup(buf, bufsize, GFP_KERNEL);
- if (!dmabuf)
+ if (!dmabuf) {
+ usb_autopm_put_interface(serial->interface);
return -ENOMEM;
+ }
result = usb_control_msg(serial->dev, usb_sndctrlpipe(serial->dev, 0),
CP210X_VENDOR_SPECIFIC, type, val,
@@ -712,6 +725,7 @@ static int cp210x_write_vendor_block(struct usb_serial
*serial, u8 type,
USB_CTRL_SET_TIMEOUT);
kfree(dmabuf);
+ usb_autopm_put_interface(serial->interface);
if (result == bufsize) {
result = 0;
@@ -1383,6 +1397,7 @@ static void cp210x_gpio_set(struct gpio_chip *gc,
unsigned int gpio, int value)
} else {
u16 wIndex = buf.state << 8 | buf.mask;
+ usb_autopm_get_interface(serial->interface);
result = usb_control_msg(serial->dev,
usb_sndctrlpipe(serial->dev, 0),
CP210X_VENDOR_SPECIFIC,
@@ -1390,6 +1405,7 @@ static void cp210x_gpio_set(struct gpio_chip *gc,
unsigned int gpio, int value)
CP210X_WRITE_LATCH,
wIndex,
NULL, 0, USB_CTRL_SET_TIMEOUT);
+ usb_autopm_put_interface(serial->interface);
}
if (result < 0) {
--
2.20.1
[PATCH] USB: EHCI: ehci-mv: add MODULE_DEVICE_TABLE
This fixes autoloading the module by the OF compatible string.
Fixes: 813e18b18a87f31c5b216ea7546127deac3ae1ae
Cc: sta...@vger.kernel.org # v4.19+
Signed-off-by: Lubomir Rintel
---
drivers/usb/host/ehci-mv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/host/ehci-mv.c b/drivers/usb/host/ehci-mv.c
index f26109eafdbf..66ec1fdf9fe7 100644
--- a/drivers/usb/host/ehci-mv.c
+++ b/drivers/usb/host/ehci-mv.c
@@ -302,3 +302,4 @@ MODULE_AUTHOR("Chao Xie ");
MODULE_AUTHOR("Neil Zhang ");
MODULE_ALIAS("mv-ehci");
MODULE_LICENSE("GPL");
+MODULE_DEVICE_TABLE(of, ehci_mv_dt_ids);
--
2.19.2
usb: dwc2 continuously receiving BNA interrupts on ep0
Hi Minas and John, I'm hoping that one of you can help me devise a fix to a system hang issue caused by BNA interrupts on USB Endpoint 0. Our system is using an Altera Cyclone V SoC FPGA on our board with linux kernel 4.14.44 and enabling the USB gadget for HID (keyboard and mouse) and mass storage (either 1 or 2 interfaces). The USB will always be configured for USB gadget (and never host). On a specific case when enumerating the USB gadget, dwc2 will continuously trigger a BNA interrupts on DPOEPINT0. As a result, it will hang our system and will trigger a watchdog reset. If the watchdog timer is disabled, the system hangs for about 5 to 7 seconds and will get out of the hang after a USB Reset has occur, which will then fix the USB re-enumeration. The USB gadget is configured in the following order: - USB mass storage interface 0 - USB HID keyboard - USB HID mouse If the order is USB HID keyboard, USB HID mouse, and USB mass storage interface 0, the issue will not be encountered. On first USB enumeration of the USB gadget as described above where mass storage interface is enumerated first prior to HID, it will work fine. A copy of a file to a Windows 10 PC will be initiated. The copy will be abruptly interrupted and our system will re-configure the USB gadget to be re-enumerated with only the USB HID available (i.e., no more USB mass storage). On the next USB enumeration where USB mass storage is again enabled, the problem will be encountered. The problem occurs after the following USB requests: 1. After all the Get Descriptor requests for ep0 2. Get Max LUN request for ep0 3. SCSI Inquiry (Lun 0, Page 0) 4. SCSI Inquiry (Lun 0, Page 0) 5. SCSI Inquiry (Lun 0, Page 128) 6. Set Idle on ep0 interface 0 <-- hangs here due to BNA interrupts on DPOEPINT0 Would you guys know how to clear the BNA interrupt for DPOEPINT0? The dwc2_hsotg_epint() function only handles the BNA interrupt if the transfer is isochronous. Thus, in our case, it will never gets cleared. I could not find how to clear this properly on the Altera Cyclone V Technical Reference Manual. I am hoping that you guys would know. For now, once this issue happens on ep0, I just disable the BNA interrupt on dwc2_hsotg_epint. It prevents the system hang but it still halts the USB enumeration for a few seconds until the USB reset occurs. I prefer to resolve it without any hang in the USB enumeration. Thanks in advance, Maynard Ce message, ainsi que tous les fichiers joints à ce message, peuvent contenir des informations sensibles et/ ou confidentielles ne devant pas être divulguées. Si vous n'êtes pas le destinataire de ce message (ou que vous recevez ce message par erreur), nous vous remercions de le notifier immédiatement à son expéditeur, et de détruire ce message. Toute copie, divulgation, modification, utilisation ou diffusion, non autorisée, directe ou indirecte, de tout ou partie de ce message, est strictement interdite. This e-mail, and any document attached hereby, may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized, direct or indirect, copying, disclosure, distribution or other use of the material or parts thereof is strictly forbidden.
[PATCH v2 2/4] arm: dts: mt2701: Add usb2 device nodes
From: Min Guo
Add musb nodes and usb2 phy nodes for MT2701
Signed-off-by: Min Guo
---
arch/arm/boot/dts/mt2701-evb.dts | 21 +
arch/arm/boot/dts/mt2701.dtsi| 33 +
2 files changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
index be0edb3..2635911 100644
--- a/arch/arm/boot/dts/mt2701-evb.dts
+++ b/arch/arm/boot/dts/mt2701-evb.dts
@@ -6,6 +6,7 @@
*/
/dts-v1/;
+#include
#include "mt2701.dtsi"
/ {
@@ -60,6 +61,20 @@
>;
default-brightness-level = <9>;
};
+
+ extcon_usb: extcon_iddig {
+ compatible = "linux,extcon-usb-gpio";
+ id-gpio = <&pio 44 GPIO_ACTIVE_HIGH>;
+ };
+
+ usb_vbus: regulator@0 {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = <&pio 45 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
};
&auxadc {
@@ -229,3 +244,9 @@
&uart0 {
status = "okay";
};
+
+&usb2 {
+ vbus-supply = <&usb_vbus>;
+ extcon = <&extcon_usb>;
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 180377e..a6b1434 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -670,6 +670,39 @@
};
};
+ usb2: usb@1120 {
+ compatible = "mediatek,mt2701-musb",
+"mediatek,mtk-musb";
+ reg = <0 0x1120 0 0x1000>;
+ interrupts = ;
+ interrupt-names = "mc";
+ phys = <&u2port2 PHY_TYPE_USB2>;
+ dr_mode = "otg";
+ clocks = <&pericfg CLK_PERI_USB0>,
+<&pericfg CLK_PERI_USB0_MCU>,
+<&pericfg CLK_PERI_USB_SLV>;
+ clock-names = "main","mcu","univpll";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_IFR_MSC>;
+ status = "disabled";
+ };
+
+ u2phy0: usb-phy@1121 {
+ compatible = "mediatek,generic-tphy-v1";
+ reg = <0 0x1121 0 0x0800>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "okay";
+
+ u2port2: usb-phy@1a1c4800 {
+ reg = <0 0x11210800 0 0x0100>;
+ clocks = <&topckgen CLK_TOP_USB_PHY48M>;
+ clock-names = "ref";
+ #phy-cells = <1>;
+ status = "okay";
+ };
+ };
+
ethsys: syscon@1b00 {
compatible = "mediatek,mt2701-ethsys", "syscon";
reg = <0 0x1b00 0 0x1000>;
--
1.9.1
[PATCH v2 1/4] dt-bindings: usb: musb: Add support for MediaTek musb controller
From: Min Guo
This adds support for MediaTek musb controller in
host, peripheral and otg mode.
Signed-off-by: Min Guo
---
.../devicetree/bindings/usb/mediatek,musb.txt | 43 ++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/mediatek,musb.txt
diff --git a/Documentation/devicetree/bindings/usb/mediatek,musb.txt
b/Documentation/devicetree/bindings/usb/mediatek,musb.txt
new file mode 100644
index 000..3e3f671
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mediatek,musb.txt
@@ -0,0 +1,43 @@
+MediaTek musb DRD/OTG controller
+---
+
+Required properties:
+ - compatible : should be "mediatek,mtk-musb"
+ - reg : specifies physical base address and size of
+ the registers
+ - interrupts : interrupt used by musb controller
+ - interrupt-names : must be "mc"
+ - phys: PHY specifier for the OTG phy
+ - dr_mode : should be one of "host", "peripheral" or "otg",
+ refer to usb/generic.txt
+ - clocks : a list of phandle + clock-specifier pairs, one for
+ each entry in clock-names
+ - clock-names : must contain "main", "mcu", "univpll"
+ for clocks of controller
+
+Optional properties:
+ - extcon : external connector for VBUS and IDPIN changes detection,
+ needed when supports dual-role mode.
+ - vbus-supply : reference to the VBUS regulator, needed when supports
+ dual-role mode.
+ - power-domains : a phandle to USB power domain node to control USB's
+ MTCMOS
+
+Example:
+
+usb2: usb@1120 {
+ compatible = "mediatek,mt2701-musb",
+"mediatek,mtk-musb";
+ reg = <0 0x1120 0 0x1000>;
+ interrupts = ;
+ interrupt-names = "mc";
+ phys = <&u2port2 PHY_TYPE_USB2>;
+ vbus-supply = <&usb_vbus>;
+ extcon = <&extcon_usb>;
+ dr_mode = "otg";
+ clocks = <&pericfg CLK_PERI_USB0>,
+<&pericfg CLK_PERI_USB0_MCU>,
+<&pericfg CLK_PERI_USB_SLV>;
+ clock-names = "main","mcu","univpll";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_IFR_MSC>;
+};
--
1.9.1
[PATCH v2 3/4] usb: musb: Extract set toggle as a separate interface
From: Min Guo
Add a common interface for set data toggle
Signed-off-by: Min Guo
---
drivers/usb/musb/musb_host.c | 37 +++--
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index b59ce9a..16d0ba4 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -306,6 +306,25 @@ static inline void musb_save_toggle(struct musb_qh *qh,
int is_in,
usb_settoggle(urb->dev, qh->epnum, !is_in, csr ? 1 : 0);
}
+static inline u16 musb_set_toggle(struct musb_qh *qh, int is_in,
+ struct urb *urb)
+{
+ u16 csr = 0;
+ u16 toggle = 0;
+
+ toggle = usb_gettoggle(urb->dev, qh->epnum, !is_in);
+
+ if (is_in)
+ csr = toggle ? (MUSB_RXCSR_H_WR_DATATOGGLE
+ | MUSB_RXCSR_H_DATATOGGLE) : 0;
+ else
+ csr = toggle ? (MUSB_TXCSR_H_WR_DATATOGGLE
+ | MUSB_TXCSR_H_DATATOGGLE)
+ : MUSB_TXCSR_CLRDATATOG;
+
+ return csr;
+}
+
/*
* Advance this hardware endpoint's queue, completing the specified URB and
* advancing to either the next URB queued to that qh, or else invalidating
@@ -772,13 +791,8 @@ static void musb_ep_program(struct musb *musb, u8 epnum,
);
csr |= MUSB_TXCSR_MODE;
- if (!hw_ep->tx_double_buffered) {
- if (usb_gettoggle(urb->dev, qh->epnum, 1))
- csr |= MUSB_TXCSR_H_WR_DATATOGGLE
- | MUSB_TXCSR_H_DATATOGGLE;
- else
- csr |= MUSB_TXCSR_CLRDATATOG;
- }
+ if (!hw_ep->tx_double_buffered)
+ csr |= musb_set_toggle(qh, !is_out, urb);
musb_writew(epio, MUSB_TXCSR, csr);
/* REVISIT may need to clear FLUSHFIFO ... */
@@ -860,17 +874,12 @@ static void musb_ep_program(struct musb *musb, u8 epnum,
/* IN/receive */
} else {
- u16 csr;
+ u16 csr = 0;
if (hw_ep->rx_reinit) {
musb_rx_reinit(musb, qh, epnum);
+ csr |= musb_set_toggle(qh, !is_out, urb);
- /* init new state: toggle and NYET, maybe DMA later */
- if (usb_gettoggle(urb->dev, qh->epnum, 0))
- csr = MUSB_RXCSR_H_WR_DATATOGGLE
- | MUSB_RXCSR_H_DATATOGGLE;
- else
- csr = 0;
if (qh->type == USB_ENDPOINT_XFER_INT)
csr |= MUSB_RXCSR_DISNYET;
--
1.9.1
[PATCH v2 4/4] usb: musb: Add support for MediaTek musb controller
From: Min Guo
This adds support for MediaTek musb controller in
host, peripheral and otg mode.
There are some quirk of MediaTek musb controller, such as:
-W1C interrupt status registers
-Private data toggle registers
-No dedicated DMA interrupt line
Signed-off-by: Min Guo
Signed-off-by: Yonglong Wu
---
drivers/usb/musb/Kconfig | 8 +-
drivers/usb/musb/Makefile| 1 +
drivers/usb/musb/mediatek.c | 617 +++
drivers/usb/musb/musb_core.c | 69 +
drivers/usb/musb/musb_core.h | 9 +
drivers/usb/musb/musb_dma.h | 9 +
drivers/usb/musb/musb_host.c | 26 +-
drivers/usb/musb/musb_io.h | 6 +
drivers/usb/musb/musbhsdma.c | 55 ++--
9 files changed, 762 insertions(+), 38 deletions(-)
create mode 100644 drivers/usb/musb/mediatek.c
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index ad08895..b72b7c1 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -115,6 +115,12 @@ config USB_MUSB_JZ4740
depends on USB_MUSB_GADGET
depends on USB_OTG_BLACKLIST_HUB
+config USB_MUSB_MEDIATEK
+ tristate "MediaTek platforms"
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ depends on NOP_USB_XCEIV
+ depends on GENERIC_PHY
+
config USB_MUSB_AM335X_CHILD
tristate
@@ -141,7 +147,7 @@ config USB_UX500_DMA
config USB_INVENTRA_DMA
bool 'Inventra'
- depends on USB_MUSB_OMAP2PLUS
+ depends on USB_MUSB_OMAP2PLUS || USB_MUSB_MEDIATEK
help
Enable DMA transfers using Mentor's engine.
diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile
index 3a88c79..63d82d0 100644
--- a/drivers/usb/musb/Makefile
+++ b/drivers/usb/musb/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_USB_MUSB_DA8XX) += da8xx.o
obj-$(CONFIG_USB_MUSB_UX500) += ux500.o
obj-$(CONFIG_USB_MUSB_JZ4740) += jz4740.o
obj-$(CONFIG_USB_MUSB_SUNXI) += sunxi.o
+obj-$(CONFIG_USB_MUSB_MEDIATEK)+= mediatek.o
obj-$(CONFIG_USB_MUSB_AM335X_CHILD)+= musb_am335x.o
diff --git a/drivers/usb/musb/mediatek.c b/drivers/usb/musb/mediatek.c
new file mode 100644
index 000..7221989
--- /dev/null
+++ b/drivers/usb/musb/mediatek.c
@@ -0,0 +1,617 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 MediaTek Inc.
+ *
+ * Author:
+ * Min Guo
+ * Yonglong Wu
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "musb_core.h"
+#include "musb_dma.h"
+
+#define USB_L1INTS 0x00a0
+#define USB_L1INTM 0x00a4
+#define MTK_MUSB_TXFUNCADDR0x0480
+
+/* MediaTek controller toggle enable and status reg */
+#define MUSB_RXTOG 0x80
+#define MUSB_RXTOGEN 0x82
+#define MUSB_TXTOG 0x84
+#define MUSB_TXTOGEN 0x86
+
+#define TX_INT_STATUS BIT(0)
+#define RX_INT_STATUS BIT(1)
+#define USBCOM_INT_STATUS BIT(2)
+#define DMA_INT_STATUS BIT(3)
+
+#define DMA_INTR_STATUS_MSKGENMASK(7, 0)
+#define DMA_INTR_UNMASK_SET_MSKGENMASK(31, 24)
+
+enum mtk_vbus_id_state {
+ MTK_ID_FLOAT = 1,
+ MTK_ID_GROUND,
+ MTK_VBUS_OFF,
+ MTK_VBUS_VALID,
+};
+
+struct mtk_glue {
+ struct device *dev;
+ struct musb *musb;
+ struct platform_device *musb_pdev;
+ struct platform_device *usb_phy;
+ struct phy *phy;
+ struct usb_phy *xceiv;
+ enum phy_mode phy_mode;
+ struct clk *main;
+ struct clk *mcu;
+ struct clk *univpll;
+ struct regulator *vbus;
+ struct extcon_dev *edev;
+ struct notifier_block vbus_nb;
+ struct notifier_block id_nb;
+};
+
+static int mtk_musb_clks_get(struct mtk_glue *glue)
+{
+ struct device *dev = glue->dev;
+
+ glue->main = devm_clk_get(dev, "main");
+ if (IS_ERR(glue->main)) {
+ dev_err(dev, "fail to get main clock\n");
+ return PTR_ERR(glue->main);
+ }
+
+ glue->mcu = devm_clk_get(dev, "mcu");
+ if (IS_ERR(glue->mcu)) {
+ dev_err(dev, "fail to get mcu clock\n");
+ return PTR_ERR(glue->mcu);
+ }
+
+ glue->univpll = devm_clk_get(dev, "univpll");
+ if (IS_ERR(glue->univpll)) {
+ dev_err(dev, "fail to get univpll clock\n");
+ return PTR_ERR(glue->univpll);
+ }
+
+ return 0;
+}
+
+static int mtk_musb_clks_enable(struct mtk_glue *glue)
+{
+ int ret;
+
+ ret = clk_prepare_enable(glue->main);
+ if (ret) {
+ dev_err(glue->dev, "failed to enable main clock\n");
+ goto err_main_clk;
+ }
+
+ ret = clk_prepare_enable(glue->mcu);
+ if (ret) {
+ dev_err(glue->dev, "failed to enable mcu clock\n");
+ goto err_mcu_clk;
+ }
+
+ ret = clk_prepare_enable(glue->univpll);
+ if (ret) {
+ dev_err(glue->dev, "failed to enable univpll
[PATCH v2 0/4] Add MediaTek MUSB Controller Driver
From: Min Guo These patches introduce the MediaTek MUSB controller driver. The driver can be configured as Dual-Role Device (DRD), Peripheral Only and Host Only modes. This has beed tested on MT2701 with a variety of devices in host mode and with the f_mass gadget driver in peripheral mode, plugging otg cables in/out a lot of times in all possible imaginable plug orders. changes in v2: changes of dt-bindings suggested by Rob and Bin: 1. Modify DRC to DRD 2. Drop the "-musb" in compatible 3. Remove phy-names 4. Add space after comma in clock-names dtsi: 1. Remove phy-names changes of driver suggested by Bin: 1. Add a new patch for musb_set_toggle 2. Add summarize of MediaTek musb controller differences in the commit log 3. Abondon patch "usb: musb: Move musbhsdma macro definition to musb_dma.h" 4. Add "|| COMPILE_TEST" in Kconfig 5. Add musb_clearb() and musb_clearw() hooks 6. Add get_toggle() and set_toggle() hooks 7. Replace musb_readl() with musb_readw() to read 16bit toggle register 8. Move MediaTek's private toggle registers from musb_regs.h to mediatek.c 9. Create musbhs_dma_controller_create_noirq() Min Guo (4): dt-bindings: usb: musb: Add support for MediaTek musb controller arm: dts: mt2701: Add usb2 device nodes usb: musb: Extract set toggle as a separate interface usb: musb: Add support for MediaTek musb controller .../devicetree/bindings/usb/mediatek,musb.txt | 43 ++ arch/arm/boot/dts/mt2701-evb.dts | 21 + arch/arm/boot/dts/mt2701.dtsi | 33 ++ drivers/usb/musb/Kconfig | 8 +- drivers/usb/musb/Makefile | 1 + drivers/usb/musb/mediatek.c| 617 + drivers/usb/musb/musb_core.c | 69 +++ drivers/usb/musb/musb_core.h | 9 + drivers/usb/musb/musb_dma.h| 9 + drivers/usb/musb/musb_host.c | 35 +- drivers/usb/musb/musb_io.h | 6 + drivers/usb/musb/musbhsdma.c | 55 +- 12 files changed, 868 insertions(+), 38 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/mediatek,musb.txt create mode 100644 drivers/usb/musb/mediatek.c -- 1.9.1
Re: Magewell Gen 2935:0001 USB annoyances
Thanks for getting back to me Mauro. So it works on MacOS via a hootoo USB-C dongle https://s.natalian.org/2019-01-15/hootoo.jpeg So since my T480s has two USB-C ports, I tried using the same dongle on my Thinkpad. It works! I discovered that I can reliably get the device working by using another USB-C adaptor. https://s.natalian.org/2019-01-15/ss.jpeg This to my astonishment reliably works. [hendry@t480s ~]$ lsusb -vvv 2>/dev/null | grep -A5 2935:0001 Bus 004 Device 002: ID 2935:0001 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 3.00 bDeviceClass 239 Miscellaneous Device Maybe it's some USB bus power supply issue on my other Thinkpad ports. No idea. Thanks for sounding me out.
Re: [PATCH v2 05/10] phy: add A3700 UTMI PHY driver
Hi, On Fri, 2019-01-11 at 14:31 +0100, Miquel Raynal wrote: > Marvell Armada 3700 SoC has two USB controllers, each of them being > wired to an internal UTMI PHY. Add a driver to control them. > > Igal Liberman worked on supporting the PHY, I took the while 'register > configuration' from his work and rewrote almost entirely the > driver/bindings around it. > > Co-developed-by: Igal Liberman > Signed-off-by: Miquel Raynal > Signed-off-by: Igal Liberman > --- > drivers/phy/marvell/Kconfig| 9 + > drivers/phy/marvell/Makefile | 1 + > drivers/phy/marvell/phy-mvebu-a3700-utmi.c | 297 + > 3 files changed, 307 insertions(+) > create mode 100644 drivers/phy/marvell/phy-mvebu-a3700-utmi.c > > diff --git a/drivers/phy/marvell/Kconfig b/drivers/phy/marvell/Kconfig > index 9c90c0408ea3..b8e9dd38ad0d 100644 > --- a/drivers/phy/marvell/Kconfig > +++ b/drivers/phy/marvell/Kconfig > @@ -33,6 +33,15 @@ config PHY_MVEBU_A3700_COMPHY > shared serdes PHYs on Marvell Armada 3700. Its serdes lanes can be > used by various controllers: Ethernet, SATA, USB3, PCIe. > > +config PHY_MVEBU_A3700_UTMI > + tristate "Marvell A3700 UTMI driver" > + depends on ARCH_MVEBU || COMPILE_TEST > + depends on OF > + default y > + select GENERIC_PHY > + help > + Enable this to support Marvell A3700 UTMI PHY driver. > + > config PHY_MVEBU_CP110_COMPHY > tristate "Marvell CP110 comphy driver" > depends on ARCH_MVEBU || COMPILE_TEST > diff --git a/drivers/phy/marvell/Makefile b/drivers/phy/marvell/Makefile > index c13a0c8ab6f0..82f291cf59ee 100644 > --- a/drivers/phy/marvell/Makefile > +++ b/drivers/phy/marvell/Makefile > @@ -3,6 +3,7 @@ obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY)+= > phy-armada375-usb2.o > obj-$(CONFIG_PHY_BERLIN_SATA)+= phy-berlin-sata.o > obj-$(CONFIG_PHY_BERLIN_USB) += phy-berlin-usb.o > obj-$(CONFIG_PHY_MVEBU_A3700_COMPHY) += phy-mvebu-a3700-comphy.o > +obj-$(CONFIG_PHY_MVEBU_A3700_UTMI) += phy-mvebu-a3700-utmi.o > obj-$(CONFIG_PHY_MVEBU_CP110_COMPHY) += phy-mvebu-cp110-comphy.o > obj-$(CONFIG_PHY_MVEBU_SATA) += phy-mvebu-sata.o > obj-$(CONFIG_PHY_PXA_28NM_HSIC) += phy-pxa-28nm-hsic.o > diff --git a/drivers/phy/marvell/phy-mvebu-a3700-utmi.c > b/drivers/phy/marvell/phy-mvebu-a3700-utmi.c > new file mode 100644 > index ..97d8235d661d > --- /dev/null > +++ b/drivers/phy/marvell/phy-mvebu-a3700-utmi.c > @@ -0,0 +1,297 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2018 Marvell > + * > + * Authors: > + * Evan Wang > + * Miquèl Raynal > + * > + * Marvell A3700 UTMI PHY driver > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* Armada 3700 UTMI PHY registers */ > +#define USB2_PHY_PLL_CTRL_REG0 0x0 > +#define PLL_REF_DIV_OFF0 > +#define PLL_REF_DIV_MASK (0x7F << PLL_REF_DIV_OFF) use GENMASK? > +#define PLL_REF_DIV_5 0x5 > +#define PLL_FB_DIV_OFF 16 > +#define PLL_FB_DIV_MASK(0x1FF << PLL_FB_DIV_OFF) > +#define PLL_FB_DIV_96 96 > +#define PLL_SEL_LPFR_OFF 28 > +#define PLL_SEL_LPFR_MASK (0x3 << PLL_SEL_LPFR_OFF) > +#define PLL_READY BIT(31) > +#define USB2_PHY_CAL_CTRL0x8 > +#define PHY_PLLCAL_DONEBIT(31) > +#define PHY_IMPCAL_DONEBIT(23) > +#define USB2_RX_CHAN_CTRL1 0x18 > +#define USB2PHY_SQCAL_DONE BIT(31) > +#define USB2_PHY_OTG_CTRL0x34 > +#define PHY_PU_OTG BIT(4) > +#define USB2_PHY_CHRGR_DETECT0x38 > +#define PHY_CDP_EN BIT(2) > +#define PHY_DCP_EN BIT(3) > +#define PHY_PD_EN BIT(4) > +#define PHY_PU_CHRG_DTCBIT(5) > +#define PHY_CDP_DM_AUTOBIT(7) > +#define PHY_ENSWITCH_DPBIT(12) > +#define PHY_ENSWITCH_DMBIT(13) > + > +/* Armada 3700 USB miscellaneous registers */ > +#define USB2_PHY_CTRL(usb32) (usb32 ? 0x20 : 0x4) > +#define RB_USB2PHY_PU BIT(0) > +#define USB2_DP_PULLDN_DEV_MODEBIT(5) > +#define USB2_DM_PULLDN_DEV_MODEBIT(6) > +#define RB_USB2PHY_SUSPM(usb32)(usb32 ? BIT(14) : BIT(7)) > + > +#define PLL_LOCK_DELAY_US1 > +#define PLL_LOCK_TIMEOUT_US 100 > + > +/** > + * struct mvebu_a3700_utmi_caps - PHY capabilities > + * > + * @usb32: Flag indicating which PHY is in use (impacts the register map): > + * - The UTMI PHY wired to
