01:22 <wpwrak> now this is a fun little movie: https://www.youtube.com/watch?v=NpN9NzO4Mo8

13:13 <wpwrak> Joerg-Neo900: i'll classify the modem VBUS switch as a v2-only feature, okay ? in case it should turn out we'll need it in final as well, it can always be reclassified

13:35 <Joerg-Neo900> I don't think it's a v2_only but a classification doesn't hurt

13:36 <Joerg-Neo900> we rather should check what's the role and means of implementation of VBUS with a PHY

13:37 <Joerg-Neo900> if PHY has support for VBUS (if only in form of a logic line controlling whatever external chargepump or whatever), then the current implementation for sure is v2_only

13:38 <wpwrak> :)

13:39 <Joerg-Neo900> VBUS obviously in very first diagram/figure in that pdf

13:39 <Joerg-Neo900> http://wstaw.org/m/2016/12/20/plasma-desktopV17764.png

13:40 <wpwrak> ideally, suspend/resume will work as it should, and then power cycling vusb_modem won't be needed. the usb architecture doesn't assume that you actually can do that anyway. so that would only be needed post-v2 if either some horrible surprise is found with suspend/resume, or if no conclusive result has been obtained during v2 evaluation

13:41 <Joerg-Neo900> http://wstaw.org/m/2016/12/20/plasma-desktopR17764.png

13:41 <Joerg-Neo900> power cycling of VBUS is needed anyway to trigger a new session

13:42 <wpwrak> that's already somewhere in the fancy feature domain :)

13:42 <Joerg-Neo900> the USB architecture assumes you can unplug USB cable, which we can't

13:43 <wpwrak> okay, let's say "core architecture". there, if you need to reset/re-enumerate a device, you just send a SE0 but don't touch VBUS.

13:44 <wpwrak> and for "sleep", you have suspend/resume

13:44 <Joerg-Neo900> >> In addition to the internal VBUS comparators, the USB332x also includes the integrated VBUS pull-up and pull-down resistors used for VBUS Pulsing during OTG Session Request Protocol. To discharge the VBUS voltage so that a Session Request can begin, the USB332x provides a pull-down resistor from VBUS to Ground. This resistor is controlled by the DischargeVbus bit 3 of the OTG Control register. The pull-up resistor is connected between VBUS

13:44 <Joerg-Neo900> and VDD33<<

13:45 <Joerg-Neo900> so yes, this feature is prolly v2_only :-)

13:47 <Joerg-Neo900> though: >> The USB332x does not provide an external output for the DrvVbusExternal ULPI register. For OTG and Host applications, the external VBUS supply or power switch must be controlled by the Link as shown in Figure 8.2.<<

13:48 <Joerg-Neo900> http://wstaw.org/m/2016/12/20/plasma-desktopS17764.png

13:50 <Joerg-Neo900> so obviously we need "chargepump" aka "VBUS switch" for final too, and we need to control it from APE

13:52 <Joerg-Neo900> so we add a switch (FET?) to VBAT_SW (3.3V<VBUS<5.5V) and hook it up to an IO-extender

13:52 <wpwrak> already there :)

13:52 <Joerg-Neo900> :-D

13:54 <wpwrak> but i'm not so sure about the requirement for post-v2. the link controller is outside the scope for the PHY. so even if the PHY insists in being able to monitor VBUS, we could just connect it to VBUS_SWITCHED (and hope it doesn't mind the voltage difference)

13:54 <Joerg-Neo900> VBUS control is mandatory for USB

13:56 <Joerg-Neo900> actually it's even mandated for host controllers afaik, even while some PC host implementations disregard that

13:57 <Joerg-Neo900> for our design anyway VBUS disabling is the only way to "unplug" the USB peripheral, which is a desirable feature no matter what

13:59 <Joerg-Neo900> yet to be avaluated if it's even allowed by modem specs to apply >3V to VBUS while VDD is zero

14:03 <Joerg-Neo900> ROTFL http://wstaw.org/m/2016/12/20/plasma-desktopg17764.png

14:03 <wpwrak> regarding switching vbus, you may want to read section 7.2.1.1 "Bus-powered Hubs" of usb 1.1. especially "Switching on the non-removable function is not required if the aggregate power drawn by it and the Hub Controller is less than one unit load."

14:03 <Joerg-Neo900> o.O

14:04 <Joerg-Neo900> how's that related?

14:04 <wpwrak> ah yes, VBUS >> VCC could be an interesting case

14:04 <wpwrak> that section talks about switching power to downstream ports, and even explicitly references non-removable devices

14:05 <Joerg-Neo900> we're not going to gamble and take chances regarding implementation of an available feature that seemingly is useful too

