mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®