On 05/22/2018 12:33 PM, Geert Uytterhoeven wrote:
> Hi Marek,
>
> On Tue, May 22, 2018 at 11:48 AM, Marek Vasut <marek.vasut@xxxxxxxxx> wrote:
>> On 05/22/2018 11:42 AM, Geert Uytterhoeven wrote:
>>> On Mon, May 21, 2018 at 11:05 PM, Marek Vasut <marek.vasut@xxxxxxxxx> 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.
>>>> Use udelay() instead of usleep() for such a small delay as suggested
>>>> by the timer documentation and because this will be used in atomic
>>>> context later on when the suspend/resume patches land.
>>>>
>>>> Signed-off-by: Marek Vasut <marek.vasut+renesas@xxxxxxxxx>
>>>
>>> Thanks for your patch!
>>>
>>>> --- a/drivers/pci/host/pcie-rcar.c
>>>> +++ b/drivers/pci/host/pcie-rcar.c
>>>> @@ -529,13 +529,13 @@ static void phy_write_reg(struct rcar_pcie *pcie,
>>>>
>>>> static int rcar_pcie_wait_for_dl(struct rcar_pcie *pcie)
>>>> {
>>>> - unsigned int timeout = 10;
>>>> + unsigned int timeout = 10000;
>>>>
>>>> while (timeout--) {
>>>> if ((rcar_pci_read_reg(pcie, PCIETSTR) & DATA_LINK_ACTIVE))
>>>> return 0;
>>>>
>>>> - msleep(5);
>>>> + udelay(5);
>>>
>>> + cpu_relax()?
>>
>> Is it safe to use in atomic context ? Because of that suspend/resume thing.
>
> Yes.
OK, added.
>>>> }
>>>
>>> if this ever happens, it will have blocked for more than 50 ms...
>>
>> Well yes, so did the previous thing.
>
> No, the previous thing slept. Big difference.
True
--
Best regards,
Marek Vasut
