mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Ming Qian(OSS)" <ming.qian@oss.nxp.com>
To: Frank Li <Frank.li@nxp.com>
Cc: mchehab@kernel.org, hverkuil-cisco@xs4all.nl,
	mirela.rabulea@oss.nxp.com, shawnguo@kernel.org,
	s.hauer@pengutronix.de, kernel@pengutronix.de,
	festevam@gmail.com, xiahong.bao@nxp.com, eagle.zhou@nxp.com,
	linux-imx@nxp.com, imx@lists.linux.dev,
	linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 3/3] media: imx-jpeg: Check decoding is ongoing for motion-jpeg
Date: Tue, 1 Apr 2025 11:17:36 +0800	[thread overview]
Message-ID: <22fd3087-6832-4b61-8c78-bc8dd3ac808b@oss.nxp.com> (raw)
In-Reply-To: <Z+qnln8qbHCYVH+e@lizhi-Precision-Tower-5810>


Hi Frank,

On 2025/3/31 22:32, Frank Li wrote:
> On Mon, Mar 31, 2025 at 11:10:20AM +0800, Ming Qian(OSS) wrote:
>>
>> Hi Frank,
>>
>> On 2025/3/28 22:45, Frank Li wrote:
>>> On Fri, Mar 28, 2025 at 02:30:52PM +0800, ming.qian@oss.nxp.com wrote:
>>>> From: Ming Qian <ming.qian@oss.nxp.com>
>>>>
>>>> To support decoding motion-jpeg without DHT, driver will try to decode a
>>>> pattern jpeg before actual jpeg frame by use of linked descriptors
>>>> (This is called "repeat mode"), then the DHT in the pattern jpeg can be
>>>> used for decoding the motion-jpeg.
>>>>
>>>> In other words, 2 frame done interrupts will be triggered, driver will
>>>> ignore the first interrupt,
>>>
>>> Does any field in linked descriptors to control if issue irq? Generally
>>> you needn't enable first descriptors's irq and only enable second one.
>>>
>>
>> Unfortunately, we cannot configure interrupts for each descriptor.
>> So we can't only enable the second irq.
>>
>>
>>>> and wait for the second interrupt.
>>>> If the resolution is small, and the 2 interrupts may be too close,
>>>
>>> It also possible two irqs combine to 1 irqs. If I understand correct, your
>>> irq handle only handle one descriptors per irq.
>>>
>>> Another words,
>>>
>>> If second irq already happen just before 1,
>>>
>>> 1. dec_ret = readl(reg + MXC_SLOT_OFFSET(slot, SLOT_STATUS));
>>> 2. writel(dec_ret, reg + MXC_SLOT_OFFSET(slot, SLOT_STATUS)); /* w1c */
>>>
>>> Does your driver wait forever because no second irq happen?
>>>
>>> Frank
>>
>> Before this patch, the answer is yes, the driver will wait 2 seconds
>> until timeout.
>> In fact, this is the problem that this patch wants to avoid.
>> Now I think there are 3 cases for motion-jpeg decoding:
>> 1. The second irq happens before the first irq status check, the on-going
>> check
>> help to hanle this case.
>> 2. The second irq happens after the first irq status check, but before
>> on-going check, this on-going check can help handle it, fisnish the
>> current decoding and reset the jpeg decoder.
>> 3. The second irq happens after the on-going check, this is the normal
>> process before. No additional processing required.
> 
> Okay, not sure if hardware provide current_descript position. Generally
> descriptor queue irq handle is like
> 
> cur = queue_header;
> while(cur != read_hardware_currunt_pos())
> {
> 	handle(cur);
> 	cur = cur->next;
> 	queue_header = cur;
> }
> 
> with above logic, even you queue new request during irq handler, it should
> work correctly.
> 
> But it is depend on if hardware can indicate current working queue
> position, some time, hardware stop last queue posistion when handle last
> one.
> 
> Frank
> 

I think it doesn't matter, the 2 descriptors are the cfg descriptor and
then the image descriptor.
If the current descriptor register remains the last image descriptor,
the ongoing check works.

And I guess your concern is as below.
If the current descriptor register is still the cfg descriptor, but the
hardware has finished decoding the next image descriptor.

I confirmed with our hardware engineer. This can't happen.
The first cfg decriptor has a next_descpt_ptr that is pointing to the
image descriptor, when the hardware read tne next_descpt_ptr, the
current descriptor register is updated, before the actual decoding.

Thanks,
Ming

