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 ? > 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. > >> > > 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. -- balbi
Attachment:
signature.asc
Description: Digital signature
