Re: About the DRD mode implementation of DWC3 driver]
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
Re: About the DRD mode implementation of DWC3 driver]
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
Re: About the DRD mode implementation of DWC3 driver]
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
Re: About the DRD mode implementation of DWC3 driver]
Hi, On Wed, Apr 16, 2014 at 10:13:38AM +0800, Wang, Yu wrote: 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. ok, I heard reports of a few hundred IRQs firing when removing cable... I don't remember seeing any of that on OMAP5, I'll see if I can time to test it again and, hopefully, make this solid to be merged on v3.16. 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. thanks -- balbi signature.asc Description: Digital signature
Re: About the DRD mode implementation of DWC3 driver]
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. 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. 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. 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). 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
About the DRD mode implementation of DWC3 driver]
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 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. 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? 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. Agree. They can be discussed separately. 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? 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? 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
About the DRD mode implementation of DWC3 driver
Hi Balbi, 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. :( 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. And the most important thing is we implemented two low power states for dwc3 controller. D0i3hot and D0i3cold. If no cable connected, we will trigger D0i3cold which will power gate every clock/power used by dwc3 controller. 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). For ID/VBus detection, we are using PMIC to do detect. So we will also power gate the USB PHY for D0i3cold. 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. So with this PM design and DRD mode, we can't use your OTG mode. :( I want to get your suggestions for DRD mode of dwc3 driver. We add DRD support based on your otg.c or create new file drd.c? Thanks Yu -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About the DRD mode implementation of DWC3 driver
On Wed, Apr 09, 2014 at 02:08:32PM +0800, Wang, Yu wrote: Hi Balbi, 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. :( 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. And the most important thing is we implemented two low power states for dwc3 controller. D0i3hot and D0i3cold. If no cable connected, we will trigger D0i3cold which will power gate every clock/power used by dwc3 controller. 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). For ID/VBus detection, we are using PMIC to do detect. So we will also power gate the USB PHY for D0i3cold. 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. So with this PM design and DRD mode, we can't use your OTG mode. :( I want to get your suggestions for DRD mode of dwc3 driver. Why do you insist in tell role switching and PM are part of same thing? It's my understanding we need to implement proper pm runtime callbacks for D0i3* and leave role switching alone. We can make proper calls of pm runtime from phy driver to control PM state of dwc3 (for D0i3cold). Br, David We add DRD support based on your otg.c or create new file drd.c? Thanks Yu -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
