On Tue, Mar 7, 2017 at 8:24 AM, Icenowy Zheng <icenowy@xxxxxxxx> wrote: > > > 07.03.2017, 07:48, "Ondřej Jirman" <megous@xxxxxxxxxx>: >> Hi Icenowy, >> >> when I was trying to add OTG support I found an issue with powercycling. >> When I have USB cable connecting PC and the OTG port on the SBC, when >> the board enables the vbus, it would become impossible to power cycle >> the board after poweroff. The reason being that when vbus is enabled, >> the board is powered from the OTG port even if you disconnect the barrel >> plug. >> >> Should kernel turn off the vbus before shutting down/restarting? What do >> you think? > > It's a good problem. > > I think this problem can be abstracted into: > Some regulators are needed to be shut down before system > shutdown. Sounds like the board is getting back-powered from VBUS through the enabled current regulator. Given that you have it connected to the PC, which I assume means peripheral mode, the bigger issue is why is VBUS enabled in peripheral mode? It should never ever be so. Regards ChenYu > Is there any framework for it? > > Mark, > I add you to recipients for the question above. > > Thanks, > Icenowy > >> >> regards, >> o. >> >> Dne 6.3.2017 v 23:34 Icenowy Zheng napsal(a): >>> Allwinner H3 have a its USB PHY0 routed to two USB controllers: one is >>> a MUSB controller, which can work in peripheral mode, but works badly in >>> host mode (several hardware will fail on the MUSB controller, even connect >>> one MUSB controller in peripheral mode to another one in host mode cannot >>> work); the other is a pair of EHCI/OHCI controller, which can work only >>> in host mode, but have better compatibillity. The route is controlled in >>> a register, which we have set it to HCI only when we do not know about >>> it well. >>> >>> Add support to route to the best controller according to current USB mode >>> (host/peripheral). >>> >>> Note: Currently even if hardware only support hostmode, we should still >>> enable the MUSB controller, as it controls the USB mode. (Some this kind >>> of hardware can also work in peripheral mode by settings in the sysfs >>> node of MUSB, then connect it to another host via a USB Type-A to Type-A >>> cable.) >>> >>> Patch 1 changes the device tree binding to include the "pmu0" for HCI pair. >>> >>> Patch 2 adds support for auto routing of PHY0. It's currently only enabled >>> on H3, but it's easy to extend it to other SoCs which feature this >>> route control. >>> >>> Patch 3 adds necessary device tree nodes to the H3 DTSI file. Note: The >>> phy is not bind for OHCI/EHCI0, as OHCI/EHCI drivers will keep the VBUS >>> on. Only MUSB driver can properly handle a dual-role PHY. >>> >>> Patch 4 enables USB OTG functionality on Orange Pi One board, which is >>> the only H3 board I have that have proper OTG function. It's easy to >>> enable OTG on other boards with their schematics. >>> >>> Patch 5 enables USB OTG functionality on Orange Pi Zero board, as the >>> board cannot output power on Vbus, I only enabled peripheral mode by >>> default. >>> >>> The USB PHY on V3s/A64 SoCs also feature this capability, and it will >>> be soon enabled on these SoCs after this patchset is merged. >>> >>> Icenowy Zheng (5): >>> dt: bindings: add pmu0 regs for USB PHYs on Allwinner H3/V3s/A64 >>> phy: sun4i-usb: support automatically switch PHY0 route to MUSB/HCI >>> ARM: dts: sun8i: h3: add usb_otg and OHCI/EHCI for usbc0 on H3 >>> ARM: dts: sun8i: h3: enable USB OTG on Orange Pi One >>> ARM: dts: sun8i: h2+: enable USB OTG for Orange Pi Zero board >>> >>> .../devicetree/bindings/phy/sun4i-usb-phy.txt | 1 + >>> arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts | 14 ++++++ >>> arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 22 +++++++++- >>> arch/arm/boot/dts/sun8i-h3.dtsi | 32 ++++++++++++++ >>> drivers/phy/phy-sun4i-usb.c | 50 ++++++++++++++-------- >>> 5 files changed, 101 insertions(+), 18 deletions(-) > > -- > You received this message because you are subscribed to the Google Groups "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@xxxxxxxxxxxxxxxx. > For more options, visit https://groups.google.com/d/optout. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
