linux-kernel - Re: [PATCH v4] media: vivid: Improve timestamping

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a2of9sZ5BGCKshCjFkpt8q6s-KD-9XC4SGYP2Ppj7fjEw@mail.gmail.com>
Date:   Sun, 2 Dec 2018 21:43:53 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     gfmandaji@...il.com
Cc:     Hans Verkuil <hverkuil@...all.nl>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        lkcamp@...ts.libreplanetbr.org
Subject: Re: [PATCH v4] media: vivid: Improve timestamping

On Sun, Dec 2, 2018 at 2:47 PM Gabriel Francisco Mandaji
<gfmandaji@...il.com> wrote:

> @@ -667,10 +653,28 @@ static void vivid_overlay(struct vivid_dev *dev, struct vivid_buffer *buf)
>         }
>  }
>
> +static void vivid_cap_update_frame_period(struct vivid_dev *dev)
> +{
> +       u64 f_period;
> +
> +       f_period = (u64)dev->timeperframe_vid_cap.numerator * 1000000000;
> +       do_div(f_period, dev->timeperframe_vid_cap.denominator);
> +       if (dev->field_cap == V4L2_FIELD_ALTERNATE)
> +               do_div(f_period, 2);
> +       /*
> +        * If "End of Frame", then offset the exposure time by 0.9
> +        * of the frame period.
> +        */
> +       dev->cap_frame_eof_offset = f_period * 9;
> +       do_div(dev->cap_frame_eof_offset, 10);
> +       dev->cap_frame_period = f_period;
> +}

Doing two or three do_div() operations is going to make this rather
expensive on 32-bit architectures, and it looks like this happens for
each frame?

Since each one is a multiplication followed by a division, could this
be changed to using a different factor followed by a bit shift?

      Arnd