[1/2] PCI: rcar: Poll more often in rcar_pcie_wait_for_dl()
diff mbox series

Message ID 20180318105253.30532-1-marek.vasut+renesas@gmail.com
State Superseded
Delegated to: Lorenzo Pieralisi
Headers show
Series
  • [1/2] PCI: rcar: Poll more often in rcar_pcie_wait_for_dl()
Related show

Commit Message

Marek Vasut March 18, 2018, 10:52 a.m. UTC
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
---
 drivers/pci/host/pcie-rcar.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Comments

Simon Horman March 19, 2018, 8:38 a.m. UTC | #1
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.

Reviewed-by: Simon Horman <horms+renesas@verge.net.au>


> ---
>  drivers/pci/host/pcie-rcar.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
> index 93d59f15c589..099998f1923a 100644
> --- a/drivers/pci/host/pcie-rcar.c
> +++ b/drivers/pci/host/pcie-rcar.c
> @@ -528,13 +528,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);
>  	}
>  
>  	return -ETIMEDOUT;
> -- 
> 2.16.2
>
Marek Vasut March 19, 2018, 9:53 a.m. UTC | #2
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.

> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> 
> 
>> ---
>>  drivers/pci/host/pcie-rcar.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
>> index 93d59f15c589..099998f1923a 100644
>> --- a/drivers/pci/host/pcie-rcar.c
>> +++ b/drivers/pci/host/pcie-rcar.c
>> @@ -528,13 +528,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);
>>  	}
>>  
>>  	return -ETIMEDOUT;
>> -- 
>> 2.16.2
>>
Geert Uytterhoeven March 19, 2018, 10:53 a.m. UTC | #3
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.
So this can spin for up to 50 ms (+ overhead)?

>>> --- a/drivers/pci/host/pcie-rcar.c
>>> +++ b/drivers/pci/host/pcie-rcar.c
>>> @@ -528,13 +528,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);
>>>      }
>>>
>>>      return -ETIMEDOUT;

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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
Marek Vasut March 19, 2018, 10:56 a.m. UTC | #4
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.

>>>> --- a/drivers/pci/host/pcie-rcar.c
>>>> +++ b/drivers/pci/host/pcie-rcar.c
>>>> @@ -528,13 +528,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);
>>>>      }
>>>>
>>>>      return -ETIMEDOUT;
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> 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
>
Vladimir Zapolskiy March 19, 2018, 1:43 p.m. UTC | #5
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().

--
With best wishes,
Vladimir
Marek Vasut March 19, 2018, 1:48 p.m. UTC | #6
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.
Vladimir Zapolskiy March 19, 2018, 1:56 p.m. UTC | #7
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@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.
> 

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.

--
With best wishes,
Vladimir
Marek Vasut March 19, 2018, 2:04 p.m. UTC | #8
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@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.
>>
> 
> 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.
Lorenzo Pieralisi April 25, 2018, 2:13 p.m. UTC | #9
Hi Marek,

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
> ---
>  drivers/pci/host/pcie-rcar.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

I assume this patch is still a valid change, I noticed you split this
series but I think this patch was not updated so I should take it as-is.

Please let me know.

Thanks,
Lorenzo

> diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
> index 93d59f15c589..099998f1923a 100644
> --- a/drivers/pci/host/pcie-rcar.c
> +++ b/drivers/pci/host/pcie-rcar.c
> @@ -528,13 +528,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);
>  	}
>  
>  	return -ETIMEDOUT;
> -- 
> 2.16.2
>
Marek Vasut April 25, 2018, 3:49 p.m. UTC | #10
On 04/25/2018 04:13 PM, Lorenzo Pieralisi wrote:
> Hi Marek,
> 
> 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
>> ---
>>  drivers/pci/host/pcie-rcar.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> I assume this patch is still a valid change, I noticed you split this
> series but I think this patch was not updated so I should take it as-is.
> 
> Please let me know.

The discussion from a month ago would indicate that I need to resubmit it.

Patch
diff mbox series

diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
index 93d59f15c589..099998f1923a 100644
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
@@ -528,13 +528,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);
 	}
 
 	return -ETIMEDOUT;