> > On Thu, Feb 13, 2020 at 04:57:24PM +0000, Srivastava, Shobhit wrote: > > > On 2/12/20 12:34 AM, Rajat Jain wrote: > > ... > > > > I wonder is it enough to have this quick toggling only or is time or > > > actually number of clock cycles dependent? Now there is no delay > > > between but I'm thinking if it needs certain number cycles does this > > > still work when using low ssp_clk rates similar than in commit > d0283eb2dbc1 ("spi: > > > pxa2xx: Add output control for multiple Intel LPSS chip selects"). > > > > > > I'm thinking can this be done only once after resume and may other > > > LPSS blocks need the same? I.e. should this be done in drivers/mfd/intel- > lpss.c? > > > This behavior is seen after S0ix resume, but it is not seen after S3 resume. > > I already commented in the other thread about this. > > Have you checked what's going on in intel_lpss_suspend() and > intel_lpss_resume() for your case? Yes, I checked those functions and they look fine. I even dumped all the relevant registers for both S3 resume & S0ix resume case. All registers were same except the SSCR0. > Is intel_lpss_prepare() called during S0ix exit? Yes, it is called during S0ix entry, before the suspend callback. > > I am thinking that it happens because we are not enabling the SSP after > resume. > > It is deferred until we need to send data. By enabling the SSP in resume, I > don’t see the issue. > > For S3, I think BIOS re-enables the SSP in resume flow. > > -- > With Best Regards, > Andy Shevchenko >