Message-ID: <c97c6fab-cc13-4fb9-a91c-58ce0bb5e593@oss.nxp.com>
Date: Thu, 3 Apr 2025 14:23:15 +0800
From: "Ming Qian(OSS)" <ming.qian@....nxp.com>
To: Frank Li <Frank.li@....com>
Cc: mchehab@...nel.org, hverkuil-cisco@...all.nl, mirela.rabulea@....nxp.com,
 shawnguo@...nel.org, s.hauer@...gutronix.de, kernel@...gutronix.de,
 festevam@...il.com, xiahong.bao@....com, eagle.zhou@....com,
 linux-imx@....com, imx@...ts.linux.dev, linux-media@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 3/3] media: imx-jpeg: Check decoding is ongoing for
 motion-jpeg

Hi Frank,

On 2025/4/3 2:03, Frank Li wrote:
> On Wed, Apr 02, 2025 at 01:34:00PM +0800, Ming Qian(OSS) wrote:
>> Hi Frank,
>>
>>
>> On 2025/4/1 22:37, Frank Li wrote:
>>> On Tue, Apr 01, 2025 at 11:17:36AM +0800, Ming Qian(OSS) wrote:
>>>>
>>>> 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@....nxp.com wrote:
>>>>>>>> From: Ming Qian <ming.qian@....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.
>>>
>>> Maybe off topic,
>>>
>>> CFG->next = Image
>>>
>>> Image->next = NULL;
>>>
>>> If hardware finish image descriptior, current descriptor is 'Image' or 'NULL'
>>>
>>> If it is 'Image', need extra status bit show 'done'
>>>
>>> 1:	slot_status = readl(jpeg->base_reg + MXC_SLOT_OFFSET(ctx->slot, SLOT_STATUS));
>>>
>>> I suppose it should be DONE status if just finish CFG description.
>>>
>>> 2: 	curr_desc = readl(jpeg->base_reg + MXC_SLOT_OFFSET(ctx->slot, SLOT_CUR_DESCPT_PTR));
>>>
>>> It is possible curr_desc already was 'Image' after 1.
>>>
>>>    if (curr_desc == jpeg->slot_data.cfg_desc_handle)  //not hit this
>>>           return true;
>>>
>>>    if (slot_status & SLOT_STATUS_ONGOING)  // not hit this
>>>           return true;
>>>
>>> fake false may return.
>>>
>>> check two aync condition "slot_status" and "curr_desc" always be risk. But
>>> I don't know what's happen if fake false return here.
>>>
>>> for this type check
>>> 	do {
>>> 		slot_status = readl();
>>> 		curr_desc = readl();
>>> 	} while (slot_status != read());
>>>
>>> to make sure slot_status and cur_desc indicate the hardware status
>>> correctly.
>>
>> I confirmed with the hardware engineer, the curr_desc register is set
>> when hardware load next_descpt_ptr,
> 
> The key is last one, does last one set curr_desc to NULL when it done.
> If yes, the whole logic will be much simple. You just need check
> curr_desc.

No, the curr_desc will remain the last image descripor even after done.

> 
>> but the ongoing bit is set when
>> hardware finish loading the content of the descriptor, the size is 32
>> bytes.
>> So you are right, the slot_status and curr_desc is not synchronous,
>> but the gap time will be very short
> 
> Yes, it will be really hard to debug it if met once.
> 

I think we can read the slot_status twice to reduce the probability to
almost 0.



>>
>> This patch is a workaround that hardware finish 2 descriptors too soon,
>> irq() is not scheduled on time, the driver keeps waiting until timeout.
>>
>> And I agree there is still some risk that the ongoing check may return
>> fake false, even if the probability of occurrence is extremely low.
>>
>> When the fake false return, the driver will finish current decoding
>> early, and the decoded image is incomplete.
>>
>> But we don't want to change to poll the done status.
> 
> It is not poll the done. It's compare if status is the same by twice read.
> Most time needn't retry.
> 
> The basic idea is the same as
> https://elixir.bootlin.com/linux/v6.14-rc6/source/drivers/clocksource/arm_global_timer.c#L73
> 

I checked the _gt_counter_read(), But I think its usage scenario is
different from here.

In _gt_counter_read(), its purpose is to ensure that the upper 32-bits
do not change when reading the lower 32-bits.
1. Read the upper 32-bit timer counter register
2. Read the lower 32-bit timer counter register
3. Read the upper 32-bit timer counter register again.
If the value in step 1 is equal to step 3, it means the upper 32 bits
are not changed, and the lower 32-bits are right.

But here, we don't expect the slot_status is the same by twice read.
Now the case is:
1. curr_desc is switched to the image descriptor.
2. the ongoing bit is set after the 32 bytes descriptor is loaded.
The 2 steps are not synchronized.

If slot_status is read twice between step 1 and 2, the value is same,
but still return fake false.

I'd like to check the slot_status twice and add a delay:

slot_status = readl(jpeg->base_reg + MXC_SLOT_OFFSET(ctx->slot, 
SLOT_STATUS));
if (slot_status & SLOT_STATUS_ONGOING)
	return true;

udelay(10);

slot_status = readl(jpeg->base_reg + MXC_SLOT_OFFSET(ctx->slot, 
SLOT_STATUS));
if (slot_status & SLOT_STATUS_ONGOING)
	return true;

return false;

This delay should be able to avoid stepping into the intermediate state
between steps 1 and 2.

Thanks,
Ming

>>
>> Considering the probability of occurrence and the respective
>> consequences, I think this patch still makes sense.
>>
>> Maybe we can check the slot_status register twice and add a short delay
>> in between. Then the probability of returning fake false is basically
>> reduced to 0.
>>
>> Thanks,
>> Ming
>>
>>>
>>> Frank
>>>>
>>>> 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@....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
>>>>>>>>

Powered by blists - more mailing lists