Hi Marek,
On Tue, May 22, 2018 at 11:48 AM, Marek Vasut <[email protected]> wrote:
> On 05/22/2018 11:42 AM, Geert Uytterhoeven wrote:
>> On Mon, May 21, 2018 at 11:05 PM, Marek Vasut <[email protected]> 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 <[email protected]>
>>
>> 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.
>>> }
>>
>> 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.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
