Re: [PATCH V3 05/10] ARM: OMAP2+: SmartReflex: introduce a busy loopcondition test macro

[J, KEERTHY]

On Fri, May 4, 2012 at 2:42 PM, AnilKumar, Chimata <anilkumar@xxxxxx> wrote:
> On Thu, Apr 26, 2012 at 23:10:36, J, KEERTHY wrote:
>> From: Jean Pihet <j-pihet@xxxxxx>
>>
>> Now that omap_test_timeout is only accessible from mach-omap2/,
>> introduce a similar function for SR.
>>
>> This change makes the SmartReflex implementation ready for the move
>> to drivers/.
>>
>> Signed-off-by: Jean Pihet <j-pihet@xxxxxx>
>> Signed-off-by: J Keerthy <j-keerthy@xxxxxx>
>> ---
>>  arch/arm/mach-omap2/smartreflex.c |   12 ++++++------
>>  include/linux/power/smartreflex.h |   23 ++++++++++++++++++++++-
>>  2 files changed, 28 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c
>> index d859277..acef08d 100644
>> --- a/arch/arm/mach-omap2/smartreflex.c
>> +++ b/arch/arm/mach-omap2/smartreflex.c
>> @@ -289,9 +289,9 @@ static void sr_v1_disable(struct omap_sr *sr)
>>        * Wait for SR to be disabled.
>>        * wait until ERRCONFIG.MCUDISACKINTST = 1. Typical latency is 1us.
>>        */
>> -     omap_test_timeout((sr_read_reg(sr, ERRCONFIG_V1) &
>> -                     ERRCONFIG_MCUDISACKINTST), SR_DISABLE_TIMEOUT,
>> -                     timeout);
>> +     sr_test_cond_timeout((sr_read_reg(sr, ERRCONFIG_V1) &
>> +                          ERRCONFIG_MCUDISACKINTST), SR_DISABLE_TIMEOUT,
>> +                          timeout);
>>
>>       if (timeout >= SR_DISABLE_TIMEOUT)
>>               dev_warn(&sr->pdev->dev, "%s: Smartreflex disable timedout\n",
>> @@ -334,9 +334,9 @@ static void sr_v2_disable(struct omap_sr *sr)
>>        * Wait for SR to be disabled.
>>        * wait until IRQSTATUS.MCUDISACKINTST = 1. Typical latency is 1us.
>>        */
>> -     omap_test_timeout((sr_read_reg(sr, IRQSTATUS) &
>> -                     IRQSTATUS_MCUDISABLEACKINT), SR_DISABLE_TIMEOUT,
>> -                     timeout);
>> +     sr_test_cond_timeout((sr_read_reg(sr, IRQSTATUS) &
>> +                          IRQSTATUS_MCUDISABLEACKINT), SR_DISABLE_TIMEOUT,
>> +                          timeout);
>>
>>       if (timeout >= SR_DISABLE_TIMEOUT)
>>               dev_warn(&sr->pdev->dev, "%s: Smartreflex disable timedout\n",
>> diff --git a/include/linux/power/smartreflex.h b/include/linux/power/smartreflex.h
>> index 884eaee..78b795e 100644
>> --- a/include/linux/power/smartreflex.h
>> +++ b/include/linux/power/smartreflex.h
>> @@ -22,7 +22,7 @@
>>
>>  #include <linux/types.h>
>>  #include <linux/platform_device.h>
>> -
>> +#include <linux/delay.h>
>>  #include <plat/voltage.h>
>>
>>  /*
>> @@ -168,6 +168,27 @@ struct omap_sr {
>>  };
>>
>>  /**
>> + * test_cond_timeout - busy-loop, testing a condition
>> + * @cond: condition to test until it evaluates to true
>> + * @timeout: maximum number of microseconds in the timeout
>> + * @index: loop index (integer)
>> + *
>> + * Loop waiting for @cond to become true or until at least @timeout
>> + * microseconds have passed.  To use, define some integer @index in the
>> + * calling code.  After running, if @index == @timeout, then the loop has
>> + * timed out.
>> + *
>> + * Copied from omap_test_timeout */
>> +#define sr_test_cond_timeout(cond, timeout, index)           \
>> +({                                                           \
>> +     for (index = 0; index < timeout; index++) {             \
>> +             if (cond)                                       \
>> +                     break;                                  \
>> +             udelay(1);                                      \
>> +     }                                                       \
>> +})
>
> I think we can use time_after()/time_before() APIs for timeout and cpu_relax() for
> tight loops instead of udelay().

cpu_relax() changes the priority everytime to low and will yield to
another thread.
Considering that we are checking the condition every microsecond does it make
some saving using cpu_relax().

>
> Regards
> AnilKumar



-- 
Regards and Thanks,
Keerthy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/