>>
>> Thanks,
>> Ming
>>
>>>>
>>>> when driver is handling the first interrupt, two frames are done, then
>>>> driver will fail to wait for the second interrupt.
>>>>
>>>> In such case, driver can check whether the decoding is still ongoing,
>>>> if not, just done the current decoding.
>>>>
>>>> Signed-off-by: Ming Qian <ming.qian@oss.nxp.com>
>>>> ---
>>>>    .../media/platform/nxp/imx-jpeg/mxc-jpeg-hw.h |  1 +
>>>>    .../media/platform/nxp/imx-jpeg/mxc-jpeg.c    | 20 ++++++++++++++++++-
>>>>    2 files changed, 20 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg-hw.h b/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg-hw.h
>>>> index d579c804b047..adb93e977be9 100644
>>>> --- a/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg-hw.h
>>>> +++ b/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg-hw.h
>>>> @@ -89,6 +89,7 @@
>>>>    /* SLOT_STATUS fields for slots 0..3 */
>>>>    #define SLOT_STATUS_FRMDONE			(0x1 << 3)
>>>>    #define SLOT_STATUS_ENC_CONFIG_ERR		(0x1 << 8)
>>>> +#define SLOT_STATUS_ONGOING			(0x1 << 31)
>>>>
>>>>    /* SLOT_IRQ_EN fields TBD */
>>>>
>>>> diff --git a/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c b/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
>>>> index 45705c606769..e6bb45633a19 100644
>>>> --- a/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
>>>> +++ b/drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
>>>> @@ -910,6 +910,23 @@ static u32 mxc_jpeg_get_plane_size(struct mxc_jpeg_q_data *q_data, u32 plane_no)
>>>>    	return size;
>>>>    }
>>>>
>>>> +static bool mxc_dec_is_ongoing(struct mxc_jpeg_ctx *ctx)
>>>> +{
>>>> +	struct mxc_jpeg_dev *jpeg = ctx->mxc_jpeg;
>>>> +	u32 curr_desc;
>>>> +	u32 slot_status;
>>>> +
>>>> +	slot_status = readl(jpeg->base_reg + MXC_SLOT_OFFSET(ctx->slot, SLOT_STATUS));
>>>> +	curr_desc = readl(jpeg->base_reg + MXC_SLOT_OFFSET(ctx->slot, SLOT_CUR_DESCPT_PTR));
>>>> +
>>>> +	if (curr_desc == jpeg->slot_data.cfg_desc_handle)
>>>> +		return true;
>>>> +	if (slot_status & SLOT_STATUS_ONGOING)
>>>> +		return true;
>>>> +
>>>> +	return false;
>>>> +}
>>>> +
>>>>    static irqreturn_t mxc_jpeg_dec_irq(int irq, void *priv)
>>>>    {
>>>>    	struct mxc_jpeg_dev *jpeg = priv;
>>>> @@ -979,7 +996,8 @@ static irqreturn_t mxc_jpeg_dec_irq(int irq, void *priv)
>>>>    		mxc_jpeg_enc_mode_go(dev, reg, mxc_jpeg_is_extended_sequential(q_data->fmt));
>>>>    		goto job_unlock;
>>>>    	}
>>>> -	if (jpeg->mode == MXC_JPEG_DECODE && jpeg_src_buf->dht_needed) {
>>>> +	if (jpeg->mode == MXC_JPEG_DECODE && jpeg_src_buf->dht_needed &&
>>>> +	    mxc_dec_is_ongoing(ctx)) {
>>>>    		jpeg_src_buf->dht_needed = false;
>>>>    		dev_dbg(dev, "Decoder DHT cfg finished. Start decoding...\n");
>>>>    		goto job_unlock;
>>>> --
>>>> 2.43.0-rc1
>>>>

  reply	other threads:[~2025-04-01  3:17 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-28  6:30 [PATCH v2 0/3] media: imx-jpeg: Fix some motion-jpeg decoding issues ming.qian
2025-03-28  6:30 ` [PATCH v2 1/3] media: imx-jpeg: Enhance error handling in buffer allocation ming.qian
2025-03-28 14:27   ` Frank Li
2025-04-05 11:39   ` Sebastian Fricke
2025-04-07  2:52     ` Ming Qian(OSS)
2025-03-28  6:30 ` [PATCH v2 2/3] media: imx-jpeg: Change the pattern size to 128x64 ming.qian
2025-03-28 14:28   ` Frank Li
2025-04-05 15:26   ` Sebastian Fricke
2025-04-07  2:54     ` Ming Qian(OSS)
2025-03-28  6:30 ` [PATCH v2 3/3] media: imx-jpeg: Check decoding is ongoing for motion-jpeg ming.qian
2025-03-28 14:45   ` Frank Li
2025-03-31  3:10     ` Ming Qian(OSS)
2025-03-31 14:32       ` Frank Li
2025-04-01  3:17         ` Ming Qian(OSS) [this message]
2025-04-01 14:37           ` Frank Li
2025-04-02  5:34             ` Ming Qian(OSS)
2025-04-02 18:03               ` Frank Li
2025-04-03  6:23                 ` Ming Qian(OSS)
2025-04-05 15:37   ` Sebastian Fricke
2025-04-07  5:14     ` 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=22fd3087-6832-4b61-8c78-bc8dd3ac808b@oss.nxp.com \
    --to=ming.qian@oss.nxp.com \
    --cc=Frank.li@nxp.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=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=mirela.rabulea@oss.nxp.com \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@kernel.org \
    --cc=xiahong.bao@nxp.com \
    /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®