Re: [PATCH 1/2] PCI: rcar: Poll more often in rcar_pcie_wait_for_dl()

[Marek Vasut <marek.vasut@gmail.com>]

On 03/19/2018 02:43 PM, Vladimir Zapolskiy wrote:
> On 03/19/2018 12:56 PM, Marek Vasut wrote:
>> On 03/19/2018 11:53 AM, Geert Uytterhoeven wrote:
>>> Hi Marek,
>>>
>>> On Mon, Mar 19, 2018 at 10:53 AM, Marek Vasut <marek.vasut@gmail.com> wrote:
>>>> On 03/19/2018 09:38 AM, Simon Horman wrote:
>>>>> On Sun, Mar 18, 2018 at 11:52:52AM +0100, Marek Vasut wrote:
>>>>>> The data link active signal usually takes ~20 uSec to be asserted,
>>>>>> poll the bit more often to avoid useless delays in this function.
>>>>>>
>>>>>> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
>>>>>> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
>>>>>> Cc: Phil Edworthy <phil.edworthy@renesas.com>
>>>>>> Cc: Simon Horman <horms+renesas@verge.net.au>
>>>>>> Cc: Wolfram Sang <wsa@the-dreams.de>
>>>>>> Cc: linux-renesas-soc@vger.kernel.org
>>>>>
>>>>> Unless my eyes deceive me this seems to be quite a lot (100x) more often,
>>>>> but so be it.
>>>>
>>>> It's just a higher frequency to avoid slowdown when bringing the link up.
>>>
>>> No it isn't: you replaced a sleep by a delay, thus making it blocking.
>>
>> For much shorter period of time.
>>
>>> So this can spin for up to 50 ms (+ overhead)?
>>
>> That's what it did before too , it used msleep and now it uses udelay.
>>
> 
> msleep() does not spin, it reschedules the process.
> 
> Instead to find a balance you may want to play with usleep_range().

Which does not work in atomic context, which will be needed when using
this function in suspend/resume later on.

-- 
Best regards,
Marek Vasut