From: "Du, Bin" <bin.du@amd.com>
To: Sultan Alsawaf <sultan@kerneltoast.com>
Cc: mchehab@kernel.org, hverkuil@xs4all.nl,
laurent.pinchart+renesas@ideasonboard.com,
bryan.odonoghue@linaro.org, sakari.ailus@linux.intel.com,
prabhakar.mahadev-lad.rj@bp.renesas.com,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
pratap.nirujogi@amd.com, benjamin.chan@amd.com, king.li@amd.com,
gjorgji.rosikopulos@amd.com, Phil.Jawich@amd.com,
Dominic.Antony@amd.com, mario.limonciello@amd.com,
richard.gong@amd.com, anson.tsao@amd.com
Subject: Re: [PATCH v5 0/7] Add AMD ISP4 driver
Date: Tue, 11 Nov 2025 17:58:10 +0800 [thread overview]
Message-ID: <e09207fd-1879-44c8-a5c1-838a140dcd4b@amd.com> (raw)
In-Reply-To: <aRL8ZPwXSeKD4Qmn@sultan-box>
On 11/11/2025 5:05 PM, Sultan Alsawaf wrote:
> On Mon, Nov 10, 2025 at 05:46:28PM +0800, Du, Bin wrote:
>> Thank you, Sultan, for your time, big effort, and constant support.
>> Apologies for my delayed reply for being occupied a little with other
>> matters.
>>
>> On 11/10/2025 4:33 PM, Sultan Alsawaf wrote:
>>> Hi Bin,
>>>
>>> On Wed, Nov 05, 2025 at 01:25:58AM -0800, Sultan Alsawaf wrote:
>>>> Hi Bin,
>>>>
>>>> To expedite review, I've attached a patch containing a bunch of fixes I've made
>>>> on top of v5. Most of my changes should be self-explanatory; feel free to ask
>>>> further about specific changes if you have any questions.
>>>>
>>>> I haven't had a chance to review all of the v4 -> v5 changes yet, but I figured
>>>> I should send what I've got so far.
>>>>
>>>> FYI, there is a regression in isp4if_dequeue_buffer() where the bufq lock isn't
>>>> protecting the list_del() anymore. I also checked the compiler output when using
>>>> guard() versus scoped_guard() in that function and there is no difference:
>>>>
>>>> sha1sum:
>>>> 5652a0306da22ea741d80a9e03a787d0f71758a8 isp4_interface.o // guard()
>>>> 5652a0306da22ea741d80a9e03a787d0f71758a8 isp4_interface.o // scoped_guard()
>>>>
>>>> So guard() should be used there again, which I've done in my patch.
>>>>
>>>> I also have a few questions:
>>>>
>>>> 1. Does ISP FW provide a register interface to disable the IRQ? If so, it is
>>>> faster to use that than using disable_irq_nosync() to disable the IRQ from
>>>> the CPU's side.
>>>>
>>>> 2. When the IRQ is re-enabled in isp4sd_fw_resp_func(), is there anything
>>>> beforehand to mask all pending interrupts from the ISP so that there isn't a
>>>> bunch of stale interrupts firing as soon the IRQ is re-enabled?
>>>>
>>>> 3. Is there any risk of deadlock due to the stream kthread racing with the ISP
>>>> when the ISP posts a new response _after_ the kthread determines there are no
>>>> more new responses but _before_ the enable_irq() in isp4sd_fw_resp_func()?
>>>>
>>>> 4. Why are some lines much longer than before? It seems inconsistent that now
>>>> there is a mix of several lines wrapped to 80 cols and many lines going
>>>> beyond 80 cols. And there are multiple places where code is wrapped before
>>>> reaching 80 cols even with lots of room left, specifically for cases where it
>>>> wouldn't hurt readability to put more characters onto each line.
>>>
>>> I've attached a new, complete patch of changes to apply on top of v5. You may
>>> ignore the incomplete patch from my previous email and use the new one instead.
>>>
>>> I made many changes and also answered questions 1-3 myself.
>>>
>>> Please apply this on top of v5 and let me know if you have any questions.
>>>
>>
>> Sure, will review, apply and test your patch accordingly. Your contribution
>> is greatly appreciated, will let you know if there is any question or
>> problem.
>>
>>> BTW, I noticed a strange regression in v5 even without any of my changes: every
>>> time you use cheese after using it one time, the video will freeze after 30-60
>>> seconds with this message printed to dmesg:
>>> [ 2032.716559] amd_isp_capture amd_isp_capture: -><- fail respid unknown respid(0x30002)
>>>
>>> And the video never unfreezes. I haven't found the cause for the regression yet;
>>> can you try to reproduce it?
>>>
>>
>> Really weird, we don't see this issue either in dev or QA test. Is it 100%
>> reproducible and any other fail or err in the log?
>
> Yes, it's 100% reproducible. There's no other message in dmesg, only that one.
>
> Sometimes there is a stop stream error when I close cheese after it froze:
>
> [ 656.540307] amd_isp_capture amd_isp_capture: fail to disable stream
> [ 657.046633] amd_isp_capture amd_isp_capture: fail to stop steam
> [ 657.047224] amd_isp_capture amd_isp_capture: disabling streaming failed (-110)
>
> When I revert to v4 I cannot reproduce it at all. It seems to be something in
> v4 -> v5 that is not fixed by any of my changes.
>
Hi Sultan, could you please try following modifications on top of v5 to
see if it helps?
diff --git a/drivers/media/platform/amd/isp4/isp4_fw_cmd_resp.h
b/drivers/media/platform/amd/isp4/isp4_fw_cmd_resp.h
index 39c2265121f9..d571b3873edb 100644
--- a/drivers/media/platform/amd/isp4/isp4_fw_cmd_resp.h
+++ b/drivers/media/platform/amd/isp4/isp4_fw_cmd_resp.h
@@ -97,7 +97,7 @@
#define ADDR_SPACE_TYPE_GPU_VA 4
-#define FW_MEMORY_POOL_SIZE (200 * 1024 * 1024)
+#define FW_MEMORY_POOL_SIZE (100 * 1024 * 1024)
/*
* standard ISP mipicsi=>isp
diff --git a/drivers/media/platform/amd/isp4/isp4_subdev.c
b/drivers/media/platform/amd/isp4/isp4_subdev.c
index 248d10076ae8..acbc80aa709e 100644
--- a/drivers/media/platform/amd/isp4/isp4_subdev.c
+++ b/drivers/media/platform/amd/isp4/isp4_subdev.c
@@ -697,7 +697,7 @@ static int isp4sd_stop_resp_proc_threads(struct
isp4_subdev *isp_subdev)
return 0;
}
-static int isp4sd_pwroff_and_deinit(struct isp4_subdev *isp_subdev)
+static int isp4sd_pwroff_and_deinit(struct isp4_subdev *isp_subdev,
bool irq_enabled)
{
struct isp4sd_sensor_info *sensor_info = &isp_subdev->sensor_info;
unsigned int perf_state = ISP4SD_PERFORMANCE_STATE_LOW;
@@ -716,8 +716,9 @@ static int isp4sd_pwroff_and_deinit(struct
isp4_subdev *isp_subdev)
return 0;
}
- for (int i = 0; i < ISP4SD_MAX_FW_RESP_STREAM_NUM; i++)
- disable_irq(isp_subdev->irq[i]);
+ if (irq_enabled)
+ for (int i = 0; i < ISP4SD_MAX_FW_RESP_STREAM_NUM; i++)
+ disable_irq(isp_subdev->irq[i]);
isp4sd_stop_resp_proc_threads(isp_subdev);
dev_dbg(dev, "isp_subdev stop resp proc streads suc");
@@ -813,7 +814,7 @@ static int isp4sd_pwron_and_init(struct isp4_subdev
*isp_subdev)
return 0;
err_unlock_and_close:
- isp4sd_pwroff_and_deinit(isp_subdev);
+ isp4sd_pwroff_and_deinit(isp_subdev, false);
return -EINVAL;
}
@@ -985,7 +986,7 @@ static int isp4sd_set_power(struct v4l2_subdev *sd,
int on)
if (on)
return isp4sd_pwron_and_init(isp_subdev);
else
- return isp4sd_pwroff_and_deinit(isp_subdev);
+ return isp4sd_pwroff_and_deinit(isp_subdev, true);
}
static const struct v4l2_subdev_core_ops isp4sd_core_ops = {
On the other hand, please also add the patch in amdgpu which sets *bo to
NULL in isp_kernel_buffer_alloc() which you mentioned in another thread.
> I will try to identify the cause this week.
>
> Sultan
--
Regards,
Bin
next prev parent reply other threads:[~2025-11-11 9:58 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-24 9:06 Bin Du
2025-10-24 9:06 ` [PATCH v5 1/7] media: platform: amd: Introduce amd isp4 capture driver Bin Du
2025-10-24 13:57 ` Krzysztof Kozlowski
2025-10-28 8:30 ` Du, Bin
2025-10-28 8:41 ` Krzysztof Kozlowski
2025-10-28 9:00 ` Du, Bin
2025-10-28 9:06 ` Krzysztof Kozlowski
2025-10-28 9:10 ` Du, Bin
2025-11-03 6:17 ` Du, Bin
2025-10-24 9:06 ` [PATCH v5 2/7] media: platform: amd: low level support for isp4 firmware Bin Du
2025-10-24 9:06 ` [PATCH v5 3/7] media: platform: amd: Add isp4 fw and hw interface Bin Du
2025-10-24 9:06 ` [PATCH v5 4/7] media: platform: amd: isp4 subdev and firmware loading handling added Bin Du
2025-10-24 9:06 ` [PATCH v5 5/7] media: platform: amd: isp4 video node and buffers " Bin Du
2025-10-24 9:06 ` [PATCH v5 6/7] media: platform: amd: isp4 debug fs logging and more descriptive errors Bin Du
2025-10-24 9:06 ` [PATCH v5 7/7] Documentation: add documentation of AMD isp 4 driver Bin Du
2025-11-05 9:25 ` [PATCH v5 0/7] Add AMD ISP4 driver Sultan Alsawaf
2025-11-10 8:33 ` Sultan Alsawaf
2025-11-10 9:46 ` Du, Bin
2025-11-11 9:05 ` Sultan Alsawaf
2025-11-11 9:58 ` Du, Bin [this message]
2025-11-11 23:33 ` Sultan Alsawaf
2025-11-12 1:21 ` Sultan Alsawaf
2025-11-12 6:32 ` Du, Bin
2025-11-12 7:06 ` Sultan Alsawaf
2025-11-12 7:38 ` Sultan Alsawaf
2025-11-12 10:21 ` Du, Bin
2025-11-18 7:35 ` Sultan Alsawaf
2025-11-19 10:14 ` Du, Bin
2025-11-21 8:20 ` Sultan Alsawaf
2025-11-21 14:32 ` Mario Limonciello
2025-11-21 15:39 ` Sultan Alsawaf
2025-11-21 15:46 ` Mario Limonciello
2025-11-21 16:31 ` Sultan Alsawaf
2025-11-21 17:52 ` Mario Limonciello
2025-11-22 2:55 ` Sultan Alsawaf
2025-11-22 3:19 ` Sultan Alsawaf
2025-11-25 7:55 ` Sultan Alsawaf
2025-11-27 6:16 ` Du, Bin
2025-11-27 6:40 ` Sultan Alsawaf
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=e09207fd-1879-44c8-a5c1-838a140dcd4b@amd.com \
--to=bin.du@amd.com \
--cc=Dominic.Antony@amd.com \
--cc=Phil.Jawich@amd.com \
--cc=anson.tsao@amd.com \
--cc=benjamin.chan@amd.com \
--cc=bryan.odonoghue@linaro.org \
--cc=gjorgji.rosikopulos@amd.com \
--cc=hverkuil@xs4all.nl \
--cc=king.li@amd.com \
--cc=laurent.pinchart+renesas@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=mchehab@kernel.org \
--cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
--cc=pratap.nirujogi@amd.com \
--cc=richard.gong@amd.com \
--cc=sakari.ailus@linux.intel.com \
--cc=sultan@kerneltoast.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®