All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Hung <alex.hung@amd.com>
To: "Borah, Chaitanya Kumar" <chaitanya.kumar.borah@intel.com>,
	"Sharma, Swati2" <swati2.sharma@intel.com>,
	igt-dev@lists.freedesktop.org
Cc: Harry Wentland <harry.wentland@amd.com>
Subject: Re: [i-g-t] tests/kms_colorop: Use local variable for color pipeline cap
Date: Fri, 28 Aug 2026 09:32:40 -0600	[thread overview]
Message-ID: <a10ae5f1-e2e8-496b-91af-34eebb48720f@amd.com> (raw)
In-Reply-To: <a45a1a06-36e0-4d66-99ce-3d558ecd14e9@intel.com>



On 8/28/26 04:04, Borah, Chaitanya Kumar wrote:
> 
> 
> On 8/28/2026 5:45 AM, Alex Hung wrote:
>>
>>
>> On 8/26/26 23:31, Sharma, Swati2 wrote:
>>> Hi Chaitanya
>>>
>>> Patch LGTM
>>>
>>> Reviewed-by: Swati Sharma <swati2.sharma@intel.com>
>>>
>>> Also, it seems we have duplicate igt_display_require(&display, 
>>> display.drm_fd);
>>>
>>> It is required once. Anyways, its a separate patch.
>>>
>>> Alex,
>>>
>>> Can you please test on AMD driver with above change?
>>
>> yes it ran fine. Some inline comments below.
>>
>>>
>>> On 03-08-2026 01:33 pm, Chaitanya Kumar Borah wrote:
>>>> Following the pattern in kms_color_pipeline, set
>>>> DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE once and stash the result in a
>>>> local variable, then propagate it to display->has_plane_color_pipeline
>>>> after the final igt_display_require() (which reinitializes the display
>>>> state). This avoids calling drmSetClientCap() twice.
>>>>
>>>> Cc: Swati Sharma <swati2.sharma@intel.com>
>>>> Cc: Harry Wentland <harry.wentland@amd.com>
>>>> Cc: Alex Hung <alex.hung@amd.com>
>>>> Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
>>>> ---
>>>>   tests/kms_colorop.c | 9 +++++----
>>>>   1 file changed, 5 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/tests/kms_colorop.c b/tests/kms_colorop.c
>>>> index 16db0b8ad..d573d2ceb 100644
>>>> --- a/tests/kms_colorop.c
>>>> +++ b/tests/kms_colorop.c
>>>> @@ -406,6 +406,7 @@ int igt_main_args("d", long_options, help_str, 
>>>> opt_handler, NULL)
>>>>       igt_display_t display;
>>>>       int i, j, ret;
>>>> +    int has_plane_color_pipeline = 0;
>> can this be bool?
>>
>>>>       igt_fixture() {
>>>>           display.drm_fd = drm_open_driver_master(DRIVER_ANY);
>>>> @@ -417,15 +418,15 @@ int igt_main_args("d", long_options, help_str, 
>>>> opt_handler, NULL)
>>>>           igt_require_f(!ret, "error setting 
>>>> DRM_CLIENT_CAP_WRITEBACK_CONNECTORS\n");
>>>> -        igt_display_require(&display, display.drm_fd);
>>>>           if (drmSetClientCap(display.drm_fd, 
>>>> DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE, 1) == 0)
>>>> -            display.has_plane_color_pipeline = 1;
>>>> +            has_plane_color_pipeline = 1;
>>>> +
>>>> +        igt_display_require(&display, display.drm_fd);
>> is this igt_display_require() necessary?
>>
> 
> Swati flagged this too and this is probably unnecessary. However, I 
> thought of handling it in a separate patch. What do you think?

Sure. This is not a blocker

Reviewed-by: Alex Hung <alex.hung@amd.com>

> 
>>>>           kmstest_set_vt_graphics_mode();
>>>>           igt_display_require(&display, display.drm_fd);
>>>> -        if (drmSetClientCap(display.drm_fd, 
>>>> DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE, 1) == 0)
>>>> -            display.has_plane_color_pipeline = 1;
>>>> +        display.has_plane_color_pipeline = has_plane_color_pipeline;
>>>>           igt_require(display.is_atomic);
>>>>       }
>>
> 


  reply	other threads:[~2026-08-28 15:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-03  8:03 [i-g-t] tests/kms_colorop: Use local variable for color pipeline cap Chaitanya Kumar Borah
2026-08-03 19:33 ` ✗ Xe.CI.FULL: failure for " Patchwork
2026-08-04 13:42 ` ✓ Xe.CI.BAT: success " Patchwork
2026-08-04 14:00 ` ✓ i915.CI.BAT: " Patchwork
2026-08-04 18:18 ` ✓ i915.CI.Full: " Patchwork
2026-08-04 20:37 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-08-27  5:31 ` [i-g-t] " Sharma, Swati2
2026-08-28  0:15   ` Alex Hung
2026-08-28 10:04     ` Borah, Chaitanya Kumar
2026-08-28 15:32       ` Alex Hung [this message]
2026-08-27 15:36 ` Kamil Konieczny
2026-08-28 10:05   ` Borah, Chaitanya Kumar

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=a10ae5f1-e2e8-496b-91af-34eebb48720f@amd.com \
    --to=alex.hung@amd.com \
    --cc=chaitanya.kumar.borah@intel.com \
    --cc=harry.wentland@amd.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=swati2.sharma@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.