Re: About the DRD mode implementation of DWC3 driver]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

>
>> > > 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.

>
>> > > 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.
>> 
>> Get it. So we can treat this solution is working w/o PM implementation
>> so far. And maybe we need to re-design DRD/OTG when we consider to
>> support PM, right?
>
>We probably don't need to redesign anything when adding PM. What we need
>is that when we start to add PM support to this driver, in case there is
>any regression, we find out why there is a regression. Then we solve it
>properly, after looking at logs and fully understanding what's breaking
>the driver.
>
>In any case, that's something that won't happen in mainline for at least
>a couple more major releases since there are still quite a few changes
>pending.

Get your point. Thanks

>
>> > 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?

>
>> > > 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).
>> >
>> 
>> Thanks for pointing it out. We will use it too.
>> 
>> > > 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.
>> 
>> Yes. I know what is your mean. Just I don't know how to implement
>> hibernation mode for DRD mode. The synopsys DWC3 spec haven't mentioned
>> it.
>
>one thing has nothing to do with the other. By the time hibernation
>kicks in, the IP is already set on one role and won't change unless you
>revert cable or HNP - for those which support it - kicks in.
>
>In both cases, dwc3 *must* first wake up before even figuring out what
>it is the user wants it to do.

The situation is too complex. Let's discuss OTG/DRD hibernation later
after get OTG/DRD mode solution get confirmed.

>
>> 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.

>
>> > > 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.

>
>[1] http://marc.info/?l=linux-kernel&m=139648140104265
>
>-- 
>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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux