On Tue, 14 Feb 2017 11:47:24 +0200
Mika Westerberg wrote:
> On Mon, Feb 13, 2017 at 09:13:42AM +0100, Nicholas Mc Guire wrote:
> > The overall poll time here is INTEL_SPI_TIMEOUT * 1000 which is
> > 5000 * 1000 - so 5seconds and it is coded as a tight loop here
On Tue, 14 Feb 2017 11:47:24 +0200
Mika Westerberg wrote:
> On Mon, Feb 13, 2017 at 09:13:42AM +0100, Nicholas Mc Guire wrote:
> > The overall poll time here is INTEL_SPI_TIMEOUT * 1000 which is
> > 5000 * 1000 - so 5seconds and it is coded as a tight loop here delay_us
> > to
On Mon, Feb 13, 2017 at 09:13:42AM +0100, Nicholas Mc Guire wrote:
> The overall poll time here is INTEL_SPI_TIMEOUT * 1000 which is
> 5000 * 1000 - so 5seconds and it is coded as a tight loop here delay_us
> to readl_poll_timeout() is set to 0. As this is never called in an atomic
> context
On Mon, Feb 13, 2017 at 09:13:42AM +0100, Nicholas Mc Guire wrote:
> The overall poll time here is INTEL_SPI_TIMEOUT * 1000 which is
> 5000 * 1000 - so 5seconds and it is coded as a tight loop here delay_us
> to readl_poll_timeout() is set to 0. As this is never called in an atomic
> context
The overall poll time here is INTEL_SPI_TIMEOUT * 1000 which is
5000 * 1000 - so 5seconds and it is coded as a tight loop here delay_us
to readl_poll_timeout() is set to 0. As this is never called in an atomic
context sleeping should be no issue and there is no reasons for the
tight-loop here.
The overall poll time here is INTEL_SPI_TIMEOUT * 1000 which is
5000 * 1000 - so 5seconds and it is coded as a tight loop here delay_us
to readl_poll_timeout() is set to 0. As this is never called in an atomic
context sleeping should be no issue and there is no reasons for the
tight-loop here.
6 matches
Mail list logo