Re: [RFC 1/3] ath9k: Fix BTCOEX timer triggering comparision

[Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>]

Hi Raj,

On Monday 27 August 2012 04:23 PM, Rajkumar Manoharan wrote:
> On Mon, Aug 27, 2012 at 03:00:07PM +0530, Mohammed Shafi Shajakhan wrote:
>> Hi Raj,
>>
>>
>> On Friday 24 August 2012 10:28 PM, Manoharan, Rajkumar wrote:
>>> On Fri, Aug 24, 2012 at 07:47:29PM +0530, Mohammed Shafi Shajakhan wrote:
>>>> From: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
>>>>
>>>> Its safer to convert btcoex_period to 'us' while
>>>> comparing with btcoex_no_stomp which is in 'us'.
>>>> Did not find any functionality issues being fixed,
>>>> as the generic hardware timer triggers are usually
>>>> refreshed with the newer duty cycle.
>>>>
>>> In which way it is safer? What does the patch fix? It was intentionally
>>> converted to msec by "ath9k: keep btcoex period in milliseconds".
>>
>> we got btcoex_period is in 'us' while 'btcoex_no_stomp' in 'ms'
>> when we are going to compare , both of them had to been in same time
>> units. Rather then mentioning it as 'safer' the commit log should say
>> its 'more correct' :-)  previously the comparison happened with same
>> timeunits(ms).
>>
>> I could not find any functionality issue being fixed,
>> but i saw the difference, when putting debug prints for
>> btcoex->btcoex_period, btcoex->btcoex_no_stomp), there was so
>> much difference. Yet the check itself
>>
>>          if (btcoex->btcoex_period != btcoex->btcoex_no_stomp)
>>
>> seems to be true for almost all the cases. So fine with changing the
>> commit log ?
>>
>> thanks a lot for the review!
>>
> Oops. Its a regression. Can you please include the commit "ath9k: keep btcoex
> period in milliseconds" that causes this regression in your commit log.
>

sure Raj, i would do it, it did not make any difference :-)
the h/w timers are usually stopped and started.
again, thanks for you kind review!


-- 
thanks,
shafi