On Mon, Jan 28, 2019 at 09:33:04AM +0100, Jacopo Mondi wrote:
> Hi everyone,
>
> On Mon, Jan 28, 2019 at 01:20:37PM +0530, Jagan Teki wrote:
> > On Fri, Jan 25, 2019 at 9:10 PM Maxime Ripard <maxime.ripard@xxxxxxxxxxx> wrote:
> > >
> > > On Thu, Jan 24, 2019 at 11:28:01PM +0530, Jagan Teki wrote:
> > > > The ov5640_try_frame_interval operation updates the FPS as per user
> > > > input based on default ov5640_frame_rate, OV5640_30_FPS which is failed
> > > > to update when user trigger 15fps.
> > > >
> > > > So, initialize the default ov5640_frame_rate to OV5640_15_FPS so-that
> > > > it can satisfy to update all fps.
> > > >
> > > > Fixes: 5a3ad937bc78 ("media: ov5640: Make the return rate type more explicit")
> > > > Signed-off-by: Jagan Teki <jagan@xxxxxxxxxxxxxxxxxxxx>
> > >
> > > I'm pretty sure I tested this and it was working fine. You're
> > > mentionning a regression, but what regression is there exactly (ie,
> > > what was working before that commit that doesn't work anymore?). What
> > > tools/commands are you using to see this behaviour?
> >
>
> I think Jagan's right, here.
>
> For the 15FPS use case, the below condition in the for loop of
> ov5640_try_frame_interval() never gets satisfied (0 < 0 ?) and 'rate' retains
> its initial value of 30FPS.
>
> if (abs(curr_fps - fps) < abs(best_fps - fps)) {
> best_fps = curr_fps;
> rate = i;
> }
>
> To make more clear what's happening, I would initialize 'rate' just
> before 'best_fps' before the for loop. Anyway, please add:
> Acked-by: Jacopo Mondi <jacopo@xxxxxxxxxx>
>
> Maxime, does this make sense to you?
With that explanation in the commit log, yes.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Attachment:
signature.asc
Description: PGP signature
