lkml.org 
[lkml]   [2018]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFCv4,19/21] media: vim2m: add request support
    From
    Date
    Hi,

    On Mon, 2018-03-12 at 17:15 +0900, Tomasz Figa wrote:
    > Hi Paul, Dmitry,
    >
    > On Mon, Mar 12, 2018 at 5:10 PM, Paul Kocialkowski
    > <paul.kocialkowski@bootlin.com> wrote:
    > > Hi,
    > >
    > > On Sun, 2018-03-11 at 22:42 +0300, Dmitry Osipenko wrote:
    > > > Hello,
    > > >
    > > > On 07.03.2018 19:37, Paul Kocialkowski wrote:
    > > > > Hi,
    > > > >
    > > > > First off, I'd like to take the occasion to say thank-you for
    > > > > your
    > > > > work.
    > > > > This is a major piece of plumbing that is required for me to add
    > > > > support
    > > > > for the Allwinner CedarX VPU hardware in upstream Linux. Other
    > > > > drivers,
    > > > > such as tegra-vde (that was recently merged in staging) are also
    > > > > badly
    > > > > in need of this API.
    > > >
    > > > Certainly it would be good to have a common UAPI. Yet I haven't
    > > > got my
    > > > hands on
    > > > trying to implement the V4L interface for the tegra-vde driver,
    > > > but
    > > > I've taken a
    > > > look at Cedrus driver and for now I've one question:
    > > >
    > > > Would it be possible (or maybe already is) to have a single IOCTL
    > > > that
    > > > takes input/output buffers with codec parameters, processes the
    > > > request(s) and returns to userspace when everything is done?
    > > > Having 5
    > > > context switches for a single frame decode (like Cedrus VAAPI
    > > > driver
    > > > does) looks like a bit of overhead.
    > >
    > > The V4L2 interface exposes ioctls for differents actions and I don't
    > > think there's a combined ioctl for this. The request API was
    > > introduced
    > > precisely because we need to have consistency between the various
    > > ioctls
    > > needed for each frame. Maybe one single (atomic) ioctl would have
    > > worked
    > > too, but that's apparently not how the V4L2 API was designed.
    > >
    > > I don't think there is any particular overhead caused by having n
    > > ioctls
    > > instead of a single one. At least that would be very surprising
    > > IMHO.
    >
    > Well, there is small syscall overhead, which normally shouldn't be
    > very painful, although with all the speculative execution hardening,
    > can't be sure of anything anymore. :)

    Oh, my mistake then, I had it in mind that it is not really something
    noticeable. Hopefully, it won't be a limiting factor in our cases.

    > Hans and Alex can correct me if I'm wrong, but I believe there is a
    > more atomic-like API being planned, which would only need one IOCTL to
    > do everything. However, that would be a more serious change to the
    > V4L2 interfaces, so should be decoupled from Request API itself.
    >
    > Best regards,
    > Tomasz
    --
    Paul Kocialkowski, Bootlin (formerly Free Electrons)
    Embedded Linux and kernel engineering
    https://bootlin.com[unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2018-03-12 09:27    [W:2.380 / U:0.356 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site