On Tue, Apr 15, 2014 at 09:53:49AM -0500, Felipe Balbi wrote: >Hi, > >On Tue, Apr 15, 2014 at 06:29:20PM +0800, Wang, Yu wrote: >> On Fri, Apr 11, 2014 at 06:19:57PM -0500, Felipe Balbi wrote: >> >Hi, >> > >> >On Fri, Apr 11, 2014 at 10:23:38AM +0800, Wang, Yu wrote: >> >> Hi Balbi, >> >> >> >> At first, thank you to help give the response in patience. >> >> >> >> > 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. >> >> > >> >> >> >> Can I get your friends' email address if they are in Intel? I would like to >> > >> >You already have that. Just look at Cc list. >> > >> >> contact them to make the branch work on my Merrifield/Moorefield board too. >> >> Currently I can't see any link change event with the branch. >> > >> >how did you test it ? According to [1] Merrifield won't work for more >> >than 20s or so with v3.14 and, since there is no resolution on the >> >thread, I assume today's mainline won't work either. >> > >> >Anyway, if you really did test, test again with enabling verbose debug >> >on dwc3 and show me the logs, I'm interested in what the IP is doing. >> >> Yes. As you said, the v3.14 haven't get stable so far on Merrifield >> platform. So I tried to back port your dwc3-role-switch branch solution >> to our v3.10 base and verified. > >That's no the same. What if you missed something ? What if it didn't >work because you broke it while backporting ? I don't know that because >you never showed me your backported version, also did you test on v3.10 >vanilla or v3.10 + Intel's patches + dwc3-role-switch backport ? Yes. That is why I will try v3.14 original dwc3-role-switch code to double confirm. You can ignore this result first. I will share the v3.14 result to you after the stability issue fixed. > >> I will waiting v3.14 get ready and do the test again to double confirm. >> I will let you know the result. Sorry cause the misunderstanding for >> you. > >ok, just next time make sure to be extra clear about your setup. If I >didn't have reports from one of your colleagues that the patches were >working, I could've spent time debugging something that doesn't exist. Understood. Sorry for the mistake made by the new comer. I will provide the result with extra clear environment for you in the future. > >> >> > > 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. >> >> > >> >> >> >> Ok. Just confirm with you that you think it's not a matter to use >> >> GCTL.PortCapDir or OCTL.PeriMode to switch role, right? >> > >> >As of today, I don't see a difference. Things *can* change though. We >> >can find out more details about the HW which forces us to use one of the >> >other. >> >> I will help to try both DRD/OTG solution with your design on Merrifield >> when v3.14 get stable on it. > >ok, but you probably want to use v3.15-rc1 instead of v3.14. > >> >> > 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. >> >> > >> >> >> >> Understand. What are the other features you mean that need thorough testing >> >> before adding PM support? >> > >> >DRD for one. Then there is a redesign of parts of the gadget API that I >> >want to do before PM too. Then there is the whole Link Power Management >> >(which has *nothing* to do with Linux PM - system or runtime; we can put >> >the USB bus in low power mode even though we don't gate any of the USB >> >IP's clocks or power rails). >> >> Get it. I think your mean is the U1/U2, right? > >yup > >> >> And also for OTG hibernation mode. If we power gate the USB PHY during >> >> OTG hibernation mode, and using PMIC to do ID/VBUS detection. I don't >> >> know if there have any issues. >> > >> >Until we get there, we won't know. >> > >> >> > > 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. >> >> > >> >> >> >> Maybe I should add more explanation on the purpose of this email. I >> >> was not complaining you on your codes. Just wanted to discuss with you >> >> on our solution in order to improve our codes acceptable in community. >> > >> >sure, that's always good; but you can't expect me to consider - or even >> >know about - out-of-tree patches. >> >> Yes. You are correct. Sorry for cause the misunderstanding. > >np > >> >> > > 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 >> >> >> >> Do you have a first version that I can take a look? Since I'm working >> >> on it too, I would like to avoid conflict at the beginning. Thanks. >> > >> >see my dwc3-role-switch branch in k.org. And since you're asking, it >> >makes me wonder again how did you test my patches ? I mean, you _did_ >> >claim they don't work and yet you don't know where to get them from ? >> >> No No. My mean is if there have other local designs which haven't merged >> into your dwc3-role-switch branch. > >nope... Anyway, all my code is in my k.org tree. Get it. Thanks. > >-- >balbi -- 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
