[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <72b35424372f4e3b73d82c84637672b7b39353e8.camel@collabora.com>
Date: Thu, 17 Sep 2020 14:43:19 -0400
From: Nicolas Dufresne <nicolas.dufresne@...labora.com>
To: Hans Verkuil <hverkuil@...all.nl>
Cc: kernel@...labora.com, Maxime Ripard <mripard@...nel.org>,
Paul Kocialkowski <paul.kocialkowski@...tlin.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Chen-Yu Tsai <wens@...e.org>, linux-media@...r.kernel.org,
devel@...verdev.osuosl.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] media: cedrus: Propagate OUTPUT resolution to CAPTURE
Le jeudi 17 septembre 2020 à 12:39 +0200, Hans Verkuil a écrit :
> On 14/05/2020 17:39, Nicolas Dufresne wrote:
> > As per spec, the CAPTURE resolution should be automatically set based on
> > the OTUPUT resolution. This patch properly propagate width/height to the
> > capture when the OUTPUT format is set and override the user provided
> > width/height with configured OUTPUT resolution when the CAPTURE fmt is
> > updated.
> >
> > This also prevents userspace from selecting a CAPTURE resolution that is
> > too small, avoiding unwanted page faults.
> >
> > Signed-off-by: Nicolas Dufresne <nicolas.dufresne@...labora.com>
> > ---
> > drivers/staging/media/sunxi/cedrus/cedrus_video.c | 7 ++++++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > index 16d82309e7b6..a6d6b15adc2e 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > @@ -247,6 +247,8 @@ static int cedrus_try_fmt_vid_cap(struct file *file, void *priv,
> > return -EINVAL;
> >
> > pix_fmt->pixelformat = fmt->pixelformat;
> > + pix_fmt->width = ctx->src_fmt.width;
> > + pix_fmt->height = ctx->src_fmt.height;
> > cedrus_prepare_format(pix_fmt);
> >
> > return 0;
> > @@ -319,11 +321,14 @@ static int cedrus_s_fmt_vid_out(struct file *file, void *priv,
> > break;
> > }
> >
> > - /* Propagate colorspace information to capture. */
> > + /* Propagate format information to capture. */
> > ctx->dst_fmt.colorspace = f->fmt.pix.colorspace;
> > ctx->dst_fmt.xfer_func = f->fmt.pix.xfer_func;
> > ctx->dst_fmt.ycbcr_enc = f->fmt.pix.ycbcr_enc;
> > ctx->dst_fmt.quantization = f->fmt.pix.quantization;
> > + ctx->dst_fmt.width = ctx->src_fmt.width;
> > + ctx->dst_fmt.height = ctx->src_fmt.height;
>
> You can only do this if the capture queue isn't busy.
>
> See also hantro_reset_raw_fmt() where it does that check.
>
> So this needs a v2.
I missed this reply, wasn't expecting a negative third review. I'll
copy and paste from there. So basically:
- EBUSY if peer vq is busy
- EBUSY if pixel format is changed while vq is busy
- EBUSY if streaming
Obviously, I don't have userspace to exercise any of these cases, but
it seems to make sense. I remembered about this patch today as someone
reported the kernel crash we get without this patch:
---
I tried testing cedrus with gstreamer 0.18 and it managed to crash the
kernel on
A64. I used:
gst-launch-1.0 filesrc location=test.mkv ! matroskademux ! queue !
h264parse ! v4l2slh264dec ! filesink location=aaa.dat
Unable to handle kernel paging request at virtual address
8080808080808088
Mem abort info:
ESR = 0x96000044
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000044
CM = 0, WnR = 1
[8080808080808088] address between user and kernel address ranges
Internal error: Oops: 96000044 [#1] SMP
Modules linked in: modem_power hci_uart btrtl bluetooth ecdh_generic
ecc sunxi_cedrus(C) sun8i_ce crypto_engine snd_soc_bt_sco
snd_soc_simple_card snd_soc_simple_card_utils snd_soc_simple_amplifier
sun50i_codec_analog sun8i_codec sun8i_adda_pr_regmap snd_soc_ec25
sun4i_i2s snd_soc_core snd_pcm_dmaengine snd_pcm snd_timer snd
soundcore stk3310 inv_mpu6050_i2c inv_mpu6050 st_magn_i2c
st_sensors_i2c st_magn st_sensors industrialio_triggered_buffer
kfifo_buf regmap_i2c option usb_wwan usbserial anx7688 ohci_platform
ohci_hcd ehci_platform ehci_hcd g_cdc usb_f_acm u_serial usb_f_ecm
u_ether libcomposite sunxi phy_generic musb_hdrc udc_core usbcore
sun8i_rotate v4l2_mem2mem gc2145 ov5640 sun6i_csi videobuf2_dma_contig
v4l2_fwnode videobuf2_memops videobuf2_v4l2 videobuf2_common videodev
mc 8723cs(C) cfg80211 rfkill lima gpu_sched goodix
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G C 5.9.0-rc5-
00386-g4fe2ef82bd0b #62
Hardware name: Pine64 PinePhone (1.2) (DT)
pstate: 80000085 (Nzcv daIf -PAN -UAO BTYPE=--)
pc : v4l2_m2m_buf_remove+0x44/0x90 [v4l2_mem2mem]
lr : v4l2_m2m_buf_remove+0x18/0x90 [v4l2_mem2mem]
sp : ffffffc010c8be20
x29: ffffffc010c8be20 x28: ffffffc010bb2fc0
x27: 0000000000000060 x26: ffffffc010935e58
x25: ffffffc010c06a5a x24: 0000000000000080
x23: 0000000000000005 x22: ffffffc010c8bf4c
x21: ffffff806ba0d088 x20: ffffff80687d1800
x19: ffffff8066c40298 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000
x15: 000001b66678fd80 x14: 0000000000000204
x13: 0000000000000001 x12: 0000000000000040
x11: ffffff806f0c0248 x10: ffffff806f0c024a
x9 : ffffffc010bbdac8 x8 : ffffff806f000270
x7 : 0000000000000000 x6 : dead000000000100
x5 : dead000000000122 x4 : 0000000000000000
x3 : 8080808080808080 x2 : 8080808080808080
x1 : ffffff80641327a8 x0 : 0000000000000080
Call trace:
v4l2_m2m_buf_remove+0x44/0x90 [v4l2_mem2mem]
v4l2_m2m_buf_done_and_job_finish+0x34/0x140 [v4l2_mem2mem]
cedrus_irq+0x8c/0xc0 [sunxi_cedrus]
__handle_irq_event_percpu+0x54/0x150
handle_irq_event+0x4c/0xec
handle_fasteoi_irq+0xbc/0x1c0
__handle_domain_irq+0x78/0xdc
gic_handle_irq+0x50/0xa0
el1_irq+0xb8/0x140
arch_cpu_idle+0x10/0x14
cpu_startup_entry+0x24/0x60
rest_init+0xb0/0xbc
arch_call_rest_init+0xc/0x14
start_kernel+0x690/0x6b0
Code: f2fbd5a6 f2fbd5a5 52800004 a9400823 (f9000462)
---[ end trace 88233b9a76cdb261 ]---
Kernel panic - not syncing: Fatal exception in interrupt
>
> Regards,
>
> Hans
>
> > + cedrus_prepare_format(&ctx->dst_fmt);
> >
> > return 0;
> > }
> >
Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)
Powered by blists - more mailing lists