Hi, On 28 February 2018 4:43 AM, Peter Chen <hzpeterchen@xxxxxxxxx> wrote: > You mean you measure it after echo "mem" > /sys/power/state, right? Yes, I've put my multimeter to some grounded part of the board and the other measuring head(or is it called test prod in English?) to the right pin of the usb port (if watched from above). It stayed on after echo mem > /sys/power/state. > You mean disabled "1-1" wakeup entry, but other wakeup entries are > enabled, still wakes up system for "mem"? Yes. > Would you please try below changes: > 1. By connecting external HUB at USBOTG0, and only enable its wakeup > to see if the abnormal wakeup occurs? > 2184200.usb -> 2184000.usb > ci\_hdrc.1 ->ci\_hdrc.0 > > 2. Unbind wired USB HUB at host port to see if the abnormal wakeup > occurs? > echo -n "1-1:1.0" > /sys/bus/usb/drivers/hub/unbind I'm afraid I'm not able to do this at the moment. I only have a HUB with a Mini-USB-Input and a cable Mini-USB-B to (usual) USB-A. The connector on the board also is a Mini-A/B-Port, so i would need a Mini-USB-(AorB)--to--Mini-USB-B--cable. Maybe with OTG capability and an USB-HUB with OTG capability. If necessary, I could try to order one or solder one by 2 old Mini-USB-cables. > 3. Search schematic to see if Power of USB HUB is controlled by > software, and be off at mem-sleep. I don't have a schematic drawing of the board, but I have the manuals of cpu- and carrier-board. I could ask our supplier for that drawing if necessary. But maybe these informations might help: "The VBUS supplies of Host interfaces at the USB connectors are controlled by the common enable signal USBH_PEN# of the emCON interface. Also a common over current flag USBH_OC# is fed back." [2] It looks like there are 4 ports connected to the Hub (2xUSB2.0, 1xUSB3.0, 1xminiPCIe(There seem to be additional USB Pins on the miniPCIe-Socket)) and 1 OTG Port that has nothing to do with the hub. About the 2.0 Ports on the Hub: "The VBUS outputs of both ports are driven by a dual channel power switch which is controlled by the signal USBH_PEN# of the emCON interface." [2] About the 3.0 Ports on the Hub: "The USB 3.0 interface is directly driven by the emCON connector."; "The USB 2.0 interface is driven by the USB Hub of the Avari."; "The VBUS output of this connector is controlled by an own USB power switch which can source 2 A. The power switch is controlled by the signal USBH_PEN# of the emCON interface." [2] About the OTG Port: "The interface signals are directly connected to the emCON connector. Therefore all characteristics of the interface depend on the used CPU module. The VBUS power switch is controlled by the signal USBOTG_PEN# of the CPU module and by the ID pin of the USB connector. Only if the ID pin is driven low by a connected cable the VBUS supply can be driven by the CPU module. The ID pin also controls the signal USBOTG_VBUS at the emCON connector. If the ID pin is left open the VBUS switch of the Avari is disabled and the level of the VBUS signal at pin 1 of the USB connector is driven to the signal USBOTG_VBUS. Thus plugging of a USB Host can is detected while the interface is operated in Device mode." [2] While the cpu board manual says about the "USB Host": "To switch the bus power the control line USBH_PEN# is connected to the emCON connector. A logical “0” at the processor GPIO3-31 switches the power on; a logical “1” turns the power off."; "The USBH_VBUS signal on the emCON connector is only an input to detect the VBUS voltage on the baseboard." [3] And about the "USB OTG": "To switch the bus power in USB Host mode the control line USBOTG_PEN# is connected to the emCON connector. A logical “0” at the processor GPIO1-8 switches the power on; a logical “1” turns the power off."; "The USBOTG_VBUS signal on the emCON connector is only an input to detect the VBUS voltage on the baseboard." [3] To clearify some names: - emCON connector := large connector between cpu board and carrier board - Avari := carrier board It looks like you can turn off the hub by GPIO3-31 and the power of the OTG Port by GPIO1-8, so I think it is really controlled by software. If you want to take a look on those manuals by your own, all I've quoted is in [2] chapter 7 and [3] chapters 4.5 and 4.6. > To see if function imx6q_finalize_wakeup_setting is existed at > drivers/usb/chipidea/usbmisc_imx.c, if existed, it the kernel from > fsl/nxp. There ale only these functions in usbmisc_imx.c that contain wakeup in their name: - static int usbmisc_imx6q_set_wakeup - static int usbmisc_imx7d_set_wakeup - int imx_usbmisc_set_wakeup Best regards, Ralf [1] i.MX 6Solo/6DualLite Applications Processor Reference Manual, Rev. 3, 09/2017 (IMX6SDLRM.pdf) (https://imxdev.gitlab.io/imxdoc/reference-manual-imx6/) [2] emCON_Avari, emCON compliant baseboard, Hardware Description, Rev3 / 25.10.2016 (emCON_Avari_HW_v003en.pdf) (https://www.emtrion.de/de/details_products-accessoires/emcon-mx6-57.html) [3] emCON-MX6, Hardware Manual, Rev2 / 13.10.2017 (emCON-MX6x_HW_V002en.pdf) (https://www.emtrion.de/de/details_products-accessoires/emcon-mx6-57.html) -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
