Hi, Thinh Nguyen <Thinh.Nguyen@xxxxxxxxxxxx> writes: >>>>>>>> "Power Down Scale (PwrDnScale) >>>>>>>> The USB3 suspend_clk input replaces pipe3_rx_pclk as a clock source >>>>>>>> to a small part of the USB3 controller that operates when the SS >>>>>>>> PHY is in its lowest power (P3) state, and therefore does not provide a clock. >>>>>>>> The Power Down Scale field specifies how many suspend_clk periods >>>>>>>> fit into a 16 kHz clock period. When performing the division, round >>>>>>>> up the remainder. >>>>>>>> For example, when using an 8-bit/16-bit/32-bit PHY and 25-MHz >>>>>>>> Suspend clock, Power Down Scale = 25000 kHz/16 kHz = 13'd1563 >>>>>>>> (rounder up) >>>>>>>> Note: >>>>>>>> - Minimum Suspend clock frequency is 32 kHz >>>>>>>> - Maximum Suspend clock frequency is 125 MHz" >>>>>>> Cool, now do we have an upper bound for how many clock cycles it >>>>>>> takes to wake up the PHY? >>>>>> My understanding is this ep command does not wake up the SS PHY, the >>>>>> SS PHY still stays at P3 when execute this ep command. The time >>>>>> required here is to wait controller complete something for this ep >>>>>> command with 32K clock. >>>>> Sorry I made a mistake. You're right. Just checked with one of the RTL >>>>> engineers, and it doesn't need to wake up the phy. However, if it is >>>>> eSS speed, it may take longer time as the command may be completing >>>>> with the suspend clock. >>>>> >>>> What's the value for GCTL[7:6]? >>> 2'b00 >>> >>> Thanks >>> Li Jun >> (Sorry for the delay reply) >> >> If it's 0, then the ram clock should be the same as the bus_clk, which >> is odd since you mentioned that the suspend_clk is used instead while in P3. > > Just checked with the RTL engineer, even if GCTL[7:6] is set to 0, > internally it can still run with suspend clock during P3. > >> Anyway, I was looking for a way maybe to improve the speed during >> issuing a command. One way is to set GUSB3PIPECTL[17]=0, and it should >> wakeup the phy anytime. I think Felipe suggested it. It's odd that it >> doesn't work for you. I don't have other ideas beside increasing the >> command timeout. >> > > In any case, increasing the timeout should be fine with me. It maybe > difficult to determine the max timeout base on the slowest clock rate > and number of cycles. Different controller and controller versions > behave differently and may have different number of clock cycles to > complete a command. > > The RTL engineer recommended timeout to be at least 1ms (which maybe > more than the polling rate of this patch). I'm fine with either the rate > provided by this tested patch or higher. A whole ms waiting for a command to complete? Wow, that's a lot of time blocking the CPU. It looks like, perhaps, we should move to command completion interrupts. The difficulty here is that we issue commands from within the interrupt handler and, as such, can't wait_for_completion(). Meanwhile, we will take the timeout increase I guess, otherwise NXP won't have a working setup. -- balbi
Attachment:
signature.asc
Description: PGP signature
