On Fri, Aug 24, 2012 at 07:47:29PM +0530, Mohammed Shafi Shajakhan wrote:
> From: Mohammed Shafi Shajakhan <[email protected]>
>
> 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".
-Rajkumar
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 <[email protected]>
>>
>> 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!
--
thanks,
shafi