Re: [PATCH V2 RFC] mtd: spi-nor: intel: provide a range for poll_timout

2018-05-18 Thread Boris Brezillon
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

Re: [PATCH V2 RFC] mtd: spi-nor: intel: provide a range for poll_timout

2018-05-18 Thread Boris Brezillon
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

Re: [PATCH V2 RFC] mtd: spi-nor: intel: provide a range for poll_timout

2017-02-14 Thread Mika Westerberg
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

Re: [PATCH V2 RFC] mtd: spi-nor: intel: provide a range for poll_timout

2017-02-14 Thread Mika Westerberg
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

[PATCH V2 RFC] mtd: spi-nor: intel: provide a range for poll_timout

2017-02-13 Thread Nicholas Mc Guire
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.

[PATCH V2 RFC] mtd: spi-nor: intel: provide a range for poll_timout

2017-02-13 Thread Nicholas Mc Guire
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.