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. -- Best regards, Marek Vasut
