[PATCH 1/2] drm/amd/display: dc_link: code clean up on enable_link_dp function

[Melissa Wen]

Coding style clean up on enable_link_dp function as suggested by
checkpatch.pl:

CHECK: Lines should not end with a '('
WARNING: line over 80 characters
WARNING: suspect code indent for conditional statements (8, 24)
CHECK: braces {} should be used on all arms of this statement
ERROR: else should follow close brace '}'
CHECK: Comparison to NULL could be written
   "link->preferred_training_settings.fec_enable"

Signed-off-by: Melissa Wen 
---
 drivers/gpu/drm/amd/display/dc/core/dc_link.c | 32 +--
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index a09119c10d7c..0f28b5694144 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -1480,9 +1480,8 @@ static void enable_stream_features(struct pipe_ctx 
*pipe_ctx)
}
 }
 
-static enum dc_status enable_link_dp(
-   struct dc_state *state,
-   struct pipe_ctx *pipe_ctx)
+static enum dc_status enable_link_dp(struct dc_state *state,
+struct pipe_ctx *pipe_ctx)
 {
struct dc_stream_state *stream = pipe_ctx->stream;
enum dc_status status;
@@ -1512,27 +1511,28 @@ static enum dc_status enable_link_dp(
 
pipe_ctx->stream_res.pix_clk_params.requested_sym_clk =
link_settings.link_rate * LINK_RATE_REF_FREQ_IN_KHZ;
-   if (state->clk_mgr && !apply_seamless_boot_optimization)
-   state->clk_mgr->funcs->update_clocks(state->clk_mgr, state, 
false);
+   if (state->clk_mgr && !apply_seamless_boot_optimization) {
+   state->clk_mgr->funcs->update_clocks(state->clk_mgr,
+state, false);
+   }
 
skip_video_pattern = true;
 
if (link_settings.link_rate == LINK_RATE_LOW)
-   skip_video_pattern = false;
-
-   if (perform_link_training_with_retries(
-   _settings,
-   skip_video_pattern,
-   LINK_TRAINING_ATTEMPTS,
-   pipe_ctx,
-   pipe_ctx->stream->signal)) {
+   skip_video_pattern = false;
+
+   if (perform_link_training_with_retries(_settings,
+  skip_video_pattern,
+  LINK_TRAINING_ATTEMPTS,
+  pipe_ctx,
+  pipe_ctx->stream->signal)) {
link->cur_link_settings = link_settings;
status = DC_OK;
-   }
-   else
+   } else {
status = DC_FAIL_DP_LINK_TRAINING;
+   }
 
-   if (link->preferred_training_settings.fec_enable != NULL)
+   if (link->preferred_training_settings.fec_enable)
fec_enable = *link->preferred_training_settings.fec_enable;
else
fec_enable = true;
-- 
2.25.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/2] drm/amd/display: dc_link: cleaning up some code style issues

[Melissa Wen]

This patchset solves some coding style issues on dc_link for readability
and cleaning up warnings. Change suggested by checkpatch.pl. 

Melissa Wen (2):
  drm/amd/display: dc_link: code clean up on enable_link_dp function
  drm/amd/display: dc_link: code clean up on detect_dp function

 drivers/gpu/drm/amd/display/dc/core/dc_link.c | 67 +--
 1 file changed, 32 insertions(+), 35 deletions(-)

-- 
2.25.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/amd/display: dc_link: code clean up on detect_dp function

[Melissa Wen]

Removes codestyle issues on detect_dp function as suggested by
checkpatch.pl.

CHECK: Lines should not end with a '('
WARNING: Missing a blank line after declarations
WARNING: line over 80 characters
CHECK: Alignment should match open parenthesis

Signed-off-by: Melissa Wen 
---
 drivers/gpu/drm/amd/display/dc/core/dc_link.c | 35 +--
 1 file changed, 16 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index 0f28b5694144..adb717f02c9c 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -585,14 +585,14 @@ static void read_current_link_settings_on_detect(struct 
dc_link *link)
LINK_SPREAD_05_DOWNSPREAD_30KHZ : LINK_SPREAD_DISABLED;
 }
 
-static bool detect_dp(
-   struct dc_link *link,
-   struct display_sink_capability *sink_caps,
-   bool *converter_disable_audio,
-   struct audio_support *audio_support,
-   enum dc_detect_reason reason)
+static bool detect_dp(struct dc_link *link,
+ struct display_sink_capability *sink_caps,
+ bool *converter_disable_audio,
+ struct audio_support *audio_support,
+ enum dc_detect_reason reason)
 {
bool boot = false;
+
sink_caps->signal = link_detect_sink(link, reason);
sink_caps->transaction_type =
get_ddc_transaction_type(sink_caps->signal);
@@ -606,9 +606,8 @@ static bool detect_dp(
sink_caps->signal = SIGNAL_TYPE_DISPLAY_PORT_MST;
link->type = dc_connection_mst_branch;
 
-   dal_ddc_service_set_transaction_type(
-   link->ddc,
-   
sink_caps->transaction_type);
+   dal_ddc_service_set_transaction_type(link->ddc,
+
sink_caps->transaction_type);
 
/*
 * This call will initiate MST topology discovery. Which
@@ -637,13 +636,10 @@ static bool detect_dp(
if (reason == DETECT_REASON_BOOT)
boot = true;
 
-   dm_helpers_dp_update_branch_info(
-   link->ctx,
-   link);
+   dm_helpers_dp_update_branch_info(link->ctx, link);
 
-   if (!dm_helpers_dp_mst_start_top_mgr(
-   link->ctx,
-   link, boot)) {
+   if (!dm_helpers_dp_mst_start_top_mgr(link->ctx,
+link, boot)) {
/* MST not supported */
link->type = dc_connection_single;
sink_caps->signal = SIGNAL_TYPE_DISPLAY_PORT;
@@ -651,7 +647,7 @@ static bool detect_dp(
}
 
if (link->type != dc_connection_mst_branch &&
-   is_dp_active_dongle(link)) {
+   is_dp_active_dongle(link)) {
/* DP active dongles */
link->type = dc_connection_active_dongle;
if (!link->dpcd_caps.sink_count.bits.SINK_COUNT) {
@@ -662,14 +658,15 @@ static bool detect_dp(
return true;
}
 
-   if (link->dpcd_caps.dongle_type != 
DISPLAY_DONGLE_DP_HDMI_CONVERTER)
+   if (link->dpcd_caps.dongle_type !=
+   DISPLAY_DONGLE_DP_HDMI_CONVERTER)
*converter_disable_audio = true;
}
} else {
/* DP passive dongles */
sink_caps->signal = dp_passive_dongle_detection(link->ddc,
-   sink_caps,
-   audio_support);
+   sink_caps,
+   audio_support);
}
 
return true;
-- 
2.25.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/2] drm/amd/display: dc_link: code clean up on enable_link_dp function

[Melissa Wen]

Coding style clean up on enable_link_dp function as suggested by
checkpatch.pl:

CHECK: Lines should not end with a '('
WARNING: line over 80 characters
WARNING: suspect code indent for conditional statements (8, 24)
CHECK: braces {} should be used on all arms of this statement
ERROR: else should follow close brace '}'
CHECK: Comparison to NULL could be written
   "link->preferred_training_settings.fec_enable"

Signed-off-by: Melissa Wen 
---
 drivers/gpu/drm/amd/display/dc/core/dc_link.c | 29 +--
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index 02e1ad318203..eb9894e416ed 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -1498,9 +1498,8 @@ static void enable_stream_features(struct pipe_ctx 
*pipe_ctx)
}
 }
 
-static enum dc_status enable_link_dp(
-   struct dc_state *state,
-   struct pipe_ctx *pipe_ctx)
+static enum dc_status enable_link_dp(struct dc_state *state,
+struct pipe_ctx *pipe_ctx)
 {
struct dc_stream_state *stream = pipe_ctx->stream;
enum dc_status status;
@@ -1532,7 +1531,8 @@ static enum dc_status enable_link_dp(
pipe_ctx->stream_res.pix_clk_params.requested_sym_clk =
link_settings.link_rate * LINK_RATE_REF_FREQ_IN_KHZ;
if (state->clk_mgr && !apply_seamless_boot_optimization)
-   state->clk_mgr->funcs->update_clocks(state->clk_mgr, state, 
false);
+   state->clk_mgr->funcs->update_clocks(state->clk_mgr,
+state, false);
 
// during mode switch we do DP_SET_POWER off then on, and OUI is lost
dpcd_set_source_specific_data(link);
@@ -1540,21 +1540,20 @@ static enum dc_status enable_link_dp(
skip_video_pattern = true;
 
if (link_settings.link_rate == LINK_RATE_LOW)
-   skip_video_pattern = false;
-
-   if (perform_link_training_with_retries(
-   _settings,
-   skip_video_pattern,
-   LINK_TRAINING_ATTEMPTS,
-   pipe_ctx,
-   pipe_ctx->stream->signal)) {
+   skip_video_pattern = false;
+
+   if (perform_link_training_with_retries(_settings,
+  skip_video_pattern,
+  LINK_TRAINING_ATTEMPTS,
+  pipe_ctx,
+  pipe_ctx->stream->signal)) {
link->cur_link_settings = link_settings;
status = DC_OK;
-   }
-   else
+   } else {
status = DC_FAIL_DP_LINK_TRAINING;
+   }
 
-   if (link->preferred_training_settings.fec_enable != NULL)
+   if (link->preferred_training_settings.fec_enable)
fec_enable = *link->preferred_training_settings.fec_enable;
else
fec_enable = true;
-- 
2.25.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 0/2] drm/amd/display: dc_link: cleaning up some code style issues

[Melissa Wen]

This patchset solves some coding style issues on dc_link for readability
and cleaning up warnings. Change suggested by checkpatch.pl.

Changes in v2:
- Apply patches to the right amdgpu repository.
- Remove unnecessary {} added in the previous version.

Melissa Wen (2):
  drm/amd/display: dc_link: code clean up on enable_link_dp function
  drm/amd/display: dc_link: code clean up on detect_dp function

 drivers/gpu/drm/amd/display/dc/core/dc_link.c | 64 +--
 1 file changed, 30 insertions(+), 34 deletions(-)

-- 
2.25.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/2] drm/amd/display: dc_link: code clean up on detect_dp function

[Melissa Wen]

Removes codestyle issues on detect_dp function as suggested by
checkpatch.pl.

CHECK: Lines should not end with a '('
WARNING: Missing a blank line after declarations
WARNING: line over 80 characters
CHECK: Alignment should match open parenthesis

Signed-off-by: Melissa Wen 
---
 drivers/gpu/drm/amd/display/dc/core/dc_link.c | 35 +--
 1 file changed, 16 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index eb9894e416ed..549bea1d725c 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -585,14 +585,14 @@ static void read_current_link_settings_on_detect(struct 
dc_link *link)
LINK_SPREAD_05_DOWNSPREAD_30KHZ : LINK_SPREAD_DISABLED;
 }
 
-static bool detect_dp(
-   struct dc_link *link,
-   struct display_sink_capability *sink_caps,
-   bool *converter_disable_audio,
-   struct audio_support *audio_support,
-   enum dc_detect_reason reason)
+static bool detect_dp(struct dc_link *link,
+ struct display_sink_capability *sink_caps,
+ bool *converter_disable_audio,
+ struct audio_support *audio_support,
+ enum dc_detect_reason reason)
 {
bool boot = false;
+
sink_caps->signal = link_detect_sink(link, reason);
sink_caps->transaction_type =
get_ddc_transaction_type(sink_caps->signal);
@@ -609,9 +609,8 @@ static bool detect_dp(
sink_caps->signal = SIGNAL_TYPE_DISPLAY_PORT_MST;
link->type = dc_connection_mst_branch;
 
-   dal_ddc_service_set_transaction_type(
-   link->ddc,
-   
sink_caps->transaction_type);
+   dal_ddc_service_set_transaction_type(link->ddc,
+
sink_caps->transaction_type);
 
/*
 * This call will initiate MST topology discovery. Which
@@ -640,13 +639,10 @@ static bool detect_dp(
if (reason == DETECT_REASON_BOOT)
boot = true;
 
-   dm_helpers_dp_update_branch_info(
-   link->ctx,
-   link);
+   dm_helpers_dp_update_branch_info(link->ctx, link);
 
-   if (!dm_helpers_dp_mst_start_top_mgr(
-   link->ctx,
-   link, boot)) {
+   if (!dm_helpers_dp_mst_start_top_mgr(link->ctx,
+link, boot)) {
/* MST not supported */
link->type = dc_connection_single;
sink_caps->signal = SIGNAL_TYPE_DISPLAY_PORT;
@@ -654,7 +650,7 @@ static bool detect_dp(
}
 
if (link->type != dc_connection_mst_branch &&
-   is_dp_active_dongle(link)) {
+   is_dp_active_dongle(link)) {
/* DP active dongles */
link->type = dc_connection_active_dongle;
if (!link->dpcd_caps.sink_count.bits.SINK_COUNT) {
@@ -665,14 +661,15 @@ static bool detect_dp(
return true;
}
 
-   if (link->dpcd_caps.dongle_type != 
DISPLAY_DONGLE_DP_HDMI_CONVERTER)
+   if (link->dpcd_caps.dongle_type !=
+   DISPLAY_DONGLE_DP_HDMI_CONVERTER)
*converter_disable_audio = true;
}
} else {
/* DP passive dongles */
sink_caps->signal = dp_passive_dongle_detection(link->ddc,
-   sink_caps,
-   audio_support);
+   sink_caps,
+   audio_support);
}
 
return true;
-- 
2.25.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/amd/display: dcn20: remove an unused function

[Melissa Wen]

The dpp2_get_optimal_number_of_taps function is never used. Removing just for
code cleaning up.

Signed-off-by: Melissa Wen 
---
 .../gpu/drm/amd/display/dc/dcn20/dcn20_dpp.c  | 78 ---
 1 file changed, 78 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp.c 
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp.c
index 13e057d7ee93..42bba7c9548b 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dpp.c
@@ -369,84 +369,6 @@ void dpp2_set_cursor_attributes(
}
 }
 
-#define IDENTITY_RATIO(ratio) (dc_fixpt_u3d19(ratio) == (1 << 19))
-
-bool dpp2_get_optimal_number_of_taps(
-   struct dpp *dpp,
-   struct scaler_data *scl_data,
-   const struct scaling_taps *in_taps)
-{
-   /* Some ASICs does not support  FP16 scaling, so we reject modes 
require this*/
-   if (scl_data->viewport.width  != scl_data->h_active &&
-   scl_data->viewport.height != scl_data->v_active &&
-   dpp->caps->dscl_data_proc_format == 
DSCL_DATA_PRCESSING_FIXED_FORMAT &&
-   scl_data->format == PIXEL_FORMAT_FP16)
-   return false;
-
-   if (scl_data->viewport.width > scl_data->h_active &&
-   dpp->ctx->dc->debug.max_downscale_src_width != 0 &&
-   scl_data->viewport.width > 
dpp->ctx->dc->debug.max_downscale_src_width)
-   return false;
-
-   /* TODO: add lb check */
-
-   /* No support for programming ratio of 8, drop to 7.9.. */
-   if (scl_data->ratios.horz.value == (8ll << 32))
-   scl_data->ratios.horz.value--;
-   if (scl_data->ratios.vert.value == (8ll << 32))
-   scl_data->ratios.vert.value--;
-   if (scl_data->ratios.horz_c.value == (8ll << 32))
-   scl_data->ratios.horz_c.value--;
-   if (scl_data->ratios.vert_c.value == (8ll << 32))
-   scl_data->ratios.vert_c.value--;
-
-   /* Set default taps if none are provided */
-   if (in_taps->h_taps == 0) {
-   if (dc_fixpt_ceil(scl_data->ratios.horz) > 4)
-   scl_data->taps.h_taps = 8;
-   else
-   scl_data->taps.h_taps = 4;
-   } else
-   scl_data->taps.h_taps = in_taps->h_taps;
-   if (in_taps->v_taps == 0) {
-   if (dc_fixpt_ceil(scl_data->ratios.vert) > 4)
-   scl_data->taps.v_taps = 8;
-   else
-   scl_data->taps.v_taps = 4;
-   } else
-   scl_data->taps.v_taps = in_taps->v_taps;
-   if (in_taps->v_taps_c == 0) {
-   if (dc_fixpt_ceil(scl_data->ratios.vert_c) > 4)
-   scl_data->taps.v_taps_c = 4;
-   else
-   scl_data->taps.v_taps_c = 2;
-   } else
-   scl_data->taps.v_taps_c = in_taps->v_taps_c;
-   if (in_taps->h_taps_c == 0) {
-   if (dc_fixpt_ceil(scl_data->ratios.horz_c) > 4)
-   scl_data->taps.h_taps_c = 4;
-   else
-   scl_data->taps.h_taps_c = 2;
-   } else if ((in_taps->h_taps_c % 2) != 0 && in_taps->h_taps_c != 1)
-   /* Only 1 and even h_taps_c are supported by hw */
-   scl_data->taps.h_taps_c = in_taps->h_taps_c - 1;
-   else
-   scl_data->taps.h_taps_c = in_taps->h_taps_c;
-
-   if (!dpp->ctx->dc->debug.always_scale) {
-   if (IDENTITY_RATIO(scl_data->ratios.horz))
-   scl_data->taps.h_taps = 1;
-   if (IDENTITY_RATIO(scl_data->ratios.vert))
-   scl_data->taps.v_taps = 1;
-   if (IDENTITY_RATIO(scl_data->ratios.horz_c))
-   scl_data->taps.h_taps_c = 1;
-   if (IDENTITY_RATIO(scl_data->ratios.vert_c))
-   scl_data->taps.v_taps_c = 1;
-   }
-
-   return true;
-}
-
 void oppn20_dummy_program_regamma_pwl(
struct dpp *dpp,
const struct pwl_params *params,
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/2] drm/amd/display: dc_link: cleaning up some code style issues

[Melissa Wen]

Hi Rodrigo,

On 02/27, Rodrigo Siqueira wrote:
> Hi Melissa,
> 
> First of all, thank you very much for this patchset; in general,
> everything looks good to me.
> 
> I noticed that your patchset does not apply because you made your
> changes based on `drm-misc-next`; when you send patches to amdgpu, use
> the following repository:
> 
>  git://people.freedesktop.org/~agd5f/linux 
> 
> Could you prepare a V2?
Yes.

Thanks for reviewing my patches.
Soon, I will send a V2 with the changes suggested by you. 
> 
> Thanks!
> 
> On 02/26, Melissa Wen wrote:
> > This patchset solves some coding style issues on dc_link for readability
> > and cleaning up warnings. Change suggested by checkpatch.pl. 
> > 
> > Melissa Wen (2):
> >   drm/amd/display: dc_link: code clean up on enable_link_dp function
> >   drm/amd/display: dc_link: code clean up on detect_dp function
> > 
> >  drivers/gpu/drm/amd/display/dc/core/dc_link.c | 67 +--
> >  1 file changed, 32 insertions(+), 35 deletions(-)
> > 
> > -- 
> > 2.25.0
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-develdata=02%7C01%7CRodrigo.Siqueira%40amd.com%7C7a3e02e3f43447ed4fab08d7bb080d9b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637183515885211986sdata=bnipkrUtKdO1oOKxdt1th4iIG1%2BBgl2wMPVrdmn3P1U%3Dreserved=0
> 
> -- 
> Rodrigo Siqueira
> https://siqueira.tech

Melissa Wen
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Looking for guidance to reproduce a bug in drm/vkms reported by syzkaller

[Melissa Wen]

Hi,

I am trying to reproduce a syzkaller bug found in the vkms:
- WARNING in vkms_gem_free_object
- https://groups.google.com/forum/#!msg/syzkaller-bugs/_oARhriB1SA/PelnW1BqAwAJ

However, I was not very successful in this task. As I don't know how to deal
with syzkaller and I am not sure if I am following the right steps, it would be
great if someone can give me some tips and guidance.

First, looking at the bug history at:
- https://syzkaller.appspot.com/bug?extid=e7ad70d406e74d8fc9d0,
it seems like the bug still exists. Am I right?

Second, here is a report of what I tried to do:
Note: For testing, I use a VM (QEMU) with Debian 10 with a kernel compiled at
- https://cgit.freedesktop.org/drm/drm-misc (branch drm-misc-next)

1 - Using the usual .config for my VM, I compiled and installed the kernel and,
as root, ran the C program provided by syzkaller:
- https://syzkaller.appspot.com/x/repro.c?x=15e27c5360
Nothing happened.

2 - Then, I checked the debug/panic/hacking/drm/i915 debugging/vkms settings on
the .config reported by syzkaller:
- https://syzkaller.appspot.com/x/.config?x=7cf4eed5fe42c31a
and enabled the same things in my .config.
I compiled and installed the kernel and ran the C program.
Nothing happened.

3 - So, I reverted my current branch to the commit that generated the bug
(as reported: 94e2ec3f7fef86506293a448273b2b4ee21e6195) and used the kernel on
that state.
Nothing happened.

4 - I decided to use the syzkaller .config without modifications and
adaptations for my VM (although I didn't think it felt right). I compiled,
installed... some boot problems happened, but the kernel worked. I ran the C
program and nothing.

So I gave up... for a while :)

Does anyone have any advice for me?
I have already searched for information on the Internet, but I am still stuck.

The last thing that I noted is that syzkaller stopped providing a C program of
this bug for crashes after the beginning of the year (I also don't know if it
is something important).

Thanks in advance,

Melissa Wen
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/4] drm/amd/display: cleanup codestyle type BLOCK_COMMENT_STYLE on dc_link

[Melissa Wen]

Solve comments alignment problems on dc_link file

Signed-off-by: Melissa Wen 
---
 drivers/gpu/drm/amd/display/dc/core/dc_link.c | 25 +++
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index 67cfff1586e9..f580b533db5f 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -64,11 +64,11 @@
 enum {
PEAK_FACTOR_X1000 = 1006,
/*
-   * Some receivers fail to train on first try and are good
-   * on subsequent tries. 2 retries should be plenty. If we
-   * don't have a successful training then we don't expect to
-   * ever get one.
-   */
+* Some receivers fail to train on first try and are good
+* on subsequent tries. 2 retries should be plenty. If we
+* don't have a successful training then we don't expect to
+* ever get one.
+*/
LINK_TRAINING_MAX_VERIFY_RETRY = 2
 };
 
@@ -270,7 +270,8 @@ static enum ddc_transaction_type get_ddc_transaction_type(
case SIGNAL_TYPE_DISPLAY_PORT_MST:
/* MST does not use I2COverAux, but there is the
 * SPECIAL use case for "immediate dwnstrm device
-* access" (EPR#370830). */
+* access" (EPR#370830).
+*/
transaction_type = DDC_TRANSACTION_TYPE_I2C_OVER_AUX;
break;
 
@@ -369,7 +370,8 @@ bool dc_link_is_dp_sink_present(struct dc_link *link)
/* Open GPIO and set it to I2C mode */
/* Note: this GpioMode_Input will be converted
 * to GpioConfigType_I2cAuxDualMode in GPIO component,
-* which indicates we need additional delay */
+* which indicates we need additional delay
+*/
 
if (GPIO_RESULT_OK != dal_ddc_open(
ddc, GPIO_MODE_INPUT, GPIO_DDC_CONFIG_TYPE_MODE_I2C)) {
@@ -414,14 +416,16 @@ static enum signal_type link_detect_sink(
link->link_enc->id, link->link_id);
 
/* Internal digital encoder will detect only dongles
-* that require digital signal */
+* that require digital signal
+*/
 
/* Detection mechanism is different
 * for different native connectors.
 * LVDS connector supports only LVDS signal;
 * PCIE is a bus slot, the actual connector needs to be detected first;
 * eDP connector supports only eDP signal;
-* HDMI should check straps for audio */
+* HDMI should check straps for audio
+*/
 
/* PCIE detects the actual connector on add-on board */
 
@@ -432,7 +436,8 @@ static enum signal_type link_detect_sink(
switch (link->link_id.id) {
case CONNECTOR_ID_HDMI_TYPE_A: {
/* check audio support:
-* if native HDMI is not supported, switch to DVI */
+* if native HDMI is not supported, switch to DVI
+*/
struct audio_support *aud_support = 
>dc->res_pool->audio_support;
 
if (!aud_support->hdmi_audio_native)
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/4] drm/amd/display: more code cleanup in the dc_link file

[Melissa Wen]

These patches address many code style issues on dc_link for readability
and cleaning up warnings. Change suggested by checkpatch.pl.
Some issues remain and need some minor code refactoring for proper handling. 

Melissa Wen (4):
  drm/amd/display: cleanup codestyle type BLOCK_COMMENT_STYLE on dc_link
  drm/amd/display: codestyle cleanup on dc_link file until detect_dp
func
  drm/amd/display: code cleanup on dc_link from is_same_edid to
get_ddc_line
  drm/amd/display: code cleanup of dc_link file on func
dc_link_construct

 drivers/gpu/drm/amd/display/dc/core/dc_link.c | 358 +-
 1 file changed, 176 insertions(+), 182 deletions(-)

-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/4] drm/amd/display: codestyle cleanup on dc_link file until detect_dp func

[Melissa Wen]

Removes codestyle issues on the file dc_link until detect_dp func as
suggested by checkpatch.pl.

Types covered:

CHECK: Please don't use multiple blank lines
CHECK: Comparison to NULL could be written
ERROR: space required before the open parenthesis '('
CHECK: Alignment should match open parenthesis
CHECK: Lines should not end with a '('
WARNING: please, no space before tabs
WARNING: Comparisons should place the constant on the right side of the test
WARNING: braces {} are not necessary for single statement blocks
CHECK: Please don't use multiple blank lines

Signed-off-by: Melissa Wen 
---
 drivers/gpu/drm/amd/display/dc/core/dc_link.c | 109 --
 1 file changed, 49 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index f580b533db5f..0b303d17e543 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -49,7 +49,6 @@
 
 #define DC_LOGGER_INIT(logger)
 
-
 #define LINK_INFO(...) \
DC_LOG_HW_HOTPLUG(  \
__VA_ARGS__)
@@ -79,7 +78,7 @@ static void dc_link_destruct(struct dc_link *link)
 {
int i;
 
-   if (link->hpd_gpio != NULL) {
+   if (link->hpd_gpio) {
dal_gpio_destroy_irq(>hpd_gpio);
link->hpd_gpio = NULL;
}
@@ -87,7 +86,7 @@ static void dc_link_destruct(struct dc_link *link)
if (link->ddc)
dal_ddc_service_destroy(>ddc);
 
-   if(link->link_enc)
+   if (link->link_enc)
link->link_enc->funcs->destroy(>link_enc);
 
if (link->local_sink)
@@ -98,8 +97,8 @@ static void dc_link_destruct(struct dc_link *link)
 }
 
 struct gpio *get_hpd_gpio(struct dc_bios *dcb,
-   struct graphics_object_id link_id,
-   struct gpio_service *gpio_service)
+ struct graphics_object_id link_id,
+ struct gpio_service *gpio_service)
 {
enum bp_result bp_result;
struct graphics_object_hpd_info hpd_info;
@@ -116,10 +115,9 @@ struct gpio *get_hpd_gpio(struct dc_bios *dcb,
return NULL;
}
 
-   return dal_gpio_service_create_irq(
-   gpio_service,
-   pin_info.offset,
-   pin_info.mask);
+   return dal_gpio_service_create_irq(gpio_service,
+  pin_info.offset,
+  pin_info.mask);
 }
 
 /*
@@ -134,13 +132,10 @@ struct gpio *get_hpd_gpio(struct dc_bios *dcb,
  *  @return
  * true on success, false otherwise
  */
-static bool program_hpd_filter(
-   const struct dc_link *link)
+static bool program_hpd_filter(const struct dc_link *link)
 {
bool result = false;
-
struct gpio *hpd;
-
int delay_on_connect_in_ms = 0;
int delay_on_disconnect_in_ms = 0;
 
@@ -159,10 +154,10 @@ static bool program_hpd_filter(
case SIGNAL_TYPE_DISPLAY_PORT_MST:
/* Program hpd filter to allow DP signal to settle */
/* 500: not able to detect MST <-> SST switch as HPD is low for
-*  only 100ms on DELL U2413
-* 0:   some passive dongle still show aux mode instead of i2c
-* 20-50:not enough to hide bouncing HPD with passive dongle.
-*  also see intermittent i2c read issues.
+* only 100ms on DELL U2413
+* 0: some passive dongle still show aux mode instead of i2c
+* 20-50: not enough to hide bouncing HPD with passive dongle.
+* also see intermittent i2c read issues.
 */
delay_on_connect_in_ms = 80;
delay_on_disconnect_in_ms = 0;
@@ -175,7 +170,8 @@ static bool program_hpd_filter(
}
 
/* Obtain HPD handle */
-   hpd = get_hpd_gpio(link->ctx->dc_bios, link->link_id, 
link->ctx->gpio_service);
+   hpd = get_hpd_gpio(link->ctx->dc_bios, link->link_id,
+  link->ctx->gpio_service);
 
if (!hpd)
return result;
@@ -226,8 +222,9 @@ bool dc_link_detect_sink(struct dc_link *link, enum 
dc_connection_type *type)
}
 
/* todo: may need to lock gpio access */
-   hpd_pin = get_hpd_gpio(link->ctx->dc_bios, link->link_id, 
link->ctx->gpio_service);
-   if (hpd_pin == NULL)
+   hpd_pin = get_hpd_gpio(link->ctx->dc_bios, link->link_id,
+  link->ctx->gpio_service);
+   if (!hpd_pin)
goto hpd_gpio_failure;
 
dal_gpio_open(hpd_pin, GPIO_MODE_INTERRUPT);
@@ -248,8 +245,7 @@ bool dc_link_detect_sink(struct dc_link *link, enum 
dc_connection_type *type)
return false;
 }
 
-static enum ddc_transaction_type get_ddc_transaction_type(
-   

[PATCH 3/4] drm/amd/display: code cleanup on dc_link from is_same_edid to get_ddc_line

[Melissa Wen]

Removes codestyle issues on the file dc_link between is_same_edid and
get_ddc_line as suggested by checkpatch.pl.

Types covered:

CHECK: Blank lines aren't necessary after an open brace '{'
CHECK: Blank lines aren't necessary before a close brace '}'
WARNING: braces {} are not necessary for single statement blocks
CHECK: Comparison to NULL could be written
CHECK: Lines should not end with a '('
CHECK: Alignment should match open parenthesis
CHECK: Using comparison to false is error prone
CHECK: Using comparison to true is error prone
WARNING: Avoid multiple line dereference - prefer 
'link->dpcd_caps.sink_count.bits.SINK_COUNT'
CHECK: Unnecessary parentheses around
WARNING: Missing a blank line after declarations

Signed-off-by: Melissa Wen 
---
 drivers/gpu/drm/amd/display/dc/core/dc_link.c | 130 +-
 1 file changed, 62 insertions(+), 68 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index 0b303d17e543..b5b202bd9d7c 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -677,12 +677,12 @@ static bool is_same_edid(struct dc_edid *old_edid, struct 
dc_edid *new_edid)
if (new_edid->length == 0)
return false;
 
-   return (memcmp(old_edid->raw_edid, new_edid->raw_edid, 
new_edid->length) == 0);
+   return (memcmp(old_edid->raw_edid,
+  new_edid->raw_edid, new_edid->length) == 0);
 }
 
 static bool wait_for_alt_mode(struct dc_link *link)
 {
-
/**
 * something is terribly wrong if time out is > 200ms. (5Hz)
 * 500 microseconds * 400 tries us 200 ms
@@ -697,7 +697,7 @@ static bool wait_for_alt_mode(struct dc_link *link)
 
DC_LOGGER_INIT(link->ctx->logger);
 
-   if (link->link_enc->funcs->is_in_alt_mode == NULL)
+   if (!link->link_enc->funcs->is_in_alt_mode)
return true;
 
is_in_alt_mode = link->link_enc->funcs->is_in_alt_mode(link->link_enc);
@@ -712,21 +712,21 @@ static bool wait_for_alt_mode(struct dc_link *link)
udelay(sleep_time_in_microseconds);
/* ask the link if alt mode is enabled, if so return ok */
if (link->link_enc->funcs->is_in_alt_mode(link->link_enc)) {
-
finish_timestamp = dm_get_timestamp(link->ctx);
-   time_taken_in_ns = dm_get_elapse_time_in_ns(
-   link->ctx, finish_timestamp, enter_timestamp);
+   time_taken_in_ns =
+   dm_get_elapse_time_in_ns(link->ctx,
+finish_timestamp,
+enter_timestamp);
DC_LOG_WARNING("Alt mode entered finished after %llu 
ms\n",
   div_u64(time_taken_in_ns, 100));
return true;
}
-
}
finish_timestamp = dm_get_timestamp(link->ctx);
time_taken_in_ns = dm_get_elapse_time_in_ns(link->ctx, finish_timestamp,
enter_timestamp);
DC_LOG_WARNING("Alt mode has timed out after %llu ms\n",
-   div_u64(time_taken_in_ns, 100));
+  div_u64(time_taken_in_ns, 100));
return false;
 }
 
@@ -762,30 +762,30 @@ static bool dc_link_detect_helper(struct dc_link *link,
return false;
 
if ((link->connector_signal == SIGNAL_TYPE_LVDS ||
-   link->connector_signal == SIGNAL_TYPE_EDP) &&
-   link->local_sink) {
-
+link->connector_signal == SIGNAL_TYPE_EDP) &&
+   link->local_sink) {
// need to re-write OUI and brightness in resume case
if (link->connector_signal == SIGNAL_TYPE_EDP) {
dpcd_set_source_specific_data(link);
-   dc_link_set_default_brightness_aux(link); //TODO: use 
cached
+   dc_link_set_default_brightness_aux(link);
+   //TODO: use cached
}
 
return true;
}
 
-   if (false == dc_link_detect_sink(link, _connection_type)) {
+   if (!dc_link_detect_sink(link, _connection_type)) {
BREAK_TO_DEBUGGER();
return false;
}
 
prev_sink = link->local_sink;
-   if (prev_sink != NULL) {
+   if (prev_sink) {
dc_sink_retain(prev_sink);
memcpy(_dpcd_caps, >dpcd_caps, sizeof(struct 
dpcd_caps));
}
-   link_disconnect_sink(link);
 
+   link_disconnect_sink(link);
if (new_connection_type != dc_connection_none) {
  

[PATCH 4/4] drm/amd/display: code cleanup of dc_link file on func dc_link_construct

[Melissa Wen]

Removes codestyle issues in dc_link file, on dc_link_construct and
translate_encoder_to_transmitter as suggested by checkpatch.pl.

Types covered:

CHECK: Lines should not end with a '('
WARNING: Missing a blank line after declarations
CHECK: Alignment should match open parenthesis
CHECK: Comparison to NULL could be written
CHECK: Logical continuations should be on the previous line
CHECK: Blank lines aren't necessary after an open brace '{'

Signed-off-by: Melissa Wen 
---
 drivers/gpu/drm/amd/display/dc/core/dc_link.c | 94 ++-
 1 file changed, 50 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
index b5b202bd9d7c..a93997ff0419 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c
@@ -1098,13 +1098,13 @@ bool dc_link_get_hpd_state(struct dc_link *dc_link)
return state;
 }
 
-static enum hpd_source_id get_hpd_line(
-   struct dc_link *link)
+static enum hpd_source_id get_hpd_line(struct dc_link *link)
 {
struct gpio *hpd;
enum hpd_source_id hpd_id = HPD_SOURCEID_UNKNOWN;
 
-   hpd = get_hpd_gpio(link->ctx->dc_bios, link->link_id, 
link->ctx->gpio_service);
+   hpd = get_hpd_gpio(link->ctx->dc_bios, link->link_id,
+  link->ctx->gpio_service);
 
if (hpd) {
switch (dal_irq_get_source(hpd)) {
@@ -1179,8 +1179,7 @@ static enum channel_id get_ddc_line(struct dc_link *link)
return channel;
 }
 
-static enum transmitter translate_encoder_to_transmitter(
-   struct graphics_object_id encoder)
+static enum transmitter translate_encoder_to_transmitter(struct 
graphics_object_id encoder)
 {
switch (encoder.id) {
case ENCODER_ID_INTERNAL_UNIPHY:
@@ -1244,9 +1243,8 @@ static enum transmitter translate_encoder_to_transmitter(
}
 }
 
-static bool dc_link_construct(
-   struct dc_link *link,
-   const struct link_init_data *init_params)
+static bool dc_link_construct(struct dc_link *link,
+ const struct link_init_data *init_params)
 {
uint8_t i;
struct ddc_service_init_data ddc_service_init_data = { { 0 } };
@@ -1255,6 +1253,7 @@ static bool dc_link_construct(
struct integrated_info info = {{{ 0 }}};
struct dc_bios *bios = init_params->dc->ctx->dc_bios;
const struct dc_vbios_funcs *bp_funcs = bios->funcs;
+
DC_LOGGER_INIT(dc_ctx->logger);
 
link->irq_source_hpd = DC_IRQ_SOURCE_INVALID;
@@ -1266,23 +1265,27 @@ static bool dc_link_construct(
link->ctx = dc_ctx;
link->link_index = init_params->link_index;
 
-   memset(>preferred_training_settings, 0, sizeof(struct 
dc_link_training_overrides));
-   memset(>preferred_link_setting, 0, sizeof(struct 
dc_link_settings));
+   memset(>preferred_training_settings, 0,
+  sizeof(struct dc_link_training_overrides));
+   memset(>preferred_link_setting, 0,
+  sizeof(struct dc_link_settings));
 
-   link->link_id = bios->funcs->get_connector_id(bios, 
init_params->connector_index);
+   link->link_id =
+   bios->funcs->get_connector_id(bios, 
init_params->connector_index);
 
if (link->link_id.type != OBJECT_TYPE_CONNECTOR) {
dm_output_to_console("%s: Invalid Connector ObjectID from 
Adapter Service for connector index:%d! type %d expected %d\n",
-__func__, init_params->connector_index,
-link->link_id.type, OBJECT_TYPE_CONNECTOR);
+__func__, init_params->connector_index,
+link->link_id.type, OBJECT_TYPE_CONNECTOR);
goto create_fail;
}
 
if (link->dc->res_pool->funcs->link_init)
link->dc->res_pool->funcs->link_init(link);
 
-   link->hpd_gpio = get_hpd_gpio(link->ctx->dc_bios, link->link_id, 
link->ctx->gpio_service);
-   if (link->hpd_gpio != NULL) {
+   link->hpd_gpio = get_hpd_gpio(link->ctx->dc_bios, link->link_id,
+ link->ctx->gpio_service);
+   if (link->hpd_gpio) {
dal_gpio_open(link->hpd_gpio, GPIO_MODE_INTERRUPT);
dal_gpio_unlock_pin(link->hpd_gpio);
link->irq_source_hpd = dal_irq_get_source(link->hpd_gpio);
@@ -1302,9 +1305,9 @@ static bool dc_link_construct(
link->connector_signal = SIGNAL_TYPE_DVI_DUAL_LINK;
break;
case CONNECTOR_ID_DISPLAY_PORT:
-   link->connector_signal =SIGNAL_TYPE_DISPLAY_PORT;
+   link->connector_signal = SIGNAL_TYPE_DISPLAY_PORT;
 
-

[PATCH] drm/vkms: use bitfield op to get xrgb on compute crc

[Melissa Wen]

The previous memset operation was not correctly setting zero on the
alpha channel to compute the crc, and as a result, the
pipe-A-cursor-alpha-transparent subtest of the IGT test kms_cursor_crc
was crashing. To avoid errors of misinterpretation related to
endianness, this solution uses a bitfield operation to extract the RGB
values from each pixel and ignores the alpha channel as expected.

Signed-off-by: Melissa Wen 
---
 drivers/gpu/drm/vkms/vkms_composer.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
b/drivers/gpu/drm/vkms/vkms_composer.c
index 4af2f19480f4..8c1c005bb717 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0+
 
 #include 
+#include 
 
 #include 
 #include 
@@ -9,6 +10,8 @@
 
 #include "vkms_drv.h"
 
+#define XRGB_MSK GENMASK(23, 0)
+
 /**
  * compute_crc - Compute CRC value on output frame
  *
@@ -26,6 +29,7 @@ static uint32_t compute_crc(void *vaddr_out, struct 
vkms_composer *composer)
int h_src = drm_rect_height(>src) >> 16;
int w_src = drm_rect_width(>src) >> 16;
u32 crc = 0;
+   u32 *pixel;
 
for (i = y_src; i < y_src + h_src; ++i) {
for (j = x_src; j < x_src + w_src; ++j) {
@@ -33,7 +37,8 @@ static uint32_t compute_crc(void *vaddr_out, struct 
vkms_composer *composer)
 + (i * composer->pitch)
 + (j * composer->cpp);
/* XRGB format ignores Alpha channel */
-   memset(vaddr_out + src_offset + 24, 0,  8);
+   pixel = vaddr_out + src_offset;
+   *pixel = FIELD_GET(XRGB_MSK, *(u32 *)pixel);
crc = crc32_le(crc, vaddr_out + src_offset,
   sizeof(u32));
}
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/vkms: enable cursor by default

[Melissa Wen]

This patch proposes a change in the behavior of the cursor to enable it as
soon as the vkms module is added. Enabling the cursor by default appears
to be an expected and more friendly behavior, especially when running IGT
tests.

Signed-off-by: Melissa Wen 
---
 drivers/gpu/drm/vkms/vkms_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index 860de052e820..6e6feecf7f20 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -34,7 +34,7 @@
 
 static struct vkms_device *vkms_device;
 
-bool enable_cursor;
+bool enable_cursor = true;
 module_param_named(enable_cursor, enable_cursor, bool, 0444);
 MODULE_PARM_DESC(enable_cursor, "Enable/Disable cursor support");
 
-- 
2.25.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vkms: Use devm_drm_dev_alloc

[Melissa Wen]

On 09/09, Daniel Vetter wrote:
> This means we also need to slightly restructure the exit code, so that
> final cleanup of the drm_device is triggered by unregistering the
> platform device. Note that devres is both clean up when the driver is
> unbound (not the case for vkms, we don't bind), and also when unregistering
> the device (very much the case for vkms). Therefore we can rely on devres
> even though vkms isn't a proper platform device driver.
> 
> This also somewhat untangles the load code, since the drm and platform device
> setup are no longer interleaved, but two distinct steps.
> 
> v2: use devres_open/release_group so we can use devm without real
> hacks in the driver core or having to create an entire fake bus for
> testing drivers. Might want to extract this into helpers eventually,
> maybe as a mock_drm_dev_alloc or test_drm_dev_alloc.
> 
> v3: Only deref vkms_device after checking it (Melissa)
Thanks :)
> 
> Cc: Melissa Wen 
> Signed-off-by: Daniel Vetter 
> Cc: Rodrigo Siqueira 
> Cc: Haneen Mohammed 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/vkms/vkms_drv.c | 56 -
>  1 file changed, 28 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index 83dd5567de8b..cb0b6230c22c 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -61,9 +61,6 @@ static void vkms_release(struct drm_device *dev)
>  {
>   struct vkms_device *vkms = container_of(dev, struct vkms_device, drm);
>  
> - platform_device_unregister(vkms->platform);
> - drm_atomic_helper_shutdown(>drm);
> - drm_mode_config_cleanup(>drm);
>   destroy_workqueue(vkms->output.composer_workq);
>  }
>  
> @@ -144,30 +141,31 @@ static int vkms_modeset_init(struct vkms_device 
> *vkmsdev)
>  static int __init vkms_init(void)
>  {
>   int ret;
> + struct platform_device *pdev;
>  
> - vkms_device = kzalloc(sizeof(*vkms_device), GFP_KERNEL);
> - if (!vkms_device)
> - return -ENOMEM;
> + pdev = platform_device_register_simple(DRIVER_NAME, -1, NULL, 0);
> + if (IS_ERR(pdev))
> + return PTR_ERR(pdev);
>  
> - vkms_device->platform =
> - platform_device_register_simple(DRIVER_NAME, -1, NULL, 0);
> - if (IS_ERR(vkms_device->platform)) {
> - ret = PTR_ERR(vkms_device->platform);
> - goto out_free;
> + if (!devres_open_group(>dev, NULL, GFP_KERNEL)) {
> + ret = -ENOMEM;
> + goto out_unregister;
>   }
>  
> - ret = drm_dev_init(_device->drm, _driver,
> -_device->platform->dev);
> - if (ret)
> - goto out_unregister;
> - drmm_add_final_kfree(_device->drm, vkms_device);
> + vkms_device = devm_drm_dev_alloc(>dev, _driver,
> +  struct vkms_device, drm);
> + if (IS_ERR(vkms_device)) {
> + ret = PTR_ERR(vkms_device);
> + goto out_devres;
> + }
> + vkms_device->platform = pdev;
>  
>   ret = dma_coerce_mask_and_coherent(vkms_device->drm.dev,
>  DMA_BIT_MASK(64));
>  
>   if (ret) {
>   DRM_ERROR("Could not initialize DMA support\n");
> - goto out_put;
> + goto out_devres;
>   }
>  
>   vkms_device->drm.irq_enabled = true;
> @@ -175,39 +173,41 @@ static int __init vkms_init(void)
>   ret = drm_vblank_init(_device->drm, 1);
>   if (ret) {
>   DRM_ERROR("Failed to vblank\n");
> - goto out_put;
> + goto out_devres;
>   }
>  
>   ret = vkms_modeset_init(vkms_device);
>   if (ret)
> - goto out_put;
> + goto out_devres;
>  
>   ret = drm_dev_register(_device->drm, 0);
>   if (ret)
> - goto out_put;
> + goto out_devres;
>  
>   return 0;
>  
> -out_put:
> - drm_dev_put(_device->drm);
> - platform_device_unregister(vkms_device->platform);
> - return ret;
> +out_devres:
> + devres_release_group(>dev, NULL);
>  out_unregister:
> - platform_device_unregister(vkms_device->platform);
> -out_free:
> - kfree(vkms_device);
> + platform_device_unregister(pdev);
>   return ret;
>  }
>  
>  static void __exit vkms_exit(void)
>  {
> + struct platform_device *pdev;
> +
>   if (!vkms_device) {
>   DRM_INFO("vkms_device is NULL.\n");
>   return;

Re: [PATCH 04/24] drm/vgem: Use devm_drm_dev_alloc

[Melissa Wen]

Hi Daniel,

looks good to me, just a few things inline.

On 09/04, Daniel Vetter wrote:
> This means we also need to slightly restructure the exit code, so that
> final cleanup of the drm_device is triggered by unregistering the
> platform device. Note that devres is both clean up when the driver is
> unbound (not the case for vgem, we don't bind), and also when unregistering
> the device (very much the case for vgem). Therefore we can rely on devres
> even though vgem isn't a proper platform device driver.
> 
> This also somewhat untangles the load code, since the drm and platform device
> setup are no longer interleaved, but two distinct steps.
> 
> v2: use devres_open/release_group so we can use devm without real
> hacks in the driver core or having to create an entire fake bus for
> testing drivers. Might want to extract this into helpers eventually,
> maybe as a mock_drm_dev_alloc or test_drm_dev_alloc.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Daniel Vetter 
> Cc: Emil Velikov 
> Cc: Sean Paul 
> Cc: Chris Wilson 
> Cc: Sam Ravnborg 
> Cc: Rob Clark 
> ---
>  drivers/gpu/drm/vgem/vgem_drv.c | 55 ++---
>  1 file changed, 24 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index 313339bbff90..f95537627463 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -401,16 +401,8 @@ static int vgem_prime_mmap(struct drm_gem_object *obj,
>   return 0;
>  }
>  
> -static void vgem_release(struct drm_device *dev)
> -{
> - struct vgem_device *vgem = container_of(dev, typeof(*vgem), drm);
> -
> - platform_device_unregister(vgem->platform);
> -}
> -
>  static struct drm_driver vgem_driver = {
>   .driver_features= DRIVER_GEM | DRIVER_RENDER,
> - .release= vgem_release,
>   .open   = vgem_open,
>   .postclose  = vgem_postclose,
>   .gem_free_object_unlocked   = vgem_gem_free_object,
> @@ -442,48 +434,49 @@ static struct drm_driver vgem_driver = {
>  static int __init vgem_init(void)
>  {
>   int ret;
> + struct platform_device *pdev;
>  
> - vgem_device = kzalloc(sizeof(*vgem_device), GFP_KERNEL);
> - if (!vgem_device)
> - return -ENOMEM;
> + pdev = platform_device_register_simple("vgem", -1, NULL, 0);
> + if (IS_ERR(pdev))
> + return PTR_ERR(vgem_device->platform);
I caught this line right above.
It should be: return PTR_ERR (pdev), right?
>  
> - vgem_device->platform =
> - platform_device_register_simple("vgem", -1, NULL, 0);
> - if (IS_ERR(vgem_device->platform)) {
> - ret = PTR_ERR(vgem_device->platform);
> - goto out_free;
> + if (!devres_open_group(>dev, NULL, GFP_KERNEL)) {
> + ret = -ENOMEM;
> + goto out_unregister;
>   }
>  
> - dma_coerce_mask_and_coherent(_device->platform->dev,
> + dma_coerce_mask_and_coherent(>dev,
>DMA_BIT_MASK(64));
> - ret = drm_dev_init(_device->drm, _driver,
> -_device->platform->dev);
> - if (ret)
> - goto out_unregister;
> - drmm_add_final_kfree(_device->drm, vgem_device);
> +
> + vgem_device = devm_drm_dev_alloc(>dev, _driver,
> +  struct vgem_device, drm);
> + if (IS_ERR(vgem_device)) {
> + ret = PTR_ERR(vgem_device);
> + goto out_devres;
> + }
> + vgem_device->platform = pdev;
>  
>   /* Final step: expose the device/driver to userspace */
>   ret = drm_dev_register(_device->drm, 0);
>   if (ret)
> - goto out_put;
> + goto out_devres;
>  
>   return 0;
>  
> -out_put:
> - drm_dev_put(_device->drm);
> - platform_device_unregister(vgem_device->platform);
> - return ret;
> +out_devres:
> + devres_release_group(>dev, NULL);
>  out_unregister:
> - platform_device_unregister(vgem_device->platform);
> -out_free:
> - kfree(vgem_device);
> + platform_device_unregister(pdev);
>   return ret;
>  }
>  
>  static void __exit vgem_exit(void)
>  {
> +     struct platform_device *pdev = vgem_device->platform;
> +
Well, there has never been a check for a null vgem_device here before,
as in vkms. Should?
>   drm_dev_unregister(_device->drm);
> - drm_dev_put(_device->drm);
> + devres_release_group(>dev, NULL);
> + platform_device_unr

Re: [PATCH 04/24] drm/vgem: Use devm_drm_dev_alloc

[Melissa Wen]

On 09/09, Daniel Vetter wrote:
> On Wed, Sep 9, 2020 at 1:01 PM Melissa Wen  wrote:
> >
> > Hi Daniel,
> >
> > looks good to me, just a few things inline.
> >
> > On 09/04, Daniel Vetter wrote:
> > > This means we also need to slightly restructure the exit code, so that
> > > final cleanup of the drm_device is triggered by unregistering the
> > > platform device. Note that devres is both clean up when the driver is
> > > unbound (not the case for vgem, we don't bind), and also when 
> > > unregistering
> > > the device (very much the case for vgem). Therefore we can rely on devres
> > > even though vgem isn't a proper platform device driver.
> > >
> > > This also somewhat untangles the load code, since the drm and platform 
> > > device
> > > setup are no longer interleaved, but two distinct steps.
> > >
> > > v2: use devres_open/release_group so we can use devm without real
> > > hacks in the driver core or having to create an entire fake bus for
> > > testing drivers. Might want to extract this into helpers eventually,
> > > maybe as a mock_drm_dev_alloc or test_drm_dev_alloc.
> > >
> > > Signed-off-by: Daniel Vetter 
> > > Cc: Daniel Vetter 
> > > Cc: Emil Velikov 
> > > Cc: Sean Paul 
> > > Cc: Chris Wilson 
> > > Cc: Sam Ravnborg 
> > > Cc: Rob Clark 
> > > ---
> > >  drivers/gpu/drm/vgem/vgem_drv.c | 55 ++---
> > >  1 file changed, 24 insertions(+), 31 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c 
> > > b/drivers/gpu/drm/vgem/vgem_drv.c
> > > index 313339bbff90..f95537627463 100644
> > > --- a/drivers/gpu/drm/vgem/vgem_drv.c
> > > +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> > > @@ -401,16 +401,8 @@ static int vgem_prime_mmap(struct drm_gem_object 
> > > *obj,
> > >   return 0;
> > >  }
> > >
> > > -static void vgem_release(struct drm_device *dev)
> > > -{
> > > - struct vgem_device *vgem = container_of(dev, typeof(*vgem), drm);
> > > -
> > > - platform_device_unregister(vgem->platform);
> > > -}
> > > -
> > >  static struct drm_driver vgem_driver = {
> > >   .driver_features= DRIVER_GEM | DRIVER_RENDER,
> > > - .release= vgem_release,
> > >   .open   = vgem_open,
> > >   .postclose  = vgem_postclose,
> > >   .gem_free_object_unlocked   = vgem_gem_free_object,
> > > @@ -442,48 +434,49 @@ static struct drm_driver vgem_driver = {
> > >  static int __init vgem_init(void)
> > >  {
> > >   int ret;
> > > + struct platform_device *pdev;
> > >
> > > - vgem_device = kzalloc(sizeof(*vgem_device), GFP_KERNEL);
> > > - if (!vgem_device)
> > > - return -ENOMEM;
> > > + pdev = platform_device_register_simple("vgem", -1, NULL, 0);
> > > + if (IS_ERR(pdev))
> > > + return PTR_ERR(vgem_device->platform);
> > I caught this line right above.
> > It should be: return PTR_ERR (pdev), right?
> 
> Yes I will fix.
> 
> > > - vgem_device->platform =
> > > - platform_device_register_simple("vgem", -1, NULL, 0);
> > > - if (IS_ERR(vgem_device->platform)) {
> > > - ret = PTR_ERR(vgem_device->platform);
> > > - goto out_free;
> > > + if (!devres_open_group(>dev, NULL, GFP_KERNEL)) {
> > > + ret = -ENOMEM;
> > > + goto out_unregister;
> > >   }
> > >
> > > - dma_coerce_mask_and_coherent(_device->platform->dev,
> > > + dma_coerce_mask_and_coherent(>dev,
> > >DMA_BIT_MASK(64));
> > > - ret = drm_dev_init(_device->drm, _driver,
> > > -_device->platform->dev);
> > > - if (ret)
> > > - goto out_unregister;
> > > - drmm_add_final_kfree(_device->drm, vgem_device);
> > > +
> > > + vgem_device = devm_drm_dev_alloc(>dev, _driver,
> > > +  struct vgem_device, drm);
> > > + if (IS_ERR(vgem_device)) {
> > > + ret = PTR_ERR(vgem_device);
> > > + goto out_devres;
> > > + }
> > > + v

[PATCH] MAINTAINERS: add entry for VKMS

[Melissa Wen]

Add myself as maintainer of VKMS driver

Signed-off-by: Melissa Wen 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 01fb9ee6b951..d4277824a01c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5640,6 +5640,7 @@ F:drivers/gpu/drm/udl/
 
 DRM DRIVER FOR VIRTUAL KERNEL MODESETTING (VKMS)
 M: Rodrigo Siqueira 
+M: Melissa Wen 
 R: Haneen Mohammed 
 R: Daniel Vetter 
 L: dri-devel@lists.freedesktop.org
-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 2/3] drm/vkms: Compute CRC without change input data

[Melissa Wen]

On 08/30, Rodrigo Siqueira wrote:
> The compute_crc() function is responsible for calculating the
> framebuffer CRC value; due to the XRGB format, this function has to
> ignore the alpha channel during the CRC computation. Therefore,
> compute_crc() set zero to the alpha channel directly in the input
> framebuffer, which is not a problem since this function receives a copy
> of the original buffer. However, if we want to use this function in a
> context without a buffer copy, it will change the initial value. This
> patch makes compute_crc() calculate the CRC value without modifying the
> input framebuffer.
Hi Rodrigo,

This commit message no longer reflects the current state of crc
computation on vkms, since the alpha channel is no longer ignored (not
zeroed) there. I think the point here is to improve readability, which I
agree, is it? If so, update this msg.
> 
> Change in V5 (Melissa):
> - Rebase and drop bitmap for alpha
> Change in V4 (Emil):
> - Move bitmap_clear operation and comments to get_pixel function
> 
> Signed-off-by: Rodrigo Siqueira 
> ---
>  drivers/gpu/drm/vkms/vkms_composer.c | 34 ++--
>  1 file changed, 22 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index f67d1baf1942..c5b32fe5870f 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -9,31 +9,41 @@
>  
>  #include "vkms_drv.h"
>  
> +static u32 get_pixel_from_buffer(int x, int y, const u8 *buffer,
> +  const struct vkms_composer *composer)
> +{
> + u32 pixel;
> + int src_offset = composer->offset + (y * composer->pitch)
> +   + (x * composer->cpp);
> +
> + pixel = *(u32 *)[src_offset];
> +
> + return pixel;
> +}
> +
>  /**
>   * compute_crc - Compute CRC value on output frame
>   *
> - * @vaddr_out: address to final framebuffer
> + * @vaddr: address to final framebuffer
>   * @composer: framebuffer's metadata
>   *
>   * returns CRC value computed using crc32 on the visible portion of
>   * the final framebuffer at vaddr_out
>   */
> -static uint32_t compute_crc(void *vaddr_out, struct vkms_composer *composer)
> +static uint32_t compute_crc(const u8 *vaddr,
> + const struct vkms_composer *composer)
>  {
> - int i, j, src_offset;
> + int x, y;
> + u32 crc = 0, pixel = 0;
>   int x_src = composer->src.x1 >> 16;
>   int y_src = composer->src.y1 >> 16;
>   int h_src = drm_rect_height(>src) >> 16;
>   int w_src = drm_rect_width(>src) >> 16;
> - u32 crc = 0;
> -
> - for (i = y_src; i < y_src + h_src; ++i) {
> - for (j = x_src; j < x_src + w_src; ++j) {
> - src_offset = composer->offset
> -  + (i * composer->pitch)
> -  + (j * composer->cpp);
> - crc = crc32_le(crc, vaddr_out + src_offset,
> -sizeof(u32));
> +
> + for (y = y_src; y < y_src + h_src; ++y) {
> + for (x = x_src; x < x_src + w_src; ++x) {
> + pixel = get_pixel_from_buffer(x, y, vaddr, composer);
> + crc = crc32_le(crc, (void *), sizeof(u32));
>   }
>   }
>  
> -- 
> 2.28.0
> 
Please, update the commit msg.
The code improvement look good to me. So:

Reviewed-by: Melissa Wen 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 1/3] drm/vkms: Decouple crc operations from composer

[Melissa Wen]

Hi,

On 08/30, Rodrigo Siqueira wrote:
> In the vkms_composer.c, some of the functions related to CRC and compose
> have interdependence between each other. This patch reworks some
> functions inside vkms_composer to make crc and composer computation
> decoupled.
> 
> This patch is preparation work for making vkms able to support new
> features.
> 
> Tested-by: Melissa Wen 
> Signed-off-by: Rodrigo Siqueira 
> ---
>  drivers/gpu/drm/vkms/vkms_composer.c | 49 
>  1 file changed, 29 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index eaecc5a6c5db..f67d1baf1942 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -131,35 +131,31 @@ static void compose_cursor(struct vkms_composer 
> *cursor_composer,
> primary_composer, cursor_composer);
>  }
>  
> -static uint32_t _vkms_get_crc(struct vkms_composer *primary_composer,
> -   struct vkms_composer *cursor_composer)
> +static int compose_planes(void **vaddr_out,
> +   struct vkms_composer *primary_composer,
> +   struct vkms_composer *cursor_composer)
>  {
>   struct drm_framebuffer *fb = _composer->fb;
>   struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0);
>   struct vkms_gem_object *vkms_obj = drm_gem_to_vkms_gem(gem_obj);
> - void *vaddr_out = kzalloc(vkms_obj->gem.size, GFP_KERNEL);
> - u32 crc = 0;
>  
> - if (!vaddr_out) {
> - DRM_ERROR("Failed to allocate memory for output frame.");
> - return 0;
> + if (!*vaddr_out) {
> + *vaddr_out = kzalloc(vkms_obj->gem.size, GFP_KERNEL);
> + if (!*vaddr_out) {
> + DRM_ERROR("Cannot allocate memory for output frame.");
> + return -ENOMEM;
> + }
>   }
>  
> - if (WARN_ON(!vkms_obj->vaddr)) {
> - kfree(vaddr_out);
> - return crc;
> - }
> + if (WARN_ON(!vkms_obj->vaddr))
> + return -EINVAL;
>  
> - memcpy(vaddr_out, vkms_obj->vaddr, vkms_obj->gem.size);
> + memcpy(*vaddr_out, vkms_obj->vaddr, vkms_obj->gem.size);
>  
>   if (cursor_composer)
> - compose_cursor(cursor_composer, primary_composer, vaddr_out);
> + compose_cursor(cursor_composer, primary_composer, *vaddr_out);
>  
> - crc = compute_crc(vaddr_out, primary_composer);
> -
> - kfree(vaddr_out);
> -
> - return crc;
> + return 0;
>  }
>  
>  /**
> @@ -180,9 +176,11 @@ void vkms_composer_worker(struct work_struct *work)
>   struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
>   struct vkms_composer *primary_composer = NULL;
>   struct vkms_composer *cursor_composer = NULL;
> + void *vaddr_out = NULL;
>   u32 crc32 = 0;
>   u64 frame_start, frame_end;
>   bool crc_pending;
> + int ret;
>  
>   spin_lock_irq(>composer_lock);
>   frame_start = crtc_state->frame_start;
> @@ -206,14 +204,25 @@ void vkms_composer_worker(struct work_struct *work)
>   if (crtc_state->num_active_planes == 2)
>   cursor_composer = crtc_state->active_planes[1]->composer;
>  
> - if (primary_composer)
> - crc32 = _vkms_get_crc(primary_composer, cursor_composer);
> + if (!primary_composer)
> + return;
> +
> + ret = compose_planes(_out, primary_composer, cursor_composer);
> + if (ret) {
> + if (ret == -EINVAL)
> + kfree(vaddr_out);
> + return;
> + }
> +
> + crc32 = compute_crc(vaddr_out, primary_composer);
>  
>   /*
>* The worker can fall behind the vblank hrtimer, make sure we catch up.
>*/
>   while (frame_start <= frame_end)
>   drm_crtc_add_crc_entry(crtc, true, frame_start++, );
> +
> + kfree(vaddr_out);
>  }
>  
>  static const char * const pipe_crc_sources[] = {"auto"};
> -- 
> 2.28.0
>

I noticed two improvements: for a pre-existing op (alloc), but that
could affect the logic of the next patch; and another one (kfree -
release vaddr_out earlier, when it’s no longer needed) that you also
adjusted in the next one and is harmless here.

So, looking as a preparation for the writeback patch, I tested and
consider that this rework keeps operations stable here.

Reviewed-by: Melissa Wen 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 05/24] drm/vkms: Use devm_drm_dev_alloc

[Melissa Wen]

Hi Daniel,

Thanks for this work.

This change works smoothly to me. However, there is a check in the vkms_exit
that doesn't look very good. Please, see inline comment.

On 09/04, Daniel Vetter wrote:
> This means we also need to slightly restructure the exit code, so that
> final cleanup of the drm_device is triggered by unregistering the
> platform device. Note that devres is both clean up when the driver is
> unbound (not the case for vkms, we don't bind), and also when unregistering
> the device (very much the case for vkms). Therefore we can rely on devres
> even though vkms isn't a proper platform device driver.
> 
> This also somewhat untangles the load code, since the drm and platform device
> setup are no longer interleaved, but two distinct steps.
> 
> v2: use devres_open/release_group so we can use devm without real
> hacks in the driver core or having to create an entire fake bus for
> testing drivers. Might want to extract this into helpers eventually,
> maybe as a mock_drm_dev_alloc or test_drm_dev_alloc.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Rodrigo Siqueira 
> Cc: Haneen Mohammed 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/vkms/vkms_drv.c | 54 -
>  1 file changed, 26 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index 83dd5567de8b..0d2c6dcf73c3 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -61,9 +61,6 @@ static void vkms_release(struct drm_device *dev)
>  {
>   struct vkms_device *vkms = container_of(dev, struct vkms_device, drm);
>  
> - platform_device_unregister(vkms->platform);
> - drm_atomic_helper_shutdown(>drm);
> - drm_mode_config_cleanup(>drm);
>   destroy_workqueue(vkms->output.composer_workq);
>  }
>  
> @@ -144,30 +141,31 @@ static int vkms_modeset_init(struct vkms_device 
> *vkmsdev)
>  static int __init vkms_init(void)
>  {
>   int ret;
> + struct platform_device *pdev;
>  
> - vkms_device = kzalloc(sizeof(*vkms_device), GFP_KERNEL);
> - if (!vkms_device)
> - return -ENOMEM;
> + pdev = platform_device_register_simple(DRIVER_NAME, -1, NULL, 0);
> + if (IS_ERR(pdev))
> + return PTR_ERR(pdev);
>  
> - vkms_device->platform =
> - platform_device_register_simple(DRIVER_NAME, -1, NULL, 0);
> - if (IS_ERR(vkms_device->platform)) {
> - ret = PTR_ERR(vkms_device->platform);
> - goto out_free;
> + if (!devres_open_group(>dev, NULL, GFP_KERNEL)) {
> + ret = -ENOMEM;
> + goto out_unregister;
>   }
>  
> - ret = drm_dev_init(_device->drm, _driver,
> -_device->platform->dev);
> - if (ret)
> - goto out_unregister;
> - drmm_add_final_kfree(_device->drm, vkms_device);
> + vkms_device = devm_drm_dev_alloc(>dev, _driver,
> +  struct vkms_device, drm);
> + if (IS_ERR(vkms_device)) {
> + ret = PTR_ERR(vkms_device);
> + goto out_devres;
> + }
> + vkms_device->platform = pdev;
>  
>   ret = dma_coerce_mask_and_coherent(vkms_device->drm.dev,
>  DMA_BIT_MASK(64));
>  
>   if (ret) {
>   DRM_ERROR("Could not initialize DMA support\n");
> - goto out_put;
> + goto out_devres;
>   }
>  
>   vkms_device->drm.irq_enabled = true;
> @@ -175,39 +173,39 @@ static int __init vkms_init(void)
>   ret = drm_vblank_init(_device->drm, 1);
>   if (ret) {
>   DRM_ERROR("Failed to vblank\n");
> - goto out_put;
> + goto out_devres;
>   }
>  
>   ret = vkms_modeset_init(vkms_device);
>   if (ret)
> - goto out_put;
> + goto out_devres;
>  
>   ret = drm_dev_register(_device->drm, 0);
>   if (ret)
> - goto out_put;
> + goto out_devres;
>  
>   return 0;
>  
> -out_put:
> - drm_dev_put(_device->drm);
> - platform_device_unregister(vkms_device->platform);
> - return ret;
> +out_devres:
> + devres_release_group(>dev, NULL);
>  out_unregister:
> - platform_device_unregister(vkms_device->platform);
> -out_free:
> - kfree(vkms_device);
> + platform_device_unregister(pdev);
>   return ret;
>  }
>  
>  static void __exit vkms_exit(void)
>  {
> + struct platform_device *pdev = vkms_device->platform;
> +
>   if (!vkms_device) {
>   DRM_INFO("vkms_device is NULL.\n");
>   return;
>   }

I think it would be better to check vkms_device before assigning
vkms_device->platform to the pdev above. I don't know if the compiler
handles this, but doing the validation first seems more clear.

>  
>   drm_dev_unregister(_device->drm);
> - drm_dev_put(_device->drm);
> + drm_atomic_helper_shutdown(_device->drm);
> + devres_release_group(>dev, 

[PATCH] drm/vkms: update todo

[Melissa Wen]

Drop issues already resolved in vkms:

- CRC API Improvements to [1] add igt test to check extreme alpha values
  and [2] alpha blending;
- [3] prime buffer sharing;
- [4] writeback support;

On the other hand, we also found or thought about other improvements since
the last update of this document:

- better support for IGT tests
- improvements to writeback support
- syzbot report

Finally, we reorder items by the assumed complexity.

[1] https://patchwork.freedesktop.org/series/55944/
[2] https://patchwork.freedesktop.org/series/80823/
[3] https://patchwork.freedesktop.org/series/63212/
[4] https://patchwork.freedesktop.org/series/81177/

Cc: Daniel Vetter 
Cc: Rodrigo Siqueira 
Cc: Haneen Mohammed 

Signed-off-by: Melissa Wen 
---
 Documentation/gpu/vkms.rst | 99 --
 1 file changed, 53 insertions(+), 46 deletions(-)

diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
index 61586fc861bb..82a01bb4104c 100644
--- a/Documentation/gpu/vkms.rst
+++ b/Documentation/gpu/vkms.rst
@@ -10,36 +10,24 @@
 TODO
 
 
-CRC API Improvements
-
-
-- Optimize CRC computation ``compute_crc()`` and plane blending ``blend()``
-
-- Use the alpha value to blend vaddr_src with vaddr_dst instead of
-  overwriting it in ``blend()``.
-
-- Add igt test to check cleared alpha value for XRGB plane format.
-
-- Add igt test to check extreme alpha values i.e. fully opaque and fully
-  transparent (intermediate values are affected by hw-specific rounding modes).
-
-Runtime Configuration
--
-
-We want to be able to reconfigure vkms instance without having to reload the
-module. Use/Test-cases:
-
-- Hotplug/hotremove connectors on the fly (to be able to test DP MST handling 
of
-  compositors).
+If you want to do any of the items listed below, please share your interest
+with one of the VKMS maintainers.
 
-- Configure planes/crtcs/connectors (we'd need some code to have more than 1 of
-  them first).
+IGT better support
+--
 
-- Change output configuration: Plug/unplug screens, change EDID, allow changing
-  the refresh rate.
+- Investigate: (1) test cases on kms_plane that are failing due to timeout on
+  capturing CRC; (2) when running kms_flip test cases in sequence, some
+  successful individual test cases are failing randomly.
 
-The currently proposed solution is to expose vkms configuration through
-configfs.  All existing module options should be supported through configfs 
too.
+- VKMS already has support for vblanks simulated via hrtimers, which can be
+  tested with kms_flip test; in some way, we can say that VKMS already mimics
+  the real hardware vblank. However, we also have virtual hardware that does
+  not support vblank interrupt and completes page_flip events right away; in
+  this case, compositor developers may end up creating a busy loop on virtual
+  hardware. It would be useful to support Virtual Hardware behavior in VKMS
+  because this can help compositor developers to test their features in
+  multiple scenarios.
 
 Add Plane Features
 --
@@ -55,34 +43,50 @@ There's lots of plane features we could add support for:
 - Additional buffer formats, especially YUV formats for video like NV12.
   Low/high bpp RGB formats would also be interesting.
 
-- Async updates (currently only possible on cursor plane using the legacy 
cursor
-  api).
+- Async updates (currently only possible on cursor plane using the legacy
+  cursor api).
+
+For all of these, we also want to review the igt test coverage and make sure
+all relevant igt testcases work on vkms.
+
+Prime Buffer Sharing
+
 
-For all of these, we also want to review the igt test coverage and make sure 
all
-relevant igt testcases work on vkms.
+- Syzbot report:
+  WARNING in vkms_gem_free_object: https://lkml.org/lkml/2019/10/13/220
+
+Runtime Configuration
+-
+
+We want to be able to reconfigure vkms instance without having to reload the
+module. Use/Test-cases:
+
+- Hotplug/hotremove connectors on the fly (to be able to test DP MST handling
+  of compositors).
+
+- Configure planes/crtcs/connectors (we'd need some code to have more than 1 of
+  them first).
+
+- Change output configuration: Plug/unplug screens, change EDID, allow changing
+  the refresh rate.
+
+The currently proposed solution is to expose vkms configuration through
+configfs.  All existing module options should be supported through configfs
+too.
 
 Writeback support
 -
 
-Currently vkms only computes a CRC for each frame. Once we have additional 
plane
-features, we could write back the entire composited frame, and expose it as:
+- The writeback and CRC capture operations share the use of composer_enabled
+  boolean to ensure vblanks. Probably, when these operations work together,
+  composer_enabled needs to refcounting the composer state to proper work.
 
-- Writeback connector. This is useful for testing

Re: [PATCH 2/3] drm/vkms: Switch to shmem helpers

[Melissa Wen]

Hi Daniel,

Thanks for this patch.

It took me a while to understand the update.
I run some tests and it looks good to me.

On 10/10, Daniel Vetter wrote:
> Inspired by a patch by Chris Wilson for vgem. Plus this gives us vmap
> at the gem bo level, which we need for generic fbdev emulation.
> 
> Luckily shmem also tracks ->vaddr, so we just need to adjust the code
> all over a bit to make this fit.
> 
> Also wire up handle_to_fd, dunno why that was missing.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Chris Wilson 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Rodrigo Siqueira 
> Cc: Melissa Wen 
> Cc: Haneen Mohammed 
> ---
>  drivers/gpu/drm/Kconfig   |   1 +
>  drivers/gpu/drm/vkms/Makefile |   1 -
>  drivers/gpu/drm/vkms/vkms_composer.c  |  17 +-
>  drivers/gpu/drm/vkms/vkms_drv.c   |  19 +-
>  drivers/gpu/drm/vkms/vkms_drv.h   |  26 ---
>  drivers/gpu/drm/vkms/vkms_gem.c   | 261 --
>  drivers/gpu/drm/vkms/vkms_plane.c |  13 +-
>  drivers/gpu/drm/vkms/vkms_writeback.c |  17 +-
>  8 files changed, 32 insertions(+), 323 deletions(-)
>  delete mode 100644 drivers/gpu/drm/vkms/vkms_gem.c
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 9efb82caaa87..b796c118fc3b 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -287,6 +287,7 @@ config DRM_VKMS
>   tristate "Virtual KMS (EXPERIMENTAL)"
>   depends on DRM
>   select DRM_KMS_HELPER
> + select DRM_GEM_SHMEM_HELPER
>   select CRC32
>   default n
>   help
> diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
> index 333d3cead0e3..72f779cbfedd 100644
> --- a/drivers/gpu/drm/vkms/Makefile
> +++ b/drivers/gpu/drm/vkms/Makefile
> @@ -4,7 +4,6 @@ vkms-y := \
>   vkms_plane.o \
>   vkms_output.o \
>   vkms_crtc.o \
> - vkms_gem.o \
>   vkms_composer.o \
>   vkms_writeback.o
>  
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index 33c031f27c2c..66c6842d70db 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -5,6 +5,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "vkms_drv.h"
> @@ -129,15 +130,15 @@ static void compose_cursor(struct vkms_composer 
> *cursor_composer,
>  void *vaddr_out)
>  {
>   struct drm_gem_object *cursor_obj;
> - struct vkms_gem_object *cursor_vkms_obj;
> + struct drm_gem_shmem_object *cursor_shmem_obj;
>  
>   cursor_obj = drm_gem_fb_get_obj(_composer->fb, 0);
> - cursor_vkms_obj = drm_gem_to_vkms_gem(cursor_obj);
> + cursor_shmem_obj = to_drm_gem_shmem_obj(cursor_obj);
>  
> - if (WARN_ON(!cursor_vkms_obj->vaddr))
> + if (WARN_ON(!cursor_shmem_obj->vaddr))
>   return;
>  
> - blend(vaddr_out, cursor_vkms_obj->vaddr,
> + blend(vaddr_out, cursor_shmem_obj->vaddr,
> primary_composer, cursor_composer);
>  }
>  
> @@ -147,20 +148,20 @@ static int compose_planes(void **vaddr_out,
>  {
>   struct drm_framebuffer *fb = _composer->fb;
>   struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0);
> - struct vkms_gem_object *vkms_obj = drm_gem_to_vkms_gem(gem_obj);
> + struct drm_gem_shmem_object *shmem_obj = to_drm_gem_shmem_obj(gem_obj);
>  
>   if (!*vaddr_out) {
> - *vaddr_out = kzalloc(vkms_obj->gem.size, GFP_KERNEL);
> + *vaddr_out = kzalloc(shmem_obj->base.size, GFP_KERNEL);
>   if (!*vaddr_out) {
>   DRM_ERROR("Cannot allocate memory for output frame.");
>   return -ENOMEM;
>   }
>   }
>  
> - if (WARN_ON(!vkms_obj->vaddr))
> + if (WARN_ON(!shmem_obj->vaddr))
>   return -EINVAL;
>  
> - memcpy(*vaddr_out, vkms_obj->vaddr, vkms_obj->gem.size);
> + memcpy(*vaddr_out, shmem_obj->vaddr, shmem_obj->base.size);
>  
>   if (cursor_composer)
>   compose_cursor(cursor_composer, primary_composer, *vaddr_out);
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index eb4007443706..6221e5040264 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "vkms_drv.h"
> @@ -39,17 +40,7 @@ bool enable_cursor = true;
&

Re: [PATCH 1/3] drm/vkms: Set preferred depth correctly

[Melissa Wen]

On 10/10, Daniel Vetter wrote:
> The only thing we support is xrgb.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Rodrigo Siqueira 
> Cc: Melissa Wen 
> Cc: Haneen Mohammed 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/vkms/vkms_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index 726801ab44d4..eb4007443706 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -124,7 +124,7 @@ static int vkms_modeset_init(struct vkms_device *vkmsdev)
>   dev->mode_config.max_height = YRES_MAX;
>   dev->mode_config.cursor_width = 512;
>   dev->mode_config.cursor_height = 512;
> - dev->mode_config.preferred_depth = 24;
> + dev->mode_config.preferred_depth = 32;
nice catch!

>   dev->mode_config.helper_private = _mode_config_helpers;
>  
>       return vkms_output_init(vkmsdev, 0);
> -- 
> 2.28.0
>
Thanks, 

Reviewed-by: Melissa Wen 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/vkms: Set preferred depth correctly

[Melissa Wen]

On 10/15, Daniel Vetter wrote:
> On Mon, Oct 12, 2020 at 09:59:22AM -0300, Melissa Wen wrote:
> > On 10/10, Daniel Vetter wrote:
> > > The only thing we support is xrgb.
> > > 
> > > Signed-off-by: Daniel Vetter 
> > > Cc: Rodrigo Siqueira 
> > > Cc: Melissa Wen 
> > > Cc: Haneen Mohammed 
> > > Cc: Daniel Vetter 
> > > ---
> > >  drivers/gpu/drm/vkms/vkms_drv.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c 
> > > b/drivers/gpu/drm/vkms/vkms_drv.c
> > > index 726801ab44d4..eb4007443706 100644
> > > --- a/drivers/gpu/drm/vkms/vkms_drv.c
> > > +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> > > @@ -124,7 +124,7 @@ static int vkms_modeset_init(struct vkms_device 
> > > *vkmsdev)
> > >   dev->mode_config.max_height = YRES_MAX;
> > >   dev->mode_config.cursor_width = 512;
> > >   dev->mode_config.cursor_height = 512;
> > > - dev->mode_config.preferred_depth = 24;
> > > + dev->mode_config.preferred_depth = 32;
> > nice catch!
> > 
> > >   dev->mode_config.helper_private = _mode_config_helpers;
> > >  
> > >   return vkms_output_init(vkmsdev, 0);
> > > -- 
> > > 2.28.0
> > >
> > Thanks, 
> > 
> > Reviewed-by: Melissa Wen 
> 
> I merged the first 2 patches of this series, but noticed that you didn't
> reply with a r-b tag on the 3rd patch. Is that intentional or just
> oversight?
Hi Daniel,

Initially, it was intentional because I was following the feedback and
still wanted to check it out better, then I forgot to come back to
comment.

My fault, but it's done now.

Thanks for the touch,

Melissa

> 
> Thanks, Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] drm/vkms: fbdev emulation support

[Melissa Wen]

Hi,

Thanks for this improvement.

I could see that it increased the IGT test coverage, including now the
fbdev test cases. 

On 10/10, Daniel Vetter wrote:
> Hooray for generic fbdev support, making this a oneliner. We just
> needed to fix preferred_depth fixed and the vmap support added first.

I consider that including in the msg that, with this patch, both fbdev
test cases [info and mmap] are passing would be interesting for future
debugs.

> 
> Signed-off-by: Daniel Vetter 
> Cc: Rodrigo Siqueira 
> Cc: Melissa Wen 
> Cc: Haneen Mohammed 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/vkms/vkms_drv.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index 6221e5040264..cc09e2df5cb1 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -169,6 +169,8 @@ static int __init vkms_init(void)
>   if (ret)
>   goto out_devres;
>  
> + drm_fbdev_generic_setup(_device->drm, 0);
> +
>   return 0;
>  
>  out_devres:
> -- 
> 2.28.0
>

Looks good to me,

Reviewed-by: Melissa Wen 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/vkms: Set preferred depth correctly

[Melissa Wen]

On 10/16, Daniel Vetter wrote:
> On Fri, Oct 16, 2020 at 12:38 PM Simon Ser  wrote:
> >
> > > The only thing we support is xrgb.
> > >
> > > Signed-off-by: Daniel Vetter 
> > > Cc: Rodrigo Siqueira 
> > > Cc: Melissa Wen 
> > > Cc: Haneen Mohammed 
> > > Cc: Daniel Vetter 
> > > ---
> > >  drivers/gpu/drm/vkms/vkms_drv.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c 
> > > b/drivers/gpu/drm/vkms/vkms_drv.c
> > > index 726801ab44d4..eb4007443706 100644
> > > --- a/drivers/gpu/drm/vkms/vkms_drv.c
> > > +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> > > @@ -124,7 +124,7 @@ static int vkms_modeset_init(struct vkms_device 
> > > *vkmsdev)
> > >   dev->mode_config.max_height = YRES_MAX;
> > >   dev->mode_config.cursor_width = 512;
> > >   dev->mode_config.cursor_height = 512;
> > > - dev->mode_config.preferred_depth = 24;
> > > + dev->mode_config.preferred_depth = 32;
> >
> > Are you sure xrgb's depth is 32 and not 24? Looking at drmdb [1], *all*
> > drivers set it to 24.
> 
> Uh there's a problem I think. Depth should indeed stay at 24, the
> problem is that fb helpers directly take that to be the bpp parameter,
> which is a different thing. And if you look at how most drivers set up
> that, they pick 32.
> 
> I guess I need to revert this here, and unconfuse the fb helpers about
> depth vs bpp.

Hi guys,

Perhaps it deserves to be pointed out: the documentation says
"preferred_depth: preferred RBG(sic) pixel depth, used by fb helpers",
and looking to fb helpers, preferred_depth is only used by
generic_setup, as bits by pixel (if I didn't miss something there).

In fact, the alpha channel is not used for final display (perhaps in the
future); however, I saw another driver with a change similar to this
here and, possibly like me, following the same misunderstanding.

Melissa
> 
> Maybe best would be to just switch over to preferred drm_fourcc format
> code, or maybe just pick this up from the first format the primary
> plane supports.
> 
> This is all getting slightly tricky and a lot more work :-/
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/vkms: Set preferred depth correctly

[Melissa Wen]

On 10/16, Daniel Vetter wrote:
> On Fri, Oct 16, 2020 at 7:02 PM Melissa Wen  wrote:
> >
> > On 10/16, Daniel Vetter wrote:
> > > On Fri, Oct 16, 2020 at 12:38 PM Simon Ser  wrote:
> > > >
> > > > > The only thing we support is xrgb.
> > > > >
> > > > > Signed-off-by: Daniel Vetter 
> > > > > Cc: Rodrigo Siqueira 
> > > > > Cc: Melissa Wen 
> > > > > Cc: Haneen Mohammed 
> > > > > Cc: Daniel Vetter 
> > > > > ---
> > > > >  drivers/gpu/drm/vkms/vkms_drv.c | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c 
> > > > > b/drivers/gpu/drm/vkms/vkms_drv.c
> > > > > index 726801ab44d4..eb4007443706 100644
> > > > > --- a/drivers/gpu/drm/vkms/vkms_drv.c
> > > > > +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> > > > > @@ -124,7 +124,7 @@ static int vkms_modeset_init(struct vkms_device 
> > > > > *vkmsdev)
> > > > >   dev->mode_config.max_height = YRES_MAX;
> > > > >   dev->mode_config.cursor_width = 512;
> > > > >   dev->mode_config.cursor_height = 512;
> > > > > - dev->mode_config.preferred_depth = 24;
> > > > > + dev->mode_config.preferred_depth = 32;
> > > >
> > > > Are you sure xrgb's depth is 32 and not 24? Looking at drmdb [1], 
> > > > *all*
> > > > drivers set it to 24.
> > >
> > > Uh there's a problem I think. Depth should indeed stay at 24, the
> > > problem is that fb helpers directly take that to be the bpp parameter,
> > > which is a different thing. And if you look at how most drivers set up
> > > that, they pick 32.
> > >
> > > I guess I need to revert this here, and unconfuse the fb helpers about
> > > depth vs bpp.
> >
> > Hi guys,
> >
> > Perhaps it deserves to be pointed out: the documentation says
> > "preferred_depth: preferred RBG(sic) pixel depth, used by fb helpers",
> > and looking to fb helpers, preferred_depth is only used by
> > generic_setup, as bits by pixel (if I didn't miss something there).
> >
> > In fact, the alpha channel is not used for final display (perhaps in the
> > future); however, I saw another driver with a change similar to this
> > here and, possibly like me, following the same misunderstanding.
> 
> Yeah the problem is that preferred_depth is depth, and that means 24
> bit for XRGB. But bpp as used by fb helpers would be 32 bit for
> XRGB.
> 
> I think the real fix here is to switch this entire mess over to using
> drm_fourcc codes directly, at least for atomic drivers. Which nowadays
> are most. Interim I'm not sure whether we should revert my patch (it
> breaks fbdev) or switch preferred_depth to 0, which means we get the
> default every, and that means both fbdev helpers and userspace will
> pick XRGB.

hmm... but why not keep preferred_depth = 24 and pass 32 as the
preferred_bpp parameter of fbdev_generic_setup?

> -Daniel
> 
> > Melissa
> > >
> > > Maybe best would be to just switch over to preferred drm_fourcc format
> > > code, or maybe just pick this up from the first format the primary
> > > plane supports.
> > >
> > > This is all getting slightly tricky and a lot more work :-/
> > > -Daniel
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
> 
> 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/vkms: update todo

[Melissa Wen]

Drop issues already resolved in vkms:

- CRC API Improvements to [1] add igt test to check extreme alpha values
  and [2] alpha blending;
- [3] prime buffer sharing;
- [4] writeback support;

On the other hand, we also found or thought about other improvements since
the last update of this document:

- better support for IGT tests
- improvements to writeback support
- syzbot report

Finally, we reorder items by the assumed complexity.

[1] https://patchwork.freedesktop.org/series/55944/
[2] https://patchwork.freedesktop.org/series/80823/
[3] https://patchwork.freedesktop.org/series/63212/
[4] https://patchwork.freedesktop.org/series/81177/

v2:
- Link to syzbot dashboard

Cc: Daniel Vetter 
Cc: Rodrigo Siqueira 
Cc: Haneen Mohammed 

Signed-off-by: Melissa Wen 
Acked-by: Daniel Vetter 
---
 Documentation/gpu/vkms.rst | 99 --
 1 file changed, 53 insertions(+), 46 deletions(-)

diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
index 61586fc861bb..50b30dea0ba8 100644
--- a/Documentation/gpu/vkms.rst
+++ b/Documentation/gpu/vkms.rst
@@ -10,36 +10,24 @@
 TODO
 
 
-CRC API Improvements
-
-
-- Optimize CRC computation ``compute_crc()`` and plane blending ``blend()``
-
-- Use the alpha value to blend vaddr_src with vaddr_dst instead of
-  overwriting it in ``blend()``.
-
-- Add igt test to check cleared alpha value for XRGB plane format.
-
-- Add igt test to check extreme alpha values i.e. fully opaque and fully
-  transparent (intermediate values are affected by hw-specific rounding modes).
-
-Runtime Configuration
--
-
-We want to be able to reconfigure vkms instance without having to reload the
-module. Use/Test-cases:
-
-- Hotplug/hotremove connectors on the fly (to be able to test DP MST handling 
of
-  compositors).
+If you want to do any of the items listed below, please share your interest
+with one of the VKMS maintainers.
 
-- Configure planes/crtcs/connectors (we'd need some code to have more than 1 of
-  them first).
+IGT better support
+--
 
-- Change output configuration: Plug/unplug screens, change EDID, allow changing
-  the refresh rate.
+- Investigate: (1) test cases on kms_plane that are failing due to timeout on
+  capturing CRC; (2) when running kms_flip test cases in sequence, some
+  successful individual test cases are failing randomly.
 
-The currently proposed solution is to expose vkms configuration through
-configfs.  All existing module options should be supported through configfs 
too.
+- VKMS already has support for vblanks simulated via hrtimers, which can be
+  tested with kms_flip test; in some way, we can say that VKMS already mimics
+  the real hardware vblank. However, we also have virtual hardware that does
+  not support vblank interrupt and completes page_flip events right away; in
+  this case, compositor developers may end up creating a busy loop on virtual
+  hardware. It would be useful to support Virtual Hardware behavior in VKMS
+  because this can help compositor developers to test their features in
+  multiple scenarios.
 
 Add Plane Features
 --
@@ -55,34 +43,50 @@ There's lots of plane features we could add support for:
 - Additional buffer formats, especially YUV formats for video like NV12.
   Low/high bpp RGB formats would also be interesting.
 
-- Async updates (currently only possible on cursor plane using the legacy 
cursor
-  api).
+- Async updates (currently only possible on cursor plane using the legacy
+  cursor api).
+
+For all of these, we also want to review the igt test coverage and make sure
+all relevant igt testcases work on vkms.
+
+Prime Buffer Sharing
+
 
-For all of these, we also want to review the igt test coverage and make sure 
all
-relevant igt testcases work on vkms.
+- Syzbot report - WARNING in vkms_gem_free_object:
+  https://syzkaller.appspot.com/bug?extid=e7ad70d406e74d8fc9d0
+
+Runtime Configuration
+-
+
+We want to be able to reconfigure vkms instance without having to reload the
+module. Use/Test-cases:
+
+- Hotplug/hotremove connectors on the fly (to be able to test DP MST handling
+  of compositors).
+
+- Configure planes/crtcs/connectors (we'd need some code to have more than 1 of
+  them first).
+
+- Change output configuration: Plug/unplug screens, change EDID, allow changing
+  the refresh rate.
+
+The currently proposed solution is to expose vkms configuration through
+configfs.  All existing module options should be supported through configfs
+too.
 
 Writeback support
 -
 
-Currently vkms only computes a CRC for each frame. Once we have additional 
plane
-features, we could write back the entire composited frame, and expose it as:
+- The writeback and CRC capture operations share the use of composer_enabled
+  boolean to ensure vblanks. Probably, when these operations work together,
+  composer_enabled needs to refcounting the composer

Re: [PATCH v5 3/3] drm/vkms: Add support for writeback

[Melissa Wen]

On 08/24, Rodrigo Siqueira wrote:
> This patch implements the necessary functions to add writeback support
> for vkms. This feature is useful for testing compositors if you don't
> have hardware with writeback support.
> 
> Change in V4 (Emil and Melissa):
> - Move signal completion above drm_crtc_add_crc_entry()
> - Make writeback always available
> - Use appropriate namespace
> - Drop fb check in vkms_wb_atomic_commit
> - Make vkms_set_composer visible for writeback code
> - Enable composer operation on prepare_job and disable it on cleanup_job
> 
> Change in V3 (Daniel):
> - If writeback is enabled, compose everything into the writeback buffer
> instead of CRC private buffer
> - Guarantees that the CRC will match exactly what we have in the
> writeback buffer.
> 
> Change in V2:
> - Rework signal completion (Brian)
> - Integrates writeback with active_planes (Daniel)
> - Compose cursor (Daniel)
> 
> Signed-off-by: Rodrigo Siqueira 
> ---
>  drivers/gpu/drm/vkms/Makefile |   9 +-
>  drivers/gpu/drm/vkms/vkms_composer.c  |  21 +++-
>  drivers/gpu/drm/vkms/vkms_drv.h   |  11 +-
>  drivers/gpu/drm/vkms/vkms_output.c|   4 +
>  drivers/gpu/drm/vkms/vkms_writeback.c | 143 ++
>  5 files changed, 181 insertions(+), 7 deletions(-)
>  create mode 100644 drivers/gpu/drm/vkms/vkms_writeback.c
> 
> diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
> index 0b767d7efa24..333d3cead0e3 100644
> --- a/drivers/gpu/drm/vkms/Makefile
> +++ b/drivers/gpu/drm/vkms/Makefile
> @@ -1,4 +1,11 @@
>  # SPDX-License-Identifier: GPL-2.0-only
> -vkms-y := vkms_drv.o vkms_plane.o vkms_output.o vkms_crtc.o vkms_gem.o 
> vkms_composer.o
> +vkms-y := \
> + vkms_drv.o \
> + vkms_plane.o \
> + vkms_output.o \
> + vkms_crtc.o \
> + vkms_gem.o \
> + vkms_composer.o \
> + vkms_writeback.o
>  
>  obj-$(CONFIG_DRM_VKMS) += vkms.o
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index 387b0690a64a..656085c4ebf3 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -163,16 +163,17 @@ void vkms_composer_worker(struct work_struct *work)
>   struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
>   struct vkms_composer *primary_composer = NULL;
>   struct vkms_composer *cursor_composer = NULL;
> + bool crc_pending, wb_pending;
>   void *vaddr_out = NULL;
>   u32 crc32 = 0;
>   u64 frame_start, frame_end;
> - bool crc_pending;
>   int ret;
>  
>   spin_lock_irq(>composer_lock);
>   frame_start = crtc_state->frame_start;
>   frame_end = crtc_state->frame_end;
>   crc_pending = crtc_state->crc_pending;
> + wb_pending = crtc_state->wb_pending;
>   crtc_state->frame_start = 0;
>   crtc_state->frame_end = 0;
>   crtc_state->crc_pending = false;
> @@ -194,22 +195,32 @@ void vkms_composer_worker(struct work_struct *work)
>   if (!primary_composer)
>   return;
>  
> + if (wb_pending)
> + vaddr_out = crtc_state->active_writeback;
> +
>   ret = compose_planes(_out, primary_composer, cursor_composer);
>   if (ret) {
> - if (ret == -EINVAL)
> + if (ret == -EINVAL && !wb_pending)
>   kfree(vaddr_out);
>   return;
>   }
>  
>   crc32 = compute_crc(vaddr_out, primary_composer);
>  
> + if (wb_pending) {
> + drm_writeback_signal_completion(>wb_connector, 0);
> + spin_lock_irq(>composer_lock);
> + crtc_state->wb_pending = false;
> + spin_unlock_irq(>composer_lock);
> + } else {
> + kfree(vaddr_out);
> + }
> +
>   /*
>* The worker can fall behind the vblank hrtimer, make sure we catch up.
>*/
>   while (frame_start <= frame_end)
>   drm_crtc_add_crc_entry(crtc, true, frame_start++, );
> -
> - kfree(vaddr_out);
>  }
>  
>  static const char * const pipe_crc_sources[] = {"auto"};
> @@ -252,7 +263,7 @@ int vkms_verify_crc_source(struct drm_crtc *crtc, const 
> char *src_name,
>   return 0;
>  }
>  
> -static void vkms_set_composer(struct vkms_output *out, bool enabled)
> +void vkms_set_composer(struct vkms_output *out, bool enabled)
>  {
>   bool old_enabled;
>  
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index f4036bb0b9a8..641d8bc52a3a 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -8,6 +8,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define XRES_MIN20
>  #define YRES_MIN20
> @@ -19,6 +20,7 @@
>  #define YRES_MAX  8192
>  
>  extern bool enable_cursor;
> +extern bool enable_writeback;
>  
>  struct vkms_composer {
>   struct drm_framebuffer fb;
> @@ -52,9 +54,11 @@ struct vkms_crtc_state {
>   int num_active_planes;
>   /* stack of active planes for crc computation, should 

Re: [PATCH v5 0/3] drm/vkms: Introduces writeback support

[Melissa Wen]

Hi Rodrigo,

Nice work!

I tested this on the kms_writeback set of subtests and works fine.

I have also checked it on the other IGT tests that I usually uses:
- kms_cursor_crc/cursor-alpha-transparent was affected by a small
  problem in the bitmap_clear of the get_pixel_from_buffer function,
  that I pointed out inline. Please, check it.
- kms_flip and kms_pipe_crc_basic works as expected (was not affected).

Best regards,

Melissa Wen

On 08/24, Rodrigo Siqueira wrote:
> This is the V5 version of a series that introduces the writeback support
> to VKMS. The first two patches of this series are a pre-work for the
> latest patch that adds the writeback connector, this patchset can be seen
> in two parts: 
> 
> * A pre-work that aims to make vkms composer operations a little bit more
>   generic; these patches try to centralize the vkms framebuffer operations.
> * The final patch enables the support for writeback in vkms.
> 
> In the previous review, Emil suggested multiple changes in the series. I
> tried to apply most of the recommendations except for some suggestions
> which I was not able to incorporate due to compilation issues, or other
> suggestions that may complicate this series review. I left some changes
> for future patches for keeping this patchset simple with the hope of
> landing this feature soon in order to support VKMS user's requirements.
> Emil, let me know if you want me to change any other thing.
> 
> It is important to highlight that from the previous series to the
> current version of this patchset we had some changes in the VKMS that
> made it unstable.  In particular, our previous writeback series stopped
> working properly due to changes in our commit tail.  Thanks to Melissa
> working in the instability issue and her latest fixes to VKMS, I finally
> could update writeback and make it work again. The main update in the
> latest patch is the use of vkms_set_composer when the writeback work
> starts (enable composer) and after the writeback end (disable composer).
> 
> Best Regard
> 
> Rodrigo Siqueira (3):
>   drm/vkms: Decouple crc operations from composer
>   drm/vkms: Compute CRC without change input data
>   drm/vkms: Add support for writeback
> 
>  drivers/gpu/drm/vkms/Makefile |   9 +-
>  drivers/gpu/drm/vkms/vkms_composer.c  | 102 +++---
>  drivers/gpu/drm/vkms/vkms_drv.h   |  11 +-
>  drivers/gpu/drm/vkms/vkms_output.c|   4 +
>  drivers/gpu/drm/vkms/vkms_writeback.c | 143 ++
>  5 files changed, 231 insertions(+), 38 deletions(-)
>  create mode 100644 drivers/gpu/drm/vkms/vkms_writeback.c
> 
> -- 
> 2.28.0
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 3/3] drm/vkms: Add support for writeback

[Melissa Wen]

On Tue, Aug 25, 2020 at 12:45 PM Melissa Wen  wrote:
>
> On 08/24, Rodrigo Siqueira wrote:
> > This patch implements the necessary functions to add writeback support
> > for vkms. This feature is useful for testing compositors if you don't
> > have hardware with writeback support.
> >
> > Change in V4 (Emil and Melissa):
> > - Move signal completion above drm_crtc_add_crc_entry()
> > - Make writeback always available
> > - Use appropriate namespace
> > - Drop fb check in vkms_wb_atomic_commit
> > - Make vkms_set_composer visible for writeback code
> > - Enable composer operation on prepare_job and disable it on cleanup_job
> >
> > Change in V3 (Daniel):
> > - If writeback is enabled, compose everything into the writeback buffer
> > instead of CRC private buffer
> > - Guarantees that the CRC will match exactly what we have in the
> > writeback buffer.
> >
> > Change in V2:
> > - Rework signal completion (Brian)
> > - Integrates writeback with active_planes (Daniel)
> > - Compose cursor (Daniel)
> >
> > Signed-off-by: Rodrigo Siqueira 
> > ---
> >  drivers/gpu/drm/vkms/Makefile |   9 +-
> >  drivers/gpu/drm/vkms/vkms_composer.c  |  21 +++-
> >  drivers/gpu/drm/vkms/vkms_drv.h   |  11 +-
> >  drivers/gpu/drm/vkms/vkms_output.c|   4 +
> >  drivers/gpu/drm/vkms/vkms_writeback.c | 143 ++
> >  5 files changed, 181 insertions(+), 7 deletions(-)
> >  create mode 100644 drivers/gpu/drm/vkms/vkms_writeback.c
> >
> > diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
> > index 0b767d7efa24..333d3cead0e3 100644
> > --- a/drivers/gpu/drm/vkms/Makefile
> > +++ b/drivers/gpu/drm/vkms/Makefile
> > @@ -1,4 +1,11 @@
> >  # SPDX-License-Identifier: GPL-2.0-only
> > -vkms-y := vkms_drv.o vkms_plane.o vkms_output.o vkms_crtc.o vkms_gem.o 
> > vkms_composer.o
> > +vkms-y := \
> > + vkms_drv.o \
> > + vkms_plane.o \
> > + vkms_output.o \
> > + vkms_crtc.o \
> > + vkms_gem.o \
> > + vkms_composer.o \
> > + vkms_writeback.o
> >
> >  obj-$(CONFIG_DRM_VKMS) += vkms.o
> > diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
> > b/drivers/gpu/drm/vkms/vkms_composer.c
> > index 387b0690a64a..656085c4ebf3 100644
> > --- a/drivers/gpu/drm/vkms/vkms_composer.c
> > +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> > @@ -163,16 +163,17 @@ void vkms_composer_worker(struct work_struct *work)
> >   struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
> >   struct vkms_composer *primary_composer = NULL;
> >   struct vkms_composer *cursor_composer = NULL;
> > + bool crc_pending, wb_pending;
> >   void *vaddr_out = NULL;
> >   u32 crc32 = 0;
> >   u64 frame_start, frame_end;
> > - bool crc_pending;
> >   int ret;
> >
> >   spin_lock_irq(>composer_lock);
> >   frame_start = crtc_state->frame_start;
> >   frame_end = crtc_state->frame_end;
> >   crc_pending = crtc_state->crc_pending;
> > + wb_pending = crtc_state->wb_pending;
> >   crtc_state->frame_start = 0;
> >   crtc_state->frame_end = 0;
> >   crtc_state->crc_pending = false;
> > @@ -194,22 +195,32 @@ void vkms_composer_worker(struct work_struct *work)
> >   if (!primary_composer)
> >   return;
> >
> > + if (wb_pending)
> > + vaddr_out = crtc_state->active_writeback;
> > +
> >   ret = compose_planes(_out, primary_composer, cursor_composer);
> >   if (ret) {
> > - if (ret == -EINVAL)
> > + if (ret == -EINVAL && !wb_pending)
> >   kfree(vaddr_out);
> >   return;
> >   }
> >
> >   crc32 = compute_crc(vaddr_out, primary_composer);
> >
> > + if (wb_pending) {
> > + drm_writeback_signal_completion(>wb_connector, 0);
> > + spin_lock_irq(>composer_lock);
> > + crtc_state->wb_pending = false;
> > + spin_unlock_irq(>composer_lock);
> > + } else {
> > + kfree(vaddr_out);
> > + }
> > +
> >   /*
> >* The worker can fall behind the vblank hrtimer, make sure we catch 
> > up.
> >*/
> >   while (frame_start <= frame_end)
> >   drm_crtc_add_crc_entry(crtc, true, frame_start++, );
> > -
> > - kfree(vaddr_out);
> >  }
> >
> &g

Re: [PATCH v5 2/3] drm/vkms: Compute CRC without change input data

[Melissa Wen]

On 08/24, Rodrigo Siqueira wrote:
> The compute_crc() function is responsible for calculating the
> framebuffer CRC value; due to the XRGB format, this function has to
> ignore the alpha channel during the CRC computation. Therefore,
> compute_crc() set zero to the alpha channel directly in the input
> framebuffer, which is not a problem since this function receives a copy
> of the original buffer. However, if we want to use this function in a
> context without a buffer copy, it will change the initial value. This
> patch makes compute_crc() calculate the CRC value without modifying the
> input framebuffer.
> 
> Change in V4 (Emil):
> - Move bitmap_clear operation and comments to get_pixel function
> 
> Signed-off-by: Rodrigo Siqueira 
> ---
>  drivers/gpu/drm/vkms/vkms_composer.c | 38 ++--
>  1 file changed, 24 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index 4d8bc04bb6ee..387b0690a64a 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -9,33 +9,43 @@
>  
>  #include "vkms_drv.h"
>  
> +static u32 get_pixel_from_buffer(int x, int y, const u8 *buffer,
> +  const struct vkms_composer *composer)
> +{
> + u32 pixel;
> + int src_offset = composer->offset + (y * composer->pitch)
> +   + (x * composer->cpp);
> +
> + pixel = *(u32 *)[src_offset];
> + /* XRGB format ignores Alpha channel */
> + bitmap_clear((void *), 0, 8);

I noticed a small problem in this bitmap_clear as I recently sent a
patch changing it.  The starting point for zeroing the alpha is not 0,
but 24. As in the removed line below:
-   bitmap_clear(vaddr_out + src_offset, 24, 8);

It affects the kms_cursor_crc/cursor-alpha-transparent subtest.

> +
> + return pixel;
> +}
> +
>  /**
>   * compute_crc - Compute CRC value on output frame
>   *
> - * @vaddr_out: address to final framebuffer
> + * @vaddr: address to final framebuffer
>   * @composer: framebuffer's metadata
>   *
>   * returns CRC value computed using crc32 on the visible portion of
>   * the final framebuffer at vaddr_out
>   */
> -static uint32_t compute_crc(void *vaddr_out, struct vkms_composer *composer)
> +static uint32_t compute_crc(const u8 *vaddr,
> + const struct vkms_composer *composer)
>  {
> - int i, j, src_offset;
> + int x, y;
> + u32 crc = 0, pixel = 0;
>   int x_src = composer->src.x1 >> 16;
>   int y_src = composer->src.y1 >> 16;
>   int h_src = drm_rect_height(>src) >> 16;
>   int w_src = drm_rect_width(>src) >> 16;
> - u32 crc = 0;
> -
> - for (i = y_src; i < y_src + h_src; ++i) {
> - for (j = x_src; j < x_src + w_src; ++j) {
> - src_offset = composer->offset
> -  + (i * composer->pitch)
> -  + (j * composer->cpp);
> - /* XRGB format ignores Alpha channel */
> - bitmap_clear(vaddr_out + src_offset, 24, 8);
> - crc = crc32_le(crc, vaddr_out + src_offset,
> -sizeof(u32));
> +
> + for (y = y_src; y < y_src + h_src; ++y) {
> + for (x = x_src; x < x_src + w_src; ++x) {
> + pixel = get_pixel_from_buffer(x, y, vaddr, composer);
> + crc = crc32_le(crc, (void *), sizeof(u32));
>   }
>   }
>  
> -- 
> 2.28.0
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 1/3] drm/vkms: Decouple crc operations from composer

[Melissa Wen]

On Mon, Aug 24, 2020 at 11:31 PM Rodrigo Siqueira
 wrote:
>
> In the vkms_composer.c, some of the functions related to CRC and compose
> have interdependence between each other. This patch reworks some
> functions inside vkms_composer to make crc and composer computation
> decoupled.
>
> This patch is preparation work for making vkms able to support new
> features.
>
> Signed-off-by: Rodrigo Siqueira 
> ---
>  drivers/gpu/drm/vkms/vkms_composer.c | 49 
>  1 file changed, 29 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index 4f3b07a32b60..4d8bc04bb6ee 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -108,35 +108,31 @@ static void compose_cursor(struct vkms_composer 
> *cursor_composer,
>   primary_composer, cursor_composer);
>  }
>
> -static uint32_t _vkms_get_crc(struct vkms_composer *primary_composer,
> - struct vkms_composer *cursor_composer)
> +static int compose_planes(void **vaddr_out,
> + struct vkms_composer *primary_composer,
> + struct vkms_composer *cursor_composer)
>  {
> struct drm_framebuffer *fb = _composer->fb;
> struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0);
> struct vkms_gem_object *vkms_obj = drm_gem_to_vkms_gem(gem_obj);
> -   void *vaddr_out = kzalloc(vkms_obj->gem.size, GFP_KERNEL);
> -   u32 crc = 0;
>
> -   if (!vaddr_out) {
> -   DRM_ERROR("Failed to allocate memory for output frame.");
> -   return 0;
> +   if (!*vaddr_out) {
> +   *vaddr_out = kzalloc(vkms_obj->gem.size, GFP_KERNEL);
> +   if (!*vaddr_out) {
> +   DRM_ERROR("Cannot allocate memory for output frame.");
> +   return -ENOMEM;
> +   }
> }
>
> -   if (WARN_ON(!vkms_obj->vaddr)) {
> -   kfree(vaddr_out);
> -   return crc;
> -   }
> +   if (WARN_ON(!vkms_obj->vaddr))
> +   return -EINVAL;
>
> -   memcpy(vaddr_out, vkms_obj->vaddr, vkms_obj->gem.size);
> +   memcpy(*vaddr_out, vkms_obj->vaddr, vkms_obj->gem.size);
>
> if (cursor_composer)
> -   compose_cursor(cursor_composer, primary_composer, vaddr_out);
> +   compose_cursor(cursor_composer, primary_composer, *vaddr_out);
>
> -   crc = compute_crc(vaddr_out, primary_composer);
> -
> -   kfree(vaddr_out);
> -
> -   return crc;
> +   return 0;
>  }
>
>  /**
> @@ -157,9 +153,11 @@ void vkms_composer_worker(struct work_struct *work)
> struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
> struct vkms_composer *primary_composer = NULL;
> struct vkms_composer *cursor_composer = NULL;
> +   void *vaddr_out = NULL;
> u32 crc32 = 0;
> u64 frame_start, frame_end;
> bool crc_pending;
> +   int ret;
>
> spin_lock_irq(>composer_lock);
> frame_start = crtc_state->frame_start;
> @@ -183,14 +181,25 @@ void vkms_composer_worker(struct work_struct *work)
> if (crtc_state->num_active_planes == 2)
> cursor_composer = crtc_state->active_planes[1]->composer;
>
> -   if (primary_composer)
> -   crc32 = _vkms_get_crc(primary_composer, cursor_composer);
> +   if (!primary_composer)
> +   return;
> +
> +   ret = compose_planes(_out, primary_composer, cursor_composer);
> +   if (ret) {
> +   if (ret == -EINVAL)
> +   kfree(vaddr_out);
> +   return;
> +   }
> +
> +   crc32 = compute_crc(vaddr_out, primary_composer);
>
> /*
>  * The worker can fall behind the vblank hrtimer, make sure we catch 
> up.
>  */
> while (frame_start <= frame_end)
> drm_crtc_add_crc_entry(crtc, true, frame_start++, );
> +
> +   kfree(vaddr_out);
>  }
>
>  static const char * const pipe_crc_sources[] = {"auto"};
> --
> 2.28.0
>

Tested-by: Melissa Wen 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vkms: add alpha-premultiplied color blending

[Melissa Wen]

Hi Rodrigo,

Thanks for the review!
I just sent a v2 applying your suggestions.

Best Regards,

Melissa Wen

Melissa Wen


On Tue, Aug 25, 2020 at 12:04 AM Rodrigo Siqueira
 wrote:
>
> Hi Melissa,
>
> First of all, thanks a lot for your patch!
>
> Follows my inline comments.
>
> On 08/19, Melissa Wen wrote:
> > The current VKMS blend function ignores alpha channel and just overwrites
> > vaddr_src with vaddr_dst. This XRGB approach triggers a warning when
> > running the kms_cursor_crc/cursor-alpha-transparent test case. In IGT
> > tests, cairo_format_argb32 uses premultiplied alpha (according to
> > documentation), so this patch considers premultiplied alpha colors to
> > compose vaddr_src with vaddr_dst.
> >
> > This change removes the following cursor-alpha-transparent warning:
> > Suspicious CRC: All values are 0.
> >
> > Cc: Daniel Vetter 
> > Cc: Rodrigo Siqueira 
> > Cc: Haneen Mohammed 
> >
> > Signed-off-by: Melissa Wen 
> > ---
> >  drivers/gpu/drm/vkms/vkms_composer.c | 43 +---
> >  1 file changed, 33 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
> > b/drivers/gpu/drm/vkms/vkms_composer.c
> > index 4f3b07a32b60..6aac962d3e2e 100644
> > --- a/drivers/gpu/drm/vkms/vkms_composer.c
> > +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> > @@ -32,8 +32,6 @@ static uint32_t compute_crc(void *vaddr_out, struct 
> > vkms_composer *composer)
> >   src_offset = composer->offset
> >+ (i * composer->pitch)
> >+ (j * composer->cpp);
> > - /* XRGB format ignores Alpha channel */
> > - bitmap_clear(vaddr_out + src_offset, 24, 8);
> >   crc = crc32_le(crc, vaddr_out + src_offset,
> >  sizeof(u32));
> >   }
> > @@ -42,6 +40,32 @@ static uint32_t compute_crc(void *vaddr_out, struct 
> > vkms_composer *composer)
> >   return crc;
> >  }
> >
> > +u8 blend_channel(u8 c_src, u8 c_dst, u8 a_src)
>
> Use static here.
>
> Also, replace c_src to src, c_dst to dst, and a_src to alpha.
>
> > +{
> > + u32 pre_blend;
> > + u8 new_color;
> > +
> > + /* Premultiplied alpha blending - IGT + cairo context */
>
> You can drop the part that says "IGT + cairo context", this explanation
> better suit the commit message.
>
> > + pre_blend = (c_src * 255 + c_dst * (255 - a_src));
> > +
> > + /* Faster div by 255 */
> > + new_color = ((pre_blend + ((pre_blend + 257) >> 8)) >> 8);
> > +
> > + return new_color;
> > +}
> > +
> > +void alpha_blending(u8 *argb_src, u8 *argb_dst)
>
> Use static.
>
> Looks like that argb_src is a read-only variable, in this sense add
> const.
>
> > +{
> > + u8 a_src;
> > +
> > + a_src = argb_src[3];
>
> change a_src to alpha.
>
> > + argb_dst[0] = blend_channel(argb_src[0], argb_dst[0], a_src);
> > + argb_dst[1] = blend_channel(argb_src[1], argb_dst[1], a_src);
> > + argb_dst[2] = blend_channel(argb_src[2], argb_dst[2], a_src);
> > + /* Opaque primary */
> > + argb_dst[3] = 0xFF;
> > +}
> > +
> >  /**
> >   * blend - blend value at vaddr_src with value at vaddr_dst
> >   * @vaddr_dst: destination address
> > @@ -50,12 +74,9 @@ static uint32_t compute_crc(void *vaddr_out, struct 
> > vkms_composer *composer)
> >   * @src_composer: source framebuffer's metadata
> >   *
> >   * Blend value at vaddr_src with value at vaddr_dst.
> > - * Currently, this function write value of vaddr_src on value
> > - * at vaddr_dst using buffer's metadata to locate the new values
> > - * from vaddr_src and their destination at vaddr_dst.
> > - *
> > - * TODO: Use the alpha value to blend vaddr_src with vaddr_dst
> > - *instead of overwriting it.
> > + * Currently, this function considers premultiplied alpha for blending, as 
> > used
> > + * by Cairo. It uses buffer's metadata to locate the new composite values 
> > at
> > + * vaddr_dst.
> >   */
> >  static void blend(void *vaddr_dst, void *vaddr_src,
> > struct vkms_composer *dest_composer,
> > @@ -63,6 +84,7 @@ static void blend(void *vaddr_dst, void *vaddr_src,
> >  {
> >   int i, j, j_dst, i_dst;
> >   int offset_src, offset_dst;
> > + u8 *p_dst, *p_src;
>
> I suppose t

[PATCH v2] drm/vkms: add alpha-premultiplied color blending

[Melissa Wen]

The VKMS blend function was ignoring the alpha channel and just
overwriting vaddr_src with vaddr_dst. This XRGB approach triggers a
warning when running the kms_cursor_crc/cursor-alpha-transparent test
case. In IGT, cairo_format_argb32 uses premultiplied alpha (according to
documentation). Also current DRM assumption is that alpha is
premultiplied. Therefore, this patch considers premultiplied alpha
blending eq to compose vaddr_src with vaddr_dst.

This change removes the following cursor-alpha-transparent warning:
"Suspicious CRC: All values are 0."

--

v2:
- static for local functions
- const for the read-only variable argb_src
- replaces variable names
- drops unnecessary comment

--

Cc: Daniel Vetter 
Cc: Rodrigo Siqueira 
Cc: Haneen Mohammed 

Signed-off-by: Melissa Wen 
---
 drivers/gpu/drm/vkms/vkms_composer.c | 55 
 1 file changed, 39 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
b/drivers/gpu/drm/vkms/vkms_composer.c
index 4f3b07a32b60..eaecc5a6c5db 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -32,8 +32,6 @@ static uint32_t compute_crc(void *vaddr_out, struct 
vkms_composer *composer)
src_offset = composer->offset
 + (i * composer->pitch)
 + (j * composer->cpp);
-   /* XRGB format ignores Alpha channel */
-   bitmap_clear(vaddr_out + src_offset, 24, 8);
crc = crc32_le(crc, vaddr_out + src_offset,
   sizeof(u32));
}
@@ -42,27 +40,51 @@ static uint32_t compute_crc(void *vaddr_out, struct 
vkms_composer *composer)
return crc;
 }
 
+static u8 blend_channel(u8 src, u8 dst, u8 alpha)
+{
+   u32 pre_blend;
+   u8 new_color;
+
+   pre_blend = (src * 255 + dst * (255 - alpha));
+
+   /* Faster div by 255 */
+   new_color = ((pre_blend + ((pre_blend + 257) >> 8)) >> 8);
+
+   return new_color;
+}
+
+static void alpha_blending(const u8 *argb_src, u8 *argb_dst)
+{
+   u8 alpha;
+
+   alpha = argb_src[3];
+   argb_dst[0] = blend_channel(argb_src[0], argb_dst[0], alpha);
+   argb_dst[1] = blend_channel(argb_src[1], argb_dst[1], alpha);
+   argb_dst[2] = blend_channel(argb_src[2], argb_dst[2], alpha);
+   /* Opaque primary */
+   argb_dst[3] = 0xFF;
+}
+
 /**
  * blend - blend value at vaddr_src with value at vaddr_dst
  * @vaddr_dst: destination address
  * @vaddr_src: source address
- * @dest_composer: destination framebuffer's metadata
+ * @dst_composer: destination framebuffer's metadata
  * @src_composer: source framebuffer's metadata
  *
- * Blend value at vaddr_src with value at vaddr_dst.
- * Currently, this function write value of vaddr_src on value
- * at vaddr_dst using buffer's metadata to locate the new values
- * from vaddr_src and their destination at vaddr_dst.
- *
- * TODO: Use the alpha value to blend vaddr_src with vaddr_dst
- *  instead of overwriting it.
+ * Blend the vaddr_src value with the vaddr_dst value using the pre-multiplied
+ * alpha blending equation, since DRM currently assumes that the pixel color
+ * values have already been pre-multiplied with the alpha channel values. See
+ * more drm_plane_create_blend_mode_property(). This function uses buffer's
+ * metadata to locate the new composite values at vaddr_dst.
  */
 static void blend(void *vaddr_dst, void *vaddr_src,
- struct vkms_composer *dest_composer,
+ struct vkms_composer *dst_composer,
  struct vkms_composer *src_composer)
 {
int i, j, j_dst, i_dst;
int offset_src, offset_dst;
+   u8 *pixel_dst, *pixel_src;
 
int x_src = src_composer->src.x1 >> 16;
int y_src = src_composer->src.y1 >> 16;
@@ -77,15 +99,16 @@ static void blend(void *vaddr_dst, void *vaddr_src,
 
for (i = y_src, i_dst = y_dst; i < y_limit; ++i) {
for (j = x_src, j_dst = x_dst; j < x_limit; ++j) {
-   offset_dst = dest_composer->offset
-+ (i_dst * dest_composer->pitch)
-+ (j_dst++ * dest_composer->cpp);
+   offset_dst = dst_composer->offset
++ (i_dst * dst_composer->pitch)
++ (j_dst++ * dst_composer->cpp);
offset_src = src_composer->offset
 + (i * src_composer->pitch)
 + (j * src_composer->cpp);
 
-   memcpy(vaddr_dst + offset_dst,
-  vaddr_src + offset_src, sizeof(u32));
+   pixel_src = (u8 *)(vaddr_src + offset_src);
+   

[PATCH] drm/vkms: add alpha-premultiplied color blending

[Melissa Wen]

The current VKMS blend function ignores alpha channel and just overwrites
vaddr_src with vaddr_dst. This XRGB approach triggers a warning when
running the kms_cursor_crc/cursor-alpha-transparent test case. In IGT
tests, cairo_format_argb32 uses premultiplied alpha (according to
documentation), so this patch considers premultiplied alpha colors to
compose vaddr_src with vaddr_dst.

This change removes the following cursor-alpha-transparent warning:
Suspicious CRC: All values are 0.

Cc: Daniel Vetter 
Cc: Rodrigo Siqueira 
Cc: Haneen Mohammed 

Signed-off-by: Melissa Wen 
---
 drivers/gpu/drm/vkms/vkms_composer.c | 43 +---
 1 file changed, 33 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
b/drivers/gpu/drm/vkms/vkms_composer.c
index 4f3b07a32b60..6aac962d3e2e 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -32,8 +32,6 @@ static uint32_t compute_crc(void *vaddr_out, struct 
vkms_composer *composer)
src_offset = composer->offset
 + (i * composer->pitch)
 + (j * composer->cpp);
-   /* XRGB format ignores Alpha channel */
-   bitmap_clear(vaddr_out + src_offset, 24, 8);
crc = crc32_le(crc, vaddr_out + src_offset,
   sizeof(u32));
}
@@ -42,6 +40,32 @@ static uint32_t compute_crc(void *vaddr_out, struct 
vkms_composer *composer)
return crc;
 }
 
+u8 blend_channel(u8 c_src, u8 c_dst, u8 a_src)
+{
+   u32 pre_blend;
+   u8 new_color;
+
+   /* Premultiplied alpha blending - IGT + cairo context */
+   pre_blend = (c_src * 255 + c_dst * (255 - a_src));
+
+   /* Faster div by 255 */
+   new_color = ((pre_blend + ((pre_blend + 257) >> 8)) >> 8);
+
+   return new_color;
+}
+
+void alpha_blending(u8 *argb_src, u8 *argb_dst)
+{
+   u8 a_src;
+
+   a_src = argb_src[3];
+   argb_dst[0] = blend_channel(argb_src[0], argb_dst[0], a_src);
+   argb_dst[1] = blend_channel(argb_src[1], argb_dst[1], a_src);
+   argb_dst[2] = blend_channel(argb_src[2], argb_dst[2], a_src);
+   /* Opaque primary */
+   argb_dst[3] = 0xFF;
+}
+
 /**
  * blend - blend value at vaddr_src with value at vaddr_dst
  * @vaddr_dst: destination address
@@ -50,12 +74,9 @@ static uint32_t compute_crc(void *vaddr_out, struct 
vkms_composer *composer)
  * @src_composer: source framebuffer's metadata
  *
  * Blend value at vaddr_src with value at vaddr_dst.
- * Currently, this function write value of vaddr_src on value
- * at vaddr_dst using buffer's metadata to locate the new values
- * from vaddr_src and their destination at vaddr_dst.
- *
- * TODO: Use the alpha value to blend vaddr_src with vaddr_dst
- *  instead of overwriting it.
+ * Currently, this function considers premultiplied alpha for blending, as used
+ * by Cairo. It uses buffer's metadata to locate the new composite values at
+ * vaddr_dst.
  */
 static void blend(void *vaddr_dst, void *vaddr_src,
  struct vkms_composer *dest_composer,
@@ -63,6 +84,7 @@ static void blend(void *vaddr_dst, void *vaddr_src,
 {
int i, j, j_dst, i_dst;
int offset_src, offset_dst;
+   u8 *p_dst, *p_src;
 
int x_src = src_composer->src.x1 >> 16;
int y_src = src_composer->src.y1 >> 16;
@@ -84,8 +106,9 @@ static void blend(void *vaddr_dst, void *vaddr_src,
 + (i * src_composer->pitch)
 + (j * src_composer->cpp);
 
-   memcpy(vaddr_dst + offset_dst,
-  vaddr_src + offset_src, sizeof(u32));
+   p_src = (u8 *)(vaddr_src + offset_src);
+   p_dst = (u8 *)(vaddr_dst + offset_dst);
+   alpha_blending(p_src, p_dst);
}
i_dst++;
}
-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vkms: fix warning in vkms_get_vblank_timestamp

[Melissa Wen]

Hi Sidong,

Thanks for this patch.

The code looks good to me; however, I see some issues in the patch
format and commit message. Please, see inline comments.

On 08/25, Sidong Yang wrote:
> From: Sidong Yang , Haneen Mohammed 
> 

You need to fix the Author name.
> 
> When vkms_get_vblank_timestamp() is called very first time without
> enabling vblank before, vblank time has just intial value and it makes
> warning message. this patch prevents warning message by setting vblank
> time to current time.

I consider *fix* a somewhat strong term to this change. In my opinion,
it would be better to choose another term in the commit message like
*avoid* timestamp warning when vblanks aren't enabled.

In the body of the commit message, I think interesting to include the
exactly warning message that this patch addresses. You could also
describe the initial values that triggers this warning and why this
approach is reasonable, as VKMS has fake clocks.

> 
> Cc: Daniel Vetter 
> Cc: Rodrigo Siqueira 
> Cc: Haneen Mohammed 
> Cc: Melissa Wen 
> 
> Signed-off-by: Sidong Yang 
> ---
>  drivers/gpu/drm/vkms/vkms_crtc.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c 
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> index ac85e17428f8..09c012d54d58 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -86,6 +86,11 @@ static bool vkms_get_vblank_timestamp(struct drm_crtc 
> *crtc,
>   struct vkms_output *output = >output;
>   struct drm_vblank_crtc *vblank = >vblank[pipe];
>  
> + if (!READ_ONCE(vblank->enabled)) {
> + *vblank_time = ktime_get();
> + return true;
> + }
> +

Apart from issues in commit message and format, I checked the code and it
works fine.

Reviewed-by: Melissa Wen 

>   *vblank_time = READ_ONCE(output->vblank_hrtimer.node.expires);
>  
>   if (WARN_ON(*vblank_time == vblank->time))
> -- 
> 2.17.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: update todo.rst

[Melissa Wen]

On 09/29, Daniel Vetter wrote:
> - debugfs cleanup has moved forward thanks to the cleanup Wambui has
>   done
> 
> Cc: Wambui Karuga 
> Cc: Greg Kroah-Hartman 
> Cc: Melissa Wen 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/gpu/todo.rst | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 3751ac976c3e..700637e25ecd 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -515,9 +515,6 @@ There's a bunch of issues with it:
>this (together with the drm_minor->drm_device move) would allow us to 
> remove
>debugfs_init.
>  
> -- Drop the return code and error checking from all debugfs functions. Greg 
> KH is
> -  working on this already.
> -
>  Contact: Daniel Vetter
>  
>  Level: Intermediate
> -- 
> 2.28.0
>
Acked-by: Melissa Wen 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 18/21] drm/vkms: Introduce GEM object functions

[Melissa Wen]

Hi Thomas,

On 09/15, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in vkms.
> 
> Signed-off-by: Thomas Zimmermann 

Thanks! Looks fine.

Reviewed-by: Melissa Wen 

> ---
>  drivers/gpu/drm/vkms/vkms_drv.c |  8 
>  drivers/gpu/drm/vkms/vkms_gem.c | 13 +
>  2 files changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index cb0b6230c22c..726801ab44d4 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -51,12 +51,6 @@ static const struct file_operations vkms_driver_fops = {
>   .release= drm_release,
>  };
>  
> -static const struct vm_operations_struct vkms_gem_vm_ops = {
> - .fault = vkms_gem_fault,
> - .open = drm_gem_vm_open,
> - .close = drm_gem_vm_close,
> -};
> -
>  static void vkms_release(struct drm_device *dev)
>  {
>   struct vkms_device *vkms = container_of(dev, struct vkms_device, drm);
> @@ -98,8 +92,6 @@ static struct drm_driver vkms_driver = {
>   .release= vkms_release,
>   .fops   = _driver_fops,
>   .dumb_create= vkms_dumb_create,
> - .gem_vm_ops = _gem_vm_ops,
> - .gem_free_object_unlocked = vkms_gem_free_object,
>   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
>   .gem_prime_import_sg_table = vkms_prime_import_sg_table,
>  
> diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
> index a017fc59905e..19a0e260a4df 100644
> --- a/drivers/gpu/drm/vkms/vkms_gem.c
> +++ b/drivers/gpu/drm/vkms/vkms_gem.c
> @@ -7,6 +7,17 @@
>  
>  #include "vkms_drv.h"
>  
> +static const struct vm_operations_struct vkms_gem_vm_ops = {
> + .fault = vkms_gem_fault,
> + .open = drm_gem_vm_open,
> + .close = drm_gem_vm_close,
> +};
> +
> +static const struct drm_gem_object_funcs vkms_gem_object_funcs = {
> + .free = vkms_gem_free_object,
> + .vm_ops = _gem_vm_ops,
> +};
> +
>  static struct vkms_gem_object *__vkms_gem_create(struct drm_device *dev,
>u64 size)
>  {
> @@ -17,6 +28,8 @@ static struct vkms_gem_object *__vkms_gem_create(struct 
> drm_device *dev,
>   if (!obj)
>   return ERR_PTR(-ENOMEM);
>  
> + obj->gem.funcs = _gem_object_funcs;
> +
>   size = roundup(size, PAGE_SIZE);
>   ret = drm_gem_object_init(dev, >gem, size);
>   if (ret) {
> -- 
> 2.28.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 16/21] drm/vgem: Introduce GEM object functions

[Melissa Wen]

Hi Thomas,

On 09/15, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in vgem. The only exception is gem_prime_mmap,
> which is non-trivial to convert.
> 
> Signed-off-by: Thomas Zimmermann 

Thanks here again.

This drv file is little tumultuous to me.
I mean, I took a while to sort functions in my head.

However, finally, I got it, and the change looks good.

Reviewed-by: Melissa Wen 

> ---
>  drivers/gpu/drm/vgem/vgem_drv.c | 21 ++---
>  1 file changed, 14 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index cb884c890065..fa54a6d1403d 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -50,6 +50,8 @@
>  #define DRIVER_MAJOR 1
>  #define DRIVER_MINOR 0
>  
> +static const struct drm_gem_object_funcs vgem_gem_object_funcs;
> +
>  static struct vgem_device {
>   struct drm_device drm;
>   struct platform_device *platform;
> @@ -167,6 +169,8 @@ static struct drm_vgem_gem_object 
> *__vgem_gem_create(struct drm_device *dev,
>   if (!obj)
>   return ERR_PTR(-ENOMEM);
>  
> + obj->base.funcs = _gem_object_funcs;
> +
>   ret = drm_gem_object_init(dev, >base, roundup(size, PAGE_SIZE));
>   if (ret) {
>   kfree(obj);
> @@ -401,12 +405,20 @@ static int vgem_prime_mmap(struct drm_gem_object *obj,
>   return 0;
>  }
>  
> +static const struct drm_gem_object_funcs vgem_gem_object_funcs = {
> + .free = vgem_gem_free_object,
> + .pin = vgem_prime_pin,
> + .unpin = vgem_prime_unpin,
> + .get_sg_table = vgem_prime_get_sg_table,
> + .vmap = vgem_prime_vmap,
> + .vunmap = vgem_prime_vunmap,
> + .vm_ops = _gem_vm_ops,
> +};
> +
>  static struct drm_driver vgem_driver = {
>   .driver_features= DRIVER_GEM | DRIVER_RENDER,
>   .open   = vgem_open,
>   .postclose  = vgem_postclose,
> - .gem_free_object_unlocked   = vgem_gem_free_object,
> - .gem_vm_ops = _gem_vm_ops,
>   .ioctls = vgem_ioctls,
>   .num_ioctls = ARRAY_SIZE(vgem_ioctls),
>   .fops   = _driver_fops,
> @@ -415,13 +427,8 @@ static struct drm_driver vgem_driver = {
>  
>   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
>   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> - .gem_prime_pin = vgem_prime_pin,
> - .gem_prime_unpin = vgem_prime_unpin,
>   .gem_prime_import = vgem_prime_import,
>   .gem_prime_import_sg_table = vgem_prime_import_sg_table,
> - .gem_prime_get_sg_table = vgem_prime_get_sg_table,
> - .gem_prime_vmap = vgem_prime_vmap,
> - .gem_prime_vunmap = vgem_prime_vunmap,
>   .gem_prime_mmap = vgem_prime_mmap,
>  
>   .name   = DRIVER_NAME,
> -- 
> 2.28.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/vgem: validate vgem_device before exit operations

[Melissa Wen]

This patch adds a check for the vgem_device before handling it.

Signed-off-by: Melissa Wen 
---
 drivers/gpu/drm/vgem/vgem_drv.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index cb884c890065..119ca887cb8a 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -472,7 +472,14 @@ static int __init vgem_init(void)
 
 static void __exit vgem_exit(void)
 {
-   struct platform_device *pdev = vgem_device->platform;
+   struct platform_device *pdev;
+
+   if (!vgem_device) {
+   DRM_INFO("vgem_device is NULL\n");
+   return;
+   }
+
+   pdev = vgem_device->platform;
 
drm_dev_unregister(_device->drm);
devres_release_group(>dev, NULL);
-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/vkms: add missing drm_crtc_vblank_put to the get/put pair on flush

[Melissa Wen]

This patch adds a missing drm_crtc_vblank_put op to the pair
drm_crtc_vblank_get/put (inc/decrement counter to guarantee vblanks).

It clears the execution of the following kms_cursor_crc subtests:
1. pipe-A-cursor-[size,alpha-opaque, NxN-(on-screen, off-screen, sliding,
   random, fast-moving])] - successful when running individually.
2. pipe-A-cursor-dpms passes again
3. pipe-A-cursor-suspend also passes

The issue was initially tracked in the sequential execution of IGT
kms_cursor_crc subtest: when running the test sequence or one of its
subtests twice, the odd execs complete and the pairs get stuck in an
endless wait. In the IGT code, calling a wait_for_vblank before the start
of CRC capture prevented the busy-wait. But the problem persisted in the
pipe-A-cursor-dpms and -suspend subtests.

Checking the history, the pipe-A-cursor-dpms subtest was successful when,
in vkms_atomic_commit_tail, instead of using the flip_done op, it used
wait_for_vblanks. Another way to prevent blocking was wait_one_vblank when
enabling crtc. However, in both cases, pipe-A-cursor-suspend persisted
blocking in the 2nd start of CRC capture, which may indicate that
something got stuck in the step of CRC setup. Indeed, wait_one_vblank in
the crc setup was able to sync things and free all kms_cursor_crc
subtests.

Tracing and comparing a clean run with a blocked one:
- in a clean one, vkms_crtc_atomic_flush enables vblanks;
- when blocked, only in next op, vkms_crtc_atomic_enable, the vblanks
started. Moreover, a series of vkms_vblank_simulate flow out until
disabling vblanks.
Also watching the steps of vkms_crtc_atomic_flush, when the very first
drm_crtc_vblank_get returned an error, the subtest crashed. On the other
hand, when vblank_get succeeded, the subtest completed. Finally, checking
the flush steps: it increases counter to hold a vblank reference (get),
but there isn't a op to decreased it and release vblanks (put).

Cc: Daniel Vetter 
Cc: Rodrigo Siqueira 
Cc: Haneen Mohammed 
Signed-off-by: Melissa Wen 
---
 drivers/gpu/drm/vkms/vkms_crtc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index ac85e17428f8..a99d6b4a92dd 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -246,6 +246,7 @@ static void vkms_crtc_atomic_flush(struct drm_crtc *crtc,
 
spin_unlock(>dev->event_lock);
 
+   drm_crtc_vblank_put(crtc);
crtc->state->event = NULL;
}
 
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vkms: add missing drm_crtc_vblank_put to the get/put pair on flush

[Melissa Wen]

On 07/22, dan...@ffwll.ch wrote:
> On Wed, Jul 22, 2020 at 08:04:11AM -0300, Melissa Wen wrote:
> > This patch adds a missing drm_crtc_vblank_put op to the pair
> > drm_crtc_vblank_get/put (inc/decrement counter to guarantee vblanks).
> > 
> > It clears the execution of the following kms_cursor_crc subtests:
> > 1. pipe-A-cursor-[size,alpha-opaque, NxN-(on-screen, off-screen, sliding,
> >random, fast-moving])] - successful when running individually.
> > 2. pipe-A-cursor-dpms passes again
> > 3. pipe-A-cursor-suspend also passes
> > 
> > The issue was initially tracked in the sequential execution of IGT
> > kms_cursor_crc subtest: when running the test sequence or one of its
> > subtests twice, the odd execs complete and the pairs get stuck in an
> > endless wait. In the IGT code, calling a wait_for_vblank before the start
> > of CRC capture prevented the busy-wait. But the problem persisted in the
> > pipe-A-cursor-dpms and -suspend subtests.
> > 
> > Checking the history, the pipe-A-cursor-dpms subtest was successful when,
> > in vkms_atomic_commit_tail, instead of using the flip_done op, it used
> > wait_for_vblanks. Another way to prevent blocking was wait_one_vblank when
> > enabling crtc. However, in both cases, pipe-A-cursor-suspend persisted
> > blocking in the 2nd start of CRC capture, which may indicate that
> > something got stuck in the step of CRC setup. Indeed, wait_one_vblank in
> > the crc setup was able to sync things and free all kms_cursor_crc
> > subtests.
> > 
> > Tracing and comparing a clean run with a blocked one:
> > - in a clean one, vkms_crtc_atomic_flush enables vblanks;
> > - when blocked, only in next op, vkms_crtc_atomic_enable, the vblanks
> > started. Moreover, a series of vkms_vblank_simulate flow out until
> > disabling vblanks.
> > Also watching the steps of vkms_crtc_atomic_flush, when the very first
> > drm_crtc_vblank_get returned an error, the subtest crashed. On the other
> > hand, when vblank_get succeeded, the subtest completed. Finally, checking
> > the flush steps: it increases counter to hold a vblank reference (get),
> > but there isn't a op to decreased it and release vblanks (put).
> > 
> > Cc: Daniel Vetter 
> > Cc: Rodrigo Siqueira 
> > Cc: Haneen Mohammed 
> > Signed-off-by: Melissa Wen 
> > ---
> >  drivers/gpu/drm/vkms/vkms_crtc.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c 
> > b/drivers/gpu/drm/vkms/vkms_crtc.c
> > index ac85e17428f8..a99d6b4a92dd 100644
> > --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> > @@ -246,6 +246,7 @@ static void vkms_crtc_atomic_flush(struct drm_crtc 
> > *crtc,
> >  
> > spin_unlock(>dev->event_lock);
> >  
> > +   drm_crtc_vblank_put(crtc);
> 
> Uh so I reviewed this a bit more carefully now, and I dont think this is
> the correct bugfix. From the kerneldoc of drm_crtc_arm_vblank_event():
> 
>  * Caller must hold a vblank reference for the event @e acquired by a
>  * drm_crtc_vblank_get(), which will be dropped when the next vblank arrives.
> 
> So when we call drm_crtc_arm_vblank_event then the vblank_put gets called
> for us. And that's the only case where we successfully acquired a vblank
> interrupt reference since on failure of drm_crtc_vblank_get (0 indicates
> success for that function, failure negative error number) we directly send
> out the event.
> 
> So something else fishy is going on, and now I'm totally confused why this
> even happens.
> 
> We also have a pile of WARN_ON checks in drm_crtc_vblank_put to make sure
> we don't underflow the refcount, so it's also not that I think (except if
> this patch creates more WARNING backtraces).
> 
> But clearly it changes behaviour somehow ... can you try to figure out
> what changes? Maybe print out the vblank->refcount at various points in
> the driver, and maybe also trace when exactly the fake vkms vblank hrtimer
> is enabled/disabled ...

:(

I can check these, but I also have other suspicions. When I place the
drm_crct_vblank_put out of the if (at the end of flush), it not only solve
the issue of blocking on kms_cursor_crc, but also the WARN_ON on kms_flip
doesn't appear anymore (a total cleanup). Just after:

vkms_output->composer_state = to_vkms_crtc_state(crtc->state);

looks like there is something stuck around here.

Besides, there is a lock at atomic_begin:

  /* This lock is held across the atomic commit to block vblank timer
   * from scheduling vkms_composer_worker until the composer is updated
   */
  spin_lock_irq(_outpu

Re: [PATCH] drm/vkms: add missing drm_crtc_vblank_put to the get/put pair on flush

[Melissa Wen]

Melissa Wen

On Sat, Jul 25, 2020 at 3:12 PM Daniel Vetter  wrote:
>
> On Sat, Jul 25, 2020 at 7:45 PM Melissa Wen  wrote:
> >
> > On 07/25, Daniel Vetter wrote:
> > > On Sat, Jul 25, 2020 at 5:12 AM Sidong Yang  wrote:
> > > >
> > > > On Wed, Jul 22, 2020 at 05:17:05PM +0200, Daniel Vetter wrote:
> > > > > On Wed, Jul 22, 2020 at 4:06 PM Melissa Wen  
> > > > > wrote:
> > > > > >
> > > > > > On 07/22, dan...@ffwll.ch wrote:
> > > > > > > On Wed, Jul 22, 2020 at 08:04:11AM -0300, Melissa Wen wrote:
> > > > > > > > This patch adds a missing drm_crtc_vblank_put op to the pair
> > > > > > > > drm_crtc_vblank_get/put (inc/decrement counter to guarantee 
> > > > > > > > vblanks).
> > > > > > > >
> > > > > > > > It clears the execution of the following kms_cursor_crc 
> > > > > > > > subtests:
> > > > > > > > 1. pipe-A-cursor-[size,alpha-opaque, NxN-(on-screen, 
> > > > > > > > off-screen, sliding,
> > > > > > > >random, fast-moving])] - successful when running 
> > > > > > > > individually.
> > > > > > > > 2. pipe-A-cursor-dpms passes again
> > > > > > > > 3. pipe-A-cursor-suspend also passes
> > > > > > > >
> > > > > > > > The issue was initially tracked in the sequential execution of 
> > > > > > > > IGT
> > > > > > > > kms_cursor_crc subtest: when running the test sequence or one 
> > > > > > > > of its
> > > > > > > > subtests twice, the odd execs complete and the pairs get stuck 
> > > > > > > > in an
> > > > > > > > endless wait. In the IGT code, calling a wait_for_vblank before 
> > > > > > > > the start
> > > > > > > > of CRC capture prevented the busy-wait. But the problem 
> > > > > > > > persisted in the
> > > > > > > > pipe-A-cursor-dpms and -suspend subtests.
> > > > > > > >
> > > > > > > > Checking the history, the pipe-A-cursor-dpms subtest was 
> > > > > > > > successful when,
> > > > > > > > in vkms_atomic_commit_tail, instead of using the flip_done op, 
> > > > > > > > it used
> > > > > > > > wait_for_vblanks. Another way to prevent blocking was 
> > > > > > > > wait_one_vblank when
> > > > > > > > enabling crtc. However, in both cases, pipe-A-cursor-suspend 
> > > > > > > > persisted
> > > > > > > > blocking in the 2nd start of CRC capture, which may indicate 
> > > > > > > > that
> > > > > > > > something got stuck in the step of CRC setup. Indeed, 
> > > > > > > > wait_one_vblank in
> > > > > > > > the crc setup was able to sync things and free all 
> > > > > > > > kms_cursor_crc
> > > > > > > > subtests.
> > > > > > > >
> > > > > > > > Tracing and comparing a clean run with a blocked one:
> > > > > > > > - in a clean one, vkms_crtc_atomic_flush enables vblanks;
> > > > > > > > - when blocked, only in next op, vkms_crtc_atomic_enable, the 
> > > > > > > > vblanks
> > > > > > > > started. Moreover, a series of vkms_vblank_simulate flow out 
> > > > > > > > until
> > > > > > > > disabling vblanks.
> > > > > > > > Also watching the steps of vkms_crtc_atomic_flush, when the 
> > > > > > > > very first
> > > > > > > > drm_crtc_vblank_get returned an error, the subtest crashed. On 
> > > > > > > > the other
> > > > > > > > hand, when vblank_get succeeded, the subtest completed. 
> > > > > > > > Finally, checking
> > > > > > > > the flush steps: it increases counter to hold a vblank 
> > > > > > > > reference (get),
> > > > > > > > but there isn't a op to decreased it and release vblanks (put).
> > > > > > > >
> > > > > > > > Cc: Daniel Vetter 
> > > > 

[PATCH] drm/vkms: guarantee vblank when capturing crc

[Melissa Wen]

VKMS needs vblank interrupts enabled to capture CRC. When vblank is
disabled, tests like kms_cursor_crc and kms_pipe_crc_basic getting stuck
waiting for a capture that will not occur until vkms wakes up. This
patch ensures that vblank remains enabled as long as the CRC capture is
needed.

It clears the execution of the following kms_cursor_crc subtests:
1. pipe-A-cursor-[size,alpha-opaque, NxN-(on-screen, off-screen, sliding,
random, fast-moving])] - successful when running individually.
2. pipe-A-cursor-dpms passes again
3. pipe-A-cursor-suspend also passes

The issue was initially tracked in the sequential execution of IGT
kms_cursor_crc subtest: when running the test sequence or one of its
subtests twice, the odd execs complete and the pairs get stuck in an
endless wait. In the IGT code, calling a wait_for_vblank on preparing
for CRC capture prevented the busy-wait. But the problem persisted in
the pipe-A-cursor-dpms and -suspend subtests.

Checking the history, the pipe-A-cursor-dpms subtest was successful
when, in vkms_atomic_commit_tail, instead of using the flip_done op, it
used wait_for_vblanks. Another way to prevent blocking was
wait_one_vblank when enabling crtc. However, in both cases,
pipe-A-cursor-suspend persisted blocking in the 2nd start of CRC
capture, which may indicate that something got stuck in the step of CRC
setup. Indeed, wait_one_vblank in the crc setup was able to sync things
and free all kms_cursor_crc subtests.

Besides, other alternatives to force enabling vblanks or prevent
disabling them such as calling drm_crtc_put_vblank or modeset_enables
before commit_planes + offdelay = 0, also unlock all subtests
executions. These facts together converge on the lack of vblank to
unblock the crc capture.

Finally, considering the vkms's dependence on vblank interruptions to
perform tasks, this patch acquires a vblank ref when setup CRC source
and releases ref when disabling crc capture, ensuring vblanks happen to
compute CRC.

Cc: Rodrigo Siqueira 
Cc: Haneen Mohammed 
Co-developed-by: Sidong Yang 
Signed-off-by: Sidong Yang 
Co-developed-by: Daniel Vetter 
Signed-off-by: Daniel Vetter 
Signed-off-by: Melissa Wen 
---
 drivers/gpu/drm/vkms/vkms_composer.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
b/drivers/gpu/drm/vkms/vkms_composer.c
index 4af2f19480f4..1161eaa383f1 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -241,6 +241,14 @@ int vkms_set_crc_source(struct drm_crtc *crtc, const char 
*src_name)
 
ret = vkms_crc_parse_source(src_name, );
 
+   /* Ensure that vblank interruptions are enabled for crc capture */
+   /* Enabling CRC: acquire vblank ref */
+   if (enabled)
+   drm_crtc_vblank_get(crtc);
+   /* Disabling CRC: release vblank ref */
+   if (!src_name)
+   drm_crtc_vblank_put(crtc);
+
spin_lock_irq(>lock);
out->composer_enabled = enabled;
spin_unlock_irq(>lock);
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vkms: modify sequence disable/plane/enable in commit_tail

[Melissa Wen]

On Wed, Jul 29, 2020 at 12:22 PM Sidong Yang  wrote:
>
> This patch modifies function call sequence in commit tail. This is for
> the problem that raised when kms_cursor_crc test is tested repeatedly.
> In second test, there is an bug that crtc commit doesn't start vblank events.
> Because there is some error about vblank's refcount. in commit_flush() that
> called from commit_plane, drm_vblank_get() is called and vblank is enabled
> in normal case. But in second test, vblank isn't enable for vblank->refcount
> is already increased in previous test. Increased refcount will be decreased
> in drm_atomic_helper_commit_modeset_enables() after commit_plane.
> Therefore, commit_plane should be called after commit_modeset_enable.
>
> In this situation, there is a warning raised in get_vblank_timestamp().
> hrtimer.node.expires and vblank->time are zero for no vblank events before.
> This patch returns current time when vblank is not enabled.
>
Hi Sidong,

I think this patch tries to solve two different issues.

I am not a maintainer, but I believe you can split it.

Everything indicates that changing the commit tail sequence does not
ideally solve the problem of subtests getting stuck (as we have dicussed);
however, for me, the treatment of the warning is valid and it is also related
to other IGT tests using VKMS.

One option is to send a patch that only treats the warning. I believe that
in the body of the commit message, it would be nice to have the warning
that this patch addresses, and when it appears by running an IGT test.
Also, say why it should be done this way in vkms.
This info could help future debugging.

Off-topic: I removed the group's mailing list of the University of São
Paulo (kernel-usp) from the cc, since I believe you had no intention of
sending the patch to them.

Best regards,

Melissa

> Cc: Daniel Vetter 
> Cc: Rodrigo Siqueira 
> Cc: Haneen Mohammed 
>
> Signed-off-by: Sidong Yang 
> ---
>  drivers/gpu/drm/vkms/vkms_crtc.c | 5 +
>  drivers/gpu/drm/vkms/vkms_drv.c  | 4 ++--
>  2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c 
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> index ac85e17428f8..09c012d54d58 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -86,6 +86,11 @@ static bool vkms_get_vblank_timestamp(struct drm_crtc 
> *crtc,
> struct vkms_output *output = >output;
> struct drm_vblank_crtc *vblank = >vblank[pipe];
>
> +   if (!READ_ONCE(vblank->enabled)) {
> +   *vblank_time = ktime_get();
> +   return true;
> +   }
> +
> *vblank_time = READ_ONCE(output->vblank_hrtimer.node.expires);
>
> if (WARN_ON(*vblank_time == vblank->time))
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index 1e8b2169d834..c2c83a01d4a7 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -76,10 +76,10 @@ static void vkms_atomic_commit_tail(struct 
> drm_atomic_state *old_state)
>
> drm_atomic_helper_commit_modeset_disables(dev, old_state);
>
> -   drm_atomic_helper_commit_planes(dev, old_state, 0);
> -
> drm_atomic_helper_commit_modeset_enables(dev, old_state);
>
> +   drm_atomic_helper_commit_planes(dev, old_state, 0);
> +
> drm_atomic_helper_fake_vblank(old_state);
>
> drm_atomic_helper_commit_hw_done(old_state);
> --
> 2.17.1
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Kernel USP" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to kernel-usp+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/kernel-usp/20200729152231.13249-1-realwakka%40gmail.com.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3] drm/vkms: guarantee vblank when capturing crc

[Melissa Wen]

VKMS needs vblank interrupts enabled to capture CRC. When vblank is
disabled, tests like kms_cursor_crc and kms_pipe_crc_basic getting stuck
waiting for a capture that will not occur until vkms wakes up. This patch
adds a helper to set composer and ensure that vblank remains enabled as
long as the CRC capture is needed.

It clears the execution of the following kms_cursor_crc subtests:
1. pipe-A-cursor-[size,alpha-opaque, NxN-(on-screen, off-screen, sliding,
random, fast-moving])] - successful when running individually.
2. pipe-A-cursor-dpms passes again
3. pipe-A-cursor-suspend also passes

The issue was initially tracked in the sequential execution of IGT
kms_cursor_crc subtests: when running the test sequence or one of its
subtests twice, the odd execs complete and the pairs get stuck in an
endless wait. In the IGT code, calling a wait_for_vblank on preparing for
CRC capture prevented the busy-wait. But the problem persisted in the
pipe-A-cursor-dpms and -suspend subtests.

Checking the history, the pipe-A-cursor-dpms subtest was successful when,
in vkms_atomic_commit_tail, instead of using the flip_done op, it used
wait_for_vblanks. Another way to prevent blocking was wait_one_vblank when
enabling crtc. However, in both cases, pipe-A-cursor-suspend persisted
blocking in the 2nd start of CRC capture, which may indicate that
something got stuck in the step of CRC setup. Indeed, wait_one_vblank in
the crc setup was able to sync things and free all kms_cursor_crc
subtests. Besides, other alternatives to force enabling vblanks or prevent
disabling them such as calling drm_crtc_put_vblank or modeset_enables
before commit_planes + offdelay = 0, also unlock all subtests executions.

Finally, due to vkms's dependence on vblank interruptions to perform
tasks, this patch uses refcount to ensure that vblanks happen when
enabling composer and while crc capture is needed.

Cc: Rodrigo Siqueira 
Cc: Haneen Mohammed 

Co-debugged-by: Sidong Yang 
Signed-off-by: Sidong Yang 
Signed-off-by: Melissa Wen 
Reviewed-by: Daniel Vetter 

---

v2:
- extract a vkms_set_composer helper
- fix vblank refcounting for the disabling case

v3:
- make the vkms_set_composer helper static
- review the credit tags

---
 drivers/gpu/drm/vkms/vkms_composer.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
b/drivers/gpu/drm/vkms/vkms_composer.c
index b8b060354667..4f3b07a32b60 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -233,6 +233,22 @@ int vkms_verify_crc_source(struct drm_crtc *crtc, const 
char *src_name,
return 0;
 }
 
+static void vkms_set_composer(struct vkms_output *out, bool enabled)
+{
+   bool old_enabled;
+
+   if (enabled)
+   drm_crtc_vblank_get(>crtc);
+
+   spin_lock_irq(>lock);
+   old_enabled = out->composer_enabled;
+   out->composer_enabled = enabled;
+   spin_unlock_irq(>lock);
+
+   if (old_enabled)
+   drm_crtc_vblank_put(>crtc);
+}
+
 int vkms_set_crc_source(struct drm_crtc *crtc, const char *src_name)
 {
struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
@@ -241,9 +257,7 @@ int vkms_set_crc_source(struct drm_crtc *crtc, const char 
*src_name)
 
ret = vkms_crc_parse_source(src_name, );
 
-   spin_lock_irq(>lock);
-   out->composer_enabled = enabled;
-   spin_unlock_irq(>lock);
+   vkms_set_composer(out, enabled);
 
return ret;
 }
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vkms: add missing drm_crtc_vblank_put to the get/put pair on flush

[Melissa Wen]

On 07/29, Daniel Vetter wrote:
> On Wed, Jul 29, 2020 at 9:09 PM Melissa Wen  wrote:
> >
> > Melissa Wen
> >
> > On Sat, Jul 25, 2020 at 3:12 PM Daniel Vetter  wrote:
> > >
> > > On Sat, Jul 25, 2020 at 7:45 PM Melissa Wen  wrote:
> > > >
> > > > On 07/25, Daniel Vetter wrote:
> > > > > On Sat, Jul 25, 2020 at 5:12 AM Sidong Yang  
> > > > > wrote:
> > > > > >
> > > > > > On Wed, Jul 22, 2020 at 05:17:05PM +0200, Daniel Vetter wrote:
> > > > > > > On Wed, Jul 22, 2020 at 4:06 PM Melissa Wen 
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On 07/22, dan...@ffwll.ch wrote:
> > > > > > > > > On Wed, Jul 22, 2020 at 08:04:11AM -0300, Melissa Wen wrote:
> > > > > > > > > > This patch adds a missing drm_crtc_vblank_put op to the pair
> > > > > > > > > > drm_crtc_vblank_get/put (inc/decrement counter to guarantee 
> > > > > > > > > > vblanks).
> > > > > > > > > >
> > > > > > > > > > It clears the execution of the following kms_cursor_crc 
> > > > > > > > > > subtests:
> > > > > > > > > > 1. pipe-A-cursor-[size,alpha-opaque, NxN-(on-screen, 
> > > > > > > > > > off-screen, sliding,
> > > > > > > > > >random, fast-moving])] - successful when running 
> > > > > > > > > > individually.
> > > > > > > > > > 2. pipe-A-cursor-dpms passes again
> > > > > > > > > > 3. pipe-A-cursor-suspend also passes
> > > > > > > > > >
> > > > > > > > > > The issue was initially tracked in the sequential execution 
> > > > > > > > > > of IGT
> > > > > > > > > > kms_cursor_crc subtest: when running the test sequence or 
> > > > > > > > > > one of its
> > > > > > > > > > subtests twice, the odd execs complete and the pairs get 
> > > > > > > > > > stuck in an
> > > > > > > > > > endless wait. In the IGT code, calling a wait_for_vblank 
> > > > > > > > > > before the start
> > > > > > > > > > of CRC capture prevented the busy-wait. But the problem 
> > > > > > > > > > persisted in the
> > > > > > > > > > pipe-A-cursor-dpms and -suspend subtests.
> > > > > > > > > >
> > > > > > > > > > Checking the history, the pipe-A-cursor-dpms subtest was 
> > > > > > > > > > successful when,
> > > > > > > > > > in vkms_atomic_commit_tail, instead of using the flip_done 
> > > > > > > > > > op, it used
> > > > > > > > > > wait_for_vblanks. Another way to prevent blocking was 
> > > > > > > > > > wait_one_vblank when
> > > > > > > > > > enabling crtc. However, in both cases, 
> > > > > > > > > > pipe-A-cursor-suspend persisted
> > > > > > > > > > blocking in the 2nd start of CRC capture, which may 
> > > > > > > > > > indicate that
> > > > > > > > > > something got stuck in the step of CRC setup. Indeed, 
> > > > > > > > > > wait_one_vblank in
> > > > > > > > > > the crc setup was able to sync things and free all 
> > > > > > > > > > kms_cursor_crc
> > > > > > > > > > subtests.
> > > > > > > > > >
> > > > > > > > > > Tracing and comparing a clean run with a blocked one:
> > > > > > > > > > - in a clean one, vkms_crtc_atomic_flush enables vblanks;
> > > > > > > > > > - when blocked, only in next op, vkms_crtc_atomic_enable, 
> > > > > > > > > > the vblanks
> > > > > > > > > > started. Moreover, a series of vkms_vblank_simulate flow 
> > > > > > > > > > out until
> > > > > > > > > > disabling vblanks.
> > > > > > > > > > Also watching the steps of vkms_crt

Re: [PATCH] drm/vkms: add missing drm_crtc_vblank_put to the get/put pair on flush

[Melissa Wen]

On 07/31, Sidong Yang wrote:
> On Fri, Jul 31, 2020 at 11:08:34AM +0200, dan...@ffwll.ch wrote:
> > On Thu, Jul 30, 2020 at 07:09:25AM -0300, Melissa Wen wrote:
> > > On 07/29, Daniel Vetter wrote:
> > > > On Wed, Jul 29, 2020 at 9:09 PM Melissa Wen  
> > > > wrote:
> > > > >
> > > > > Melissa Wen
> > > > >
> > > > > On Sat, Jul 25, 2020 at 3:12 PM Daniel Vetter  wrote:
> > > > > >
> > > > > > On Sat, Jul 25, 2020 at 7:45 PM Melissa Wen  
> > > > > > wrote:
> > > > > > >
> > > > > > > On 07/25, Daniel Vetter wrote:
> > > > > > > > On Sat, Jul 25, 2020 at 5:12 AM Sidong Yang 
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > On Wed, Jul 22, 2020 at 05:17:05PM +0200, Daniel Vetter wrote:
> > > > > > > > > > On Wed, Jul 22, 2020 at 4:06 PM Melissa Wen 
> > > > > > > > > >  wrote:
> > > > > > > > > > >
> > > > > > > > > > > On 07/22, dan...@ffwll.ch wrote:
> > > > > > > > > > > > On Wed, Jul 22, 2020 at 08:04:11AM -0300, Melissa Wen 
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > This patch adds a missing drm_crtc_vblank_put op to 
> > > > > > > > > > > > > the pair
> > > > > > > > > > > > > drm_crtc_vblank_get/put (inc/decrement counter to 
> > > > > > > > > > > > > guarantee vblanks).
> > > > > > > > > > > > >
> > > > > > > > > > > > > It clears the execution of the following 
> > > > > > > > > > > > > kms_cursor_crc subtests:
> > > > > > > > > > > > > 1. pipe-A-cursor-[size,alpha-opaque, NxN-(on-screen, 
> > > > > > > > > > > > > off-screen, sliding,
> > > > > > > > > > > > >random, fast-moving])] - successful when running 
> > > > > > > > > > > > > individually.
> > > > > > > > > > > > > 2. pipe-A-cursor-dpms passes again
> > > > > > > > > > > > > 3. pipe-A-cursor-suspend also passes
> > > > > > > > > > > > >
> > > > > > > > > > > > > The issue was initially tracked in the sequential 
> > > > > > > > > > > > > execution of IGT
> > > > > > > > > > > > > kms_cursor_crc subtest: when running the test 
> > > > > > > > > > > > > sequence or one of its
> > > > > > > > > > > > > subtests twice, the odd execs complete and the pairs 
> > > > > > > > > > > > > get stuck in an
> > > > > > > > > > > > > endless wait. In the IGT code, calling a 
> > > > > > > > > > > > > wait_for_vblank before the start
> > > > > > > > > > > > > of CRC capture prevented the busy-wait. But the 
> > > > > > > > > > > > > problem persisted in the
> > > > > > > > > > > > > pipe-A-cursor-dpms and -suspend subtests.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Checking the history, the pipe-A-cursor-dpms subtest 
> > > > > > > > > > > > > was successful when,
> > > > > > > > > > > > > in vkms_atomic_commit_tail, instead of using the 
> > > > > > > > > > > > > flip_done op, it used
> > > > > > > > > > > > > wait_for_vblanks. Another way to prevent blocking was 
> > > > > > > > > > > > > wait_one_vblank when
> > > > > > > > > > > > > enabling crtc. However, in both cases, 
> > > > > > > > > > > > > pipe-A-cursor-suspend persisted
> > > > > > > > > > > > > blocking in the 2nd start of CRC capture, which may 
> > > > > > > > > > >

Re: [PATCH] drm/vkms: guarantee vblank when capturing crc

[Melissa Wen]

On 08/04, dan...@ffwll.ch wrote:
> On Sat, Aug 01, 2020 at 03:49:29PM -0300, Melissa Wen wrote:
> > VKMS needs vblank interrupts enabled to capture CRC. When vblank is
> > disabled, tests like kms_cursor_crc and kms_pipe_crc_basic getting stuck
> > waiting for a capture that will not occur until vkms wakes up. This
> > patch ensures that vblank remains enabled as long as the CRC capture is
> > needed.
> > 
> > It clears the execution of the following kms_cursor_crc subtests:
> > 1. pipe-A-cursor-[size,alpha-opaque, NxN-(on-screen, off-screen, sliding,
> > random, fast-moving])] - successful when running individually.
> > 2. pipe-A-cursor-dpms passes again
> > 3. pipe-A-cursor-suspend also passes
> > 
> > The issue was initially tracked in the sequential execution of IGT
> > kms_cursor_crc subtest: when running the test sequence or one of its
> > subtests twice, the odd execs complete and the pairs get stuck in an
> > endless wait. In the IGT code, calling a wait_for_vblank on preparing
> > for CRC capture prevented the busy-wait. But the problem persisted in
> > the pipe-A-cursor-dpms and -suspend subtests.
> > 
> > Checking the history, the pipe-A-cursor-dpms subtest was successful
> > when, in vkms_atomic_commit_tail, instead of using the flip_done op, it
> > used wait_for_vblanks. Another way to prevent blocking was
> > wait_one_vblank when enabling crtc. However, in both cases,
> > pipe-A-cursor-suspend persisted blocking in the 2nd start of CRC
> > capture, which may indicate that something got stuck in the step of CRC
> > setup. Indeed, wait_one_vblank in the crc setup was able to sync things
> > and free all kms_cursor_crc subtests.
> > 
> > Besides, other alternatives to force enabling vblanks or prevent
> > disabling them such as calling drm_crtc_put_vblank or modeset_enables
> > before commit_planes + offdelay = 0, also unlock all subtests
> > executions. These facts together converge on the lack of vblank to
> > unblock the crc capture.
> > 
> > Finally, considering the vkms's dependence on vblank interruptions to
> > perform tasks, this patch acquires a vblank ref when setup CRC source
> > and releases ref when disabling crc capture, ensuring vblanks happen to
> > compute CRC.
> > 
> > Cc: Rodrigo Siqueira 
> > Cc: Haneen Mohammed 
> > Co-developed-by: Sidong Yang 
> > Signed-off-by: Sidong Yang 
> > Co-developed-by: Daniel Vetter 
> > Signed-off-by: Daniel Vetter 
> > Signed-off-by: Melissa Wen 
> 
> Excellent summary of the debug story.
> 
> > ---
> >  drivers/gpu/drm/vkms/vkms_composer.c | 8 
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
> > b/drivers/gpu/drm/vkms/vkms_composer.c
> > index 4af2f19480f4..1161eaa383f1 100644
> > --- a/drivers/gpu/drm/vkms/vkms_composer.c
> > +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> > @@ -241,6 +241,14 @@ int vkms_set_crc_source(struct drm_crtc *crtc, const 
> > char *src_name)
> >  
> > ret = vkms_crc_parse_source(src_name, );
> >  
> > +   /* Ensure that vblank interruptions are enabled for crc capture */
> > +   /* Enabling CRC: acquire vblank ref */
> 
> This comment just explains what the code does, that's not needed. The
> first comment I think can be replaced if we create a little helper
> function like
> 
> void vkms_set_composer(struct vkms_output, bool enable) {
>   bool old_state;
> 
>   if (enabled)
>   drm_crtc_vblank_get(crtc);
> 
>   spin_lock_irq(>lock);
>   old_enable = out->composer_enabled;
>   out->composer_enabled = enabled;
>   spin_unlock_irq(>lock);
> 
>   if (old_enabled)
>   drm_crtc_vblank_put(crtc);
> 
> }
> 
> This should also help as prep for the writeback work, where we have a 2nd
> user that might need to enable the composer (maybe even need to switch to
> refcounting the composer state then).
>
Hi Daniel,

Thanks for the feedback and advice.
I applied the suggestion and just sent a v2.

Best regards,

Melissa

> > +   if (enabled)
> > +   drm_crtc_vblank_get(crtc);
> > +   /* Disabling CRC: release vblank ref */
> > +   if (!src_name)
> > +   drm_crtc_vblank_put(crtc);
> 
> I'm not sure this correctly releases the vblank reference in all cases, I
> think the suggestion in the helper function pseudo code should work
> better. It does mean we temporarily elevate the vblank refcount if we go
> enabled -> enabled, but that's not a problem since it's refcounted.
> 
> Cheers, Daniel
> 
> > +
> > spin_lock_irq(>lock);
> > out->composer_enabled = enabled;
> > spin_unlock_irq(>lock);
> > -- 
> > 2.27.0
> > 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/vkms: guarantee vblank when capturing crc

[Melissa Wen]

VKMS needs vblank interrupts enabled to capture CRC. When vblank is
disabled, tests like kms_cursor_crc and kms_pipe_crc_basic getting stuck
waiting for a capture that will not occur until vkms wakes up. This patch
adds a helper to set composer and ensure that vblank remains enabled as
long as the CRC capture is needed.

It clears the execution of the following kms_cursor_crc subtests:
1. pipe-A-cursor-[size,alpha-opaque, NxN-(on-screen, off-screen, sliding,
random, fast-moving])] - successful when running individually.
2. pipe-A-cursor-dpms passes again
3. pipe-A-cursor-suspend also passes

The issue was initially tracked in the sequential execution of IGT
kms_cursor_crc subtest: when running the test sequence or one of its
subtests twice, the odd execs complete and the pairs get stuck in an
endless wait. In the IGT code, calling a wait_for_vblank on preparing for
CRC capture prevented the busy-wait. But the problem persisted in the
pipe-A-cursor-dpms and -suspend subtests.

Checking the history, the pipe-A-cursor-dpms subtest was successful when,
in vkms_atomic_commit_tail, instead of using the flip_done op, it used
wait_for_vblanks. Another way to prevent blocking was wait_one_vblank when
enabling crtc. However, in both cases, pipe-A-cursor-suspend persisted
blocking in the 2nd start of CRC capture, which may indicate that
something got stuck in the step of CRC setup. Indeed, wait_one_vblank in
the crc setup was able to sync things and free all kms_cursor_crc
subtests. Besides, other alternatives to force enabling vblanks or prevent
disabling them such as calling drm_crtc_put_vblank or modeset_enables
before commit_planes + offdelay = 0, also unlock all subtests executions.

Finally, due to vkms's dependence on vblank interruptions to perform
tasks, this patch uses refcount to ensure that vblanks happen when
enabling composer and while crc capture is needed.

Cc: Rodrigo Siqueira 
Cc: Haneen Mohammed 
Co-developed-by: Sidong Yang 
Signed-off-by: Sidong Yang 
Co-developed-by: Daniel Vetter 
Signed-off-by: Daniel Vetter 
Signed-off-by: Melissa Wen 
---
 drivers/gpu/drm/vkms/vkms_composer.c | 20 +---
 drivers/gpu/drm/vkms/vkms_drv.h  |  1 +
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
b/drivers/gpu/drm/vkms/vkms_composer.c
index b8b060354667..e2ac2b9759bf 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -233,6 +233,22 @@ int vkms_verify_crc_source(struct drm_crtc *crtc, const 
char *src_name,
return 0;
 }
 
+void vkms_set_composer(struct vkms_output *out, bool enabled)
+{
+   bool old_enabled;
+
+   if (enabled)
+   drm_crtc_vblank_get(>crtc);
+
+   spin_lock_irq(>lock);
+   old_enabled = out->composer_enabled;
+   out->composer_enabled = enabled;
+   spin_unlock_irq(>lock);
+
+   if (old_enabled)
+   drm_crtc_vblank_put(>crtc);
+}
+
 int vkms_set_crc_source(struct drm_crtc *crtc, const char *src_name)
 {
struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
@@ -241,9 +257,7 @@ int vkms_set_crc_source(struct drm_crtc *crtc, const char 
*src_name)
 
ret = vkms_crc_parse_source(src_name, );
 
-   spin_lock_irq(>lock);
-   out->composer_enabled = enabled;
-   spin_unlock_irq(>lock);
+   vkms_set_composer(out, enabled);
 
return ret;
 }
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index f4036bb0b9a8..2cc86d08bd4e 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -142,6 +142,7 @@ int vkms_verify_crc_source(struct drm_crtc *crtc, const 
char *source_name,
   size_t *values_cnt);
 
 /* Composer Support */
+void vkms_set_composer(struct vkms_output *output, bool enabled);
 void vkms_composer_worker(struct work_struct *work);
 
 #endif /* _VKMS_DRV_H_ */
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/vkms: change the max cursor width/height

[Melissa Wen]

This change expands the coverage for the IGT kms_cursor_crc test, where
the size varies between 64 and 512 for a square cursor. With this, in
addition to the cursor 64x64, this patch enables the test of cursors with
sizes: 128x128, 256x256, and 512x512.

Signed-off-by: Melissa Wen 
---
 drivers/gpu/drm/vkms/vkms_drv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index 1e8b2169d834..57a8a397d5e8 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -133,6 +133,8 @@ static int vkms_modeset_init(struct vkms_device *vkmsdev)
dev->mode_config.min_height = YRES_MIN;
dev->mode_config.max_width = XRES_MAX;
dev->mode_config.max_height = YRES_MAX;
+   dev->mode_config.cursor_width = 512;
+   dev->mode_config.cursor_height = 512;
dev->mode_config.preferred_depth = 24;
dev->mode_config.helper_private = _mode_config_helpers;
 
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vkms: add wait_for_vblanks in atomic_commit_tail

[Melissa Wen]

On 07/13, Daniel Vetter wrote:
> On Fri, Jul 10, 2020 at 02:05:33PM -0300, Melissa Wen wrote:
> > On 07/02, Daniel Vetter wrote:
> > > On Wed, Jul 01, 2020 at 03:31:34PM +, Sidong Yang wrote:
> > > > there is an error when igt test is run continuously. 
> > > > vkms_atomic_commit_tail()
> > > > need to call drm_atomic_helper_wait_for_vblanks() for give up ownership 
> > > > of
> > > > vblank events. without this code, next atomic commit will not enable 
> > > > vblank
> > > > and raise timeout error.
> > > > 
> > > > Signed-off-by: Sidong Yang 
> > > > ---
> > > >  drivers/gpu/drm/vkms/vkms_drv.c | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c 
> > > > b/drivers/gpu/drm/vkms/vkms_drv.c
> > > > index 1e8b2169d834..10b9be67a068 100644
> > > > --- a/drivers/gpu/drm/vkms/vkms_drv.c
> > > > +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> > > > @@ -93,6 +93,8 @@ static void vkms_atomic_commit_tail(struct 
> > > > drm_atomic_state *old_state)
> > > > flush_work(_state->composer_work);
> > > > }
> > > >  
> > > > +   drm_atomic_helper_wait_for_vblanks(dev, old_state);
> > > 
> > > Uh, we have a wait_for_flip_done right above, which should be doing
> > > exactly the same, but more precisely: Instead of just waiting for any
> > > vblank to happen, we wait for exactly the vblank corresponding to this
> > > atomic commit. So no races possible. If this is papering over some issue,
> > > then I think more debugging is needed.
> > > 
> > > What exactly is going wrong here for you?
> > 
> > Hi Daniel and Sidong,
> > 
> > I noticed a similar issue when running the IGT test kms_cursor_crc. For
> > example, a subtest that passes on the first run (alpha-opaque) fails on
> > the second due to a kind of busy waiting in subtest preparation (the
> > subtest fails before actually running).
> > 
> > In addition, in the same test, the dpms subtest started to fail since
> > the commit that change from wait_for_vblanks to wait_for_flip_done. By
> > reverting this commit, the dpms subtest passes again and the sequential
> > subtests return to normal.
> > 
> > I am trying to figure out what's missing from using flip_done op on
> > vkms, since I am also interested in solving this problem and I
> > understand that the change for flip_done has been discussed in the past.
> > 
> > Do you have any idea?
> 
> Uh, not at all. This is indeed rather surprising ...
> 
> What exactly is the failure mode when running a test the 2nd time? Full
> igt logs might give me an idea. But yeah this is kinda surprising.

Hi Daniel,

This is the IGT log of the 2nd run of kms_cursor_crc/alpha-opaque:

IGT-Version: 1.25-NO-GIT (x86_64) (Linux: 5.8.0-rc2-DRM+ x86_64)
Force option used: Using driver vkms
Starting subtest: pipe-A-cursor-alpha-opaque
Timed out: Opening crc fd, and poll for first CRC.
Subtest pipe-A-cursor-alpha-opaque failed.
 DEBUG 
(kms_cursor_crc:2317) igt_kms-DEBUG: display: Virtual-1: set_pipe(A)
(kms_cursor_crc:2317) igt_kms-DEBUG: display: Virtual-1: Selecting pipe A
(kms_cursor_crc:2317) igt_fb-DEBUG: igt_create_fb_with_bo_size(width=1024, 
height=768, format=XR24(0x34325258), modifier=0x0, size=0)
(kms_cursor_crc:2317) igt_fb-DEBUG: igt_create_fb_with_bo_size(handle=1, 
pitch=4096)
(kms_cursor_crc:2317) igt_fb-DEBUG: Test requirement passed: 
cairo_surface_status(fb->cairo_surface) == CAIRO_STATUS_SUCCESS
(kms_cursor_crc:2317) igt_fb-DEBUG: igt_create_fb_with_bo_size(width=1024, 
height=768, format=XR24(0x34325258), modifier=0x0, size=0)
(kms_cursor_crc:2317) igt_fb-DEBUG: igt_create_fb_with_bo_size(handle=2, 
pitch=4096)
(kms_cursor_crc:2317) igt_fb-DEBUG: Test requirement passed: 
cairo_surface_status(fb->cairo_surface) == CAIRO_STATUS_SUCCESS
(kms_cursor_crc:2317) igt_kms-DEBUG: Test requirement passed: plane_idx >= 0 && 
plane_idx < pipe->n_planes
(kms_cursor_crc:2317) igt_kms-DEBUG: Test requirement passed: plane_idx >= 0 && 
plane_idx < pipe->n_planes
(kms_cursor_crc:2317) igt_kms-DEBUG: display: A.0: plane_set_fb(37)
(kms_cursor_crc:2317) igt_kms-DEBUG: display: A.0: plane_set_size (1024x768)
(kms_cursor_crc:2317) igt_kms-DEBUG: display: A.0: fb_set_position(0,0)
(kms_cursor_crc:2317) igt_kms-DEBUG: display: A.0: fb_set_size(1024x768)
(kms_cursor_crc:2317) igt_kms-DEBUG: display: commit {
(kms_cursor_crc:2317) igt_kms-DEBUG: display: Virtual-1: SetCrtc pipe A, fb 
37, src (0, 0), mode 1024x768
(k

Re: [PATCH] drm/vkms: add wait_for_vblanks in atomic_commit_tail

[Melissa Wen]

On Tue, Jul 14, 2020 at 7:20 AM Melissa Wen  wrote:
>
> On 07/13, Daniel Vetter wrote:
> > On Fri, Jul 10, 2020 at 02:05:33PM -0300, Melissa Wen wrote:
> > > On 07/02, Daniel Vetter wrote:
> > > > On Wed, Jul 01, 2020 at 03:31:34PM +, Sidong Yang wrote:
> > > > > there is an error when igt test is run continuously. 
> > > > > vkms_atomic_commit_tail()
> > > > > need to call drm_atomic_helper_wait_for_vblanks() for give up 
> > > > > ownership of
> > > > > vblank events. without this code, next atomic commit will not enable 
> > > > > vblank
> > > > > and raise timeout error.
> > > > >
> > > > > Signed-off-by: Sidong Yang 
> > > > > ---
> > > > >  drivers/gpu/drm/vkms/vkms_drv.c | 2 ++
> > > > >  1 file changed, 2 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c 
> > > > > b/drivers/gpu/drm/vkms/vkms_drv.c
> > > > > index 1e8b2169d834..10b9be67a068 100644
> > > > > --- a/drivers/gpu/drm/vkms/vkms_drv.c
> > > > > +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> > > > > @@ -93,6 +93,8 @@ static void vkms_atomic_commit_tail(struct 
> > > > > drm_atomic_state *old_state)
> > > > > flush_work(_state->composer_work);
> > > > > }
> > > > >
> > > > > +   drm_atomic_helper_wait_for_vblanks(dev, old_state);
> > > >
> > > > Uh, we have a wait_for_flip_done right above, which should be doing
> > > > exactly the same, but more precisely: Instead of just waiting for any
> > > > vblank to happen, we wait for exactly the vblank corresponding to this
> > > > atomic commit. So no races possible. If this is papering over some 
> > > > issue,
> > > > then I think more debugging is needed.
> > > >
> > > > What exactly is going wrong here for you?
> > >
> > > Hi Daniel and Sidong,
> > >
> > > I noticed a similar issue when running the IGT test kms_cursor_crc. For
> > > example, a subtest that passes on the first run (alpha-opaque) fails on
> > > the second due to a kind of busy waiting in subtest preparation (the
> > > subtest fails before actually running).
> > >
> > > In addition, in the same test, the dpms subtest started to fail since
> > > the commit that change from wait_for_vblanks to wait_for_flip_done. By
> > > reverting this commit, the dpms subtest passes again and the sequential
> > > subtests return to normal.
> > >
> > > I am trying to figure out what's missing from using flip_done op on
> > > vkms, since I am also interested in solving this problem and I
> > > understand that the change for flip_done has been discussed in the past.
> > >
> > > Do you have any idea?
> >
> > Uh, not at all. This is indeed rather surprising ...
> >
> > What exactly is the failure mode when running a test the 2nd time? Full
> > igt logs might give me an idea. But yeah this is kinda surprising.
>
> Hi Daniel,
>
> This is the IGT log of the 2nd run of kms_cursor_crc/alpha-opaque:
>
> IGT-Version: 1.25-NO-GIT (x86_64) (Linux: 5.8.0-rc2-DRM+ x86_64)
> Force option used: Using driver vkms
> Starting subtest: pipe-A-cursor-alpha-opaque
> Timed out: Opening crc fd, and poll for first CRC.
> Subtest pipe-A-cursor-alpha-opaque failed.
>  DEBUG 
> (kms_cursor_crc:2317) igt_kms-DEBUG: display: Virtual-1: set_pipe(A)
> (kms_cursor_crc:2317) igt_kms-DEBUG: display: Virtual-1: Selecting pipe A
> (kms_cursor_crc:2317) igt_fb-DEBUG: igt_create_fb_with_bo_size(width=1024, 
> height=768, format=XR24(0x34325258), modifier=0x0, size=0)
> (kms_cursor_crc:2317) igt_fb-DEBUG: igt_create_fb_with_bo_size(handle=1, 
> pitch=4096)
> (kms_cursor_crc:2317) igt_fb-DEBUG: Test requirement passed: 
> cairo_surface_status(fb->cairo_surface) == CAIRO_STATUS_SUCCESS
> (kms_cursor_crc:2317) igt_fb-DEBUG: igt_create_fb_with_bo_size(width=1024, 
> height=768, format=XR24(0x34325258), modifier=0x0, size=0)
> (kms_cursor_crc:2317) igt_fb-DEBUG: igt_create_fb_with_bo_size(handle=2, 
> pitch=4096)
> (kms_cursor_crc:2317) igt_fb-DEBUG: Test requirement passed: 
> cairo_surface_status(fb->cairo_surface) == CAIRO_STATUS_SUCCESS
> (kms_cursor_crc:2317) igt_kms-DEBUG: Test requirement passed: plane_idx >= 0 
> && plane_idx < pipe->n_planes
> (kms_cursor_crc:2317) igt_kms-DEBUG: Test requirement passed: plane_idx >= 0 

Re: [PATCH 04/25] drm/vkms: Annotate vblank timer

[Melissa Wen]

On 07/12, Rodrigo Siqueira wrote:
> Hi,
> 
> Everything looks fine to me, I just noticed that the amdgpu patches did
> not apply smoothly, however it was trivial to fix the issues.
> 
> Reviewed-by: Rodrigo Siqueira 
> 
> Melissa,
> Since you are using vkms regularly, could you test this patch and review
> it? Remember to add your Tested-by when you finish.
>
Hi,

I've applied the patch series, ran some tests on vkms, and found no
issues. I mean, things have remained stable.

Tested-by: Melissa Wen 

> Thanks
> 
> On 07/07, Daniel Vetter wrote:
> > This is needed to signal the fences from page flips, annotate it
> > accordingly. We need to annotate entire timer callback since if we get
> > stuck anywhere in there, then the timer stops, and hence fences stop.
> > Just annotating the top part that does the vblank handling isn't
> > enough.
> > 
> > Cc: linux-me...@vger.kernel.org
> > Cc: linaro-mm-...@lists.linaro.org
> > Cc: linux-r...@vger.kernel.org
> > Cc: amd-...@lists.freedesktop.org
> > Cc: intel-...@lists.freedesktop.org
> > Cc: Chris Wilson 
> > Cc: Maarten Lankhorst 
> > Cc: Christian König 
> > Signed-off-by: Daniel Vetter 
> > Cc: Rodrigo Siqueira 
> > Cc: Haneen Mohammed 
> > Cc: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/vkms/vkms_crtc.c | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c 
> > b/drivers/gpu/drm/vkms/vkms_crtc.c
> > index ac85e17428f8..a53a40848a72 100644
> > --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> > @@ -1,5 +1,7 @@
> >  // SPDX-License-Identifier: GPL-2.0+
> >  
> > +#include 
> > +
> >  #include 
> >  #include 
> >  #include 
> > @@ -14,7 +16,9 @@ static enum hrtimer_restart vkms_vblank_simulate(struct 
> > hrtimer *timer)
> > struct drm_crtc *crtc = >crtc;
> > struct vkms_crtc_state *state;
> > u64 ret_overrun;
> > -   bool ret;
> > +   bool ret, fence_cookie;
> > +
> > +   fence_cookie = dma_fence_begin_signalling();
> >  
> > ret_overrun = hrtimer_forward_now(>vblank_hrtimer,
> >   output->period_ns);
> > @@ -49,6 +53,8 @@ static enum hrtimer_restart vkms_vblank_simulate(struct 
> > hrtimer *timer)
> > DRM_DEBUG_DRIVER("Composer worker already queued\n");
> > }
> >  
> > +   dma_fence_end_signalling(fence_cookie);
> > +
> > return HRTIMER_RESTART;
> >  }
> >  
> > -- 
> > 2.27.0
> > 
> 
> -- 
> Rodrigo Siqueira
> https://siqueira.tech


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 04/25] drm/vkms: Annotate vblank timer

[Melissa Wen]

Hi,

On 07/14, Daniel Vetter wrote:
> On Tue, Jul 14, 2020 at 11:57 AM Melissa Wen  wrote:
> >
> > On 07/12, Rodrigo Siqueira wrote:
> > > Hi,
> > >
> > > Everything looks fine to me, I just noticed that the amdgpu patches did
> > > not apply smoothly, however it was trivial to fix the issues.
> > >
> > > Reviewed-by: Rodrigo Siqueira 
> > >
> > > Melissa,
> > > Since you are using vkms regularly, could you test this patch and review
> > > it? Remember to add your Tested-by when you finish.
> > >
> > Hi,
> >
> > I've applied the patch series, ran some tests on vkms, and found no
> > issues. I mean, things have remained stable.
> >
> > Tested-by: Melissa Wen 
> 
> Did you test with CONFIG_PROVE_LOCKING enabled in the kernel .config?
> Without that enabled, there's not really any change here, but with
> that enabled there might be some lockdep splats in dmesg indicating a
> problem.
>

Even with the lock debugging config enabled, no new issue arose in dmesg
during my tests using vkms.

Melissa

> Thanks, Daniel
> >
> > > Thanks
> > >
> > > On 07/07, Daniel Vetter wrote:
> > > > This is needed to signal the fences from page flips, annotate it
> > > > accordingly. We need to annotate entire timer callback since if we get
> > > > stuck anywhere in there, then the timer stops, and hence fences stop.
> > > > Just annotating the top part that does the vblank handling isn't
> > > > enough.
> > > >
> > > > Cc: linux-me...@vger.kernel.org
> > > > Cc: linaro-mm-...@lists.linaro.org
> > > > Cc: linux-r...@vger.kernel.org
> > > > Cc: amd-...@lists.freedesktop.org
> > > > Cc: intel-...@lists.freedesktop.org
> > > > Cc: Chris Wilson 
> > > > Cc: Maarten Lankhorst 
> > > > Cc: Christian König 
> > > > Signed-off-by: Daniel Vetter 
> > > > Cc: Rodrigo Siqueira 
> > > > Cc: Haneen Mohammed 
> > > > Cc: Daniel Vetter 
> > > > ---
> > > >  drivers/gpu/drm/vkms/vkms_crtc.c | 8 +++-
> > > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c 
> > > > b/drivers/gpu/drm/vkms/vkms_crtc.c
> > > > index ac85e17428f8..a53a40848a72 100644
> > > > --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> > > > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> > > > @@ -1,5 +1,7 @@
> > > >  // SPDX-License-Identifier: GPL-2.0+
> > > >
> > > > +#include 
> > > > +
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > @@ -14,7 +16,9 @@ static enum hrtimer_restart 
> > > > vkms_vblank_simulate(struct hrtimer *timer)
> > > > struct drm_crtc *crtc = >crtc;
> > > > struct vkms_crtc_state *state;
> > > > u64 ret_overrun;
> > > > -   bool ret;
> > > > +   bool ret, fence_cookie;
> > > > +
> > > > +   fence_cookie = dma_fence_begin_signalling();
> > > >
> > > > ret_overrun = hrtimer_forward_now(>vblank_hrtimer,
> > > >   output->period_ns);
> > > > @@ -49,6 +53,8 @@ static enum hrtimer_restart 
> > > > vkms_vblank_simulate(struct hrtimer *timer)
> > > > DRM_DEBUG_DRIVER("Composer worker already 
> > > > queued\n");
> > > > }
> > > >
> > > > +   dma_fence_end_signalling(fence_cookie);
> > > > +
> > > > return HRTIMER_RESTART;
> > > >  }
> > > >
> > > > --
> > > > 2.27.0
> > > >
> > >
> > > --
> > > Rodrigo Siqueira
> > > https://siqueira.tech
> >
> >
> 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vkms: add wait_for_vblanks in atomic_commit_tail

[Melissa Wen]

On 07/14, Daniel Vetter wrote:
> On Tue, Jul 14, 2020 at 07:39:42AM -0300, Melissa Wen wrote:
> > On Tue, Jul 14, 2020 at 7:20 AM Melissa Wen  wrote:
> > >
> > > On 07/13, Daniel Vetter wrote:
> > > > On Fri, Jul 10, 2020 at 02:05:33PM -0300, Melissa Wen wrote:
> > > > > On 07/02, Daniel Vetter wrote:
> > > > > > On Wed, Jul 01, 2020 at 03:31:34PM +, Sidong Yang wrote:
> > > > > > > there is an error when igt test is run continuously. 
> > > > > > > vkms_atomic_commit_tail()
> > > > > > > need to call drm_atomic_helper_wait_for_vblanks() for give up 
> > > > > > > ownership of
> > > > > > > vblank events. without this code, next atomic commit will not 
> > > > > > > enable vblank
> > > > > > > and raise timeout error.
> > > > > > >
> > > > > > > Signed-off-by: Sidong Yang 
> > > > > > > ---
> > > > > > >  drivers/gpu/drm/vkms/vkms_drv.c | 2 ++
> > > > > > >  1 file changed, 2 insertions(+)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c 
> > > > > > > b/drivers/gpu/drm/vkms/vkms_drv.c
> > > > > > > index 1e8b2169d834..10b9be67a068 100644
> > > > > > > --- a/drivers/gpu/drm/vkms/vkms_drv.c
> > > > > > > +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> > > > > > > @@ -93,6 +93,8 @@ static void vkms_atomic_commit_tail(struct 
> > > > > > > drm_atomic_state *old_state)
> > > > > > > flush_work(_state->composer_work);
> > > > > > > }
> > > > > > >
> > > > > > > +   drm_atomic_helper_wait_for_vblanks(dev, old_state);
> > > > > >
> > > > > > Uh, we have a wait_for_flip_done right above, which should be doing
> > > > > > exactly the same, but more precisely: Instead of just waiting for 
> > > > > > any
> > > > > > vblank to happen, we wait for exactly the vblank corresponding to 
> > > > > > this
> > > > > > atomic commit. So no races possible. If this is papering over some 
> > > > > > issue,
> > > > > > then I think more debugging is needed.
> > > > > >
> > > > > > What exactly is going wrong here for you?
> > > > >
> > > > > Hi Daniel and Sidong,
> > > > >
> > > > > I noticed a similar issue when running the IGT test kms_cursor_crc. 
> > > > > For
> > > > > example, a subtest that passes on the first run (alpha-opaque) fails 
> > > > > on
> > > > > the second due to a kind of busy waiting in subtest preparation (the
> > > > > subtest fails before actually running).
> > > > >
> > > > > In addition, in the same test, the dpms subtest started to fail since
> > > > > the commit that change from wait_for_vblanks to wait_for_flip_done. By
> > > > > reverting this commit, the dpms subtest passes again and the 
> > > > > sequential
> > > > > subtests return to normal.
> > > > >
> > > > > I am trying to figure out what's missing from using flip_done op on
> > > > > vkms, since I am also interested in solving this problem and I
> > > > > understand that the change for flip_done has been discussed in the 
> > > > > past.
> > > > >
> > > > > Do you have any idea?
> > > >
> > > > Uh, not at all. This is indeed rather surprising ...
> > > >
> > > > What exactly is the failure mode when running a test the 2nd time? Full
> > > > igt logs might give me an idea. But yeah this is kinda surprising.
> > >
> > > Hi Daniel,
> > >
> > > This is the IGT log of the 2nd run of kms_cursor_crc/alpha-opaque:
> > >
> > > IGT-Version: 1.25-NO-GIT (x86_64) (Linux: 5.8.0-rc2-DRM+ x86_64)
> > > Force option used: Using driver vkms
> > > Starting subtest: pipe-A-cursor-alpha-opaque
> > > Timed out: Opening crc fd, and poll for first CRC.
> > > Subtest pipe-A-cursor-alpha-opaque failed.
> > >  DEBUG 
> > > (kms_cursor_crc:2317) igt_kms-DEBUG: display: Virtual-1: set_pipe(A)
> > > (kms_cursor_crc:2317) igt_kms-DEBUG: display: Virt

Re: [PATCH] drm/vkms: add wait_for_vblanks in atomic_commit_tail

[Melissa Wen]

On 07/15, Sidong Yang wrote:
> On Wed, Jul 15, 2020 at 10:17:56AM +0200, Daniel Vetter wrote:
> > On Tue, Jul 14, 2020 at 9:01 PM Melissa Wen  wrote:
> > >
> > > On 07/14, Daniel Vetter wrote:
> > > > On Tue, Jul 14, 2020 at 07:39:42AM -0300, Melissa Wen wrote:
> > > > > On Tue, Jul 14, 2020 at 7:20 AM Melissa Wen  
> > > > > wrote:
> > > > > >
> > > > > > On 07/13, Daniel Vetter wrote:
> > > > > > > On Fri, Jul 10, 2020 at 02:05:33PM -0300, Melissa Wen wrote:
> > > > > > > > On 07/02, Daniel Vetter wrote:
> > > > > > > > > On Wed, Jul 01, 2020 at 03:31:34PM +, Sidong Yang wrote:
> > > > > > > > > > there is an error when igt test is run continuously. 
> > > > > > > > > > vkms_atomic_commit_tail()
> > > > > > > > > > need to call drm_atomic_helper_wait_for_vblanks() for give 
> > > > > > > > > > up ownership of
> > > > > > > > > > vblank events. without this code, next atomic commit will 
> > > > > > > > > > not enable vblank
> > > > > > > > > > and raise timeout error.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Sidong Yang 
> > > > > > > > > > ---
> > > > > > > > > >  drivers/gpu/drm/vkms/vkms_drv.c | 2 ++
> > > > > > > > > >  1 file changed, 2 insertions(+)
> > > > > > > > > >
> > > > > > > > > > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c 
> > > > > > > > > > b/drivers/gpu/drm/vkms/vkms_drv.c
> > > > > > > > > > index 1e8b2169d834..10b9be67a068 100644
> > > > > > > > > > --- a/drivers/gpu/drm/vkms/vkms_drv.c
> > > > > > > > > > +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> > > > > > > > > > @@ -93,6 +93,8 @@ static void 
> > > > > > > > > > vkms_atomic_commit_tail(struct drm_atomic_state *old_state)
> > > > > > > > > > flush_work(_state->composer_work);
> > > > > > > > > > }
> > > > > > > > > >
> > > > > > > > > > +   drm_atomic_helper_wait_for_vblanks(dev, old_state);
> > > > > > > > >
> > > > > > > > > Uh, we have a wait_for_flip_done right above, which should be 
> > > > > > > > > doing
> > > > > > > > > exactly the same, but more precisely: Instead of just waiting 
> > > > > > > > > for any
> > > > > > > > > vblank to happen, we wait for exactly the vblank 
> > > > > > > > > corresponding to this
> > > > > > > > > atomic commit. So no races possible. If this is papering over 
> > > > > > > > > some issue,
> > > > > > > > > then I think more debugging is needed.
> > > > > > > > >
> > > > > > > > > What exactly is going wrong here for you?
> > > > > > > >
> > > > > > > > Hi Daniel and Sidong,
> > > > > > > >
> > > > > > > > I noticed a similar issue when running the IGT test 
> > > > > > > > kms_cursor_crc. For
> > > > > > > > example, a subtest that passes on the first run (alpha-opaque) 
> > > > > > > > fails on
> > > > > > > > the second due to a kind of busy waiting in subtest preparation 
> > > > > > > > (the
> > > > > > > > subtest fails before actually running).
> > > > > > > >
> > > > > > > > In addition, in the same test, the dpms subtest started to fail 
> > > > > > > > since
> > > > > > > > the commit that change from wait_for_vblanks to 
> > > > > > > > wait_for_flip_done. By
> > > > > > > > reverting this commit, the dpms subtest passes again and the 
> > > > > > > > sequential
> > > > > > > > subtests return to normal.
> > > > > > > >
> > > > > > > > I am trying to figure 

Re: [PATCH] drm/vkms: add wait_for_vblanks in atomic_commit_tail

[Melissa Wen]

On 07/02, Daniel Vetter wrote:
> On Wed, Jul 01, 2020 at 03:31:34PM +, Sidong Yang wrote:
> > there is an error when igt test is run continuously. 
> > vkms_atomic_commit_tail()
> > need to call drm_atomic_helper_wait_for_vblanks() for give up ownership of
> > vblank events. without this code, next atomic commit will not enable vblank
> > and raise timeout error.
> > 
> > Signed-off-by: Sidong Yang 
> > ---
> >  drivers/gpu/drm/vkms/vkms_drv.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c 
> > b/drivers/gpu/drm/vkms/vkms_drv.c
> > index 1e8b2169d834..10b9be67a068 100644
> > --- a/drivers/gpu/drm/vkms/vkms_drv.c
> > +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> > @@ -93,6 +93,8 @@ static void vkms_atomic_commit_tail(struct 
> > drm_atomic_state *old_state)
> > flush_work(_state->composer_work);
> > }
> >  
> > +   drm_atomic_helper_wait_for_vblanks(dev, old_state);
> 
> Uh, we have a wait_for_flip_done right above, which should be doing
> exactly the same, but more precisely: Instead of just waiting for any
> vblank to happen, we wait for exactly the vblank corresponding to this
> atomic commit. So no races possible. If this is papering over some issue,
> then I think more debugging is needed.
> 
> What exactly is going wrong here for you?

Hi Daniel and Sidong,

I noticed a similar issue when running the IGT test kms_cursor_crc. For
example, a subtest that passes on the first run (alpha-opaque) fails on
the second due to a kind of busy waiting in subtest preparation (the
subtest fails before actually running).

In addition, in the same test, the dpms subtest started to fail since
the commit that change from wait_for_vblanks to wait_for_flip_done. By
reverting this commit, the dpms subtest passes again and the sequential
subtests return to normal.

I am trying to figure out what's missing from using flip_done op on
vkms, since I am also interested in solving this problem and I
understand that the change for flip_done has been discussed in the past.

Do you have any idea?

Melissa

> -Daniel
> 
> > +
> > drm_atomic_helper_cleanup_planes(dev, old_state);
> >  }
> >  
> > -- 
> > 2.17.1
> > 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vkms: add missing drm_crtc_vblank_put to the get/put pair on flush

[Melissa Wen]

On 07/25, Daniel Vetter wrote:
> On Sat, Jul 25, 2020 at 5:12 AM Sidong Yang  wrote:
> >
> > On Wed, Jul 22, 2020 at 05:17:05PM +0200, Daniel Vetter wrote:
> > > On Wed, Jul 22, 2020 at 4:06 PM Melissa Wen  wrote:
> > > >
> > > > On 07/22, dan...@ffwll.ch wrote:
> > > > > On Wed, Jul 22, 2020 at 08:04:11AM -0300, Melissa Wen wrote:
> > > > > > This patch adds a missing drm_crtc_vblank_put op to the pair
> > > > > > drm_crtc_vblank_get/put (inc/decrement counter to guarantee 
> > > > > > vblanks).
> > > > > >
> > > > > > It clears the execution of the following kms_cursor_crc subtests:
> > > > > > 1. pipe-A-cursor-[size,alpha-opaque, NxN-(on-screen, off-screen, 
> > > > > > sliding,
> > > > > >random, fast-moving])] - successful when running individually.
> > > > > > 2. pipe-A-cursor-dpms passes again
> > > > > > 3. pipe-A-cursor-suspend also passes
> > > > > >
> > > > > > The issue was initially tracked in the sequential execution of IGT
> > > > > > kms_cursor_crc subtest: when running the test sequence or one of its
> > > > > > subtests twice, the odd execs complete and the pairs get stuck in an
> > > > > > endless wait. In the IGT code, calling a wait_for_vblank before the 
> > > > > > start
> > > > > > of CRC capture prevented the busy-wait. But the problem persisted 
> > > > > > in the
> > > > > > pipe-A-cursor-dpms and -suspend subtests.
> > > > > >
> > > > > > Checking the history, the pipe-A-cursor-dpms subtest was successful 
> > > > > > when,
> > > > > > in vkms_atomic_commit_tail, instead of using the flip_done op, it 
> > > > > > used
> > > > > > wait_for_vblanks. Another way to prevent blocking was 
> > > > > > wait_one_vblank when
> > > > > > enabling crtc. However, in both cases, pipe-A-cursor-suspend 
> > > > > > persisted
> > > > > > blocking in the 2nd start of CRC capture, which may indicate that
> > > > > > something got stuck in the step of CRC setup. Indeed, 
> > > > > > wait_one_vblank in
> > > > > > the crc setup was able to sync things and free all kms_cursor_crc
> > > > > > subtests.
> > > > > >
> > > > > > Tracing and comparing a clean run with a blocked one:
> > > > > > - in a clean one, vkms_crtc_atomic_flush enables vblanks;
> > > > > > - when blocked, only in next op, vkms_crtc_atomic_enable, the 
> > > > > > vblanks
> > > > > > started. Moreover, a series of vkms_vblank_simulate flow out until
> > > > > > disabling vblanks.
> > > > > > Also watching the steps of vkms_crtc_atomic_flush, when the very 
> > > > > > first
> > > > > > drm_crtc_vblank_get returned an error, the subtest crashed. On the 
> > > > > > other
> > > > > > hand, when vblank_get succeeded, the subtest completed. Finally, 
> > > > > > checking
> > > > > > the flush steps: it increases counter to hold a vblank reference 
> > > > > > (get),
> > > > > > but there isn't a op to decreased it and release vblanks (put).
> > > > > >
> > > > > > Cc: Daniel Vetter 
> > > > > > Cc: Rodrigo Siqueira 
> > > > > > Cc: Haneen Mohammed 
> > > > > > Signed-off-by: Melissa Wen 
> > > > > > ---
> > > > > >  drivers/gpu/drm/vkms/vkms_crtc.c | 1 +
> > > > > >  1 file changed, 1 insertion(+)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c 
> > > > > > b/drivers/gpu/drm/vkms/vkms_crtc.c
> > > > > > index ac85e17428f8..a99d6b4a92dd 100644
> > > > > > --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> > > > > > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> > > > > > @@ -246,6 +246,7 @@ static void vkms_crtc_atomic_flush(struct 
> > > > > > drm_crtc *crtc,
> > > > > >
> > > > > > spin_unlock(>dev->event_lock);
> > > > > >
> > > > > > +   drm_crtc_vblank_put(crtc);
> > > > >
> &

Re: [PATCH] drm/vkms: add missing drm_crtc_vblank_put to the get/put pair on flush

[Melissa Wen]

On 07/25, Daniel Vetter wrote:
> On Sat, Jul 25, 2020 at 7:45 PM Melissa Wen  wrote:
> >
> > On 07/25, Daniel Vetter wrote:
> > > On Sat, Jul 25, 2020 at 5:12 AM Sidong Yang  wrote:
> > > >
> > > > On Wed, Jul 22, 2020 at 05:17:05PM +0200, Daniel Vetter wrote:
> > > > > On Wed, Jul 22, 2020 at 4:06 PM Melissa Wen  
> > > > > wrote:
> > > > > >
> > > > > > On 07/22, dan...@ffwll.ch wrote:
> > > > > > > On Wed, Jul 22, 2020 at 08:04:11AM -0300, Melissa Wen wrote:
> > > > > > > > This patch adds a missing drm_crtc_vblank_put op to the pair
> > > > > > > > drm_crtc_vblank_get/put (inc/decrement counter to guarantee 
> > > > > > > > vblanks).
> > > > > > > >
> > > > > > > > It clears the execution of the following kms_cursor_crc 
> > > > > > > > subtests:
> > > > > > > > 1. pipe-A-cursor-[size,alpha-opaque, NxN-(on-screen, 
> > > > > > > > off-screen, sliding,
> > > > > > > >random, fast-moving])] - successful when running 
> > > > > > > > individually.
> > > > > > > > 2. pipe-A-cursor-dpms passes again
> > > > > > > > 3. pipe-A-cursor-suspend also passes
> > > > > > > >
> > > > > > > > The issue was initially tracked in the sequential execution of 
> > > > > > > > IGT
> > > > > > > > kms_cursor_crc subtest: when running the test sequence or one 
> > > > > > > > of its
> > > > > > > > subtests twice, the odd execs complete and the pairs get stuck 
> > > > > > > > in an
> > > > > > > > endless wait. In the IGT code, calling a wait_for_vblank before 
> > > > > > > > the start
> > > > > > > > of CRC capture prevented the busy-wait. But the problem 
> > > > > > > > persisted in the
> > > > > > > > pipe-A-cursor-dpms and -suspend subtests.
> > > > > > > >
> > > > > > > > Checking the history, the pipe-A-cursor-dpms subtest was 
> > > > > > > > successful when,
> > > > > > > > in vkms_atomic_commit_tail, instead of using the flip_done op, 
> > > > > > > > it used
> > > > > > > > wait_for_vblanks. Another way to prevent blocking was 
> > > > > > > > wait_one_vblank when
> > > > > > > > enabling crtc. However, in both cases, pipe-A-cursor-suspend 
> > > > > > > > persisted
> > > > > > > > blocking in the 2nd start of CRC capture, which may indicate 
> > > > > > > > that
> > > > > > > > something got stuck in the step of CRC setup. Indeed, 
> > > > > > > > wait_one_vblank in
> > > > > > > > the crc setup was able to sync things and free all 
> > > > > > > > kms_cursor_crc
> > > > > > > > subtests.
> > > > > > > >
> > > > > > > > Tracing and comparing a clean run with a blocked one:
> > > > > > > > - in a clean one, vkms_crtc_atomic_flush enables vblanks;
> > > > > > > > - when blocked, only in next op, vkms_crtc_atomic_enable, the 
> > > > > > > > vblanks
> > > > > > > > started. Moreover, a series of vkms_vblank_simulate flow out 
> > > > > > > > until
> > > > > > > > disabling vblanks.
> > > > > > > > Also watching the steps of vkms_crtc_atomic_flush, when the 
> > > > > > > > very first
> > > > > > > > drm_crtc_vblank_get returned an error, the subtest crashed. On 
> > > > > > > > the other
> > > > > > > > hand, when vblank_get succeeded, the subtest completed. 
> > > > > > > > Finally, checking
> > > > > > > > the flush steps: it increases counter to hold a vblank 
> > > > > > > > reference (get),
> > > > > > > > but there isn't a op to decreased it and release vblanks (put).
> > > > > > > >
> > > > > > > > Cc: Daniel Vetter 
> > > > > > > > Cc: Rodrigo Siqueira 
>

Re: [PATCH] drm/vkms: add missing drm_crtc_vblank_put to the get/put pair on flush

[Melissa Wen]

> No, this very first warning continues (only once) :(
> From here (drm_crtc_vblank_on):
> if (atomic_read(>refcount) != 0 || drm_vblank_offdelay == 0)
> drm_WARN_ON(dev, drm_vblank_enable(dev, pipe));

Sorry, not sure when this warning is triggered.

>
> > But I'm still wondering why after step 3 we don't get -EINVAL from
> > vblank_get() - after vblank_off() vblank->enabled should be false
> > again, getting us back to the same state as after 1. Is that not
> > happening?
>
> Yes (sorry if it got confused), we got -EINVAL after setp 3:
>
> In step 3, at the end of the 2nd running, we have:
> atomic_disable
> --> vblank_off [!vblank->inmodeset + refcount going 0->1 + inmodeset=1]
> and then in next vblank_get: -EINVAL (!vblank->enabled + refcount ends 1)
> as in the first step.
>
> Melissa
>
> > -Daniel
> >
> > >
> > > > >
> > > > > Thanks
> > > > > -Sidong
> > > > >
> > > > > > > >
> > > > > > > > > crtc->state->event = NULL;
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > 2.27.0
> > > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Daniel Vetter
> > > > > > > > Software Engineer, Intel Corporation
> > > > > > > > http://blog.ffwll.ch
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Daniel Vetter
> > > > > > Software Engineer, Intel Corporation
> > > > > > http://blog.ffwll.ch
> > > > > > ___
> > > > > > dri-devel mailing list
> > > > > > dri-devel@lists.freedesktop.org
> > > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > >
> > > >
> > > >
> > > > --
> > > > Daniel Vetter
> > > > Software Engineer, Intel Corporation
> > > > http://blog.ffwll.ch
> >
> >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vkms: add missing drm_crtc_vblank_put to the get/put pair on flush

[Melissa Wen]

On Sat, Jul 25, 2020 at 4:19 PM Melissa Wen  wrote:
>
> > No, this very first warning continues (only once) :(
> > From here (drm_crtc_vblank_on):
> > if (atomic_read(>refcount) != 0 || drm_vblank_offdelay == 0)
> > drm_WARN_ON(dev, drm_vblank_enable(dev, pipe));
>
> Sorry, not sure when this warning is triggered.

Again, I just had to look at the trace:
[   52.299388]  drm_get_last_vbltimestamp+0xaa/0xc0 [drm]
[   52.299389]  drm_reset_vblank_timestamp+0x5b/0xd0 [drm]
[   52.299389]  drm_crtc_vblank_on.cold+0x37/0x103 [drm]
[   52.299390]  drm_atomic_helper_commit_modeset_enable

>
> >
> > > But I'm still wondering why after step 3 we don't get -EINVAL from
> > > vblank_get() - after vblank_off() vblank->enabled should be false
> > > again, getting us back to the same state as after 1. Is that not
> > > happening?
> >
> > Yes (sorry if it got confused), we got -EINVAL after setp 3:
> >
> > In step 3, at the end of the 2nd running, we have:
> > atomic_disable
> > --> vblank_off [!vblank->inmodeset + refcount going 0->1 + inmodeset=1]
> > and then in next vblank_get: -EINVAL (!vblank->enabled + refcount ends 1)
> > as in the first step.
> >
> > Melissa
> >
> > > -Daniel
> > >
> > > >
> > > > > >
> > > > > > Thanks
> > > > > > -Sidong
> > > > > >
> > > > > > > > >
> > > > > > > > > > crtc->state->event = NULL;
> > > > > > > > > > }
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > 2.27.0
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Daniel Vetter
> > > > > > > > > Software Engineer, Intel Corporation
> > > > > > > > > http://blog.ffwll.ch
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Daniel Vetter
> > > > > > > Software Engineer, Intel Corporation
> > > > > > > http://blog.ffwll.ch
> > > > > > > ___
> > > > > > > dri-devel mailing list
> > > > > > > dri-devel@lists.freedesktop.org
> > > > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Daniel Vetter
> > > > > Software Engineer, Intel Corporation
> > > > > http://blog.ffwll.ch
> > >
> > >
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vkms: add wait_for_vblanks in atomic_commit_tail

[Melissa Wen]

Hi all,

I traced the subtests' execution to figure out what happens (or not) in
a clean run and a blocked run, and this led me to suspect the
vkms_crtc_atomic_flush function. Examining the code and considering the
DRM doc, it seemed to me that a drm_crtc_vblank_get call was missing a
drm_crtc_vblank_put pair. So I checked it that way, and again, the
problem of sequential execution + dpms/suspend failures disappeared.

diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index ac85e17428f8..f60bf1495306 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -240,30 +240,31 @@ static void vkms_crtc_atomic_flush(struct drm_crtc *crtc,
spin_lock(>dev->event_lock);

if (drm_crtc_vblank_get(crtc) != 0)
drm_crtc_send_vblank_event(crtc, crtc->state->event);
else
drm_crtc_arm_vblank_event(crtc, crtc->state->event);

spin_unlock(>dev->event_lock);

crtc->state->event = NULL;
}

vkms_output->composer_state = to_vkms_crtc_state(crtc->state);

spin_unlock_irq(_output->lock);
+   drm_crtc_vblank_put(crtc);
 }

However, I'm not sure if it's just another duck-tape proposal or if it
makes any sense. I'm still investigating better, but I think sharing
with you may be more productive.

Melissa

On 07/21, Daniel Vetter wrote:
> On Tue, Jul 21, 2020 at 05:33:00AM +, Sidong Yang wrote:
> > Hi, Daniel and Melissa
> > 
> > I tested some code for this problem trying to find the code that make 
> > problem in igt test.
> > kms_cursor_crc test in igt test has 3 steps (preparation, test, cleanup). I 
> > check each steps
> > and I found that without cleanup step, the problem solved.
> > In cleanup step, igt test code seems like this.
> > 
> > drmModeSetCrtc(display->drm_fd, crtc_id, 0 /* fb_id */, 0, 
> > 0 /* x, y */, NULL /* connector */, 0, NULL /* mode */)
> > 
> > I commented out this function call and there is no problem in executing 
> > tests repeatedly.
> > I'm trying to find out what's happen in this call. but don't know until now
> > I hope this information help to solve the problem.
> 
> Ah yes that fits the evidence we have from Melissa pretty well: Not
> turning off the CRTC means the next test wont have to turn it back on
> again. And the vblank bug seems to be in the code which turns the crtc
> back on. At least inserting a vblank wait in there is enough to paper over
> all the issues, per Melissa's testing.
> 
> So at least we're now fairly confident where the bug is, that's some solid
> progress.
> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/vkms: fix xrgb on compute crc

[Melissa Wen]

The previous memset operation was not correctly zeroing the alpha
channel to compute the crc, and as a result, the IGT subtest
kms_cursor_crc/pipe-A-cursor-alpha-transparent fails.

Fixes: db7f419c06d7c ("drm/vkms: Compute CRC with Cursor Plane")

Signed-off-by: Melissa Wen 
---
 drivers/gpu/drm/vkms/vkms_composer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
b/drivers/gpu/drm/vkms/vkms_composer.c
index 4af2f19480f4..b8b060354667 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -33,7 +33,7 @@ static uint32_t compute_crc(void *vaddr_out, struct 
vkms_composer *composer)
 + (i * composer->pitch)
 + (j * composer->cpp);
/* XRGB format ignores Alpha channel */
-   memset(vaddr_out + src_offset + 24, 0,  8);
+   bitmap_clear(vaddr_out + src_offset, 24, 8);
crc = crc32_le(crc, vaddr_out + src_offset,
   sizeof(u32));
}
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V5 2/3] drm/vkms: Add support for writeback module

[Melissa Wen]

On 01/12, Sumera Priyadarsini wrote:
> Add enable_writeback feature to vkms_config as a module.
> 
> Signed-off-by: Sumera Priyadarsini 
> ---
>  drivers/gpu/drm/vkms/vkms_drv.c| 5 +
>  drivers/gpu/drm/vkms/vkms_drv.h| 1 +
>  drivers/gpu/drm/vkms/vkms_output.c | 9 ++---
>  3 files changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index 6b33975a5cb2..708f7f54001d 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -40,6 +40,10 @@ static bool enable_cursor = true;
>  module_param_named(enable_cursor, enable_cursor, bool, 0444);
>  MODULE_PARM_DESC(enable_cursor, "Enable/Disable cursor support");
>  
> +static bool enable_writeback = true;
> +module_param_named(enable_writeback, enable_writeback, bool, 0444);
> +MODULE_PARM_DESC(enable_writeback, "Enable/Disable writeback connector 
> support");
> +
>  DEFINE_DRM_GEM_FOPS(vkms_driver_fops);
>  
>  static void vkms_release(struct drm_device *dev)
> @@ -189,6 +193,7 @@ static int __init vkms_init(void)
>   default_config = config;
>  
>   config->cursor = enable_cursor;
> + config->writeback = enable_writeback;
>  
>   return vkms_create(config);
>  }
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 6a27bd8875f2..b9b4e2bc11c0 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -83,6 +83,7 @@ struct vkms_output {
>  struct vkms_device;
>  
>  struct vkms_config {
> + bool writeback;
>   bool cursor;
>   /* only set when instantiated */
>   struct vkms_device *dev;
> diff --git a/drivers/gpu/drm/vkms/vkms_output.c 
> b/drivers/gpu/drm/vkms/vkms_output.c
> index 8f3ffb28b9d1..f5f6f15c362c 100644
> --- a/drivers/gpu/drm/vkms/vkms_output.c
> +++ b/drivers/gpu/drm/vkms/vkms_output.c
> @@ -41,6 +41,7 @@ int vkms_output_init(struct vkms_device *vkmsdev, int index)
>   struct drm_crtc *crtc = >crtc;
>   struct drm_plane *primary, *cursor = NULL;
>   int ret;
> + int writeback;
>  
>   primary = vkms_plane_init(vkmsdev, DRM_PLANE_TYPE_PRIMARY, index);
>   if (IS_ERR(primary))
> @@ -80,9 +81,11 @@ int vkms_output_init(struct vkms_device *vkmsdev, int 
> index)
>   goto err_attach;
>   }
>  
> - ret = vkms_enable_writeback_connector(vkmsdev);
> - if (ret)
> - DRM_ERROR("Failed to init writeback connector\n");
> + if (vkmsdev->config->writeback) {
> + writeback = vkms_enable_writeback_connector(vkmsdev);
> + if (writeback)
> + DRM_ERROR("Failed to init writeback connector\n");
> + }

Thanks,

Reviewed-by: Melissa Wen 

>
>   drm_mode_config_reset(dev);
>  
> -- 
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V5 1/3] drm/vkms: Add vkms_config type

[Melissa Wen]

On 01/12, Sumera Priyadarsini wrote:
> Currently, data for the device instance is held by vkms_device.
> Add a separate type, vkms_config to contain configuration details
> for the device and various modes to be later used by configfs.
> This config data stays constant once the device is created.
> 
> Accordingly, add vkms_create and vkms_destroy to initialize/destroy
> device through configfs. Currently, they are being called from vkms_init
> and vkms_exit, but will be evoked from configfs later on. When configfs
> is added, device configuration will be tracked by configfs and only vkms
> device lifetime will be handled by vkms_init and vkms_exit functions.
> 
> Modify usage of enable_cursor feature to reflect the changes in
> relevant files.
> 
> Co-developed-by: Daniel Vetter 
> Signed-off-by: Daniel Vetter 
> Signed-off-by: Sumera Priyadarsini 
> ---
>  drivers/gpu/drm/vkms/vkms_drv.c| 40 --
>  drivers/gpu/drm/vkms/vkms_drv.h| 12 +++--
>  drivers/gpu/drm/vkms/vkms_output.c |  4 +--
>  3 files changed, 44 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index aef29393b811..6b33975a5cb2 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -34,9 +34,9 @@
>  #define DRIVER_MAJOR 1
>  #define DRIVER_MINOR 0
>  
> -static struct vkms_device *vkms_device;
> +static struct vkms_config *default_config;
>  
> -bool enable_cursor = true;
> +static bool enable_cursor = true;
>  module_param_named(enable_cursor, enable_cursor, bool, 0444);
>  MODULE_PARM_DESC(enable_cursor, "Enable/Disable cursor support");
>  
> @@ -122,10 +122,11 @@ static int vkms_modeset_init(struct vkms_device 
> *vkmsdev)
>   return vkms_output_init(vkmsdev, 0);
>  }
>  
> -static int __init vkms_init(void)
> +static int vkms_create(struct vkms_config *config)
>  {
>   int ret;
>   struct platform_device *pdev;
> + struct vkms_device *vkms_device;
>  
>   pdev = platform_device_register_simple(DRIVER_NAME, -1, NULL, 0);
>   if (IS_ERR(pdev))
> @@ -143,6 +144,8 @@ static int __init vkms_init(void)
>   goto out_devres;
>   }
>   vkms_device->platform = pdev;
> + vkms_device->config = config;
> + config->dev = vkms_device;
>  
>   ret = dma_coerce_mask_and_coherent(vkms_device->drm.dev,
>  DMA_BIT_MASK(64));
> @@ -179,21 +182,42 @@ static int __init vkms_init(void)
>   return ret;
>  }
>  
> -static void __exit vkms_exit(void)
> +static int __init vkms_init(void)
> +{
> + struct vkms_config *config = kmalloc(sizeof(*config), GFP_KERNEL);
> +
> + default_config = config;
> +
> + config->cursor = enable_cursor;
> +
> + return vkms_create(config);
> +}
> +
> +static void vkms_destroy(struct vkms_config *config)
>  {
>   struct platform_device *pdev;
>  
> - if (!vkms_device) {
> + if (!config->dev) {
>   DRM_INFO("vkms_device is NULL.\n");
>   return;
>   }
>  
> - pdev = vkms_device->platform;
> + pdev = config->dev->platform;
>  
> - drm_dev_unregister(_device->drm);
> - drm_atomic_helper_shutdown(_device->drm);
> + drm_dev_unregister(>dev->drm);
> + drm_atomic_helper_shutdown(>dev->drm);
>   devres_release_group(>dev, NULL);
>   platform_device_unregister(pdev);
> +
> + config->dev = NULL;
> +}
> +
> +static void __exit vkms_exit(void)
> +{
> + if (default_config->dev)
> + vkms_destroy(default_config);
> +
> + kfree(default_config);
>  }
>  
>  module_init(vkms_init);
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 5ed91ff08cb3..6a27bd8875f2 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -19,8 +19,6 @@
>  #define XRES_MAX  8192
>  #define YRES_MAX  8192
>  
> -extern bool enable_cursor;
> -
>  struct vkms_composer {
>   struct drm_framebuffer fb;
>   struct drm_rect src, dst;
> @@ -82,10 +80,19 @@ struct vkms_output {
>   spinlock_t composer_lock;
>  };
>  
> +struct vkms_device;
> +
> +struct vkms_config {
> + bool cursor;
> + /* only set when instantiated */
> + struct vkms_device *dev;
> +};
> +
>  struct vkms_device {
>   struct drm_device drm;
>   struct platform_device *platform;
>   struct vkms_output output;
> + const struct vkms_config *config;
>  };
>  
>  #define

Re: [PATCH V5 3/3] drm/vkms: Add information about module options

[Melissa Wen]

On 01/12, Sumera Priyadarsini wrote:
> Update vkms documentation to contain usage of `modinfo`
> command and steps to load vkms with module options enabled.
> 
> Signed-off-by: Sumera Priyadarsini 
> ---
>  Documentation/gpu/vkms.rst | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
> index 9e030c74a82e..2c9b376da5ca 100644
> --- a/Documentation/gpu/vkms.rst
> +++ b/Documentation/gpu/vkms.rst
> @@ -35,6 +35,18 @@ Now, to load the driver, use::
>  On running the lsmod command now, the VKMS driver will appear listed.
>  You can also observe the driver being loaded in the dmesg logs.
>  
> +The VKMS driver has optional features to simulate different kinds of 
> hardware,
> +which are exposed as module options. You can use the `modinfo` command
> +to see the module options for vkms::
> +
> +  modinfo vkms
> +
> +Module options are helpful when testing, and enabling modules
> +can be done while loading vkms. For example, to load vkms with cursor 
> enabled,
> +use::
> +
> +  sudo modprobe vkms enable_cursor=1
> +

Hi Sumera,

Thanks for documenting.

You forgot to bring Daniel's ack; however, as I also reviewed and lgtm,

Reviewed-by: Melissa Wen 

>  To disable the driver, use ::
>  
>sudo modprobe -r vkms
> -- 
> 2.25.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V3] drm/vkms: Decouple config data for configfs

[Melissa Wen]

On 01/05, Sumera Priyadarsini wrote:
> Currently, data for the device instance is held by vkms_device.
> Add a separate type, vkms_config to contain configuration details
> for the device and various modes to be later used by configfs.
> This config data stays constant once the device is created.
> 
> Accordingly, add vkms_create and vkms_destroy to initialize/destroy
> device through configfs. Currently, they are being called from vkms_init
> and vkms_exit, but will be evoked from configfs later on. When configfs
> is added, device configuration will be tracked by configfs and only vkms
> device lifetime will be handled by vkms_init and vkms_exit functions.
> 
> Modify usage of enable_cursor feature to reflect the changes in
> relevant files.
> 
> Add enable_writeback_connector feature to vkms_config type.
> 
> Co-developed-by: Daniel Vetter 
> Signed-off-by: Daniel Vetter 
> Signed-off-by: Sumera Priyadarsini 
> 
> ---
> Changes in v2:
> - add Co-developed-by tag
> 
> Changes in v3:
> - correct usage of Co-developed by tag(Melissa)
> - add enable_writeback_feature(Melissa)
> - modify commit message(Melissa)
> ---
>  drivers/gpu/drm/vkms/vkms_drv.c| 45 --
>  drivers/gpu/drm/vkms/vkms_drv.h| 12 ++--
>  drivers/gpu/drm/vkms/vkms_output.c | 13 +
>  3 files changed, 54 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index aef29393b811..fab964900dce 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -34,12 +34,16 @@
>  #define DRIVER_MAJOR 1
>  #define DRIVER_MINOR 0
>  
> -static struct vkms_device *vkms_device;
> +static struct vkms_config *default_config;
>  
> -bool enable_cursor = true;
> +static bool enable_cursor = true;
>  module_param_named(enable_cursor, enable_cursor, bool, 0444);
>  MODULE_PARM_DESC(enable_cursor, "Enable/Disable cursor support");
>  
> +static bool enable_writeback_connector = true;
> +module_param_named(enable_writeback_connector, enable_writeback_connector, 
> bool, 0444);
> +MODULE_PARM_DESC(enable_writeback_connector, "Enable/Disable writeback 
> connector support");
> +
Even though the limit is now 100 characteres, I consider 'enable_writeback'
enough here. I think removing this _connector suffix doesn't affect the
undestanding and also save some space to avoid break lines in the future

>  DEFINE_DRM_GEM_FOPS(vkms_driver_fops);
>  
>  static void vkms_release(struct drm_device *dev)
> @@ -122,10 +126,11 @@ static int vkms_modeset_init(struct vkms_device 
> *vkmsdev)
>   return vkms_output_init(vkmsdev, 0);
>  }
>  
> -static int __init vkms_init(void)
> +static int vkms_create(struct vkms_config *config)
>  {
>   int ret;
>   struct platform_device *pdev;
> + struct vkms_device *vkms_device;
>  
>   pdev = platform_device_register_simple(DRIVER_NAME, -1, NULL, 0);
>   if (IS_ERR(pdev))
> @@ -143,6 +148,8 @@ static int __init vkms_init(void)
>   goto out_devres;
>   }
>   vkms_device->platform = pdev;
> + vkms_device->config = config;
> + config->dev = vkms_device;
>  
>   ret = dma_coerce_mask_and_coherent(vkms_device->drm.dev,
>  DMA_BIT_MASK(64));
> @@ -179,21 +186,43 @@ static int __init vkms_init(void)
>   return ret;
>  }
>  
> -static void __exit vkms_exit(void)
> +static int __init vkms_init(void)
> +{
> + struct vkms_config *config = kmalloc(sizeof(*config), GFP_KERNEL);
> +
> + default_config = config;
> +
> + config->cursor = enable_cursor;
> + config->writeback = enable_writeback_connector;
> +
> + return vkms_create(config);
> +}
> +
> +static void vkms_destroy(struct vkms_config *config)
>  {
>   struct platform_device *pdev;
>  
> - if (!vkms_device) {
> + if (!config->dev) {
>   DRM_INFO("vkms_device is NULL.\n");
>   return;
>   }
>  
> - pdev = vkms_device->platform;
> + pdev = config->dev->platform;
>  
> - drm_dev_unregister(_device->drm);
> - drm_atomic_helper_shutdown(_device->drm);
> + drm_dev_unregister(>dev->drm);
> + drm_atomic_helper_shutdown(>dev->drm);
>   devres_release_group(>dev, NULL);
>   platform_device_unregister(pdev);
> +
> + config->dev = NULL;
> +}
> +
> +static void __exit vkms_exit(void)
> +{
> + if (default_config->dev)
> + vkms_destroy(default_config);
> +
> + kfree(default_config);
>  }
>  
>  module_init(vkms_init);
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 5ed91ff08cb3..caa1fafb6ca7 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -19,8 +19,6 @@
>  #define XRES_MAX  8192
>  #define YRES_MAX  8192
>  
> -extern bool enable_cursor;
> -
>  struct vkms_composer {
>   struct drm_framebuffer fb;
>   struct drm_rect src, dst;
> @@ -82,10 +80,18 @@ struct vkms_output {
>

Re: [PATCH V2] drm/vkms: Add setup and testing information

[Melissa Wen]

On 12/09, Daniel Vetter wrote:
> On Wed, Dec 9, 2020 at 12:33 PM Sumera Priyadarsini
>  wrote:
> >
> > On Wed, Dec 9, 2020 at 6:24 AM Daniel Vetter  wrote:
> > >
> > > On Wed, Dec 09, 2020 at 02:07:35AM +0530, Sumera Priyadarsini wrote:
> > > > Update the vkms documentation to contain steps to:
> > > >
> > > >  - setup the vkms driver
> > > >  - run tests using igt
> > > >
> > > > Signed-off-by: Sumera Priyadarsini 
> > > > ___
> > > > Changes in v2:
> > > >  - Change heading to title case (Daniel)
> > > >  - Add examples to run tests directly (Daniel)
> > > >  - Add examples to run subtests (Melissa)
> > > > ---
> > > >  Documentation/gpu/vkms.rst | 67 ++
> > > >  1 file changed, 67 insertions(+)
> > > >
> > > > diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
> > > > index 13bab1d93bb3..d6739fbbe503 100644
> > > > --- a/Documentation/gpu/vkms.rst
> > > > +++ b/Documentation/gpu/vkms.rst
> > > > @@ -7,6 +7,73 @@
> > > >  .. kernel-doc:: drivers/gpu/drm/vkms/vkms_drv.c
> > > > :doc: vkms (Virtual Kernel Modesetting)
> > > >
> > > > +Setup
> > > > +=
> > > > +
> > > > +The VKMS driver can be setup with the following steps:
> > > > +
> > > > +To check if VKMS is loaded, run::
> > > > +
> > > > +  lsmod | grep vkms
> > > > +
> > > > +This should list the VKMS driver. If no output is obtained, then
> > > > +you need to enable and/or load the VKMS driver.
> > > > +Ensure that the VKMS driver has been set as a loadable module in your
> > > > +kernel config file. Do::
> > > > +
> > > > +  make nconfig
> > > > +
> > > > +  Go to `Device Drivers> Graphics support`
> > > > +
> > > > +  Enable `Virtual KMS (EXPERIMENTAL)`
> > > > +
> > > > +Compile and build the kernel for the changes to get reflected.
> > > > +Now, to load the driver, use::
> > > > +
> > > > +  sudo modprobe vkms
> > > > +
> > > > +On running the lsmod command now, the VKMS driver will appear listed.
> > > > +You can also observe the driver being loaded in the dmesg logs.
> > > > +
> > > > +To disable the driver, use ::
> > > > +
> > > > +  sudo modprobe -r vkms
> > > > +
> > > > +Testing With IGT
> > > > +
> > > > +
> > > > +The IGT GPU Tools is a test suite used specifically for debugging and
> > > > +development of the DRM drivers.
> > > > +The IGT Tools can be installed from
> > > > +`here `_ .
> > > > +
> > > > +The tests need to be run without a compositor, so you need to switch 
> > > > to text
> > > > +only mode. You can do this by::
> > > > +
> > > > +  sudo systemctl isolate multi-user.target
> > > > +
> > > > +To return to graphical mode, do::
> > > > +
> > > > +  sudo systemctl isolate graphical.target
> > > > +
> > > > +Once you are in text only mode, you can run tests using the --device 
> > > > switch
> > > > +or IGT_DEVICE variable to specify the device filter for the driver we 
> > > > want
> > > > +to test::
> > > > +
> > > > +  sudo ./build/tests/ --device 
> > > > "sys:/sys/devices/platform/vkms"
> > > > +  sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./build/tests/ > > > of test>
> > > > +
> > > > +For example, to test the functionality of the writeback library,
> > > > +we can run the kms_writeback test::
> > > > +
> > > > +  sudo ./build/tests/kms_writeback --device 
> > > > "sys:/sys/devices/platform/vkms"
> > > > +  sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" 
> > > > ./build/tests/kms_writeback
> > > > +
> > > > +You can also run subtests if you do not want to run the entire test::
> > > > +
> > > > +  sudo ./build/tests/kms_flip --run-subtest basic-plain-flip --device 
> > > > "sys:/sys/devices/platform/vkms"
> > > > +  sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" 
> > > > ./build/tests/kms_flip --run-subtest basic-plain-flip
> > >
> > > Does IGT_DEVICE also work with run-tests.sh? Aside from my curious
> > > question, patch looks good to me, thanks a lot.
> >
> > Good catch, it does.
> >
> > Melissa, IGT_FORCE_DRIVER also works. I think I was used test/kms_flip
> > earlier instead of
> > ./build/test/kms_flip hence the fluke.
> >
> > Should I add these also to the docs, was wondering if it will get too
> > confusing
> 
> I think IGT_FORCE_DRIVER is deprecated, so better not to mention that.
> IGT_DEVICE and --device are the new thing. I think just adding a
> sentence that IGT_DEVICE also works with the run-tests scripts would
> be good perhaps.

Yes, that's what I think too

Good work!

Melissa

> -Daniel
> 
> >
> > >
> > > Reviewed-by: Daniel Vetter 
> > >
> > > > +
> > > >  TODO
> > > >  
> > > >
> > > > --
> > > > 2.25.1
> > > >
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel 

Re: [PATCH v3] drm/vkms: Add setup and testing information

[Melissa Wen]

On 12/09, Daniel Vetter wrote:
> On Thu, Dec 10, 2020 at 12:34:53AM +0530, Sumera Priyadarsini wrote:
> > Update the vkms documentation to contain steps to:
> > 
> >  - setup the vkms driver
> >  - run tests using igt
> > 
> > Signed-off-by: Sumera Priyadarsini 
> > ___
> > Changes in v2:
> >  - Change heading to title case (Daniel)
> >  - Add examples to run tests directly (Daniel)
> >  - Add examples to run subtests (Melissa)
> > 
> > Changes in v3:
> >  - Add example using run-tests.sh script(Daniel)
> 
> Reviewed-by: Daniel Vetter 
> 
Applied to drm-misc-next.

Thanks for these improvements,

Melissa
> > ---
> >  Documentation/gpu/vkms.rst | 70 ++
> >  1 file changed, 70 insertions(+)
> > 
> > diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
> > index 13bab1d93bb3..9e030c74a82e 100644
> > --- a/Documentation/gpu/vkms.rst
> > +++ b/Documentation/gpu/vkms.rst
> > @@ -7,6 +7,76 @@
> >  .. kernel-doc:: drivers/gpu/drm/vkms/vkms_drv.c
> > :doc: vkms (Virtual Kernel Modesetting)
> >  
> > +Setup
> > +=
> > +
> > +The VKMS driver can be setup with the following steps:
> > +
> > +To check if VKMS is loaded, run::
> > +
> > +  lsmod | grep vkms
> > +
> > +This should list the VKMS driver. If no output is obtained, then
> > +you need to enable and/or load the VKMS driver.
> > +Ensure that the VKMS driver has been set as a loadable module in your
> > +kernel config file. Do::
> > +
> > +  make nconfig
> > +
> > +  Go to `Device Drivers> Graphics support`
> > +
> > +  Enable `Virtual KMS (EXPERIMENTAL)`
> > +
> > +Compile and build the kernel for the changes to get reflected.
> > +Now, to load the driver, use::
> > +
> > +  sudo modprobe vkms
> > +
> > +On running the lsmod command now, the VKMS driver will appear listed.
> > +You can also observe the driver being loaded in the dmesg logs.
> > +
> > +To disable the driver, use ::
> > +
> > +  sudo modprobe -r vkms
> > +
> > +Testing With IGT
> > +
> > +
> > +The IGT GPU Tools is a test suite used specifically for debugging and
> > +development of the DRM drivers.
> > +The IGT Tools can be installed from
> > +`here `_ .
> > +
> > +The tests need to be run without a compositor, so you need to switch to 
> > text
> > +only mode. You can do this by::
> > +
> > +  sudo systemctl isolate multi-user.target
> > +
> > +To return to graphical mode, do::
> > +
> > +  sudo systemctl isolate graphical.target
> > +
> > +Once you are in text only mode, you can run tests using the --device switch
> > +or IGT_DEVICE variable to specify the device filter for the driver we want
> > +to test. IGT_DEVICE can also be used with the run-test.sh script to run the
> > +tests for a specific driver::
> > +
> > +  sudo ./build/tests/ --device 
> > "sys:/sys/devices/platform/vkms"
> > +  sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./build/tests/ > test>
> > +  sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./scripts/run-tests.sh 
> > -t 
> > +
> > +For example, to test the functionality of the writeback library,
> > +we can run the kms_writeback test::
> > +
> > +  sudo ./build/tests/kms_writeback --device 
> > "sys:/sys/devices/platform/vkms"
> > +  sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" 
> > ./build/tests/kms_writeback
> > +  sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./scripts/run-tests.sh 
> > -t kms_writeback
> > +
> > +You can also run subtests if you do not want to run the entire test::
> > +
> > +  sudo ./build/tests/kms_flip --run-subtest basic-plain-flip --device 
> > "sys:/sys/devices/platform/vkms"
> > +  sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./build/tests/kms_flip 
> > --run-subtest basic-plain-flip
> > +
> >  TODO
> >  
> >  
> > -- 
> > 2.25.1
> > 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vkms: Add setup and testing information

[Melissa Wen]

Hi Sumera,

Thanks for the doc improvements.
Please see some complimentary comments below.

On 12/03, Daniel Vetter wrote:
> On Thu, Dec 3, 2020 at 8:13 PM Sumera Priyadarsini
>  wrote:
> >
> > Update the vkms documentation to contain steps to:
> >
> >  - setup the vkms driver
> >  - run tests using igt
> >
> > Signed-off-by: Sumera Priyadarsini 
> > ---
> >  Documentation/gpu/vkms.rst | 47 ++
> >  1 file changed, 47 insertions(+)
> >
> > diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
> > index 13bab1d93bb3..d6782174d23f 100644
> > --- a/Documentation/gpu/vkms.rst
> > +++ b/Documentation/gpu/vkms.rst
> > @@ -7,6 +7,53 @@
> >  .. kernel-doc:: drivers/gpu/drm/vkms/vkms_drv.c
> > :doc: vkms (Virtual Kernel Modesetting)
> >
> > +SETUP
> 
> Absolute bikeshed, but we generally stick to titlecase for titles, so
> just "Setup" and "Testing with IGT".
> > +=
> > +
> > +The VKMS driver can be setup with the following steps:
> > +
> > +To check if VKMS is loaded, run::
> > +
> > +  lsmod | grep vkms
> > +
> > +This should list the VKMS driver. If no output is obtained, then
> > +you need to enable and/or load the VKMS driver.
> > +Ensure that the VKMS driver has been set as a loadable module in your
> > +kernel config file. The following line should be present in the .config
> > +file in your kernel root::
> > +
> > +  CONFIG_DRM_VKMS=m
> > +

Considering the target audience, I would make it clearer to explore the
configuration options using "make *config". As in
https://kernelnewbies.org/FirstKernelPatch#Recompiling_the_driver

> > +Compile and build the kernel for the changes to get reflected.
> > +If your existing config already has VKMS available as a loadable module,
> > +then there is no need to build the kernel again.
> > +Now, to load the driver, use::
> > +
> > +  sudo modprobe vkms
> > +
> > +On running the lsmod command now, the VKMS driver will appear listed.
> > +You can also observe the driver being loaded in the dmesg logs.
> > +
> > +To disable the driver, use ::
s/disable/unload/
> > +
> > +  sudo modprobe -r vkms
> > +
> > +TESTING WITH IGT
> > +
> > +
> > +The IGT GPU Tools is a test suite used specifically for debugging and
> > +development of the DRM drivers.
> > +The IGT Tools can be installed from
> > +`here `_ .
> > +Once you have installed IGT, you can run tests using::
> > +
> > +  ./scripts/run-tests.sh -t 
> > +
> > +For example, to test the functionality of the igt_draw library,
> > +we can run the kms_draw_crc test::
> > +
> > +  ./scripts/run-tests.sh -t kms_draw_crc
> 
> If we run igt tests directly, there's an option to select the right
> device. This is important if you have more than one gpu driver
> (usually the case if you run this directly, but even on virtual
> machines there should usually be a drm driver around).  E.g. when I
> run a test directly:
> 
> # tests/kms_flip --device drm:/dev/dri/card0
> 
> I'm not sure whether there's an option that's always going to select
> the vkms device. I'm also not sure you can pass these options to
> run-tests.sh, I kinda don't use that one myself ...

I also run a test directly. Some cases have many subtests, therefore I
can pass --run-subtest to specify one.

And, to select vkms, I use IGT_FORCE_DRIVER. For example:

# IGT_FORCE_DRIVER=vkms tests/kms_flip --run-subtest basic-plain-flip

> 
> Aside from that looks all good to me.
+1

Melissa
> -Daniel
> 
> > +
> >  TODO
> >  
> >
> > --
> > 2.25.1
> >
> 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH][next] drm/vkms: Fix missing kmalloc allocation failure check

[Melissa Wen]

On 01/15, Sumera Priyadarsini wrote:
> On Fri, Jan 15, 2021 at 6:39 PM Colin King  wrote:
> >
> > From: Colin Ian King 
> >
> > Currently the kmalloc allocation for config is not being null
> > checked and could potentially lead to a null pointer dereference.
> > Fix this by adding the missing null check.
> >
> > Addresses-Coverity: ("Dereference null return value")
> > Fixes: 2df7af93fdad ("drm/vkms: Add vkms_config type")
> > Signed-off-by: Colin Ian King 
> 
> Good catch, thank you!
> 
> Reviewed-by: Sumera Priyadarsini 

Applied to drm-misc-next.

Thanks,
Melissa Wen
> > ---
> >  drivers/gpu/drm/vkms/vkms_drv.c | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c 
> > b/drivers/gpu/drm/vkms/vkms_drv.c
> > index 708f7f54001d..2173b82606f6 100644
> > --- a/drivers/gpu/drm/vkms/vkms_drv.c
> > +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> > @@ -188,7 +188,11 @@ static int vkms_create(struct vkms_config *config)
> >
> >  static int __init vkms_init(void)
> >  {
> > -   struct vkms_config *config = kmalloc(sizeof(*config), GFP_KERNEL);
> > +   struct vkms_config *config;
> > +
> > +   config = kmalloc(sizeof(*config), GFP_KERNEL);
> > +   if (!config)
> > +   return -ENOMEM;
> >
> > default_config = config;
> >
> > --
> > 2.29.2
> >
> regards,
> Sumera
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V2] drm/vkms: Decouple config data for configfs

[Melissa Wen]

Hi Sumera,

Thanks for your patch.
Please see some comments below.

On 01/02, Sumera Priyadarsini wrote:
> Currently, data for the device instance is held by vkms_device.
> Add a separate type, vkms_config to contain configuration details
> for the device and various modes to be later used by configfs.
> This config data stays constant once the device is created.
> 
> Accordingly, add vkms_create and vkms_destroy to initialize/destroy
> device through configfs. Currently, they are being called from vkms_init
> and vkms_exit, but will be evoked from configfs later on. When configfs
> is added, device configuration- enabling/disabling features will
> be tracked by configfs and only vkms device lifetime will be kept track of
> by vkms_init and vkms_exit functions.

I didn't quite understand this very last sentence.

> 
> Modify usage of enable_cursor feature to reflect the changes in
> relevant files.

Since the goal is also enabling/disabling writeback and vblank via a
future configfs support, it would be nice to see here this same cursor
adaptation applied to others, initially as a module parameter.  For
writeback, it's really straightforward...

> 
> Signed-off-by: Sumera Priyadarsini 
> Co-developed-by: Daniel Vetter 

There are some formatting details for credits, for example, including
the co-developer s-o-b. See here:
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by

> ---
> Changes in v2:
> - add Co-developed-by tag
> 
> ---
>  drivers/gpu/drm/vkms/vkms_drv.c| 40 --
>  drivers/gpu/drm/vkms/vkms_drv.h| 11 +---
>  drivers/gpu/drm/vkms/vkms_output.c |  4 +--
>  3 files changed, 42 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index aef29393b811..6b33975a5cb2 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -34,9 +34,9 @@
>  #define DRIVER_MAJOR 1
>  #define DRIVER_MINOR 0
>  
> -static struct vkms_device *vkms_device;
> +static struct vkms_config *default_config;
>  
> -bool enable_cursor = true;
> +static bool enable_cursor = true;
>  module_param_named(enable_cursor, enable_cursor, bool, 0444);
>  MODULE_PARM_DESC(enable_cursor, "Enable/Disable cursor support");
>  
> @@ -122,10 +122,11 @@ static int vkms_modeset_init(struct vkms_device 
> *vkmsdev)
>   return vkms_output_init(vkmsdev, 0);
>  }
>  
> -static int __init vkms_init(void)
> +static int vkms_create(struct vkms_config *config)
>  {
>   int ret;
>   struct platform_device *pdev;
> + struct vkms_device *vkms_device;
>  
>   pdev = platform_device_register_simple(DRIVER_NAME, -1, NULL, 0);
>   if (IS_ERR(pdev))
> @@ -143,6 +144,8 @@ static int __init vkms_init(void)
>   goto out_devres;
>   }
>   vkms_device->platform = pdev;
> + vkms_device->config = config;
> + config->dev = vkms_device;
>  
>   ret = dma_coerce_mask_and_coherent(vkms_device->drm.dev,
>  DMA_BIT_MASK(64));
> @@ -179,21 +182,42 @@ static int __init vkms_init(void)
>   return ret;
>  }
>  
> -static void __exit vkms_exit(void)
> +static int __init vkms_init(void)
> +{
> + struct vkms_config *config = kmalloc(sizeof(*config), GFP_KERNEL);
> +
> + default_config = config;
> +
> + config->cursor = enable_cursor;
> +
> + return vkms_create(config);
> +}
> +
> +static void vkms_destroy(struct vkms_config *config)
>  {
>   struct platform_device *pdev;
>  
> - if (!vkms_device) {
> + if (!config->dev) {
>   DRM_INFO("vkms_device is NULL.\n");
>   return;
>   }
>  
> - pdev = vkms_device->platform;
> + pdev = config->dev->platform;
>  
> - drm_dev_unregister(_device->drm);
> - drm_atomic_helper_shutdown(_device->drm);
> + drm_dev_unregister(>dev->drm);
> + drm_atomic_helper_shutdown(>dev->drm);
>   devres_release_group(>dev, NULL);
>   platform_device_unregister(pdev);
> +
> + config->dev = NULL;
> +}
> +
> +static void __exit vkms_exit(void)
> +{
> + if (default_config->dev)
> + vkms_destroy(default_config);
> +
> + kfree(default_config);
>  }
>  
>  module_init(vkms_init);
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index 5ed91ff08cb3..2fa0c52f1dd8 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -19,8 +19,6 @@
>  #define XRES_MAX  8192
>  #define YRES_MAX  8192
>  
> -extern bool enable_cursor;
> -
>  struct vkms_composer {
>   struct drm_framebuffer fb;
>   struct drm_rect src, dst;
> @@ -82,10 +80,17 @@ struct vkms_output {
>   spinlock_t composer_lock;
>  };
>  
> +struct vkms_device;
> +struct vkms_config {
> + bool cursor;
> + /* only set when instantiated */
> + struct vkms_device *dev;
> +};
>  struct vkms_device {
>   struct drm_device drm;

Re: [PATCH V5 0/3] Decouple config data for configfs

[Melissa Wen]

On 01/12, Sumera Priyadarsini wrote:
> This patchset aims to lay down some prep work before configfs can be
> implemented for the vkms driver. The first patch in the series adds a
> new type vkms_config to track device configuration. The second and third
> patch add module testing support for writeback operations.
> 
> The first patch is developed by Daniel Vetter.
> 
> Daniel Vetter (1):
>   drm/vkms: Add vkms_config type
> 
> Sumera Priyadarsini (3):
>   drm/vkms: Add vkms_config type
>   drm/vkms: Add support for writeback module
>   drm/vkms: Add information about module options
> 
>  Documentation/gpu/vkms.rst | 12 
>  drivers/gpu/drm/vkms/vkms_drv.c| 45 --
>  drivers/gpu/drm/vkms/vkms_drv.h| 13 +++--
>  drivers/gpu/drm/vkms/vkms_output.c | 13 +
>  4 files changed, 68 insertions(+), 15 deletions(-)

Applied to drm-misc-next.
I fixed the extra line issue while applying.

Thanks for your patches,

Melissa

> 
> ---
> Changes in v2:
>  - add Co-developed-by tag
>  
> Changes in v3:
>  - correct usage of Co-developed by tag(Melissa)
>  - add enable_writeback_feature(Melissa)
>  - modify commit message(Melissa)
> 
> Changes in v4:
>  - split previous patch into patchset(Melissa)
>  - fix checkpatch issue(Melissa)
>  - update docs(Daniel)
> 
> Changes in v5:
>  - modify docs patch(Daniel)
> -- 
> 2.25.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/v3d: Expose performance counters to userspace

[Melissa Wen]

On 06/08, Juan A. Suarez Romero wrote:
> The V3D engine has several hardware performance counters that can of
> interest for userspace performance analysis tools.
> 
> This exposes new ioctls to create and destroy performance monitor
> objects, as well as to query the counter values.
> 
> Each created performance monitor object has an ID that can be attached
> to CL/CSD submissions, so the driver enables the requested counters when
> the job is submitted, and updates the performance monitor values when
> the job is done.
> 
> It is up to the user to ensure all the jobs have been finished before
> getting the performance monitor values. It is also up to the user to
> properly synchronize BCL jobs when submitting jobs with different
> performance monitors attached.
> 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> Cc: Emma Anholt 
> To: dri-devel@lists.freedesktop.org
> Signed-off-by: Juan A. Suarez Romero 

Hi Juan,

I've checked it (+ mesa MR) on glxgears, and lgtm.

+ some basic tests from igt, by default.

Acked-by: Melissa Wen 

> ---
>  drivers/gpu/drm/v3d/Makefile  |   1 +
>  drivers/gpu/drm/v3d/v3d_drv.c |   8 ++
>  drivers/gpu/drm/v3d/v3d_drv.h |  63 +
>  drivers/gpu/drm/v3d/v3d_gem.c |  31 +
>  drivers/gpu/drm/v3d/v3d_perfmon.c | 213 ++
>  drivers/gpu/drm/v3d/v3d_regs.h|   2 +
>  drivers/gpu/drm/v3d/v3d_sched.c   |  16 +++
>  include/uapi/drm/v3d_drm.h| 136 +++
>  8 files changed, 470 insertions(+)
>  create mode 100644 drivers/gpu/drm/v3d/v3d_perfmon.c
> 
> diff --git a/drivers/gpu/drm/v3d/Makefile b/drivers/gpu/drm/v3d/Makefile
> index db4cfc155821..e8b314137020 100644
> --- a/drivers/gpu/drm/v3d/Makefile
> +++ b/drivers/gpu/drm/v3d/Makefile
> @@ -9,6 +9,7 @@ v3d-y := \
>   v3d_gem.o \
>   v3d_irq.o \
>   v3d_mmu.o \
> + v3d_perfmon.o \
>   v3d_trace_points.o \
>   v3d_sched.o
>  
> diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
> index 99e22beea90b..9403c3b36aca 100644
> --- a/drivers/gpu/drm/v3d/v3d_drv.c
> +++ b/drivers/gpu/drm/v3d/v3d_drv.c
> @@ -94,6 +94,9 @@ static int v3d_get_param_ioctl(struct drm_device *dev, void 
> *data,
>   case DRM_V3D_PARAM_SUPPORTS_CACHE_FLUSH:
>   args->value = 1;
>   return 0;
> + case DRM_V3D_PARAM_SUPPORTS_PERFMON:
> + args->value = (v3d->ver >= 40);
> + return 0;
>   default:
>   DRM_DEBUG("Unknown parameter %d\n", args->param);
>   return -EINVAL;
> @@ -121,6 +124,7 @@ v3d_open(struct drm_device *dev, struct drm_file *file)
> 1, NULL);
>   }
>  
> + v3d_perfmon_open_file(v3d_priv);
>   file->driver_priv = v3d_priv;
>  
>   return 0;
> @@ -136,6 +140,7 @@ v3d_postclose(struct drm_device *dev, struct drm_file 
> *file)
>   drm_sched_entity_destroy(_priv->sched_entity[q]);
>   }
>  
> + v3d_perfmon_close_file(v3d_priv);
>   kfree(v3d_priv);
>  }
>  
> @@ -156,6 +161,9 @@ static const struct drm_ioctl_desc v3d_drm_ioctls[] = {
>   DRM_IOCTL_DEF_DRV(V3D_GET_BO_OFFSET, v3d_get_bo_offset_ioctl, 
> DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(V3D_SUBMIT_TFU, v3d_submit_tfu_ioctl, 
> DRM_RENDER_ALLOW | DRM_AUTH),
>   DRM_IOCTL_DEF_DRV(V3D_SUBMIT_CSD, v3d_submit_csd_ioctl, 
> DRM_RENDER_ALLOW | DRM_AUTH),
> + DRM_IOCTL_DEF_DRV(V3D_PERFMON_CREATE, v3d_perfmon_create_ioctl, 
> DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(V3D_PERFMON_DESTROY, v3d_perfmon_destroy_ioctl, 
> DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(V3D_PERFMON_GET_VALUES, v3d_perfmon_get_values_ioctl, 
> DRM_RENDER_ALLOW),
>  };
>  
>  static const struct drm_driver v3d_drm_driver = {
> diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
> index 8a390738d65b..270134779073 100644
> --- a/drivers/gpu/drm/v3d/v3d_drv.h
> +++ b/drivers/gpu/drm/v3d/v3d_drv.h
> @@ -37,6 +37,40 @@ struct v3d_queue_state {
>   u64 emit_seqno;
>  };
>  
> +/* Performance monitor object. The perform lifetime is controlled by 
> userspace
> + * using perfmon related ioctls. A perfmon can be attached to a submit_cl
> + * request, and when this is the case, HW perf counters will be activated 
> just
> + * before the submit_cl is submitted to the GPU and disabled when the job is
> + * done. This way, only events related to a specific job will be counted.
> + */
> +struct v3d_perfmon {
> + /* Tracks the number of users of the perfmon, when this counter reaches
> +  * zero the perfmon is destroyed.
> +  */
> +  

Re: [PATCH] drm/vkms: Create vkms_config_debufs in vkms_drv.c

[Melissa Wen]

On 07/07, Beatriz Martins de Carvalho wrote:
> Development vkms_config_debufs in vkms_drv.c for the long term plan of
> making vkms configurable and have multiple different instances it's
> useful to be able to get at the config of each instance in debugfs
Hi Beatriz,

Thanks for your patch.

Changes lgtm.

However commit message needs small improvements. Besides typo, it would
be good to make the subject clearer in terms of its purpose (creating
a debugfs file to get/track vkms config data).

Please, address these minor things and add my r-b.
Reviewed-by: Melissa Wen 

> 
> Signed-off-by: Beatriz Martins de Carvalho 
> 
> ---
>  drivers/gpu/drm/vkms/vkms_drv.c | 28 
>  1 file changed, 28 insertions(+)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index 027ffe759440..c81fba6c72f0 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -28,6 +28,9 @@
>  
>  #include "vkms_drv.h"
>  
> +#include 
> +#include 
> +
>  #define DRIVER_NAME  "vkms"
>  #define DRIVER_DESC  "Virtual Kernel Mode Setting"
>  #define DRIVER_DATE  "20180514"
> @@ -86,12 +89,37 @@ static void vkms_atomic_commit_tail(struct 
> drm_atomic_state *old_state)
>   drm_atomic_helper_cleanup_planes(dev, old_state);
>  }
>  
> +static int vkms_config_show(struct seq_file *m, void *data)
> +{
> + struct drm_info_node *node = (struct drm_info_node *)m->private;
> + struct drm_device *dev = node->minor->dev;
> + struct vkms_device *vkmsdev = drm_device_to_vkms_device(dev);
> +
> + seq_printf(m, "writeback=%d\n", vkmsdev->config->writeback);
> + seq_printf(m, "cursor=%d\n", vkmsdev->config->cursor);
> + seq_printf(m, "overlay=%d\n", vkmsdev->config->overlay);
> +
> + return 0;
> +}
> +
> +static const struct drm_info_list vkms_config_debugfs_list[] = {
> + { "vkms_config", vkms_config_show, 0 },
> +};
> +
> +static void vkms_config_debugfs_init(struct drm_minor *minor)
> +{
> + drm_debugfs_create_files(vkms_config_debugfs_list, 
> ARRAY_SIZE(vkms_config_debugfs_list),
> +  minor->debugfs_root, minor);
> +}
> +
>  static const struct drm_driver vkms_driver = {
>   .driver_features= DRIVER_MODESET | DRIVER_ATOMIC | DRIVER_GEM,
>   .release= vkms_release,
>   .fops   = _driver_fops,
>   DRM_GEM_SHMEM_DRIVER_OPS,
>  
> + .debugfs_init   = vkms_config_debugfs_init,
> +
>   .name   = DRIVER_NAME,
>   .desc   = DRIVER_DESC,
>   .date   = DRIVER_DATE,
> -- 
> 2.25.1
> 

[PATCH v2] drm/vkms: update the current status of todo list

[Melissa Wen]

Update:
- debugging issues on igt testcases
- plane composition features: add primary plane improvements
- suggestions of good tasks to start working on vkms

Drop:
- syzkaller bug report:
  what triggered the warning was replaced by shmem functions at
  https://patchwork.freedesktop.org/patch/394614/
- overlay plane: this feature was added by
  https://patchwork.freedesktop.org/patch/430941/

---

v2:
- add task to enable multiple overlay planes (Simon)

Signed-off-by: Melissa Wen 
---
 Documentation/gpu/vkms.rst | 38 ++
 1 file changed, 26 insertions(+), 12 deletions(-)

diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
index 2c9b376da5ca..941f0e7e5eef 100644
--- a/Documentation/gpu/vkms.rst
+++ b/Documentation/gpu/vkms.rst
@@ -98,9 +98,17 @@ with VKMS maintainers.
 IGT better support
 --
 
-- Investigate: (1) test cases on kms_plane that are failing due to timeout on
-  capturing CRC; (2) when running kms_flip test cases in sequence, some
-  successful individual test cases are failing randomly.
+Debugging:
+
+- kms_plane: some test cases are failing due to timeout on capturing CRC;
+
+- kms_flip: when running test cases in sequence, some successful individual
+  test cases are failing randomly; when individually, some successful test
+  cases display in the log the following error::
+
+  [drm:vkms_prepare_fb [vkms]] ERROR vmap failed: -4
+
+Virtual hardware (vblank-less) mode:
 
 - VKMS already has support for vblanks simulated via hrtimers, which can be
   tested with kms_flip test; in some way, we can say that VKMS already mimics
@@ -116,7 +124,17 @@ Add Plane Features
 
 There's lots of plane features we could add support for:
 
-- Real overlay planes, not just cursor.
+- Multiple overlay planes. [Good to get started]
+
+- Clearing primary plane: clear primary plane before plane composition (at the
+  start) for correctness of pixel blend ops. It also guarantees alpha channel
+  is cleared in the target buffer for stable crc. [Good to get started]
+
+- ARGB format on primary plane: blend the primary plane into background with
+  translucent alpha.
+
+- Support when the primary plane isn't exactly matching the output size: blend
+  the primary plane into the black background.
 
 - Full alpha blending on all planes.
 
@@ -129,13 +147,8 @@ There's lots of plane features we could add support for:
   cursor api).
 
 For all of these, we also want to review the igt test coverage and make sure
-all relevant igt testcases work on vkms.
-
-Prime Buffer Sharing
-
-
-- Syzbot report - WARNING in vkms_gem_free_object:
-  https://syzkaller.appspot.com/bug?extid=e7ad70d406e74d8fc9d0
+all relevant igt testcases work on vkms. They are good options for internship
+project.
 
 Runtime Configuration
 -
@@ -153,7 +166,7 @@ module. Use/Test-cases:
   the refresh rate.
 
 The currently proposed solution is to expose vkms configuration through
-configfs.  All existing module options should be supported through configfs
+configfs. All existing module options should be supported through configfs
 too.
 
 Writeback support
@@ -162,6 +175,7 @@ Writeback support
 - The writeback and CRC capture operations share the use of composer_enabled
   boolean to ensure vblanks. Probably, when these operations work together,
   composer_enabled needs to refcounting the composer state to proper work.
+  [Good to get started]
 
 - Add support for cloned writeback outputs and related test cases using a
   cloned output in the IGT kms_writeback.
-- 
2.30.2

Re: [PATCH v4 24/27] drm/vkms: Don't set struct drm_device.irq_enabled

[Melissa Wen]

On 06/25, Thomas Zimmermann wrote:
> The field drm_device.irq_enabled is only used by legacy drivers
> with userspace modesetting. Don't set it in vkms.
> 
> Signed-off-by: Thomas Zimmermann 
> Reviewed-by: Laurent Pinchart 

I've also checked here, lgtm.

Reviewed-by: Melissa Wen 
> ---
>  drivers/gpu/drm/vkms/vkms_drv.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index 027ffe759440..496de38ad983 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -163,8 +163,6 @@ static int vkms_create(struct vkms_config *config)
>   goto out_devres;
>   }
>  
> - vkms_device->drm.irq_enabled = true;
> -
>   ret = drm_vblank_init(_device->drm, 1);
>   if (ret) {
>   DRM_ERROR("Failed to vblank\n");
> -- 
> 2.32.0
> 

Re: [PATCH 0/4] vkms: Switch to shadow-buffered plane state

[Melissa Wen]

On 07/06, Thomas Zimmermann wrote:
> Hi
> 
> Am 05.07.21 um 23:29 schrieb Melissa Wen:
> > On 07/05, Daniel Vetter wrote:
> > > On Mon, Jul 05, 2021 at 12:05:28PM +0200, Thomas Zimmermann wrote:
> > > > Hi
> > > > 
> > > > Am 05.07.21 um 11:27 schrieb Daniel Vetter:
> > > > > On Mon, Jul 05, 2021 at 09:46:29AM +0200, Thomas Zimmermann wrote:
> > > > > > Vkms copies each plane's framebuffer into the output buffer; 
> > > > > > essentially
> > > > > > using a shadow buffer. DRM provides struct drm_shadow_plane_state, 
> > > > > > which
> > > > > > handles the details of mapping/unmapping shadow buffers into memory 
> > > > > > for
> > > > > > active planes.
> > > > > > 
> > > > > > Convert vkms to the helpers. Makes vkms use shared code and gives 
> > > > > > more
> > > > > > test exposure to shadow-plane helpers.
> > > > > > 
> > > > > > Thomas Zimmermann (4):
> > > > > > drm/gem: Export implementation of shadow-plane helpers
> > > > > > drm/vkms: Inherit plane state from struct drm_shadow_plane_state
> > > > > > drm/vkms: Let shadow-plane helpers prepare the plane's FB
> > > > > > drm/vkms: Use dma-buf mapping from shadow-plane state for 
> > > > > > composing
> > > > > 
> > > > > So I think right now this fits, but I think it'll mismit going 
> > > > > forward: We
> > > > > don't really have a shadow-plane that we then toss to the hw, it's a
> > > > > shadow-crtc-area. Right now there's no difference, because we don't
> > > > > support positioning/scaling the primary plane. But that's all kinda 
> > > > > stuff
> > > > > that's on the table.
> > > > > 
> > > > > But conceptually at least the compositioning buffer should bet part 
> > > > > of the
> > > > > crtc, not of the primary plane.
> > > > > 
> > > > > So not sure what to do, but also coffee hasn't kicked in yet, so 
> > > > > maybe I'm
> > > > > just confused.
> > > > 
> > > > I'm not sure if I understand your concern. Can you elaborate? The
> > > > compositing output buffer is not affected by this patchset. Only the 
> > > > input
> > > > frambuffers of the planes. Those are shadow buffers. AFAICT the composer
> > > > code memcpy's the primary plane and then blends the other planes on top.
> > > > Supporting transformation of the primary plane doesn't really change 
> > > > much
> > > > wrt to the vmaping of input fbs.
> > > 
> > > Yeah that's the current implementation, because that's easier. But
> > > fundamentally we don't need a copy of the input shadow plane, we need a
> > > scratch area that's sized for the crtc.
> > 
> > Maybe I'm missing something, but I am not sure the relevance for vkms to
> > switch to shadow-buffered plane. (?)
> 
> It replaces the vkms code with shared code. Nothing else. For the shared
> shadow-buffer code it means more testing. If vkms ever supports color
> formats that use multiple planes, the new code will be ready.
Hi,

lgtm.

For debug history, can you please include in the description of the
third patch (shadow-plane helpers to prepare fb) that vmap failure is no
longer displayed in the execution some IGT kms_flip testcases?

For the series:
Reviewed-by: Melissa Wen 

Thanks,
Melissa
> 
> Best regards
> Thomas
> 
> 
> -- 
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
> 

Re: [PATCH 0/4] vkms: Switch to shadow-buffered plane state

[Melissa Wen]

On 07/05, Daniel Vetter wrote:
> On Mon, Jul 05, 2021 at 12:05:28PM +0200, Thomas Zimmermann wrote:
> > Hi
> > 
> > Am 05.07.21 um 11:27 schrieb Daniel Vetter:
> > > On Mon, Jul 05, 2021 at 09:46:29AM +0200, Thomas Zimmermann wrote:
> > > > Vkms copies each plane's framebuffer into the output buffer; essentially
> > > > using a shadow buffer. DRM provides struct drm_shadow_plane_state, which
> > > > handles the details of mapping/unmapping shadow buffers into memory for
> > > > active planes.
> > > > 
> > > > Convert vkms to the helpers. Makes vkms use shared code and gives more
> > > > test exposure to shadow-plane helpers.
> > > > 
> > > > Thomas Zimmermann (4):
> > > >drm/gem: Export implementation of shadow-plane helpers
> > > >drm/vkms: Inherit plane state from struct drm_shadow_plane_state
> > > >drm/vkms: Let shadow-plane helpers prepare the plane's FB
> > > >drm/vkms: Use dma-buf mapping from shadow-plane state for composing
> > > 
> > > So I think right now this fits, but I think it'll mismit going forward: We
> > > don't really have a shadow-plane that we then toss to the hw, it's a
> > > shadow-crtc-area. Right now there's no difference, because we don't
> > > support positioning/scaling the primary plane. But that's all kinda stuff
> > > that's on the table.
> > > 
> > > But conceptually at least the compositioning buffer should bet part of the
> > > crtc, not of the primary plane.
> > > 
> > > So not sure what to do, but also coffee hasn't kicked in yet, so maybe I'm
> > > just confused.
> > 
> > I'm not sure if I understand your concern. Can you elaborate? The
> > compositing output buffer is not affected by this patchset. Only the input
> > frambuffers of the planes. Those are shadow buffers. AFAICT the composer
> > code memcpy's the primary plane and then blends the other planes on top.
> > Supporting transformation of the primary plane doesn't really change much
> > wrt to the vmaping of input fbs.
> 
> Yeah that's the current implementation, because that's easier. But
> fundamentally we don't need a copy of the input shadow plane, we need a
> scratch area that's sized for the crtc.

Maybe I'm missing something, but I am not sure the relevance for vkms to
switch to shadow-buffered plane. (?)

Btw, in terms of code changes, it works well and also vmap error stops
to happen (reported in the last update of todo list). This fix seems to
be a side-effect because it replaces the vkms_prepare_fb that got
problematic since (I guess) the last switch to shmem. 

Thanks,
Melissa

> So if the primary plane is smaller than the crtc window (because we use
> plane hw for compositing, or maybe primary plane shows a vidoe with black
> borders or whatever), then the primary plane shadow isn't the right size.
> 
> And yes this means some surgery, vkms isn't there yet at all. But still it
> would mean we're going right here, but then have to backtrack before we
> can go left again. So a detour.
> 
> Also I don't think any other driver will ever need this, you really only
> need it when you want to composite planes in software - which defeats the
> purpose of planes. Except when the goal of your driver is to be a software
> model.
> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

Re: [PATCH v2] drm/vkms: Creating a debug file to get/track vkms config in vkms_drv.c

[Melissa Wen]

On 07/08, Beatriz Martins de Carvalho wrote:
> Creating a vkms_config_debufs file in vkms_drv.c to get/track vkms config
> data, for the long-term plan of making vkms configurable and have multiple
> different instances.
> 
> Reviewed-by: Melissa Wen 
> Signed-off-by: Beatriz Martins de Carvalho 
> 
Applied to drm-misc-next.
Small issues in the message were handled when applying.

Thanks,

Melissa
> ---
> Changes in v2:
> - corrected subject to make clear in terms of its purpose
> - corrected commit message
> ---
>  drivers/gpu/drm/vkms/vkms_drv.c | 28 
>  1 file changed, 28 insertions(+)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index 027ffe759440..c81fba6c72f0 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -28,6 +28,9 @@
>  
>  #include "vkms_drv.h"
>  
> +#include 
> +#include 
> +
>  #define DRIVER_NAME  "vkms"
>  #define DRIVER_DESC  "Virtual Kernel Mode Setting"
>  #define DRIVER_DATE  "20180514"
> @@ -86,12 +89,37 @@ static void vkms_atomic_commit_tail(struct 
> drm_atomic_state *old_state)
>   drm_atomic_helper_cleanup_planes(dev, old_state);
>  }
>  
> +static int vkms_config_show(struct seq_file *m, void *data)
> +{
> + struct drm_info_node *node = (struct drm_info_node *)m->private;
> + struct drm_device *dev = node->minor->dev;
> + struct vkms_device *vkmsdev = drm_device_to_vkms_device(dev);
> +
> + seq_printf(m, "writeback=%d\n", vkmsdev->config->writeback);
> + seq_printf(m, "cursor=%d\n", vkmsdev->config->cursor);
> + seq_printf(m, "overlay=%d\n", vkmsdev->config->overlay);
> +
> + return 0;
> +}
> +
> +static const struct drm_info_list vkms_config_debugfs_list[] = {
> + { "vkms_config", vkms_config_show, 0 },
> +};
> +
> +static void vkms_config_debugfs_init(struct drm_minor *minor)
> +{
> + drm_debugfs_create_files(vkms_config_debugfs_list, 
> ARRAY_SIZE(vkms_config_debugfs_list),
> +  minor->debugfs_root, minor);
> +}
> +
>  static const struct drm_driver vkms_driver = {
>   .driver_features= DRIVER_MODESET | DRIVER_ATOMIC | DRIVER_GEM,
>   .release= vkms_release,
>   .fops   = _driver_fops,
>   DRM_GEM_SHMEM_DRIVER_OPS,
>  
> + .debugfs_init   = vkms_config_debugfs_init,
> +
>   .name   = DRIVER_NAME,
>   .desc   = DRIVER_DESC,
>   .date   = DRIVER_DATE,
> -- 
> 2.25.1
> 

Re: [PATCH] drm/vkms: update the current status of todo list

[Melissa Wen]

On 04/25, Simon Ser wrote:
> On Saturday, April 24th, 2021 at 3:57 PM, Melissa Wen  
> wrote:
> 
> > -- Real overlay planes, not just cursor.
> 
> Maybe we should mention "multiple overlay planes" as a good task?

Sure. I'll include it.

Thanks for taking a look and pointing it out.

Melissa

> 
> Thanks,
> 
> Simon
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/vkms: update the current status of todo list

[Melissa Wen]

Update:
- debugging issues on igt testcases
- plane composition features: add primary plane improvements
- suggestions of good tasks to start working on vkms

Drop:
- syzkaller bug report:
  what triggered the warning was replaced by shmem functions at
  https://patchwork.freedesktop.org/patch/394614/
- overlay plane: this feature was added by
  https://patchwork.freedesktop.org/patch/430941/

Cc: Daniel Vetter 
Cc: Rodrigo Siqueira 
Cc: Sumera Priyadarsini 
Signed-off-by: Melissa Wen 
---
 Documentation/gpu/vkms.rst | 36 
 1 file changed, 24 insertions(+), 12 deletions(-)

diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
index 2c9b376da5ca..dbcb175da958 100644
--- a/Documentation/gpu/vkms.rst
+++ b/Documentation/gpu/vkms.rst
@@ -98,9 +98,17 @@ with VKMS maintainers.
 IGT better support
 --
 
-- Investigate: (1) test cases on kms_plane that are failing due to timeout on
-  capturing CRC; (2) when running kms_flip test cases in sequence, some
-  successful individual test cases are failing randomly.
+Debugging:
+
+- kms_plane: some test cases are failing due to timeout on capturing CRC;
+
+- kms_flip: when running test cases in sequence, some successful individual
+  test cases are failing randomly; when individually, some successful test
+  cases display in the log the following error::
+
+  [drm:vkms_prepare_fb [vkms]] ERROR vmap failed: -4
+
+Virtual hardware (vblank-less) mode:
 
 - VKMS already has support for vblanks simulated via hrtimers, which can be
   tested with kms_flip test; in some way, we can say that VKMS already mimics
@@ -116,7 +124,15 @@ Add Plane Features
 
 There's lots of plane features we could add support for:
 
-- Real overlay planes, not just cursor.
+- Clearing primary plane: clear primary plane before plane composition (at the
+  start) for correctness of pixel blend ops. It also guarantees alpha channel
+  is cleared in the target buffer for stable crc. [Good to start]
+
+- ARGB format on primary plane: blend the primary plane into background with
+  translucent alpha.
+
+- Support when the primary plane isn't exactly matching the output size: blend
+  the primary plane into the black background.
 
 - Full alpha blending on all planes.
 
@@ -129,13 +145,8 @@ There's lots of plane features we could add support for:
   cursor api).
 
 For all of these, we also want to review the igt test coverage and make sure
-all relevant igt testcases work on vkms.
-
-Prime Buffer Sharing
-
-
-- Syzbot report - WARNING in vkms_gem_free_object:
-  https://syzkaller.appspot.com/bug?extid=e7ad70d406e74d8fc9d0
+all relevant igt testcases work on vkms. They are good options for internship
+project.
 
 Runtime Configuration
 -
@@ -153,7 +164,7 @@ module. Use/Test-cases:
   the refresh rate.
 
 The currently proposed solution is to expose vkms configuration through
-configfs.  All existing module options should be supported through configfs
+configfs. All existing module options should be supported through configfs
 too.
 
 Writeback support
@@ -162,6 +173,7 @@ Writeback support
 - The writeback and CRC capture operations share the use of composer_enabled
   boolean to ensure vblanks. Probably, when these operations work together,
   composer_enabled needs to refcounting the composer state to proper work.
+  [Good to start]
 
 - Add support for cloned writeback outputs and related test cases using a
   cloned output in the IGT kms_writeback.
-- 
2.30.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 4/4] drm/vkms: add overlay support

[Melissa Wen]

On 04/26, Pekka Paalanen wrote:
> On Sat, 24 Apr 2021 05:26:10 -0300
> Melissa Wen  wrote:
> 
> > Add support to overlay plane, in addition to primary and cursor
> > planes. In this approach, the plane composition still requires an
> > active primary plane and planes are composed associatively in the
> > order: (primary <- overlay) <- cursor
> > 
> > It enables to run the following IGT tests successfully:
> > - kms_plane_cursor:
> >   - pipe-A-[overlay, primary, viewport]-size-[64, 128, 256]
> > - kms_atomic:
> >   - plane-overlay-legacy
> > and preserves the successful execution of kms_cursor_crc,
> > kms_writeback and kms_flip
> > 
> > Signed-off-by: Melissa Wen 
> > Reviewed-by: Daniel Vetter 
> 
> Hi,
> 
> just curious, when you need to compute a CRC without having a writeback
> connector output, where do you write the blended result in order to
> compute CRC?

Hi,

so, when no writeback output, an output frame is allocated in the
compose_planes functions to get the plane composition there, as shown
here: https://lkml.org/lkml/2020/8/30/163

Melissa

> 
> 
> Thanks,
> pq
> 
> > ---
> >  drivers/gpu/drm/vkms/vkms_composer.c | 27 +--
> >  drivers/gpu/drm/vkms/vkms_drv.c  |  5 +
> >  drivers/gpu/drm/vkms/vkms_drv.h  |  1 +
> >  drivers/gpu/drm/vkms/vkms_output.c   | 11 ++-
> >  drivers/gpu/drm/vkms/vkms_plane.c| 15 ---
> >  5 files changed, 45 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
> > b/drivers/gpu/drm/vkms/vkms_composer.c
> > index 7e01bc39d2a1..1b510f3dbcbf 100644
> > --- a/drivers/gpu/drm/vkms/vkms_composer.c
> > +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> > @@ -176,11 +176,12 @@ static void compose_plane(struct vkms_composer 
> > *primary_composer,
> >  
> >  static int compose_active_planes(void **vaddr_out,
> >  struct vkms_composer *primary_composer,
> > -struct vkms_composer *cursor_composer)
> > +struct vkms_crtc_state *crtc_state)
> >  {
> > struct drm_framebuffer *fb = _composer->fb;
> > struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0);
> > struct drm_gem_shmem_object *shmem_obj = to_drm_gem_shmem_obj(gem_obj);
> > +   int i;
> >  
> > if (!*vaddr_out) {
> > *vaddr_out = kzalloc(shmem_obj->base.size, GFP_KERNEL);
> > @@ -195,8 +196,14 @@ static int compose_active_planes(void **vaddr_out,
> >  
> > memcpy(*vaddr_out, shmem_obj->vaddr, shmem_obj->base.size);
> >  
> > -   if (cursor_composer)
> > -   compose_plane(primary_composer, cursor_composer, *vaddr_out);
> > +   /* If there are other planes besides primary, we consider the active
> > +* planes should be in z-order and compose them associatively:
> > +* ((primary <- overlay) <- cursor)
> > +*/
> > +   for (i = 1; i < crtc_state->num_active_planes; i++)
> > +   compose_plane(primary_composer,
> > + crtc_state->active_planes[i]->composer,
> > + *vaddr_out);
> >  
> > return 0;
> >  }
> > @@ -218,7 +225,7 @@ void vkms_composer_worker(struct work_struct *work)
> > struct drm_crtc *crtc = crtc_state->base.crtc;
> > struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
> > struct vkms_composer *primary_composer = NULL;
> > -   struct vkms_composer *cursor_composer = NULL;
> > +   struct vkms_plane_state *act_plane = NULL;
> > bool crc_pending, wb_pending;
> > void *vaddr_out = NULL;
> > u32 crc32 = 0;
> > @@ -242,11 +249,11 @@ void vkms_composer_worker(struct work_struct *work)
> > if (!crc_pending)
> > return;
> >  
> > -   if (crtc_state->num_active_planes >= 1)
> > -   primary_composer = crtc_state->active_planes[0]->composer;
> > -
> > -   if (crtc_state->num_active_planes == 2)
> > -   cursor_composer = crtc_state->active_planes[1]->composer;
> > +   if (crtc_state->num_active_planes >= 1) {
> > +   act_plane = crtc_state->active_planes[0];
> > +   if (act_plane->base.plane->type == DRM_PLANE_TYPE_PRIMARY)
> > +   primary_composer = act_plane->composer;
> > +   }
> >  
> > if (!primary_composer)
> > return;
> > @@ -255,7 +262,7 @@ void vkms_composer_worker(struct work_struct *wo

Re: [PATCH v4 3/4] drm/vkms: add XRGB planes composition

[Melissa Wen]

On 04/26, Daniel Vetter wrote:
> On Mon, Apr 26, 2021 at 11:03:15AM +0300, Pekka Paalanen wrote:
> > On Sat, 24 Apr 2021 05:25:31 -0300
> > Melissa Wen  wrote:
> > 
> > > Add support for composing XRGB888 planes in addition to the ARGB
> > > format. In the case of an XRGB plane at the top, the composition consists
> > > of copying the RGB values of a pixel from src to dst and clearing alpha
> > > channel, without the need for alpha blending operations for each pixel.
> > > 
> > > Blend equations assume a completely opaque background, i.e., primary plane
> > > is not cleared before pixel blending but alpha channel is explicitly
> > > opaque (a = 0xff). Also, there is room for performance evaluation in
> > > switching pixel blend operation according to the plane format.
> > > 
> > > v4:
> > > - clear alpha channel (0xff) after blend color values by pixel
> > > - improve comments on blend ops to reflect the current state
> > > - describe in the commit message future improvements for plane composition
> > > 
> > > Signed-off-by: Melissa Wen 
> > > Reviewed-by: Daniel Vetter 
> > > ---
> > >  drivers/gpu/drm/vkms/vkms_composer.c | 56 ++--
> > >  drivers/gpu/drm/vkms/vkms_plane.c|  7 ++--
> > >  2 files changed, 48 insertions(+), 15 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
> > > b/drivers/gpu/drm/vkms/vkms_composer.c
> > > index 02642801735d..7e01bc39d2a1 100644
> > > --- a/drivers/gpu/drm/vkms/vkms_composer.c
> > > +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> > > @@ -4,6 +4,7 @@
> > >  
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -64,7 +65,17 @@ static u8 blend_channel(u8 src, u8 dst, u8 alpha)
> > >   return new_color;
> > >  }
> > >  
> > > -static void alpha_blending(const u8 *argb_src, u8 *argb_dst)
> > > +/**
> > > + * alpha_blend - alpha blending equation
> > > + * @argb_src: src pixel on premultiplied alpha mode
> > > + * @argb_dst: dst pixel completely opaque
> > > + *
> > > + * blend pixels using premultiplied blend formula. The current DRM 
> > > assumption
> > > + * is that pixel color values have been already pre-multiplied with the 
> > > alpha
> > > + * channel values. See more drm_plane_create_blend_mode_property(). 
> > > Also, this
> > > + * formula assumes a completely opaque background.
> > > + */
> > > +static void alpha_blend(const u8 *argb_src, u8 *argb_dst)
> > >  {
> > >   u8 alpha;
> > >  
> > > @@ -72,8 +83,16 @@ static void alpha_blending(const u8 *argb_src, u8 
> > > *argb_dst)
> > >   argb_dst[0] = blend_channel(argb_src[0], argb_dst[0], alpha);
> > >   argb_dst[1] = blend_channel(argb_src[1], argb_dst[1], alpha);
> > >   argb_dst[2] = blend_channel(argb_src[2], argb_dst[2], alpha);
> > > - /* Opaque primary */
> > > - argb_dst[3] = 0xFF;
> > > +}
> > > +
> > > +/**
> > > + * x_blend - blending equation that ignores the pixel alpha
> > > + *
> > > + * overwrites RGB color value from src pixel to dst pixel.
> > > + */
> > > +static void x_blend(const u8 *xrgb_src, u8 *xrgb_dst)
> > > +{
> > > + memcpy(xrgb_dst, xrgb_src, sizeof(u8) * 3);
> > 
> > Hi,
> > 
> > this function very clearly assumes a very specific pixel format on both
> > source and destination. I think it would be good if the code comments
> > called out exactly which DRM_FORMAT_* they assume. This would be good
> > to do on almost every function that makes such assumptions. I believe that
> > would help code readability, and also point out explicitly which things
> > need to be fixed when you add support for even more pixel formats.
> > 
> > "xrgb" and "argb" are IMO too vague. You might be referring to
> > DRM_FORMAT_XRGB* and DRM_FORMAT_ARGB*, or maybe you are referring to any
> > pixel format that happens to have or not have an alpha channel in
> > addition to the three RGB channels in some order and width.
> > 
> > Being explicit that these refer to specific DRM_FORMAT_* should also
> > help understanding how things work on big-endian CPUs. My current
> > understanding is that this memcpy is correct also on big-endian, given
> > DRM_FORMAT_XRGB.

This endianess issue

Re: [PATCH v4 3/4] drm/vkms: add XRGB planes composition

[Melissa Wen]

On 04/27, Pekka Paalanen wrote:
> On Mon, 26 Apr 2021 14:31:28 -0300
> Melissa Wen  wrote:
> 
> > On 04/26, Daniel Vetter wrote:
> > > On Mon, Apr 26, 2021 at 11:03:15AM +0300, Pekka Paalanen wrote:  
> > > > On Sat, 24 Apr 2021 05:25:31 -0300
> > > > Melissa Wen  wrote:
> > > >   
> > > > > Add support for composing XRGB888 planes in addition to the ARGB
> > > > > format. In the case of an XRGB plane at the top, the composition 
> > > > > consists
> > > > > of copying the RGB values of a pixel from src to dst and clearing 
> > > > > alpha
> > > > > channel, without the need for alpha blending operations for each 
> > > > > pixel.
> > > > > 
> > > > > Blend equations assume a completely opaque background, i.e., primary 
> > > > > plane
> > > > > is not cleared before pixel blending but alpha channel is explicitly
> > > > > opaque (a = 0xff). Also, there is room for performance evaluation in
> > > > > switching pixel blend operation according to the plane format.
> > > > > 
> > > > > v4:
> > > > > - clear alpha channel (0xff) after blend color values by pixel
> > > > > - improve comments on blend ops to reflect the current state
> > > > > - describe in the commit message future improvements for plane 
> > > > > composition
> > > > > 
> > > > > Signed-off-by: Melissa Wen 
> > > > > Reviewed-by: Daniel Vetter 
> > > > > ---
> > > > >  drivers/gpu/drm/vkms/vkms_composer.c | 56 
> > > > > ++--
> > > > >  drivers/gpu/drm/vkms/vkms_plane.c|  7 ++--
> > > > >  2 files changed, 48 insertions(+), 15 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
> > > > > b/drivers/gpu/drm/vkms/vkms_composer.c
> > > > > index 02642801735d..7e01bc39d2a1 100644
> > > > > --- a/drivers/gpu/drm/vkms/vkms_composer.c
> > > > > +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> > > > > @@ -4,6 +4,7 @@
> > > > >  
> > > > >  #include 
> > > > >  #include 
> > > > > +#include 
> > > > >  #include 
> > > > >  #include 
> > > > >  #include 
> > > > > @@ -64,7 +65,17 @@ static u8 blend_channel(u8 src, u8 dst, u8 alpha)
> > > > >   return new_color;
> > > > >  }
> > > > >  
> > > > > -static void alpha_blending(const u8 *argb_src, u8 *argb_dst)
> > > > > +/**
> > > > > + * alpha_blend - alpha blending equation
> > > > > + * @argb_src: src pixel on premultiplied alpha mode
> > > > > + * @argb_dst: dst pixel completely opaque
> > > > > + *
> > > > > + * blend pixels using premultiplied blend formula. The current DRM 
> > > > > assumption
> > > > > + * is that pixel color values have been already pre-multiplied with 
> > > > > the alpha
> > > > > + * channel values. See more drm_plane_create_blend_mode_property(). 
> > > > > Also, this
> > > > > + * formula assumes a completely opaque background.
> > > > > + */
> > > > > +static void alpha_blend(const u8 *argb_src, u8 *argb_dst)
> > > > >  {
> > > > >   u8 alpha;
> > > > >  
> > > > > @@ -72,8 +83,16 @@ static void alpha_blending(const u8 *argb_src, u8 
> > > > > *argb_dst)
> > > > >   argb_dst[0] = blend_channel(argb_src[0], argb_dst[0], alpha);
> > > > >   argb_dst[1] = blend_channel(argb_src[1], argb_dst[1], alpha);
> > > > >   argb_dst[2] = blend_channel(argb_src[2], argb_dst[2], alpha);
> > > > > - /* Opaque primary */
> > > > > - argb_dst[3] = 0xFF;
> > > > > +}
> > > > > +
> > > > > +/**
> > > > > + * x_blend - blending equation that ignores the pixel alpha
> > > > > + *
> > > > > + * overwrites RGB color value from src pixel to dst pixel.
> > > > > + */
> > > > > +static void x_blend(const u8 *xrgb_src, u8 *xrgb_dst)
> > > > > +{
> > > > > + memcpy(xrgb_dst, xrgb_src, sizeof(u8) * 3);  
> > > > 
> > > > Hi,
> > > > 
>

[PATCH v4 0/4] drm/vkms: add overlay plane support

[Melissa Wen]

Adding support to overlay type in addition to primary and cursor plane.
The planes composition relies on the z order of the active planes and
only occurs if there is a primary plane (as in the current behavior).

The first patch switches the function of initializing planes from
drm_universal_plane_init to drmm_universal_plane_alloc. It aims to
improve aspects of allocation and cleanup operations, leaving it to the
DRM infrastructure.

The second patch generalizes variables and functions names to refer to
any kind of plane, not only cursor. The goal is to reuse them for
blending overlay and cursor planes to primary.

The third patch enables the plane composition to select a pixel blend
operation according to the plane format (XRGB or ARGB).

The last patch creates a module option to enable overlay, and includes
overlay to supported types of plane. When the overlay option is enabled,
one overlay plane is initialized (plus primary and cursor) and it is
included in the planes composition.

This work preserves the current results of IGT tests: kms_cursor_crc;
kms_flip and kms_writeback. In addition, subtests related to overlay in
kms_atomic and kms_plane_cursor start to pass (pointed out in the commit
message).

v2:

- Drop unnecessary changes that init crtc without cursor (Daniel)
- Replace function to initialize planes (Daniel)
- Add proper pixel blending op according to the plane format (Daniel)

v3:

- Proper use of the variable funcs (kernel bot)
- Adjust the patch series format

v4:
- use better names for functions of plane composition (Daniel)
- clear alpha channel (0xff) after blend color values by pixel
- improve comments on blend ops to reflect the current state
- describe in the commit message future improvements for plane composition

Melissa Wen (4):
  drm/vkms: init plane using drmm_universal_plane_alloc
  drm/vkms: rename cursor to plane on ops of planes composition
  drm/vkms: add XRGB planes composition
  drm/vkms: add overlay support

 drivers/gpu/drm/vkms/vkms_composer.c | 104 ++-
 drivers/gpu/drm/vkms/vkms_drv.c  |   5 ++
 drivers/gpu/drm/vkms/vkms_drv.h  |   9 ++-
 drivers/gpu/drm/vkms/vkms_output.c   |  28 
 drivers/gpu/drm/vkms/vkms_plane.c|  51 ++---
 5 files changed, 125 insertions(+), 72 deletions(-)

-- 
2.30.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 1/4] drm/vkms: init plane using drmm_universal_plane_alloc

[Melissa Wen]

By using drmm_universal_plane_alloc instead of
drm_universal_plane_init, we let the DRM infrastructure handles
resource allocation and cleanup. We can also get rid of some
code repetitions for plane cleanup, improving code maintainability
in vkms.

Signed-off-by: Melissa Wen 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/vkms/vkms_drv.h|  8 ++--
 drivers/gpu/drm/vkms/vkms_output.c | 19 +--
 drivers/gpu/drm/vkms/vkms_plane.c  | 29 +++--
 3 files changed, 22 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 35540c7c4416..70fb79621617 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -37,6 +37,10 @@ struct vkms_plane_state {
struct vkms_composer *composer;
 };
 
+struct vkms_plane {
+   struct drm_plane base;
+};
+
 /**
  * vkms_crtc_state - Driver specific CRTC state
  * @base: base CRTC state
@@ -114,8 +118,8 @@ int vkms_crtc_init(struct drm_device *dev, struct drm_crtc 
*crtc,
 
 int vkms_output_init(struct vkms_device *vkmsdev, int index);
 
-struct drm_plane *vkms_plane_init(struct vkms_device *vkmsdev,
- enum drm_plane_type type, int index);
+struct vkms_plane *vkms_plane_init(struct vkms_device *vkmsdev,
+  enum drm_plane_type type, int index);
 
 /* CRC Support */
 const char *const *vkms_get_crc_sources(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/vkms/vkms_output.c 
b/drivers/gpu/drm/vkms/vkms_output.c
index f5f6f15c362c..6979fbc7f821 100644
--- a/drivers/gpu/drm/vkms/vkms_output.c
+++ b/drivers/gpu/drm/vkms/vkms_output.c
@@ -39,7 +39,7 @@ int vkms_output_init(struct vkms_device *vkmsdev, int index)
struct drm_connector *connector = >connector;
struct drm_encoder *encoder = >encoder;
struct drm_crtc *crtc = >crtc;
-   struct drm_plane *primary, *cursor = NULL;
+   struct vkms_plane *primary, *cursor = NULL;
int ret;
int writeback;
 
@@ -49,15 +49,13 @@ int vkms_output_init(struct vkms_device *vkmsdev, int index)
 
if (vkmsdev->config->cursor) {
cursor = vkms_plane_init(vkmsdev, DRM_PLANE_TYPE_CURSOR, index);
-   if (IS_ERR(cursor)) {
-   ret = PTR_ERR(cursor);
-   goto err_cursor;
-   }
+   if (IS_ERR(cursor))
+   return PTR_ERR(cursor);
}
 
-   ret = vkms_crtc_init(dev, crtc, primary, cursor);
+   ret = vkms_crtc_init(dev, crtc, >base, >base);
if (ret)
-   goto err_crtc;
+   return ret;
 
ret = drm_connector_init(dev, connector, _connector_funcs,
 DRM_MODE_CONNECTOR_VIRTUAL);
@@ -100,12 +98,5 @@ int vkms_output_init(struct vkms_device *vkmsdev, int index)
 err_connector:
drm_crtc_cleanup(crtc);
 
-err_crtc:
-   if (vkmsdev->config->cursor)
-   drm_plane_cleanup(cursor);
-
-err_cursor:
-   drm_plane_cleanup(primary);
-
return ret;
 }
diff --git a/drivers/gpu/drm/vkms/vkms_plane.c 
b/drivers/gpu/drm/vkms/vkms_plane.c
index 6d310d31b75d..135140f8e87a 100644
--- a/drivers/gpu/drm/vkms/vkms_plane.c
+++ b/drivers/gpu/drm/vkms/vkms_plane.c
@@ -86,7 +86,6 @@ static void vkms_plane_reset(struct drm_plane *plane)
 static const struct drm_plane_funcs vkms_plane_funcs = {
.update_plane   = drm_atomic_helper_update_plane,
.disable_plane  = drm_atomic_helper_disable_plane,
-   .destroy= drm_plane_cleanup,
.reset  = vkms_plane_reset,
.atomic_duplicate_state = vkms_plane_duplicate_state,
.atomic_destroy_state   = vkms_plane_destroy_state,
@@ -191,18 +190,14 @@ static const struct drm_plane_helper_funcs 
vkms_primary_helper_funcs = {
.cleanup_fb = vkms_cleanup_fb,
 };
 
-struct drm_plane *vkms_plane_init(struct vkms_device *vkmsdev,
- enum drm_plane_type type, int index)
+struct vkms_plane *vkms_plane_init(struct vkms_device *vkmsdev,
+  enum drm_plane_type type, int index)
 {
struct drm_device *dev = >drm;
const struct drm_plane_helper_funcs *funcs;
-   struct drm_plane *plane;
+   struct vkms_plane *plane;
const u32 *formats;
-   int ret, nformats;
-
-   plane = kzalloc(sizeof(*plane), GFP_KERNEL);
-   if (!plane)
-   return ERR_PTR(-ENOMEM);
+   int nformats;
 
if (type == DRM_PLANE_TYPE_CURSOR) {
formats = vkms_cursor_formats;
@@ -214,16 +209,14 @@ struct drm_plane *vkms_plane_init(struct vkms_device 
*vkmsdev,
funcs = _primary_helper_funcs;
}
 
-   ret = drm_universal_plane_init(dev, plane, 1 << index,
-  _plane_funcs,
- 

[PATCH v4 2/4] drm/vkms: rename cursor to plane on ops of planes composition

[Melissa Wen]

Generalize variables and function names used for planes composition
(from cursor to plane), since we will reuse the operations for both
cursor and overlay types.

No functional change.

v4:
- use better names for functions of plane composition (Daniel)

Signed-off-by: Melissa Wen 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/vkms/vkms_composer.c | 31 ++--
 1 file changed, 16 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
b/drivers/gpu/drm/vkms/vkms_composer.c
index 66c6842d70db..02642801735d 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -125,26 +125,26 @@ static void blend(void *vaddr_dst, void *vaddr_src,
}
 }
 
-static void compose_cursor(struct vkms_composer *cursor_composer,
-  struct vkms_composer *primary_composer,
-  void *vaddr_out)
+static void compose_plane(struct vkms_composer *primary_composer,
+ struct vkms_composer *plane_composer,
+ void *vaddr_out)
 {
-   struct drm_gem_object *cursor_obj;
-   struct drm_gem_shmem_object *cursor_shmem_obj;
+   struct drm_gem_object *plane_obj;
+   struct drm_gem_shmem_object *plane_shmem_obj;
 
-   cursor_obj = drm_gem_fb_get_obj(_composer->fb, 0);
-   cursor_shmem_obj = to_drm_gem_shmem_obj(cursor_obj);
+   plane_obj = drm_gem_fb_get_obj(_composer->fb, 0);
+   plane_shmem_obj = to_drm_gem_shmem_obj(plane_obj);
 
-   if (WARN_ON(!cursor_shmem_obj->vaddr))
+   if (WARN_ON(!plane_shmem_obj->vaddr))
return;
 
-   blend(vaddr_out, cursor_shmem_obj->vaddr,
- primary_composer, cursor_composer);
+   blend(vaddr_out, plane_shmem_obj->vaddr,
+ primary_composer, plane_composer);
 }
 
-static int compose_planes(void **vaddr_out,
- struct vkms_composer *primary_composer,
- struct vkms_composer *cursor_composer)
+static int compose_active_planes(void **vaddr_out,
+struct vkms_composer *primary_composer,
+struct vkms_composer *cursor_composer)
 {
struct drm_framebuffer *fb = _composer->fb;
struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0);
@@ -164,7 +164,7 @@ static int compose_planes(void **vaddr_out,
memcpy(*vaddr_out, shmem_obj->vaddr, shmem_obj->base.size);
 
if (cursor_composer)
-   compose_cursor(cursor_composer, primary_composer, *vaddr_out);
+   compose_plane(primary_composer, cursor_composer, *vaddr_out);
 
return 0;
 }
@@ -222,7 +222,8 @@ void vkms_composer_worker(struct work_struct *work)
if (wb_pending)
vaddr_out = crtc_state->active_writeback;
 
-   ret = compose_planes(_out, primary_composer, cursor_composer);
+   ret = compose_active_planes(_out, primary_composer,
+   cursor_composer);
if (ret) {
if (ret == -EINVAL && !wb_pending)
kfree(vaddr_out);
-- 
2.30.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 3/4] drm/vkms: add XRGB planes composition

[Melissa Wen]

Add support for composing XRGB888 planes in addition to the ARGB
format. In the case of an XRGB plane at the top, the composition consists
of copying the RGB values of a pixel from src to dst and clearing alpha
channel, without the need for alpha blending operations for each pixel.

Blend equations assume a completely opaque background, i.e., primary plane
is not cleared before pixel blending but alpha channel is explicitly
opaque (a = 0xff). Also, there is room for performance evaluation in
switching pixel blend operation according to the plane format.

v4:
- clear alpha channel (0xff) after blend color values by pixel
- improve comments on blend ops to reflect the current state
- describe in the commit message future improvements for plane composition

Signed-off-by: Melissa Wen 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/vkms/vkms_composer.c | 56 ++--
 drivers/gpu/drm/vkms/vkms_plane.c|  7 ++--
 2 files changed, 48 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
b/drivers/gpu/drm/vkms/vkms_composer.c
index 02642801735d..7e01bc39d2a1 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -4,6 +4,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -64,7 +65,17 @@ static u8 blend_channel(u8 src, u8 dst, u8 alpha)
return new_color;
 }
 
-static void alpha_blending(const u8 *argb_src, u8 *argb_dst)
+/**
+ * alpha_blend - alpha blending equation
+ * @argb_src: src pixel on premultiplied alpha mode
+ * @argb_dst: dst pixel completely opaque
+ *
+ * blend pixels using premultiplied blend formula. The current DRM assumption
+ * is that pixel color values have been already pre-multiplied with the alpha
+ * channel values. See more drm_plane_create_blend_mode_property(). Also, this
+ * formula assumes a completely opaque background.
+ */
+static void alpha_blend(const u8 *argb_src, u8 *argb_dst)
 {
u8 alpha;
 
@@ -72,8 +83,16 @@ static void alpha_blending(const u8 *argb_src, u8 *argb_dst)
argb_dst[0] = blend_channel(argb_src[0], argb_dst[0], alpha);
argb_dst[1] = blend_channel(argb_src[1], argb_dst[1], alpha);
argb_dst[2] = blend_channel(argb_src[2], argb_dst[2], alpha);
-   /* Opaque primary */
-   argb_dst[3] = 0xFF;
+}
+
+/**
+ * x_blend - blending equation that ignores the pixel alpha
+ *
+ * overwrites RGB color value from src pixel to dst pixel.
+ */
+static void x_blend(const u8 *xrgb_src, u8 *xrgb_dst)
+{
+   memcpy(xrgb_dst, xrgb_src, sizeof(u8) * 3);
 }
 
 /**
@@ -82,16 +101,20 @@ static void alpha_blending(const u8 *argb_src, u8 
*argb_dst)
  * @vaddr_src: source address
  * @dst_composer: destination framebuffer's metadata
  * @src_composer: source framebuffer's metadata
+ * @pixel_blend: blending equation based on plane format
  *
- * Blend the vaddr_src value with the vaddr_dst value using the pre-multiplied
- * alpha blending equation, since DRM currently assumes that the pixel color
- * values have already been pre-multiplied with the alpha channel values. See
- * more drm_plane_create_blend_mode_property(). This function uses buffer's
- * metadata to locate the new composite values at vaddr_dst.
+ * Blend the vaddr_src value with the vaddr_dst value using a pixel blend
+ * equation according to the plane format and clearing alpha channel to an
+ * completely opaque background. This function uses buffer's metadata to locate
+ * the new composite values at vaddr_dst.
+ *
+ * TODO: completely clear the primary plane (a = 0xff) before starting to blend
+ * pixel color values
  */
 static void blend(void *vaddr_dst, void *vaddr_src,
  struct vkms_composer *dst_composer,
- struct vkms_composer *src_composer)
+ struct vkms_composer *src_composer,
+ void (*pixel_blend)(const u8 *, u8 *))
 {
int i, j, j_dst, i_dst;
int offset_src, offset_dst;
@@ -119,7 +142,9 @@ static void blend(void *vaddr_dst, void *vaddr_src,
 
pixel_src = (u8 *)(vaddr_src + offset_src);
pixel_dst = (u8 *)(vaddr_dst + offset_dst);
-   alpha_blending(pixel_src, pixel_dst);
+   pixel_blend(pixel_src, pixel_dst);
+   /* clearing alpha channel (0xff)*/
+   memset(vaddr_dst + offset_dst + 3, 0xff, 1);
}
i_dst++;
}
@@ -131,6 +156,8 @@ static void compose_plane(struct vkms_composer 
*primary_composer,
 {
struct drm_gem_object *plane_obj;
struct drm_gem_shmem_object *plane_shmem_obj;
+   struct drm_framebuffer *fb = _composer->fb;
+   void (*pixel_blend)(const u8 *p_src, u8 *p_dst);
 
plane_obj = drm_gem_fb_get_obj(_composer->fb, 0);
plane_shmem_obj = to_drm_gem_shmem_obj(plane_obj);
@@ -138,8 +165,13 @@ static void compose_plane(struct vkms_composer 
*primary_co

[PATCH v4 4/4] drm/vkms: add overlay support

[Melissa Wen]

Add support to overlay plane, in addition to primary and cursor
planes. In this approach, the plane composition still requires an
active primary plane and planes are composed associatively in the
order: (primary <- overlay) <- cursor

It enables to run the following IGT tests successfully:
- kms_plane_cursor:
  - pipe-A-[overlay, primary, viewport]-size-[64, 128, 256]
- kms_atomic:
  - plane-overlay-legacy
and preserves the successful execution of kms_cursor_crc,
kms_writeback and kms_flip

Signed-off-by: Melissa Wen 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/vkms/vkms_composer.c | 27 +--
 drivers/gpu/drm/vkms/vkms_drv.c  |  5 +
 drivers/gpu/drm/vkms/vkms_drv.h  |  1 +
 drivers/gpu/drm/vkms/vkms_output.c   | 11 ++-
 drivers/gpu/drm/vkms/vkms_plane.c| 15 ---
 5 files changed, 45 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
b/drivers/gpu/drm/vkms/vkms_composer.c
index 7e01bc39d2a1..1b510f3dbcbf 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -176,11 +176,12 @@ static void compose_plane(struct vkms_composer 
*primary_composer,
 
 static int compose_active_planes(void **vaddr_out,
 struct vkms_composer *primary_composer,
-struct vkms_composer *cursor_composer)
+struct vkms_crtc_state *crtc_state)
 {
struct drm_framebuffer *fb = _composer->fb;
struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0);
struct drm_gem_shmem_object *shmem_obj = to_drm_gem_shmem_obj(gem_obj);
+   int i;
 
if (!*vaddr_out) {
*vaddr_out = kzalloc(shmem_obj->base.size, GFP_KERNEL);
@@ -195,8 +196,14 @@ static int compose_active_planes(void **vaddr_out,
 
memcpy(*vaddr_out, shmem_obj->vaddr, shmem_obj->base.size);
 
-   if (cursor_composer)
-   compose_plane(primary_composer, cursor_composer, *vaddr_out);
+   /* If there are other planes besides primary, we consider the active
+* planes should be in z-order and compose them associatively:
+* ((primary <- overlay) <- cursor)
+*/
+   for (i = 1; i < crtc_state->num_active_planes; i++)
+   compose_plane(primary_composer,
+ crtc_state->active_planes[i]->composer,
+ *vaddr_out);
 
return 0;
 }
@@ -218,7 +225,7 @@ void vkms_composer_worker(struct work_struct *work)
struct drm_crtc *crtc = crtc_state->base.crtc;
struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
struct vkms_composer *primary_composer = NULL;
-   struct vkms_composer *cursor_composer = NULL;
+   struct vkms_plane_state *act_plane = NULL;
bool crc_pending, wb_pending;
void *vaddr_out = NULL;
u32 crc32 = 0;
@@ -242,11 +249,11 @@ void vkms_composer_worker(struct work_struct *work)
if (!crc_pending)
return;
 
-   if (crtc_state->num_active_planes >= 1)
-   primary_composer = crtc_state->active_planes[0]->composer;
-
-   if (crtc_state->num_active_planes == 2)
-   cursor_composer = crtc_state->active_planes[1]->composer;
+   if (crtc_state->num_active_planes >= 1) {
+   act_plane = crtc_state->active_planes[0];
+   if (act_plane->base.plane->type == DRM_PLANE_TYPE_PRIMARY)
+   primary_composer = act_plane->composer;
+   }
 
if (!primary_composer)
return;
@@ -255,7 +262,7 @@ void vkms_composer_worker(struct work_struct *work)
vaddr_out = crtc_state->active_writeback;
 
ret = compose_active_planes(_out, primary_composer,
-   cursor_composer);
+   crtc_state);
if (ret) {
if (ret == -EINVAL && !wb_pending)
kfree(vaddr_out);
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index 2173b82606f6..027ffe759440 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -44,6 +44,10 @@ static bool enable_writeback = true;
 module_param_named(enable_writeback, enable_writeback, bool, 0444);
 MODULE_PARM_DESC(enable_writeback, "Enable/Disable writeback connector 
support");
 
+static bool enable_overlay;
+module_param_named(enable_overlay, enable_overlay, bool, 0444);
+MODULE_PARM_DESC(enable_overlay, "Enable/Disable overlay support");
+
 DEFINE_DRM_GEM_FOPS(vkms_driver_fops);
 
 static void vkms_release(struct drm_device *dev)
@@ -198,6 +202,7 @@ static int __init vkms_init(void)
 
config->cursor = enable_cursor;
config->writeback = enable_writeback;
+   config->overlay = enable_overlay;
 
 

Re: [PATCH] drm/vkms: fix misuse of WARN_ON

[Melissa Wen]

On 03/25, Dmitry Vyukov wrote:
> On Wed, Mar 24, 2021 at 11:00 PM Melissa Wen  wrote:
> >
> > On 03/20, Dmitry Vyukov wrote:
> > > vkms_vblank_simulate() uses WARN_ON for timing-dependent condition
> > > (timer overrun). This is a mis-use of WARN_ON, WARN_ON must be used
> > > to denote kernel bugs. Use pr_warn() instead.
> > >
> > > Signed-off-by: Dmitry Vyukov 
> > > Reported-by: syzbot+4fc21a003c8332eb0...@syzkaller.appspotmail.com
> > > Cc: Rodrigo Siqueira 
> > > Cc: Melissa Wen 
> > > Cc: Haneen Mohammed 
> > > Cc: Daniel Vetter 
> > > Cc: David Airlie 
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc: linux-ker...@vger.kernel.org
> > > Change-Id: I7f01c288092bc7e472ec63af198f93ce3d8c49f7
> > > ---
> > >  drivers/gpu/drm/vkms/vkms_crtc.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c 
> > > b/drivers/gpu/drm/vkms/vkms_crtc.c
> > > index 0443b7deeaef6..758d8a98d96b3 100644
> > > --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> > > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> > > @@ -18,7 +18,8 @@ static enum hrtimer_restart vkms_vblank_simulate(struct 
> > > hrtimer *timer)
> > >
> > >   ret_overrun = hrtimer_forward_now(>vblank_hrtimer,
> > > output->period_ns);
> > > - WARN_ON(ret_overrun != 1);
> > > + if (ret_overrun != 1)
> > > + pr_warn("%s: vblank timer overrun\n", __func__);
> >
> > Hi Dmitry,
> >
> > Thanks for your patch.
> >
> > Looks good to me.
> > The Change-Id tag just seems a little noisy to me, but can be
> > fixed while applying.
> 
> Yes, please drop Change-Id when applying if possible. Sorry for that.
> Thanks for the review, Melissa.

Applied to drm-misc-next.

Thanks,

Melissa
> 
> > Acked-by: Melissa Wen 
> >
> > >
> > >   spin_lock(>lock);
> > >   ret = drm_crtc_handle_vblank(crtc);
> > >
> > > base-commit: e94c55b8e0a0bbe9a026250cf31e2fa45957d776
> > > --
> > > 2.31.0.291.g576ba9dcdaf-goog
> > >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vkms: fix misuse of WARN_ON

[Melissa Wen]

On 03/20, Dmitry Vyukov wrote:
> vkms_vblank_simulate() uses WARN_ON for timing-dependent condition
> (timer overrun). This is a mis-use of WARN_ON, WARN_ON must be used
> to denote kernel bugs. Use pr_warn() instead.
> 
> Signed-off-by: Dmitry Vyukov 
> Reported-by: syzbot+4fc21a003c8332eb0...@syzkaller.appspotmail.com
> Cc: Rodrigo Siqueira 
> Cc: Melissa Wen 
> Cc: Haneen Mohammed 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
> Change-Id: I7f01c288092bc7e472ec63af198f93ce3d8c49f7
> ---
>  drivers/gpu/drm/vkms/vkms_crtc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c 
> b/drivers/gpu/drm/vkms/vkms_crtc.c
> index 0443b7deeaef6..758d8a98d96b3 100644
> --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> @@ -18,7 +18,8 @@ static enum hrtimer_restart vkms_vblank_simulate(struct 
> hrtimer *timer)
>  
>   ret_overrun = hrtimer_forward_now(>vblank_hrtimer,
> output->period_ns);
> - WARN_ON(ret_overrun != 1);
> + if (ret_overrun != 1)
> + pr_warn("%s: vblank timer overrun\n", __func__);

Hi Dmitry,

Thanks for your patch.

Looks good to me.
The Change-Id tag just seems a little noisy to me, but can be
fixed while applying.

Acked-by: Melissa Wen 

>  
>   spin_lock(>lock);
>   ret = drm_crtc_handle_vblank(crtc);
> 
> base-commit: e94c55b8e0a0bbe9a026250cf31e2fa45957d776
> -- 
> 2.31.0.291.g576ba9dcdaf-goog
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 3/3] drm/vkms: add overlay support

[Melissa Wen]

On 02/22, Daniel Vetter wrote:
> On Sat, Feb 20, 2021 at 11:42:12AM -0300, Melissa Wen wrote:
> > Add support to overlay plane, in addition to primary and cursor
> > planes. In this approach, the plane composition still requires an
> > active primary plane and planes are composed associatively in the
> > order: (primary <- overlay) <- cursor
> > 
> > It enables to run the following IGT tests successfully:
> > - kms_plane_cursor:
> >   - pipe-A-[overlay, primary, viewport]-size-[64, 128, 256]
> > - kms_atomic:
> >   - plane-overlay-legacy
> > and preserves the successful execution of kms_cursor_crc,
> > kms_writeback and kms_flip
> > 
> > Signed-off-by: Melissa Wen 
> > ---
> >  drivers/gpu/drm/vkms/vkms_composer.c | 27 +--
> >  drivers/gpu/drm/vkms/vkms_drv.c  |  5 +
> >  drivers/gpu/drm/vkms/vkms_drv.h  |  1 +
> >  drivers/gpu/drm/vkms/vkms_output.c   | 17 +++--
> >  drivers/gpu/drm/vkms/vkms_plane.c| 20 +++-
> >  5 files changed, 53 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
> > b/drivers/gpu/drm/vkms/vkms_composer.c
> > index be8f1d33c645..2116da9b5a43 100644
> > --- a/drivers/gpu/drm/vkms/vkms_composer.c
> > +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> > @@ -144,11 +144,12 @@ static void compose_planes(struct vkms_composer 
> > *primary_composer,
> >  
> >  static int composite(void **vaddr_out,
> >  struct vkms_composer *primary_composer,
> > -struct vkms_composer *cursor_composer)
> > +struct vkms_crtc_state *crtc_state)
> >  {
> > struct drm_framebuffer *fb = _composer->fb;
> > struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0);
> > struct drm_gem_shmem_object *shmem_obj = to_drm_gem_shmem_obj(gem_obj);
> > +   int i;
> >  
> > if (!*vaddr_out) {
> > *vaddr_out = kzalloc(shmem_obj->base.size, GFP_KERNEL);
> > @@ -163,8 +164,14 @@ static int composite(void **vaddr_out,
> >  
> > memcpy(*vaddr_out, shmem_obj->vaddr, shmem_obj->base.size);
> >  
> > -   if (cursor_composer)
> > -   compose_planes(primary_composer, cursor_composer, *vaddr_out);
> > +   /* If there are other planes besides primary, we consider the active
> > +* planes should be in z-order and compose them associatively:
> > +* ((primary <- overlay) <- cursor)
> > +*/
> > +   for (i = 1; i < crtc_state->num_active_planes; i++)
> > +   compose_planes(primary_composer,
> > +  crtc_state->active_planes[i]->composer,
> > +  *vaddr_out);
> >  
> > return 0;
> >  }
> > @@ -186,7 +193,7 @@ void vkms_composer_worker(struct work_struct *work)
> > struct drm_crtc *crtc = crtc_state->base.crtc;
> > struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
> > struct vkms_composer *primary_composer = NULL;
> > -   struct vkms_composer *cursor_composer = NULL;
> > +   struct vkms_plane_state *act_plane = NULL;
> > bool crc_pending, wb_pending;
> > void *vaddr_out = NULL;
> > u32 crc32 = 0;
> > @@ -210,11 +217,11 @@ void vkms_composer_worker(struct work_struct *work)
> > if (!crc_pending)
> > return;
> >  
> > -   if (crtc_state->num_active_planes >= 1)
> > -   primary_composer = crtc_state->active_planes[0]->composer;
> > -
> > -   if (crtc_state->num_active_planes == 2)
> > -   cursor_composer = crtc_state->active_planes[1]->composer;
> > +   if (crtc_state->num_active_planes >= 1) {
> > +   act_plane = crtc_state->active_planes[0];
> > +   if (act_plane->base.plane->type == DRM_PLANE_TYPE_PRIMARY)
> > +   primary_composer = act_plane->composer;
> > +   }
> >  
> > if (!primary_composer)
> > return;
> > @@ -222,7 +229,7 @@ void vkms_composer_worker(struct work_struct *work)
> > if (wb_pending)
> > vaddr_out = crtc_state->active_writeback;
> >  
> > -   ret = composite(_out, primary_composer, cursor_composer);
> > +   ret = composite(_out, primary_composer, crtc_state);
> > if (ret) {
> > if (ret == -EINVAL && !wb_pending)
> > kfree(vaddr_out);
> > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c 
> > b/drivers/gpu/drm/vkms/vkms_drv.c
> > index 2173b82606f6..02

Re: [RFC PATCH 1/3] drm/vkms: decouple cursor plane setup from crtc_init

[Melissa Wen]

On 02/22, Daniel Vetter wrote:
> On Sat, Feb 20, 2021 at 11:38:50AM -0300, Melissa Wen wrote:
> > Initialize CRTC only with primary plane (without cursor) as a preparation
> > to init overlay plane before cursor plane and keep cursor on the top.
> > 
> > Signed-off-by: Melissa Wen 
> 
> Why can't we first initialize all the planes (primary, cursor, overlay)
> and then the crtc?
> 
> For drivers where there's not really a functional difference between these
> planes (like vkms, since it's all sw, only difference is z position
> really) the usual approach is to initialize all planes in a loop. And then
> call crtc init with the first and last plane for that crtc.
> 
Hi Daniel,

It was a misundertanding from my side. I thought that, besides to
initialize the planes, setting the possible_crtcs should also be done in
order.

Thanks for the feeback. I will discard this patch from the series.

Melissa

> Passing NULL for the cursor for crtc_init and then patching it up
> afterwards is a bit a hack, so would be good to avoid that.
> -Daniel
> 
> > ---
> >  drivers/gpu/drm/vkms/vkms_crtc.c   |  4 ++--
> >  drivers/gpu/drm/vkms/vkms_drv.h|  2 +-
> >  drivers/gpu/drm/vkms/vkms_output.c | 14 +-
> >  3 files changed, 12 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c 
> > b/drivers/gpu/drm/vkms/vkms_crtc.c
> > index 0443b7deeaef..2d4cd7736933 100644
> > --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> > @@ -270,12 +270,12 @@ static const struct drm_crtc_helper_funcs 
> > vkms_crtc_helper_funcs = {
> >  };
> >  
> >  int vkms_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
> > -  struct drm_plane *primary, struct drm_plane *cursor)
> > +  struct drm_plane *primary)
> >  {
> > struct vkms_output *vkms_out = drm_crtc_to_vkms_output(crtc);
> > int ret;
> >  
> > -   ret = drm_crtc_init_with_planes(dev, crtc, primary, cursor,
> > +   ret = drm_crtc_init_with_planes(dev, crtc, primary, NULL,
> > _crtc_funcs, NULL);
> > if (ret) {
> > DRM_ERROR("Failed to init CRTC\n");
> > diff --git a/drivers/gpu/drm/vkms/vkms_drv.h 
> > b/drivers/gpu/drm/vkms/vkms_drv.h
> > index 35540c7c4416..9ad5ad8b7737 100644
> > --- a/drivers/gpu/drm/vkms/vkms_drv.h
> > +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> > @@ -110,7 +110,7 @@ struct vkms_device {
> >  
> >  /* CRTC */
> >  int vkms_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
> > -  struct drm_plane *primary, struct drm_plane *cursor);
> > +  struct drm_plane *primary);
> >  
> >  int vkms_output_init(struct vkms_device *vkmsdev, int index);
> >  
> > diff --git a/drivers/gpu/drm/vkms/vkms_output.c 
> > b/drivers/gpu/drm/vkms/vkms_output.c
> > index f5f6f15c362c..05d3bb45e6c1 100644
> > --- a/drivers/gpu/drm/vkms/vkms_output.c
> > +++ b/drivers/gpu/drm/vkms/vkms_output.c
> > @@ -47,6 +47,10 @@ int vkms_output_init(struct vkms_device *vkmsdev, int 
> > index)
> > if (IS_ERR(primary))
> > return PTR_ERR(primary);
> >  
> > +   ret = vkms_crtc_init(dev, crtc, primary);
> > +   if (ret)
> > +   goto err_crtc;
> > +
> > if (vkmsdev->config->cursor) {
> > cursor = vkms_plane_init(vkmsdev, DRM_PLANE_TYPE_CURSOR, index);
> > if (IS_ERR(cursor)) {
> > @@ -55,9 +59,9 @@ int vkms_output_init(struct vkms_device *vkmsdev, int 
> > index)
> > }
> > }
> >  
> > -   ret = vkms_crtc_init(dev, crtc, primary, cursor);
> > -   if (ret)
> > -   goto err_crtc;
> > +   crtc->cursor = cursor;
> > +   if (cursor && !cursor->possible_crtcs)
> > +   cursor->possible_crtcs = drm_crtc_mask(crtc);
> >  
> > ret = drm_connector_init(dev, connector, _connector_funcs,
> >  DRM_MODE_CONNECTOR_VIRTUAL);
> > @@ -100,11 +104,11 @@ int vkms_output_init(struct vkms_device *vkmsdev, int 
> > index)
> >  err_connector:
> > drm_crtc_cleanup(crtc);
> >  
> > -err_crtc:
> > +err_cursor:
> > if (vkmsdev->config->cursor)
> > drm_plane_cleanup(cursor);
> >  
> > -err_cursor:
> > +err_crtc:
> > drm_plane_cleanup(primary);
> >  
> > return ret;
> > -- 
> > 2.30.0
> > 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 3/3] drm/vkms: add overlay support

[Melissa Wen]

On 02/23, Daniel Vetter wrote:
> On Tue, Feb 23, 2021 at 11:21 AM Melissa Wen  wrote:
> >
> > On 02/22, Daniel Vetter wrote:
> > > On Sat, Feb 20, 2021 at 11:42:12AM -0300, Melissa Wen wrote:
> > > > Add support to overlay plane, in addition to primary and cursor
> > > > planes. In this approach, the plane composition still requires an
> > > > active primary plane and planes are composed associatively in the
> > > > order: (primary <- overlay) <- cursor
> > > >
> > > > It enables to run the following IGT tests successfully:
> > > > - kms_plane_cursor:
> > > >   - pipe-A-[overlay, primary, viewport]-size-[64, 128, 256]
> > > > - kms_atomic:
> > > >   - plane-overlay-legacy
> > > > and preserves the successful execution of kms_cursor_crc,
> > > > kms_writeback and kms_flip
> > > >
> > > > Signed-off-by: Melissa Wen 
> > > > ---
> > > >  drivers/gpu/drm/vkms/vkms_composer.c | 27 +--
> > > >  drivers/gpu/drm/vkms/vkms_drv.c  |  5 +
> > > >  drivers/gpu/drm/vkms/vkms_drv.h  |  1 +
> > > >  drivers/gpu/drm/vkms/vkms_output.c   | 17 +++--
> > > >  drivers/gpu/drm/vkms/vkms_plane.c| 20 +++-
> > > >  5 files changed, 53 insertions(+), 17 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
> > > > b/drivers/gpu/drm/vkms/vkms_composer.c
> > > > index be8f1d33c645..2116da9b5a43 100644
> > > > --- a/drivers/gpu/drm/vkms/vkms_composer.c
> > > > +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> > > > @@ -144,11 +144,12 @@ static void compose_planes(struct vkms_composer 
> > > > *primary_composer,
> > > >
> > > >  static int composite(void **vaddr_out,
> > > >  struct vkms_composer *primary_composer,
> > > > -struct vkms_composer *cursor_composer)
> > > > +struct vkms_crtc_state *crtc_state)
> > > >  {
> > > > struct drm_framebuffer *fb = _composer->fb;
> > > > struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0);
> > > > struct drm_gem_shmem_object *shmem_obj = 
> > > > to_drm_gem_shmem_obj(gem_obj);
> > > > +   int i;
> > > >
> > > > if (!*vaddr_out) {
> > > > *vaddr_out = kzalloc(shmem_obj->base.size, GFP_KERNEL);
> > > > @@ -163,8 +164,14 @@ static int composite(void **vaddr_out,
> > > >
> > > > memcpy(*vaddr_out, shmem_obj->vaddr, shmem_obj->base.size);
> > > >
> > > > -   if (cursor_composer)
> > > > -   compose_planes(primary_composer, cursor_composer, 
> > > > *vaddr_out);
> > > > +   /* If there are other planes besides primary, we consider the active
> > > > +* planes should be in z-order and compose them associatively:
> > > > +* ((primary <- overlay) <- cursor)
> > > > +*/
> > > > +   for (i = 1; i < crtc_state->num_active_planes; i++)
> > > > +   compose_planes(primary_composer,
> > > > +  crtc_state->active_planes[i]->composer,
> > > > +  *vaddr_out);
> > > >
> > > > return 0;
> > > >  }
> > > > @@ -186,7 +193,7 @@ void vkms_composer_worker(struct work_struct *work)
> > > > struct drm_crtc *crtc = crtc_state->base.crtc;
> > > > struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
> > > > struct vkms_composer *primary_composer = NULL;
> > > > -   struct vkms_composer *cursor_composer = NULL;
> > > > +   struct vkms_plane_state *act_plane = NULL;
> > > > bool crc_pending, wb_pending;
> > > > void *vaddr_out = NULL;
> > > > u32 crc32 = 0;
> > > > @@ -210,11 +217,11 @@ void vkms_composer_worker(struct work_struct 
> > > > *work)
> > > > if (!crc_pending)
> > > > return;
> > > >
> > > > -   if (crtc_state->num_active_planes >= 1)
> > > > -   primary_composer = crtc_state->active_planes[0]->composer;
> > > > -
> > > > -   if (crtc_state->num_active_planes == 2)
> > > > -   cursor_composer = crtc_state->active_planes[1]->composer;
> > > > +   if (crtc_state-