14:05 <wpwrak> well, we'll have it in v2. when we can see what to do with it.

14:06 <Joerg-Neo900> the spirit of Freerunner and Neo is "let the user see what to do with it"

14:08 <Joerg-Neo900> we really don't need to spend hours of discussion about implementing a clearly 100% safe and standard feature, or rather leave it out based on whatever highly specific evaluation for the sake of saving 2 0302 components on bom

14:13 <Joerg-Neo900> adding that tiny switch allows us to "unplug" the modem from VBUS. This alone is enough benefit to have it

14:14 <Joerg-Neo900> s/VBUS/USB/

14:15 <Joerg-Neo900> I don't see the purpose of writing a whitepaper why we considered this feature not worth implementing

14:18 <wpwrak> if you're concerned about VBUS >> VDD,perhaps the switch should then be controlled either by MODEM_EM, or route MODEM_EN to the SIM power silego, and control the VUSB_MODEM switch from the silego ? the silego would then implement EN_VBUS_MODEM = MODEM_EN && <i2c-settable-bit>

14:18 <Joerg-Neo900> note for final: consider connecting VBUS switch in to PHY VDD33 instead VBAT_SW

14:19 <Joerg-Neo900> yeah, good idea if we really need to make sure VBUS<VCC

14:19 <Joerg-Neo900> to be evaluated against modem DS

14:21 <Joerg-Neo900> we also could power the PHY from VEXT, and VBUS from PHY VDD33

14:21 <Joerg-Neo900> that's a topic for final though, not for v2

14:22 <wpwrak> controlling the power source from the things being supplied, even if only nominally in this case, seems a little risk-seeking ;)

14:22 <Joerg-Neo900> hm?

14:23 <Joerg-Neo900> sorry I can't parse that

14:24 <Joerg-Neo900> of course powering down PHY with modem is annoyingly laying-violating and introduces issues to (USB)driver init

14:25 <wpwrak> yes, the power/control flow has a loop. probably doesn't matter in this case, since it's not about really supplying power

14:27 <Joerg-Neo900> when we power PHY from VEXT then PHY will lose initialization on modem shztdown

14:28 <Joerg-Neo900> this is no issue neither for modem nor for ULPI hw, but it makes life of USB kernel driver devels a nightmare

14:29 <wpwrak> or the lives of those using the driver ;-)

14:29 <Joerg-Neo900> or that

14:30 <Joerg-Neo900> we would have to mandate modem-USB kernel driver getting unloaded prior to modem shutdown

14:30 <Joerg-Neo900> or have a special driver that re-initializes PHY whenever modem gets powered up

14:30 <Joerg-Neo900> not exactly a bad concept, but unusual

14:32 <Joerg-Neo900> anyway there are more signals than just VBUS on modem that need evaluation if save to be at VIO18 or even VBUS level while modem power shut down

14:32 <Joerg-Neo900> safe*

14:37 <Joerg-Neo900> http://wstaw.org/m/2016/12/20/plasma-desktopo17764.png

14:38 <Joerg-Neo900> seems VBUS is safe

14:39 <Joerg-Neo900> we need to check other signal lines though

14:39 <Joerg-Neo900> but it doesn't sound like this is catastrophic failure, so I assume we can hanle all this in software

14:39 <wpwrak> looks software-ish, yes

14:40 <Joerg-Neo900> :-)

14:40 <wpwrak> anyway, i've now moved VUSB_MODEM switch control to the SIM pwr silego

14:40 <Joerg-Neo900> hmm, ok

14:40 <Joerg-Neo900> :-)

14:41 <Joerg-Neo900> looks like a natural place for it

14:42 <Joerg-Neo900> the silego critters are bored anyway with our design ;-)

14:43 <wpwrak> they're perfect for this :)

14:43 <Joerg-Neo900> "I can do this too, of course! and could you please find me a TV? I'm bored"

14:44 <wpwrak> else, we'd already have another board between UPPER and LOWER, full of 74xx1g and 74xxx2g chips, plus a bunch of comparators :)

14:45 <Joerg-Neo900> nah, we prolly had way more clumsy less versatile perfect solutions for a lot of things

14:45 <Joerg-Neo900> possibly no dual SIM at all

14:46 <Joerg-Neo900> incl smartcard reader functionality

14:49 <Joerg-Neo900> and maybe our RF modem monitor would be snakeoil since it either would suffer from frequent false positives and thus suck battery empty by constantly awakening APE CPU, or it wouldn't detect low energy TX at all

14:50 <Joerg-Neo900> just like e.g. the SB sleeve will

14:51 <Joerg-Neo900> oh wait, do they even implement true RF detection? or only try to monitor a bus for events that never will show up there