Linux kernel and device drivers for NXP i.MX platforms
 help / color / mirror / Atom feed
From: "Ming Qian(OSS)" <ming.qian@oss.nxp.com>
To: Lucas Stach <l.stach@pengutronix.de>, linux-media@vger.kernel.org
Cc: mchehab@kernel.org, hverkuil-cisco@xs4all.nl,
	nicolas@ndufresne.ca, benjamin.gaignard@collabora.com,
	p.zabel@pengutronix.de, sebastian.fricke@collabora.com,
	shawnguo@kernel.org, ulf.hansson@linaro.org,
	s.hauer@pengutronix.de, kernel@pengutronix.de,
	festevam@gmail.com, linux-imx@nxp.com, peng.fan@nxp.com,
	eagle.zhou@nxp.com, imx@lists.linux.dev,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/2] media: verisilicon: Avoid G2 bus error while decoding H.264 and HEVC
Date: Tue, 25 Nov 2025 11:06:37 +0800	[thread overview]
Message-ID: <a4e516d3-ff8e-4233-b959-7a8d4222e5d6@oss.nxp.com> (raw)
In-Reply-To: <53cb1a8e87f80d8bb1a9b6463077a99b2268e46c.camel@pengutronix.de>


Hi Lucas,

On 11/25/2025 1:42 AM, Lucas Stach wrote:
> Hi Ming,
> 
> Am Freitag, dem 21.11.2025 um 16:19 +0800 schrieb
> ming.qian@oss.nxp.com:
>> From: Ming Qian <ming.qian@oss.nxp.com>
>>
>> For the i.MX8MQ platform, there is a hardware limitation: the g1 VPU and
>> g2 VPU cannot decode simultaneously; otherwise, it will cause below bus
>> error and produce corrupted pictures, even led to system hang.
>>
>> [  110.527986] hantro-vpu 38310000.video-codec: frame decode timed out.
>> [  110.583517] hantro-vpu 38310000.video-codec: bus error detected.
>>
>> Therefore, it is necessary to ensure that g1 and g2 operate alternately.
>> Then this allows for successful multi-instance decoding of H.264 and HEVC.
>>
> Is there any more info available on what's actually causing the hang?
> Is there some kind of overflow of the interconnect request capacity?
> 
> I'm asking to understand the issue a bit better, as locking both
> decoder instances against each other seems like a pretty big hammer.
> 
> Regards,
> Lucas
> 

In NXP's internal VPU solution, i.MX8MQ combines g1 and g2 into a single
device for processing. However, i.MX8MP separates g1 and g2 into two
separate devices.
However, I cannot find relevant documentation.
I can only guess that there are some hardware signals on the i.MX8MQ
that might interfere with each other, such as G1 and G2 VPU.

We recently encountered this problem when trying to switch to upstream
device nodes. So we tried applying our previous strategy.

I agree that waiting or locking is not nice enough, I will try a better
solution.

Regards,
Ming

>> Fixes: cb5dd5a0fa518 ("media: hantro: Introduce G2/HEVC decoder")
>> Signed-off-by: Ming Qian <ming.qian@oss.nxp.com>
>> ---
>>   drivers/media/platform/verisilicon/hantro.h   |  1 +
>>   .../media/platform/verisilicon/hantro_drv.c   | 26 +++++++++++++++++++
>>   .../media/platform/verisilicon/imx8m_vpu_hw.c |  4 +++
>>   3 files changed, 31 insertions(+)
>>
>> diff --git a/drivers/media/platform/verisilicon/hantro.h b/drivers/media/platform/verisilicon/hantro.h
>> index e0fdc4535b2d..8baebf767d26 100644
>> --- a/drivers/media/platform/verisilicon/hantro.h
>> +++ b/drivers/media/platform/verisilicon/hantro.h
>> @@ -101,6 +101,7 @@ struct hantro_variant {
>>   	unsigned int double_buffer : 1;
>>   	unsigned int legacy_regs : 1;
>>   	unsigned int late_postproc : 1;
>> +	atomic_t *shared_resource;
>>   };
>>   
>>   /**
>> diff --git a/drivers/media/platform/verisilicon/hantro_drv.c b/drivers/media/platform/verisilicon/hantro_drv.c
>> index 60b95b5d8565..036ce43c9359 100644
>> --- a/drivers/media/platform/verisilicon/hantro_drv.c
>> +++ b/drivers/media/platform/verisilicon/hantro_drv.c
>> @@ -19,6 +19,7 @@
>>   #include <linux/slab.h>
>>   #include <linux/videodev2.h>
>>   #include <linux/workqueue.h>
>> +#include <linux/iopoll.h>
>>   #include <media/v4l2-event.h>
>>   #include <media/v4l2-mem2mem.h>
>>   #include <media/videobuf2-core.h>
>> @@ -93,6 +94,9 @@ static void hantro_job_finish(struct hantro_dev *vpu,
>>   
>>   	clk_bulk_disable(vpu->variant->num_clocks, vpu->clocks);
>>   
>> +	if (vpu->variant->shared_resource)
>> +		atomic_cmpxchg(vpu->variant->shared_resource, 0, 1);
>> +
>>   	hantro_job_finish_no_pm(vpu, ctx, result);
>>   }
>>   
>> @@ -166,12 +170,34 @@ void hantro_end_prepare_run(struct hantro_ctx *ctx)
>>   			      msecs_to_jiffies(2000));
>>   }
>>   
>> +static int hantro_wait_shared_resource(struct hantro_dev *vpu)
>> +{
>> +	u32 data;
>> +	int ret;
>> +
>> +	if (!vpu->variant->shared_resource)
>> +		return 0;
>> +
>> +	ret = read_poll_timeout(atomic_cmpxchg, data, data, 10, 300 * NSEC_PER_MSEC, false,
>> +				vpu->variant->shared_resource, 1, 0);
>> +	if (ret) {
>> +		dev_err(vpu->dev, "Failed to wait shared resource\n");
>> +		return -EINVAL;
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>>   static void device_run(void *priv)
>>   {
>>   	struct hantro_ctx *ctx = priv;
>>   	struct vb2_v4l2_buffer *src, *dst;
>>   	int ret;
>>   
>> +	ret = hantro_wait_shared_resource(ctx->dev);
>> +	if (ret < 0)
>> +		goto err_cancel_job;
>> +
>>   	src = hantro_get_src_buf(ctx);
>>   	dst = hantro_get_dst_buf(ctx);
>>   
>> diff --git a/drivers/media/platform/verisilicon/imx8m_vpu_hw.c b/drivers/media/platform/verisilicon/imx8m_vpu_hw.c
>> index 5be0e2e76882..1b3a0bfbf890 100644
>> --- a/drivers/media/platform/verisilicon/imx8m_vpu_hw.c
>> +++ b/drivers/media/platform/verisilicon/imx8m_vpu_hw.c
>> @@ -324,6 +324,8 @@ static const char * const imx8mq_reg_names[] = { "g1", "g2", "ctrl" };
>>   static const char * const imx8mq_g1_clk_names[] = { "g1" };
>>   static const char * const imx8mq_g2_clk_names[] = { "g2" };
>>   
>> +static atomic_t imx8mq_shared_resource = ATOMIC_INIT(1);
>> +
>>   const struct hantro_variant imx8mq_vpu_variant = {
>>   	.dec_fmts = imx8m_vpu_dec_fmts,
>>   	.num_dec_fmts = ARRAY_SIZE(imx8m_vpu_dec_fmts),
>> @@ -356,6 +358,7 @@ const struct hantro_variant imx8mq_vpu_g1_variant = {
>>   	.num_irqs = ARRAY_SIZE(imx8mq_irqs),
>>   	.clk_names = imx8mq_g1_clk_names,
>>   	.num_clocks = ARRAY_SIZE(imx8mq_g1_clk_names),
>> +	.shared_resource = &imx8mq_shared_resource,
>>   };
>>   
>>   const struct hantro_variant imx8mq_vpu_g2_variant = {
>> @@ -371,6 +374,7 @@ const struct hantro_variant imx8mq_vpu_g2_variant = {
>>   	.num_irqs = ARRAY_SIZE(imx8mq_g2_irqs),
>>   	.clk_names = imx8mq_g2_clk_names,
>>   	.num_clocks = ARRAY_SIZE(imx8mq_g2_clk_names),
>> +	.shared_resource = &imx8mq_shared_resource,
>>   };
>>   
>>   const struct hantro_variant imx8mm_vpu_g1_variant = {
> 

  reply	other threads:[~2025-11-25  3:06 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-21  8:19 [PATCH 1/2] pmdomain: imx8m-blk-ctrl: Remove separate rst and clk mask for 8mq vpu ming.qian
2025-11-21  8:19 ` [PATCH 2/2] media: verisilicon: Avoid G2 bus error while decoding H.264 and HEVC ming.qian
2025-11-21 10:31   ` Benjamin Gaignard
2025-11-21 16:08   ` Frank Li
2025-11-24  1:38     ` Ming Qian(OSS)
2025-11-24 15:49       ` Frank Li
2025-11-24 16:39         ` Nicolas Dufresne
2025-11-24 16:55           ` Nicolas Dufresne
2025-11-25  2:39             ` Ming Qian(OSS)
2025-11-24 17:42   ` Lucas Stach
2025-11-25  3:06     ` Ming Qian(OSS) [this message]
2025-11-21 10:30 ` [PATCH 1/2] pmdomain: imx8m-blk-ctrl: Remove separate rst and clk mask for 8mq vpu Benjamin Gaignard
2025-11-21 16:11 ` Frank Li
2025-11-24  1:48   ` Ming Qian(OSS)
2025-11-21 18:07 ` Nicolas Dufresne
2025-11-24  2:06   ` Ming Qian(OSS)

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=a4e516d3-ff8e-4233-b959-7a8d4222e5d6@oss.nxp.com \
    --to=ming.qian@oss.nxp.com \
    --cc=benjamin.gaignard@collabora.com \
    --cc=eagle.zhou@nxp.com \
    --cc=festevam@gmail.com \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=imx@lists.linux.dev \
    --cc=kernel@pengutronix.de \
    --cc=l.stach@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=nicolas@ndufresne.ca \
    --cc=p.zabel@pengutronix.de \
    --cc=peng.fan@nxp.com \
    --cc=s.hauer@pengutronix.de \
    --cc=sebastian.fricke@collabora.com \
    --cc=shawnguo@kernel.org \
    --cc=ulf.hansson@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox