Re: [PATCH] USB: qcaux: Add Motorola modem UARTs

[Tony Lindgren]

* Tony Lindgren  [181206 07:48]:
> * Johan Hovold  [181206 06:00]:
> > How do switch modes by the way?
> 
> The flash mode gets enabled with the control GPIOs. I just
> did a quick test patch for phy-mapphone-mdm6600 using module
> param for that. Then additionally the modem USB can be
> multiplexed to the PC by configuring mode in phy-cpcap-usb
> but I don't have a patch for that.

FYI, below is the test patch against next I used for switching
between normal mode and flash mode with a module param flash_mode
if somebody wants to play with it. For flashing the modem,
Android update-binary does it to deal with the signed modem
firmware, I don't know of the details what happens there.

Kishon, is there maybe some phy framework sysfs property
we could use for switching phy modes?

Regards,

Tony

8< ---
diff --git a/drivers/phy/motorola/phy-mapphone-mdm6600.c 
b/drivers/phy/motorola/phy-mapphone-mdm6600.c
--- a/drivers/phy/motorola/phy-mapphone-mdm6600.c
+++ b/drivers/phy/motorola/phy-mapphone-mdm6600.c
@@ -80,6 +80,10 @@ enum phy_mdm6600_status {
PHY_MDM6600_STATUS_UNDEFINED,
 };
 
+static bool flash_mode;
+module_param(flash_mode, bool, 0);
+MODULE_PARM_DESC(flash_mode, "Start mdm6600 in flash mode");
+
 static const char * const
 phy_mdm6600_status_name[] = {
"off", "busy", "qc_dl", "ram_dl", "awake",
@@ -249,6 +253,9 @@ static irqreturn_t phy_mdm6600_wakeirq_thread(int irq, void 
*data)
struct phy_mdm6600 *ddata = data;
struct gpio_desc *mode_gpio1;
 
+   if (flash_mode)
+   return IRQ_NONE;
+
mode_gpio1 = ddata->mode_gpios->desc[PHY_MDM6600_MODE1];
dev_dbg(ddata->dev, "OOB wake on mode_gpio1: %i\n",
gpiod_get_value(mode_gpio1));
@@ -377,8 +384,13 @@ static int phy_mdm6600_device_power_on(struct phy_mdm6600 
*ddata)
 * to configure USB flashing mode later on based on a module
 * parameter.
 */
-   gpiod_set_value_cansleep(mode_gpio0, 0);
-   gpiod_set_value_cansleep(mode_gpio1, 0);
+   if (flash_mode) {
+   gpiod_set_value_cansleep(mode_gpio0, 1);
+   gpiod_set_value_cansleep(mode_gpio1, 1);
+   } else {
+   gpiod_set_value_cansleep(mode_gpio0, 0);
+   gpiod_set_value_cansleep(mode_gpio1, 0);
+   }
 
/* Request start-up mode */
phy_mdm6600_cmd(ddata, PHY_MDM6600_CMD_NO_BYPASS);
@@ -414,7 +426,12 @@ static int phy_mdm6600_device_power_on(struct phy_mdm6600 
*ddata)
dev_err(ddata->dev, "Timed out powering up\n");
}
 
-   /* Reconfigure mode1 GPIO as input for OOB wake */
+   /* Maybe reconfigure mode1 GPIO as input for OOB wake? */
+   if (flash_mode) {
+   dev_info(ddata->dev, "Started in flash mode\n");
+   goto done;
+   }
+
gpiod_direction_input(mode_gpio1);
 
wakeirq = gpiod_to_irq(mode_gpio1);
@@ -431,7 +448,7 @@ static int phy_mdm6600_device_power_on(struct phy_mdm6600 
*ddata)
if (error)
dev_warn(ddata->dev, "no modem wakeirq irq%i: %i\n",
 wakeirq, error);
-
+done:
ddata->running = true;
 
return error;
@@ -499,6 +516,9 @@ static void phy_mdm6600_modem_wake(struct work_struct *work)
 {
struct phy_mdm6600 *ddata;
 
+   if (flash_mode)
+   return;
+
ddata = container_of(work, struct phy_mdm6600, modem_wake_work.work);
phy_mdm6600_wake_modem(ddata);
schedule_delayed_work(>modem_wake_work,
@@ -509,6 +529,9 @@ static int __maybe_unused 
phy_mdm6600_runtime_suspend(struct device *dev)
 {
struct phy_mdm6600 *ddata = dev_get_drvdata(dev);
 
+   if (flash_mode)
+   return 0;
+
cancel_delayed_work_sync(>modem_wake_work);
ddata->awake = false;
 
@@ -519,6 +542,9 @@ static int __maybe_unused phy_mdm6600_runtime_resume(struct 
device *dev)
 {
struct phy_mdm6600 *ddata = dev_get_drvdata(dev);
 
+   if (flash_mode)
+   return 0;
+
phy_mdm6600_modem_wake(>modem_wake_work.work);
ddata->awake = true;
 
-- 
2.19.2

Re: [PATCH] USB: qcaux: Add Motorola modem UARTs

[Tony Lindgren]

Hi,

* Johan Hovold  [181206 06:00]:
> On Wed, Dec 05, 2018 at 05:54:07PM -0800, Tony Lindgren wrote:
...
> >   idVendor   0x22b8 
> >   idProduct  0x4281 
> 
> This PID is not included in your patch however.

Oops sorry did a cat on wrong two trimmed lsusb -v output
files..

> And this doesn't look like a modem with five (?) interfaces, but I guess
> it's in "flash" mode?

Yes, the wrong lsusb output is  for the flash mode that we're not
adding here and can be ignored for now.

> Could you post the output for the two devices you have in "modem" mode?

Yes correct lsusb -v output below with five UARTs with ff/ff/ff and
two QMI ports that are already handled with an earlier commit
4071898bf0f4 ("net: qmi_wwan: Add USB IDs for MDM6600 modem on
Motorola Droid 4").

> How do switch modes by the way?

The flash mode gets enabled with the control GPIOs. I just
did a quick test patch for phy-mapphone-mdm6600 using module
param for that. Then additionally the modem USB can be
multiplexed to the PC by configuring mode in phy-cpcap-usb
but I don't have a patch for that.

Regards,

Tony

8< ---
Bus 001 Device 002: ID 22b8:2a70  
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x22b8 
  idProduct  0x2a70 
  bcdDevice0.00
  iManufacturer   1 Motorola, Incorporated
  iProduct2 Flash MZ600
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   0x00fb
bNumInterfaces  9
bConfigurationValue 1
iConfiguration  3 Motorola Configuration
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower  500mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 
  bInterfaceSubClass255 
  bInterfaceProtocol255 
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval  32
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval  32
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 
  bInterfaceSubClass255 
  bInterfaceProtocol255 
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval  32
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval  32
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber2
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 
  bInterfaceSubClass255 
  bInterfaceProtocol255 
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval  32
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03  EP 3 OUT
   

Re: [PATCH] USB: qcaux: Add Motorola modem UARTs

[Tony Lindgren]

Hi,

* Johan Hovold  [181205 06:17]:
> On Sun, Dec 02, 2018 at 05:34:24PM -0800, Tony Lindgren wrote:
> > On Motorola Mapphone devices such as Droid 4 there are five USB ports
> > that do not use the same layout as Gobi 1K/2K/etc devices listed in
> > qcserial.c. So we should use qcaux.c or option.c as noted by
> > Dan Williams .
> > 
> > The ff/ff/ff interfaces seem to always be UARTs on Motorola devices.
> > And we should not add interfaces with 0x0a class (CDC Data) as they
> > are part of a multi-interface function like for example interface
> > 0x22b8:0x4281 as noted by Bjørn Mork .
> 
> Can you post the output of usb-devices (or lsusb -v) for these three
> devices (PIDs)?

Here's two out of three for you to look at. They're all listed in
drivers/usb/serial/mdm6600.c in at least the Motorola Mapphone
Android kernels, see for example the LineageOS kernel at [0] if
you want to look at the USB serial driver.

I don't have a device with 9600 with 0x2e0a id.

Regards,

Tony

[0] 
https://github.com/LineageOS/android_kernel_motorola_omap4-common/blob/cm-14.1/drivers/usb/serial/mdm6600.c

8< -
Bus 001 Device 002: ID 22b8:4281  
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x22b8 
  idProduct  0x4281 
  bcdDevice0.00
  iManufacturer   1 Motorola, Incorporated
  iProduct2 Flash MZ600
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   0x0020
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  3 Motorola Configuration
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower  500mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass10 
  bInterfaceSubClass  0 
  bInterfaceProtocol252 
  iInterface  5 Motorola Flash
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
Device Status: 0x
  (Bus Powered)

Bus 003 Device 109: ID 22b8:900e  
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x22b8 
  idProduct  0x900e 
  bcdDevice0.00
  iManufacturer   1 Motorola, Incorporated
  iProduct2 Flash MZ600
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   0x0020
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  3 Motorola Configuration
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower  500mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 
  bInterfaceSubClass255 
  bInterfaceProtocol255 
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval  32
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval  32
Device Status: 0x
  (Bus Powered)

[PATCH] USB: qcaux: Add Motorola modem UARTs

[Tony Lindgren]

On Motorola Mapphone devices such as Droid 4 there are five USB ports
that do not use the same layout as Gobi 1K/2K/etc devices listed in
qcserial.c. So we should use qcaux.c or option.c as noted by
Dan Williams .

The ff/ff/ff interfaces seem to always be UARTs on Motorola devices.
And we should not add interfaces with 0x0a class (CDC Data) as they
are part of a multi-interface function like for example interface
0x22b8:0x4281 as noted by Bjørn Mork .

The ttyUSB ports on Droid 4 seem to be:

ttyUSB0 DIAG, CQDM-capable
ttyUSB1 MUX or NMEA, no response
ttyUSB2 MUX or NMEA, no response
ttyUSB3 TCMD
ttyUSB4 AT-capable

To enable the MUX or NMEA ports, it seems that something needs
to be done additionally to enable them, maybe via the DIAG or
TCMD port. Who knows, maybe it's just some NVRAM setting.

Cc: Bjørn Mork 
Cc: Johan Hovold 
Cc: Dan Williams 
Cc: Marcel Partap 
Cc: Merlijn Wajer 
Cc: Pavel Machek 
Cc: Sebastian Reichel 
Signed-off-by: Tony Lingren 
---
 drivers/usb/serial/qcaux.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/usb/serial/qcaux.c b/drivers/usb/serial/qcaux.c
--- a/drivers/usb/serial/qcaux.c
+++ b/drivers/usb/serial/qcaux.c
@@ -42,6 +42,12 @@
 #define LG_VENDOR_ID   0x1004
 #define LG_PRODUCT_VX4400_6000 0x6000 /* VX4400/VX6000/Rumor */
 
+/* Motorola devices */
+#define MOTOROLA_VENDOR_ID 0x22b8
+#define MOTOROLA_PRODUCT_MDM6600   0x2a70 /* MDM6600 on mapphone */
+#define MOTOROLA_PRODUCT_MDM9600   0x2e0a /* MDM9600 on mapphone */
+#define MOTOROLA_PRODUCT_MDM_FLASH 0x900e /* MDM UART flash mode */
+
 /* Sanyo devices */
 #define SANYO_VENDOR_ID0x0474
 #define SANYO_PRODUCT_KATANA_LX0x0754 /* SCP-3800 
(Katana LX) */
@@ -60,6 +66,9 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(CMOTECH_VENDOR_ID, 
CMOTECH_PRODUCT_CDU550, 0xff, 0xff, 0x00) },
{ USB_DEVICE_AND_INTERFACE_INFO(CMOTECH_VENDOR_ID, 
CMOTECH_PRODUCT_CDX650, 0xff, 0xff, 0x00) },
{ USB_DEVICE_AND_INTERFACE_INFO(LG_VENDOR_ID, LG_PRODUCT_VX4400_6000, 
0xff, 0xff, 0x00) },
+   { USB_DEVICE_AND_INTERFACE_INFO(MOTOROLA_VENDOR_ID, 
MOTOROLA_PRODUCT_MDM6600, 0xff, 0xff, 0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(MOTOROLA_VENDOR_ID, 
MOTOROLA_PRODUCT_MDM9600, 0xff, 0xff, 0xff) },
+   { USB_DEVICE_AND_INTERFACE_INFO(MOTOROLA_VENDOR_ID, 
MOTOROLA_PRODUCT_MDM_FLASH, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(SANYO_VENDOR_ID, 
SANYO_PRODUCT_KATANA_LX, 0xff, 0xff, 0x00) },
{ USB_DEVICE_AND_INTERFACE_INFO(SAMSUNG_VENDOR_ID, 
SAMSUNG_PRODUCT_U520, 0xff, 0x00, 0x00) },
{ USB_VENDOR_AND_INTERFACE_INFO(UTSTARCOM_VENDOR_ID, 0xff, 0xfd, 0xff) 
},  /* NMEA */
-- 
2.19.2

Re: [PATCH 0/3] Fix OMAP EHCI probe & assorted cleanups

[Tony Lindgren]

* Laurent Pinchart  [180911 16:12]:
> On Tuesday, 11 September 2018 18:16:41 EEST Tony Lindgren wrote:
> > * Laurent Pinchart  [180911 15:10]:
> > > Hello,
> > > 
> > > This series fixes a v4.19-rc1 regression that results in OMAP EHCI failing
> > > to probe (patch 1/3) and then moves on to cleaning up related code
> > > (patches 2/3 and 3/3).
> > > 
> > > The first patch is a regression fix and should thus be merged before
> > > v4.19. The other two patches can wait until v4.20.
> > 
> > Hmm can you please check again with this patch applied:
> > 
> > "[PATCH] mfd: omap-usb-host: Fix dts probe of children"
> 
> This fixes the issue for me.
> 
> Tested-by: Laurent Pinchart 

OK good to hear.

> > That was supposed to be queued for v4.18 but fell through the
> > cracks and I only recently noticed it but Lee has it tagged
> > now for v4.19-rc series.
> > 
> > But maybe there are additional issues..
> 
> I think we can go one step further and avoid using fs_initcall, but that can 
> wait for v4.20. What's your opinion on that ? If you agree I'll resubmit this 
> series rebased on top of the aforementioned patch.

Yes sounds good to me. Actually with ti-sysc we're probing the
interconnect target modules at module_init time, so any children
will only get probed after that and the fs_initcall is not
doing anything before that mhuwhhaa.

But yeah hopefully the fs_initcall is no longer needed with
device tree based booting even before we have all the dts
files using ti-sysc.

> > > Tony, as patch 1/3 fixes a problem introduced by one of your DT changes,
> > > could you please review it ? Out of curiosity, is ethernet on the
> > > Pandaboard not part of your regression tests ?
> > 
> > Sorry not any longer.. I've switched over to wlan based
> > setup for PM testing:
> > 
> > 1. u-boot downloads kernel dtb and modules.tar.gz and writes
> >modules.tar.gz to MMC card
> > 
> > 2. on kernel boot, first modules.tar.gz is unpacked
> > 
> > 3. distro brings up wlan but no USB ether
> > 
> > So I can now test also PM on pandaboard-es. I do have ohci
> > enabled on droid4 though for mdm6600 modem, but usually have
> > ehci disabled as the w3glte modem on ehci does not yet work
> > with mainline kernel.
> 
> :-/ If you have a test script that analyzes the kernel log, it would be 
> useful 
> to add a check to verify that the USB ethernet interface chip is detected. 
> That would prevent the regression we're seeing here.

Yeah sorry about the regression.

Hrm well it goes back to the droid4 lcd patches again that I've
been carrying along :) I did not notice this was still pending
too buried into the pile I was carrying until recently.. The
original fix was already sent back in April.

I in fact worked all summer using Linux next (working) snapshots
on droid4 with a lapdock over ssh and mdm6600 modem on it's ohci
bus being my main connection. So the *hci is getting tested by
real use in this case, no need to analyze kernel logs unless
something goes wrong.

Regards,

Tony

Re: [PATCH 0/3] Fix OMAP EHCI probe & assorted cleanups

[Tony Lindgren]

* Tony Lindgren  [180911 15:21]:
> * Laurent Pinchart  [180911 15:10]:
> > Tony, as patch 1/3 fixes a problem introduced by one of your DT changes, 
> > could
> > you please review it ? Out of curiosity, is ethernet on the Pandaboard not
> > part of your regression tests ?
> 
> Sorry not any longer.. I've switched over to wlan based
> setup for PM testing:
> 
> 1. u-boot downloads kernel dtb and modules.tar.gz and writes
>modules.tar.gz to MMC card

To clarify, u-boot downloads kernel, dtb and modules.tar.gz
over USB Ethernet and writes modules.tar.gz to MMC card.

> 2. on kernel boot, first modules.tar.gz is unpacked
> 
> 3. distro brings up wlan but no USB ether
> 
> So I can now test also PM on pandaboard-es. I do have ohci
> enabled on droid4 though for mdm6600 modem, but usually have
> ehci disabled as the w3glte modem on ehci does not yet work
> with mainline kernel.
> 
> > Lee, could you then please make sure the patch gets to mainline before v4.19
> > final ?
> 
> Let's first check what all is needed, I'll test here too.

Yup with "[PATCH] mfd: omap-usb-host: Fix dts probe of children"
usb Ethernet works just fine for me with v4.19-rc3.

So it seems that then Lauren't changes can be done as nice
clean-up for v4.20.

Regards,

Tony

Re: [PATCH 1/3] mfd: omap-usb-host: Use regular platform device probe mechanism

[Tony Lindgren]

* Laurent Pinchart  [180911 15:10]:
> --- a/drivers/mfd/omap-usb-host.c
> +++ b/drivers/mfd/omap-usb-host.c
> @@ -855,31 +856,14 @@ static struct platform_driver usbhs_omap_driver = {
>   .pm = _dev_pm_ops,
>   .of_match_table = usbhs_omap_dt_ids,
>   },
> + .probe  = usbhs_omap_probe,
>   .remove = usbhs_omap_remove,
>  };

So I have this already along few other fixes in patch
"[PATCH] mfd: omap-usb-host: Fix dts probe of children".

> +module_platform_driver(usbhs_omap_driver);
> +
>  MODULE_AUTHOR("Keshava Munegowda ");
>  MODULE_AUTHOR("Roger Quadros ");
>  MODULE_ALIAS("platform:" USBHS_DRIVER_NAME);
>  MODULE_LICENSE("GPL v2");
>  MODULE_DESCRIPTION("usb host common core driver for omap EHCI and OHCI");
> -
> -static int __init omap_usbhs_drvinit(void)
> -{
> - return platform_driver_probe(_omap_driver, usbhs_omap_probe);
> -}
> -
> -/*
> - * init before ehci and ohci drivers;
> - * The usbhs core driver should be initialized much before
> - * the omap ehci and ohci probe functions are called.
> - * This usbhs core driver should be initialized after
> - * usb tll driver
> - */
> -fs_initcall_sync(omap_usbhs_drvinit);
> -
> -static void __exit omap_usbhs_drvexit(void)
> -{
> - platform_driver_unregister(_omap_driver);
> -}
> -module_exit(omap_usbhs_drvexit);

Seems like part can then become part of your clean-up
for v4.20 then?

Regards,

Tony

Re: [PATCH 0/3] Fix OMAP EHCI probe & assorted cleanups

[Tony Lindgren]

* Laurent Pinchart  [180911 15:10]:
> Hello,
> 
> This series fixes a v4.19-rc1 regression that results in OMAP EHCI failing to
> probe (patch 1/3) and then moves on to cleaning up related code (patches 2/3
> and 3/3).
> 
> The first patch is a regression fix and should thus be merged before v4.19.
> The other two patches can wait until v4.20.

Hmm can you please check again with this patch applied:

"[PATCH] mfd: omap-usb-host: Fix dts probe of children"

That was supposed to be queued for v4.18 but fell through the
cracks and I only recently noticed it but Lee has it tagged
now for v4.19-rc series.

But maybe there are additional issues..

> Tony, as patch 1/3 fixes a problem introduced by one of your DT changes, could
> you please review it ? Out of curiosity, is ethernet on the Pandaboard not
> part of your regression tests ?

Sorry not any longer.. I've switched over to wlan based
setup for PM testing:

1. u-boot downloads kernel dtb and modules.tar.gz and writes
   modules.tar.gz to MMC card

2. on kernel boot, first modules.tar.gz is unpacked

3. distro brings up wlan but no USB ether

So I can now test also PM on pandaboard-es. I do have ohci
enabled on droid4 though for mdm6600 modem, but usually have
ehci disabled as the w3glte modem on ehci does not yet work
with mainline kernel.

> Lee, could you then please make sure the patch gets to mainline before v4.19
> final ?

Let's first check what all is needed, I'll test here too.

Regards,

Tony

Re: [RFC 0/5] Migrate AM35xx MUSB glue to device tree and enable MUSB

[Tony Lindgren]

* Adam Ford  [180624 17:15]:
> 
> It currently doesnt' work, but I am looking for ideas on
> what I may have missed or done incorrectly.  

Check the drivers/phy/ti driver part and make sure that
works and has pins and clocks configured.

The rest should be pretty much generic stuff for musb
as long as the SoC glue layer can deal with the module,
clocks and pins.

Regards,

Tony
--
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 3/5] ARM: OMAP2+: Add AM3517 MUSB setup to pdata quirks.

[Tony Lindgren]

* Adam Ford  [180625 00:15]:
> The pin muxing and clock definitions for the MUSB controller are
> not done through the same registers/pin mux options, so this
> explicitly configures the registers and pin-mux options for MUSB
> on AM3517-EVM
> 
> Signed-off-by: Adam Ford 
> 
> diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
> b/arch/arm/mach-omap2/pdata-quirks.c
> index 7f02743edbe4..e0c7ac2c87c1 100644
> --- a/arch/arm/mach-omap2/pdata-quirks.c
> +++ b/arch/arm/mach-omap2/pdata-quirks.c
> @@ -258,9 +258,28 @@ static void __init omap3_sbc_t3517_legacy_init(void)
>   omap3_sbc_t3517_wifi_init();
>  }
>  
> +/* The pin muxing for AM3517 OTG isn't done through the normal means */
> +static __init void am3517_evm_musb_init(void)
> +{
> + u32 devconf2;
> +
> + /*
> +  * Set up USB clock/mode in the DEVCONF2 register.
> +  */
> + devconf2 = omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2);
> +
> + /* USB2.0 PHY reference clock is 13 MHz */
> + devconf2 &= ~(CONF2_REFFREQ | CONF2_OTGMODE | CONF2_PHY_GPIOMODE);
> + devconf2 |=  CONF2_REFFREQ_13MHZ | CONF2_SESENDEN | CONF2_VBDTCTEN
> + | CONF2_DATPOL;
> +
> + omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
> +}
> +
>  static void __init am3517_evm_legacy_init(void)
>  {
>   am35xx_emac_reset();
> + am3517_evm_musb_init();
>  }

To me it seems you should do this with a simple drivers/phy driver.
There might be already something similar that you can use, see the
da and dm related drivers under drivers/phy/ti.

Regards,

Tony
--
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: of-simple: fix use-after-free on remove

[Tony Lindgren]

Hi,

Adding Rafael and linux-pm to Cc as well.

* Felipe Balbi  [180619 01:23]:
> This is a direct consequence of not paying attention to the order of
> things. If driver were to assume that pm_domain->activate() would do the
> right thing for the device -- meaning that probe would run with an
> active device --, then we wouldn't need that pm_runtime_get() call on
> probe at all. Rather we would follow the sequence:
> 
>   pm_runtime_forbid()
>   pm_runtime_set_active()
>   pm_runtime_enable()
> 
>   /* do your probe routine */
> 
>   pm_runtime_put_noidle()
> 
> Then you remove you would need to call pm_runtime_get_noresume() to
> balance out the pm_runtime_put_noidle() there.

How about let's create some prettier interface for the above runtime PM
trickery?

How about something like pm_runtime_init_enabled() for the above
sequence?

It might be then able to do the trick even if activate is not
implemented..

Right now it has the feeling of "oh well we can't get runtime PM to
work so let's bypass it with activate call and then trick runtime PM
to start in enabled mode" :)

> Anyway, with an assumption like this, after all platform_devices are
> converted over, the assumption can be moved into the bus code and, low
> and behold, to enable runtime pm for your driver, all you have to is
> implement your callbacks and add pm_runtime_put_noidle() to probe and
> pm_runtime_get_noresume() to remove (apart from, of course, making sure
> the device isn't allowed to runtime_suspend when it's actually busy).
> 
> Do you see the end goal?

It certainly would be nice to make runtime PM generic for drivers :)

> (If you need to know why the pm_runtime_put_noidle(), remember that
> pm_runtime_set_active() increments the usage counter, so
> pm_runtime_put_noidle is basically allowing pm_runtime to happen as soon
> as userspace writes "auto" to /sys//power/control)

I wonder if we could also remove the need for drivers to call
pm_runtime_putnoidle() at the end of the probe? If we had
pm_runtime_init_enabled() implemented.

Regards,

Tony
--
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: of-simple: fix use-after-free on remove

[Tony Lindgren]

* Tero Kristo  [180619 12:13]:
> 
> TI SoC arm64 PM is done via genpd attached to each domain, which in turn
> passes control messages to the PM firmware when transitions happen. See
> drivers/soc/ti_sci_pm_domains.c for details.
> 
> Not quite sure about the discussion following later, but there is work
> ongoing to get rid of both omap_hwmod and omap_device, and replace this with
> a proper bus driver for OMAP architectures. It might solve the issues being
> talked about, or then not. Tony, any comments on that?

As long as drivers keep working we should add the callbacks suggested by
Felipe if that allows making drivers generic. Then changing the driver
probes can be done one driver at a time hopefully.

> Anyway, main reason that omap devices are actually suspended on HW level
> during probe is the aggressive power management applied on the device, and
> based on the documentation this is actually a valid thing to do. This makes
> sure that all devices get to idle if they are not used (no driver probed
> etc.), and will allow the SoC to idle core powerdomain.

What Felipe is suggesting is adding the callbacks that won't change the
runtime PM usecount. They just enable the device for probe, then bus code
can disable it again on failed probe. In the device driver probe things
in theory should work then both the old way and the PCI style way Felipe
wants. Needs to be tested of course :)

Regards,

Tony
--
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] phy: mapphone-mdm6600: Add runtime PM support for n_gsm on USB suspend

[Tony Lindgren]

We can suspend the mdm6600 over USB via sysfs and then mdm6600 enters
a low-power idle mode. In the low-power mode, mdm6600 radio and n_gsm
uart are functional but we need to use USB mode0 GPIO pin to send a
wake-up pulse to the modem to talk with it over n_gsm.

As the GPIO mode0 line is dual purposed and and also needed by the
USB PHY driver to boot mdm6600 into the correct USB mode, let's also
manage the wake-up GPIO in the USB PHY driver. For the USB PHY idle,
there does not anything specific we need to do for runtime PM after
getting the PHY configured. The PHY framework already idles the USB
PHY when not in use separately from the mdm6600 state.

It seems that it takes about 100 - 200ms for mdm6600 to wake up from
the low-power idle mode. And then mdm6600 stays awake about 1.2s until
it needs to be kicked again. The mdm6600 status GPIO pins don't seem
to change state when mdm6600 changes between normal and idle mode.

Let's manage the mdm6600 mode with runtime PM. If phy-mapphone-mdm6600
sysfs entry for power/control is set to "on", we keep mdm6600 out of
idle by kicking the GPIO line. If the entry is set to "auto" we let
mdm6600 enter low-power state.

Cc: Marcel Partap <mpar...@gmx.net>
Cc: Merlijn Wajer <merl...@wizzup.org>
Cc: Michael Scott <hashcod...@gmail.com>
Cc: NeKit <nekit1...@gmail.com>
Cc: Pavel Machek <pa...@ucw.cz>
Cc: Sebastian Reichel <s...@kernel.org>
Signed-off-by: Tony Lindgren <t...@atomide.com>
---
 drivers/phy/motorola/phy-mapphone-mdm6600.c | 85 +
 1 file changed, 85 insertions(+)

diff --git a/drivers/phy/motorola/phy-mapphone-mdm6600.c 
b/drivers/phy/motorola/phy-mapphone-mdm6600.c
--- a/drivers/phy/motorola/phy-mapphone-mdm6600.c
+++ b/drivers/phy/motorola/phy-mapphone-mdm6600.c
@@ -19,6 +19,8 @@
 
 #define PHY_MDM6600_PHY_DELAY_MS   4000/* PHY enable 2.2s to 3.5s */
 #define PHY_MDM6600_ENABLED_DELAY_MS   8000/* 8s more total for MDM6600 */
+#define MDM6600_MODEM_IDLE_DELAY_MS1000/* modem after USB suspend */
+#define MDM6600_MODEM_WAKE_DELAY_MS200 /* modem response after idle */
 
 enum phy_mdm6600_ctrl_lines {
PHY_MDM6600_ENABLE, /* USB PHY enable */
@@ -93,9 +95,11 @@ struct phy_mdm6600 {
struct gpio_descs *cmd_gpios;
struct delayed_work bootup_work;
struct delayed_work status_work;
+   struct delayed_work modem_wake_work;
struct completion ack;
bool enabled;   /* mdm6600 phy enabled */
bool running;   /* mdm6600 boot done */
+   bool awake; /* mdm6600 respnds on n_gsm */
int status;
 };
 
@@ -446,6 +450,62 @@ static void phy_mdm6600_deferred_power_on(struct 
work_struct *work)
dev_err(ddata->dev, "Device not functional\n");
 }
 
+/*
+ * USB suspend puts mdm6600 into low power mode. For any n_gsm using apps,
+ * we need to keep the modem awake by kicking it's mode0 GPIO. This will
+ * keep the modem awake for about 1.2 seconds. When no n_gsm apps are using
+ * the modem, runtime PM auto mode can be enabled so modem can enter low
+ * power mode.
+ */
+static void phy_mdm6600_wake_modem(struct phy_mdm6600 *ddata)
+{
+   struct gpio_desc *mode_gpio0;
+
+   mode_gpio0 = ddata->mode_gpios->desc[PHY_MDM6600_MODE0];
+   gpiod_set_value_cansleep(mode_gpio0, 1);
+   usleep_range(5, 15);
+   gpiod_set_value_cansleep(mode_gpio0, 0);
+   if (ddata->awake)
+   usleep_range(5, 15);
+   else
+   msleep(MDM6600_MODEM_WAKE_DELAY_MS);
+}
+
+static void phy_mdm6600_modem_wake(struct work_struct *work)
+{
+   struct phy_mdm6600 *ddata;
+
+   ddata = container_of(work, struct phy_mdm6600, modem_wake_work.work);
+   phy_mdm6600_wake_modem(ddata);
+   schedule_delayed_work(>modem_wake_work,
+ msecs_to_jiffies(MDM6600_MODEM_IDLE_DELAY_MS));
+}
+
+static int __maybe_unused phy_mdm6600_runtime_suspend(struct device *dev)
+{
+   struct phy_mdm6600 *ddata = dev_get_drvdata(dev);
+
+   cancel_delayed_work_sync(>modem_wake_work);
+   ddata->awake = false;
+
+   return 0;
+}
+
+static int __maybe_unused phy_mdm6600_runtime_resume(struct device *dev)
+{
+   struct phy_mdm6600 *ddata = dev_get_drvdata(dev);
+
+   phy_mdm6600_modem_wake(>modem_wake_work.work);
+   ddata->awake = true;
+
+   return 0;
+}
+
+static const struct dev_pm_ops phy_mdm6600_pm_ops = {
+   SET_RUNTIME_PM_OPS(phy_mdm6600_runtime_suspend,
+  phy_mdm6600_runtime_resume, NULL)
+};
+
 static const struct of_device_id phy_mdm6600_id_table[] = {
{ .compatible = "motorola,mapphone-mdm6600", },
{},
@@ -464,6 +524,7 @@ static int phy_mdm6600_probe(struct platform_device *pdev)
INIT_DELAYED_WORK(>bootup_work,

Re: [PATCHv4] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Tony Lindgren]

* Dan Williams <d...@redhat.com> [180326 15:18]:
> On Sun, 2018-03-25 at 13:52 -0700, Tony Lindgren wrote:
> > Anyways, looks like qmi_wwan needs to be loaded before
> > qcserial module, otherwise we get nine ttyUSB instances
> > and ModemManager can't find any modems.
> 
> Use qcaux.c or option, unless the 6600 actually *does* have the same
> layout as Gobi 1K/2K/etc devices.

OK yeah I don't think it's Gobi.

> If you're going to use qcaux or optoin, then you need to use some
> variant of USB_DEVICE_AND_INTERFACE_INFO to lock the serial driver to
> the specific USB interfaces that expose the TTYs and to ignore the QMI
> interfaces and netdevs.

OK thanks I'll take a look and post a patch after some testing.

Regards,

Tony
--
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: [PATCHv4] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Tony Lindgren]

* Tony Lindgren <t...@atomide.com> [180326 00:24]:
> Looks like on /dev/ttyUSB4 doing AT+COPS? or AT+CREG? won't work
> while on /dev/gsmtty1 they work. So /dev/ttyUSB4 seems to a subset of
> what's available over n_gsm on ch1. Anyways, good to hear that
> /dev/ttyUSB4 can be used to debug voice calls :)

Hmm and now they work on /dev/ttyUSB4. Maybe I had SIM card
poorly connected..

Tony
--
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: [PATCHv4] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Tony Lindgren]

* Pavel Machek  [180325 22:57]:
> Hi!
> 
> > > > > Hmm. Interesting. Anyway, for me ttyUSB4 is interesting, as it seems
> > > > > to react to AT commands, and in particular reacts to ADT123; (; is
> > > > > important).
> > > > 
> > > > Is that to dial a voice call?
> > > 
> > > Yes. And it is ATD123; not ATD.
> > 
> > Strange, no semicolon is needed when using /dev/gsmtty to
> > dial a voice call with my current pile of pending changes,
> > just doing ATD123 dials..
> 
> Interesting. Maybe I made some mistake in experiment.

Looks like on /dev/ttyUSB4 doing AT+COPS? or AT+CREG? won't work
while on /dev/gsmtty1 they work. So /dev/ttyUSB4 seems to a subset of
what's available over n_gsm on ch1. Anyways, good to hear that
/dev/ttyUSB4 can be used to debug voice calls :)

> Thanks for hints, it would not be bad to get gps working. But .. voice
> calls. Those are important :-).

Yup, please keep us posted :) Meanwhile, I'll slowly continue
getting the n_gsm stuff working.

Tony
--
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: [PATCHv4] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Tony Lindgren]

* Pavel Machek  [180325 19:00]:
> Hi!
> 
> > > Hmm. Interesting. Anyway, for me ttyUSB4 is interesting, as it seems
> > > to react to AT commands, and in particular reacts to ADT123; (; is
> > > important).
> > 
> > Is that to dial a voice call?
> 
> Yes. And it is ATD123; not ATD.

Strange, no semicolon is needed when using /dev/gsmtty to
dial a voice call with my current pile of pending changes,
just doing ATD123 dials..

Anyways, looks like qmi_wwan needs to be loaded before
qcserial module, otherwise we get nine ttyUSB instances
and ModemManager can't find any modems.

With qcserial module loaded after qmi_wwan, it still takes
a long time for ModemManager to find the modem.

Then unrelated to the qcserial module, also looks like I can
no longer use the GPS with ModemManager:

$ mmcli -m 0 --enable
$ mmcli -m 0 --location-enable-gps-raw

And then chmod a+r /dev/cdc-wdm0 and pointing gpsd to use
/dev/cdc-wdm0 used to work, but now it seems that gpsd
can no longer read it. Trying to start gpsd manually produces:

# gpsd -b -n -N /dev/cdc-wdm0
gpsd:ERROR: SER: /dev/cdc-wdm0 already opened by another process
gpsd:ERROR: initial GPS device /dev/cdc-wdm0 open failed
gpsd:ERROR: can't run with neither control socket nor devices open

And lsof shows /usr/libexec/qmi-proxy having it open.

Anybody know what I might be doing wrong? Sounds like something
now needs to be done with qmi-proxy to get access to GPS?

> > Anyway, "good" solution is to get ofonod running, then use ofone from
> > here: https://github.com/pavelmachek/unicsy_demo

Thanks I'll take a look.

> > I think it's the cpcap based config to route voice call audio
> > to SoC, Sebastian knows the details :)
> > 
> > The way to figure that one out is to dump the cpcap registers
> > before and during voice call on android with cpcaprw, then
> > diff the output for the audio registers. Probably some SoC
> > registers need to be diffed too with rwmem or similar tool
> > for the mcbsp instance(s) used.
> 
> That sounds like hard way to do it. There's source available, I'm now
> trying to understand it / fit it into Sebastian's driver.
> 
> https://raw.githubusercontent.com/NotKit/android_kernel_motorola_omap4-common/hybris-11.0/sound/soc/codecs/cpcap.c

Sure that hopefully helps too :)

Tony
--
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: [PATCHv4] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Tony Lindgren]

* Pavel Machek <pa...@ucw.cz> [180324 20:03]:
> On Sat 2018-03-24 07:25:17, Tony Lindgren wrote:
> > * Dan Williams <d...@redhat.com> [180324 14:00]:
> > > On Fri, 2018-03-23 at 21:13 +0100, Pavel Machek wrote:
> > > > Does ofonod work for you? I could not get that one to work...
> > > 
> > > Because it's looking for a Gobi modem but the MDM6600 isn't one and
> > > doesn't expose that layout (and doesn't really need to anyway).  I
> > > don't think ofono has a generic QMI driver, so you'd either need to for
> > > ce it to use the telitqmi or quectelqmi drivers, or write your own
> > > generic QMI one.
> > 
> > We also get five USB uarts if we add the device id with something
> > like the patch below. I don't quite get why we get five UARTS?
> 
> Not sure, either. Often more than one uart is useful, you get AT
> commands on one, while GPRS data flow on some other. 
> 
> > Also not sure if we should be using drivers/usb/serial/qcaux.c
> > instead of qcserial.c?
> > 
> > And from what I recall trying it out, adding the USB UARTs
> > somehow confused ModemManager I think, that needs to be retested
> > though :)
> > 
> > And the USB UARTs added do not offer the same set of AT commands
> > as the n_gsm serial mux.
> 
> Hmm. Interesting. Anyway, for me ttyUSB4 is interesting, as it seems
> to react to AT commands, and in particular reacts to ADT123; (; is
> important).

Is that to dial a voice call?

> AT+CMGF=1
> AT+CMGS="123"
> foo^Z
> 
> Works for SMS sending. Good.

So what do you use for reading notifying and reading sms?

> Now, if someone knows what needs to be done to get GSM audio working,
> let me know. That's something I'd really like.

I think it's the cpcap based config to route voice call audio
to SoC, Sebastian knows the details :)

The way to figure that one out is to dump the cpcap registers
before and during voice call on android with cpcaprw, then
diff the output for the audio registers. Probably some SoC
registers need to be diffed too with rwmem or similar tool
for the mcbsp instance(s) used.

Regards,

Tony

--
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: [PATCHv4] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Tony Lindgren]

* Dan Williams  [180324 14:00]:
> On Fri, 2018-03-23 at 21:13 +0100, Pavel Machek wrote:
> > Does ofonod work for you? I could not get that one to work...
> 
> Because it's looking for a Gobi modem but the MDM6600 isn't one and
> doesn't expose that layout (and doesn't really need to anyway).  I
> don't think ofono has a generic QMI driver, so you'd either need to for
> ce it to use the telitqmi or quectelqmi drivers, or write your own
> generic QMI one.

We also get five USB uarts if we add the device id with something
like the patch below. I don't quite get why we get five UARTS?

Also not sure if we should be using drivers/usb/serial/qcaux.c
instead of qcserial.c?

And from what I recall trying it out, adding the USB UARTs
somehow confused ModemManager I think, that needs to be retested
though :)

And the USB UARTs added do not offer the same set of AT commands
as the n_gsm serial mux.

Regards,

Tony

8< --
diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -181,6 +181,9 @@ static const struct usb_device_id id_table[] = {
/* Huawei devices */
{DEVICE_HWI(0x03f0, 0x581d)},   /* HP lt4112 LTE/HSPA+ Gobi 4G Modem 
(Huawei me906e) */
 
+   /* Motorola devices */
+   {DEVICE_HWI(0x22b8, 0x2a70)},   /* Droid 4 mdm6600 */
+
{ } /* Terminating entry */
 };
 MODULE_DEVICE_TABLE(usb, id_table);
-- 
2.16.2
--
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: [PATCHv4] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Tony Lindgren]

* Pavel Machek  [180322 13:57]:
> Hi!
> 
> > idle lcd offphy-mapphone-mdm6600ohci-platform
> > 153mW   284mW   344mW
> > 
> > So it seems that MDM6600 is currently not yet idling even with it's
> > radio turned off, but that's something that is beyond the control of
> > this USB PHY driver. This patch does get us to the point where modem
> > data and GPS are usable with libqmi and ModemManager for example.
> > Voice calls need more audio driver work.
> 
> Ok, let me try. I believe I should see the modem device on lsusb, but
> I don't.
> 
> user@devuan:/sys/devices/platform/4400.ocp/4a064000.usbhshost$
> sudo lsusb
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> user@devuan:/sys/devices/platform/4400.ocp/4a064000.usbhshost$
> zcat /proc/config.gz | grep MAPPH
> CONFIG_PHY_MAPPHONE_MDM6600=y
> user@devuan:/sys/devices/platform/4400.ocp/4a064000.usbhshost$
> zcat /proc/config.gz | grep OHCI_
> CONFIG_USB_OHCI_LITTLE_ENDIAN=y
> CONFIG_USB_OHCI_HCD=y
> CONFIG_USB_OHCI_HCD_OMAP3=y
> CONFIG_USB_OHCI_HCD_PLATFORM=y
> user@devuan:/sys/devices/platform/4400.ocp/4a064000.usbhshost$
> 
> As far as I can tell,
> 
> +CONFIG_USB_WDM=y
> +CONFIG_USB_SERIAL=y
> +CONFIG_USB_SERIAL_QUALCOMM=y
> +CONFIG_USB_SERIAL_WWAN=y
> 
> should be enabled to enable the drivers (and I did that), but without
> device showing on the bus...
> 
> Any ideas?

Do you have the related dts patches picked from next?

fdd192037fce ("ARM: dts: omap4-droid4: Fix USB PHY port naming")
e5b9fd7bdeb5 ("ARM: dts: omap4-droid4: Configure MDM6600 USB PHY")

But yeah all you need to do is have phy-mapphone-mdm6600 and
ohci-platform loaded and then ifconfig should show four wwan
interfaces being added.

Regards,

Tony



signature.asc
Description: PGP signature

Re: [PATCHv4] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Tony Lindgren]

* Pavel Machek  [180309 09:45]:
> Hi!
> 
> > Let's add support for the GPIO controlled USB PHY on the MDM6600 modem.
> > It is used on some Motorola Mapphone series of phones and tablets such
> > as Droid 4.
> ...
> > So it seems that MDM6600 is currently not yet idling even with it's
> > radio turned off, but that's something that is beyond the control of
> > this USB PHY driver. This patch does get us to the point where modem
> > data and GPS are usable with libqmi and ModemManager for example.
> > Voice calls need more audio driver work.
> 
> Thanks for the good work. Looks like I'll need to get droid
> 4... fortunately it is not available in czech republic so I don't get
> excuse to get another toy.
> 
> Oh.. no. It is available in Czech republic. Is Motorola Droid 4 XT894
> the right one? Hmm, and LTE modem is useless in Europe, while the GSM
> one does not work, right?

Yup xt894 is the model number for droid 4.

Regards,

Tony


--
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

[PATCHv4] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Tony Lindgren]

Let's add support for the GPIO controlled USB PHY on the MDM6600 modem.
It is used on some Motorola Mapphone series of phones and tablets such
as Droid 4.

The MDM6600 is hardwired to the first OHCI port in the Droid 4 case, and
is controlled by several GPIOs. The USB PHY is integrated into the MDM6600
device it seems. We know this as we get L3 errors from omap-usb-host if
trying to use the PHY before MDM6600 is configured.

The GPIOs controlling MDM6600 are used to power device on and off, to
configure the USB start-up mode (normal mode versus USB flashing), and
they also tell the state of the MDM6600 device.

The two start-up mode GPIOs are dual-purposed and used for out of band
(OOB) wake-up for USB and TS 27.010 serial mux. But we need to configure
the USB start-up mode first to get MDM6600 booted in the right mode to
be usable in the first place.

Note that the Motorola Mapphone Linux kernel tree has a "radio-ctrl"
driver for modems. But it really does not control the radio at all, it
just controls the modem power and start-up mode for USB. So I came to
the conclusion that we're better off having this done in the USB PHY
driver. For adding support for USB flashing mode, we can later on add
a kernel module option for flash_mode=1 or something similar.

Also note that currently there is no PM runtime support for the OHCI
on omap variant SoCs. So for low(er) power idle states, currenty both
ohci-platform and phy-mapphone-mdm6600 must be unloaded or unbound.

For reference here is what I measured for total power consumption on
an idle Droid 4 with and without USB related MDM6600 modules:

idle lcd offphy-mapphone-mdm6600ohci-platform
153mW   284mW   344mW

So it seems that MDM6600 is currently not yet idling even with it's
radio turned off, but that's something that is beyond the control of
this USB PHY driver. This patch does get us to the point where modem
data and GPS are usable with libqmi and ModemManager for example.
Voice calls need more audio driver work.

Cc: devicet...@vger.kernel.org
Cc: Mark Rutland <mark.rutl...@arm.com>
Cc: Marcel Partap <mpar...@gmx.net>
Cc: Michael Scott <michael.sc...@linaro.org>
Cc: Rob Herring <robh...@kernel.org>
Reviewed-by: Rob Herring <r...@kernel.org>
Signed-off-by: Tony Lindgren <t...@atomide.com>
---

Changes since v3:
- Dropped unneeded usb_phy related parts as suggested by Kishon

Changes since v2:
- Dropped OTG as suggested by Kishon
- Added Rob's Reviewed-by

Changes since v1:
- Fixed up issues noticed by Rob and Sebastian
- Implemented wake irq handler (for debug use only for now)
- Improved error handling based on more testing

---
 .../bindings/phy/phy-mapphone-mdm6600.txt  |  30 ++
 drivers/phy/motorola/Kconfig   |   8 +
 drivers/phy/motorola/Makefile  |   1 +
 drivers/phy/motorola/phy-mapphone-mdm6600.c| 542 +
 4 files changed, 581 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
 create mode 100644 drivers/phy/motorola/phy-mapphone-mdm6600.c

diff --git a/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt 
b/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
@@ -0,0 +1,30 @@
+Device tree binding documentation for Motorola Mapphone MDM6600 USB PHY
+
+Required properties:
+- compatible   Must be "motorola,mapphone-mdm6600"
+- enable-gpios GPIO to enable the USB PHY
+- power-gpios  GPIO to power on the device
+- reset-gpios  GPIO to reset the device
+- motorola,mode-gpios  Two GPIOs to configure MDM6600 USB start-up mode for
+   normal mode versus USB flashing mode
+- motorola,cmd-gpios   Three GPIOs to control the power state of the MDM6600
+- motorola,status-gpiosThree GPIOs to read the power state of the 
MDM6600
+
+Example:
+
+usb-phy {
+   compatible = "motorola,mapphone-mdm6600";
+   enable-gpios = < 31 GPIO_ACTIVE_LOW>;
+   power-gpios = < 22 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 17 GPIO_ACTIVE_HIGH>;
+   motorola,mode-gpios = < 20 GPIO_ACTIVE_HIGH>,
+ < 21 GPIO_ACTIVE_HIGH>;
+   motorola,cmd-gpios = < 7 GPIO_ACTIVE_HIGH>,
+< 8 GPIO_ACTIVE_HIGH>,
+< 14 GPIO_ACTIVE_HIGH>;
+   motorola,status-gpios = < 20 GPIO_ACTIVE_HIGH>,
+   < 21 GPIO_ACTIVE_HIGH>,
+   < 23 GPIO_ACTIVE_HIGH>;
+   #phy-cells = <0>;
+};
+
diff --git a/drivers/phy/motorola/Kconfig b/drivers/phy/motorola/Kconfig
--- a/drivers/phy/motorola/Kconfig
+++ b/drivers/phy/motorola/Kconfig
@@ -10,3 +10,11 @@ config PHY_CPCAP_USB
help
 

Re: [PATCHv3] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Tony Lindgren]

* Kishon Vijay Abraham I <kis...@ti.com> [180308 08:23]:
> On Wednesday 07 March 2018 08:26 PM, Tony Lindgren wrote:
> > +config PHY_MAPPHONE_MDM6600
> > +   tristate "Motorola Mapphone MDM6600 modem USB PHY driver"
> > +   depends on OF && USB_SUPPORT
> > +   select GENERIC_PHY
> > +   select USB_PHY
> 
> given that OTG is removed, USB_PHY won't be required anymore. Sorry for not
> stating this explicitly before.

Oh OK I did not know that.

> > +   ddata->dev = >dev;
> > +   ddata->phy.dev = ddata->dev;
> > +   ddata->phy.label = "phy_mdm6600";
> > +   ddata->phy.type = USB_PHY_TYPE_USB2;
> 
> All of this can be removed since usb_phy is not required.

> > +   usb_add_phy_dev(>phy);
> 
> This should also be removed.

OK cool, will remove and post v4 hopefully tonight at some
point.

Regards,

Tony
--
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

[PATCHv3] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Tony Lindgren]

Let's add support for the GPIO controlled USB PHY on the MDM6600 modem.
It is used on some Motorola Mapphone series of phones and tablets such
as Droid 4.

The MDM6600 is hardwired to the first OHCI port in the Droid 4 case, and
is controlled by several GPIOs. The USB PHY is integrated into the MDM6600
device it seems. We know this as we get L3 errors from omap-usb-host if
trying to use the PHY before MDM6600 is configured.

The GPIOs controlling MDM6600 are used to power device on and off, to
configure the USB start-up mode (normal mode versus USB flashing), and
they also tell the state of the MDM6600 device.

The two start-up mode GPIOs are dual-purposed and used for out of band
(OOB) wake-up for USB and TS 27.010 serial mux. But we need to configure
the USB start-up mode first to get MDM6600 booted in the right mode to
be usable in the first place.

Note that the Motorola Mapphone Linux kernel tree has a "radio-ctrl"
driver for modems. But it really does not control the radio at all, it
just controls the modem power and start-up mode for USB. So I came to
the conclusion that we're better off having this done in the USB PHY
driver. For adding support for USB flashing mode, we can later on add
a kernel module option for flash_mode=1 or something similar.

Also note that currently there is no PM runtime support for the OHCI
on omap variant SoCs. So for low(er) power idle states, currenty both
ohci-platform and phy-mapphone-mdm6600 must be unloaded or unbound.

For reference here is what I measured for total power consumption on
an idle Droid 4 with and without USB related MDM6600 modules:

idle lcd offphy-mapphone-mdm6600ohci-platform
153mW   284mW   344mW

So it seems that MDM6600 is currently not yet idling even with it's
radio turned off, but that's something that is beyond the control of
this USB PHY driver. This patch does get us to the point where modem
data and GPS are usable with libqmi and ModemManager for example.
Voice calls need more audio driver work.

Cc: devicet...@vger.kernel.org
Cc: Mark Rutland <mark.rutl...@arm.com>
Cc: Marcel Partap <mpar...@gmx.net>
Cc: Michael Scott <michael.sc...@linaro.org>
Cc: Rob Herring <robh...@kernel.org>
Reviewed-by: Rob Herring <r...@kernel.org>
Signed-off-by: Tony Lindgren <t...@atomide.com>
---

Changes since v2:
- Dropped OTG as suggested by Kishon
- Added Rob's Reviewed-by

Changes since v1:
- Fixed up issues noticed by Rob and Sebastian
- Implemented wake irq handler (for debug use only for now)
- Improved error handling based on more testing

---
 .../bindings/phy/phy-mapphone-mdm6600.txt  |  30 ++
 drivers/phy/motorola/Kconfig   |   9 +
 drivers/phy/motorola/Makefile  |   1 +
 drivers/phy/motorola/phy-mapphone-mdm6600.c| 549 +
 4 files changed, 589 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
 create mode 100644 drivers/phy/motorola/phy-mapphone-mdm6600.c

diff --git a/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt 
b/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
@@ -0,0 +1,30 @@
+Device tree binding documentation for Motorola Mapphone MDM6600 USB PHY
+
+Required properties:
+- compatible   Must be "motorola,mapphone-mdm6600"
+- enable-gpios GPIO to enable the USB PHY
+- power-gpios  GPIO to power on the device
+- reset-gpios  GPIO to reset the device
+- motorola,mode-gpios  Two GPIOs to configure MDM6600 USB start-up mode for
+   normal mode versus USB flashing mode
+- motorola,cmd-gpios   Three GPIOs to control the power state of the MDM6600
+- motorola,status-gpiosThree GPIOs to read the power state of the 
MDM6600
+
+Example:
+
+usb-phy {
+   compatible = "motorola,mapphone-mdm6600";
+   enable-gpios = < 31 GPIO_ACTIVE_LOW>;
+   power-gpios = < 22 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 17 GPIO_ACTIVE_HIGH>;
+   motorola,mode-gpios = < 20 GPIO_ACTIVE_HIGH>,
+ < 21 GPIO_ACTIVE_HIGH>;
+   motorola,cmd-gpios = < 7 GPIO_ACTIVE_HIGH>,
+< 8 GPIO_ACTIVE_HIGH>,
+< 14 GPIO_ACTIVE_HIGH>;
+   motorola,status-gpios = < 20 GPIO_ACTIVE_HIGH>,
+   < 21 GPIO_ACTIVE_HIGH>,
+   < 23 GPIO_ACTIVE_HIGH>;
+   #phy-cells = <0>;
+};
+
diff --git a/drivers/phy/motorola/Kconfig b/drivers/phy/motorola/Kconfig
--- a/drivers/phy/motorola/Kconfig
+++ b/drivers/phy/motorola/Kconfig
@@ -10,3 +10,12 @@ config PHY_CPCAP_USB
help
  Enable this for USB to work on Motorola phones and tablets
  such as Droi

Re: [PATCHv2] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Tony Lindgren]

* Kishon Vijay Abraham I <kis...@ti.com> [180302 08:04]:
> Hi Tony,
> 
> On Thursday 01 March 2018 09:20 AM, Tony Lindgren wrote:
> > Let's add support for the GPIO controlled USB PHY on the MDM6600 modem.
> > It is used on some Motorola Mapphone series of phones and tablets such
> > as Droid 4.
> 
> Generally PHY configuration is done for the PHYs that is connected to the USB
> controllers in the SoC. In that sense it differs from the usual case by
> programming the PHY in the device.

Yup in this case it's the MDM6600 that provides the PHY for the SoC :)

> > The MDM6600 is hardwired to the first OHCI port in the Droid 4 case, and
> > is controlled by several GPIOs. The USB PHY is integrated into the MDM6600
> > device it seems. We know this as we get L3 errors from omap-usb-host if
> > trying to use the PHY before MDM6600 is configured.
> 
> Do you know what phy is connected to the OHCI port. Previously we've seen for
> having USB devices on the board itself, phy less configurations was used.

We have MDM6600 on *HCI port 1 providing "ohci-phy-4pin-dpdm"
PHY for the SoC, so not TLL. Then there's another modem W3GLTE on
port 2 that is using "ehci-tll".

> > --- /dev/null
> > +++ b/drivers/phy/motorola/phy-mapphone-mdm6600.c
> .
> .
> 
> .
> .
> > +
> > +static int phy_mdm6600_probe(struct platform_device *pdev)
> > +{
> > +   struct phy_mdm6600 *ddata;
> > +   struct usb_otg *otg;
> 
> Since it is connected to a OHCI, not sure if we really need to add usb_otg 
> here.

OK yeah that's copy paste leftover from my earlier PHY driver I used
to start with. Will drop thanks.

Regards,

Tony
--
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

[PATCHv2] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Tony Lindgren]

Let's add support for the GPIO controlled USB PHY on the MDM6600 modem.
It is used on some Motorola Mapphone series of phones and tablets such
as Droid 4.

The MDM6600 is hardwired to the first OHCI port in the Droid 4 case, and
is controlled by several GPIOs. The USB PHY is integrated into the MDM6600
device it seems. We know this as we get L3 errors from omap-usb-host if
trying to use the PHY before MDM6600 is configured.

The GPIOs controlling MDM6600 are used to power device on and off, to
configure the USB start-up mode (normal mode versus USB flashing), and
they also tell the state of the MDM6600 device.

The two start-up mode GPIOs are dual-purposed and used for out of band
(OOB) wake-up for USB and TS 27.010 serial mux. But we need to configure
the USB start-up mode first to get MDM6600 booted in the right mode to
be usable in the first place.

Note that the Motorola Mapphone Linux kernel tree has a "radio-ctrl"
driver for modems. But it really does not control the radio at all, it
just controls the modem power and start-up mode for USB. So I came to
the conclusion that we're better off having this done in the USB PHY
driver. For adding support for USB flashing mode, we can later on add
a kernel module option for flash_mode=1 or something similar.

Also note that currently there is no PM runtime support for the OHCI
on omap variant SoCs. So for low(er) power idle states, currenty both
ohci-platform and phy-mapphone-mdm6600 must be unloaded or unbound.

For reference here is what I measured for total power consumption on
an idle Droid 4 with and without USB related MDM6600 modules:

idle lcd offphy-mapphone-mdm6600ohci-platform
153mW   284mW   344mW

So it seems that MDM6600 is currently not yet idling even with it's
radio turned off, but that's something that is beyond the control of
this USB PHY driver. This patch does get us to the point where modem
data and GPS are usable with libqmi and ModemManager for example.
Voice calls need more audio driver work.

Cc: devicet...@vger.kernel.org
Cc: Mark Rutland <mark.rutl...@arm.com>
Cc: Marcel Partap <mpar...@gmx.net>
Cc: Michael Scott <michael.sc...@linaro.org>
Cc: Rob Herring <robh...@kernel.org>
Cc: Sebastian Reichel <s...@kernel.org>
Signed-off-by: Tony Lindgren <t...@atomide.com>
---

Changes since v1:
- Fixed up issues noticed by Rob and Sebastian
- Implemented wake irq handler (for debug use only for now)
- Improved error handling based on more testing

---
 .../bindings/phy/phy-mapphone-mdm6600.txt  |  30 ++
 drivers/phy/motorola/Kconfig   |   9 +
 drivers/phy/motorola/Makefile  |   1 +
 drivers/phy/motorola/phy-mapphone-mdm6600.c| 556 +
 4 files changed, 596 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
 create mode 100644 drivers/phy/motorola/phy-mapphone-mdm6600.c

diff --git a/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt 
b/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
@@ -0,0 +1,30 @@
+Device tree binding documentation for Motorola Mapphone MDM6600 USB PHY
+
+Required properties:
+- compatible   Must be "motorola,mapphone-mdm6600"
+- enable-gpios GPIO to enable the USB PHY
+- power-gpios  GPIO to power on the device
+- reset-gpios  GPIO to reset the device
+- motorola,mode-gpios  Two GPIOs to configure MDM6600 USB start-up mode for
+   normal mode versus USB flashing mode
+- motorola,cmd-gpios   Three GPIOs to control the power state of the MDM6600
+- motorola,status-gpiosThree GPIOs to read the power state of the 
MDM6600
+
+Example:
+
+usb-phy {
+   compatible = "motorola,mapphone-mdm6600";
+   enable-gpios = < 31 GPIO_ACTIVE_LOW>;
+   power-gpios = < 22 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 17 GPIO_ACTIVE_HIGH>;
+   motorola,mode-gpios = < 20 GPIO_ACTIVE_HIGH>,
+ < 21 GPIO_ACTIVE_HIGH>;
+   motorola,cmd-gpios = < 7 GPIO_ACTIVE_HIGH>,
+< 8 GPIO_ACTIVE_HIGH>,
+< 14 GPIO_ACTIVE_HIGH>;
+   motorola,status-gpios = < 20 GPIO_ACTIVE_HIGH>,
+   < 21 GPIO_ACTIVE_HIGH>,
+   < 23 GPIO_ACTIVE_HIGH>;
+   #phy-cells = <0>;
+};
+
diff --git a/drivers/phy/motorola/Kconfig b/drivers/phy/motorola/Kconfig
--- a/drivers/phy/motorola/Kconfig
+++ b/drivers/phy/motorola/Kconfig
@@ -10,3 +10,12 @@ config PHY_CPCAP_USB
help
  Enable this for USB to work on Motorola phones and tablets
  such as Droid 4.
+
+config PHY_MAPPHONE_MDM6600
+   tristate "Motorola Mapphone MDM

Re: [PATCH] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Tony Lindgren]

* kbuild test robot  [180219 07:47]:
>  > 354if (reset_gpio >= 0)
>355gpiod_set_value_cansleep(reset_gpio, 1);

Thanks this test can be just dropped. Will send out an updated
version shortly.

Regards,

Tony
--
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] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Tony Lindgren]

* Rob Herring <r...@kernel.org> [180219 20:41]:
> On Sat, Feb 17, 2018 at 01:07:23PM -0800, Tony Lindgren wrote:
> > The GPIOs controlling MDM6600 are used to power MDM660 on and off, to
> 
> MDM660 a typo?

Thanks fixing.

> > +Required properties:
> > +- compatible   Must be "motorola,mapphone-mdm6600"
> > +- enable-gpios GPIO to enable the USB PHY
> > +- power-gpios  GPIO to power on the device
> > +- reset-gpios  GPIO to reset the device
> 
> The are pretty standard, but...
> 
> > +- mode-gpios   Two GPIOs to configure MDM6600 USB start-up mode for
> > +   normal mode versus USB flashing mode
> > +- status-gpios Three GPIOs to read the power state of the MDM6600
> > +- cmd-gpiosThree GPIOs to control the power state of the MDM6600
> 
> These 3 should have vendor a prefix.

OK

> > +
> > +Example:
> > +
> > +fsusb1_phy: fsusb1_phy {
> 
> usb-phy {

Thanks will send out an updated version shortly.

Regards,

Tony
--
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/1] usb: musb: call pm_runtime_{get,put}_sync before reading vbus registers

[Tony Lindgren]

* Merlijn Wajer <merl...@wizzup.org> [180227 22:29]:
> Without pm_runtime_{get,put}_sync calls in place, reading
> vbus status via /sys causes the following error:
> 
> Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa0ab060
> pgd = b333e822
> [fa0ab060] *pgd=48011452(bad)
> 
> [] (musb_default_readb) from [] (musb_vbus_show+0x58/0xe4)
> [] (musb_vbus_show) from [] (dev_attr_show+0x20/0x44)
> [] (dev_attr_show) from [] (sysfs_kf_seq_show+0x80/0xdc)
> [] (sysfs_kf_seq_show) from [] (seq_read+0x250/0x448)
> [] (seq_read) from [] (__vfs_read+0x1c/0x118)
> [] (__vfs_read) from [] (vfs_read+0x90/0x144)
> [] (vfs_read) from [] (SyS_read+0x3c/0x74)
> [] (SyS_read) from [] (ret_fast_syscall+0x0/0x54)
> 
> Solution was suggested by Tony Lindgren <t...@atomide.com>.
> 
> Signed-off-by: Merlijn Wajer <merl...@wizzup.org>

Thanks for fixing this. Assuming it passes Bin's tests:

Acked-by: Tony Lindgren <t...@atomide.com>
--
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] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Tony Lindgren]

* Sebastian Reichel <s...@kernel.org> [180218 00:32]:
> On Sat, Feb 17, 2018 at 01:07:23PM -0800, Tony Lindgren wrote:
> > For reference here is what I measured for total power consumption on
> > an idle Droid 4 with and without USB related MDM6600 modules:
> > 
> > idle lcd offphy-mapphone-mdm6600ohci-platform
> > 153mW   284mW   344mW
> 
> So more than twice the idle power... We really want to get runtime
> PM working :/

Yes and we want' modem to idle too :)

> > +/*
> > + * MDM6600 status codes. These are copied from Motorola Mapphone Linux
> > + * kernel tree. The BB naming here refers to "BaseBand" for modem.
> > + */
> 
> Actually your status codes are BP_ (baseband processor) prefixed.

I'll just get rid of the naming and stick to MDM6600 prefixies.
No need to keep the confusing BP/AP prefixes.

> > +static void phy_mdm6600_init_irq(struct phy_mdm6600 *ddata)
> > +{
> > +   struct device *dev = ddata->dev;
> > +   int i, error, irq;
> > +
> > +   for (i = PHY_MDM6600_STATUS0;
> > +i <= PHY_MDM6600_STATUS2; i++) {
> > +   if (IS_ERR(ddata->gpio[i]))
> > +   continue;
> 
> This can be dropped, since the driver errors out of probe
> when there are gpio errors.

True will drop.

> > +static int phy_mdm6600_init_lines(struct phy_mdm6600 *ddata)
> > +{
> > +   struct device *dev = ddata->dev;
> > +   int i, j, nr_gpio = 0;
> > +
> > +   for (i = 0; i < ARRAY_SIZE(phy_mdm6600_line_map); i++) {
> > +   const struct phy_mdm6600_map *map =
> > +   _mdm6600_line_map[i];
> > +
> > +   for (j = 0; j < map->nr_gpios; j++) {
> > +   struct gpio_desc **gpio = >gpio[nr_gpio];
> > +
> > +   *gpio = devm_gpiod_get_index(dev,
> > +map->name, j,
> > +map->direction);
> > +   if (IS_ERR(*gpio)) {
> > +   dev_info(dev,
> > +"gpio %s error %li, already taken?\n",
> > +map->name, PTR_ERR(*gpio));
> > +   return PTR_ERR(*gpio);
> > +   }
> > +   nr_gpio++;
> > +   }
> 
> I think the code should use the gpiod_get_array() API.

OK thanks will take a look.

> > +   /* Give up shared GPIOs now, they will be used for OOB wake */
> > +   devm_gpiod_put(ddata->dev, mode_gpio0);
> > +   ddata->gpio[PHY_MDM6600_MODE0] = ERR_PTR(-ENODEV);
> > +   devm_gpiod_put(ddata->dev, mode_gpio1);
> > +   ddata->gpio[PHY_MDM6600_MODE0] = ERR_PTR(-ENODEV);
> 
> You want PHY_MDM6600_MODE1 instead. Also I would just use NULL.
> NULL is used by gpiod_get_optional and is handled by the gpiod
> functions, so you don't need to check for gpio errors everywhere.

Oops yup let's just drop this until we know what to do in the
further patches.

> > +#ifdef CONFIG_OF
> > +static const struct of_device_id phy_mdm6600_id_table[] = {
> > +   { .compatible = "motorola,mapphone-mdm6600", },
> > +   {},
> > +};
> > +MODULE_DEVICE_TABLE(of, phy_mdm6600_id_table);
> > +#endif
> 
> I suggest to just depend on CONFIG_OF in Kconfig and drop the ifdef
> and of_match_ptr() parts. It's very unlikely, that this will be
> used without DT and would need quite some rework anyways.

OK

> > +static int phy_mdm6600_probe(struct platform_device *pdev)
> > +{
> > +   struct phy_mdm6600 *ddata;
> > +   struct usb_otg *otg;
> > +   const struct of_device_id *of_id;
> > +   int error;
> > +
> > +   of_id = of_match_device(of_match_ptr(phy_mdm6600_id_table),
> > +   >dev);
> > +   if (!of_id)
> > +   return -EINVAL;
> 
> I suggest to drop the of_match_device(). The driver will error
> out anyways when it can't get the gpios.

OK

> Generally I'm a bit worried about handling the mode gpios in two
> different drivers. It looks like it might become a dependency hell.

Yeah you're right. That will require the modules to be loaded
in the right order. It's probably best that we handle the mdm6600
to SoC wake-up in this driver. And then maybe export a function for
toggling the SoC to mdm660 wake to make sure the dependencies are
clear for the modules.

Regards,

Tony


--
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] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Tony Lindgren]

Let's add support for the GPIO controlled USB PHY on the MDM6600 modem.
It is used on some Motorola Mapphone series of phones and tablets such
as Droid 4.

The MDM6600 is hardwired to the first OHCI port in the Droid 4 case, and
is controlled by several GPIOs. The USB PHY is integrated into the MDM6600
device it seems. We know this as we get L3 errors from omap-usb-host if
trying to use the PHY before MDM6600 is configured.

The GPIOs controlling MDM6600 are used to power MDM660 on and off, to
configure the USB start-up mode (normal mode versus USB flashing), and
they also tell the state of the MDM6600 device.

The two start-up mode GPIOs are dual-purposed and used for out of band
(OOB) wake-up for USB and TS 27.010 serial mux. But we need to configure
the USB start-up mode first to get MDM6600 booted in the right mode to
be usable in the first place.

For now, this driver just gives up the two start-up mode GPIOs after the
modem has been configured to boot in normal mode. One of them we may
want to configure for USB OOB wake in this driver later on, but that's a
separate series of patches and needs more work.

Note that the Motorola Mapphone Linux kernel tree has a "radio-ctrl"
driver for modems. But it really does not control the radio at all, it
just controls the modem power and start-up mode for USB. So I came to
the conclusion that we're better off having this done in the USB PHY
driver. For adding support for USB flashing mode, we can later on add
a kernel module option for flash_mode=1 or something similar.

Also note that currently there is no PM runtime support for the OHCI
on omap variant SoCs. So for low(er) power idle states, currenty both
ohci-platform and phy-mapphone-mdm6600 must be unloaded or unbound.

For reference here is what I measured for total power consumption on
an idle Droid 4 with and without USB related MDM6600 modules:

idle lcd offphy-mapphone-mdm6600ohci-platform
153mW   284mW   344mW

So it seems that MDM6600 is currently not yet idling even with it's
radio turned off, but that's something that is beyond the control of
this USB PHY driver.

Cc: devicet...@vger.kernel.org
Cc: Mark Rutland <mark.rutl...@arm.com>
Cc: Marcel Partap <mpar...@gmx.net>
Cc: Michael Scott <michael.sc...@linaro.org>
Cc: Rob Herring <robh...@kernel.org>
Cc: Sebastian Reichel <s...@kernel.org>
Signed-off-by: Tony Lindgren <t...@atomide.com>
---
 .../bindings/phy/phy-mapphone-mdm6600.txt  |  30 ++
 drivers/phy/motorola/Kconfig   |   9 +
 drivers/phy/motorola/Makefile  |   1 +
 drivers/phy/motorola/phy-mapphone-mdm6600.c| 490 +
 4 files changed, 530 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
 create mode 100644 drivers/phy/motorola/phy-mapphone-mdm6600.c

diff --git a/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt 
b/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
@@ -0,0 +1,30 @@
+Device tree binding documentation for Motorola Mapphone MDM6600 USB PHY
+
+Required properties:
+- compatible   Must be "motorola,mapphone-mdm6600"
+- enable-gpios GPIO to enable the USB PHY
+- power-gpios  GPIO to power on the device
+- reset-gpios  GPIO to reset the device
+- mode-gpios   Two GPIOs to configure MDM6600 USB start-up mode for
+   normal mode versus USB flashing mode
+- status-gpios Three GPIOs to read the power state of the MDM6600
+- cmd-gpiosThree GPIOs to control the power state of the MDM6600
+
+Example:
+
+fsusb1_phy: fsusb1_phy {
+   compatible = "motorola,mapphone-mdm6600";
+   enable-gpios = < 31 GPIO_ACTIVE_LOW>; /* gpio_95 */
+   power-gpios = < 22 GPIO_ACTIVE_HIGH>; /* gpio_54 */
+   reset-gpios = < 17 GPIO_ACTIVE_HIGH>; /* gpio_49 */
+   mode-gpios = < 20 GPIO_ACTIVE_HIGH>,  /* gpio_148 */
+< 21 GPIO_ACTIVE_HIGH>;  /* gpio_149 */
+   status-gpios = < 23 GPIO_ACTIVE_HIGH>,/* gpio_55 */
+  < 21 GPIO_ACTIVE_HIGH>,/* gpio_53 */
+  < 20 GPIO_ACTIVE_HIGH>;/* gpio_52 */
+   cmd-gpios = < 7 GPIO_ACTIVE_HIGH>,/* gpio_103 */
+   < 8 GPIO_ACTIVE_HIGH>,/* gpio_104 */
+   < 14 GPIO_ACTIVE_HIGH>;   /* gpio_142 */
+   #phy-cells = <0>;
+};
+
diff --git a/drivers/phy/motorola/Kconfig b/drivers/phy/motorola/Kconfig
--- a/drivers/phy/motorola/Kconfig
+++ b/drivers/phy/motorola/Kconfig
@@ -10,3 +10,12 @@ config PHY_CPCAP_USB
help
  Enable this for USB to work on Motorola phones and tablets
  such as Droid 4.
+
+config PHY_MAPPHONE_MDM6600
+   tristate "Motorola Mappho

[PATCH] phy: dm816x-usb: Remove unused phy_data

[Tony Lindgren]

This is used by some TI USB PHY drivers but not this one, so we
can just remove it.

Signed-off-by: Tony Lindgren <t...@atomide.com>
---
 drivers/phy/ti/phy-dm816x-usb.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/phy/ti/phy-dm816x-usb.c b/drivers/phy/ti/phy-dm816x-usb.c
--- a/drivers/phy/ti/phy-dm816x-usb.c
+++ b/drivers/phy/ti/phy-dm816x-usb.c
@@ -189,7 +189,6 @@ static int dm816x_usb_phy_probe(struct platform_device 
*pdev)
struct phy_provider *phy_provider;
struct usb_otg *otg;
const struct of_device_id *of_id;
-   const struct usb_phy_data *phy_data;
int error;
 
of_id = of_match_device(of_match_ptr(dm816x_usb_phy_id_table),
@@ -220,8 +219,6 @@ static int dm816x_usb_phy_probe(struct platform_device 
*pdev)
if (phy->usbphy_ctrl == 0x2c)
phy->instance = 1;
 
-   phy_data = of_id->data;
-
otg = devm_kzalloc(>dev, sizeof(*otg), GFP_KERNEL);
if (!otg)
return -ENOMEM;
-- 
2.16.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

Re: [BUG] musb: broken isochronous transfer at TI AM335x platform

[Tony Lindgren]

* Matwey V. Kornilov  [180215 17:55]:
> []   7.219456 d=  0.000997 [181.0 +  3.667] [  3] IN   : 4.5
> [T   ]   7.219459 d=  0.03 [181.0 +  7.083] [800] DATA0: 53 da ...
> []   7.220456 d=  0.000997 [182   +  3.667] [  3] IN   : 4.5
> [T   ]   7.220459 d=  0.03 [182   +  7.000] [800] DATA0: 13 36 ...
> []   7.222456 d=  0.001997 [184   +  3.667] [  3] IN   : 4.5
> []   7.222459 d=  0.03 [184   +  7.000] [  3] DATA0: 00 00
> []   7.223456 d=  0.000997 [185.0 +  3.667] [  3] IN   : 4.5
> []   7.223459 d=  0.03 [185.0 +  7.000] [  3] DATA0: 00 00
> 
> Please note, that the time moment "7.221456" has missed IN request
> packet which must be sent out every 1ms in this low-speed USB case.
> Then, all incoming packets became empty ones. Such moments coincide
> with frame discarding in pwc driver.

Well sounds like you may be able to fix it since you have a test
case for it :)

> Even though IN sending is usually handled by USB host hardware, it is
> not fully true for MUSB. Every IN is triggered by musb kernel driver
> (see MUSB_RXCSR_H_REQPKT usage in musb_host_packet_rx() and
> musb_ep_program()) since auto IN is not used. Rather complicated logic
> is incorporated to decide whether IN packet has to be sent. First,
> musb_host_packet_rx() handles IN sending when current URB is not
> completed (i.e. current URB has another packet which has to be
> received next). Second, musb_advance_schedule() (via musb_start_urb())
> handles the case when current URB is completed but there is another
> URB pending. It seems that there is a hardware logic to fire IN packet
> in a way to have exactly 1ms between two consequent INs. So,
> MUSB_RXCSR_H_REQPKT is considered as IN requesting flag.

Yeah this is a known issue with musb, there is not much ISO support
currently really. The regression should be fixed though.

Sorry I don't have much ideas on how to improve things here. One
way might be to attempt to split the large musb functions into
smaller functions and see if that then allows finer grained control.

Just to try to come up with some new ideas.. Maybe there's some way
to swap the hardware EP config dynamically and have some packets
mostly preconfigured and waiting to be triggered?

Regards,

Tony
--
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 4/4] ARM: dts: am43xx: Enable dual-role mode for USB1

[Tony Lindgren]

* Roger Quadros  [180122 05:17]:
> +Tony
> 
> On 22/01/18 15:11, Roger Quadros wrote:
> > USB1 port is micro-AB type and can function as peripheral
> > as well as host. Enable dual-role mode for USB1.

Looks like I don't have this one, please resend it
separately when it's safe to apply.

Regards,

Tony
--
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: musb: fix enumeration after resume

[Tony Lindgren]

* Andreas Kemnade <andr...@kemnade.info> [180127 08:34]:
> On dm3730 there are enumeration problems after resume.
> Investigation led to the cause that the MUSB_POWER_SOFTCONN
> bit is not set. If it was set before suspend (because it
> was enabled via musb_pullup()), it is set in
> musb_restore_context() so the pullup is enabled. But then
> musb_start() is called which overwrites MUSB_POWER and
> therefore disables MUSB_POWER_SOFTCONN, so no pullup is
> enabled and the device is not enumerated.

I just gave this patch a quick try and things seem to behave
for me from PM point of view:

Tested-by: Tony Lindgren <t...@atomide.com>

Unrelated to this patch, I also noticed that we now somehow
higher idle power consumption initially when musb modules are
loaded. It used to idle after that but now to get things to
idle I had to plug and unplug a USB device once to the musb
port.

Regards,

Tony
--
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: power management problems in ehci-omap

[Tony Lindgren]

* Andreas Kemnade <andr...@kemnade.info> [180206 18:04]:
> On Tue, 6 Feb 2018 09:17:37 -0800
> Tony Lindgren <t...@atomide.com> wrote:
> > uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2>/dev/null)
> > for uart in $uarts; do
> > echo enabled > $uart/wakeup 2>&1
> > echo auto > $uart/control 2>&1
> > done
> > 
> 
> hmm, this looks a bit like runtime suspend.

Not only that, it enables wakeup for UART also for suspend :)

That is if your dts has it configured with interrupts-extended
for the console UART like omap3-beagle-xm.dts has for example.
Seems like the gta04 dts don't have these.. And you also want
to have chosen with stdout-path =  or whatever the debug
UART is for earlycon to work.

> I mean suspend aka echo mem >/sys/power/state
> 
> > echo -n 1 > /sys/kernel/debug/pm_debug/enable_off_mode

And the above will enable SoC and PMIC off modes, which will also
take the suspend power to some much much lower value :) You need
to configure the PMIC too depending if the oscillator can be turned
off, in that case set "ti,twl4030-power-idle-osc-off". That too
seems to be missing in gta04 dts files..

Regards,

Tony

--
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: power management problems in ehci-omap

[Tony Lindgren]

* Andreas Kemnade <andr...@kemnade.info> [180206 16:56]:
> On Tue, 6 Feb 2018 08:04:52 -0800
> Tony Lindgren <t...@atomide.com> wrote:
> 
> > * Andreas Kemnade <andr...@kemnade.info> [180206 06:42]:
> > > rechecked with a board with really nothing connected there
> > > Same behaviour  
> > 
> > I've just verified that my test board power consumption goes
> > back to normal after rmmod ehci-omap with v4.15.
> > 
> yes, for me too, I initially used a test script which does an
> echo rmmod ehci-omap
> 
> without a real
> rmmod ehci-omap

Ah OK :)

> It just seems to be consistent with my observations in a fully booted
> system (where many things can play a role). Sorry for that confusion.

Try with a minimal set of modules first, then modprobe and rmmod one
at a time until you find the module breaking PM?

You probably know this already, but just in case it helps..

First idle the UARTs and enable off mode with something like:

uarts=$(find /sys/class/tty/tty[SO]*/device/power/ -type d)
for uart in $uarts; do
echo 3000 > $uart/autosuspend_delay_ms 2>&1
done

uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2>/dev/null)
for uart in $uarts; do
echo enabled > $uart/wakeup 2>&1
echo auto > $uart/control 2>&1
done

echo -n 1 > /sys/kernel/debug/pm_debug/enable_off_mode

Then if using omap3, the attached debug hack patch can be used to
see which devices are not idling:

> But suspend current is a problem. I have repeated the measurement with
> another board, so it is not a board problem. 

I also verified v4.15 behaves for suspend current even with
echi-omap loaded just in case.

Regards,

Tony

8< ---
>From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren <t...@atomide.com>
Date: Wed, 13 Dec 2017 16:36:45 -0800
Subject: [PATCH] NOT FOR MERGING: Test patch for dumping omap3 off idle
 blocking bits

Allows seeing the deeper idle state blockers in
/sys/kernel/debug/pm_debug/count. For example, when
off idle is working on beaglboard xm, this is what
i see:

# sleep 5; cat /sys/kernel/debug/pm_debug/count
...
0006 48005020 (fa005020) cm_idlest_per blocking bits: 0001
e7bd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 0042
000d 48004a28 (fa004a28) cm_idlest3_core
---
 arch/arm/mach-omap2/pm-debug.c | 68 ++
 1 file changed, 68 insertions(+)

diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -142,10 +142,78 @@ static int pwrdm_dbg_show_timer(struct powerdomain 
*pwrdm, void *user)
return 0;
 }
 
+#include "iomap.h"
+
+struct dregs {
+   const char  *desc;
+   u32 phys;
+   void __iomem*virt;
+   u32 mask;
+};
+
+#define PER_CM_BASE0x48005000
+#define PER_CM_REG(name, offset, mask) \
+   { name, PER_CM_BASE + offset,   \
+   OMAP2_L4_IO_ADDRESS(PER_CM_BASE + offset), mask, }
+
+static struct dregs cm_per[] = {
+   PER_CM_REG("cm_idlest_per", 0x20, 0xfff8), /* p 513 */
+   { NULL, },
+};
+
+#define CORE_CM_BASE   0x48004a00
+#define CORE_CM_REG(name, offset, mask)\
+   { name, CORE_CM_BASE + offset,  \
+   OMAP2_L4_IO_ADDRESS(CORE_CM_BASE + offset), mask, }
+
+static struct dregs cm_core[] = {
+   CORE_CM_REG("cm_idlest1_core", 0x20, 0x9c800109), /* p 467 */
+   CORE_CM_REG("cm_idlest3_core", 0x28, 0xfffb),
+   { NULL, },
+};
+
+void __dregs_dump(struct dregs *dregs, struct seq_file *s)
+{
+   for (; dregs->desc; dregs++) {
+   u32 val, blockers;
+
+   val = __raw_readl(dregs->virt);
+
+   seq_printf(s, "%08x %08x (%p) %s",
+  val, dregs->phys, dregs->virt,
+  dregs->desc);
+
+   if (dregs->mask) {
+   blockers = ~val;
+   blockers &= ~dregs->mask;
+
+   if (blockers)
+   seq_printf(s, " blocking bits: %08x",
+  blockers);
+   }
+
+   seq_printf(s, "\n");
+   }
+}
+
+void cm_per_dump(struct seq_file *s)
+{
+   __dregs_dump(cm_per, s);
+}
+
+void cm_core_dump(struct seq_file *s)
+{
+   __dregs_dump(cm_core, s);
+}
+
 static int pm_dbg_show_counters(struct seq_file *s, void *unused)
 {
pwrdm_for_each(pwrdm_dbg_show_counter, s);
clkdm_for_each(clkdm_dbg_show_counter, s);
+   if (cpu_is_omap34xx()) {
+   cm_per_dump(s);
+   cm_core_dump(s);
+   }
 
return 0;
 }
-- 
2.16.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

Re: power management problems in ehci-omap

[Tony Lindgren]

* Andreas Kemnade  [180206 06:42]:
> rechecked with a board with really nothing connected there
> Same behaviour

I've just verified that my test board power consumption goes
back to normal after rmmod ehci-omap with v4.15.

For ehci PM, it might be a bit easier to do nowadays that
we have Linux generic wakeirq support if somebody wants to
take a look at it. The PHY lines could have wakeirq events
enabled for the pads, and there is an older series from
Rogeq that does not use wakeirqs at:

https://lkml.org/lkml/2013/7/10/355

Regards,

Tony
--
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] ARM: dts: dra7: Disable USB metastability workaround for USB2

[Tony Lindgren]

* Felipe Balbi  [171204 11:43]:
> Roger Quadros  writes:
> 
> > The metastability workaround causes Erratic errors [1]
> > on the HighSpeed USB PHY which can cause upto 2 seconds
> > delay in enumerating to a USB host while in Gadget mode.
> >
> > Disable the Run/Stop metastability workaround to avoid this
> > ill effect. We are aware that this opens up the opportunity
> > for Run/Stop metastability, however this issue has never been
> > observed in TI releases so we think that Run/Stop metastability
> > is a lesser evil than the PHY Erratic errors. So disable it.
> >
> > [1] USB controller trace during gadget enumeration
> > irq/90-dwc3-969   [000] d...52.323145: dwc3_event: event 
> > (0901): Erratic Error [U0]
> > irq/90-dwc3-969   [000] d...52.560646: dwc3_event: event 
> > (0901): Erratic Error [U0]
> > irq/90-dwc3-969   [000] d...52.798144: dwc3_event: event 
> > (0901): Erratic Error [U0]
> >
> > Signed-off-by: Roger Quadros 
> 
> FWIW:
> 
> Acked-by: Felipe Balbi 
> 
> I'm taking the dwc3 counterpart to v4.16

OK applying this into omap-for-v4.16/dt thanks.

Tony

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: EHCI and MUSB do not discover devices without CONFIG_PM

[Tony Lindgren]

* Ladislav Michl <la...@linux-mips.org> [171128 17:01]:
> On Tue, Nov 28, 2017 at 06:39:13AM -0800, Tony Lindgren wrote:
> > Limiting things to C1 with cpuidle is probably what you need
> > for having USB also working.
> 
> With echo 1 > /sys/devices/system/cpu/cpu0/cpuidle/state{1-6}/disable
> jitter is about 100us which is about 3x worse than with CONFIG_PM
> disabled (and much better when idling), but decoder works with
> occassional errors.

OK sounds like there is still something happening in the idle path
beyond WFI then.

> Anyway, it would be nice to find out why USB does not work with CONFIG_PM
> disabled :)

Sure.

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: EHCI and MUSB do not discover devices without CONFIG_PM

[Tony Lindgren]

* Ladislav Michl <la...@linux-mips.org> [171128 14:31]:
> On Tue, Nov 28, 2017 at 06:11:31AM -0800, Tony Lindgren wrote:
> > * Ladislav Michl <la...@linux-mips.org> [171128 09:42]:
> > > On Tue, Nov 28, 2017 at 10:30:54AM +0100, Greg KH wrote:
> > > > bit-banging an ir decoder, ugh, you are in for a world of hurt.  Can't
> > > > you put a chip on the device that does this for you in hardware?
> > > 
> > > OMAP has DM timer which can be externally trigered on edge. Perfect for
> > > that purpose. But I cannot pinmux its input as hw designers did poor job.
> > > And there are thousands of devices deployed.
> > > 
> > > So it is about a lot of soldering or providing software solution.
> > > 
> > > > Anyway, good luck!
> > > 
> > > A little pointer would increase "luck" by several order of magnitudes.
> > 
> > Hmm did you already try limiting cpuidle to C1 only in /sys?
> 
> I have CONFIG_CPU_IDLE=n, which should be the same. Is that right?

You will then use the omap3_pm_idle() that does not know much
anything about latencies.

> > From what I recall you just set the latency to less than C2
> > has. The cpuidle latencies are in struct omap3_idle_statedata
> > omap3_idle_data[].
> 
> I disabled cpuidle and frequency scaling completely. The only thing that
> make jitter difference is CONFIG_PM (see original thread).

Right as then omap3_pm_idle() is disabled and only WFI is done :)

Limiting things to C1 with cpuidle is probably what you need
for having USB also working.

> There's lot of pm_wkup interrupts with CONFIG_PM - order of magnitude
> more than gp_timer.

Hmm yeah that is true. And idling and waking up devices also takes
some time.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: EHCI and MUSB do not discover devices without CONFIG_PM

[Tony Lindgren]

* Ladislav Michl  [171128 09:42]:
> On Tue, Nov 28, 2017 at 10:30:54AM +0100, Greg KH wrote:
> > bit-banging an ir decoder, ugh, you are in for a world of hurt.  Can't
> > you put a chip on the device that does this for you in hardware?
> 
> OMAP has DM timer which can be externally trigered on edge. Perfect for
> that purpose. But I cannot pinmux its input as hw designers did poor job.
> And there are thousands of devices deployed.
> 
> So it is about a lot of soldering or providing software solution.
> 
> > Anyway, good luck!
> 
> A little pointer would increase "luck" by several order of magnitudes.

Hmm did you already try limiting cpuidle to C1 only in /sys?

>From what I recall you just set the latency to less than C2
has. The cpuidle latencies are in struct omap3_idle_statedata
omap3_idle_data[].

Regards,

Tony
--
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 regression in next-20171108 with hub spamming

[Tony Lindgren]

* Felipe Balbi  [171109 11:01]:
> Felipe Balbi  writes:
> > Okay, found it. Testing a patch.
> 
> Here's the patch, I'll send it formally shortly.

Thanks yeah that fixes the issue for me, replied to your formal
patch with a tested by.

Regards,

Tony

> diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
> index 0cdc463c9509..c15fbf76f8f7 100644
> --- a/drivers/usb/core/message.c
> +++ b/drivers/usb/core/message.c
> @@ -975,6 +975,7 @@ int usb_get_status(struct usb_device *dev, int recip, int 
> type, int target,
>   }
>  
>   *(u32 *) data = le32_to_cpu(*(__le32 *) status);
> + ret = 0;
>   break;
>   case 2:
>   if (type != USB_STATUS_TYPE_STANDARD) {
> @@ -983,6 +984,7 @@ int usb_get_status(struct usb_device *dev, int recip, int 
> type, int target,
>   }
>  
>   *(u16 *) data = le16_to_cpu(*(__le16 *) status);
> + ret = 0;
>   break;
>   default:
>   ret = -EIO;
> -- 
> 2.14.2.642.g20fed7cad4
> 
> 
> -- 
> balbi


--
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: core: message: remember to reset 'ret' to 0 when necessary

[Tony Lindgren]

* Felipe Balbi <felipe.ba...@linux.intel.com> [171109 11:01]:
> usb_control_msg() will return the amount of bytes transferred, if that
> amount matches what we wanted to transfer, we need to reset 'ret' to 0
> from usb_get_status().

Thanks that fixes the issue I was seeing:

Tested-by: Tony Lindgren <t...@atomide.com>


> Fixes: 2e43f0fe379c ("usb: core: add a 'type' parameter to usb_get_status()")
> Reported-by: Tony Lindgren <t...@atomide.com>
> Signed-off-by: Felipe Balbi <felipe.ba...@linux.intel.com>
> ---
>  drivers/usb/core/message.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
> index 0cdc463c9509..c15fbf76f8f7 100644
> --- a/drivers/usb/core/message.c
> +++ b/drivers/usb/core/message.c
> @@ -975,6 +975,7 @@ int usb_get_status(struct usb_device *dev, int recip, int 
> type, int target,
>   }
>  
>   *(u32 *) data = le32_to_cpu(*(__le32 *) status);
> + ret = 0;
>   break;
>   case 2:
>   if (type != USB_STATUS_TYPE_STANDARD) {
> @@ -983,6 +984,7 @@ int usb_get_status(struct usb_device *dev, int recip, int 
> type, int target,
>   }
>  
>   *(u16 *) data = le16_to_cpu(*(__le16 *) status);
> + ret = 0;
>   break;
>   default:
>   ret = -EIO;
> -- 
> 2.14.2.642.g20fed7cad4
> 
--
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: MUSB Error Handling

[Tony Lindgren]

* Bin Liu  [171031 18:35]:
> Hi,
> 
> On Tue, Oct 31, 2017 at 12:56:40PM -0500, Adam Ford wrote:
> > We have a situation where occasionally the USB glitches where the D-
> > glitches low at or near an end of frame (EOF) or end of packet (EOP).
> > We're using the TWL4030 with MUSB on an OMAP3 processor.  We cannot
> > tell where the glitch is originating.
> > 
> >  We're working on resolving this in both hardware and software, but I
> > was hoping someone might have some insights on how to address it in
> > software.
> > 
> > We created a special test fixture to force the D- low for a moment
> > during the EOP and EOF to attempt to compare the handling of other USB
> > controllers and/or USB hubs.  The reason I think it's unique to the
> > MUSB controller or the TWL4030, because we cannot reproduce this issue
> > using other USB controllers and/or other USB controllers handle the
> > error condition.
> > 
> > On an older, 3.0.x kernel, if we get a glitch on D-, the MUSB
> > controller may become unresponsive to the point where a reboot becomes
> > required.
> > 
> > Testing this similar scenario with the 4.14-RC kernel, the MUSB
> > controller drops the connection and re-enumerates almost immediately,
> > which indicates to me that the error handling is getting better (or
> > the glitching is reduced somehow).  I have not seen a reboot be
> > required.
> > 
> > If I connect the same USB devices to a USB Hub and/or other USB
> > controller and attempt to force this same condition with the test
> > fixture, the high level USB code does not notice there is an error.
> > There is no disconnect, no hanging, no loss of data.
> > 
> > I am not a USB expert, but it seems like we might be able to handle
> > the error in software and/or retry if necessary without dropping the
> > connection.  Might someone have any ideas or thoughts on how we might
> > be able to tweak the software?
> 
> Does the uart console print any log message before re-enumeration happens
> with v4.14-rc? is there 'Babble'?
> 
> I cannot tell what could cause the glitches, which seems to be analog
> related, but I don't think there is any way in software can prevent
> dropping the connection. I suspect the glitches cause the babble condition,
> then the musb controller drops the connection, but the musb driver
> receives the babble event and restarts the enumeration. There is no
> software control to prevent the controller to drop the connection when
> babble happens.

This sounds like a different issue but because of the glitch on the
data lines might be worth checking..

It used to be that musb was trying to enumerate as a gadget on it's
own, maybe only if the bootloader had some gadget configured.

I think this issue is fixed now with commit a118df07f5b1 ("usb: musb:
Don't set d+ high before enable for 2430 glue layer"). So just to
make sure, have some gadget configured in the kernel for musb while
running your tests.

Regards,

Tony
--
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: isp1301-omap: Convert timers to use timer_setup()

[Tony Lindgren]

* Kees Cook <keesc...@chromium.org> [171004 17:57]:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
> 
> Cc: Felipe Balbi <ba...@kernel.org>
> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> Cc: linux-usb@vger.kernel.org
> Cc: linux-o...@vger.kernel.org
> Cc: Thomas Gleixner <t...@linutronix.de>
> Signed-off-by: Kees Cook <keesc...@chromium.org>
> ---
> This requires commit 686fef928bba ("timer: Prepare to change timer
> callback argument type") in v4.14-rc3, but should be otherwise
> stand-alone.

Acked-by: Tony Lindgren <t...@atomide.com>
--
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 0/2] USB: musb: PM fixes

[Tony Lindgren]

* Johan Hovold <jo...@kernel.org> [171005 02:15]:
> On Thu, Sep 07, 2017 at 03:37:46PM +0200, Johan Hovold wrote:
> > These patches fix a couple of bugs introduced by the recent runtime-PM
> > work (details in the individual commit messages).
> > 
> > Note that the external abort was due to the irq work never being flushed
> > on suspend, and that we may need similar fixes for the delayed reset and
> > resume work which are likewise never cancelled on suspend.
> > 
> > As I just mentioned in the v1 thread, there are a number of further issues 
> > with
> > musb suspend (e.g. on BBB):
> > 
> >  1. System suspend appears to break any active gadget (which then can be
> > restarted manually).
> > 
> >  2. The early_tx polling in musb_cppi41 lacks a timeout, something which can
> > lead to the hrtimer rescheduling itself indefinitely if the fifo never
> > empties (e.g. if a transfer is is initiated post suspend due to issue 
> > 1).
> > 
> > See commit a655f481d83d ("usb: musb: musb_cppi41: handle pre-mature TX
> > complete interrupt").
> > 
> >  3. In host mode, if a device is disconnected while the system is suspended,
> > this will keep the controller runtime active after resume as the session
> > bit is always set.
> 
> Bin and Tony, any comments to this series?

Oops sorry I forgot to test these after two recent conferences. I just gave
these a try and they both behave for me. Nice fixes, for both:

Tested-by: Tony Lindgren <t...@atomide.com>
--
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 3/3] mfd: twl: move header file out of I2C realm

[Tony Lindgren]

* Wolfram Sang <w...@the-dreams.de> [170814 01:43]:
> 
> > > Given the triviality of the change for non-MFD subsystems, can we apply
> > > this for 4.14?
> > 
> > I can't apply anything without Acks for *all* of the subsystems above.
> 
> Well, there are cases when you can. Those should be exceptions and well
> justified, of course.
> 
> > My suggestion would be to collect the Acks you've received up until
> > this point and identify which SS's are still lacking in change log
> > section of a RESEND.
> 
> I agree, though, that I can try a second round to get the acks.

As long as it's been compile tested with omap2plus_defconfig:

Acked-by: Tony Lindgren <t...@atomide.com>


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] mfd: tps65010: move header file out of I2C realm

[Tony Lindgren]

* Lee Jones <lee.jo...@linaro.org> [170814 01:44]:
> On Mon, 14 Aug 2017, Lee Jones wrote:
> 
> > On Sun, 13 Aug 2017, Wolfram Sang wrote:
> > 
> > > On Tue, May 23, 2017 at 08:18:19AM +0100, Lee Jones wrote:
> > > > On Mon, 22 May 2017, Wolfram Sang wrote:
> > > > 
> > > > > include/linux/i2c is not for client devices. Move the header file to a
> > > > > more appropriate location.
> > > > > 
> > > > > Signed-off-by: Wolfram Sang <w...@the-dreams.de>
> > > > > ---
> > > > >  arch/arm/mach-omap1/board-h2-mmc.c  | 2 +-
> > > > >  arch/arm/mach-omap1/board-h2.c  | 2 +-
> > > > >  arch/arm/mach-omap1/board-h3-mmc.c  | 2 +-
> > > > >  arch/arm/mach-omap1/board-h3.c  | 2 +-
> > > > >  arch/arm/mach-omap1/board-osk.c | 2 +-
> > > > >  arch/arm/mach-s3c24xx/mach-osiris-dvs.c | 2 +-
> > > > >  arch/arm/mach-s3c24xx/mach-osiris.c | 2 +-
> > > > 
> > > > >  drivers/mfd/tps65010.c  | 2 +-
> > > > 
> > > > For my own reference:
> > > >   Acked-for-MFD-by: Lee Jones <lee.jo...@linaro.org>
> > > 
> > > Same here: ok for 4.14 or something needed?
> > 
> > Can this patch be applied on its own, or does it have dependencies?
> 
> Even if it doesn't, it still requires Acks.

As long as this has been compile tested with omap1_defconfig:

Acked-by: Tony Lindgren <t...@atomide.com>

Regards,

Tony
--
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-next][PATCH] usb: dwc3: omap: remove IRQ_NOAUTOEN used with shared irq

[Tony Lindgren]

* Vignesh R  [170628 21:21]:
> 
> 
> On Thursday 29 June 2017 05:01 AM, Strashko, Grygorii wrote:
> > IRQ_NOAUTOEN can't be used with shared IRQs and Kernel now will triggers
> > warning if it happns, since commit 04c848d39879 ("genirq: Warn when
> > IRQ_NOAUTOEN is used with shared interrupts"). And this is the case for
> > OMAP DWC 3 driver.
> > 
> > Hence, remove IRQ_NOAUTOEN flag and instead call disable_irq() before
> > disabling PM runtime in probe error path handling.
> 
> Or, how about requesting the irq at the end of probe after extcon
> registration?

Hmm yeah, what prevents the issue that we tried to fix with commit
12a7f17fac5b ("usb: dwc3: omap: fix race of pm runtime with irq handler
in probe")?

Regards,

Tony


> > Fixes: 12a7f17fac5b ("usb: dwc3: omap: fix race of pm runtime with...")
> > Signed-off-by: Grygorii Strashko 
> > ---
> >  drivers/usb/dwc3/dwc3-omap.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
> > index 9892650..cd9bef5 100644
> > --- a/drivers/usb/dwc3/dwc3-omap.c
> > +++ b/drivers/usb/dwc3/dwc3-omap.c
> > @@ -512,7 +512,6 @@ static int dwc3_omap_probe(struct platform_device *pdev)
> >  
> > /* check the DMA Status */
> > reg = dwc3_omap_readl(omap->base, USBOTGSS_SYSCONFIG);
> > -   irq_set_status_flags(omap->irq, IRQ_NOAUTOEN);
> > ret = devm_request_threaded_irq(dev, omap->irq, dwc3_omap_interrupt,
> > dwc3_omap_interrupt_thread, IRQF_SHARED,
> > "dwc3-omap", omap);
> > @@ -533,10 +532,10 @@ static int dwc3_omap_probe(struct platform_device 
> > *pdev)
> > }
> >  
> > dwc3_omap_enable_irqs(omap);
> > -   enable_irq(omap->irq);
> > return 0;
> >  
> >  err1:
> > +   disable_irq(omap->irq);
> > pm_runtime_put_sync(dev);
> > pm_runtime_disable(dev);
> >  
> > 
> 
> -- 
> Regards
> Vignesh
--
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-related linux-next boot failures

[Tony Lindgren]

 Felipe Balbi  [170628 01:32]:
> Greg KH  writes:
> > On Tue, Jun 27, 2017 at 02:28:56PM -0400, Carlos Hernandez wrote:
> >> Still seeing AM57xx/DRA72/DRA7x usb-related boot failures on linux-next...
> >
> > Is this a regression?  If so, any specific commit that caused it?
> 
> I did ask for a bisection last time but nobody from TI replied ;-)
> 
> https://marc.info/?i=87h8zi4gmx@linux.intel.com
> 
> Can't really help without bisection logs :-)

Seems this warning got add with 04c848d39879 ("genirq: Warn when
IRQ_NOAUTOEN is used with shared interrupts"). The fix is to get
rid of IRQ_NOAUTOEN and enable_irq for a shared interrupt. Hard
to say as the warning line does not match the version of next I
have so this should be verified.

Regards,

Tony
--
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] phy: cpcap-usb: Fix missing return statement

[Tony Lindgren]

Commit 8ae904e3c236 ("phy: cpcap-usb: Add CPCAP PMIC USB support")
is missing return statement as noted by Colin Ian King
<colin.k...@canonical.com>. If the optional pins are not configured,
we just want to return early and not attempt to configure the pins.

Fixes: 8ae904e3c236 ("phy: cpcap-usb: Add CPCAP PMIC USB support")
Reported-by: Colin Ian King <colin.k...@canonical.com>
Signed-off-by: Tony Lindgren <t...@atomide.com>
---
 drivers/phy/motorola/phy-cpcap-usb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/phy/motorola/phy-cpcap-usb.c 
b/drivers/phy/motorola/phy-cpcap-usb.c
--- a/drivers/phy/motorola/phy-cpcap-usb.c
+++ b/drivers/phy/motorola/phy-cpcap-usb.c
@@ -468,6 +468,8 @@ static int cpcap_usb_init_optional_pins(struct 
cpcap_phy_ddata *ddata)
dev_info(ddata->dev, "default pins not configured: %ld\n",
 PTR_ERR(ddata->pins));
ddata->pins = NULL;
+
+   return 0;
}
 
ddata->pins_ulpi = pinctrl_lookup_state(ddata->pins, "ulpi");
-- 
2.13.0
--
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

[PATCHv3 0/3] Make ohci-platform usable for omap3/4/5

[Tony Lindgren]

Hi,

Here's v3 of this series.

Regards,

Tony

Changes since v2:

- Ignore pm_runtime_get_sync for remove(), not much we can do there
  as noted by Alan Stern

- Add acks

Changes since v1:   

  - Update runtime PM support for ohci 
based on Alan's comments and
  more testing  

  - Just remove ohci-omap3 as it needs 
LS/FS USB PHY not available
  on most hardware

Tony Lindgren (3):
  usb: host: ohci-platform: Add basic runtime PM support
  usb: host: ohci-platform: Add support for omap3 and later
  usb: host: ohci-omap3: Remove driver in favor of ohci-platform

 Documentation/devicetree/bindings/usb/usb-ohci.txt |   1 +
 drivers/usb/host/Kconfig   |   6 +-
 drivers/usb/host/Makefile  |   1 -
 drivers/usb/host/ohci-omap3.c  | 211 -
 drivers/usb/host/ohci-platform.c   |  13 ++
 5 files changed, 19 insertions(+), 213 deletions(-)
 delete mode 100644 drivers/usb/host/ohci-omap3.c

-- 
2.13.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] usb: host: ohci-platform: Add basic runtime PM support

[Tony Lindgren]

This is needed in preparation of adding support for omap3 and
later OHCI. The runtime PM will only do something on platforms
that implement it.

Cc: devicet...@vger.kernel.org
Cc: Hans de Goede <hdego...@redhat.com>
Cc: Rob Herring <r...@kernel.org>
Cc: Roger Quadros <rog...@ti.com>
Cc: Sebastian Reichel <sebastian.reic...@collabora.co.uk>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
Signed-off-by: Tony Lindgren <t...@atomide.com>
---
 drivers/usb/host/ohci-platform.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -242,6 +243,8 @@ static int ohci_platform_probe(struct platform_device *dev)
}
 #endif
 
+   pm_runtime_set_active(>dev);
+   pm_runtime_enable(>dev);
if (pdata->power_on) {
err = pdata->power_on(dev);
if (err < 0)
@@ -271,6 +274,7 @@ static int ohci_platform_probe(struct platform_device *dev)
if (pdata->power_off)
pdata->power_off(dev);
 err_reset:
+   pm_runtime_disable(>dev);
while (--rst >= 0)
reset_control_assert(priv->resets[rst]);
 err_put_clks:
@@ -292,6 +296,7 @@ static int ohci_platform_remove(struct platform_device *dev)
struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
int clk, rst;
 
+   pm_runtime_get_sync(>dev);
usb_remove_hcd(hcd);
 
if (pdata->power_off)
@@ -305,6 +310,9 @@ static int ohci_platform_remove(struct platform_device *dev)
 
usb_put_hcd(hcd);
 
+   pm_runtime_put_sync(>dev);
+   pm_runtime_disable(>dev);
+
if (pdata == _platform_defaults)
dev->dev.platform_data = NULL;
 
-- 
2.13.0
--
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/3] usb: host: ohci-omap3: Remove driver in favor of ohci-platform

[Tony Lindgren]

This driver is no longer needed and can be removed. The reason why
it's safe to remove this driver is that most omap devices don't have a
USB low-speed or full-speed compatible PHY installed and configured
with drivers/mfd/omap-usb-host.c. This means that devices like
beagleboard and pandaboard need to use a high-speed USB hub in order
to use devices like keyboard and mice.

Currently the only known configured for a full-speed PHY is the
mdm6600 modem on droid 4 and I've verified it works just fine with
ohci-platform.

Acked-by: Alan Stern <st...@rowland.harvard.edu>
Acked-by: Roger Quadros <rog...@ti.com>
Reviewed-by: Sebastian Reichel <sebastian.reic...@collabora.co.uk>
Signed-off-by: Tony Lindgren <t...@atomide.com>
---
 drivers/usb/host/Kconfig  |   6 +-
 drivers/usb/host/Makefile |   1 -
 drivers/usb/host/ohci-omap3.c | 211 --
 3 files changed, 5 insertions(+), 213 deletions(-)
 delete mode 100644 drivers/usb/host/ohci-omap3.c

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -473,8 +473,12 @@ config USB_OHCI_HCD_AT91
 config USB_OHCI_HCD_OMAP3
tristate "OHCI support for OMAP3 and later chips"
depends on (ARCH_OMAP3 || ARCH_OMAP4 || SOC_OMAP5)
+   select USB_OHCI_HCD_PLATFORM
default y
-   ---help---
+   help
+ This option is deprecated now and the driver was removed, use
+ USB_OHCI_HCD_PLATFORM instead.
+
  Enables support for the on-chip OHCI controller on
  OMAP3 and later chips.
 
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -52,7 +52,6 @@ obj-$(CONFIG_USB_OHCI_HCD_PCI)+= ohci-pci.o
 obj-$(CONFIG_USB_OHCI_HCD_PLATFORM)+= ohci-platform.o
 obj-$(CONFIG_USB_OHCI_EXYNOS)  += ohci-exynos.o
 obj-$(CONFIG_USB_OHCI_HCD_OMAP1)   += ohci-omap.o
-obj-$(CONFIG_USB_OHCI_HCD_OMAP3)   += ohci-omap3.o
 obj-$(CONFIG_USB_OHCI_HCD_SPEAR)   += ohci-spear.o
 obj-$(CONFIG_USB_OHCI_HCD_STI) += ohci-st.o
 obj-$(CONFIG_USB_OHCI_HCD_AT91)+= ohci-at91.o
diff --git a/drivers/usb/host/ohci-omap3.c b/drivers/usb/host/ohci-omap3.c
deleted file mode 100644
--- a/drivers/usb/host/ohci-omap3.c
+++ /dev/null
@@ -1,211 +0,0 @@
-/*
- * ohci-omap3.c - driver for OHCI on OMAP3 and later processors
- *
- * Bus Glue for OMAP3 USBHOST 3 port OHCI controller
- * This controller is also used in later OMAPs and AM35x chips
- *
- * Copyright (C) 2007-2010 Texas Instruments, Inc.
- * Author: Vikram Pandita <vikram.pand...@ti.com>
- * Author: Anand Gadiyar <gadi...@ti.com>
- * Author: Keshava Munegowda <keshava_mgo...@ti.com>
- *
- * Based on ehci-omap.c and some other ohci glue layers
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
- *
- * TODO (last updated Feb 27, 2011):
- * - add kernel-doc
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "ohci.h"
-
-#define DRIVER_DESC "OHCI OMAP3 driver"
-
-static const char hcd_name[] = "ohci-omap3";
-static struct hc_driver __read_mostly ohci_omap3_hc_driver;
-
-/*
- * configure so an HC device and id are always provided
- * always called with process context; sleeping is OK
- */
-
-/**
- * ohci_hcd_omap3_probe - initialize OMAP-based HCDs
- *
- * Allocates basic resources for this USB host controller, and
- * then invokes the start() method for the HCD associated with it
- * through the hotplug entry's driver_data.
- */
-static int ohci_hcd_omap3_probe(struct platform_device *pdev)
-{
-   struct device   *dev = >dev;
-   struct ohci_hcd *ohci;
-   struct usb_hcd  *hcd = NULL;
-   void __iomem*regs = NULL;
-   struct resource *res;
-   int ret;
-   int irq;
-
-   if (usb_disabled())
-   return -ENODEV;
-
-   if (!dev->parent) {
-   dev_err(dev, "Missing parent device\n");
-   return -ENODEV;
-   }
-
-   irq = platform_get_irq(pdev, 0);
-   if (irq < 0) {
-   dev_err(dev, 

[PATCH 2/3] usb: host: ohci-platform: Add support for omap3 and later

[Tony Lindgren]

With the runtime PM implemented for ohci-platform driver, we can
now support omap3 and later OHCI by adding one device tree
property.

Cc: Hans de Goede <hdego...@redhat.com>
Cc: Rob Herring <r...@kernel.org>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
Cc: Sebastian Reichel <sebastian.reic...@collabora.co.uk>
Acked-by: Alan Stern <st...@rowland.harvard.edu>
Acked-by: Roger Quadros <rog...@ti.com>
Signed-off-by: Tony Lindgren <t...@atomide.com>
---
 Documentation/devicetree/bindings/usb/usb-ohci.txt | 1 +
 drivers/usb/host/ohci-platform.c   | 5 +
 2 files changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/usb-ohci.txt 
b/Documentation/devicetree/bindings/usb/usb-ohci.txt
--- a/Documentation/devicetree/bindings/usb/usb-ohci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ohci.txt
@@ -10,6 +10,7 @@ Optional properties:
 - big-endian-desc : boolean, set this for hcds with big-endian descriptors
 - big-endian : boolean, for hcds with big-endian-regs + big-endian-desc
 - no-big-frame-no : boolean, set if frame_no lives in bits [15:0] of HCCA
+- remote-wakeup-connected: remote wakeup is wired on the platform
 - num-ports : u32, to override the detected port count
 - clocks : a list of phandle + clock specifier pairs
 - phys : phandle + phy specifier pair
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -164,6 +164,10 @@ static int ohci_platform_probe(struct platform_device *dev)
if (of_property_read_bool(dev->dev.of_node, "no-big-frame-no"))
ohci->flags |= OHCI_QUIRK_FRAME_NO;
 
+   if (of_property_read_bool(dev->dev.of_node,
+ "remote-wakeup-connected"))
+   ohci->hc_control = OHCI_CTRL_RWC;
+
of_property_read_u32(dev->dev.of_node, "num-ports",
 >num_ports);
 
@@ -358,6 +362,7 @@ static int ohci_platform_resume(struct device *dev)
 static const struct of_device_id ohci_platform_ids[] = {
{ .compatible = "generic-ohci", },
{ .compatible = "cavium,octeon-6335-ohci", },
+   { .compatible = "ti,ohci-omap3", },
{ }
 };
 MODULE_DEVICE_TABLE(of, ohci_platform_ids);
-- 
2.13.0
--
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 1/3] usb: host: ohci-platform: Add basic runtime PM support

[Tony Lindgren]

* Alan Stern <st...@rowland.harvard.edu> [170523 09:57]:
> On Mon, 22 May 2017, Tony Lindgren wrote:
> > Alan, do you have some better ideas for the ohci_platform_remove()
> > path below?
...
> > --- a/drivers/usb/host/ohci-platform.c
> > +++ b/drivers/usb/host/ohci-platform.c
> > @@ -290,7 +294,14 @@ static int ohci_platform_remove(struct platform_device 
> > *dev)
> > struct usb_hcd *hcd = platform_get_drvdata(dev);
> > struct usb_ohci_pdata *pdata = dev_get_platdata(>dev);
> > struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
> > -   int clk, rst;
> > +   int clk, rst, enabled;
> > +
> > +   enabled = pm_runtime_get_sync(>dev);
> > +   if (enabled < 0) {
> > +   dev_warn(>dev, "pm_runtime_get failed: %i\n",
> > +enabled);
> > +   pm_runtime_put_noidle(>dev);
> > +   }
> 
> I wouldn't worry about checking the return value.  There's no 
> particular reason for this call to fail, is there?

OK yeah if it was to fail it would already fail on probe
already :)

> > usb_remove_hcd(hcd);
> >  
> > @@ -305,6 +316,10 @@ static int ohci_platform_remove(struct platform_device 
> > *dev)
> >  
> > usb_put_hcd(hcd);
> >  
> > +   if (enabled >= 0)
> > +   pm_runtime_put_sync(>dev);
> > +   pm_runtime_disable(>dev);
> 
> And here you could just do the put_sync, with no test.  If the get_sync
> failed then this will probably fail too, but you won't be any worse off
> for the attempt.

OK fine with me.

Thanks,

Tony
--
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 1/3] usb: host: ohci-platform: Add basic runtime PM support

[Tony Lindgren]

* Roger Quadros <rog...@ti.com> [170523 00:14]:
> On 22/05/17 19:00, Tony Lindgren wrote:
> > --- a/drivers/usb/host/ohci-platform.c
> > +++ b/drivers/usb/host/ohci-platform.c
> > @@ -290,7 +294,14 @@ static int ohci_platform_remove(struct platform_device 
> > *dev)
> > struct usb_hcd *hcd = platform_get_drvdata(dev);
> > struct usb_ohci_pdata *pdata = dev_get_platdata(>dev);
> > struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
> > -   int clk, rst;
> > +   int clk, rst, enabled;
> > +
> > +   enabled = pm_runtime_get_sync(>dev);
> 
> Why do we need to pm_runtime_get_sync() here?

ohci_platform_remove()
usb_remove_hcd()
ohci_stop()

Will cause "external abort on non-linefetch" otherwise.

Regards,

Tony
--
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

[PATCHv4] phy: cpcap-usb: Add CPCAP PMIC USB support

[Tony Lindgren]

Some Motorola phones like droid 4 use a custom CPCAP PMIC that has a
multiplexing USB PHY.

This USB PHY can operate at least in four modes using pin multiplexing
and two control GPIOS:

- Pass through companion PHY for the SoC USB PHY
- ULPI PHY for the SoC
- Pass through USB for the modem
- UART debug console for the SoC

This patch adds support for droid 4 USB PHY and debug UART modes,
support for other modes can be added later on as needed.

Both peripheral and host mode are working for the USB. The
host mode depends on the cpcap-charger driver for VBUS.

VBUS and ID pin detection are done using cpcap-adc IIO ADC
driver.

Cc: devicet...@vger.kernel.org
Cc: Marcel Partap <mpar...@gmx.net>
Cc: Michael Scott <michael.sc...@linaro.org>
Acked-by: Rob Herring <r...@kernel.org>
Tested-by: Sebastian Reichel <s...@kernel.org>
Signed-off-by: Tony Lindgren <t...@atomide.com>
---

Changes since v3:
- Dropped extcon based on what was discussed with Kishon as
  we're better off with using IIO directly as we need the values
  for VBUS and ID from IIO

- Updated against linux next and moved to drivers/phy/motorola
  directory like other phy drivers now do

- Removed list for interrupts as it was not used

Changes since v2:   
 - Added extcon support as requested by Kishon

- Added Rob's ack

- Folded in Kconfig randconfig build fix to add depends on IIO

Changes since v1:
- Use iio_read_channel_processed() instead of iio_read_channel_scaled()
  as changed in the v2 of the ADC driver

- Kept Tested-by from Sebastian Reichel <s...@kernel.org> as the change
  from v1 is trivial

---
 .../devicetree/bindings/phy/phy-cpcap-usb.txt  |  40 ++
 drivers/phy/Kconfig|   1 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/motorola/Kconfig   |  11 +
 drivers/phy/motorola/Makefile  |   5 +
 drivers/phy/motorola/phy-cpcap-usb.c   | 674 +
 6 files changed, 732 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
 create mode 100644 drivers/phy/motorola/Kconfig
 create mode 100644 drivers/phy/motorola/Makefile
 create mode 100644 drivers/phy/motorola/phy-cpcap-usb.c

diff --git a/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt 
b/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
@@ -0,0 +1,40 @@
+Motorola CPCAP PMIC USB PHY binding
+
+Required properties:
+compatible: Shall be either "motorola,cpcap-usb-phy" or
+   "motorola,mapphone-cpcap-usb-phy"
+#phy-cells: Shall be 0
+interrupts: CPCAP PMIC interrupts used by the USB PHY
+interrupt-names: Interrupt names
+io-channels: IIO ADC channels used by the USB PHY
+io-channel-names: IIO ADC channel names
+vusb-supply: Regulator for the PHY
+
+Optional properties:
+pinctrl: Optional alternate pin modes for the PHY
+pinctrl-names: Names for optional pin modes
+mode-gpios: Optional GPIOs for configuring alternate modes
+
+Example:
+cpcap_usb2_phy: phy {
+   compatible = "motorola,mapphone-cpcap-usb-phy";
+   pinctrl-0 = <_gpio_mux_sel1 _gpio_mux_sel2>;
+   pinctrl-1 = <_ulpi_pins>;
+   pinctrl-2 = <_utmi_pins>;
+   pinctrl-3 = <_pins>;
+   pinctrl-names = "default", "ulpi", "utmi", "uart";
+   #phy-cells = <0>;
+   interrupts-extended = <
+15 0  14 0  28 0  19 0
+18 0  17 0  16 0  49 0
+48 1
+   >;
+   interrupt-names =
+   "id_ground", "id_float", "se0conn", "vbusvld",
+   "sessvld", "sessend", "se1", "dm", "dp";
+   mode-gpios = < 28 GPIO_ACTIVE_HIGH
+  0 GPIO_ACTIVE_HIGH>;
+   io-channels = <_adc 2>, <_adc 7>;
+   io-channel-names = "vbus", "id";
+   vusb-supply = <>;
+};
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -53,6 +53,7 @@ source "drivers/phy/amlogic/Kconfig"
 source "drivers/phy/broadcom/Kconfig"
 source "drivers/phy/hisilicon/Kconfig"
 source "drivers/phy/marvell/Kconfig"
+source "drivers/phy/motorola/Kconfig"
 source "drivers/phy/qualcomm/Kconfig"
 source "drivers/phy/renesas/Kconfig"
 source "drivers/phy/rockchip/Kconfig"
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_ARCH_TEGRA)  += tegra/
 obj-y  += broadcom/\
  

Re: [PATCH 2/3] usb: host: ohci-platform: Add support for omap3 and later

[Tony Lindgren]

* Tony Lindgren <t...@atomide.com> [170522 09:03]:
> With the runtime PM implemented for ohci-platform driver, we can
> now support omap3 and later OHCI by adding one device tree
> property.

And the related dts patch from v1 series I can queue separately when
people are happy with the driver changes.

Regards,

Tony
--
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

[PATCHv2 0/3] Make ohci-platform usable for omap3/4/5

[Tony Lindgren]

Hi,

Here's v2 of this series.

Regards,

Tony

Changes since v1:

- Update runtime PM support for ohci based on Alan's comments and
  more testing

- Just remove ohci-omap3 as it needs LS/FS USB PHY not available
  on most hardware

Tony Lindgren (3):
  usb: host: ohci-platform: Add basic runtime PM support
  usb: host: ohci-platform: Add support for omap3 and later
  usb: host: ohci-omap3: Remove driver in favor of ohci-platform

 Documentation/devicetree/bindings/usb/usb-ohci.txt |   1 +
 drivers/usb/host/Kconfig   |   6 +-
 drivers/usb/host/Makefile  |   1 -
 drivers/usb/host/ohci-omap3.c  | 211 -
 drivers/usb/host/ohci-platform.c   |  22 ++-
 5 files changed, 27 insertions(+), 214 deletions(-)
 delete mode 100644 drivers/usb/host/ohci-omap3.c

-- 
2.13.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] usb: host: ohci-platform: Add basic runtime PM support

[Tony Lindgren]

This is needed in preparation of adding support for omap3 and
later OHCI. The runtime PM will only do something on platforms
that implement it.

Cc: devicet...@vger.kernel.org
Cc: Hans de Goede <hdego...@redhat.com>
Cc: Rob Herring <r...@kernel.org>
Cc: Roger Quadros <rog...@ti.com>
Cc: Sebastian Reichel <sebastian.reic...@collabora.co.uk>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
Signed-off-by: Tony Lindgren <t...@atomide.com>
---

Alan, do you have some better ideas for the ohci_platform_remove()
path below?

---
 drivers/usb/host/ohci-platform.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -242,6 +243,8 @@ static int ohci_platform_probe(struct platform_device *dev)
}
 #endif
 
+   pm_runtime_set_active(>dev);
+   pm_runtime_enable(>dev);
if (pdata->power_on) {
err = pdata->power_on(dev);
if (err < 0)
@@ -271,6 +274,7 @@ static int ohci_platform_probe(struct platform_device *dev)
if (pdata->power_off)
pdata->power_off(dev);
 err_reset:
+   pm_runtime_disable(>dev);
while (--rst >= 0)
reset_control_assert(priv->resets[rst]);
 err_put_clks:
@@ -290,7 +294,14 @@ static int ohci_platform_remove(struct platform_device 
*dev)
struct usb_hcd *hcd = platform_get_drvdata(dev);
struct usb_ohci_pdata *pdata = dev_get_platdata(>dev);
struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
-   int clk, rst;
+   int clk, rst, enabled;
+
+   enabled = pm_runtime_get_sync(>dev);
+   if (enabled < 0) {
+   dev_warn(>dev, "pm_runtime_get failed: %i\n",
+enabled);
+   pm_runtime_put_noidle(>dev);
+   }
 
usb_remove_hcd(hcd);
 
@@ -305,6 +316,10 @@ static int ohci_platform_remove(struct platform_device 
*dev)
 
usb_put_hcd(hcd);
 
+   if (enabled >= 0)
+   pm_runtime_put_sync(>dev);
+   pm_runtime_disable(>dev);
+
if (pdata == _platform_defaults)
dev->dev.platform_data = NULL;
 
-- 
2.13.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] usb: host: ohci-platform: Add support for omap3 and later

[Tony Lindgren]

With the runtime PM implemented for ohci-platform driver, we can
now support omap3 and later OHCI by adding one device tree
property.

Cc: Hans de Goede <hdego...@redhat.com>
Cc: Rob Herring <r...@kernel.org>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
Cc: Sebastian Reichel <sebastian.reic...@collabora.co.uk>
Acked-by: Alan Stern <st...@rowland.harvard.edu>
Acked-by: Roger Quadros <rog...@ti.com>
Signed-off-by: Tony Lindgren <t...@atomide.com>
---
 Documentation/devicetree/bindings/usb/usb-ohci.txt | 1 +
 drivers/usb/host/ohci-platform.c   | 5 +
 2 files changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/usb-ohci.txt 
b/Documentation/devicetree/bindings/usb/usb-ohci.txt
--- a/Documentation/devicetree/bindings/usb/usb-ohci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ohci.txt
@@ -10,6 +10,7 @@ Optional properties:
 - big-endian-desc : boolean, set this for hcds with big-endian descriptors
 - big-endian : boolean, for hcds with big-endian-regs + big-endian-desc
 - no-big-frame-no : boolean, set if frame_no lives in bits [15:0] of HCCA
+- remote-wakeup-connected: remote wakeup is wired on the platform
 - num-ports : u32, to override the detected port count
 - clocks : a list of phandle + clock specifier pairs
 - phys : phandle + phy specifier pair
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -164,6 +164,10 @@ static int ohci_platform_probe(struct platform_device *dev)
if (of_property_read_bool(dev->dev.of_node, "no-big-frame-no"))
ohci->flags |= OHCI_QUIRK_FRAME_NO;
 
+   if (of_property_read_bool(dev->dev.of_node,
+ "remote-wakeup-connected"))
+   ohci->hc_control = OHCI_CTRL_RWC;
+
of_property_read_u32(dev->dev.of_node, "num-ports",
 >num_ports);
 
@@ -365,6 +369,7 @@ static int ohci_platform_resume(struct device *dev)
 static const struct of_device_id ohci_platform_ids[] = {
{ .compatible = "generic-ohci", },
{ .compatible = "cavium,octeon-6335-ohci", },
+   { .compatible = "ti,ohci-omap3", },
{ }
 };
 MODULE_DEVICE_TABLE(of, ohci_platform_ids);
-- 
2.13.0
--
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/3] usb: host: ohci-omap3: Remove driver in favor of ohci-platform

[Tony Lindgren]

This driver is no longer needed and can be removed. The reason why
it's safe to remove this driver is that most omap devices don't have a
USB low-speed or full-speed compatible PHY installed and configured
with drivers/mfd/omap-usb-host.c. This means that devices like
beagleboard and pandaboard need to use a high-speed USB hub in order
to use devices like keyboard and mice.

Currently the only known configured for a full-speed PHY is the
mdm6600 modem on droid 4 and I've verified it works just fine with
ohci-platform.

Cc: Roger Quadros <rog...@ti.com>
Cc: Sebastian Reichel <sebastian.reic...@collabora.co.uk>
Signed-off-by: Tony Lindgren <t...@atomide.com>
---
 drivers/usb/host/Kconfig  |   6 +-
 drivers/usb/host/Makefile |   1 -
 drivers/usb/host/ohci-omap3.c | 211 --
 3 files changed, 5 insertions(+), 213 deletions(-)
 delete mode 100644 drivers/usb/host/ohci-omap3.c

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -473,8 +473,12 @@ config USB_OHCI_HCD_AT91
 config USB_OHCI_HCD_OMAP3
tristate "OHCI support for OMAP3 and later chips"
depends on (ARCH_OMAP3 || ARCH_OMAP4 || SOC_OMAP5)
+   select USB_OHCI_HCD_PLATFORM
default y
-   ---help---
+   help
+ This option is deprecated now and the driver was removed, use
+ USB_OHCI_HCD_PLATFORM instead.
+
  Enables support for the on-chip OHCI controller on
  OMAP3 and later chips.
 
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -52,7 +52,6 @@ obj-$(CONFIG_USB_OHCI_HCD_PCI)+= ohci-pci.o
 obj-$(CONFIG_USB_OHCI_HCD_PLATFORM)+= ohci-platform.o
 obj-$(CONFIG_USB_OHCI_EXYNOS)  += ohci-exynos.o
 obj-$(CONFIG_USB_OHCI_HCD_OMAP1)   += ohci-omap.o
-obj-$(CONFIG_USB_OHCI_HCD_OMAP3)   += ohci-omap3.o
 obj-$(CONFIG_USB_OHCI_HCD_SPEAR)   += ohci-spear.o
 obj-$(CONFIG_USB_OHCI_HCD_STI) += ohci-st.o
 obj-$(CONFIG_USB_OHCI_HCD_AT91)+= ohci-at91.o
diff --git a/drivers/usb/host/ohci-omap3.c b/drivers/usb/host/ohci-omap3.c
deleted file mode 100644
--- a/drivers/usb/host/ohci-omap3.c
+++ /dev/null
@@ -1,211 +0,0 @@
-/*
- * ohci-omap3.c - driver for OHCI on OMAP3 and later processors
- *
- * Bus Glue for OMAP3 USBHOST 3 port OHCI controller
- * This controller is also used in later OMAPs and AM35x chips
- *
- * Copyright (C) 2007-2010 Texas Instruments, Inc.
- * Author: Vikram Pandita <vikram.pand...@ti.com>
- * Author: Anand Gadiyar <gadi...@ti.com>
- * Author: Keshava Munegowda <keshava_mgo...@ti.com>
- *
- * Based on ehci-omap.c and some other ohci glue layers
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
- *
- * TODO (last updated Feb 27, 2011):
- * - add kernel-doc
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "ohci.h"
-
-#define DRIVER_DESC "OHCI OMAP3 driver"
-
-static const char hcd_name[] = "ohci-omap3";
-static struct hc_driver __read_mostly ohci_omap3_hc_driver;
-
-/*
- * configure so an HC device and id are always provided
- * always called with process context; sleeping is OK
- */
-
-/**
- * ohci_hcd_omap3_probe - initialize OMAP-based HCDs
- *
- * Allocates basic resources for this USB host controller, and
- * then invokes the start() method for the HCD associated with it
- * through the hotplug entry's driver_data.
- */
-static int ohci_hcd_omap3_probe(struct platform_device *pdev)
-{
-   struct device   *dev = >dev;
-   struct ohci_hcd *ohci;
-   struct usb_hcd  *hcd = NULL;
-   void __iomem*regs = NULL;
-   struct resource *res;
-   int ret;
-   int irq;
-
-   if (usb_disabled())
-   return -ENODEV;
-
-   if (!dev->parent) {
-   dev_err(dev, "Missing parent device\n");
-   return -ENODEV;
-   }
-
-   irq = platform_get_irq(pdev, 0);
-   if (irq < 0) {
-   dev_err(dev, "OHCI irq failed\n");
-   r

Re: [PATCH 1/4] usb: host: ohci-platform: Add basic runtime PM support

[Tony Lindgren]

* Alan Stern <st...@rowland.harvard.edu> [170518 10:24]:
> On Wed, 17 May 2017, Tony Lindgren wrote:
> 
> > This is needed in preparation of adding support for omap3 and
> > later OHCI. The runtime PM will only do something on platforms
> > that implement it.
> 
> > @@ -51,6 +52,10 @@ static int ohci_platform_power_on(struct platform_device 
> > *dev)
> > struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
> > int clk, ret, phy_num;
> >  
> > +   ret = pm_runtime_get_sync(>dev);
> > +   if (ret < 0)
> > +   return ret;
> > +
> 
> I don't remember how probing for platform device drivers is set up.
> So although this is definitely the wrong place for 
> pm_runtime_get_sync(), it may turn out that you need to do a 
> pm_runtime_get_noresume() before calling pm_runtime_enable(), and a 
> pm_runtime_put() at the end of ohci_platform_probe().  Otherwise 
> runtime PM might kick in during the middle of the probe sequence -- not 
> what you want.

Just removing those parts seems to work for probing.

> Similarly, you may need pm_runtime_get_sync() at the start of 
> ohci_platform_remove() and pm_runtime_put_noidle() at the end.

Yup that I noticed that too trying to rmmod it with no devices
connected.

While testing I also saw once "external abort on non-linefetch":

(ohci_hub_status_data [ohci_hcd]) from []
(usb_hcd_poll_rh_status+0x3c/0x128 [usbcore])
(usb_hcd_poll_rh_status [usbcore]) from []
(call_timer_fn+0xb0/0x3f8)
(call_timer_fn) from [] (expire_timers+0xe4/0x220)
(expire_timers) from [] (run_timer_softirq+0x94/0x19c)
(run_timer_softirq) from [] (__do_softirq+0x140/0x570)

Also I'm still checking if legacy usb_phy vs phy needs handling.
So far it seems that no need to do anything because most devices
need a USB hub anyways unless they have USB serial transceiver
configured with drivers/mfd/omap-usb-host.c for LS/FS.

Regards,

Tony
--
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 3/4] usb: host: ohci-omap3: Print warning to get people to use ohci-platform

[Tony Lindgren]

* Sebastian Reichel <s...@kernel.org> [170518 10:25]:
> Hi,
> 
> On Thu, May 18, 2017 at 07:08:58AM -0700, Tony Lindgren wrote:
> > * Sebastian Reichel <s...@kernel.org> [170518 02:18]:
> > > On Wed, May 17, 2017 at 03:59:21PM -0700, Tony Lindgren wrote:
> > > > We can't just remove ohci-omap3 as that could make some people's
> > > > systems unusable for keyboard and mouse. Let's print a warning for
> > > > now, and then remove the driver in a year or so.
> > >
> > > I guess you could drop the driver and modify the Kconfig entry,
> > > so that it selects USB_OHCI_HCD_PLATFORM? I just checked and
> > > there are already a few examples of this in the USB host Kconfig :)
> > 
> > Right but there's still nothing telling people to load ohci-platform
> > instead of ohci-omap3 if we just remove ohci-omap3 without any warnings.
> 
> Shouldn't the driver be loaded automatically due to the DT
> compatible value?

Doesn't that depend on a collection of user space software of
varying quality and usability? :)

But I think we can actually ohci-omap3 once the issues are sorted
out. That's because for OHCI omaps need an OHCI PHY. In most cases
there is just EHCI PHY and an external hub is needed. I'll do some
more testing.

Regards,

Tony
--
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 1/4] usb: host: ohci-platform: Add basic runtime PM support

[Tony Lindgren]

* Alan Stern <st...@rowland.harvard.edu> [170518 08:28]:
> On Wed, 17 May 2017, Tony Lindgren wrote:
> 
> > This is needed in preparation of adding support for omap3 and
> > later OHCI. The runtime PM will only do something on platforms
> > that implement it.
> 
> This patch isn't correct.  See below.
> 
> > Cc: devicet...@vger.kernel.org
> > Cc: Hans de Goede <hdego...@redhat.com>
> > Cc: Rob Herring <r...@kernel.org>
> > Cc: Roger Quadros <rog...@ti.com>
> > Cc: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
> > Signed-off-by: Tony Lindgren <t...@atomide.com>
> > ---
> >  drivers/usb/host/ohci-platform.c | 11 +++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/drivers/usb/host/ohci-platform.c 
> > b/drivers/usb/host/ohci-platform.c
> > --- a/drivers/usb/host/ohci-platform.c
> > +++ b/drivers/usb/host/ohci-platform.c
> > @@ -24,6 +24,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -51,6 +52,10 @@ static int ohci_platform_power_on(struct platform_device 
> > *dev)
> > struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
> > int clk, ret, phy_num;
> >  
> > +   ret = pm_runtime_get_sync(>dev);
> > +   if (ret < 0)
> > +   return ret;
> > +
> > for (clk = 0; clk < OHCI_MAX_CLKS && priv->clks[clk]; clk++) {
> > ret = clk_prepare_enable(priv->clks[clk]);
> > if (ret)
> > @@ -96,6 +101,8 @@ static void ohci_platform_power_off(struct 
> > platform_device *dev)
> > for (clk = OHCI_MAX_CLKS - 1; clk >= 0; clk--)
> > if (priv->clks[clk])
> > clk_disable_unprepare(priv->clks[clk]);
> > +
> > +   pm_runtime_put_sync(>dev);
> >  }
> 
> ohci_platform_power_on() is invoked (by default) by the runtime-resume
> callback routine ohci_platform_resume(), through the pdata->power_on
> method pointer.  Likewise, ohci_platform_power_off() is invoked by the
> runtime-suspend callback routine.
> 
> This means you shouldn't do pm_runtime_get/put calls from within these 
> routines.

Oh OK great, so the above should not be needed at all.

> Is there any particular reason you wanted to add these calls?  In
> general, USB host controllers are expected to go into runtime suspend
> whenever there aren't any children keeping them awake.  Hence they
> usually don't need to worry about initiating their own suspends and
> resumes.

No particular reason as it sounds things work without it :) I'll check.

> >  static struct hc_driver __read_mostly ohci_platform_hc_driver;
> > @@ -242,6 +249,7 @@ static int ohci_platform_probe(struct platform_device 
> > *dev)
> > }
> >  #endif
> >  
> > +   pm_runtime_enable(>dev);
> 
> There should be a pm_runtime_set_active() just before this.

OK

> > if (pdata->power_on) {
> > err = pdata->power_on(dev);
> > if (err < 0)
> > @@ -271,6 +279,7 @@ static int ohci_platform_probe(struct platform_device 
> > *dev)
> > if (pdata->power_off)
> > pdata->power_off(dev);
> >  err_reset:
> > +   pm_runtime_disable(>dev);
> > while (--rst >= 0)
> > reset_control_assert(priv->resets[rst]);
> >  err_put_clks:
> > @@ -305,6 +314,8 @@ static int ohci_platform_remove(struct platform_device 
> > *dev)
> >  
> > usb_put_hcd(hcd);
> >  
> > +   pm_runtime_disable(>dev);
> > +
> > if (pdata == _platform_defaults)
> > dev->dev.platform_data = NULL;
> 
> These changes make sense.

OK thanks for looking.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] usb: host: ohci-platform: Add support for omap3 and later

[Tony Lindgren]

* Alan Stern <st...@rowland.harvard.edu> [170518 08:41]:
> On Wed, 17 May 2017, Tony Lindgren wrote:
> 
> > With the runtime PM implemented for ohci-platform driver, we can
> > now support omap3 and later OHCI by adding one device tree
> > property.
...
> > diff --git a/drivers/usb/host/ohci-platform.c 
> > b/drivers/usb/host/ohci-platform.c
> > --- a/drivers/usb/host/ohci-platform.c
> > +++ b/drivers/usb/host/ohci-platform.c
> > @@ -170,6 +170,10 @@ static int ohci_platform_probe(struct platform_device 
> > *dev)
> > if (of_property_read_bool(dev->dev.of_node, "no-big-frame-no"))
> > ohci->flags |= OHCI_QUIRK_FRAME_NO;
> >  
> > +   if (of_property_read_bool(dev->dev.of_node,
> > + "remote-wakeup-connected"))
> > +   ohci->hc_control = OHCI_CTRL_RWC;
> > +
> > of_property_read_u32(dev->dev.of_node, "num-ports",
> >  >num_ports);
> >  
> > @@ -361,6 +365,7 @@ static int ohci_platform_resume(struct device *dev)
> >  static const struct of_device_id ohci_platform_ids[] = {
> > { .compatible = "generic-ohci", },
> > { .compatible = "cavium,octeon-6335-ohci", },
> > +   { .compatible = "ti,ohci-omap3", },
> > { }
> >  };
> >  MODULE_DEVICE_TABLE(of, ohci_platform_ids);
> 
> Acked-by: Alan Stern <st...@rowland.harvard.edu>

FYI, this depends on the patch1/4 PM runtime issue getting sorted out
first as otherwise the USB controller is powered off on omaps. So let's
not apply this yet.

Regards,

Tony
--
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 3/4] usb: host: ohci-omap3: Print warning to get people to use ohci-platform

[Tony Lindgren]

* Sebastian Reichel <s...@kernel.org> [170518 02:18]:
> On Wed, May 17, 2017 at 03:59:21PM -0700, Tony Lindgren wrote:
> > We can't just remove ohci-omap3 as that could make some people's
> > systems unusable for keyboard and mouse. Let's print a warning for
> > now, and then remove the driver in a year or so.
>
> I guess you could drop the driver and modify the Kconfig entry,
> so that it selects USB_OHCI_HCD_PLATFORM? I just checked and
> there are already a few examples of this in the USB host Kconfig :)

Right but there's still nothing telling people to load ohci-platform
instead of ohci-omap3 if we just remove ohci-omap3 without any warnings.
I don't think there's any need to rush to remove ohci-omap3.

Regards,

Tony
--
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 0/4] Make ohci-platform usable for omap3/4/5

[Tony Lindgren]

Hi all,

Here are patches I promised several months ago so we can eventually
get rid of ohci-omap3 in favor of ohci-platform as suggested by
Alan Stern.

I think we need to wait a while before removing ohci-omap3, so
I just added a warning for now to urge people to move to use
ohci-platform instead.

Regards,

Tony

Tony Lindgren (4):
  usb: host: ohci-platform: Add basic runtime PM support
  usb: host: ohci-platform: Add support for omap3 and later
  usb: host: ohci-omap3: Print warning to get people to use
ohci-platform
  ARM: dts: Add remote-wakeup-connected for omap OHCI

 Documentation/devicetree/bindings/usb/usb-ohci.txt |  1 +
 arch/arm/boot/dts/omap3.dtsi   |  1 +
 arch/arm/boot/dts/omap4.dtsi   |  1 +
 arch/arm/boot/dts/omap5.dtsi   |  1 +
 drivers/usb/host/ohci-omap3.c  |  3 +++
 drivers/usb/host/ohci-platform.c   | 16 
 6 files changed, 23 insertions(+)

-- 
2.13.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/4] usb: host: ohci-platform: Add basic runtime PM support

[Tony Lindgren]

This is needed in preparation of adding support for omap3 and
later OHCI. The runtime PM will only do something on platforms
that implement it.

Cc: devicet...@vger.kernel.org
Cc: Hans de Goede <hdego...@redhat.com>
Cc: Rob Herring <r...@kernel.org>
Cc: Roger Quadros <rog...@ti.com>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
Signed-off-by: Tony Lindgren <t...@atomide.com>
---
 drivers/usb/host/ohci-platform.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -51,6 +52,10 @@ static int ohci_platform_power_on(struct platform_device 
*dev)
struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
int clk, ret, phy_num;
 
+   ret = pm_runtime_get_sync(>dev);
+   if (ret < 0)
+   return ret;
+
for (clk = 0; clk < OHCI_MAX_CLKS && priv->clks[clk]; clk++) {
ret = clk_prepare_enable(priv->clks[clk]);
if (ret)
@@ -96,6 +101,8 @@ static void ohci_platform_power_off(struct platform_device 
*dev)
for (clk = OHCI_MAX_CLKS - 1; clk >= 0; clk--)
if (priv->clks[clk])
clk_disable_unprepare(priv->clks[clk]);
+
+   pm_runtime_put_sync(>dev);
 }
 
 static struct hc_driver __read_mostly ohci_platform_hc_driver;
@@ -242,6 +249,7 @@ static int ohci_platform_probe(struct platform_device *dev)
}
 #endif
 
+   pm_runtime_enable(>dev);
if (pdata->power_on) {
err = pdata->power_on(dev);
if (err < 0)
@@ -271,6 +279,7 @@ static int ohci_platform_probe(struct platform_device *dev)
if (pdata->power_off)
pdata->power_off(dev);
 err_reset:
+   pm_runtime_disable(>dev);
while (--rst >= 0)
reset_control_assert(priv->resets[rst]);
 err_put_clks:
@@ -305,6 +314,8 @@ static int ohci_platform_remove(struct platform_device *dev)
 
usb_put_hcd(hcd);
 
+   pm_runtime_disable(>dev);
+
if (pdata == _platform_defaults)
dev->dev.platform_data = NULL;
 
-- 
2.13.0
--
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 4/4] ARM: dts: Add remote-wakeup-connected for omap OHCI

[Tony Lindgren]

Add remote-wakeup-connected for omap OHCI as that's needed by
ehci-platform driver.

Cc: devicet...@vger.kernel.org
Cc: Hans de Goede <hdego...@redhat.com>
Cc: Rob Herring <r...@kernel.org>
Cc: Roger Quadros <rog...@ti.com>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
Signed-off-by: Tony Lindgren <t...@atomide.com>
---
 arch/arm/boot/dts/omap3.dtsi | 1 +
 arch/arm/boot/dts/omap4.dtsi | 1 +
 arch/arm/boot/dts/omap5.dtsi | 1 +
 3 files changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -715,6 +715,7 @@
reg = <0x48064400 0x400>;
interrupt-parent = <>;
interrupts = <76>;
+   remote-wakeup-connected;
};
 
usbhsehci: ehci@48064800 {
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -863,6 +863,7 @@
reg = <0x4a064800 0x400>;
interrupt-parent = <>;
interrupts = ;
+   remote-wakeup-connected;
};
 
usbhsehci: ehci@4a064c00 {
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -939,6 +939,7 @@
compatible = "ti,ohci-omap3";
reg = <0x4a064800 0x400>;
interrupts = ;
+   remote-wakeup-connected;
};
 
usbhsehci: ehci@4a064c00 {
-- 
2.13.0
--
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/4] usb: host: ohci-omap3: Print warning to get people to use ohci-platform

[Tony Lindgren]

We can't just remove ohci-omap3 as that could make some people's
systems unusable for keyboard and mouse. Let's print a warning for
now, and then remove the driver in a year or so.

Cc: Hans de Goede <hdego...@redhat.com>
Cc: Rob Herring <r...@kernel.org>
Cc: Roger Quadros <rog...@ti.com>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
Signed-off-by: Tony Lindgren <t...@atomide.com>
---
 drivers/usb/host/ohci-omap3.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/host/ohci-omap3.c b/drivers/usb/host/ohci-omap3.c
--- a/drivers/usb/host/ohci-omap3.c
+++ b/drivers/usb/host/ohci-omap3.c
@@ -130,6 +130,9 @@ static int ohci_hcd_omap3_probe(struct platform_device 
*pdev)
dev_dbg(dev, "failed to add hcd with err %d\n", ret);
goto err_add_hcd;
}
+
+   WARN(1, "ohci-omap3 is deprecated, please use ohci-platform instead\n");
+
device_wakeup_enable(hcd->self.controller);
 
return 0;
-- 
2.13.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/4] usb: host: ohci-platform: Add support for omap3 and later

[Tony Lindgren]

With the runtime PM implemented for ohci-platform driver, we can
now support omap3 and later OHCI by adding one device tree
property.

Cc: Hans de Goede <hdego...@redhat.com>
Cc: Rob Herring <r...@kernel.org>
Cc: Roger Quadros <rog...@ti.com>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>
Signed-off-by: Tony Lindgren <t...@atomide.com>
---
 Documentation/devicetree/bindings/usb/usb-ohci.txt | 1 +
 drivers/usb/host/ohci-platform.c   | 5 +
 2 files changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/usb-ohci.txt 
b/Documentation/devicetree/bindings/usb/usb-ohci.txt
--- a/Documentation/devicetree/bindings/usb/usb-ohci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ohci.txt
@@ -10,6 +10,7 @@ Optional properties:
 - big-endian-desc : boolean, set this for hcds with big-endian descriptors
 - big-endian : boolean, for hcds with big-endian-regs + big-endian-desc
 - no-big-frame-no : boolean, set if frame_no lives in bits [15:0] of HCCA
+- remote-wakeup-connected: remote wakeup is wired on the platform
 - num-ports : u32, to override the detected port count
 - clocks : a list of phandle + clock specifier pairs
 - phys : phandle + phy specifier pair
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -170,6 +170,10 @@ static int ohci_platform_probe(struct platform_device *dev)
if (of_property_read_bool(dev->dev.of_node, "no-big-frame-no"))
ohci->flags |= OHCI_QUIRK_FRAME_NO;
 
+   if (of_property_read_bool(dev->dev.of_node,
+ "remote-wakeup-connected"))
+   ohci->hc_control = OHCI_CTRL_RWC;
+
of_property_read_u32(dev->dev.of_node, "num-ports",
 >num_ports);
 
@@ -361,6 +365,7 @@ static int ohci_platform_resume(struct device *dev)
 static const struct of_device_id ohci_platform_ids[] = {
{ .compatible = "generic-ohci", },
{ .compatible = "cavium,octeon-6335-ohci", },
+   { .compatible = "ti,ohci-omap3", },
{ }
 };
 MODULE_DEVICE_TABLE(of, ohci_platform_ids);
-- 
2.13.0
--
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: ohci: Allow ohci on omap5 also

[Tony Lindgren]

Hi,

* Tony Lindgren <t...@atomide.com> [160913 15:48]:
> * Alan Stern <st...@rowland.harvard.edu> [160910 19:27]:
> > On Fri, 9 Sep 2016, Alan Stern wrote:
> > 
> > > On Fri, 9 Sep 2016, Tony Lindgren wrote:
> > > 
> > > > * Alan Stern <st...@rowland.harvard.edu> [160909 13:41]:
> > > > > On Fri, 9 Sep 2016, Tony Lindgren wrote:
> > > > > 
> > > > > > * Alan Stern <st...@rowland.harvard.edu> [160909 12:47]:
> > > > > > > You know, as far as I can tell the only thing that is 
> > > > > > > OMAP-specific
> > > > > > > about the ohci-omap3 driver is the initialization of 
> > > > > > > OHCI_CTRL_RWC.  
> > > > > > > This could be added to the platform data or the DT bindings, after
> > > > > > > which this driver wouldn't be needed at all -- the ohci_platform 
> > > > > > > driver
> > > > > > > would work.  Does this seem reasonable?
> > > > > > 
> > > > > > Sure makes sense to me. Do we have some standard binding for
> > > > > > OCHI_CTRL_RWC?
> > > > > 
> > > > > No, one would have to be created.
> > > > 
> > > > OK I can do a patch for that, what should be binding be?
> > > > 
> > > > ohci-ctrl-rwc-something?
> > > 
> > > OHCI_CTRL_RWC is just a single-bit flag; the RWC part stands for
> > > "Remote Wakeup Control".
> > 
> > Sorry, careless mistake on my part.  It actually stands for "Remote 
> > Wakeup Connected"; meaning that the remote-wakeup output signal from 
> > the controller is connected to something really can wake up the system.
> > This is exactly the sort of hardware implementation detail that the 
> > firmware is supposed to know.
> 
> OK thanks. I think it can be set up as a generic wakeirq.

Sorry for the slowness on this one, I have not forgotten about this.
I now do have a nice testcase of a modem on the ohci bus I can test
with :)

Also looks we can pretty easily support GPIO wake-up events some
integrated USB devices have with the Linux generic wakeirqs. I did
some testing with that and the only question really is where to
configure it. For my tests, I just patched it into bin/unbind in
drivers/net/usb/cdc_ether.c, but I think it can be generic to all
USB devices.

Anyways, patches coming at some point, might take a while though.

Regards,

Tony
--
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-musb: keep VBUS on when device is disconnected

[Tony Lindgren]

* Bin Liu <b-...@ti.com> [170512 10:43]:
> On Fri, May 12, 2017 at 10:21:35AM -0700, Tony Lindgren wrote:
> > * Bin Liu <b-...@ti.com> [170512 08:24]:
> > > On Fri, May 12, 2017 at 07:58:49AM -0700, Tony Lindgren wrote:
> > > > OK. No better ideas except I think we should probably have a separate
> > > > timer for keeping VBUS on after state changes eventually.
> > > 
> > > Currently with the patch below, VBUS is constantly on for host-only
> > > mode, and this is what we want. Why we need a separate timer? No one
> > > cuts VBUs now for host-only mode.
> > 
> > Oh I was just thinking what we might want to do in the future if
> > we want to cut off VBUS when no devices are connected. If we have
> 
> Okay, I see. But I don't think we will ever want to turn off VBUS when
> no devices attached for host-only mode. Any other controllers do this?
> 
> Turning off VBUS doesn't save us much, because it comes from an external
> power rail, and no one consumes it when no devices are attached.
> 
> I believe keeping the controller idle as what we have now is sufficient.

OK fine with me.

Regards,

Tony
--
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-musb: keep VBUS on when device is disconnected

[Tony Lindgren]

* Bin Liu <b-...@ti.com> [170512 08:24]:
> On Fri, May 12, 2017 at 07:58:49AM -0700, Tony Lindgren wrote:
> > OK. No better ideas except I think we should probably have a separate
> > timer for keeping VBUS on after state changes eventually.
> 
> Currently with the patch below, VBUS is constantly on for host-only
> mode, and this is what we want. Why we need a separate timer? No one
> cuts VBUs now for host-only mode.

Oh I was just thinking what we might want to do in the future if
we want to cut off VBUS when no devices are connected. If we have
a USB modem for example it might first enumerate as some boot device,
then nothing for 20 seconds while it's booting, and then we have a
different device enumerating after the modem has booted. During this
period we want to keep VBUS on and will go through multiple
OTG_STATE_A_WAIT_BCON states. So we can't really control VBUS using
the OTG_STATE_WHATEVER alone.

Regards,

Tony
--
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-musb: keep VBUS on when device is disconnected

[Tony Lindgren]

* Bin Liu <b-...@ti.com> [170512 06:43]:
> On Thu, May 11, 2017 at 02:06:28PM -0700, Tony Lindgren wrote:
> > 
> > Well maybe the minimal fix for now is just pretty much back to
> > square one of this thread. This should keep VBUS always on.
> > Then we can figure out some logic to cut VBUS later on.
> > 
> > And yeah, the state machine is really hard to follow so some kind
> > of clean up would be nice.
> 
> Okay, figured out why clearing session in OTG_STATE_A_WAIT_BCON, it is
> not for error condition handling (which is done in musb-core), but for
> going back to b_idle state from a_host for dual-role mode. otg_timer()
> (now is dsps_check_status()) was only called for otg port originally, so
> it wasn't an issue, until started calling it for host mode as well when
> runtime PM was added.

OK makes sense.

> > 8< ---
> > --- a/drivers/usb/musb/musb_dsps.c
> > +++ b/drivers/usb/musb/musb_dsps.c
> > @@ -245,7 +245,6 @@ static int dsps_check_status(struct musb *musb, void 
> > *unused)
> > dsps_mod_timer_optional(glue);
> > break;
> > case OTG_STATE_A_WAIT_BCON:
> > -   musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
> > skip_session = 1;
> > /* fall */
> >  
> 
> So the above patch breaks otg port when switching from host to device
> mode. The following change should solve it. But Tony do you see any way
> to improve it with glue->vbus_irq?

OK. No better ideas except I think we should probably have a separate
timer for keeping VBUS on after state changes eventually.

I guess the real test here would be to connect a USB modem that
changes state to the am335x-evm OTG port and make sure it works
with commit similar to d680414d0f42 ("ARM: dts: Configure BeagleBone
peripheral USB VBUS irq"). And also without configuring the vusb_irq.

For the patch below, seems like the way to go for the fix assuming
it fixes the $subject issue:

Acked-by: Tony Lindgren <t...@atomide.com>

> 8< 
> diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
> index 9c7ee26ef388..465281244596 100644
> --- a/drivers/usb/musb/musb_dsps.c
> +++ b/drivers/usb/musb/musb_dsps.c
> @@ -245,9 +245,14 @@ static int dsps_check_status(struct musb *musb, void 
> *unused)
> dsps_mod_timer_optional(glue);
> break;
> case OTG_STATE_A_WAIT_BCON:
> +   /* keep VBUS on for host-only mode */
> +   if (musb->port_mode == MUSB_PORT_MODE_HOST) {
> +   dsps_mod_timer_optional(glue);
> +   break;
> +   }
> musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
> skip_session = 1;
> -   /* fall */
> +   /* fall through */
>  
> case OTG_STATE_A_IDLE:
> case OTG_STATE_B_IDLE:
--
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-musb: keep VBUS on when device is disconnected

[Tony Lindgren]

* Bin Liu <b-...@ti.com> [170511 13:47]:
> On Thu, May 11, 2017 at 01:23:06PM -0700, Tony Lindgren wrote:
> > 
> > Maybe try something like below, compile tested only. I don't
> > think I have any USB modem here to test with.
> 
> The patch below doesn't help. In device detach by the time
> dsps_check_status() is called, the otg state is already A_WAIT_BCON, set
> by musb_root_disconnect() in musb_stage0_irq() when handling DISCONNECT
> interrupt.

Oh OK.

> I don't think it is about how long the modem disappears. When detach happens,
> DISCONNECT interrupt happens, then dsps_check_status() is scheduled with
> state A_WAIT_BCON, then VBUS got cut.
> 
> BTY, I didn't debug with a modem, just with a device detach. Tring to
> see how to not cut vbus at all in dsps_check_status().

OK

> > It's also possible that we have dsps_check_status() getting called
> > again on disconnect before the new 20 second period is over, I did
> > not check for that yet.
> 
> After a few trials, I start to think about a little cleanup in the otg
> state machine in the musb drivers, I think we need to somehow
> distinguish between normal and error conditions for A_WAIT_BCON state.

Well maybe the minimal fix for now is just pretty much back to
square one of this thread. This should keep VBUS always on.
Then we can figure out some logic to cut VBUS later on.

And yeah, the state machine is really hard to follow so some kind
of clean up would be nice.

Regards,

Tony

8< ---
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -245,7 +245,6 @@ static int dsps_check_status(struct musb *musb, void 
*unused)
dsps_mod_timer_optional(glue);
break;
case OTG_STATE_A_WAIT_BCON:
-   musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
skip_session = 1;
/* fall */
 
--
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-musb: keep VBUS on when device is disconnected

[Tony Lindgren]

* Tony Lindgren <t...@atomide.com> [170511 13:26]:
> diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
> --- a/drivers/usb/musb/musb_dsps.c
> +++ b/drivers/usb/musb/musb_dsps.c
> @@ -270,6 +270,10 @@ static int dsps_check_status(struct musb *musb, void 
> *unused)
>   musb_writel(musb->ctrl_base, wrp->coreintr_set,
>   MUSB_INTR_VBUSERROR << wrp->usb_shift);
>   break;
> + case OTG_STATE_A_HOST:
> + if (glue->vbus_irq)
> + dsps_mod_timer(glue, 2);/* 20s */
> + break;
>   default:
>   break;
>   }
> -- 

Heh that's the wrong way around.. I think we can leave out the check
for vbus_irq.

8< ---
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -270,6 +270,10 @@ static int dsps_check_status(struct musb *musb, void 
*unused)
musb_writel(musb->ctrl_base, wrp->coreintr_set,
MUSB_INTR_VBUSERROR << wrp->usb_shift);
break;
+   case OTG_STATE_A_HOST:
+   /* Keep VBUS on after disconnect for 20 seconds */
+   dsps_mod_timer(glue, 2);
+   break;
default:
break;
}
-- 
2.13.0
--
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-musb: keep VBUS on when device is disconnected

[Tony Lindgren]

* Bin Liu <b-...@ti.com> [170511 13:05]:
> On Thu, May 11, 2017 at 12:38:11PM -0700, Tony Lindgren wrote:
> > 
> > I wonder if just keeping VBUS on longer in OTG_STATE_A_WAIT_BCON
> > solves this issue?
> 
> We don't cut VBUS intentionally for host mode (when devctl=0x19). The
> VBUS got cut in this case only because when a device is detached, the
> otg state changes from A_HOST -> A_WAIT_BCON, then otg_timer() cuts VBUS
> and sets the state to A_IDLE, then next otg_timer() turns on VBUS (I
> haven't check how the otg state becomes A_WAIT_VRISE from here).
> 
> Not sure how to *easily* keep VBUS here, without adding condition check
> in otg_timer() for TG_STATE_A_WAIT_BCON.
> 
> > solves this issue? It seems the issue is with modems that get
> > reconfigured after the initial enumeration?
> 
> Idealy we shouldn't cut VBUS at all in this case for host-only. I am
> looking for a small patch to solve this, if possilbe ;)

Maybe try something like below, compile tested only. I don't
think I have any USB modem here to test with.

> > We could poll for new devices every 2 seconds, if anything is seen
> > on the bus, keep VBUS on at least 20 seconds, then if nothing is
> > found, poll every 2 seconds again.
> 
> I am not sure this is relevant, VBUS is constantly on once the otg stage
> becomes A_HOST -> A_WAIT_BCON -> A_IDLE -> A_WAIT_VRISE, within a
> second.

Yup, but it sounds like once the modem changes mode, it disappears
from the USB bus for a long enough time where we go to A_WAIT_BCON
again. Or else I'm misunderstanding what's going on.

It's also possible that we have dsps_check_status() getting called
again on disconnect before the new 20 second period is over, I did
not check for that yet.

Regards,

Tony

8< ---
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -270,6 +270,10 @@ static int dsps_check_status(struct musb *musb, void 
*unused)
musb_writel(musb->ctrl_base, wrp->coreintr_set,
MUSB_INTR_VBUSERROR << wrp->usb_shift);
break;
+   case OTG_STATE_A_HOST:
+   if (glue->vbus_irq)
+   dsps_mod_timer(glue, 2);/* 20s */
+   break;
default:
break;
}
-- 
2.13.0
--
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-musb: keep VBUS on when device is disconnected

[Tony Lindgren]

* Bin Liu  [170511 12:23]:
> On Thu, May 11, 2017 at 02:10:05PM -0500, Bin Liu wrote:
> [...]
> > > > > The otg state machine implementation in the musb drivers are kind of 
> > > > > strange.
> > > > > OTG_STATE_A_WAIT_BCON suppose to be a steady state when no usb device 
> > > > > is
> > > > > attached, but the musb drivers use it as a transient state to handle 
> > > > > error
> > > > > cases, such as overcurrent ot HNP timeout, which is done in the 'case
> > > > > OTG_STATE_A_WAIT_BCON' branch in otg_timer() (or dsps_check_status() 
> > > > > for dsps
> > > > > glue).
> > > > > 
> > > > > Then later when 2f3fd2c5bde1 adds
> > > > > 
> > > > > -   /* Poll for ID change in OTG port mode */
> > > > > -   if (musb->xceiv->otg->state == OTG_STATE_B_IDLE &&
> > > > > -   musb->port_mode == MUSB_PORT_MODE_DUAL_ROLE)
> > > > > +   /* Poll for ID change and connect */
> > > > > +   switch (musb->xceiv->otg->state) {
> > > > > +   case OTG_STATE_B_IDLE:
> > > > > +   case OTG_STATE_A_WAIT_BCON:
> > > > > mod_timer(>timer, jiffies +
> > > > > msecs_to_jiffies(wrp->poll_timeout));
> > > > > +   break;
> > > > > 
> > > > > which causes dsps_check_status (or otg_timer()) got called for a 
> > > > > normal
> > > > > condition with OTG_STATE_A_WAIT_BCON, then turns off VBUS...
> > > > > 
> > > > > Will try to see how to solve this...
> > > > 
> > > > Maybe we just need to add back the earlier check for non-OTG devices
> > > > "musb->port_mode == MUSB_PORT_MODE_DUAL_ROLE" into case
> > > > OTG_STATE_A_WAIT_BCON?
> > > 
> > > Not sure if it will work. The check is to kick out device-only mode.
> > > DUAL_ROLE means both OTG and host-only.
> > > 
> > > > 
> > > > Not sure if am335x configured with host port ever idle that way,
> > > > but maybe VBUS can be kept on with musb idle.
> > > 
> > > Just tried to remove 
> > > 
> > > +   case OTG_STATE_A_WAIT_BCON:
> > > 
> > > for the polling, but the port stops detecting device attach, musb
> > > power/devctl registers are good, trying to see why... maybe related to
> > > PM state?
> > 
> > usb_otg_hs is idle, so not able to detect attach. So need to get the
> > timer rolling in here to make it detect working.
> > Maybe need to add a flag in dsps_check_status() to not turn off vbus in
> > this case? Really don't like the idea...

Yeah that's what I recall too. The timer is needed until the m3 can
implement an irqchip and we can set that up as the irq for the host
only port.

> I am not sure I gave out the picture clearly.
> 
> Before added the runtime PM support, in host mode (devctl=0x19) the
> otg_timer is stopped, the controller is ready to detect attach.
> 
> Later when added the runtime PM support, usb_otg_hs hwmod becomes idle
> when a device is detached, so the otg_timer is needed to keep hwmod
> enable/idle periodically to detect attach, which triggers the issue
> because otg_timer() turns off vbus unconditionally when otg state is
> OTG_STATE_A_WAIT_BCON.

I wonder if just keeping VBUS on longer in OTG_STATE_A_WAIT_BCON
solves this issue? It seems the issue is with modems that get
reconfigured after the initial enumeration?

We could poll for new devices every 2 seconds, if anything is seen
on the bus, keep VBUS on at least 20 seconds, then if nothing is
found, poll every 2 seconds again.

Regards,

Tony
--
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-musb: keep VBUS on when device is disconnected

[Tony Lindgren]

* Bin Liu <b-...@ti.com> [170511 11:53]:
> On Mon, Mar 27, 2017 at 10:55:37AM -0700, Tony Lindgren wrote:
> > * Bin Liu <b-...@ti.com> [170327 10:17]:
> > > On Mon, Mar 27, 2017 at 09:59:47AM -0700, Tony Lindgren wrote:
> > > > * Moreno Bartalucci <moreno.bartalu...@tecnorama.it> [170327 09:23]:
> > > > > If I understood your patch, however, if the device (anyone, not just 
> > > > > my one) takes longer to switch, VBUS is deasserted anyway.
> > > > 
> > > > Yeah some of them can take at least 10 seconds even to enumerate.
> > > > So probably we need to have to have some longer timeout set for
> > > > OTG_STATE_A_WAIT_BCON, like 20 or 30 seconds.
> > > > 
> > > > > Although this patch is working for me, personally I would prefer a 
> > > > > solution which would not deassert VBUS. At least on a host only port. 
> > > > > Honestly I don’t know how a dual role port should work.
> > > > 
> > > > It's been really long time since I read the OTG spec. There
> > > > may be some diagram showing the required timeouts in the spec
> > > > if there is one for VBUS.
> > > > 
> > > > Maybe we need some property to specify vbus-always-on-in-host-mode?
> > > 
> > > The MUSB otg state machine has been changed in many place since the last
> > > time I looked at it, and I am not sure how exactly it works now.
> > 
> > Yup.. I looked up the timers in the OTG spec and they are described
> > in chapter "8.5.5.2" as a_wait_bcon_tmo or a_wait_bcon_tmr. But
> > I could not find any values for them.
> > 
> > Anyways, clearly we want things working with real devices :)
> > 
> > > If the $subject patch can correctly keep the VBUS on for host-only mode,
> > > we can somehow use dr_modei value to distinguish the mode. We don't have
> > > to create a new vbus-always-on-in-host-mode flag. VBUS has to be always
> > > on in host-only mode anyway, until some error condition happens.
> > 
> > Yeh and it seems PM still works with the $subject patch also for
> > host mode. So maybe that's enough to fix the issue.
> > 
> > Also I don't have any idea why for ages we have been writing
> > 0 to devctl there.. Maybe we've had a bug there that only now
> > shows up when we idle things.
> 
> The otg state machine implementation in the musb drivers are kind of strange.
> OTG_STATE_A_WAIT_BCON suppose to be a steady state when no usb device is
> attached, but the musb drivers use it as a transient state to handle error
> cases, such as overcurrent ot HNP timeout, which is done in the 'case
> OTG_STATE_A_WAIT_BCON' branch in otg_timer() (or dsps_check_status() for dsps
> glue).
> 
> Then later when 2f3fd2c5bde1 adds
> 
> -   /* Poll for ID change in OTG port mode */
> -   if (musb->xceiv->otg->state == OTG_STATE_B_IDLE &&
> -   musb->port_mode == MUSB_PORT_MODE_DUAL_ROLE)
> +   /* Poll for ID change and connect */
> +   switch (musb->xceiv->otg->state) {
> +   case OTG_STATE_B_IDLE:
> +   case OTG_STATE_A_WAIT_BCON:
> mod_timer(>timer, jiffies +
> msecs_to_jiffies(wrp->poll_timeout));
> +   break;
> 
> which causes dsps_check_status (or otg_timer()) got called for a normal
> condition with OTG_STATE_A_WAIT_BCON, then turns off VBUS...
> 
> Will try to see how to solve this...

Maybe we just need to add back the earlier check for non-OTG devices
"musb->port_mode == MUSB_PORT_MODE_DUAL_ROLE" into case
OTG_STATE_A_WAIT_BCON?

Not sure if am335x configured with host port ever idle that way,
but maybe VBUS can be kept on with musb idle.

Regards,

Tony
--
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 00/10] usb: musb: tusb6010_omap: Convert to DMAengine

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfal...@ti.com> [170510 01:45]:
> The device would not boot to prompt most of the time before patch 5 (packet 
> size
> reset fix).
> With that patch in, the device would boot up fine most of the cases, but will
> fail pretty fast with my stress test [1].
> After the first 9 patch the legacy DMA mode is going to be stable with g_ncm, 
> it
> boots to prompt, and survives the stress test [1].

Best to merge that as a separate fix.

I already replied with acks to few patches, and for the entire
series please feel free to add:

Tested-by: Tony Lindgren <t...@atomide.com>
--
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 09/10] ARM: OMAP2+: DMA: Add slave map entries for 24xx external request lines

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfal...@ti.com> [170510 01:46]:
> The external request lines are used by tusb6010 on OMAP24xx platforms.
> Update the map so the driver can use dmaengine API to request the DMA
> channel. At the same time add temporary map containing only the external
> DMA request numbers for DT booted case on omap24xx since the tusb6010 stack
> is not yet supports DT boot.
> 
> Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>

Best to merge this together with the series:

Acked-by: Tony Lindgren <t...@atomide.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/10] usb: musb: tusb6010_omap: Do not reset the other direction's packet size

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfal...@ti.com> [170510 01:45]:
> We have one register for each EP to set the maximum packet size for both
> TX and RX.
> If for example an RX programming would happen before the previous TX
> transfer finishes we would reset the TX packet side.
> 
> To fix this issue, only modify the TX or RX part of the register.

Oh this is a nice one. I think we've always had this.

Bin, care to merge this one as a fix? This should have:

Fixes: 550a7375fe72 ("USB: Add MUSB and TUSB support")
Tested-by: Tony Lindgren <t...@atomide.com>
--
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 01/10] dmaengine: omap-dma: port_window support correction for both direction

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfal...@ti.com> [170510 01:45]:
> When the port_window support was verified it was done on setup where only
> the MEM_TO_DEV direction was enabled. This got un-noticed and thus only
> this direction worked.
> 
> Now that I have managed to get a setup to verify both direction it turned
> out that the setup was incorrect:
> omap_desc members are settings for the slave port while the omap_sg members
> apply to the memory side of the sDMA setup.
> 
> Fixes: 527a27591312 ("dmaengine: omap-dma: Fix the port_window support")
> Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
> Cc: Russell King <li...@armlinux.org.uk>
> Cc: dmaeng...@vger.kernel.org
> Cc: dan.j.willi...@intel.com
> Cc: vinod.k...@intel.com

Tested-by: Tony Lindgren <t...@atomide.com>
--
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: [PATCHv3] phy: cpcap-usb: Add CPCAP PMIC USB support

[Tony Lindgren]

* Kishon Vijay Abraham I <kis...@ti.com> [170507 23:23]:
> Hi Tony,
> 
> On Monday 10 April 2017 09:49 AM, Tony Lindgren wrote:
> > Some Motorola phones like droid 4 use a custom CPCAP PMIC that has a
> > multiplexing USB PHY.
> > 
> > This USB PHY can operate at least in four modes using pin multiplexing
> > and two control GPIOS:
> > 
> > - Pass through companion PHY for the SoC USB PHY
> > - ULPI PHY for the SoC
> > - Pass through USB for the modem
> > - UART debug console for the SoC
> > 
> > This patch adds support for droid 4 USB PHY and debug UART modes,
> > support for other modes can be added later on as needed.
> > 
> > Both peripheral and host mode are working for the USB. The
> > host mode depends on the cpcap-charger driver for VBUS.
> > 
> > VBUS and ID pin detection are done using cpcap-adc IIO ADC
> > driver.
> 
> I thought of using EXTCON differently from what was used below. Actually I
> thought EXTCON shuld be used in cpcap-adc driver for notifying VBUS or ID
> events to phy-cpcap driver which performs the various setting based on VBUS or
> ID. (See drivers/usb/dwc3/dwc3-omap.c which receives VBUS/ID notifications fo
> sample). That would have simply replaced the iio* calls with EXTCON calls in
> phy-cpcap-usb driver (in addition to adding extcon API's in cpcap-adc driver).

OK sorry yeah I misunderstood what you wanted then. I actually started
running into issues with extcon as it assumes that the extcon provider
can't be removed if there are consumers. So yeah let's scrap this usage
as it adds a bogus dependency between the charger driver and PHY driver.

> Usage of EXTCON like below is not of much use here since MUSB doesn't really
> wait for notification of ID or VBUS events (This is unlike dwc3-omap. since we
> invoke musb_mailbox functin directly).

OK

> If adding EXTCON in cpcap-adc isn't simple then we should stick to your patch
> version 2 since extcon support in this version is not useful IMO.

OK. I'll check and will post v3. My gut feeling is that IIO is better
for VBUS and ID as we want the values too.

For example ID pin can have multiple values, and it seems that many PHYs
can detect 102/200/440K pull-up on the ID pin for "carkit" mode etc. I'm
not yet sure if there are multiple ID pull-up values to be considered in
this case, but there is at least one pull-up value for detecting
"factory mode" where the device is supposed to be powered on USB only
even if there is no battery.

Also the VBUS in this case is the direct voltage from the battery as
far as I can tell so the voltage value should be considered.

> > +Example:
> > +cpcap_usb2_phy: phy {
> > +   compatible = "motorola,mapphone-cpcap-usb-phy";
...
> > +};
> 
> I would have preferred this to be a separate patch but since Rob has Acked it,
> it is fine.

OK

Regards,

Tony
--
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 4/4] usb: musb: tusb6010_omap: Convert to DMAengine API

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfal...@ti.com> [170508 08:15]:
> Tony,
> 
> On 2017-05-06 01:55, Tony Lindgren wrote:
> > OK I verified that with the current mainline kernel using dma
> > and g_ether and your patches 1 to 3 I can run the variable size
> > ping test loop for few minutes before it just stops working and
> > I can see the legacy DMA interrupt increase depending on the
> > size of the packet. Then I checked with v4.1 kernel, and that
> > too seems to have the same issue.
> > 
> > I've also verified running the same variable size ping test with
> > your patch 4/4 makes things stop within just a few seconds. The
> > script I'm using for ping is below.
> > 
> > Anyways, what we really should ensure here is that the external
> > dmarequest line is properly triggering things with dmaengine :)
> > That's why I'm a bit worried your patch 4/4.
> > 
> > Oh and I also verified the GPMC timings we're using are the same
> > as in production n810 kernel so that should not be the issue.
> > 
> > And using the async access on n800 will not work as it will
> > produce corrupt transfer size register the report I posted
> > earlier is from n800 allowing it to use async transfers. On
> > n810 async transfers may work as I recall it having a newer
> > tusb6010 version.
> 
> I think I have nailed the issue. I had a bug in the omap-dma implementation
> of the port_window (sigh) and couple of issues in the tusb6010/*_omap, not
> introduced by the series.
> The ASYNC access is pretty unstable on n810 as well, I got corruption in the
> XFR_SIZE.
> I have been using the g_ncm gadget with "musb->g.quirk_avoids_skb_reserve =
> 1;" to ensure that we are using SYNC access.
> 
> I'm running your variable ping script for 2 hours now, it wrapped >130 times
> already, I also run a standalone ping with 2048 size in parallel, the n810
> is booted to nfsroot:
> 
> # cat /proc/interrupts | grep dma
>  29:9483598  INTC  13 Edge  omap-dma-engine
> #
> 
> I need to clean up the code as I had debugs (disabled now) and stuff and I
> want to try the tusb6010 changes w/o the DMAengine conversion.

Hey that's good news!

Tony
--
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 4/4] usb: musb: tusb6010_omap: Convert to DMAengine API

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfal...@ti.com> [170505 08:20]:
> On 2017-05-05 16:37, Peter Ujfalusi wrote:
> > On 2017-05-05 00:05, Tony Lindgren wrote:
> > > And this sync gpmc issue seems to be timing related. Setting
> > > DEBUG in tusb6010_omap.c makes it happen easily while without
> > > it it's much harder to trigger. So probably some kind of issue
> > > with GPMC sync timings.
> > 
> > Indeed there are some interesting things happening...
> > As I said, I was testing with g_cdc (CDC Composite (ECM + ACM)) and I
> > found it pretty stable with DMAengine. But short story long:
> > 
> > With the series applied and getting rid of the dma_addr & 0x2, plus
> > setting the set the quirk_avoids_skb_reserve flag:
> > g_cdc (ECM + ACM) boots to nfsroot most of the time, ping, scp works
> > g_ether (ECM) does not boot to nfsroot, ping does not work. However if I
> > disable the rx DMA with:
> > 
> > diff --git a/drivers/usb/musb/tusb6010_omap.c
> > b/drivers/usb/musb/tusb6010_omap.c
> > index 8b43c4b99f04..8e0a19b47132 100644
> > --- a/drivers/usb/musb/tusb6010_omap.c
> > +++ b/drivers/usb/musb/tusb6010_omap.c
> > @@ -512,6 +512,12 @@ tusb_omap_dma_allocate(struct dma_controller *c,
> >  return NULL;
> >  }
> > 
> > +if (!tx) {
> > +dev_err(musb->controller, "Not allowing RX DMA for ep%i %s\n",
> > +chdat->epnum);
> 
> Remove the %s and s/chdat/hw_ep
> 
> and the kernel will not crash :( But still not booting with DMAengine when
> RX DMA is disabled :o

OK I verified that with the current mainline kernel using dma
and g_ether and your patches 1 to 3 I can run the variable size
ping test loop for few minutes before it just stops working and
I can see the legacy DMA interrupt increase depending on the
size of the packet. Then I checked with v4.1 kernel, and that
too seems to have the same issue.

I've also verified running the same variable size ping test with
your patch 4/4 makes things stop within just a few seconds. The
script I'm using for ping is below.

Anyways, what we really should ensure here is that the external
dmarequest line is properly triggering things with dmaengine :)
That's why I'm a bit worried your patch 4/4.

Oh and I also verified the GPMC timings we're using are the same
as in production n810 kernel so that should not be the issue.

And using the async access on n800 will not work as it will
produce corrupt transfer size register the report I posted
earlier is from n800 allowing it to use async transfers. On
n810 async transfers may work as I recall it having a newer
tusb6010 version.

Regards,

Tony

8< 
#!/bin/bash

device=$1
size=$2

while [ 1 ]; do
#echo "Pinging with size $size"
if ! ping -w0 -c1 -s$size $device > /dev/null 2>&1; then
break;
fi
size=$(expr $size + 1)

if [ $size -gt 8192 ]; then
size=1
fi
done
echo "Test ran up to $size"
--
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 4/4] usb: musb: tusb6010_omap: Convert to DMAengine API

[Tony Lindgren]

* Tony Lindgren <t...@atomide.com> [170504 12:43]:
> Hi,
> 
> * Peter Ujfalusi <peter.ujfal...@ti.com> [170503 04:00]:
> > With the port_window support in DMAengine and the sDMA driver we can
> > convert the driver to DMAengine.
> 
> Actually looks like this patch still has some issues.. Pinging
> the n8x0 with for example ping -s1 causes things to stop working.

Sorry it's actually ping -s2048, not -s1. Here's what happens
on n8x0 with first ping -s2048 with 4/4 applied:

musb-hdrc musb-hdrc.1.auto: Busy rx dma, not using: 0010
g_ether gadget: invalid EEM CRC
g_ether gadget: invalid EEM CRC
musb-hdrc musb-hdrc.1.auto: ep1 rx dma: 0x86803842 len: 512(512) packet_sz: 
512(512)
musb-hdrc musb-hdrc.1.auto: ep1 rx using 16-bit async dma from 0x02000620 to 
0x86803842
musb-hdrc musb-hdrc.1.auto: ep1 rx dma callback
musb-hdrc musb-hdrc.1.auto: DMA remaining 448/512
musb-hdrc musb-hdrc.1.auto: Busy rx dma, not using: 01c0
musb-hdrc musb-hdrc.1.auto: Busy rx dma, not using: 0008
musb-hdrc musb-hdrc.1.auto: ep1 rx dma: 0x869fdc02 len: 512(512) packet_sz: 
512(512)
musb-hdrc musb-hdrc.1.auto: ep1 rx using 16-bit async dma from 0x02000620 to 
0x869fdc02
musb-hdrc musb-hdrc.1.auto: ep1 rx dma callback
musb-hdrc musb-hdrc.1.auto: DMA remaining 448/512
musb-hdrc musb-hdrc.1.auto: Busy rx dma, not using: 01c0
musb-hdrc musb-hdrc.1.auto: Busy rx dma, not using: 0008
musb-hdrc musb-hdrc.1.auto: ep1 rx dma: 0x869fc642 len: 512(512) packet_sz: 
512(512)
musb-hdrc musb-hdrc.1.auto: ep1 rx using 16-bit async dma from 0x02000620 to 
0x869fc642
musb-hdrc musb-hdrc.1.auto: ep1 rx dma callback
musb-hdrc musb-hdrc.1.auto: Corrupt rx XFR_SIZE: 0x7ec0
musb-hdrc musb-hdrc.1.auto: DMA remaining 0/512
musb-hdrc musb-hdrc.1.auto: Busy rx dma, not using: 7ec0
musb-hdrc musb-hdrc.1.auto: Busy rx dma, not using: 0008
musb-hdrc musb-hdrc.1.auto: Busy rx dma, not using: 0010
musb-hdrc musb-hdrc.1.auto: Busy rx dma, not using: 7cf0

It seems the hardware dmareq line is not triggering anything
above?

Also with just ping with no size specified, it seems every other
packet is missed or DMA interrupts are not properly triggering
as I'm getting these:

g_ether gadget: invalid EEM CRC

> This is when using only with the async gpmc access as the sync
> gpmc access seems to have a regression not related to this series.
> I'll try to track down that sync gpmc issue as that most likely
> hints to something being wrong in the gpmc code in general.

And this sync gpmc issue seems to be timing related. Setting
DEBUG in tusb6010_omap.c makes it happen easily while without
it it's much harder to trigger. So probably some kind of issue
with GPMC sync timings.

I also found one other issue that might need fixing depending
on the bootloader version, see below.

Regards,

Tony

8< -----
>From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren <t...@atomide.com>
Date: Thu, 4 May 2017 09:35:32 -0700
Subject: [PATCH] ARM: dts: Fix n8x0 tusb6010 dmareq pin muxing

Looks like I forgot to add the device tree pin multiplexing for
tusb6010 on n8x0 when removing legacy platform code. Although the
bootloader sets the pins on n8x0, this may be needed on some n8x0
depending on the bootloader version.

Fixes: 602105ed740d ("ARM: OMAP2+: Remove legacy muxing
for usb-tusb6010.c")
Signed-off-by: Tony Lindgren <t...@atomide.com>
---
 arch/arm/boot/dts/omap2420-n8x0-common.dtsi | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi 
b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
--- a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
+++ b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
@@ -103,3 +103,19 @@
};
};
 };
+
+_pmx {
+   pinctrl-0 = <_dmareq_pins>;
+   pinctrl-names = "default";
+
+   tusb6010_dmareq_pins: pinmux_tusb6010_dmareq_pins {
+   pinctrl-single,pins = <
+   OMAP2420_CORE_IOPAD(0x0071, PIN_INPUT | MUX_MODE2)  /* 
gpmc_10.sys_ndmareq5 */
+   OMAP2420_CORE_IOPAD(0x0072, PIN_INPUT | MUX_MODE2)  /* 
gpmc_9.sys_ndmareq4 */
+   OMAP2420_CORE_IOPAD(0x0073, PIN_INPUT | MUX_MODE2)  /* 
gpmc_8.sys_ndmareq3 */
+   OMAP2420_CORE_IOPAD(0x0074, PIN_INPUT | MUX_MODE2)  /* 
gpmc_7.sys_ndmareq1 */
+   OMAP2420_CORE_IOPAD(0x00e5, PIN_INPUT | MUX_MODE2)  /* 
vlynq_clk.sys_ndmareq0 */
+   OMAP2420_CORE_IOPAD(0x00e6, PIN_INPUT | MUX_MODE2)  /* 
vlynq_rx1.sys_ndmareq1 */
+   >;
+   };
+};
-- 
2.12.2
--
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 4/4] usb: musb: tusb6010_omap: Convert to DMAengine API

[Tony Lindgren]

Hi,

* Peter Ujfalusi  [170503 04:00]:
> With the port_window support in DMAengine and the sDMA driver we can
> convert the driver to DMAengine.

Actually looks like this patch still has some issues.. Pinging
the n8x0 with for example ping -s1 causes things to stop working.

This is when using only with the async gpmc access as the sync
gpmc access seems to have a regression not related to this series.
I'll try to track down that sync gpmc issue as that most likely
hints to something being wrong in the gpmc code in general.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4] usb: musb: tusb6010_omap: Convert to DMAengine

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfal...@ti.com> [170503 04:00]:
> Hi,
> 
> With port_window support implemented in DMAengine and the sDMA DMAengine 
> driver,
> the tusb6010_omap driver can be converted away from the custom legacy omap-dma
> API to generic DMAengine.
> 
> The first two patch is to prepare the tusb6010_omap driver for the conversion.
> The third one adds the needed entries for the dma_slave_map so we can request
> the DMA channels. This can be reverted when the stack is converted to DT.
> 
> The last patch does the main work to move the driver to DMAengine API.
> 
> I have tested the set on top of next-20170503 on Nokia n810 with nfsroot using
> CDC Ethernet (g_cdc) and copying files with scp to/form my host.

Thanks for doing this! For this series:

Acked-by: Tony Lindgren <t...@atomide.com>

> To force that the DMA is actually used I have:
> diff --git a/drivers/usb/musb/tusb6010_omap.c 
> b/drivers/usb/musb/tusb6010_omap.c
> index 05aefcad40b5..a5fc2a6bdad3 100644
> --- a/drivers/usb/musb/tusb6010_omap.c
> +++ b/drivers/usb/musb/tusb6010_omap.c
> @@ -216,8 +216,8 @@ static int tusb_omap_dma_program(struct dma_channel 
> *channel, u16 packet_sz,
>* use a timer for the callback, but it is unsafe as the XFR_SIZE
>* register is corrupt, and we won't know if the DMA worked.
>*/
> - if (dma_addr & 0x2)
> - return false;
> +//   if (dma_addr & 0x2)
> +//   return false;
>  
>   /*
>* Because of HW issue #10, it seems like mixing sync DMA and async
> 
> Since this condition will almost all the time was true - effectively disabling
> the DMA use.

Yeah this really should have the transfers aligned to 32-bit like
the production kernel did. For reference, the following should do
the trick but of course would have to be done conditionally.

Regards,

Tony

8< --
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -2153,6 +2153,7 @@ __acquires(musb->lock)
musb->g.a_alt_hnp_support = 0;
musb->g.a_hnp_support = 0;
musb->g.quirk_zlp_not_supp = 1;
+   musb->g.quirk_avoids_skb_reserve = 1;
 
/* Normal reset, as B-Device;
 * or else after HNP, as A-Device
--
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

[PATCHv3] phy: cpcap-usb: Add CPCAP PMIC USB support

[Tony Lindgren]

Some Motorola phones like droid 4 use a custom CPCAP PMIC that has a
multiplexing USB PHY.

This USB PHY can operate at least in four modes using pin multiplexing
and two control GPIOS:

- Pass through companion PHY for the SoC USB PHY
- ULPI PHY for the SoC
- Pass through USB for the modem
- UART debug console for the SoC

This patch adds support for droid 4 USB PHY and debug UART modes,
support for other modes can be added later on as needed.

Both peripheral and host mode are working for the USB. The
host mode depends on the cpcap-charger driver for VBUS.

VBUS and ID pin detection are done using cpcap-adc IIO ADC
driver.

Cc: devicet...@vger.kernel.org
Cc: Marcel Partap <mpar...@gmx.net>
Cc: Michael Scott <michael.sc...@linaro.org>
Acked-by: Rob Herring <r...@kernel.org>
Tested-by: Sebastian Reichel <s...@kernel.org>
Signed-off-by: Tony Lindgren <t...@atomide.com>
---

Changes since v2:
- Added extcon support as requested by Kishon

- Added Rob's ack

- Folded in Kconfig randconfig build fix to add depends on IIO

Changes since v1:
- Use iio_read_channel_processed() instead of iio_read_channel_scaled()
  as changed in the v2 of the ADC driver

- Kept Tested-by from Sebastian Reichel <s...@kernel.org> as the change
  from v1 is trivial

---
 .../devicetree/bindings/phy/phy-cpcap-usb.txt  |  40 ++
 drivers/phy/Kconfig|   8 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-cpcap-usb.c| 734 +
 4 files changed, 783 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
 create mode 100644 drivers/phy/phy-cpcap-usb.c

diff --git a/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt 
b/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt
@@ -0,0 +1,40 @@
+Motorola CPCAP PMIC USB PHY binding
+
+Required properties:
+compatible: Shall be either "motorola,cpcap-usb-phy" or
+   "motorola,mapphone-cpcap-usb-phy"
+#phy-cells: Shall be 0
+interrupts: CPCAP PMIC interrupts used by the USB PHY
+interrupt-names: Interrupt names
+io-channels: IIO ADC channels used by the USB PHY
+io-channel-names: IIO ADC channel names
+vusb-supply: Regulator for the PHY
+
+Optional properties:
+pinctrl: Optional alternate pin modes for the PHY
+pinctrl-names: Names for optional pin modes
+mode-gpios: Optional GPIOs for configuring alternate modes
+
+Example:
+cpcap_usb2_phy: phy {
+   compatible = "motorola,mapphone-cpcap-usb-phy";
+   pinctrl-0 = <_gpio_mux_sel1 _gpio_mux_sel2>;
+   pinctrl-1 = <_ulpi_pins>;
+   pinctrl-2 = <_utmi_pins>;
+   pinctrl-3 = <_pins>;
+   pinctrl-names = "default", "ulpi", "utmi", "uart";
+   #phy-cells = <0>;
+   interrupts-extended = <
+15 0  14 0  28 0  19 0
+18 0  17 0  16 0  49 0
+48 1
+   >;
+   interrupt-names =
+   "id_ground", "id_float", "se0conn", "vbusvld",
+   "sessvld", "sessend", "se1", "dm", "dp";
+   mode-gpios = < 28 GPIO_ACTIVE_HIGH
+  0 GPIO_ACTIVE_HIGH>;
+   io-channels = <_adc 2>, <_adc 7>;
+   io-channel-names = "vbus", "id";
+   vusb-supply = <>;
+};
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -47,6 +47,14 @@ config PHY_BERLIN_SATA
help
  Enable this to support the SATA PHY on Marvell Berlin SoCs.
 
+config PHY_CPCAP_USB
+   tristate "CPCAP USB PHY driver"
+   depends on USB_SUPPORT && IIO
+   select GENERIC_PHY
+   select USB_PHY
+   help
+ Enable this for CPCAP USB to work.
+
 config ARMADA375_USBCLUSTER_PHY
def_bool y
depends on MACH_ARMADA_375 || COMPILE_TEST
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_PHY_BCM_NS_USB2)   += phy-bcm-ns-usb2.o
 obj-$(CONFIG_PHY_BCM_NS_USB3)  += phy-bcm-ns-usb3.o
 obj-$(CONFIG_PHY_BERLIN_USB)   += phy-berlin-usb.o
 obj-$(CONFIG_PHY_BERLIN_SATA)  += phy-berlin-sata.o
+obj-$(CONFIG_PHY_CPCAP_USB)+= phy-cpcap-usb.o
 obj-$(CONFIG_PHY_DA8XX_USB)+= phy-da8xx-usb.o
 obj-$(CONFIG_PHY_DM816X_USB)   += phy-dm816x-usb.o
 obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY) += phy-armada375-usb2.o
diff --git a/drivers/phy/phy-cpcap-usb.c b/drivers/phy/phy-cpcap-usb.c
new file mode 100644
--- /dev/null
+++ b/drivers/phy/phy-cpcap-usb.c
@@ -0,0 +1,734 @@
+/*
+ * Motorola CPCAP PMIC USB PHY driver
+ * Copyright

[PATCH] usb: musb: Fix trying to suspend while active for OTG configurations

[Tony Lindgren]

Commit d8e5f0eca1e8 ("usb: musb: Fix hardirq-safe hardirq-unsafe
lock order error") caused a regression where musb keeps trying to
enable host mode with no cable connected. This seems to be caused
by the fact that now phy is enabled earlier, and we are wrongly
trying to force USB host mode on an OTG port. The errors we are
getting are "trying to suspend as a_idle while active".

For ports configured as OTG, we should not need to do anything
to try to force USB host mode on it's OTG port. Trying to force host
mode in this case just seems to completely confuse the musb state
machine.

Let's fix the issue by making musb_host_setup() attempt to force the
mode only if port_mode is configured for host mode.

Fixes: d8e5f0eca1e8 ("usb: musb: Fix hardirq-safe hardirq-unsafe
lock order error")
Cc: Johan Hovold <jo...@kernel.org>
Reported-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
Reported-by: Peter Ujfalusi <peter.ujfal...@ti.com>
Tested-by: Peter Ujfalusi <peter.ujfal...@ti.com>
Signed-off-by: Tony Lindgren <t...@atomide.com>
---
 drivers/usb/musb/musb_host.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2780,10 +2780,11 @@ int musb_host_setup(struct musb *musb, int power_budget)
int ret;
struct usb_hcd *hcd = musb->hcd;
 
-   MUSB_HST_MODE(musb);
-   musb->xceiv->otg->default_a = 1;
-   musb->xceiv->otg->state = OTG_STATE_A_IDLE;
-
+   if (musb->port_mode == MUSB_PORT_MODE_HOST) {
+   MUSB_HST_MODE(musb);
+   musb->xceiv->otg->default_a = 1;
+   musb->xceiv->otg->state = OTG_STATE_A_IDLE;
+   }
otg_set_host(musb->xceiv->otg, >self);
hcd->self.otg_port = 1;
musb->xceiv->otg->host = >self;
-- 
2.12.2
--
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: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfal...@ti.com> [170406 10:07]:
> Tony,
> 
> On 04/05/2017 06:29 PM, Tony Lindgren wrote:
> > * Tony Lindgren <t...@atomide.com> [170405 06:53]:
> > > * Peter Ujfalusi <peter.ujfal...@ti.com> [170405 00:15]:
> > > > To be precise this is what I have tried:
> > > > - boot w/o cable connected
> > > > - boot w/ board connected to PC (device mode)
> > > > - boot w/ OTG-A cable with USB keyboard
> > > > - boot w/ OTG-A cable connected to powered USB hub and the same keyboard
> > > > 
> > > > w/ and w/o this patch I have the same flood of prints in all cases.
> > > 
> > > OK interesting that it also happens with nothing connected.
> > > 
> > > > Fwiw I have checked where the is_active is set - which causes the 
> > > > prints:
> > > > musb_core.c:musb_start()
> > > > 
> > > > if (musb->port_mode != MUSB_PORT_MODE_HOST &&
> > > > musb->xceiv->otg->state != OTG_STATE_A_WAIT_BCON &&
> > > > (devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) {
> > > > musb->is_active = 1;
> > > > } else {
> > > > devctl |= MUSB_DEVCTL_SESSION;
> > > > }
> > > > 
> > > > this was the only place where the is_active was set to 1.
> > > 
> > > That seems normal in musb_start(). Will try with your .config
> > > here.
> > 
> > If the the port is configured as OTG, we should not need to
> > try to force any states during init. The change below will stop
> > the warnings with your .config, needs to be tested more though
> > to make sure things still work in all cases.
> 
> With this change I can boot up without issues, thanks!

OK

> I can not get the kernel to react to anything I plug to the A/B connector.

Yeah it seems that we have only peripheral mode working with panda, so
there seems to be also a long time vbus related regression.

> Keyboard (directly or via powered hub), flash drive, connecting the board to
> PC. Nothing.
> Actually if I connect to a PC I got a print from twl6030 about an interrupt,
> but nothing happens in USB front.
>
> The same thing happens with 4.8, so it is not regression. Most likely it is
> an error in my setup...

For me peripheral mode works fine. You needs at least one gadget
configured, looks like your .config has CONFIG_USB_GADGET disabled.

The VBUS should be coming from twl6030 and it seems to have some vbus
code. Would be nice to get the host mode working on panda too for the
OTG port..

> Tested-by: Peter Ujfalusi <peter.ujfal...@ti.com>

OK thanks,

Tony
--
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: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)

[Tony Lindgren]

* Bin Liu <b-...@ti.com> [170406 12:09]:
> On Wed, Apr 05, 2017 at 08:29:55AM -0700, Tony Lindgren wrote:
> > If the the port is configured as OTG, we should not need to
> > try to force any states during init. The change below will stop
> 
> True, but the code has been there for a very long time, any idea what
> causes the regression?

I think it's just that with commit d8e5f0eca1e8 we now have phy enabled
earlier and calling musb_host_setup() with phy enabled sends it into
a loop of trying to force the host mode with nothing connected. This
loops seems to end after few seconds if there are devices connected,
but keeps going if there's nothing connected.

Regards,

Tony
--
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: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)

[Tony Lindgren]

* Tony Lindgren <t...@atomide.com> [170405 06:53]:
> * Peter Ujfalusi <peter.ujfal...@ti.com> [170405 00:15]:
> > To be precise this is what I have tried:
> > - boot w/o cable connected
> > - boot w/ board connected to PC (device mode)
> > - boot w/ OTG-A cable with USB keyboard
> > - boot w/ OTG-A cable connected to powered USB hub and the same keyboard
> > 
> > w/ and w/o this patch I have the same flood of prints in all cases.
> 
> OK interesting that it also happens with nothing connected.
> 
> > Fwiw I have checked where the is_active is set - which causes the prints:
> > musb_core.c:musb_start()
> > 
> > if (musb->port_mode != MUSB_PORT_MODE_HOST &&
> > musb->xceiv->otg->state != OTG_STATE_A_WAIT_BCON &&
> > (devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) {
> > musb->is_active = 1;
> > } else {
> > devctl |= MUSB_DEVCTL_SESSION;
> > }
> > 
> > this was the only place where the is_active was set to 1.
> 
> That seems normal in musb_start(). Will try with your .config
> here.

If the the port is configured as OTG, we should not need to
try to force any states during init. The change below will stop
the warnings with your .config, needs to be tested more though
to make sure things still work in all cases.

Regards,

Tony

8< --
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2780,10 +2780,11 @@ int musb_host_setup(struct musb *musb, int power_budget)
int ret;
struct usb_hcd *hcd = musb->hcd;
 
-   MUSB_HST_MODE(musb);
-   musb->xceiv->otg->default_a = 1;
-   musb->xceiv->otg->state = OTG_STATE_A_IDLE;
-
+   if (musb->port_mode == MUSB_PORT_MODE_HOST) {
+   MUSB_HST_MODE(musb);
+   musb->xceiv->otg->default_a = 1;
+   musb->xceiv->otg->state = OTG_STATE_A_IDLE;
+   }
otg_set_host(musb->xceiv->otg, >self);
hcd->self.otg_port = 1;
musb->xceiv->otg->host = >self;
-- 
2.12.2
--
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: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)

[Tony Lindgren]

* Peter Ujfalusi <peter.ujfal...@ti.com> [170405 00:15]:
> Tony,
> 
> On 2017-04-05 03:36, Tony Lindgren wrote:
> > * Tony Lindgren <t...@atomide.com> [170404 07:06]:
> > > * Bin Liu <b-...@ti.com> [170404 05:30]:
> > > > On Tue, Apr 04, 2017 at 10:09:50AM +0300, Peter Ujfalusi wrote:
> > > > > Tony,
> > > > > 
> > > > > since 4.9 (4.8 was fine) I can not boot omap4-panda-es if the musb
> > > > > is compiled in. The kernel will stuck printing:
> > > > > 
> > > > > ** 206 printk messages dropped ** [8.926727] musb_bus_suspend
> > > > > 2584: trying to suspend as a_idle while active
> > > 
> > > OK so compiled in. Do you have something connected also when
> > > booting?
> > > 
> > > > Does it sound a similar issue to
> > > > http://marc.info/?l=linux-usb=149036531809506=2
> > > 
> > > Yup.
> > > 
> > > > > The bisect (log is [1]) points to:
> > > > > d8e5f0eca1e8 usb: musb: Fix hardirq-safe hardirq-unsafe lock order 
> > > > > error
> > > > > 
> > > > > and reverting the d8e5f0eca1e8 makes the board to boot up fine
> > > > > (Linux 4.11-rc5 and next-20170331).
> > > 
> > > OK thanks for bisecting it.
> > > 
> > > > > any idea on how to fix this w/o reverting the commit?
> > > 
> > > I'll take a look.
> > 
> > OK I was able to reproduce this with loadable modules by reloading
> > the modules while having OTG-A cable inserted with a hub and USB
> > drive connected.
> > 
> > Peter, care to check if the following fixes the problem for you?
> > There should no longer be much any musb core tinkering happening
> > in the glue layers..
> 
> I had similar hunch first, but did not worked. I have tested this patch and
> did not helped.
> 
> To be precise this is what I have tried:
> - boot w/o cable connected
> - boot w/ board connected to PC (device mode)
> - boot w/ OTG-A cable with USB keyboard
> - boot w/ OTG-A cable connected to powered USB hub and the same keyboard
> 
> w/ and w/o this patch I have the same flood of prints in all cases.

OK interesting that it also happens with nothing connected.

> Fwiw I have checked where the is_active is set - which causes the prints:
> musb_core.c:musb_start()
> 
> if (musb->port_mode != MUSB_PORT_MODE_HOST &&
>   musb->xceiv->otg->state != OTG_STATE_A_WAIT_BCON &&
>   (devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) {
>   musb->is_active = 1;
> } else {
>   devctl |= MUSB_DEVCTL_SESSION;
> }
> 
> this was the only place where the is_active was set to 1.

That seems normal in musb_start(). Will try with your .config
here.

Regards,

Tony
--
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: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)

[Tony Lindgren]

* Tony Lindgren <t...@atomide.com> [170404 07:06]:
> * Bin Liu <b-...@ti.com> [170404 05:30]:
> > On Tue, Apr 04, 2017 at 10:09:50AM +0300, Peter Ujfalusi wrote:
> > > Tony,
> > > 
> > > since 4.9 (4.8 was fine) I can not boot omap4-panda-es if the musb
> > > is compiled in. The kernel will stuck printing:
> > > 
> > > ** 206 printk messages dropped ** [8.926727] musb_bus_suspend
> > > 2584: trying to suspend as a_idle while active
> 
> OK so compiled in. Do you have something connected also when
> booting?
> 
> > Does it sound a similar issue to
> > http://marc.info/?l=linux-usb=149036531809506=2
> 
> Yup.
> 
> > > The bisect (log is [1]) points to:
> > > d8e5f0eca1e8 usb: musb: Fix hardirq-safe hardirq-unsafe lock order error
> > > 
> > > and reverting the d8e5f0eca1e8 makes the board to boot up fine
> > > (Linux 4.11-rc5 and next-20170331).
> 
> OK thanks for bisecting it.
> 
> > > any idea on how to fix this w/o reverting the commit?
> 
> I'll take a look.

OK I was able to reproduce this with loadable modules by reloading
the modules while having OTG-A cable inserted with a hub and USB
drive connected.

Peter, care to check if the following fixes the problem for you?
There should no longer be much any musb core tinkering happening
in the glue layers..

Regards,

Tony

8< ---
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -91,12 +91,6 @@ static void omap2430_musb_set_vbus(struct musb *musb, int 
is_on)
}
 
otg_set_vbus(otg, 1);
-   } else {
-   musb->is_active = 1;
-   otg->default_a = 1;
-   musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE;
-   devctl |= MUSB_DEVCTL_SESSION;
-   MUSB_HST_MODE(musb);
}
} else {
musb->is_active = 0;
--
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