Hi, On Wed, Apr 09, 2014 at 02:08:32PM +0800, Wang, Yu wrote: > Glad to see the OTG mode is prepare to support in your dwc3-role-switch > branch. But it is not fit for intel Merrfield/Moorfield platforms. :( that's not what I heard when I asked some friends to test that branch on different platforms. It's certainly not perfect yet and that's why the code isn't merged in mainline, but claiming that it's not fit for Merrifield/Moorfield is just a lie. > The reason is we implemented DRD mode instead of OTG mode. So the > GCTL.PortCapDir will be set as 01 for host mode, and 10 for device mode. from a SW perspective there is *no* difference. The only reason for using PortCapDir is to cope with platforms which want to switch roles but have screwed up ID pin reporting. And since most of the platforms actually have tha problem, it's just easier to implement it that way. > And the most important thing is we implemented two low power states for > dwc3 controller. D0i3hot and D0i3cold. what does that have to do with role switching ? Power management and role switching are two completely different problems. You can have full DRD without PM the same way you can have full PM without DRD. > If no cable connected, we will trigger D0i3cold which will power gate > every clock/power used by dwc3 controller. that's not in mainline though, why should I care ? Show me code adding support for D0i3cold for dwc3 then we can talk. Until then, I'll continue assuming there's no such PM state and continue with happy hacking sessions. > And entering D0i3hot with hibernation mode when acting as host mode > (micro A cable connected), also during device mode(micro B cable connected > to PC host). Current driver also doesn't support any runtime PM, so why should I care about your out-of-tree changes ? If you have any code which is not in mainline and I change something in mainline you have to deal to with it, not me. I just cannot spend time imagining all twisted scenarios Vendors (including my employer, for that matter) want to support with whatever hacked up version of mainline drivers they might have. My plan is to *not* add a lot of PM support until I know all other features are functional. When I'm happy with those features and know they have been thoroughly tested on *all* users of dwc3 then we can all get together in a conference (maybe have a DWC3 mini-summit or whatever) and discuss how we're gonna implement PM *together*. Since the driver is used by many different vendors, it would be unfair for me to treat Intel (or any vendor, really) differently just because someone dropped me an email commenting about all the out-of-tree changes they have. > For ID/VBus detection, we are using PMIC to do detect. So we will also > power gate the USB PHY for D0i3cold. yeah, everybody does that. Everybody I've seen so far have moved the analog comparators for VBUS and ID out of the PHY and into the PMIC. We even have a very nice framework to cope with that (see drivers/extcon/extcon-palmas.c for an example). > When we plug in micro A/B cable, the PMIC will report the ID/VBus change > event, then driver will force controller resume to D0 from D0i3cold. Due > to we haven't do any backup before entering D0i3cold, so we have to > re-initialize all host/device portion registers with setting > GCTL.PortCapDir to 01 or 10. yeah, but this is just how *you* decided to implement this for your employer and, guess what, all of that is out-of-tree and, by all practical means wrt mainline kernel, it's all non-existent. This means I'm free to implement all of this any way I feel it's best considering the diverse user-base we have on this driver. Quite frankly, resetting the IP is only necessary iff all power rails are cut, in that case, sure, we will reset the IP and start all over, but we don't want to cut all power while we're attached to host, which means we don't need to reset the IP, a simple context restore is enough in most cases. Also, when we implement hibernation (dwc3's hibernation, that is) we won't need to reset the IP even if we go all the way down to D0i3cold because the IP keeps all context in a scratch buffer we allocate during probe. > So with this PM design and DRD mode, we can't use your OTG mode. :( that's not my problem though, is it ? Since *your* PM design isn't available in mainline anyway. Not to mention that *my* DRD mode wasn't merged either, even though I have good reports from some friends stating it's working in 90% of the cases. > We add DRD support based on your otg.c or create new file drd.c? Well, since I've already been working on it (well, George Cherian - now in Cc - was the originator) I rather continue on it together with George. Thank you -- balbi
Attachment:
signature.asc
Description: Digital signature
