Hi Balbi, Thanks the quick response. Actually, our solution is familiar with your thinking. Due to we have to do "Power-On or Soft Reset" for disconnect and re-connect case, so driver need re-initialized all hardware registers. That's why we want to separate register initialization operation from software part (like sw structure init and endpoint initialization) However, we find that the hardware registers initialization is located in dwc3_gadget_init and 'dwc->gadget_driver' initialization is handled in dwc3_gadget_start.() So we can't full re-use these two functions. If all the hardware initialization can be extract into a new function which call by udc_start callback and also can be called for hibernation disconnect case, then it is fine. And for disconnect, our driver need to do some hardware clear work. For example, disable irq, clear events which haven't handled, and disable endpoints and so on. BTW: Besides that. In our design, we also support host mode, and also have one OTG driver to maintain the role switch and USB charger detection. For role switch, our implementation is not only set GCTL.PORTCAP. Also we implemented some API for OTG driver, for example: start_host/stop_host and start_peripheral/stop_peripheral. All device and host hardware initialization will be done in these API. So for connect/disconnect case, the driver will re-initialization the host or device stack. I saw your design is do all hardware initialization during kernel boot. And just use GCTL.PORTCAP to do the role switch. I haven't try this solution on intel platform. And not sure if is working with hibernation feature. Thanks, Regards, Yu -----Original Message----- From: Felipe Balbi [mailto:balbi@xxxxxx] Sent: Friday, August 02, 2013 3:07 PM To: Wang, Yu Y Cc: balbi@xxxxxx; Li, Jiebing; Linux USB Mailing List Subject: Re: About the hibernation feature implementation in dwc3 driver Hi, +linux-usb Always add linux-usb On Fri, Aug 02, 2013 at 05:33:32AM +0000, Wang, Yu Y wrote: > We are the USB3 driver developers from Intel. And also base on > Synopsys DWC USB3 OTG controller. good to see Intel is also using my driver. > We base on your driver to enabled hibernation feature for runtime pm > suspend both for device and host mode. > > We just want to check with you, is there any plan to implement > hibernation mode in the future? TI's SoCs don't support hibernation, none of them. It's not configured in the IP, so I'd have no way how to test it. > Because our changes was a little big for the hibernation mode feature > with your driver. It shouldn't. Based on what I read in the spec and the original Hack from Paul Zimmerman, hibernation should be very, very simple. > There are two conditions, one is enter suspended with cable connected, > another one is enter suspended without cable connected. no, there is only one condition. When there is no cable attached, there's nothing in any register to be initialized, so you don't need to save any context, just call the the setup functions directly and it should work next time you connect the cable. > For the first case, we can enter hibernation mode which will backup > internal states to u2pmu/u3pmu, and also can restore during the resume > flow. There will be few change for this case. right, just a few. > But for the second case, followed spec. The controller should not > enter hibernation mode. Then there will be no any backup to > u2pmu/u3pmu, so we have to re-initialization whole driver stack. right(-ish), but that's already all factored-out into reusable functions. > And we are consider to use add/remove the platform device to trigger > probe/remove to achieve this purpose. But all data structures will be > free and re-alloc. This will be make impacts for the performance. don't do that, it's unnecessary. > So our major changes is divide the probe/remove and udc_start/udc_stop > to two part. All hardware settings will be move to another special > functions which will be called after cable connect/disconnect. heh, gotta revert that part, it's totally unnecessary. > So hope you can provide your hibernation solutions as the reference. Please continue this discussion in linux-usb@xxxxxxxxxxxxxxx -- 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
