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

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

 



On 03/19/2018 02:56 PM, Vladimir Zapolskiy wrote:
> On 03/19/2018 03:48 PM, Marek Vasut wrote:
>> 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@xxxxxxxxx> 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@xxxxxxxxx>
>>>>>>>> Cc: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
>>>>>>>> Cc: Phil Edworthy <phil.edworthy@xxxxxxxxxxx>
>>>>>>>> Cc: Simon Horman <horms+renesas@xxxxxxxxxxxx>
>>>>>>>> Cc: Wolfram Sang <wsa@xxxxxxxxxxxxx>
>>>>>>>> Cc: linux-renesas-soc@xxxxxxxxxxxxxxx
>>>>>>>
>>>>>>> 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.
>>
> 
> IIRC suspend/resume are never executed in atomic context, and runtime
> suspend/resume are invoked in atomic context only if pm_runtime_irq_safe()
> is called (just a few drivers in vanilla uses it at the moment).
> 
> Nevertheless, the commit message does not say that the change is needed
> for future suspend/resume add-on.

Well, then drop this patch for now, I'll resubmit it later with the
suspend/resume series. I presume 2/2 can go in though, so I don't have
to resubmit it over and over again.

-- 
Best regards,
Marek Vasut



[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux