Hi, Peter Chen <hzpeterchen@xxxxxxxxx> writes: >> >> >> >> > So, unless we use OTG FSM defined in OTG spec, we should not mention >> >> >> >> > "OTG" in Linux, right? >> >> >> >> >> >> >> >> to avoid confusion with the terminology, yes. With that settled, let's >> >> >> >> figure out how you can deliver what your marketting guys are asking of >> >> >> >> you. >> >> >> >> >> >> >> > >> >> >> > Since nxp SoC claims they are OTG compliance, we need to pass usb.org >> >> >> > test. The internal bsp has passed PET test, and formal compliance test >> >> >> > is on the way (should pass too). >> >> >> > >> >> >> > The dual-role and OTG compliance use the same zImage, but different >> >> >> > dtb. >> >> >> >> >> >> okay, that's good to know. Now, the question really is: considering we >> >> >> only have one user for this generic OTG FSM layer, do we really need to >> >> >> make it generic at all? I mean, just look at how invasive a change that >> >> >> is. >> >> > >> >> > If the chipidea is the only user for this roger's framework, I don't >> >> > think it is necessary. In fact, Roger introduces this framework, and >> >> > the first user is dwc3, we think it can be used for others. Let's >> >> >> >> Right, we need to look at the history of dwc3 to figure out why the >> >> conclusion that dwc3 needs this was made. >> >> >> >> Roger started working on this framework when Power on Reset section of >> >> databook had some details which weren't always clear and, for safety, we >> >> always had reset asserted for a really long time. It was so long (about >> >> 400 ms) that resetting dwc3 for each role swap was just too much. >> >> >> >> Coupled with that, the OTG chapter wasn't very clear either on >> >> expections from Host and Peripheral side initialization in OTG/DRD >> >> systems. >> >> >> >> More recent version of dwc3 databook have a much better description of >> >> how and which reset bits _must_ be asserted and which shouldn't be >> >> touched unless it's for debugging purposes. When I implemented that, our >> >> ->probe() went from 400ms down to about 50us. >> >> >> >> Coupled with that, the OTG chapter also became a lot clearer to the >> >> point that it states you just don't initialize anything other than the >> >> OTG block, and just wait for OTG interrupt to do whatever it is you need >> >> to do. >> >> >> >> This meant that we could actually afford to do full reinitialization of >> >> dwc3 on role swap (it's now only 50us anyway) and we knew how to swap >> >> roles properly. >> >> >> >> (The reason for needing soft-reset during role swap is kinda long. But >> >> in summary dwc3 shadows register writes to both host and peripheral >> >> sides) >> >> >> >> > just discuss if it is necessary for dual-role switch. >> >> >> >> fair. However, if we have a single user we don't have a Generic >> >> layer. There's not enough variance to come up with truly generic >> >> architecture for this. >> >> >> >> -- >> > >> > I have put some points in my last reply [1], I summery it here to >> > see if a generic framework is deserved or not? >> > >> > 1. If there are some parts we can use during the role switch >> > - The common start/stop host and peripheral operation >> > eg, when switch from host to peripheral, all drivers can use >> > usb_remove_hcd to finish it. >> >> a UDC such as dwc3 already implements start/stop for peripheral and >> host. Why would go through and indirection layer that just comes back to >> us? (well, dwc3's host side, start/stop translates to adding/removing >> xhci-plat's device) >> >> > - A common workqueue to handle vbus and id event >> >> I already have a threaded IRQ handler. Why do I need a workqueue? >> > > I know it can be done in individual driver, don't you think > we need a common part to manage the dual-role switch process, A common part will be a requirement when we have at least 3 users for it. Right now there's only one. So how can this be common at all? > since dual-role switch is used more and more common, and > there are so many switch methods: > > - ID pin > - sysfs > - type-c > - OTG FSM > - Registers > > Maybe Roger's framework is a little complicated, but if it is the > correct direction, we can improve it. IMO, we don't have enough users -- balbi
Attachment:
signature.asc
Description: PGP signature
