RE: Re: [PATCH] spi: pxa2xx: Add CS control clock quirk

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 
> 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
> 





[Index of Archives]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux