From: Torsten Duwe <duwe@lst.de>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Lucas Sinn <lucas.sinn@wolfvision.net>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Heiko Stuebner <heiko@sntech.de>,
Philipp Zabel <p.zabel@pengutronix.de>,
linux-media@vger.kernel.org, linux-rockchip@lists.infradead.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 2/4] media: rockchip: Add JPEG decoder driver
Date: Thu, 22 Oct 2026 19:00:26 +0200 [thread overview]
Message-ID: <20261022190026.6cb0a534@rocky.lan> (raw)
In-Reply-To: <20261022-rockchip-jpegdec-v7-2-3fd7dd55f408@pengutronix.de>
Hi Sascha,
first: thank you for driving this :)
On Thu, 22 Oct 2026 13:06:40 +0200
Sascha Hauer <s.hauer@pengutronix.de> wrote:
> Add a driver for the JPEG hardware decoder Rockchip integrates into a
> number of its SoCs.
[...]
> +static int rkjpegd_enum_fmt_vid_out(struct file *file, void *priv,
> + struct v4l2_fmtdesc *f)
> +{
> + if (f->index)
> + return -EINVAL;
> +
> + f->pixelformat = V4L2_PIX_FMT_JPEG;
> + f->flags |= V4L2_FMT_FLAG_DYN_RESOLUTION;
> +
> + return 0;
> +}
> +
> +static int rkjpegd_enum_framesizes(struct file *file, void *priv,
> + struct v4l2_frmsizeenum *fsize)
> +{
> + /* The decoded format follows the bitstream, nothing to enumerate. */
> + if (fsize->pixel_format == V4L2_PIX_FMT_NV12 ||
> + fsize->pixel_format == V4L2_PIX_FMT_GREY)
> + return -ENOTTY;
> +
> + if (fsize->pixel_format != V4L2_PIX_FMT_JPEG)
> + return -EINVAL;
> +
> + if (fsize->index)
> + return -EINVAL;
> +
> + fsize->type = V4L2_FRMSIZE_TYPE_STEPWISE;
> + fsize->stepwise.min_width = RKJPEGD_MIN_WIDTH;
> + fsize->stepwise.max_width = RKJPEGD_MAX_SIZE;
> + fsize->stepwise.step_width = RKJPEGD_CODED_STEP;
> + fsize->stepwise.min_height = RKJPEGD_MIN_HEIGHT;
> + fsize->stepwise.max_height = RKJPEGD_MAX_SIZE;
> + fsize->stepwise.step_height = RKJPEGD_CODED_STEP;
> +
> + return 0;
> +}
Can it do JPEG, MJPEG or maybe both? AFAICT the difference is minimal,
so maybe try to be more permissive?
[...]
> +static const struct v4l2_ioctl_ops rkjpegd_ioctl_ops = {
> + .vidioc_querycap = rkjpegd_querycap,
> + .vidioc_enum_framesizes = rkjpegd_enum_framesizes,
> +
> + .vidioc_enum_fmt_vid_cap = rkjpegd_enum_fmt_vid_cap,
> + .vidioc_g_fmt_vid_cap_mplane = rkjpegd_g_fmt_vid_cap,
> + .vidioc_try_fmt_vid_cap_mplane = rkjpegd_try_fmt_vid_cap,
> + .vidioc_s_fmt_vid_cap_mplane = rkjpegd_s_fmt_vid_cap,
> +
> + .vidioc_enum_fmt_vid_out = rkjpegd_enum_fmt_vid_out,
> + .vidioc_g_fmt_vid_out_mplane = rkjpegd_g_fmt_vid_out,
> + .vidioc_try_fmt_vid_out_mplane = rkjpegd_try_fmt_vid_out,
> + .vidioc_s_fmt_vid_out_mplane = rkjpegd_s_fmt_vid_out,
>
You are populating only the *_out_mplane members and not the single
plane ones? So a greyscale JPEG needs to go _mplane with 1 plane?
And for color, the colorspace on the decoded side should be
V4L2_COLORSPACE_JPEG, not sRGB, I think.
Would you mind to give a hint about your test setup?
Thanks,
Torsten
next prev parent reply other threads:[~2026-10-22 17:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-22 11:06 [PATCH v7 0/4] " Sascha Hauer
2026-10-22 11:06 ` [PATCH v7 1/4] media: dt-bindings: Add Rockchip JPEG decoder Sascha Hauer
2026-10-22 11:06 ` [PATCH v7 2/4] media: rockchip: Add JPEG decoder driver Sascha Hauer
2026-10-22 17:00 ` Torsten Duwe [this message]
2026-10-22 11:06 ` [PATCH v7 3/4] arm64: dts: rockchip: rk3588: Add JPEG decoder node Sascha Hauer
2026-10-22 11:06 ` [PATCH v7 4/4] arm64: dts: rockchip: rk356x: " Sascha Hauer
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=20261022190026.6cb0a534@rocky.lan \
--to=duwe@lst.de \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=heiko@sntech.de \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=lucas.sinn@wolfvision.net \
--cc=mchehab@kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=robh@kernel.org \
--cc=s.hauer@pengutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®