All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomasz Figa <tfiga@chromium.org>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: contact@paulk.fr,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	devicetree@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>,
	Joerg Roedel <joro@8bytes.org>,"
	<linux-arm-kernel@lists.infradead.org>,
	devel@driverdev.osuosl.org,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Maxime Ripard <maxime.ripard@bootlin.com>,
	Chen-Yu Tsai <wens@csie.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	thomas.petazzoni@bootlin.com, ayaka <ayaka@soulik.info>,
	Ezequiel Garcia <ezequiel@collabora.com>,
	Alexandre Courbot <acourbot@chromium.org>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	linux-sunxi@googlegroups.com
Subject: Re: [PATCH v8 4/8] media: platform: Add Cedrus VPU decoder driver
Date: Thu, 6 Sep 2018 16:25:34 +0900	[thread overview]
Message-ID: <CAAFQd5Cmc7uFhprsoTU6Gq19n3z2eiUfZZ2ZjDW4QWVWMDN6tg@mail.gmail.com> (raw)
In-Reply-To: <461c6a0d-a346-b9da-b75e-4aab907054df@xs4all.nl>

On Thu, Sep 6, 2018 at 4:01 PM Hans Verkuil <hverkuil@xs4all.nl> wrote:
>
> On 09/05/2018 06:29 PM, Paul Kocialkowski wrote:
> > Hi and thanks for the review!
> >
> > Le lundi 03 septembre 2018 à 11:11 +0200, Hans Verkuil a écrit :
> >> On 08/28/2018 09:34 AM, Paul Kocialkowski wrote:
> >>> +static int cedrus_request_validate(struct media_request *req)
> >>> +{
> >>> +   struct media_request_object *obj, *obj_safe;
> >>> +   struct v4l2_ctrl_handler *parent_hdl, *hdl;
> >>> +   struct cedrus_ctx *ctx = NULL;
> >>> +   struct v4l2_ctrl *ctrl_test;
> >>> +   unsigned int i;
> >>> +
> >>> +   list_for_each_entry_safe(obj, obj_safe, &req->objects, list) {
> >>
> >> You don't need to use the _safe variant during validation.
> >
> > Okay, I'll use the regular one then.
> >
> >>> +           struct vb2_buffer *vb;
> >>> +
> >>> +           if (vb2_request_object_is_buffer(obj)) {
> >>> +                   vb = container_of(obj, struct vb2_buffer, req_obj);
> >>> +                   ctx = vb2_get_drv_priv(vb->vb2_queue);
> >>> +
> >>> +                   break;
> >>> +           }
> >>> +   }
> >>
> >> Interesting question: what happens if more than one buffer is queued in the
> >> request? This is allowed by the request API and in that case the associated
> >> controls in the request apply to all queued buffers.
> >>
> >> Would this make sense at all for this driver? If not, then you need to
> >> check here if there is more than one buffer in the request and document in
> >> the spec that this is not allowed.
> >
> > Well, our driver was written with the (unformal) assumption that we
> > only deal with a pair of one output and one capture buffer. So I will
> > add a check for this at request validation time and document it in the
> > spec. Should that be part of the MPEG-2 PIXFMT documentation (and
> > duplicated for future formats we add support for)?
>
> Can you make a patch for vb2_request_has_buffers() in videobuf2-core.c
> renaming it to vb2_request_buffer_cnt() and returning the number of buffers
> in the request?
>
> Then you can call it here to check that you have only one buffer.
>
> And this has to be documented with the PIXFMT.
>
> Multiple buffers are certainly possible in non-codec scenarios (vim2m and
> vivid happily accept that), so this is an exception that should be
> documented and checked in the codec driver.

Hmm, isn't it still 1 buffer per 1 queue and just multiple queues
included in the request?

If we indeed allow multiple buffers for the same queue in a request,
we shouldn't restrict this on a per-driver basis. It's definitely not
a hardware limitation, since the driver could just do the same as if 2
requests with the same controls were given.

Best regards,
Tomasz

WARNING: multiple messages have this Message-ID (diff)
From: Tomasz Figa <tfiga@chromium.org>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: contact@paulk.fr,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	devicetree@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>,
	Joerg Roedel <joro@8bytes.org>,"
	<linux-arm-kernel@lists.infradead.org>,
	devel@driverdev.osuosl.org,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Maxime Ripard <maxime.ripard@bootlin.com>,
	Chen-Yu Tsai <wens@csie.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	thomas.petazzoni@bootlin.com, ayaka <ayaka@soulik.info>,
	Ezequiel Garcia <ezequiel@collabora.com>,
	Alexandre Courbot <acourbot@chromium.org>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Laurent Pinchart <laurent.p>
Subject: Re: [PATCH v8 4/8] media: platform: Add Cedrus VPU decoder driver
Date: Thu, 6 Sep 2018 16:25:34 +0900	[thread overview]
Message-ID: <CAAFQd5Cmc7uFhprsoTU6Gq19n3z2eiUfZZ2ZjDW4QWVWMDN6tg@mail.gmail.com> (raw)
In-Reply-To: <461c6a0d-a346-b9da-b75e-4aab907054df@xs4all.nl>

On Thu, Sep 6, 2018 at 4:01 PM Hans Verkuil <hverkuil@xs4all.nl> wrote:
>
> On 09/05/2018 06:29 PM, Paul Kocialkowski wrote:
> > Hi and thanks for the review!
> >
> > Le lundi 03 septembre 2018 à 11:11 +0200, Hans Verkuil a écrit :
> >> On 08/28/2018 09:34 AM, Paul Kocialkowski wrote:
> >>> +static int cedrus_request_validate(struct media_request *req)
> >>> +{
> >>> +   struct media_request_object *obj, *obj_safe;
> >>> +   struct v4l2_ctrl_handler *parent_hdl, *hdl;
> >>> +   struct cedrus_ctx *ctx = NULL;
> >>> +   struct v4l2_ctrl *ctrl_test;
> >>> +   unsigned int i;
> >>> +
> >>> +   list_for_each_entry_safe(obj, obj_safe, &req->objects, list) {
> >>
> >> You don't need to use the _safe variant during validation.
> >
> > Okay, I'll use the regular one then.
> >
> >>> +           struct vb2_buffer *vb;
> >>> +
> >>> +           if (vb2_request_object_is_buffer(obj)) {
> >>> +                   vb = container_of(obj, struct vb2_buffer, req_obj);
> >>> +                   ctx = vb2_get_drv_priv(vb->vb2_queue);
> >>> +
> >>> +                   break;
> >>> +           }
> >>> +   }
> >>
> >> Interesting question: what happens if more than one buffer is queued in the
> >> request? This is allowed by the request API and in that case the associated
> >> controls in the request apply to all queued buffers.
> >>
> >> Would this make sense at all for this driver? If not, then you need to
> >> check here if there is more than one buffer in the request and document in
> >> the spec that this is not allowed.
> >
> > Well, our driver was written with the (unformal) assumption that we
> > only deal with a pair of one output and one capture buffer. So I will
> > add a check for this at request validation time and document it in the
> > spec. Should that be part of the MPEG-2 PIXFMT documentation (and
> > duplicated for future formats we add support for)?
>
> Can you make a patch for vb2_request_has_buffers() in videobuf2-core.c
> renaming it to vb2_request_buffer_cnt() and returning the number of buffers
> in the request?
>
> Then you can call it here to check that you have only one buffer.
>
> And this has to be documented with the PIXFMT.
>
> Multiple buffers are certainly possible in non-codec scenarios (vim2m and
> vivid happily accept that), so this is an exception that should be
> documented and checked in the codec driver.

Hmm, isn't it still 1 buffer per 1 queue and just multiple queues
included in the request?

If we indeed allow multiple buffers for the same queue in a request,
we shouldn't restrict this on a per-driver basis. It's definitely not
a hardware limitation, since the driver could just do the same as if 2
requests with the same controls were given.

Best regards,
Tomasz

WARNING: multiple messages have this Message-ID (diff)
From: tfiga@chromium.org (Tomasz Figa)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v8 4/8] media: platform: Add Cedrus VPU decoder driver
Date: Thu, 6 Sep 2018 16:25:34 +0900	[thread overview]
Message-ID: <CAAFQd5Cmc7uFhprsoTU6Gq19n3z2eiUfZZ2ZjDW4QWVWMDN6tg@mail.gmail.com> (raw)
In-Reply-To: <461c6a0d-a346-b9da-b75e-4aab907054df@xs4all.nl>

On Thu, Sep 6, 2018 at 4:01 PM Hans Verkuil <hverkuil@xs4all.nl> wrote:
>
> On 09/05/2018 06:29 PM, Paul Kocialkowski wrote:
> > Hi and thanks for the review!
> >
> > Le lundi 03 septembre 2018 ? 11:11 +0200, Hans Verkuil a ?crit :
> >> On 08/28/2018 09:34 AM, Paul Kocialkowski wrote:
> >>> +static int cedrus_request_validate(struct media_request *req)
> >>> +{
> >>> +   struct media_request_object *obj, *obj_safe;
> >>> +   struct v4l2_ctrl_handler *parent_hdl, *hdl;
> >>> +   struct cedrus_ctx *ctx = NULL;
> >>> +   struct v4l2_ctrl *ctrl_test;
> >>> +   unsigned int i;
> >>> +
> >>> +   list_for_each_entry_safe(obj, obj_safe, &req->objects, list) {
> >>
> >> You don't need to use the _safe variant during validation.
> >
> > Okay, I'll use the regular one then.
> >
> >>> +           struct vb2_buffer *vb;
> >>> +
> >>> +           if (vb2_request_object_is_buffer(obj)) {
> >>> +                   vb = container_of(obj, struct vb2_buffer, req_obj);
> >>> +                   ctx = vb2_get_drv_priv(vb->vb2_queue);
> >>> +
> >>> +                   break;
> >>> +           }
> >>> +   }
> >>
> >> Interesting question: what happens if more than one buffer is queued in the
> >> request? This is allowed by the request API and in that case the associated
> >> controls in the request apply to all queued buffers.
> >>
> >> Would this make sense at all for this driver? If not, then you need to
> >> check here if there is more than one buffer in the request and document in
> >> the spec that this is not allowed.
> >
> > Well, our driver was written with the (unformal) assumption that we
> > only deal with a pair of one output and one capture buffer. So I will
> > add a check for this at request validation time and document it in the
> > spec. Should that be part of the MPEG-2 PIXFMT documentation (and
> > duplicated for future formats we add support for)?
>
> Can you make a patch for vb2_request_has_buffers() in videobuf2-core.c
> renaming it to vb2_request_buffer_cnt() and returning the number of buffers
> in the request?
>
> Then you can call it here to check that you have only one buffer.
>
> And this has to be documented with the PIXFMT.
>
> Multiple buffers are certainly possible in non-codec scenarios (vim2m and
> vivid happily accept that), so this is an exception that should be
> documented and checked in the codec driver.

Hmm, isn't it still 1 buffer per 1 queue and just multiple queues
included in the request?

If we indeed allow multiple buffers for the same queue in a request,
we shouldn't restrict this on a per-driver basis. It's definitely not
a hardware limitation, since the driver could just do the same as if 2
requests with the same controls were given.

Best regards,
Tomasz

  parent reply	other threads:[~2018-09-06  7:25 UTC|newest]

Thread overview: 84+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-28  7:34 [PATCH v8 0/8] Cedrus driver for the Allwinner Video Engine, using media requests Paul Kocialkowski
2018-08-28  7:34 ` Paul Kocialkowski
2018-08-28  7:34 ` Paul Kocialkowski
2018-08-28  7:34 ` [PATCH v8 1/8] media: v4l: Add definitions for MPEG2 slice format and metadata Paul Kocialkowski
2018-08-28  7:34   ` Paul Kocialkowski
2018-08-28  7:34   ` Paul Kocialkowski
2018-09-03  8:32   ` Hans Verkuil
2018-09-03  8:32     ` Hans Verkuil
2018-09-03  8:32     ` Hans Verkuil
2018-09-05 15:42     ` Paul Kocialkowski
2018-09-05 15:42       ` Paul Kocialkowski
2018-09-05 15:42       ` Paul Kocialkowski
2018-08-28  7:34 ` [PATCH v8 2/8] media: v4l: Add definition for the Sunxi tiled NV12 format Paul Kocialkowski
2018-08-28  7:34   ` Paul Kocialkowski
2018-08-28  7:34   ` Paul Kocialkowski
2018-08-28  7:34 ` [PATCH v8 3/8] dt-bindings: media: Document bindings for the Cedrus VPU driver Paul Kocialkowski
2018-08-28  7:34   ` Paul Kocialkowski
2018-08-28  7:34   ` Paul Kocialkowski
2018-08-28 14:44   ` Maxime Ripard
2018-08-28 14:44     ` Maxime Ripard
2018-08-28 14:47   ` [linux-sunxi] " Corentin Labbe
2018-08-28 14:47     ` Corentin Labbe
2018-08-28 14:47     ` Corentin Labbe
2018-09-05 15:43     ` [linux-sunxi] " Paul Kocialkowski
2018-09-05 15:43       ` Paul Kocialkowski
2018-09-05 15:43       ` Paul Kocialkowski
2018-08-28  7:34 ` [PATCH v8 4/8] media: platform: Add Cedrus VPU decoder driver Paul Kocialkowski
2018-08-28  7:34   ` Paul Kocialkowski
2018-08-28  7:34   ` Paul Kocialkowski
2018-08-28 14:56   ` Maxime Ripard
2018-08-28 14:56     ` Maxime Ripard
2018-08-28 14:56     ` Maxime Ripard
2018-08-29  1:08   ` Ezequiel Garcia
2018-08-29  1:08     ` Ezequiel Garcia
2018-09-05 15:49     ` Paul Kocialkowski
2018-09-05 15:49       ` Paul Kocialkowski
2018-09-05 15:49       ` Paul Kocialkowski
2018-09-03  9:11   ` Hans Verkuil
2018-09-03  9:11     ` Hans Verkuil
2018-09-03  9:11     ` Hans Verkuil
2018-09-05 16:29     ` Paul Kocialkowski
2018-09-05 16:29       ` Paul Kocialkowski
2018-09-05 16:29       ` Paul Kocialkowski
2018-09-06  7:01       ` Hans Verkuil
2018-09-06  7:01         ` Hans Verkuil
2018-09-06  7:01         ` Hans Verkuil
2018-09-06  7:22         ` Hans Verkuil
2018-09-06  7:22           ` Hans Verkuil
2018-09-06  7:22           ` Hans Verkuil
2018-09-07 15:04           ` Paul Kocialkowski
2018-09-07 15:04             ` Paul Kocialkowski
2018-09-07 15:04             ` Paul Kocialkowski
2018-09-06  7:25         ` Tomasz Figa [this message]
2018-09-06  7:25           ` Tomasz Figa
2018-09-06  7:25           ` Tomasz Figa
2018-09-06  7:39           ` Hans Verkuil
2018-09-06  7:39             ` Hans Verkuil
2018-09-06  7:39             ` Hans Verkuil
2018-09-07  8:05             ` Tomasz Figa
2018-09-07  8:05               ` Tomasz Figa
2018-09-07  8:05               ` Tomasz Figa
2018-08-28  7:34 ` [PATCH v8 5/8] ARM: dts: sun5i: Add Video Engine and reserved memory nodes Paul Kocialkowski
2018-08-28  7:34   ` Paul Kocialkowski
2018-08-28  7:34   ` Paul Kocialkowski
2018-08-28 14:55   ` Maxime Ripard
2018-08-28 14:55     ` Maxime Ripard
2018-08-28 14:55     ` Maxime Ripard
2018-08-28  7:34 ` [PATCH v8 6/8] ARM: dts: sun7i-a20: " Paul Kocialkowski
2018-08-28  7:34   ` Paul Kocialkowski
2018-08-28  7:34   ` Paul Kocialkowski
2018-08-28 14:55   ` Maxime Ripard
2018-08-28 14:55     ` Maxime Ripard
2018-08-28 14:55     ` Maxime Ripard
2018-08-28  7:34 ` [PATCH v8 7/8] ARM: dts: sun8i-a33: " Paul Kocialkowski
2018-08-28  7:34   ` Paul Kocialkowski
2018-08-28  7:34   ` Paul Kocialkowski
2018-08-28 14:55   ` Maxime Ripard
2018-08-28 14:55     ` Maxime Ripard
2018-08-28  7:34 ` [PATCH v8 8/8] ARM: dts: sun8i-h3: " Paul Kocialkowski
2018-08-28  7:34   ` Paul Kocialkowski
2018-08-28  7:34   ` Paul Kocialkowski
2018-08-28 14:55   ` Maxime Ripard
2018-08-28 14:55     ` Maxime Ripard
2018-08-28 14:55     ` Maxime Ripard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAAFQd5Cmc7uFhprsoTU6Gq19n3z2eiUfZZ2ZjDW4QWVWMDN6tg@mail.gmail.com \
    --to=tfiga@chromium.org \
    --cc=acourbot@chromium.org \
    --cc=ayaka@soulik.info \
    --cc=contact@paulk.fr \
    --cc=devel@driverdev.osuosl.org \
    --cc=devicetree@vger.kernel.org \
    --cc=ezequiel@collabora.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hverkuil@xs4all.nl \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-sunxi@googlegroups.com \
    --cc=mark.rutland@arm.com \
    --cc=maxime.ripard@bootlin.com \
    --cc=mchehab@kernel.org \
    --cc=p.zabel@pengutronix.de \
    --cc=robh+dt@kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=wens@csie.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.