Message ID | 1354575357-24221-1-git-send-email-jcd@tribudubois.net |
---|---|
State | New |
Headers | show |
On 12/04/2012 02:55 AM, Jean-Christophe DUBOIS wrote: > Check for a 0 "distance" value to avoid infinite loop when the > expired FCR timer was not programed with auto-increment. > > With this change the behavior is coherent with the same type > of code in the exynos4210_gfrc_restart() function in the same > file. > > Linux seems to mostly use this timer with auto-increment > which explain why it is not a problem most of the time. > > However other OS might have a problem with this if they > don't use the auto-increment feature. > > Signed-off-by: Jean-Christophe DUBOIS <jcd@tribudubois.net> > --- > hw/exynos4210_mct.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/hw/exynos4210_mct.c b/hw/exynos4210_mct.c > index e79cd6a..37dbda9 100644 > --- a/hw/exynos4210_mct.c > +++ b/hw/exynos4210_mct.c > @@ -568,7 +568,7 @@ static void exynos4210_gfrc_event(void *opaque) > /* Reload FRC to reach nearest comparator */ > s->g_timer.curr_comp = exynos4210_gcomp_find(s); > distance = exynos4210_gcomp_get_distance(s, s->g_timer.curr_comp); > - if (distance > MCT_GT_COUNTER_STEP) { > + if (distance > MCT_GT_COUNTER_STEP || !distance) { > distance = MCT_GT_COUNTER_STEP; > } > exynos4210_gfrc_set_count(&s->g_timer, distance); > Reviewed-by: Evgeny Voevodin <e.voevodin@samsung.com> P.S.: Next time, please, don't forget to CC appropriate people to not let them miss your patch.
On 3 December 2012 22:55, Jean-Christophe DUBOIS <jcd@tribudubois.net> wrote: > Check for a 0 "distance" value to avoid infinite loop when the > expired FCR timer was not programed with auto-increment. > > With this change the behavior is coherent with the same type > of code in the exynos4210_gfrc_restart() function in the same > file. > > Linux seems to mostly use this timer with auto-increment > which explain why it is not a problem most of the time. > > However other OS might have a problem with this if they > don't use the auto-increment feature. > > Signed-off-by: Jean-Christophe DUBOIS <jcd@tribudubois.net> Thanks, applied to arm-devs.next. -- PMM
diff --git a/hw/exynos4210_mct.c b/hw/exynos4210_mct.c index e79cd6a..37dbda9 100644 --- a/hw/exynos4210_mct.c +++ b/hw/exynos4210_mct.c @@ -568,7 +568,7 @@ static void exynos4210_gfrc_event(void *opaque) /* Reload FRC to reach nearest comparator */ s->g_timer.curr_comp = exynos4210_gcomp_find(s); distance = exynos4210_gcomp_get_distance(s, s->g_timer.curr_comp); - if (distance > MCT_GT_COUNTER_STEP) { + if (distance > MCT_GT_COUNTER_STEP || !distance) { distance = MCT_GT_COUNTER_STEP; } exynos4210_gfrc_set_count(&s->g_timer, distance);
Check for a 0 "distance" value to avoid infinite loop when the expired FCR timer was not programed with auto-increment. With this change the behavior is coherent with the same type of code in the exynos4210_gfrc_restart() function in the same file. Linux seems to mostly use this timer with auto-increment which explain why it is not a problem most of the time. However other OS might have a problem with this if they don't use the auto-increment feature. Signed-off-by: Jean-Christophe DUBOIS <jcd@tribudubois.net> --- hw/exynos4210_mct.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)