Re: [PATCH] MAINTAINERS: Add T.J. Mercier as reviewer for DMA-BUF HEAPS FRAMEWORK

[Sumit Semwal]

Hi John,

On Fri, 30 Jun 2023 at 10:22, John Stultz  wrote:
>
> T.J. has been responsible for dmab-buf items on the Android team
> for awhile now, so it would be great to have him on as a reviewer.
>
> Cc: T.J. Mercier 
> Cc: Sumit Semwal 
> Cc: Benjamin Gaignard 
> Cc: Brian Starkey 
> Cc: John Stultz 
> Cc: linux-me...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: kernel-t...@android.com
> Signed-off-by: John Stultz 

Thank you for the patch;
Acked-by: Sumit Semwal 

I'll push it to drm-misc along with the one removing Liam.

> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index cb075f52d97b..f4e92b968ed7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6184,6 +6184,7 @@ R:Benjamin Gaignard 
> 
>  R: Laura Abbott 
>  R: Brian Starkey 
>  R: John Stultz 
> +R: T.J. Mercier 
>  L: linux-me...@vger.kernel.org
>  L: dri-devel@lists.freedesktop.org
>  L: linaro-mm-...@lists.linaro.org (moderated for non-subscribers)
> --
> 2.41.0.255.g8b1d071c50-goog
>

Best,
Sumit.

[PATCH] MAINTAINERS: Add T.J. Mercier as reviewer for DMA-BUF HEAPS FRAMEWORK

[John Stultz]

T.J. has been responsible for dmab-buf items on the Android team
for awhile now, so it would be great to have him on as a reviewer.

Cc: T.J. Mercier 
Cc: Sumit Semwal 
Cc: Benjamin Gaignard 
Cc: Brian Starkey 
Cc: John Stultz 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: kernel-t...@android.com
Signed-off-by: John Stultz 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index cb075f52d97b..f4e92b968ed7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6184,6 +6184,7 @@ R:Benjamin Gaignard 

 R: Laura Abbott 
 R: Brian Starkey 
 R: John Stultz 
+R: T.J. Mercier 
 L: linux-me...@vger.kernel.org
 L: dri-devel@lists.freedesktop.org
 L: linaro-mm-...@lists.linaro.org (moderated for non-subscribers)
-- 
2.41.0.255.g8b1d071c50-goog

Re: [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register

[Sui Jingfeng]

Hi,

On 2023/6/30 01:44, Limonciello, Mario wrote:

I think what you can do is pick up all the tags in your next version.  Once the
whole series has tags we can discuss how it merges.


Yes, you are right.

I will prepare the next version.

But I think, I should only gather the reverent part together.

I means that I probably should divide the 8 patches in V7 into 4 + 4.

The first four patch form a group, and the last four patch form another 
group.



Certainly, I will pick up the precious tags I got in the next version.

Thanks you!

Re: [PATCH v3 2/3] drm/msm/dpu: use dpu core's major version to enable data compress

[Abhinav Kumar]

On 6/29/2023 8:22 PM, Dmitry Baryshkov wrote:

On 30/06/2023 06:07, Abhinav Kumar wrote:



On 6/29/2023 5:20 PM, Dmitry Baryshkov wrote:

On 29/06/2023 22:29, Abhinav Kumar wrote:

Instead of using a feature bit to decide whether to enable data
compress or not for DSC use-cases, use dpu core's major version 
instead.

This will avoid defining feature bits for every bit level details of
registers.

Also, rename the intf's enable_compression() op to program_datapath()
and allow it to accept a struct intf_dpu_datapath_cfg to program
all the bits at once. This can be re-used by widebus later on as
well as it touches the same register.


Two separate commits please, because...



I thought of it but it seemed better together and was the only way I 
could think of. Please see below.



Signed-off-by: Abhinav Kumar 
---
  .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c |  9 +++--
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c  |  9 +
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h  | 16 
++--

  3 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c

index b856c6286c85..f4e15b4c4cc9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -50,6 +50,7 @@ static void _dpu_encoder_phys_cmd_update_intf_cfg(
  to_dpu_encoder_phys_cmd(phys_enc);
  struct dpu_hw_ctl *ctl;
  struct dpu_hw_intf_cfg intf_cfg = { 0 };
+    struct dpu_kms *dpu_kms = phys_enc->dpu_kms;
  ctl = phys_enc->hw_ctl;
  if (!ctl->ops.setup_intf_cfg)
@@ -68,8 +69,12 @@ static void _dpu_encoder_phys_cmd_update_intf_cfg(
  phys_enc->hw_intf,
  phys_enc->hw_pp->idx);
-    if (intf_cfg.dsc != 0 && 
phys_enc->hw_intf->ops.enable_compression)

-    phys_enc->hw_intf->ops.enable_compression(phys_enc->hw_intf);
+    if (intf_cfg.dsc != 0 && dpu_kms->catalog->core_major_version 
>= 0x7) {


... because this becomes incorrect. The datapath should be programmed 
in all the cases, if there is a corresponding callback. intf_cfg.dsc 
should be used as a condition to set datapath_cfg.




The issue is that today we do not have dpu_mdss_cfg as part of 
dpu_hw_intf nor _setup_intf_ops because all of those have been dropped 
with some rework or cleanup.


Pass dpu_mdss_cfg to dpu_hw_intf_init(). It was removed as a cleanup, 
now we can reintroduce it.




Thanks, that will address all these concerns.

I wanted to get agreement before re-introducing it and also make sure 
there was no other way.





Ideally even I would like to assign this op only for core_rev >=7 but 
that information is no longer available. We would have to start 
passing the major and minor versions to _setup_intf_ops() to go with 
that approach. So without making all of those changes, the only way I 
had was to assign the op unconditionally but call it only for 
major_rev >= 7.


Passing core_rev to the op itself so that we can write the register 
only for core_rev >=7 is an option but then what if some bits start 
becoming usable only after minor rev. then we will have to start 
passing major and minor rev to program_datapath too. Again getting 
little messy.


I am open to ideas to achieve the goal of assigning this op only for 
core_rev >=7 other than what I wrote above.





+    struct intf_dpu_datapath_cfg datapath_cfg = { 0 };


No need for `0' in the init, empty braces would be enough.



ack.


+
+    datapath_cfg.data_compress = true;
+    phys_enc->hw_intf->ops.program_datapath(phys_enc->hw_intf, 
&datapath_cfg);

+    }
  }
  static void dpu_encoder_phys_cmd_pp_tx_done_irq(void *arg, int 
irq_idx)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c

index 5b0f6627e29b..85333df08fbc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -513,11 +513,13 @@ static void 
dpu_hw_intf_disable_autorefresh(struct dpu_hw_intf *intf,

  }
-static void dpu_hw_intf_enable_compression(struct dpu_hw_intf *ctx)
+static void dpu_hw_intf_program_datapath(struct dpu_hw_intf *ctx,
+ struct intf_dpu_datapath_cfg *datapath_cfg)
  {
  u32 intf_cfg2 = DPU_REG_READ(&ctx->hw, INTF_CONFIG2);
-    intf_cfg2 |= INTF_CFG2_DCE_DATA_COMPRESS;
+    if (datapath_cfg->data_compress)
+    intf_cfg2 |= INTF_CFG2_DCE_DATA_COMPRESS;
  DPU_REG_WRITE(&ctx->hw, INTF_CONFIG2, intf_cfg2);
  }
@@ -543,8 +545,7 @@ static void _setup_intf_ops(struct 
dpu_hw_intf_ops *ops,

  ops->disable_autorefresh = dpu_hw_intf_disable_autorefresh;
  }
-    if (cap & BIT(DPU_INTF_DATA_COMPRESS))
-    ops->enable_compression = dpu_hw_intf_enable_compression;
+    ops->program_datapath = dpu_hw_intf_program_datapath;


The `core_major_version >= 7' should either be here or in the 
callback itself.

Re: [PATCH v3 2/3] drm/msm/dpu: use dpu core's major version to enable data compress

[Dmitry Baryshkov]

On 30/06/2023 06:07, Abhinav Kumar wrote:



On 6/29/2023 5:20 PM, Dmitry Baryshkov wrote:

On 29/06/2023 22:29, Abhinav Kumar wrote:

Instead of using a feature bit to decide whether to enable data
compress or not for DSC use-cases, use dpu core's major version instead.
This will avoid defining feature bits for every bit level details of
registers.

Also, rename the intf's enable_compression() op to program_datapath()
and allow it to accept a struct intf_dpu_datapath_cfg to program
all the bits at once. This can be re-used by widebus later on as
well as it touches the same register.


Two separate commits please, because...



I thought of it but it seemed better together and was the only way I 
could think of. Please see below.



Signed-off-by: Abhinav Kumar 
---
  .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c |  9 +++--
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c  |  9 +
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h  | 16 ++--
  3 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c

index b856c6286c85..f4e15b4c4cc9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -50,6 +50,7 @@ static void _dpu_encoder_phys_cmd_update_intf_cfg(
  to_dpu_encoder_phys_cmd(phys_enc);
  struct dpu_hw_ctl *ctl;
  struct dpu_hw_intf_cfg intf_cfg = { 0 };
+    struct dpu_kms *dpu_kms = phys_enc->dpu_kms;
  ctl = phys_enc->hw_ctl;
  if (!ctl->ops.setup_intf_cfg)
@@ -68,8 +69,12 @@ static void _dpu_encoder_phys_cmd_update_intf_cfg(
  phys_enc->hw_intf,
  phys_enc->hw_pp->idx);
-    if (intf_cfg.dsc != 0 && phys_enc->hw_intf->ops.enable_compression)
-    phys_enc->hw_intf->ops.enable_compression(phys_enc->hw_intf);
+    if (intf_cfg.dsc != 0 && dpu_kms->catalog->core_major_version >= 
0x7) {


... because this becomes incorrect. The datapath should be programmed 
in all the cases, if there is a corresponding callback. intf_cfg.dsc 
should be used as a condition to set datapath_cfg.




The issue is that today we do not have dpu_mdss_cfg as part of 
dpu_hw_intf nor _setup_intf_ops because all of those have been dropped 
with some rework or cleanup.


Pass dpu_mdss_cfg to dpu_hw_intf_init(). It was removed as a cleanup, 
now we can reintroduce it.




Ideally even I would like to assign this op only for core_rev >=7 but 
that information is no longer available. We would have to start passing 
the major and minor versions to _setup_intf_ops() to go with that 
approach. So without making all of those changes, the only way I had was 
to assign the op unconditionally but call it only for major_rev >= 7.


Passing core_rev to the op itself so that we can write the register only 
for core_rev >=7 is an option but then what if some bits start becoming 
usable only after minor rev. then we will have to start passing major 
and minor rev to program_datapath too. Again getting little messy.


I am open to ideas to achieve the goal of assigning this op only for 
core_rev >=7 other than what I wrote above.





+    struct intf_dpu_datapath_cfg datapath_cfg = { 0 };


No need for `0' in the init, empty braces would be enough.



ack.


+
+    datapath_cfg.data_compress = true;
+    phys_enc->hw_intf->ops.program_datapath(phys_enc->hw_intf, 
&datapath_cfg);

+    }
  }
  static void dpu_encoder_phys_cmd_pp_tx_done_irq(void *arg, int 
irq_idx)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c

index 5b0f6627e29b..85333df08fbc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -513,11 +513,13 @@ static void 
dpu_hw_intf_disable_autorefresh(struct dpu_hw_intf *intf,

  }
-static void dpu_hw_intf_enable_compression(struct dpu_hw_intf *ctx)
+static void dpu_hw_intf_program_datapath(struct dpu_hw_intf *ctx,
+ struct intf_dpu_datapath_cfg *datapath_cfg)
  {
  u32 intf_cfg2 = DPU_REG_READ(&ctx->hw, INTF_CONFIG2);
-    intf_cfg2 |= INTF_CFG2_DCE_DATA_COMPRESS;
+    if (datapath_cfg->data_compress)
+    intf_cfg2 |= INTF_CFG2_DCE_DATA_COMPRESS;
  DPU_REG_WRITE(&ctx->hw, INTF_CONFIG2, intf_cfg2);
  }
@@ -543,8 +545,7 @@ static void _setup_intf_ops(struct 
dpu_hw_intf_ops *ops,

  ops->disable_autorefresh = dpu_hw_intf_disable_autorefresh;
  }
-    if (cap & BIT(DPU_INTF_DATA_COMPRESS))
-    ops->enable_compression = dpu_hw_intf_enable_compression;
+    ops->program_datapath = dpu_hw_intf_program_datapath;


The `core_major_version >= 7' should either be here or in the callback 
itself.




Yes, ideally I would like it like that but please see above why I 
couldnt do it.



  }
  struct dpu_hw_intf *dpu_hw_intf_init(const struct dpu_intf_cfg *cfg,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/d

Re: [PATCH v3 1/3] drm/msm/dpu: re-introduce dpu core revision to the catalog

[Dmitry Baryshkov]

On 30/06/2023 06:17, Abhinav Kumar wrote:



On 6/29/2023 5:24 PM, Dmitry Baryshkov wrote:

On 29/06/2023 22:29, Abhinav Kumar wrote:

With [1] dpu core revision was dropped in favor of using the
compatible string from the device tree to select the dpu catalog
being used in the device.

This approach works well however also necessitates adding catalog
entries for small register level details as dpu capabilities and/or
features bloating the catalog unnecessarily. Examples include but
are not limited to data_compress, interrupt register set, widebus etc.


Generic note: this description can be moved to the cover letter, it 
covers the series intent.




I kept it here as I didnt really have a cover letter but I can add one 
and move this there.


Yes, please. I suppose that any series of more than a single non-trivial 
patch should have a cover letter, which describes the intentions and the 
ideas behind the series.





Introduce the dpu core revision back as an entry to the catalog so that
we can just use dpu revision checks and enable those bits which
should be enabled unconditionally and not controlled by a catalog
and also simplify the changes to do something like:

if (dpu_core_revision > x && dpu_core_revision < x)
    enable the bit;

Since dpu's major and minor versions are now separate fields, lets
drop all the DPU_HW_VER macros.

[1]: https://patchwork.freedesktop.org/patch/530891/?series=113910&rev=4


Please use `commit aabbcc ("do this and that")' in the commit messages.



Ack.



changes in v3:
- drop DPU step version as features are not changing across steps
- add core_major_version / core_minor_version to avoid conflicts
- update the commit text to drop references to the dpu macros

Signed-off-by: Abhinav Kumar 




--
With best wishes
Dmitry

Re: [PATCH v3 1/3] drm/msm/dpu: re-introduce dpu core revision to the catalog

[Abhinav Kumar]

On 6/29/2023 5:24 PM, Dmitry Baryshkov wrote:

On 29/06/2023 22:29, Abhinav Kumar wrote:

With [1] dpu core revision was dropped in favor of using the
compatible string from the device tree to select the dpu catalog
being used in the device.

This approach works well however also necessitates adding catalog
entries for small register level details as dpu capabilities and/or
features bloating the catalog unnecessarily. Examples include but
are not limited to data_compress, interrupt register set, widebus etc.


Generic note: this description can be moved to the cover letter, it 
covers the series intent.




I kept it here as I didnt really have a cover letter but I can add one 
and move this there.



Introduce the dpu core revision back as an entry to the catalog so that
we can just use dpu revision checks and enable those bits which
should be enabled unconditionally and not controlled by a catalog
and also simplify the changes to do something like:

if (dpu_core_revision > x && dpu_core_revision < x)
    enable the bit;

Since dpu's major and minor versions are now separate fields, lets
drop all the DPU_HW_VER macros.

[1]: https://patchwork.freedesktop.org/patch/530891/?series=113910&rev=4


Please use `commit aabbcc ("do this and that")' in the commit messages.



Ack.



changes in v3:
- drop DPU step version as features are not changing across steps
- add core_major_version / core_minor_version to avoid conflicts
- update the commit text to drop references to the dpu macros

Signed-off-by: Abhinav Kumar 

Re: [PATCH v3 1/3] drm/msm/dpu: re-introduce dpu core revision to the catalog

[Abhinav Kumar]

On 6/29/2023 5:13 PM, Dmitry Baryshkov wrote:

On 29/06/2023 22:29, Abhinav Kumar wrote:

With [1] dpu core revision was dropped in favor of using the
compatible string from the device tree to select the dpu catalog
being used in the device.

This approach works well however also necessitates adding catalog
entries for small register level details as dpu capabilities and/or
features bloating the catalog unnecessarily. Examples include but
are not limited to data_compress, interrupt register set, widebus etc.

Introduce the dpu core revision back as an entry to the catalog so that
we can just use dpu revision checks and enable those bits which
should be enabled unconditionally and not controlled by a catalog
and also simplify the changes to do something like:

if (dpu_core_revision > x && dpu_core_revision < x)
    enable the bit;

Since dpu's major and minor versions are now separate fields, lets
drop all the DPU_HW_VER macros.

[1]: https://patchwork.freedesktop.org/patch/530891/?series=113910&rev=4

changes in v3:
- drop DPU step version as features are not changing across steps
- add core_major_version / core_minor_version to avoid conflicts
- update the commit text to drop references to the dpu macros

Signed-off-by: Abhinav Kumar 
---
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h  | 2 ++
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h   | 2 ++
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h   | 2 ++
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h  | 2 ++
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h   | 2 ++
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h   | 2 ++
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_3_sm6115.h   | 2 ++
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h   | 2 ++
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h  | 2 ++
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h   | 2 ++
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h   | 2 ++
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h   | 2 ++
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 2 ++
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h   | 2 ++
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h   | 2 ++
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h   | 8 ++--
  16 files changed, 36 insertions(+), 2 deletions(-)


Reviewed-by: Dmitry Baryshkov 

Nit: if there is a need for v-next, I'd probably suggest dropping th hex 
prefix from these values.




ack, I was debating in my head whether to keep it or not and kept it in 
the end. I am fine to drop it too.




diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h

index 7d0d0e74c3b0..a5d486783c3f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
@@ -190,6 +190,8 @@ static const struct dpu_perf_cfg msm8998_perf_data 
= {

  };
  const struct dpu_mdss_cfg dpu_msm8998_cfg = {
+    .core_major_version = 0x3,
+    .core_minor_version = 0x0,
  .caps = &msm8998_dpu_caps,
  .ubwc = &msm8998_ubwc_cfg,
  .mdp_count = ARRAY_SIZE(msm8998_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h

index b6098141bb9b..1fdb89a4b7a6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
@@ -194,6 +194,8 @@ static const struct dpu_perf_cfg sdm845_perf_data = {
  };
  const struct dpu_mdss_cfg dpu_sdm845_cfg = {
+    .core_major_version = 0x4,
+    .core_minor_version = 0x0,
  .caps = &sdm845_dpu_caps,
  .ubwc = &sdm845_ubwc_cfg,
  .mdp_count = ARRAY_SIZE(sdm845_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h

index b5f751354267..129c62cf450d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
@@ -208,6 +208,8 @@ static const struct dpu_perf_cfg sm8150_perf_data = {
  };
  const struct dpu_mdss_cfg dpu_sm8150_cfg = {
+    .core_major_version = 0x5,
+    .core_minor_version = 0x0,
  .caps = &sm8150_dpu_caps,
  .ubwc = &sm8150_ubwc_cfg,
  .mdp_count = ARRAY_SIZE(sm8150_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h

index 8ed2b263c5ea..ca037b070f44 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
@@ -214,6 +214,8 @@ static const struct dpu_perf_cfg sc8180x_perf_data 
= {

  };
  const struct dpu_mdss_cfg dpu_sc8180x_cfg = {
+    .core_major_version = 0x5,
+    .core_minor_version = 0x1,
  .caps = &sc8180x_dpu_caps,
  .ubwc = &sc8180x_ubwc_cfg,
  .mdp_count = ARRAY_SIZ

Re: [PATCH v3 2/3] drm/msm/dpu: use dpu core's major version to enable data compress

[Abhinav Kumar]

On 6/29/2023 5:20 PM, Dmitry Baryshkov wrote:

On 29/06/2023 22:29, Abhinav Kumar wrote:

Instead of using a feature bit to decide whether to enable data
compress or not for DSC use-cases, use dpu core's major version instead.
This will avoid defining feature bits for every bit level details of
registers.

Also, rename the intf's enable_compression() op to program_datapath()
and allow it to accept a struct intf_dpu_datapath_cfg to program
all the bits at once. This can be re-used by widebus later on as
well as it touches the same register.


Two separate commits please, because...



I thought of it but it seemed better together and was the only way I 
could think of. Please see below.



Signed-off-by: Abhinav Kumar 
---
  .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c |  9 +++--
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c  |  9 +
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h  | 16 ++--
  3 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c

index b856c6286c85..f4e15b4c4cc9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -50,6 +50,7 @@ static void _dpu_encoder_phys_cmd_update_intf_cfg(
  to_dpu_encoder_phys_cmd(phys_enc);
  struct dpu_hw_ctl *ctl;
  struct dpu_hw_intf_cfg intf_cfg = { 0 };
+    struct dpu_kms *dpu_kms = phys_enc->dpu_kms;
  ctl = phys_enc->hw_ctl;
  if (!ctl->ops.setup_intf_cfg)
@@ -68,8 +69,12 @@ static void _dpu_encoder_phys_cmd_update_intf_cfg(
  phys_enc->hw_intf,
  phys_enc->hw_pp->idx);
-    if (intf_cfg.dsc != 0 && phys_enc->hw_intf->ops.enable_compression)
-    phys_enc->hw_intf->ops.enable_compression(phys_enc->hw_intf);
+    if (intf_cfg.dsc != 0 && dpu_kms->catalog->core_major_version >= 
0x7) {


... because this becomes incorrect. The datapath should be programmed in 
all the cases, if there is a corresponding callback. intf_cfg.dsc should 
be used as a condition to set datapath_cfg.




The issue is that today we do not have dpu_mdss_cfg as part of 
dpu_hw_intf nor _setup_intf_ops because all of those have been dropped 
with some rework or cleanup.


Ideally even I would like to assign this op only for core_rev >=7 but 
that information is no longer available. We would have to start passing 
the major and minor versions to _setup_intf_ops() to go with that 
approach. So without making all of those changes, the only way I had was 
to assign the op unconditionally but call it only for major_rev >= 7.


Passing core_rev to the op itself so that we can write the register only 
for core_rev >=7 is an option but then what if some bits start becoming 
usable only after minor rev. then we will have to start passing major 
and minor rev to program_datapath too. Again getting little messy.


I am open to ideas to achieve the goal of assigning this op only for 
core_rev >=7 other than what I wrote above.





+    struct intf_dpu_datapath_cfg datapath_cfg = { 0 };


No need for `0' in the init, empty braces would be enough.



ack.


+
+    datapath_cfg.data_compress = true;
+    phys_enc->hw_intf->ops.program_datapath(phys_enc->hw_intf, 
&datapath_cfg);

+    }
  }
  static void dpu_encoder_phys_cmd_pp_tx_done_irq(void *arg, int irq_idx)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c

index 5b0f6627e29b..85333df08fbc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -513,11 +513,13 @@ static void 
dpu_hw_intf_disable_autorefresh(struct dpu_hw_intf *intf,

  }
-static void dpu_hw_intf_enable_compression(struct dpu_hw_intf *ctx)
+static void dpu_hw_intf_program_datapath(struct dpu_hw_intf *ctx,
+ struct intf_dpu_datapath_cfg *datapath_cfg)
  {
  u32 intf_cfg2 = DPU_REG_READ(&ctx->hw, INTF_CONFIG2);
-    intf_cfg2 |= INTF_CFG2_DCE_DATA_COMPRESS;
+    if (datapath_cfg->data_compress)
+    intf_cfg2 |= INTF_CFG2_DCE_DATA_COMPRESS;
  DPU_REG_WRITE(&ctx->hw, INTF_CONFIG2, intf_cfg2);
  }
@@ -543,8 +545,7 @@ static void _setup_intf_ops(struct dpu_hw_intf_ops 
*ops,

  ops->disable_autorefresh = dpu_hw_intf_disable_autorefresh;
  }
-    if (cap & BIT(DPU_INTF_DATA_COMPRESS))
-    ops->enable_compression = dpu_hw_intf_enable_compression;
+    ops->program_datapath = dpu_hw_intf_program_datapath;


The `core_major_version >= 7' should either be here or in the callback 
itself.




Yes, ideally I would like it like that but please see above why I 
couldnt do it.



  }
  struct dpu_hw_intf *dpu_hw_intf_init(const struct dpu_intf_cfg *cfg,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h

index 99e21c4137f9..f736dca38463 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_i

[PATCH] drm/exynos: fix a possible null-pointer dereference due to data race in exynos_drm_crtc_atomic_disable()

[Tuo Li]

The variable crtc->state->event is often protected by the lock 
crtc->dev->event_lock when is accessed. However, it is accessed as a 
condition of an if statement in exynos_drm_crtc_atomic_disable() without
holding the lock:

  if (crtc->state->event && !crtc->state->active)

However, if crtc->state->event is changed to NULL by another thread right
after the conditions of the if statement is checked to be true, a
null-pointer dereference can occur in drm_crtc_send_vblank_event():

  e->pipe = pipe;

To fix this possible null-pointer dereference caused by data race, the 
spin lock coverage is extended to protect the if statement as well as the 
function call to drm_crtc_send_vblank_event().

Reported-by: BassCheck 
Signed-off-by: Tuo Li 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 4153f302de7c..d19e796c2061 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -39,13 +39,12 @@ static void exynos_drm_crtc_atomic_disable(struct drm_crtc 
*crtc,
if (exynos_crtc->ops->atomic_disable)
exynos_crtc->ops->atomic_disable(exynos_crtc);
 
+   spin_lock_irq(&crtc->dev->event_lock);
if (crtc->state->event && !crtc->state->active) {
-   spin_lock_irq(&crtc->dev->event_lock);
drm_crtc_send_vblank_event(crtc, crtc->state->event);
-   spin_unlock_irq(&crtc->dev->event_lock);
-
crtc->state->event = NULL;
}
+   spin_unlock_irq(&crtc->dev->event_lock);
 }
 
 static int exynos_crtc_atomic_check(struct drm_crtc *crtc,
-- 
2.34.1

Re: [PATCH] drm/ttm: Remove duplicate assignments to ttm->caching

[Feng Jiang]

On 2023/6/29 14:37, Christian König wrote:
> This has already been fixed with:
> 
> commit 2ce977df10c179138e2723b25c2d2c055a3e3cc6
> Author: Ma Jun 
> Date:   Wed May 31 13:30:51 2023 +0800
> 
>     drm/ttm: Remove redundant code in ttm_tt_init_fields
> 
>     Remove redundant assignment code for ttm->caching as it's overwritten
>     just a few lines later.
> 
>     v2:
>  - Update the commit message.
> 
>     Signed-off-by: Ma Jun 
>     Reviewed-by: Guchun Chen 
>     Reviewed-by: Christian König 
>     Signed-off-by: Christian König 
>     Link: 
> https://patchwork.freedesktop.org/patch/msgid/20230531053051.3453509-1-jun@amd.com
> 
> 
> Regards,
> Christian.
> 
> Am 25.06.23 um 04:45 schrieb Feng Jiang:
>> The parameter 'caching' has already been assigned to
>> 'ttm->caching', so 'ttm_cached' is redundant.
>>
>> Fixes: 1b4ea4c5980f ("drm/ttm: set the tt caching state at creation time")
>> Signed-off-by: Feng Jiang 
>> ---
>>   drivers/gpu/drm/ttm/ttm_tt.c | 1 -
>>   1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
>> index ab725d9d14a6..1ce4b36ab33b 100644
>> --- a/drivers/gpu/drm/ttm/ttm_tt.c
>> +++ b/drivers/gpu/drm/ttm/ttm_tt.c
>> @@ -137,7 +137,6 @@ static void ttm_tt_init_fields(struct ttm_tt *ttm,
>>  unsigned long extra_pages)
>>   {
>>   ttm->num_pages = (PAGE_ALIGN(bo->base.size) >> PAGE_SHIFT) + 
>> extra_pages;
>> -    ttm->caching = ttm_cached;
>>   ttm->page_flags = page_flags;
>>   ttm->dma_address = NULL;
>>   ttm->swap_storage = NULL;
> 
Sorry, I will check before sending next time, thanks!
-- 
Best regards,
Feng

Re: [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register

[suijingfeng]

Hi,

On 2023/6/30 01:44, Limonciello, Mario wrote:

[Public]


-Original Message-
From: 15330273...@189.cn <15330273...@189.cn>
Sent: Thursday, June 29, 2023 12:00 PM
To: Bjorn Helgaas ; Sui Jingfeng

Cc: Bjorn Helgaas ; linux-fb...@vger.kernel.org;
Cornelia Huck ; Karol Herbst ;
nouv...@lists.freedesktop.org; Joonas Lahtinen
; dri-devel@lists.freedesktop.org; Chai,
Thomas ; Limonciello, Mario
; Gao, Likun ; David
Airlie ; Ville Syrjala ; Yi 
Liu
; k...@vger.kernel.org; amd-...@lists.freedesktop.org;
Jason Gunthorpe ; Ben Skeggs ; linux-
p...@vger.kernel.org; Kevin Tian ; Lazar, Lijo
; Thomas Zimmermann ;
Zhang, Bokun ; intel-...@lists.freedesktop.org;
Maarten Lankhorst ; Jani Nikula
; Alex Williamson
; Abhishek Sahu ;
Maxime Ripard ; Rodrigo Vivi ;
Tvrtko Ursulin ; Yishai Hadas
; Pan, Xinhui ; linux-
ker...@vger.kernel.org; Daniel Vetter ; Deucher, Alexander
; Koenig, Christian
; Zhang, Hawking 
Subject: Re: [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function
callback to vga_client_register

Hi,

On 2023/6/29 23:54, Bjorn Helgaas wrote:

On Thu, Jun 22, 2023 at 01:08:15PM +0800, Sui Jingfeng wrote:

Hi,


A nouveau developer(Lyude) from redhat send me a R-B,

Thanks for the developers of nouveau project.


Please allow me add a link[1] here.


[1]

https://lore.kernel.org/all/0afadc69f99a36bc9d03ecf54ff25859dbc10e28.ca
m...@redhat.com/

1) Thanks for this.  If you post another version of this series,
 please pick up Lyude's Reviewed-by and include it in the relevant
 patches (as long as you haven't made significant changes to the
 code Lyude reviewed).

Yes, no significant changes. Just fix typo.

I also would like to add support for other DRM drivers.

But I think this deserve another patch.


   Whoever applies this should automatically
 pick up Reviewed-by/Ack/etc that are replies to the version being
 applied, but they won't go through previous revisions to find them.

2) Please mention the commit to which the series applies.  I tried to
 apply this on v6.4-rc1, but it doesn't apply cleanly.

Since I'm a graphic driver developer, I'm using drm-tip.

I just have already pulled, it still apply cleanly on drm-tip.


3) Thanks for including cover letters in your postings.  Please
 include a little changelog in the cover letter so we know what
 changed between v6 and v7, etc.

No change between v6 and v7,

it seems that it is because the mailbox don't allow me to sending too
many mails a day.

so some of the patch is failed to delivery because out of quota.



4) Right now we're in the middle of the v6.5 merge window, so new
 content, e.g., this series, is too late for v6.5.  Most
 maintainers, including me, wait to merge new content until the
 merge window closes and a new -rc1 is tagged.  This merge window
 should close on July 9, and people will start merging content for
 v6.6, typically based on v6.5-rc1.

I'm wondering

Would you will merge all of the patches in this series (e.g. including
the patch for drm/amdgpu(7/8) and drm/radeon(8/8)) ?

Or just part of them?

Emm, I don't know because my patch seems across different subsystem of
Linux kernel.

There is also a developer for AMDGPU (Mario) give me a R-B for the
patch-0002 of this series.

So, at least, PATCH-0001, PATCH-0002, PATCH-0003, PATCH-0004, PATCH-
0006
are already OK(got reviewed by).

Those 5 patch are already qualified to be merged, I think.

I think what you can do is pick up all the tags in your next version.  Once the
whole series has tags we can discuss how it merges.


Thanks a lot, Mario.


Is it possible to merge the PCI/VGA part as fast as possible, especially the

PATCH-0006 PCI/VGA: Introduce is_boot_device function callback to 
vga_client_register

As this patch is fundamental, it introduce no functional change, as long as the 
drm

driver side don't introduce a callback.

I'm not hurry, but drm driver-side's patch have a dependency on this patch,

I think it is better the PCI/VGA-side's patch got merge first.

At least for get the first four cleanup(0001 ~ 0004) patch merged first,

so that I don't have to send so much on the next version on one series.

Being exposed so far, there no obvious objection.

It saying that other people also want it got merged.

Bjorn, is this OK ?




I means that if you could merge those 5 patch first, then there no need
to send another version again.

I will refine the rest patch with more details and description.

I'm fear of making too much noise.


Bjorn

[PATCH v3] drm/i915/pxp: Optimize GET_PARAM:PXP_STATUS

[Alan Previn]

After recent discussions with Mesa folks, it was requested
that we optimize i915's GET_PARAM for the PXP_STATUS without
changing the UAPI spec.

Add these additional optimizations:
   - If any PXP initializatoin flow failed, then ensure that
 we catch it so that we can change the returned PXP_STATUS
 from "2" (i.e. 'PXP is supported but not yet ready')
 to "-ENODEV". This typically should not happen and if it
 does, we have a platform configuration issue.
   - If a PXP arbitration session creation event failed
 due to incorrect firmware version or blocking SOC fusing
 or blocking BIOS configuration (platform reasons that won't
 change if we retry), then reflect that blockage by also
 returning -ENODEV in the GET_PARAM:PXP_STATUS.
   - GET_PARAM:PXP_STATUS should not wait at all if PXP is
 supported but non-i915 dependencies (component-driver /
 firmware) we are still pending to complete the init flows.
 In this case, just return "2" immediately (i.e. 'PXP is
 supported but not yet ready').

Difference from prio revs:
  v2: - Use a #define for the default readiness timeout (Vivaik).
  - Improve comments around the failing of proxy-init.
  v1: - Change the commit msg style to be imperative. (Jani)
  - Rename timeout to timeout_ms. (Jani)
  - Fix is_fw_err_platform_config to use higher order
param (pxp) first. (Jani)

Signed-off-by: Alan Previn 
---
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c  | 10 +-
 drivers/gpu/drm/i915/i915_getparam.c   |  2 +-
 drivers/gpu/drm/i915/pxp/intel_pxp.c   | 40 ++
 drivers/gpu/drm/i915/pxp/intel_pxp.h   |  2 +-
 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c |  7 ++--
 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c   |  7 ++--
 drivers/gpu/drm/i915/pxp/intel_pxp_types.h |  9 +
 7 files changed, 61 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
index 034b53a71541..21c2b7cce335 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
@@ -62,8 +62,16 @@ static void gsc_work(struct work_struct *work)
}
 
ret = intel_gsc_proxy_request_handler(gsc);
-   if (ret)
+   if (ret) {
+   if (actions & GSC_ACTION_FW_LOAD) {
+   /*
+* A failure right after firmware load means 
the proxy-init
+* step has failed so mark GSC as not usable 
after this
+*/
+   intel_uc_fw_change_status(&gsc->fw, 
INTEL_UC_FIRMWARE_LOAD_FAIL);
+   }
goto out_put;
+   }
 
/* mark the GSC FW init as done the first time we run this */
if (actions & GSC_ACTION_FW_LOAD) {
diff --git a/drivers/gpu/drm/i915/i915_getparam.c 
b/drivers/gpu/drm/i915/i915_getparam.c
index 890f2b382bee..5c3fec63cb4c 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -109,7 +109,7 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
return value;
break;
case I915_PARAM_PXP_STATUS:
-   value = intel_pxp_get_readiness_status(i915->pxp);
+   value = intel_pxp_get_readiness_status(i915->pxp, 0);
if (value < 0)
return value;
break;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index bb2e15329f34..e3b47525dc60 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -359,22 +359,46 @@ void intel_pxp_end(struct intel_pxp *pxp)
intel_runtime_pm_put(&i915->runtime_pm, wakeref);
 }
 
+static bool pxp_required_fw_failed(struct intel_pxp *pxp)
+{
+   if (__intel_uc_fw_status(&pxp->ctrl_gt->uc.huc.fw) == 
INTEL_UC_FIRMWARE_LOAD_FAIL)
+   return true;
+   if (HAS_ENGINE(pxp->ctrl_gt, GSC0) &&
+   __intel_uc_fw_status(&pxp->ctrl_gt->uc.gsc.fw) == 
INTEL_UC_FIRMWARE_LOAD_FAIL)
+   return true;
+
+   return false;
+}
+
+static bool pxp_fw_dependencies_completed(struct intel_pxp *pxp)
+{
+   if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+   return intel_pxp_gsccs_is_ready_for_sessions(pxp);
+
+   return pxp_component_bound(pxp);
+}
+
 /*
  * this helper is used by both intel_pxp_start and by
  * the GET_PARAM IOCTL that user space calls. Thus, the
  * return values here should match the UAPI spec.
  */
-int intel_pxp_get_readiness_status(struct intel_pxp *pxp)
+int intel_pxp_get_readiness_status(struct intel_pxp *pxp, int timeout_ms)
 {
if (!intel_pxp_is_enabled(pxp))
return -ENODEV;
 
-   if (HAS_ENGINE(pxp->ctrl_gt, GSC0)) {
-   if (wait_for(intel_pxp_gsccs_is_ready

Re: [PATCH RFC v4 7/7] drm/msm/dpu: Use DRM solid_fill property

[Dmitry Baryshkov]

On 30/06/2023 03:25, Jessica Zhang wrote:

Drop DPU_PLANE_COLOR_FILL_FLAG and check the DRM solid_fill property to
determine if the plane is solid fill. In addition drop the DPU plane
color_fill field as we can now use drm_plane_state.solid_fill instead,
and pass in drm_plane_state.alpha to _dpu_plane_color_fill_pipe() to
allow userspace to configure the alpha value for the solid fill color.

Signed-off-by: Jessica Zhang 


Reviewed-by: Dmitry Baryshkov 

Minor suggestion below.


---
  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 21 +++--
  1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 4476722f03bb..11d4fb771a1f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -42,7 +42,6 @@
  #define SHARP_SMOOTH_THR_DEFAULT  8
  #define SHARP_NOISE_THR_DEFAULT   2
  
-#define DPU_PLANE_COLOR_FILL_FLAG	BIT(31)

  #define DPU_ZPOS_MAX 255
  
  /*

@@ -82,7 +81,6 @@ struct dpu_plane {
  
  	enum dpu_sspp pipe;
  
-	uint32_t color_fill;

bool is_error;
bool is_rt_pipe;
const struct dpu_mdss_cfg *catalog;
@@ -606,6 +604,17 @@ static void _dpu_plane_color_fill_pipe(struct 
dpu_plane_state *pstate,
_dpu_plane_setup_scaler(pipe, fmt, true, &pipe_cfg, pstate->rotation);
  }
  
+static uint32_t _dpu_plane_get_fill_color(struct drm_solid_fill solid_fill)


Please consider accepting drm_plane_state instead and handling alpha 
here. Then _dpu_color_fill can accept rgba colour instead of separate 
RGB and alpha values.



+{
+   uint32_t ret = 0;
+
+   ret |= ((uint8_t) solid_fill.b) << 16;
+   ret |= ((uint8_t) solid_fill.g) << 8;
+   ret |= ((uint8_t) solid_fill.r);
+
+   return ret;
+}
+
  /**
   * _dpu_plane_color_fill - enables color fill on plane
   * @pdpu:   Pointer to DPU plane object
@@ -977,9 +986,9 @@ void dpu_plane_flush(struct drm_plane *plane)
if (pdpu->is_error)
/* force white frame with 100% alpha pipe output on error */
_dpu_plane_color_fill(pdpu, 0xFF, 0xFF);
-   else if (pdpu->color_fill & DPU_PLANE_COLOR_FILL_FLAG)
-   /* force 100% alpha */
-   _dpu_plane_color_fill(pdpu, pdpu->color_fill, 0xFF);
+   else if (drm_plane_solid_fill_enabled(plane->state))
+   _dpu_plane_color_fill(pdpu, 
_dpu_plane_get_fill_color(plane->state->solid_fill),
+   plane->state->alpha);
else {
dpu_plane_flush_csc(pdpu, &pstate->pipe);
dpu_plane_flush_csc(pdpu, &pstate->r_pipe);
@@ -1024,7 +1033,7 @@ static void dpu_plane_sspp_update_pipe(struct drm_plane 
*plane,
}
  
  	/* override for color fill */

-   if (pdpu->color_fill & DPU_PLANE_COLOR_FILL_FLAG) {
+   if (drm_plane_solid_fill_enabled(plane->state)) {
_dpu_plane_set_qos_ctrl(plane, pipe, false);
  
  		/* skip remaining processing on color fill */




--
With best wishes
Dmitry

Re: [PATCH RFC v4 6/7] drm/msm/dpu: Allow NULL FBs in atomic commit

[Dmitry Baryshkov]

On 30/06/2023 03:25, Jessica Zhang wrote:

Since solid fill planes allow for a NULL framebuffer in a valid commit,
add NULL framebuffer checks to atomic commit calls within DPU.

Signed-off-by: Jessica Zhang 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |  9 ++-
  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 45 +++
  2 files changed, 36 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 1edf2b6b0a26..d1b37d2cc202 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -451,6 +451,7 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc 
*crtc,
struct drm_plane_state *state;
struct dpu_crtc_state *cstate = to_dpu_crtc_state(crtc->state);
struct dpu_plane_state *pstate = NULL;
+   const struct msm_format *fmt;
struct dpu_format *format;
struct dpu_hw_ctl *ctl = mixer->lm_ctl;
  
@@ -470,7 +471,13 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc *crtc,

pstate = to_dpu_plane_state(state);
fb = state->fb;
  
-		format = to_dpu_format(msm_framebuffer_format(pstate->base.fb));

+   if (state->pixel_source == DRM_PLANE_PIXEL_SOURCE_FB && fb)
+   fmt = msm_framebuffer_format(pstate->base.fb);
+   else
+   fmt = dpu_get_msm_format(&_dpu_crtc_get_kms(crtc)->base,
+   DRM_FORMAT_RGBA, 0);


The DRM_FORMAT_RGBA should be defined somewhere in patch 1 as format 
for the solid_fill, then that define can be used in this patch.



+
+   format = to_dpu_format(fmt);
  
  		if (pstate->stage == DPU_STAGE_BASE && format->alpha_enable)

bg_alpha_enable = true;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 5f0984ce62b1..4476722f03bb 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -837,8 +837,10 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
  
  	pipe_cfg->dst_rect = new_plane_state->dst;
  
-	fb_rect.x2 = new_plane_state->fb->width;

-   fb_rect.y2 = new_plane_state->fb->height;
+   if (new_plane_state->pixel_source == DRM_PLANE_PIXEL_SOURCE_FB && 
new_plane_state->fb) {
+   fb_rect.x2 = new_plane_state->fb->width;
+   fb_rect.y2 = new_plane_state->fb->height;
+   }
  
  	/* Ensure fb size is supported */

if (drm_rect_width(&fb_rect) > MAX_IMG_WIDTH ||
@@ -848,10 +850,13 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
return -E2BIG;
}
  
-	fmt = to_dpu_format(msm_framebuffer_format(new_plane_state->fb));

-
max_linewidth = pdpu->catalog->caps->max_linewidth;
  
+	if (drm_plane_solid_fill_enabled(new_plane_state))

+   fmt = dpu_get_dpu_format(DRM_FORMAT_ABGR);
+   else
+   fmt = 
to_dpu_format(msm_framebuffer_format(new_plane_state->fb));
+
if (drm_rect_width(&pipe_cfg->src_rect) > max_linewidth) {
/*
 * In parallel multirect case only the half of the usual width
@@ -1082,21 +1087,32 @@ static void dpu_plane_sspp_atomic_update(struct 
drm_plane *plane)
struct drm_crtc *crtc = state->crtc;
struct drm_framebuffer *fb = state->fb;
bool is_rt_pipe;
-   const struct dpu_format *fmt =
-   to_dpu_format(msm_framebuffer_format(fb));
+   const struct dpu_format *fmt;
struct dpu_sw_pipe_cfg *pipe_cfg = &pstate->pipe_cfg;
struct dpu_sw_pipe_cfg *r_pipe_cfg = &pstate->r_pipe_cfg;
struct dpu_kms *kms = _dpu_plane_get_kms(&pdpu->base);
struct msm_gem_address_space *aspace = kms->base.aspace;
struct dpu_hw_fmt_layout layout;
bool layout_valid = false;
-   int ret;
  
-	ret = dpu_format_populate_layout(aspace, fb, &layout);

-   if (ret)
-   DPU_ERROR_PLANE(pdpu, "failed to get format layout, %d\n", ret);
-   else
-   layout_valid = true;
+   if (state->pixel_source == DRM_PLANE_PIXEL_SOURCE_FB && fb) {
+   int ret;
+
+   fmt = to_dpu_format(msm_framebuffer_format(fb));
+
+   ret = dpu_format_populate_layout(aspace, fb, &layout);
+   if (ret)
+   DPU_ERROR_PLANE(pdpu, "failed to get format layout, 
%d\n", ret);
+   else
+   layout_valid = true;
+
+   DPU_DEBUG_PLANE(pdpu, "FB[%u] " DRM_RECT_FP_FMT "->crtc%u " 
DRM_RECT_FMT
+   ", %4.4s ubwc %d\n", fb->base.id, 
DRM_RECT_FP_ARG(&state->src),
+   crtc->base.id, DRM_RECT_ARG(&state->dst),
+   (char *)&fmt->base.pixel_format, 
DPU_FORMAT_IS_UBWC(fmt));
+   } else {
+   fmt =

Re: [PATCH RFC v4 5/7] drm/msm/dpu: Add solid fill and pixel source properties

[Dmitry Baryshkov]

On 30/06/2023 03:25, Jessica Zhang wrote:

Add solid_fill and pixel_source properties to DPU plane

Signed-off-by: Jessica Zhang 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 2 ++
  1 file changed, 2 insertions(+)


This should be the last commit.
Otherwise:

Reviewed-by: Dmitry Baryshkov 



diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index c2aaaded07ed..5f0984ce62b1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -1429,6 +1429,8 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
DPU_ERROR("failed to install zpos property, rc = %d\n", ret);
  
  	drm_plane_create_alpha_property(plane);

+   drm_plane_create_solid_fill_property(plane);
+   drm_plane_create_pixel_source_property(plane, 
BIT(DRM_PLANE_PIXEL_SOURCE_COLOR));
drm_plane_create_blend_mode_property(plane,
BIT(DRM_MODE_BLEND_PIXEL_NONE) |
BIT(DRM_MODE_BLEND_PREMULTI) |



--
With best wishes
Dmitry

Re: [PATCH RFC v4 4/7] drm/atomic: Loosen FB atomic checks

[Dmitry Baryshkov]

On 30/06/2023 03:25, Jessica Zhang wrote:

Loosen the requirements for atomic and legacy commit so that, in cases
where solid fill planes is enabled but no FB is set, the commit can
still go through.

This includes adding framebuffer NULL checks in other areas to account
for FB being NULL when solid fill is enabled.

Signed-off-by: Jessica Zhang 
---
  drivers/gpu/drm/drm_atomic.c| 14 +++---
  drivers/gpu/drm/drm_atomic_helper.c | 34 --
  drivers/gpu/drm/drm_plane.c |  8 
  include/drm/drm_atomic_helper.h |  4 ++--
  include/drm/drm_plane.h | 28 
  5 files changed, 61 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 404b984d2d9f..ec9681c25366 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -668,14 +668,14 @@ static int drm_atomic_plane_check(const struct 
drm_plane_state *old_plane_state,
const struct drm_framebuffer *fb = new_plane_state->fb;
int ret;
  
-	/* either *both* CRTC and FB must be set, or neither */

-   if (crtc && !fb) {
-   drm_dbg_atomic(plane->dev, "[PLANE:%d:%s] CRTC set but no FB\n",
+   /* either *both* CRTC and pixel source must be set, or neither */
+   if (crtc && !drm_plane_has_visible_data(new_plane_state)) {
+   drm_dbg_atomic(plane->dev, "[PLANE:%d:%s] CRTC set but no visible 
data\n",
   plane->base.id, plane->name);
return -EINVAL;
-   } else if (fb && !crtc) {
-   drm_dbg_atomic(plane->dev, "[PLANE:%d:%s] FB set but no CRTC\n",
-  plane->base.id, plane->name);
+   } else if (drm_plane_has_visible_data(new_plane_state) && !crtc) {
+   drm_dbg_atomic(plane->dev, "[PLANE:%d:%s] Source %d has visible data 
but no CRTC\n",
+  plane->base.id, plane->name, 
new_plane_state->pixel_source);
return -EINVAL;
}
  
@@ -706,7 +706,7 @@ static int drm_atomic_plane_check(const struct drm_plane_state *old_plane_state,

}
  
  
-	if (fb) {

+   if (new_plane_state->pixel_source == DRM_PLANE_PIXEL_SOURCE_FB && fb) {
ret = drm_atomic_check_fb(new_plane_state);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 41b8066f61ff..d05ec9ef2b3e 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -864,7 +864,7 @@ int drm_atomic_helper_check_plane_state(struct 
drm_plane_state *plane_state,
*src = drm_plane_state_src(plane_state);
*dst = drm_plane_state_dest(plane_state);
  
-	if (!fb) {

+   if (!drm_plane_has_visible_data(plane_state)) {
plane_state->visible = false;
return 0;
}
@@ -881,25 +881,31 @@ int drm_atomic_helper_check_plane_state(struct 
drm_plane_state *plane_state,
return -EINVAL;
}
  
-	drm_rect_rotate(src, fb->width << 16, fb->height << 16, rotation);

+   if (plane_state->pixel_source == DRM_PLANE_PIXEL_SOURCE_FB && fb) {
+   drm_rect_rotate(src, fb->width << 16, fb->height << 16, 
rotation);
  
-	/* Check scaling */

-   hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
-   vscale = drm_rect_calc_vscale(src, dst, min_scale, max_scale);
-   if (hscale < 0 || vscale < 0) {
-   drm_dbg_kms(plane_state->plane->dev,
-   "Invalid scaling of plane\n");
-   drm_rect_debug_print("src: ", &plane_state->src, true);
-   drm_rect_debug_print("dst: ", &plane_state->dst, false);
-   return -ERANGE;
+   /* Check scaling */
+   hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
+   vscale = drm_rect_calc_vscale(src, dst, min_scale, max_scale);
+
+   if (hscale < 0 || vscale < 0) {
+   drm_dbg_kms(plane_state->plane->dev,
+   "Invalid scaling of plane\n");
+   drm_rect_debug_print("src: ", &plane_state->src, true);
+   drm_rect_debug_print("dst: ", &plane_state->dst, false);
+   return -ERANGE;
+   }
}
  
  	if (crtc_state->enable)

drm_mode_get_hv_timing(&crtc_state->mode, &clip.x2, &clip.y2);
  
-	plane_state->visible = drm_rect_clip_scaled(src, dst, &clip);

-
-   drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16, rotation);
+   if (plane_state->pixel_source == DRM_PLANE_PIXEL_SOURCE_FB && fb) {
+   plane_state->visible = drm_rect_clip_scaled(src, dst, &clip);
+   drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16, 
rotation);
+   } else if (drm_plane_solid_fill_enabled(plane

Re: [PATCH RFC v4 3/7] drm/atomic: Move framebuffer checks to helper

[Dmitry Baryshkov]

On 30/06/2023 03:25, Jessica Zhang wrote:

Currently framebuffer checks happen directly in
drm_atomic_plane_check(). Move these checks into their own helper
method.

Signed-off-by: Jessica Zhang 
---
  drivers/gpu/drm/drm_atomic.c | 130 ---
  1 file changed, 74 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index b4c6ffc438da..404b984d2d9f 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -580,6 +580,76 @@ plane_switching_crtc(const struct drm_plane_state 
*old_plane_state,
return true;
  }
  
+static int drm_atomic_check_fb(const struct drm_plane_state *state)

+{
+   struct drm_plane *plane = state->plane;
+   const struct drm_framebuffer *fb = state->fb;
+   struct drm_mode_rect *clips;
+
+   uint32_t num_clips;
+   unsigned int fb_width, fb_height;
+   int ret;
+
+   /* Check whether this plane supports the fb pixel format. */
+   ret = drm_plane_check_pixel_format(plane, fb->format->format,
+  fb->modifier);
+
+   if (ret) {
+   drm_dbg_atomic(plane->dev,
+  "[PLANE:%d:%s] invalid pixel format %p4cc, modifier 
0x%llx\n",
+  plane->base.id, plane->name,
+  &fb->format->format, fb->modifier);
+   return ret;
+   }
+
+   fb_width = fb->width << 16;
+   fb_height = fb->height << 16;
+
+   /* Make sure source coordinates are inside the fb. */
+   if (state->src_w > fb_width ||
+   state->src_x > fb_width - state->src_w ||
+   state->src_h > fb_height ||
+   state->src_y > fb_height - state->src_h) {
+   drm_dbg_atomic(plane->dev,
+  "[PLANE:%d:%s] invalid source coordinates "
+  "%u.%06ux%u.%06u+%u.%06u+%u.%06u (fb %ux%u)\n",
+  plane->base.id, plane->name,
+  state->src_w >> 16,
+  ((state->src_w & 0x) * 15625) >> 10,
+  state->src_h >> 16,
+  ((state->src_h & 0x) * 15625) >> 10,
+  state->src_x >> 16,
+  ((state->src_x & 0x) * 15625) >> 10,
+  state->src_y >> 16,
+  ((state->src_y & 0x) * 15625) >> 10,
+  fb->width, fb->height);
+   return -ENOSPC;
+   }
+
+   clips = __drm_plane_get_damage_clips(state);
+   num_clips = drm_plane_get_damage_clips_count(state);
+
+   /* Make sure damage clips are valid and inside the fb. */
+   while (num_clips > 0) {
+   if (clips->x1 >= clips->x2 ||
+   clips->y1 >= clips->y2 ||
+   clips->x1 < 0 ||
+   clips->y1 < 0 ||
+   clips->x2 > fb_width ||
+   clips->y2 > fb_height) {
+   drm_dbg_atomic(plane->dev,
+  "[PLANE:%d:%s] invalid damage clip %d %d %d 
%d\n",
+  plane->base.id, plane->name, clips->x1,
+  clips->y1, clips->x2, clips->y2);
+   return -EINVAL;
+   }
+   clips++;
+   num_clips--;
+   }
+
+   return 0;
+}
+
  /**
   * drm_atomic_plane_check - check plane state
   * @old_plane_state: old plane state to check
@@ -596,9 +666,6 @@ static int drm_atomic_plane_check(const struct 
drm_plane_state *old_plane_state,
struct drm_plane *plane = new_plane_state->plane;
struct drm_crtc *crtc = new_plane_state->crtc;
const struct drm_framebuffer *fb = new_plane_state->fb;
-   unsigned int fb_width, fb_height;
-   struct drm_mode_rect *clips;
-   uint32_t num_clips;
int ret;
  
  	/* either *both* CRTC and FB must be set, or neither */

@@ -625,17 +692,6 @@ static int drm_atomic_plane_check(const struct 
drm_plane_state *old_plane_state,
return -EINVAL;
}
  
-	/* Check whether this plane supports the fb pixel format. */

-   ret = drm_plane_check_pixel_format(plane, fb->format->format,
-  fb->modifier);
-   if (ret) {
-   drm_dbg_atomic(plane->dev,
-  "[PLANE:%d:%s] invalid pixel format %p4cc, modifier 
0x%llx\n",
-  plane->base.id, plane->name,
-  &fb->format->format, fb->modifier);
-   return ret;
-   }
-
/* Give drivers some help against integer overflows */
if (new_plane_state->crtc_w > INT_MAX ||
new_plane_state->crtc_x > INT_MAX - (int32_t) 
new_plane_state->crtc_w ||
@@ -649,49 +705,11 @@ s

Re: [PATCH RFC v4 2/7] drm: Introduce pixel_source DRM plane property

[Dmitry Baryshkov]

On 30/06/2023 03:25, Jessica Zhang wrote:

Add support for pixel_source property to drm_plane and related
documentation.

This enum property will allow user to specify a pixel source for the
plane. Possible pixel sources will be defined in the
drm_plane_pixel_source enum.

The current possible pixel sources are DRM_PLANE_PIXEL_SOURCE_FB and
DRM_PLANE_PIXEL_SOURCE_COLOR. The default value is *_SOURCE_FB.


I think, this should come before the solid fill property addition. First 
you tell that there is a possibility to define other pixel sources, then 
additional sources are defined.




Signed-off-by: Jessica Zhang 
---
  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
  drivers/gpu/drm/drm_atomic_uapi.c |  4 ++
  drivers/gpu/drm/drm_blend.c   | 81 +++
  include/drm/drm_blend.h   |  2 +
  include/drm/drm_plane.h   | 21 
  5 files changed, 109 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c 
b/drivers/gpu/drm/drm_atomic_state_helper.c
index fe14be2bd2b2..86fb876efbe6 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -252,6 +252,7 @@ void __drm_atomic_helper_plane_state_reset(struct 
drm_plane_state *plane_state,
  
  	plane_state->alpha = DRM_BLEND_ALPHA_OPAQUE;

plane_state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
+   plane_state->pixel_source = DRM_PLANE_PIXEL_SOURCE_FB;
  
  	if (plane_state->solid_fill_blob) {

drm_property_blob_put(plane_state->solid_fill_blob);
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index a28b4ee79444..6e59c21af66b 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -596,6 +596,8 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
drm_property_blob_put(solid_fill);
  
  		return ret;

+   } else if (property == plane->pixel_source_property) {
+   state->pixel_source = val;
} else if (property == plane->alpha_property) {
state->alpha = val;
} else if (property == plane->blend_mode_property) {


I think, it was pointed out in the discussion that drm_mode_setplane() 
(a pre-atomic IOCTL to turn the plane on and off) should also reset 
pixel_source to FB.



@@ -671,6 +673,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
} else if (property == plane->solid_fill_property) {
*val = state->solid_fill_blob ?
state->solid_fill_blob->base.id : 0;
+   } else if (property == plane->pixel_source_property) {
+   *val = state->pixel_source;
} else if (property == plane->alpha_property) {
*val = state->alpha;
} else if (property == plane->blend_mode_property) {
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index 38c3c5d6453a..8c100a957ee2 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -189,6 +189,18 @@
   *solid_fill is set up with drm_plane_create_solid_fill_property(). It
   *contains pixel data that drivers can use to fill a plane.
   *
+ * pixel_source:
+ * pixel_source is set up with drm_plane_create_pixel_source_property().
+ * It is used to toggle the source of pixel data for the plane.
+ *
+ * Possible values:
+ *
+ * "FB":
+ * Framebuffer source
+ *
+ * "COLOR":
+ * solid_fill source
+ *
   * Note that all the property extensions described here apply either to the
   * plane or the CRTC (e.g. for the background color, which currently is not
   * exposed and assumed to be black).
@@ -648,3 +660,72 @@ int drm_plane_create_solid_fill_property(struct drm_plane 
*plane)
return 0;
  }
  EXPORT_SYMBOL(drm_plane_create_solid_fill_property);
+
+/**
+ * drm_plane_create_pixel_source_property - create a new pixel source property
+ * @plane: drm plane
+ * @supported_sources: bitmask of supported pixel_sources for the driver (NOT
+ * including DRM_PLANE_PIXEL_SOURCE_FB, as it will be 
supported
+ * by default).


I'd say this is too strong. I'd suggest either renaming this to 
extra_sources (mentioning that FB is enabled for all the planes) or 
allowing any source bitmask (mentioning that FB should be enabled by the 
caller, unless there is a good reason not to do so).



+ *
+ * This creates a new property describing the current source of pixel data for 
the
+ * plane.
+ *
+ * The property is exposed to userspace as an enumeration property called
+ * "pixel_source" and has the following enumeration values:
+ *
+ * "FB":
+ * Framebuffer pixel source
+ *
+ * "COLOR":
+ * Solid fill color pixel source
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_plane_create_pixel_source_property(struct drm_plane *plane,
+  uns

Re: [v2] drm/panel: Fine tune Starry-ili9882t panel HFP and HBP

[Doug Anderson]

Hi,

On Tue, Jun 27, 2023 at 2:17 PM Doug Anderson  wrote:
>
> Hi,
>
> On Mon, Jun 26, 2023 at 10:01 PM Cong Yang
>  wrote:
> >
> > Because the setting of hproch is too small, there will be warning in

I realized that hproch should be hporch. I fixed when applying.


> > kernel log[1]. After fine tune the HFP and HBP, this warning can be
> > solved. The actual measurement frame rate is 60.1Hz.
> >
> > [1]: WARNING kernel:[drm] HFP + HBP less than d-phy, FPS will under 60Hz
>
> Thanks for including the warming. This looks like something that's
> only printed on Mediatek display controllers. Just out of curiosity:
> is that because Mediatek controllers have special requirements, or is
> this something generic and the Mediatek controller is the only one
> that warns about it?
>
>
> > Fixes: 8716a6473e6c ("drm/panel: Support for Starry-ili9882t TDDI
> > MIPI-DSI panel")
>
> Ideally the tool you have to send mail wouldn't wrap the Fixes line.
> Probably not worth resending just for this, but see if there's
> something you can do to fix this in the future.
>
> Since this is a tiny fix, I don't think we need to wait too long. I'll
> plan to land it on Thursday unless Neil wants to land it himself
> sooner.
>
> Reviewed-by: Douglas Anderson 

OK, landed. This is a weird time to land since this is a fix and the
fix has already made its way to Linus's tree but -rc1 isn't ready yet.
>From reading the flowchart in the committer guidelines:

https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-misc.html

...this means that it lands in drm-misc-next-fixes, so I've pushed it there.

59bba51ec2a5 drm/panel: Fine tune Starry-ili9882t panel HFP and HBP

-Doug

[PATCH RFC v4 7/7] drm/msm/dpu: Use DRM solid_fill property

[Jessica Zhang]

Drop DPU_PLANE_COLOR_FILL_FLAG and check the DRM solid_fill property to
determine if the plane is solid fill. In addition drop the DPU plane
color_fill field as we can now use drm_plane_state.solid_fill instead,
and pass in drm_plane_state.alpha to _dpu_plane_color_fill_pipe() to
allow userspace to configure the alpha value for the solid fill color.

Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 4476722f03bb..11d4fb771a1f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -42,7 +42,6 @@
 #define SHARP_SMOOTH_THR_DEFAULT   8
 #define SHARP_NOISE_THR_DEFAULT2
 
-#define DPU_PLANE_COLOR_FILL_FLAG  BIT(31)
 #define DPU_ZPOS_MAX 255
 
 /*
@@ -82,7 +81,6 @@ struct dpu_plane {
 
enum dpu_sspp pipe;
 
-   uint32_t color_fill;
bool is_error;
bool is_rt_pipe;
const struct dpu_mdss_cfg *catalog;
@@ -606,6 +604,17 @@ static void _dpu_plane_color_fill_pipe(struct 
dpu_plane_state *pstate,
_dpu_plane_setup_scaler(pipe, fmt, true, &pipe_cfg, pstate->rotation);
 }
 
+static uint32_t _dpu_plane_get_fill_color(struct drm_solid_fill solid_fill)
+{
+   uint32_t ret = 0;
+
+   ret |= ((uint8_t) solid_fill.b) << 16;
+   ret |= ((uint8_t) solid_fill.g) << 8;
+   ret |= ((uint8_t) solid_fill.r);
+
+   return ret;
+}
+
 /**
  * _dpu_plane_color_fill - enables color fill on plane
  * @pdpu:   Pointer to DPU plane object
@@ -977,9 +986,9 @@ void dpu_plane_flush(struct drm_plane *plane)
if (pdpu->is_error)
/* force white frame with 100% alpha pipe output on error */
_dpu_plane_color_fill(pdpu, 0xFF, 0xFF);
-   else if (pdpu->color_fill & DPU_PLANE_COLOR_FILL_FLAG)
-   /* force 100% alpha */
-   _dpu_plane_color_fill(pdpu, pdpu->color_fill, 0xFF);
+   else if (drm_plane_solid_fill_enabled(plane->state))
+   _dpu_plane_color_fill(pdpu, 
_dpu_plane_get_fill_color(plane->state->solid_fill),
+   plane->state->alpha);
else {
dpu_plane_flush_csc(pdpu, &pstate->pipe);
dpu_plane_flush_csc(pdpu, &pstate->r_pipe);
@@ -1024,7 +1033,7 @@ static void dpu_plane_sspp_update_pipe(struct drm_plane 
*plane,
}
 
/* override for color fill */
-   if (pdpu->color_fill & DPU_PLANE_COLOR_FILL_FLAG) {
+   if (drm_plane_solid_fill_enabled(plane->state)) {
_dpu_plane_set_qos_ctrl(plane, pipe, false);
 
/* skip remaining processing on color fill */

-- 
2.41.0

[PATCH RFC v4 1/7] drm: Introduce solid fill DRM plane property

[Jessica Zhang]

Document and add support for solid_fill property to drm_plane. In
addition, add support for setting and getting the values for solid_fill.

To enable solid fill planes, userspace must assign a property blob to
the "solid_fill" plane property containing the following information:

struct drm_solid_fill_info {
u8 version;
u32 r, g, b;
};

Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/drm_atomic_state_helper.c |  9 +
 drivers/gpu/drm/drm_atomic_uapi.c | 55 +++
 drivers/gpu/drm/drm_blend.c   | 33 +++
 include/drm/drm_blend.h   |  1 +
 include/drm/drm_plane.h   | 43 
 5 files changed, 141 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c 
b/drivers/gpu/drm/drm_atomic_state_helper.c
index 784e63d70a42..fe14be2bd2b2 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -253,6 +253,11 @@ void __drm_atomic_helper_plane_state_reset(struct 
drm_plane_state *plane_state,
plane_state->alpha = DRM_BLEND_ALPHA_OPAQUE;
plane_state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
 
+   if (plane_state->solid_fill_blob) {
+   drm_property_blob_put(plane_state->solid_fill_blob);
+   plane_state->solid_fill_blob = NULL;
+   }
+
if (plane->color_encoding_property) {
if (!drm_object_property_get_default_value(&plane->base,
   
plane->color_encoding_property,
@@ -335,6 +340,9 @@ void __drm_atomic_helper_plane_duplicate_state(struct 
drm_plane *plane,
if (state->fb)
drm_framebuffer_get(state->fb);
 
+   if (state->solid_fill_blob)
+   drm_property_blob_get(state->solid_fill_blob);
+
state->fence = NULL;
state->commit = NULL;
state->fb_damage_clips = NULL;
@@ -384,6 +392,7 @@ void __drm_atomic_helper_plane_destroy_state(struct 
drm_plane_state *state)
drm_crtc_commit_put(state->commit);
 
drm_property_blob_put(state->fb_damage_clips);
+   drm_property_blob_put(state->solid_fill_blob);
 }
 EXPORT_SYMBOL(__drm_atomic_helper_plane_destroy_state);
 
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index d867e7f9f2cd..a28b4ee79444 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -316,6 +316,51 @@ drm_atomic_set_crtc_for_connector(struct 
drm_connector_state *conn_state,
 }
 EXPORT_SYMBOL(drm_atomic_set_crtc_for_connector);
 
+static int drm_atomic_set_solid_fill_prop(struct drm_plane_state *state,
+   struct drm_property_blob *blob)
+{
+   int ret = 0;
+   int blob_version;
+
+   if (blob == state->solid_fill_blob)
+   return 0;
+
+   drm_property_blob_put(state->solid_fill_blob);
+   state->solid_fill_blob = NULL;
+
+   memset(&state->solid_fill, 0, sizeof(state->solid_fill));
+
+   if (blob) {
+   struct drm_solid_fill_info *user_info = (struct 
drm_solid_fill_info *)blob->data;
+
+   if (blob->length != sizeof(struct drm_solid_fill_info)) {
+   drm_dbg_atomic(state->plane->dev,
+  "[PLANE:%d:%s] bad solid fill blob 
length: %zu\n",
+  state->plane->base.id, 
state->plane->name,
+  blob->length);
+   return -EINVAL;
+   }
+
+   blob_version = user_info->version;
+
+   /* Add more versions if necessary */
+   if (blob_version == 1) {
+   state->solid_fill.r = user_info->r;
+   state->solid_fill.g = user_info->g;
+   state->solid_fill.b = user_info->b;
+   } else {
+   drm_dbg_atomic(state->plane->dev,
+  "[PLANE:%d:%s] failed to set solid fill 
(ret=%d)\n",
+  state->plane->base.id, 
state->plane->name,
+  ret);
+   return -EINVAL;
+   }
+   state->solid_fill_blob = drm_property_blob_get(blob);
+   }
+
+   return ret;
+}
+
 static void set_out_fence_for_crtc(struct drm_atomic_state *state,
   struct drm_crtc *crtc, s32 __user *fence_ptr)
 {
@@ -544,6 +589,13 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
state->src_w = val;
} else if (property == config->prop_src_h) {
state->src_h = val;
+   } else if (property == plane->solid_fill_property) {
+   struct drm_property_blob *solid_fill = 
drm_property_lookup_blob(dev, val);
+
+   ret = drm_atomic_set_solid_fill_prop(state, solid_fill);
+   d

[PATCH RFC v4 5/7] drm/msm/dpu: Add solid fill and pixel source properties

[Jessica Zhang]

Add solid_fill and pixel_source properties to DPU plane

Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index c2aaaded07ed..5f0984ce62b1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -1429,6 +1429,8 @@ struct drm_plane *dpu_plane_init(struct drm_device *dev,
DPU_ERROR("failed to install zpos property, rc = %d\n", ret);
 
drm_plane_create_alpha_property(plane);
+   drm_plane_create_solid_fill_property(plane);
+   drm_plane_create_pixel_source_property(plane, 
BIT(DRM_PLANE_PIXEL_SOURCE_COLOR));
drm_plane_create_blend_mode_property(plane,
BIT(DRM_MODE_BLEND_PIXEL_NONE) |
BIT(DRM_MODE_BLEND_PREMULTI) |

-- 
2.41.0

[PATCH RFC v4 0/7] Support for Solid Fill Planes

[Jessica Zhang]

Some drivers support hardware that have optimizations for solid fill
planes. This series aims to expose these capabilities to userspace as
some compositors have a solid fill flag (ex. SOLID_COLOR in the Android
hardware composer HAL) that can be set by apps like the Android Gears
app.

In order to expose this capability to userspace, this series will:

- Introduce solid_fill and pixel_source properties to allow userspace to
  toggle between FB and solid fill sources
- Loosen NULL FB checks within the DRM atomic commit callstack to allow
  for NULL FB when solid fill is enabled.
- Add NULL FB checks in methods where FB was previously assumed to be
  non-NULL
- Have MSM DPU driver use drm_plane_state.solid_fill instead of
  dpu_plane_state.color_fill

Note: The solid fill planes feature depends on both the solid_fill *and*
pixel_source properties.

To use this feature, userspace can set the solid_fill property to a blob
containing the appropriate version number and solid fill color (in
RGB323232 format) and and setting the pixel_source property to
DRM_PLANE_PIXEL_SOURCE_COLOR. This will disable memory fetch and the
resulting plane will display the color specified by the solid_fill blob.

Currently, there's only one version of the solid_fill blob property.
However if other drivers want to support a similar feature, but require
more than just the solid fill color, they can extend this feature by
creating additional versions of the drm_solid_fill struct.

This 2 property approach was chosen because passing in a special 1x1 FB
with the necessary color information would have unecessary overhead that
does not reflect the behavior of the solid fill feature. In addition,
assigning the solid fill blob to FB_ID would require loosening some core
drm_property checks that might cause unwanted side effects elsewhere.

---
Changes in v4:
- Rebased onto latest kernel
- Reworded cover letter for clarity (Dmitry)
- Reworded commit messages for clarity
- Split existing changes into smaller commits
- Added pixel_source enum property (Dmitry, Pekka, Ville)
- Updated drm-kms comment docs with pixel_source and solid_fill
  properties (Dmitry)
- Inlined drm_atomic_convert_solid_fill_info() (Dmitry)
- Passed in plane state alpha value to _dpu_plane_color_fill_pipe()
- Link to v3: 
https://lore.kernel.org/r/20230104234036.636-1-quic_jessz...@quicinc.com

Changes in v3:
- Fixed some logic errors in atomic checks (Dmitry)
- Introduced drm_plane_has_visible_data() and drm_atomic_check_fb() helper
  methods (Dmitry)
- Fixed typo in drm_solid_fill struct documentation
- Created drm_plane_has_visible_data() helper and corrected CRTC and FB
  NULL-check logic (Dmitry)
- Merged `if (fb)` blocks in drm_atomic_plane_check() and abstracted
  them into helper method (Dmitry)
- Inverted `if (solid_fill_enabled) else if (fb)` check order (Dmitry)
- Fixed indentation (Dmitry)

Changes in v2:
- Dropped SOLID_FILL_FORMAT property (Simon)
- Switched to implementing solid_fill property as a blob (Simon, Dmitry)
- Added drm_solid_fill and drm_solid_fill_info structs (Simon)
- Changed to checks for if solid_fill_blob is set (Dmitry)
- Abstracted (plane_state && !solid_fill_blob) checks to helper method
  (Dmitry)
- Removed DPU_PLANE_COLOR_FILL_FLAG
- Fixed whitespace and indentation issues (Dmitry)
- Changed to checks for if solid_fill_blob is set (Dmitry)
- Abstracted (plane_state && !solid_fill_blob) checks to helper method
  (Dmitry)
- Fixed dropped 'const' warning
- Added helper to convert color fill to BGR888 (Rob)
- Fixed indentation issue (Dmitry)
- Added support for solid fill on planes of varying sizes

---
Jessica Zhang (7):
  drm: Introduce solid fill DRM plane property
  drm: Introduce pixel_source DRM plane property
  drm/atomic: Move framebuffer checks to helper
  drm/atomic: Loosen FB atomic checks
  drm/msm/dpu: Add solid fill and pixel source properties
  drm/msm/dpu: Allow NULL FBs in atomic commit
  drm/msm/dpu: Use DRM solid_fill property

 drivers/gpu/drm/drm_atomic.c  | 142 +-
 drivers/gpu/drm/drm_atomic_helper.c   |  34 ---
 drivers/gpu/drm/drm_atomic_state_helper.c |  10 +++
 drivers/gpu/drm/drm_atomic_uapi.c |  59 +
 drivers/gpu/drm/drm_blend.c   | 114 
 drivers/gpu/drm/drm_plane.c   |   8 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |   9 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c |  68 +-
 include/drm/drm_atomic_helper.h   |   4 +-
 include/drm/drm_blend.h   |   3 +
 include/drm/drm_plane.h   |  92 +++
 11 files changed, 437 insertions(+), 106 deletions(-)
---
base-commit: a0364260213c96f6817f7e85cdce293cb743460f
change-id: 20230404-solid-fill-05016175db36

Best regards,
-- 
Jessica Zhang 

[PATCH RFC v4 4/7] drm/atomic: Loosen FB atomic checks

[Jessica Zhang]

Loosen the requirements for atomic and legacy commit so that, in cases
where solid fill planes is enabled but no FB is set, the commit can
still go through.

This includes adding framebuffer NULL checks in other areas to account
for FB being NULL when solid fill is enabled.

Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/drm_atomic.c| 14 +++---
 drivers/gpu/drm/drm_atomic_helper.c | 34 --
 drivers/gpu/drm/drm_plane.c |  8 
 include/drm/drm_atomic_helper.h |  4 ++--
 include/drm/drm_plane.h | 28 
 5 files changed, 61 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 404b984d2d9f..ec9681c25366 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -668,14 +668,14 @@ static int drm_atomic_plane_check(const struct 
drm_plane_state *old_plane_state,
const struct drm_framebuffer *fb = new_plane_state->fb;
int ret;
 
-   /* either *both* CRTC and FB must be set, or neither */
-   if (crtc && !fb) {
-   drm_dbg_atomic(plane->dev, "[PLANE:%d:%s] CRTC set but no FB\n",
+   /* either *both* CRTC and pixel source must be set, or neither */
+   if (crtc && !drm_plane_has_visible_data(new_plane_state)) {
+   drm_dbg_atomic(plane->dev, "[PLANE:%d:%s] CRTC set but no 
visible data\n",
   plane->base.id, plane->name);
return -EINVAL;
-   } else if (fb && !crtc) {
-   drm_dbg_atomic(plane->dev, "[PLANE:%d:%s] FB set but no CRTC\n",
-  plane->base.id, plane->name);
+   } else if (drm_plane_has_visible_data(new_plane_state) && !crtc) {
+   drm_dbg_atomic(plane->dev, "[PLANE:%d:%s] Source %d has visible 
data but no CRTC\n",
+  plane->base.id, plane->name, 
new_plane_state->pixel_source);
return -EINVAL;
}
 
@@ -706,7 +706,7 @@ static int drm_atomic_plane_check(const struct 
drm_plane_state *old_plane_state,
}
 
 
-   if (fb) {
+   if (new_plane_state->pixel_source == DRM_PLANE_PIXEL_SOURCE_FB && fb) {
ret = drm_atomic_check_fb(new_plane_state);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 41b8066f61ff..d05ec9ef2b3e 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -864,7 +864,7 @@ int drm_atomic_helper_check_plane_state(struct 
drm_plane_state *plane_state,
*src = drm_plane_state_src(plane_state);
*dst = drm_plane_state_dest(plane_state);
 
-   if (!fb) {
+   if (!drm_plane_has_visible_data(plane_state)) {
plane_state->visible = false;
return 0;
}
@@ -881,25 +881,31 @@ int drm_atomic_helper_check_plane_state(struct 
drm_plane_state *plane_state,
return -EINVAL;
}
 
-   drm_rect_rotate(src, fb->width << 16, fb->height << 16, rotation);
+   if (plane_state->pixel_source == DRM_PLANE_PIXEL_SOURCE_FB && fb) {
+   drm_rect_rotate(src, fb->width << 16, fb->height << 16, 
rotation);
 
-   /* Check scaling */
-   hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
-   vscale = drm_rect_calc_vscale(src, dst, min_scale, max_scale);
-   if (hscale < 0 || vscale < 0) {
-   drm_dbg_kms(plane_state->plane->dev,
-   "Invalid scaling of plane\n");
-   drm_rect_debug_print("src: ", &plane_state->src, true);
-   drm_rect_debug_print("dst: ", &plane_state->dst, false);
-   return -ERANGE;
+   /* Check scaling */
+   hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
+   vscale = drm_rect_calc_vscale(src, dst, min_scale, max_scale);
+
+   if (hscale < 0 || vscale < 0) {
+   drm_dbg_kms(plane_state->plane->dev,
+   "Invalid scaling of plane\n");
+   drm_rect_debug_print("src: ", &plane_state->src, true);
+   drm_rect_debug_print("dst: ", &plane_state->dst, false);
+   return -ERANGE;
+   }
}
 
if (crtc_state->enable)
drm_mode_get_hv_timing(&crtc_state->mode, &clip.x2, &clip.y2);
 
-   plane_state->visible = drm_rect_clip_scaled(src, dst, &clip);
-
-   drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16, rotation);
+   if (plane_state->pixel_source == DRM_PLANE_PIXEL_SOURCE_FB && fb) {
+   plane_state->visible = drm_rect_clip_scaled(src, dst, &clip);
+   drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16, 
rotation);
+   } else if (drm_plane_solid_fill_enabled(plane_state)) {
+ 

[PATCH RFC v4 3/7] drm/atomic: Move framebuffer checks to helper

[Jessica Zhang]

Currently framebuffer checks happen directly in
drm_atomic_plane_check(). Move these checks into their own helper
method.

Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/drm_atomic.c | 130 ---
 1 file changed, 74 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index b4c6ffc438da..404b984d2d9f 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -580,6 +580,76 @@ plane_switching_crtc(const struct drm_plane_state 
*old_plane_state,
return true;
 }
 
+static int drm_atomic_check_fb(const struct drm_plane_state *state)
+{
+   struct drm_plane *plane = state->plane;
+   const struct drm_framebuffer *fb = state->fb;
+   struct drm_mode_rect *clips;
+
+   uint32_t num_clips;
+   unsigned int fb_width, fb_height;
+   int ret;
+
+   /* Check whether this plane supports the fb pixel format. */
+   ret = drm_plane_check_pixel_format(plane, fb->format->format,
+  fb->modifier);
+
+   if (ret) {
+   drm_dbg_atomic(plane->dev,
+  "[PLANE:%d:%s] invalid pixel format %p4cc, 
modifier 0x%llx\n",
+  plane->base.id, plane->name,
+  &fb->format->format, fb->modifier);
+   return ret;
+   }
+
+   fb_width = fb->width << 16;
+   fb_height = fb->height << 16;
+
+   /* Make sure source coordinates are inside the fb. */
+   if (state->src_w > fb_width ||
+   state->src_x > fb_width - state->src_w ||
+   state->src_h > fb_height ||
+   state->src_y > fb_height - state->src_h) {
+   drm_dbg_atomic(plane->dev,
+  "[PLANE:%d:%s] invalid source coordinates "
+  "%u.%06ux%u.%06u+%u.%06u+%u.%06u (fb %ux%u)\n",
+  plane->base.id, plane->name,
+  state->src_w >> 16,
+  ((state->src_w & 0x) * 15625) >> 10,
+  state->src_h >> 16,
+  ((state->src_h & 0x) * 15625) >> 10,
+  state->src_x >> 16,
+  ((state->src_x & 0x) * 15625) >> 10,
+  state->src_y >> 16,
+  ((state->src_y & 0x) * 15625) >> 10,
+  fb->width, fb->height);
+   return -ENOSPC;
+   }
+
+   clips = __drm_plane_get_damage_clips(state);
+   num_clips = drm_plane_get_damage_clips_count(state);
+
+   /* Make sure damage clips are valid and inside the fb. */
+   while (num_clips > 0) {
+   if (clips->x1 >= clips->x2 ||
+   clips->y1 >= clips->y2 ||
+   clips->x1 < 0 ||
+   clips->y1 < 0 ||
+   clips->x2 > fb_width ||
+   clips->y2 > fb_height) {
+   drm_dbg_atomic(plane->dev,
+  "[PLANE:%d:%s] invalid damage clip %d %d 
%d %d\n",
+  plane->base.id, plane->name, clips->x1,
+  clips->y1, clips->x2, clips->y2);
+   return -EINVAL;
+   }
+   clips++;
+   num_clips--;
+   }
+
+   return 0;
+}
+
 /**
  * drm_atomic_plane_check - check plane state
  * @old_plane_state: old plane state to check
@@ -596,9 +666,6 @@ static int drm_atomic_plane_check(const struct 
drm_plane_state *old_plane_state,
struct drm_plane *plane = new_plane_state->plane;
struct drm_crtc *crtc = new_plane_state->crtc;
const struct drm_framebuffer *fb = new_plane_state->fb;
-   unsigned int fb_width, fb_height;
-   struct drm_mode_rect *clips;
-   uint32_t num_clips;
int ret;
 
/* either *both* CRTC and FB must be set, or neither */
@@ -625,17 +692,6 @@ static int drm_atomic_plane_check(const struct 
drm_plane_state *old_plane_state,
return -EINVAL;
}
 
-   /* Check whether this plane supports the fb pixel format. */
-   ret = drm_plane_check_pixel_format(plane, fb->format->format,
-  fb->modifier);
-   if (ret) {
-   drm_dbg_atomic(plane->dev,
-  "[PLANE:%d:%s] invalid pixel format %p4cc, 
modifier 0x%llx\n",
-  plane->base.id, plane->name,
-  &fb->format->format, fb->modifier);
-   return ret;
-   }
-
/* Give drivers some help against integer overflows */
if (new_plane_state->crtc_w > INT_MAX ||
new_plane_state->crtc_x > INT_MAX - (int32_t) 
new_plane_state->crtc_w ||
@@ -649,49 +705,11 @@ static int drm_atomic_plane_check(const struct

[PATCH RFC v4 6/7] drm/msm/dpu: Allow NULL FBs in atomic commit

[Jessica Zhang]

Since solid fill planes allow for a NULL framebuffer in a valid commit,
add NULL framebuffer checks to atomic commit calls within DPU.

Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |  9 ++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 45 +++
 2 files changed, 36 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 1edf2b6b0a26..d1b37d2cc202 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -451,6 +451,7 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc 
*crtc,
struct drm_plane_state *state;
struct dpu_crtc_state *cstate = to_dpu_crtc_state(crtc->state);
struct dpu_plane_state *pstate = NULL;
+   const struct msm_format *fmt;
struct dpu_format *format;
struct dpu_hw_ctl *ctl = mixer->lm_ctl;
 
@@ -470,7 +471,13 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc 
*crtc,
pstate = to_dpu_plane_state(state);
fb = state->fb;
 
-   format = to_dpu_format(msm_framebuffer_format(pstate->base.fb));
+   if (state->pixel_source == DRM_PLANE_PIXEL_SOURCE_FB && fb)
+   fmt = msm_framebuffer_format(pstate->base.fb);
+   else
+   fmt = dpu_get_msm_format(&_dpu_crtc_get_kms(crtc)->base,
+   DRM_FORMAT_RGBA, 0);
+
+   format = to_dpu_format(fmt);
 
if (pstate->stage == DPU_STAGE_BASE && format->alpha_enable)
bg_alpha_enable = true;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 5f0984ce62b1..4476722f03bb 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -837,8 +837,10 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
 
pipe_cfg->dst_rect = new_plane_state->dst;
 
-   fb_rect.x2 = new_plane_state->fb->width;
-   fb_rect.y2 = new_plane_state->fb->height;
+   if (new_plane_state->pixel_source == DRM_PLANE_PIXEL_SOURCE_FB && 
new_plane_state->fb) {
+   fb_rect.x2 = new_plane_state->fb->width;
+   fb_rect.y2 = new_plane_state->fb->height;
+   }
 
/* Ensure fb size is supported */
if (drm_rect_width(&fb_rect) > MAX_IMG_WIDTH ||
@@ -848,10 +850,13 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
return -E2BIG;
}
 
-   fmt = to_dpu_format(msm_framebuffer_format(new_plane_state->fb));
-
max_linewidth = pdpu->catalog->caps->max_linewidth;
 
+   if (drm_plane_solid_fill_enabled(new_plane_state))
+   fmt = dpu_get_dpu_format(DRM_FORMAT_ABGR);
+   else
+   fmt = 
to_dpu_format(msm_framebuffer_format(new_plane_state->fb));
+
if (drm_rect_width(&pipe_cfg->src_rect) > max_linewidth) {
/*
 * In parallel multirect case only the half of the usual width
@@ -1082,21 +1087,32 @@ static void dpu_plane_sspp_atomic_update(struct 
drm_plane *plane)
struct drm_crtc *crtc = state->crtc;
struct drm_framebuffer *fb = state->fb;
bool is_rt_pipe;
-   const struct dpu_format *fmt =
-   to_dpu_format(msm_framebuffer_format(fb));
+   const struct dpu_format *fmt;
struct dpu_sw_pipe_cfg *pipe_cfg = &pstate->pipe_cfg;
struct dpu_sw_pipe_cfg *r_pipe_cfg = &pstate->r_pipe_cfg;
struct dpu_kms *kms = _dpu_plane_get_kms(&pdpu->base);
struct msm_gem_address_space *aspace = kms->base.aspace;
struct dpu_hw_fmt_layout layout;
bool layout_valid = false;
-   int ret;
 
-   ret = dpu_format_populate_layout(aspace, fb, &layout);
-   if (ret)
-   DPU_ERROR_PLANE(pdpu, "failed to get format layout, %d\n", ret);
-   else
-   layout_valid = true;
+   if (state->pixel_source == DRM_PLANE_PIXEL_SOURCE_FB && fb) {
+   int ret;
+
+   fmt = to_dpu_format(msm_framebuffer_format(fb));
+
+   ret = dpu_format_populate_layout(aspace, fb, &layout);
+   if (ret)
+   DPU_ERROR_PLANE(pdpu, "failed to get format layout, 
%d\n", ret);
+   else
+   layout_valid = true;
+
+   DPU_DEBUG_PLANE(pdpu, "FB[%u] " DRM_RECT_FP_FMT "->crtc%u " 
DRM_RECT_FMT
+   ", %4.4s ubwc %d\n", fb->base.id, 
DRM_RECT_FP_ARG(&state->src),
+   crtc->base.id, DRM_RECT_ARG(&state->dst),
+   (char *)&fmt->base.pixel_format, 
DPU_FORMAT_IS_UBWC(fmt));
+   } else {
+   fmt = dpu_get_dpu_format(DRM_FORMAT_ABGR);
+   }
 
pstate->pending = true;
 
@@ -1104,11 +1120,6 @@ static void dpu_plane_sspp_atomic_up

[PATCH RFC v4 2/7] drm: Introduce pixel_source DRM plane property

[Jessica Zhang]

Add support for pixel_source property to drm_plane and related
documentation.

This enum property will allow user to specify a pixel source for the
plane. Possible pixel sources will be defined in the
drm_plane_pixel_source enum.

The current possible pixel sources are DRM_PLANE_PIXEL_SOURCE_FB and
DRM_PLANE_PIXEL_SOURCE_COLOR. The default value is *_SOURCE_FB.

Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
 drivers/gpu/drm/drm_atomic_uapi.c |  4 ++
 drivers/gpu/drm/drm_blend.c   | 81 +++
 include/drm/drm_blend.h   |  2 +
 include/drm/drm_plane.h   | 21 
 5 files changed, 109 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c 
b/drivers/gpu/drm/drm_atomic_state_helper.c
index fe14be2bd2b2..86fb876efbe6 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -252,6 +252,7 @@ void __drm_atomic_helper_plane_state_reset(struct 
drm_plane_state *plane_state,
 
plane_state->alpha = DRM_BLEND_ALPHA_OPAQUE;
plane_state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
+   plane_state->pixel_source = DRM_PLANE_PIXEL_SOURCE_FB;
 
if (plane_state->solid_fill_blob) {
drm_property_blob_put(plane_state->solid_fill_blob);
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index a28b4ee79444..6e59c21af66b 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -596,6 +596,8 @@ static int drm_atomic_plane_set_property(struct drm_plane 
*plane,
drm_property_blob_put(solid_fill);
 
return ret;
+   } else if (property == plane->pixel_source_property) {
+   state->pixel_source = val;
} else if (property == plane->alpha_property) {
state->alpha = val;
} else if (property == plane->blend_mode_property) {
@@ -671,6 +673,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
} else if (property == plane->solid_fill_property) {
*val = state->solid_fill_blob ?
state->solid_fill_blob->base.id : 0;
+   } else if (property == plane->pixel_source_property) {
+   *val = state->pixel_source;
} else if (property == plane->alpha_property) {
*val = state->alpha;
} else if (property == plane->blend_mode_property) {
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index 38c3c5d6453a..8c100a957ee2 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -189,6 +189,18 @@
  * solid_fill is set up with drm_plane_create_solid_fill_property(). It
  * contains pixel data that drivers can use to fill a plane.
  *
+ * pixel_source:
+ * pixel_source is set up with drm_plane_create_pixel_source_property().
+ * It is used to toggle the source of pixel data for the plane.
+ *
+ * Possible values:
+ *
+ * "FB":
+ * Framebuffer source
+ *
+ * "COLOR":
+ * solid_fill source
+ *
  * Note that all the property extensions described here apply either to the
  * plane or the CRTC (e.g. for the background color, which currently is not
  * exposed and assumed to be black).
@@ -648,3 +660,72 @@ int drm_plane_create_solid_fill_property(struct drm_plane 
*plane)
return 0;
 }
 EXPORT_SYMBOL(drm_plane_create_solid_fill_property);
+
+/**
+ * drm_plane_create_pixel_source_property - create a new pixel source property
+ * @plane: drm plane
+ * @supported_sources: bitmask of supported pixel_sources for the driver (NOT
+ * including DRM_PLANE_PIXEL_SOURCE_FB, as it will be 
supported
+ * by default).
+ *
+ * This creates a new property describing the current source of pixel data for 
the
+ * plane.
+ *
+ * The property is exposed to userspace as an enumeration property called
+ * "pixel_source" and has the following enumeration values:
+ *
+ * "FB":
+ * Framebuffer pixel source
+ *
+ * "COLOR":
+ * Solid fill color pixel source
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_plane_create_pixel_source_property(struct drm_plane *plane,
+  unsigned int supported_sources)
+{
+   struct drm_device *dev = plane->dev;
+   struct drm_property *prop;
+   const struct drm_prop_enum_list enum_list[] = {
+   { DRM_PLANE_PIXEL_SOURCE_FB, "FB" },
+   { DRM_PLANE_PIXEL_SOURCE_COLOR, "COLOR" },
+   };
+   unsigned int valid_source_mask = BIT(DRM_PLANE_PIXEL_SOURCE_FB) |
+  BIT(DRM_PLANE_PIXEL_SOURCE_COLOR);
+   int i;
+
+   /* FB is supported by default */
+   supported_sources |= BIT(DRM_PLANE_PIXEL_SOURCE_FB);
+
+   if (WARN_ON(supported_sources & ~valid_source_mask))
+   return -EINVAL;
+
+ 

Re: [PATCH v3 1/3] drm/msm/dpu: re-introduce dpu core revision to the catalog

[Dmitry Baryshkov]

On 29/06/2023 22:29, Abhinav Kumar wrote:

With [1] dpu core revision was dropped in favor of using the
compatible string from the device tree to select the dpu catalog
being used in the device.

This approach works well however also necessitates adding catalog
entries for small register level details as dpu capabilities and/or
features bloating the catalog unnecessarily. Examples include but
are not limited to data_compress, interrupt register set, widebus etc.


Generic note: this description can be moved to the cover letter, it 
covers the series intent.



Introduce the dpu core revision back as an entry to the catalog so that
we can just use dpu revision checks and enable those bits which
should be enabled unconditionally and not controlled by a catalog
and also simplify the changes to do something like:

if (dpu_core_revision > x && dpu_core_revision < x)
enable the bit;

Since dpu's major and minor versions are now separate fields, lets
drop all the DPU_HW_VER macros.

[1]: https://patchwork.freedesktop.org/patch/530891/?series=113910&rev=4


Please use `commit aabbcc ("do this and that")' in the commit messages.



changes in v3:
- drop DPU step version as features are not changing across steps
- add core_major_version / core_minor_version to avoid conflicts
- update the commit text to drop references to the dpu macros

Signed-off-by: Abhinav Kumar 


--
With best wishes
Dmitry

Re: [PATCH v3 3/3] drm/msm/dpu: drop DPU_INTF_DATA_COMPRESS from dpu catalog

[Dmitry Baryshkov]

On 29/06/2023 22:29, Abhinav Kumar wrote:

Now that all usages of DPU_INTF_DATA_COMPRESS have been replaced
with the dpu core's major revision lets drop DPU_INTF_DATA_COMPRESS
from the catalog completely.

Signed-off-by: Abhinav Kumar 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 --
  2 files changed, 1 insertion(+), 3 deletions(-)


Reviewed-by: Dmitry Baryshkov 

--
With best wishes
Dmitry

Re: [PATCH v3 2/3] drm/msm/dpu: use dpu core's major version to enable data compress

[Dmitry Baryshkov]

On 29/06/2023 22:29, Abhinav Kumar wrote:

Instead of using a feature bit to decide whether to enable data
compress or not for DSC use-cases, use dpu core's major version instead.
This will avoid defining feature bits for every bit level details of
registers.

Also, rename the intf's enable_compression() op to program_datapath()
and allow it to accept a struct intf_dpu_datapath_cfg to program
all the bits at once. This can be re-used by widebus later on as
well as it touches the same register.


Two separate commits please, because...


Signed-off-by: Abhinav Kumar 
---
  .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c |  9 +++--
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c  |  9 +
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h  | 16 ++--
  3 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index b856c6286c85..f4e15b4c4cc9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -50,6 +50,7 @@ static void _dpu_encoder_phys_cmd_update_intf_cfg(
to_dpu_encoder_phys_cmd(phys_enc);
struct dpu_hw_ctl *ctl;
struct dpu_hw_intf_cfg intf_cfg = { 0 };
+   struct dpu_kms *dpu_kms = phys_enc->dpu_kms;
  
  	ctl = phys_enc->hw_ctl;

if (!ctl->ops.setup_intf_cfg)
@@ -68,8 +69,12 @@ static void _dpu_encoder_phys_cmd_update_intf_cfg(
phys_enc->hw_intf,
phys_enc->hw_pp->idx);
  
-	if (intf_cfg.dsc != 0 && phys_enc->hw_intf->ops.enable_compression)

-   phys_enc->hw_intf->ops.enable_compression(phys_enc->hw_intf);
+   if (intf_cfg.dsc != 0 && dpu_kms->catalog->core_major_version >= 0x7) {


... because this becomes incorrect. The datapath should be programmed in 
all the cases, if there is a corresponding callback. intf_cfg.dsc should 
be used as a condition to set datapath_cfg.




+   struct intf_dpu_datapath_cfg datapath_cfg = { 0 };


No need for `0' in the init, empty braces would be enough.


+
+   datapath_cfg.data_compress = true;
+   phys_enc->hw_intf->ops.program_datapath(phys_enc->hw_intf, 
&datapath_cfg);
+   }
  }
  
  static void dpu_encoder_phys_cmd_pp_tx_done_irq(void *arg, int irq_idx)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index 5b0f6627e29b..85333df08fbc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -513,11 +513,13 @@ static void dpu_hw_intf_disable_autorefresh(struct 
dpu_hw_intf *intf,
  
  }
  
-static void dpu_hw_intf_enable_compression(struct dpu_hw_intf *ctx)

+static void dpu_hw_intf_program_datapath(struct dpu_hw_intf *ctx,
+struct intf_dpu_datapath_cfg 
*datapath_cfg)
  {
u32 intf_cfg2 = DPU_REG_READ(&ctx->hw, INTF_CONFIG2);
  
-	intf_cfg2 |= INTF_CFG2_DCE_DATA_COMPRESS;

+   if (datapath_cfg->data_compress)
+   intf_cfg2 |= INTF_CFG2_DCE_DATA_COMPRESS;
  
  	DPU_REG_WRITE(&ctx->hw, INTF_CONFIG2, intf_cfg2);

  }
@@ -543,8 +545,7 @@ static void _setup_intf_ops(struct dpu_hw_intf_ops *ops,
ops->disable_autorefresh = dpu_hw_intf_disable_autorefresh;
}
  
-	if (cap & BIT(DPU_INTF_DATA_COMPRESS))

-   ops->enable_compression = dpu_hw_intf_enable_compression;
+   ops->program_datapath = dpu_hw_intf_program_datapath;


The `core_major_version >= 7' should either be here or in the callback 
itself.



  }
  
  struct dpu_hw_intf *dpu_hw_intf_init(const struct dpu_intf_cfg *cfg,

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
index 99e21c4137f9..f736dca38463 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
@@ -48,6 +48,11 @@ struct intf_status {
u32 line_count; /* current line count including blanking */
  };
  
+struct intf_dpu_datapath_cfg {

+   u8 data_compress;   /* enable data compress between dpu and dsi */
+   /* can be expanded for other programmable bits */
+};


I'd say, dpu_datapath is too generic. What about  intf_cmd_mode_cfg?


+
  /**
   * struct dpu_hw_intf_ops : Interface to the interface Hw driver functions
   *  Assumption is these functions will be called after clocks are enabled
@@ -70,7 +75,7 @@ struct intf_status {
   * @get_autorefresh:Retrieve autorefresh config from hardware
   *  Return: 0 on success, -ETIMEDOUT on timeout
   * @vsync_sel:  Select vsync signal for tear-effect 
configuration
- * @enable_compression: Enable data compression
+ * @program_datapath:   Program the DPU to interface datapath for 
relevant chipsets
   */
  struct dpu_hw_

Re: [PATCH v3 1/3] drm/msm/dpu: re-introduce dpu core revision to the catalog

[Dmitry Baryshkov]

On 29/06/2023 22:29, Abhinav Kumar wrote:

With [1] dpu core revision was dropped in favor of using the
compatible string from the device tree to select the dpu catalog
being used in the device.

This approach works well however also necessitates adding catalog
entries for small register level details as dpu capabilities and/or
features bloating the catalog unnecessarily. Examples include but
are not limited to data_compress, interrupt register set, widebus etc.

Introduce the dpu core revision back as an entry to the catalog so that
we can just use dpu revision checks and enable those bits which
should be enabled unconditionally and not controlled by a catalog
and also simplify the changes to do something like:

if (dpu_core_revision > x && dpu_core_revision < x)
enable the bit;

Since dpu's major and minor versions are now separate fields, lets
drop all the DPU_HW_VER macros.

[1]: https://patchwork.freedesktop.org/patch/530891/?series=113910&rev=4

changes in v3:
- drop DPU step version as features are not changing across steps
- add core_major_version / core_minor_version to avoid conflicts
- update the commit text to drop references to the dpu macros

Signed-off-by: Abhinav Kumar 
---
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h  | 2 ++
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h   | 2 ++
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h   | 2 ++
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h  | 2 ++
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h   | 2 ++
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h   | 2 ++
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_3_sm6115.h   | 2 ++
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h   | 2 ++
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h  | 2 ++
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h   | 2 ++
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h   | 2 ++
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h   | 2 ++
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 2 ++
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h   | 2 ++
  drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h   | 2 ++
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h   | 8 ++--
  16 files changed, 36 insertions(+), 2 deletions(-)


Reviewed-by: Dmitry Baryshkov 

Nit: if there is a need for v-next, I'd probably suggest dropping th hex 
prefix from these values.




diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
index 7d0d0e74c3b0..a5d486783c3f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
@@ -190,6 +190,8 @@ static const struct dpu_perf_cfg msm8998_perf_data = {
  };
  
  const struct dpu_mdss_cfg dpu_msm8998_cfg = {

+   .core_major_version = 0x3,
+   .core_minor_version = 0x0,
.caps = &msm8998_dpu_caps,
.ubwc = &msm8998_ubwc_cfg,
.mdp_count = ARRAY_SIZE(msm8998_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
index b6098141bb9b..1fdb89a4b7a6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
@@ -194,6 +194,8 @@ static const struct dpu_perf_cfg sdm845_perf_data = {
  };
  
  const struct dpu_mdss_cfg dpu_sdm845_cfg = {

+   .core_major_version = 0x4,
+   .core_minor_version = 0x0,
.caps = &sdm845_dpu_caps,
.ubwc = &sdm845_ubwc_cfg,
.mdp_count = ARRAY_SIZE(sdm845_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
index b5f751354267..129c62cf450d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
@@ -208,6 +208,8 @@ static const struct dpu_perf_cfg sm8150_perf_data = {
  };
  
  const struct dpu_mdss_cfg dpu_sm8150_cfg = {

+   .core_major_version = 0x5,
+   .core_minor_version = 0x0,
.caps = &sm8150_dpu_caps,
.ubwc = &sm8150_ubwc_cfg,
.mdp_count = ARRAY_SIZE(sm8150_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
index 8ed2b263c5ea..ca037b070f44 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
@@ -214,6 +214,8 @@ static const struct dpu_perf_cfg sc8180x_perf_data = {
  };
  
  const struct dpu_mdss_cfg dpu_sc8180x_cfg = {

+   .core_major_version = 0x5,
+   .core_minor_version = 0x1,
.caps = &sc8180x_dpu_caps,
.ubwc = &sc8180x_ubwc_cfg,
.mdp_count = ARRAY_SIZE(sc8180x_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h 
b/drivers

Re: [PATCH 6/6] drm/msm/dpu: Update dev core dump to dump registers of sub blocks

[Dmitry Baryshkov]

On 30/06/2023 02:29, Abhinav Kumar wrote:



On 6/24/2023 7:44 PM, Abhinav Kumar wrote:



On 6/24/2023 8:03 AM, Dmitry Baryshkov wrote:

On 24/06/2023 17:17, Abhinav Kumar wrote:



On 6/24/2023 5:07 AM, Dmitry Baryshkov wrote:

On 24/06/2023 03:09, Abhinav Kumar wrote:



On 6/22/2023 5:13 PM, Dmitry Baryshkov wrote:

On 23/06/2023 02:48, Ryan McCann wrote:
Currently, the device core dump mechanism does not dump 
registers of sub

blocks within the DSPP, SSPP, DSC, and PINGPONG blocks. Add wrapper
function to dump hardware blocks that contain sub blocks.

Signed-off-by: Ryan McCann 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 194 
+++-

  1 file changed, 168 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c

index aa8499de1b9f..9b1b1c382269 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -885,6 +885,154 @@ static int dpu_irq_postinstall(struct 
msm_kms *kms)

  return 0;
  }
+static void dpu_kms_mdp_snapshot_add_block(struct 
msm_disp_state *disp_state,

+   void __iomem *mmio, void *blk,
+   enum dpu_hw_blk_type blk_type)


No. Such multiplexers add no value to the code. Please inline it.

Not to mention that this patch is hard to review. You both move 
existing code and add new features. If it were to go, it should 
have been split into two patches: one introducing the multiplexer 
and another one adding subblocks.




Ok. we can split this into:

1) adding the multiplexer
2) adding sub-blk parsing support inside the multiplexer


I'd say, drop the multiplexer completely. It adds no value here. It 
is only used from dpu_kms_mdp_snapshot(). If the code there was 
complex enough, it would have made sense to _split_ the function. 
But even in such case there would be no point in having 
multiplexer. We do not enumerate block by type.




Can you pls elaborate what you mean by enumerate blk by type?

We do have DPU_HW_BLK_***

Did you mean sub-blk?




+{
+    u32 base;
+
+    switch (blk_type) {
+    case DPU_HW_BLK_TOP:
+    {
+    struct dpu_mdp_cfg *top = (struct dpu_mdp_cfg *)blk;
+
+    if (top->features & BIT(DPU_MDP_PERIPH_0_REMOVED)) {
+    msm_disp_snapshot_add_block(disp_state, 
MDP_PERIPH_TOP0,

+    mmio + top->base, "top");
+    msm_disp_snapshot_add_block(disp_state, top->len - 
MDP_PERIPH_TOP0_END,
+    mmio + top->base + 
MDP_PERIPH_TOP0_END,

+    "top_2");
+    } else {
+    msm_disp_snapshot_add_block(disp_state, top->len, 
mmio + top->base, "top");

+    }
+    break;
+    }
+    case DPU_HW_BLK_LM:
+    {
+    struct dpu_lm_cfg *mixer = (struct dpu_lm_cfg *)blk;
+
+    msm_disp_snapshot_add_block(disp_state, mixer->len, 
mmio + mixer->base, "%s",

+    mixer->name);
+    break;
+    }
+    case DPU_HW_BLK_CTL:
+    {
+    struct dpu_ctl_cfg *ctl = (struct dpu_ctl_cfg *)blk;
+
+    msm_disp_snapshot_add_block(disp_state, ctl->len, mmio 
+ ctl->base, "%s",

+    ctl->name);
+    break;
+    }
+    case DPU_HW_BLK_INTF:
+    {
+    struct dpu_intf_cfg *intf = (struct dpu_intf_cfg *)blk;
+
+    msm_disp_snapshot_add_block(disp_state, intf->len, mmio 
+ intf->base, "%s",

+    intf->name);
+    break;
+    }
+    case DPU_HW_BLK_WB:
+    {
+    struct dpu_wb_cfg *wb = (struct dpu_wb_cfg *)blk;
+
+    msm_disp_snapshot_add_block(disp_state, wb->len, mmio + 
wb->base, "%s",

+    wb->name);
+    break;
+    }
+    case DPU_HW_BLK_SSPP:
+    {
+    struct dpu_sspp_cfg *sspp_block = (struct dpu_sspp_cfg 
*)blk;

+    const struct dpu_sspp_sub_blks *sblk = sspp_block->sblk;
+
+    base = sspp_block->base;
+
+    msm_disp_snapshot_add_block(disp_state, 
sspp_block->len, mmio + base, "%s",

+    sspp_block->name);
+
+    if (sspp_block->features & BIT(DPU_SSPP_SCALER_QSEED3) ||
+    sspp_block->features & 
BIT(DPU_SSPP_SCALER_QSEED3LITE) ||

+    sspp_block->features & BIT(DPU_SSPP_SCALER_QSEED4))
+    msm_disp_snapshot_add_block(disp_state, 
sblk->scaler_blk.len,
+    mmio + base + 
sblk->scaler_blk.base, "%s_%s",
+    sspp_block->name, 
sblk->scaler_blk.name);


Actually, it would be better to:
- drop name from all sblk instances (and use known string instead 
of the sblk name here)

- Use sblk->foo_blk.len to check if it should be printed or not.



No, I dont agree. If we drop the names from the sub_blk in the 
catalog, we will end up using "sub_blk_name" string here in the 
code to indicate which blk that is in the dump.


If we add more sub_blks in the catalog in the future we need to 
keep changing the code over here. Thats not how it 

Re: [PATCH v2 13/15] arm64: dts: qcom: sm6125: Add dispcc node

[Dmitry Baryshkov]

On 29/06/2023 22:53, Konrad Dybcio wrote:

On 29.06.2023 14:24, Dmitry Baryshkov wrote:

On Thu, 29 Jun 2023 at 15:14, Marijn Suijten
 wrote:


On 2023-06-29 13:56:25, Dmitry Baryshkov wrote:

On 27/06/2023 23:14, Marijn Suijten wrote:

Enable and configure the dispcc node on SM6125 for consumption by MDSS
later on.

Signed-off-by: Marijn Suijten 
---
   arch/arm64/boot/dts/qcom/sm6125.dtsi | 25 +
   1 file changed, 25 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm6125.dtsi 
b/arch/arm64/boot/dts/qcom/sm6125.dtsi
index edb03508dba3..a5cc0d43d2d9 100644
--- a/arch/arm64/boot/dts/qcom/sm6125.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6125.dtsi
@@ -3,6 +3,7 @@
* Copyright (c) 2021, Martin Botka 
*/

+#include 
   #include 
   #include 
   #include 
@@ -1203,6 +1204,30 @@ sram@469 {
 reg = <0x0469 0x1>;
 };

+   dispcc: clock-controller@5f0 {
+   compatible = "qcom,sm6125-dispcc";
+   reg = <0x05f0 0x2>;
+   clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
+<0>,
+<0>,
+<0>,
+<0>,
+<0>,
+<&gcc GCC_DISP_AHB_CLK>,
+<&gcc GCC_DISP_GPLL0_DIV_CLK_SRC>;
+   clock-names = "bi_tcxo",
+ "dsi0_phy_pll_out_byteclk",
+ "dsi0_phy_pll_out_dsiclk",
+ "dsi1_phy_pll_out_dsiclk",
+ "dp_phy_pll_link_clk",
+ "dp_phy_pll_vco_div_clk",
+ "cfg_ahb_clk",
+ "gcc_disp_gpll0_div_clk_src";
+   power-domains = <&rpmpd SM6125_VDDCX>;


Would it be logical to specify the required-opps too?


Perhaps, but barely any other SoC aside from sm8x50 sets it on dispcc.
What should it be, rpmhpd_opp_low_svs?  IIRC we used "svs" for the DSI
PHY despite not having a reference value downstream (it sets a range of
NOM-TURBO_NO_CPR, and RETENTION when it's off).


Then for DSI PHY the required-opps should be rpmpd_opp_nom.

Yes



For the dispcc I think the rpmpd_opp_ret, the lowest possible vote,
should be enough.

I'm not 100% sure but not specifying an opp and turning on the domain
***probably*** just sticks with the lowest vote


I think so too. But I think it might be better to be explicit rather 
than being implicit here. Both of us are describing Linux behaviour 
(=set lowest possible value), while DT should describe the hardware.




Konrad




- Marijn




+   #clock-cells = <1>;
+   #power-domain-cells = <1>;
+   };
+
 apps_smmu: iommu@c60 {
 compatible = "qcom,sm6125-smmu-500", "qcom,smmu-500", 
"arm,mmu-500";
 reg = <0x0c60 0x8>;



--
With best wishes
Dmitry







--
With best wishes
Dmitry

Re: [PATCH 6/6] drm/msm/dpu: Update dev core dump to dump registers of sub blocks

[Abhinav Kumar]

On 6/24/2023 7:44 PM, Abhinav Kumar wrote:



On 6/24/2023 8:03 AM, Dmitry Baryshkov wrote:

On 24/06/2023 17:17, Abhinav Kumar wrote:



On 6/24/2023 5:07 AM, Dmitry Baryshkov wrote:

On 24/06/2023 03:09, Abhinav Kumar wrote:



On 6/22/2023 5:13 PM, Dmitry Baryshkov wrote:

On 23/06/2023 02:48, Ryan McCann wrote:
Currently, the device core dump mechanism does not dump registers 
of sub

blocks within the DSPP, SSPP, DSC, and PINGPONG blocks. Add wrapper
function to dump hardware blocks that contain sub blocks.

Signed-off-by: Ryan McCann 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 194 
+++-

  1 file changed, 168 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c

index aa8499de1b9f..9b1b1c382269 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -885,6 +885,154 @@ static int dpu_irq_postinstall(struct 
msm_kms *kms)

  return 0;
  }
+static void dpu_kms_mdp_snapshot_add_block(struct msm_disp_state 
*disp_state,

+   void __iomem *mmio, void *blk,
+   enum dpu_hw_blk_type blk_type)


No. Such multiplexers add no value to the code. Please inline it.

Not to mention that this patch is hard to review. You both move 
existing code and add new features. If it were to go, it should 
have been split into two patches: one introducing the multiplexer 
and another one adding subblocks.




Ok. we can split this into:

1) adding the multiplexer
2) adding sub-blk parsing support inside the multiplexer


I'd say, drop the multiplexer completely. It adds no value here. It 
is only used from dpu_kms_mdp_snapshot(). If the code there was 
complex enough, it would have made sense to _split_ the function. 
But even in such case there would be no point in having multiplexer. 
We do not enumerate block by type.




Can you pls elaborate what you mean by enumerate blk by type?

We do have DPU_HW_BLK_***

Did you mean sub-blk?




+{
+    u32 base;
+
+    switch (blk_type) {
+    case DPU_HW_BLK_TOP:
+    {
+    struct dpu_mdp_cfg *top = (struct dpu_mdp_cfg *)blk;
+
+    if (top->features & BIT(DPU_MDP_PERIPH_0_REMOVED)) {
+    msm_disp_snapshot_add_block(disp_state, 
MDP_PERIPH_TOP0,

+    mmio + top->base, "top");
+    msm_disp_snapshot_add_block(disp_state, top->len - 
MDP_PERIPH_TOP0_END,

+    mmio + top->base + MDP_PERIPH_TOP0_END,
+    "top_2");
+    } else {
+    msm_disp_snapshot_add_block(disp_state, top->len, 
mmio + top->base, "top");

+    }
+    break;
+    }
+    case DPU_HW_BLK_LM:
+    {
+    struct dpu_lm_cfg *mixer = (struct dpu_lm_cfg *)blk;
+
+    msm_disp_snapshot_add_block(disp_state, mixer->len, mmio 
+ mixer->base, "%s",

+    mixer->name);
+    break;
+    }
+    case DPU_HW_BLK_CTL:
+    {
+    struct dpu_ctl_cfg *ctl = (struct dpu_ctl_cfg *)blk;
+
+    msm_disp_snapshot_add_block(disp_state, ctl->len, mmio + 
ctl->base, "%s",

+    ctl->name);
+    break;
+    }
+    case DPU_HW_BLK_INTF:
+    {
+    struct dpu_intf_cfg *intf = (struct dpu_intf_cfg *)blk;
+
+    msm_disp_snapshot_add_block(disp_state, intf->len, mmio 
+ intf->base, "%s",

+    intf->name);
+    break;
+    }
+    case DPU_HW_BLK_WB:
+    {
+    struct dpu_wb_cfg *wb = (struct dpu_wb_cfg *)blk;
+
+    msm_disp_snapshot_add_block(disp_state, wb->len, mmio + 
wb->base, "%s",

+    wb->name);
+    break;
+    }
+    case DPU_HW_BLK_SSPP:
+    {
+    struct dpu_sspp_cfg *sspp_block = (struct dpu_sspp_cfg 
*)blk;

+    const struct dpu_sspp_sub_blks *sblk = sspp_block->sblk;
+
+    base = sspp_block->base;
+
+    msm_disp_snapshot_add_block(disp_state, sspp_block->len, 
mmio + base, "%s",

+    sspp_block->name);
+
+    if (sspp_block->features & BIT(DPU_SSPP_SCALER_QSEED3) ||
+    sspp_block->features & 
BIT(DPU_SSPP_SCALER_QSEED3LITE) ||

+    sspp_block->features & BIT(DPU_SSPP_SCALER_QSEED4))
+    msm_disp_snapshot_add_block(disp_state, 
sblk->scaler_blk.len,
+    mmio + base + sblk->scaler_blk.base, 
"%s_%s",
+    sspp_block->name, 
sblk->scaler_blk.name);


Actually, it would be better to:
- drop name from all sblk instances (and use known string instead 
of the sblk name here)

- Use sblk->foo_blk.len to check if it should be printed or not.



No, I dont agree. If we drop the names from the sub_blk in the 
catalog, we will end up using "sub_blk_name" string here in the 
code to indicate which blk that is in the dump.


If we add more sub_blks in the catalog in the future we need to 
keep changing the code over here. Thats not how it should be.


Leaving the names in the catal

Re: [PATCH v2 2/4] regulator: Introduce Qualcomm REFGEN regulator driver

[kernel test robot]

Hi Konrad,

kernel test robot noticed the following build errors:

[auto build test ERROR on 5c875096d59010cee4e00da1f9c7bdb07a025dc2]

url:
https://github.com/intel-lab-lkp/linux/commits/Konrad-Dybcio/dt-bindings-regulator-Describe-Qualcomm-REFGEN-regulator/20230630-043835
base:   5c875096d59010cee4e00da1f9c7bdb07a025dc2
patch link:
https://lore.kernel.org/r/20230628-topic-refgen-v2-2-6136487c78c5%40linaro.org
patch subject: [PATCH v2 2/4] regulator: Introduce Qualcomm REFGEN regulator 
driver
config: s390-allmodconfig 
(https://download.01.org/0day-ci/archive/20230630/202306300643.lhn1fbot-...@intel.com/config)
compiler: s390-linux-gcc (GCC) 12.3.0
reproduce: 
(https://download.01.org/0day-ci/archive/20230630/202306300643.lhn1fbot-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202306300643.lhn1fbot-...@intel.com/

All errors (new ones prefixed by >>, old ones prefixed by <<):

WARNING: modpost: missing MODULE_DESCRIPTION() in net/netfilter/ipvs/ip_vs_sed.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/netfilter/ipvs/ip_vs_nq.o
WARNING: modpost: missing MODULE_DESCRIPTION() in 
net/netfilter/ipvs/ip_vs_twos.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/netfilter/ipvs/ip_vs_ftp.o
WARNING: modpost: missing MODULE_DESCRIPTION() in 
net/netfilter/ipvs/ip_vs_pe_sip.o
WARNING: modpost: missing MODULE_DESCRIPTION() in 
net/ipv4/netfilter/nf_defrag_ipv4.o
WARNING: modpost: missing MODULE_DESCRIPTION() in 
net/ipv4/netfilter/nf_reject_ipv4.o
WARNING: modpost: missing MODULE_DESCRIPTION() in 
net/ipv4/netfilter/iptable_nat.o
WARNING: modpost: missing MODULE_DESCRIPTION() in 
net/ipv4/netfilter/iptable_raw.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/ipv4/ip_tunnel.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/ipv4/ipip.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/ipv4/ip_gre.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/ipv4/udp_tunnel.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/ipv4/ip_vti.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/ipv4/ah4.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/ipv4/esp4.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/ipv4/xfrm4_tunnel.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/ipv4/tunnel4.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/ipv4/inet_diag.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/ipv4/tcp_diag.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/ipv4/udp_diag.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/ipv4/raw_diag.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/xfrm/xfrm_algo.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/xfrm/xfrm_user.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/unix/unix_diag.o
WARNING: modpost: missing MODULE_DESCRIPTION() in 
net/ipv6/netfilter/ip6table_raw.o
WARNING: modpost: missing MODULE_DESCRIPTION() in 
net/ipv6/netfilter/ip6table_nat.o
WARNING: modpost: missing MODULE_DESCRIPTION() in 
net/ipv6/netfilter/nf_defrag_ipv6.o
WARNING: modpost: missing MODULE_DESCRIPTION() in 
net/ipv6/netfilter/nf_reject_ipv6.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/ipv6/ah6.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/ipv6/esp6.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/ipv6/xfrm6_tunnel.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/ipv6/tunnel6.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/ipv6/mip6.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/ipv6/sit.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/ipv6/ip6_udp_tunnel.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/dsa/tag_ar9331.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/dsa/tag_brcm.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/dsa/tag_dsa.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/dsa/tag_gswip.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/dsa/tag_hellcreek.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/dsa/tag_ksz.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/dsa/tag_lan9303.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/dsa/tag_mtk.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/dsa/tag_none.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/dsa/tag_ocelot.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/dsa/tag_ocelot_8021q.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/dsa/tag_qca.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/dsa/tag_rtl4_a.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/dsa/tag_rtl8_4.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/dsa/tag_rzn1_a5psw.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/dsa/tag_sja1105.o
WARNING: modpost: missing MODULE_DESCRIPTION() in net/dsa/tag_trailer.o
WARNING: mo

[PATCH 1/2] fbdev: Split frame buffer support in FB and FB_CORE symbols

[Javier Martinez Canillas]

Currently the CONFIG_FB option has to be enabled even if no legacy fbdev
drivers are needed (e.g: only to have support for framebuffer consoles).

The DRM subsystem has a fbdev emulation layer, but depends on CONFIG_FB
and so it can only be enabled if that dependency is enabled as well.

That means fbdev drivers have to be explicitly disabled if users want to
enable CONFIG_FB, only to use fbcon and/or the DRM fbdev emulation layer.

This patch introduces a CONFIG_FB_CORE option that could be enabled just
to have the core support needed for CONFIG_DRM_FBDEV_EMULATION, allowing
CONFIG_FB to be disabled (and automatically disabling all fbdev drivers).

Signed-off-by: Javier Martinez Canillas 
---

 arch/x86/Makefile |  2 +-
 arch/x86/video/Makefile   |  2 +-
 drivers/video/console/Kconfig |  2 +-
 drivers/video/fbdev/Kconfig   | 62 ++-
 drivers/video/fbdev/core/Makefile | 14 +++
 5 files changed, 47 insertions(+), 35 deletions(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index b39975977c03..89a02e69be5f 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -259,7 +259,7 @@ drivers-$(CONFIG_PCI)+= arch/x86/pci/
 # suspend and hibernation support
 drivers-$(CONFIG_PM) += arch/x86/power/
 
-drivers-$(CONFIG_FB) += arch/x86/video/
+drivers-$(CONFIG_FB_CORE) += arch/x86/video/
 
 
 # boot loader support. Several targets are kept for legacy purposes
diff --git a/arch/x86/video/Makefile b/arch/x86/video/Makefile
index 11640c116115..5ebe48752ffc 100644
--- a/arch/x86/video/Makefile
+++ b/arch/x86/video/Makefile
@@ -1,2 +1,2 @@
 # SPDX-License-Identifier: GPL-2.0-only
-obj-$(CONFIG_FB)   += fbdev.o
+obj-$(CONFIG_FB_CORE)  += fbdev.o
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index a2a88d42edf0..1b5a319971ed 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -72,7 +72,7 @@ config DUMMY_CONSOLE_ROWS
 
 config FRAMEBUFFER_CONSOLE
bool "Framebuffer Console support"
-   depends on FB && !UML
+   depends on FB_CORE && !UML
select VT_HW_CONSOLE_BINDING
select CRC32
select FONT_SUPPORT
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index cecf15418632..74d7a305657a 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -6,10 +6,8 @@
 config FB_NOTIFY
bool
 
-menuconfig FB
-   tristate "Support for frame buffer devices"
-   select FB_NOTIFY
-   select VIDEO_CMDLINE
+menuconfig FB_CORE
+   tristate "Core support for frame buffer devices"
help
  The frame buffer device provides an abstraction for the graphics
  hardware. It represents the frame buffer of some video hardware and
@@ -33,6 +31,20 @@ menuconfig FB
   for 
more
  information.
 
+ This options enables the core support for frame buffer devices.
+
+menuconfig FB
+   tristate "Support for frame buffer device drivers"
+   depends on FB_CORE
+   select FB_NOTIFY
+   select VIDEO_CMDLINE
+   help
+ This enables support for native frame buffer device (fbdev) drivers.
+
+ The DRM subsystem provides support for emulated frame buffer devices
+ on top of KMS drivers, but this option allows legacy fbdev drivers to
+ be enabled as well.
+
  Say Y here and to the driver for your graphics board below if you
  are compiling a kernel for a non-x86 architecture.
 
@@ -44,7 +56,7 @@ menuconfig FB
 
 config FIRMWARE_EDID
bool "Enable firmware EDID"
-   depends on FB
+   depends on FB_CORE
help
  This enables access to the EDID transferred from the firmware.
  On the i386, this is from the Video BIOS. Enable this if DDC/I2C
@@ -59,7 +71,7 @@ config FIRMWARE_EDID
 
 config FB_DEVICE
bool "Provide legacy /dev/fb* device"
-   depends on FB
+   depends on FB_CORE
default y
help
  Say Y here if you want the legacy /dev/fb* device file and
@@ -69,13 +81,13 @@ config FB_DEVICE
 
 config FB_DDC
tristate
-   depends on FB
+   depends on FB_CORE
select I2C_ALGOBIT
select I2C
 
 config FB_CFB_FILLRECT
tristate
-   depends on FB
+   depends on FB_CORE
help
  Include the cfb_fillrect function for generic software rectangle
  filling. This is used by drivers that don't provide their own
@@ -83,7 +95,7 @@ config FB_CFB_FILLRECT
 
 config FB_CFB_COPYAREA
tristate
-   depends on FB
+   depends on FB_CORE
help
  Include the cfb_copyarea function for generic software area copying.
  This is used by drivers that don't provide their own (accelerated)
@@ -91,7 +103,7 @@ config FB_CFB_COPYAREA
 
 config FB_CFB_IMAGEBLIT
tristate
-   depends on FB
+

[PATCH 2/2] drm: Make fbdev emulation depend on FB_CORE instead of FB

[Javier Martinez Canillas]

Now that the fbdev core has been split in FB_CORE and FB, make DRM fbdev
emulation layer to just depend on the former.

This allows to disable the CONFIG_FB option if is not needed, which will
avoid the need to explicitly disable each of the legacy fbdev drivers.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/gpu/drm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index afb3b2f5f425..6ecb984d213a 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -132,7 +132,7 @@ config DRM_DEBUG_MODESET_LOCK
 config DRM_FBDEV_EMULATION
bool "Enable legacy fbdev support for your modesetting driver"
depends on DRM_KMS_HELPER
-   depends on FB=y || FB=DRM_KMS_HELPER
+   depends on FB_CORE=y || FB=DRM_KMS_HELPER
select FRAMEBUFFER_CONSOLE if !EXPERT
select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
default y
-- 
2.41.0

[PATCH 0/2] Allow disabling all native fbdev drivers and only keeping DRM emulation

[Javier Martinez Canillas]

This patch series splits the fbdev core support in two different Kconfig
symbols: FB and FB_CORE. The motivation for this is to allow CONFIG_FB to
be disabled, while still having the the core fbdev support needed for the
CONFIG_DRM_FBDEV_EMULATION to be enabled. The motivation is automatically
disabling all fbdev drivers instead of having to be disabled individually.

The reason for doing this is that now with simpledrm, there's no need for
the legacy fbdev (e.g: efifb or vesafb) drivers anymore and many distros
now disable them. But it would simplify the config a lot fo have a single
Kconfig symbol to disable all fbdev drivers.

I've build tested with possible combinations of CONFIG_FB, CONFIG_FB_CORE,
CONFIG_DRM_FBDEV_EMULATION and CONFIG_FB_DEVICE symbols set to 'y' or 'n'.

Patch 1/2 makes the CONFIG_FB split that is mentioned above and patch 2/2
makes DRM fbdev emulation depend on the new FB_CORE symbol instead of FB.


Javier Martinez Canillas (2):
  fbdev: Split frame buffer support in FB and FB_CORE symbols
  drm: Make fbdev emulation depend on FB_CORE instead of FB

 arch/x86/Makefile |  2 +-
 arch/x86/video/Makefile   |  2 +-
 drivers/gpu/drm/Kconfig   |  2 +-
 drivers/video/console/Kconfig |  2 +-
 drivers/video/fbdev/Kconfig   | 62 ++-
 drivers/video/fbdev/core/Makefile | 14 +++
 6 files changed, 48 insertions(+), 36 deletions(-)

-- 
2.41.0

Re: [Intel-gfx] [PATCH] drm/i915/pxp: Optimize GET_PARAM:PXP_STATUS

[Teres Alexis, Alan Previn]

On Tue, 2023-06-20 at 09:30 -0500, Balasubrawmanian, Vivaik wrote:
> On 6/1/2023 12:45 PM, Alan Previn wrote:
> > After recent discussions with Mesa folks, it was requested
> > that we optimize i915's GET_PARAM for the PXP_STATUS without
> > changing the UAPI spec.
> > 
> > This patch adds this additional optimizations:
> > - If any PXP initializatoin flow failed, then ensure that
> >   we catch it so that we can change the returned PXP_STATUS
> >   from "2" (i.e. 'PXP is supported but not yet ready')
> >   to "-ENODEV". This typically should not happen and if it
> >   does, we have a platform configuration.
> > - If a PXP arbitration session creation event failed
> >   due to incorrect firmware version or blocking SOC fusing
> >   or blocking BIOS configuration (platform reasons that won't
> >   change if we retry), then reflect that blockage by also
> >   returning -ENODEV in the GET_PARAM-PXP_STATUS.
> > - GET_PARAM:PXP_STATUS should not wait at all if PXP is
> >   supported but non-i915 dependencies (component-driver /
> >   firmware) we are still pending to complete the init flows.
> >   In this case, just return "2" immediately (i.e. 'PXP is
> >   supported but not yet ready').
> > 
> > Signed-off-by: Alan Previn 
> > ---
> >   drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c  | 11 +-
> >   drivers/gpu/drm/i915/i915_getparam.c   |  2 +-
> >   drivers/gpu/drm/i915/pxp/intel_pxp.c   | 25 ++
> >   drivers/gpu/drm/i915/pxp/intel_pxp.h   |  2 +-
> >   drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c |  7 +++---
> >   drivers/gpu/drm/i915/pxp/intel_pxp_tee.c   |  7 +++---
> >   drivers/gpu/drm/i915/pxp/intel_pxp_types.h |  9 
> >   7 files changed, 50 insertions(+), 13 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c 
> > b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
> > index fb0984f875f9..4dd744c96a37 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
> > @@ -42,8 +42,17 @@ static void gsc_work(struct work_struct *work)
> > }
> >   
> > ret = intel_gsc_proxy_request_handler(gsc);
> > -   if (ret)
> > +   if (ret) {
> > +   if (actions & GSC_ACTION_FW_LOAD) {
> > +   /*
> > +* a proxy request failure that came together 
> > with the
> > +* firmware load action means the last part of 
> > init has
> > +* failed so GSC fw won't be usable after this
> > +*/
> > +   intel_uc_fw_change_status(&gsc->fw, 
> > INTEL_UC_FIRMWARE_LOAD_FAIL);
> > +   }
> > goto out_put;
> > +   }
> >   
> > /* mark the GSC FW init as done the first time we run this */
> > if (actions & GSC_ACTION_FW_LOAD) {
> 
> On the huc authentication comment block above this snippet, the last 
> statement: "Note that we can only do the GSC auth if the GuC auth was" 
> is confusing as the code below is only dealing with HuC Authentication.
alan: i believe what he meant was "can only do the GSC-based auth if
the GuC-based auth"... but I can't change that code as part
of this patch - I believe the rules for kernel patch is to ensure each
single patch is modular (not mixing unrelated changes) and focuses just
on what its described to do. IIRC, we would need to create a separate
patch review for that change.

> 
> This function seems to have a section to deal with FW load action and 
> another to deal with SW Proxy requests, but we seem to be mixing both 
> actions in the SW proxy section. instead, can we move this call to 
> intel_gsc_proxy_request_handler to the FW load section itself instead of 
> handling it as an additional check in the SW_proxy section? In the same 
> vein, we should also move the intel_uc_fw_change_status() call into the 
> above FW Load action section. i think that way the code reads better.
alan: GSC_ACTION_FW_LOAD is used for loading the GSC firmware which is a
one-time thing per i915 load. However, GSC_ACTION_SW_PROXY events can happen
any time the GSC fw needs to communicate with CSE firmware (or vice versa)
due to platform events that may have not been triggered by i915 long after
init. However, the rule is after GSC FW is loaded, i915 is required
to do a 1-time proxy-init step to prime both GSC and CSE fws that proxy
comms is avail. without this step, we can't use the gsc-fw for other ops.

So to recap the rules:
1. we launch the worker to do the one-time the GSC firmware load.
2. after the GSC firmware load is successful, we have to do a one-time SW-proxy 
init.
-> this is why we add the GSC_ACTION_SW_PROXY flag successful load 
completion.
3. If we are doing proxy-handling for the very first time, we ensure
   -> FW status is only set to RUNNING if proxy int

[PATCH drm-next v6 13/13] drm/nouveau: debugfs: implement DRM GPU VA debugfs

[Danilo Krummrich]

Provide the driver indirection iterating over all DRM GPU VA spaces to
enable the common 'gpuvas' debugfs file for dumping DRM GPU VA spaces.

Signed-off-by: Danilo Krummrich 
---
 drivers/gpu/drm/nouveau/nouveau_debugfs.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c 
b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index 99d022a91afc..053f703f2f68 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -203,6 +203,44 @@ nouveau_debugfs_pstate_open(struct inode *inode, struct 
file *file)
return single_open(file, nouveau_debugfs_pstate_get, inode->i_private);
 }
 
+static void
+nouveau_debugfs_gpuva_regions(struct seq_file *m, struct nouveau_uvmm *uvmm)
+{
+   MA_STATE(mas, &uvmm->region_mt, 0, 0);
+   struct nouveau_uvma_region *reg;
+
+   seq_puts  (m, " VA regions  | start  | range  | 
end\n");
+   seq_puts  (m, 
"\n");
+   mas_for_each(&mas, reg, ULONG_MAX)
+   seq_printf(m, " | 0x%016llx | 0x%016llx | 
0x%016llx\n",
+  reg->va.addr, reg->va.range, reg->va.addr + 
reg->va.range);
+}
+
+static int
+nouveau_debugfs_gpuva(struct seq_file *m, void *data)
+{
+   struct drm_info_node *node = (struct drm_info_node *) m->private;
+   struct nouveau_drm *drm = nouveau_drm(node->minor->dev);
+   struct nouveau_cli *cli;
+
+   mutex_lock(&drm->clients_lock);
+   list_for_each_entry(cli, &drm->clients, head) {
+   struct nouveau_uvmm *uvmm = nouveau_cli_uvmm(cli);
+
+   if (!uvmm)
+   continue;
+
+   nouveau_uvmm_lock(uvmm);
+   drm_debugfs_gpuva_info(m, &uvmm->umgr);
+   seq_puts(m, "\n");
+   nouveau_debugfs_gpuva_regions(m, uvmm);
+   nouveau_uvmm_unlock(uvmm);
+   }
+   mutex_unlock(&drm->clients_lock);
+
+   return 0;
+}
+
 static const struct file_operations nouveau_pstate_fops = {
.owner = THIS_MODULE,
.open = nouveau_debugfs_pstate_open,
@@ -214,6 +252,7 @@ static const struct file_operations nouveau_pstate_fops = {
 static struct drm_info_list nouveau_debugfs_list[] = {
{ "vbios.rom",  nouveau_debugfs_vbios_image, 0, NULL },
{ "strap_peek", nouveau_debugfs_strap_peek, 0, NULL },
+   DRM_DEBUGFS_GPUVA_INFO(nouveau_debugfs_gpuva, NULL),
 };
 #define NOUVEAU_DEBUGFS_ENTRIES ARRAY_SIZE(nouveau_debugfs_list)
 
-- 
2.41.0

[PATCH drm-next v6 11/13] drm/nouveau: nvkm/vmm: implement raw ops to manage uvmm

[Danilo Krummrich]

The new VM_BIND UAPI uses the DRM GPU VA manager to manage the VA space.
Hence, we a need a way to manipulate the MMUs page tables without going
through the internal range allocator implemented by nvkm/vmm.

This patch adds a raw interface for nvkm/vmm to pass the resposibility
for managing the address space and the corresponding map/unmap/sparse
operations to the upper layers.

Signed-off-by: Danilo Krummrich 
---
 drivers/gpu/drm/nouveau/include/nvif/if000c.h |  26 ++-
 drivers/gpu/drm/nouveau/include/nvif/vmm.h|  19 +-
 .../gpu/drm/nouveau/include/nvkm/subdev/mmu.h |  20 +-
 drivers/gpu/drm/nouveau/nouveau_svm.c |   2 +-
 drivers/gpu/drm/nouveau/nouveau_vmm.c |   4 +-
 drivers/gpu/drm/nouveau/nvif/vmm.c| 100 +++-
 .../gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c| 213 --
 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 197 
 drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h |  25 ++
 .../drm/nouveau/nvkm/subdev/mmu/vmmgf100.c|  16 +-
 .../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c|  16 +-
 .../gpu/drm/nouveau/nvkm/subdev/mmu/vmmnv50.c |  27 ++-
 12 files changed, 566 insertions(+), 99 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/include/nvif/if000c.h 
b/drivers/gpu/drm/nouveau/include/nvif/if000c.h
index 9c7ff56831c5..a5a182b3c28d 100644
--- a/drivers/gpu/drm/nouveau/include/nvif/if000c.h
+++ b/drivers/gpu/drm/nouveau/include/nvif/if000c.h
@@ -3,7 +3,10 @@
 struct nvif_vmm_v0 {
__u8  version;
__u8  page_nr;
-   __u8  managed;
+#define NVIF_VMM_V0_TYPE_UNMANAGED 0x00
+#define NVIF_VMM_V0_TYPE_MANAGED   0x01
+#define NVIF_VMM_V0_TYPE_RAW   0x02
+   __u8  type;
__u8  pad03[5];
__u64 addr;
__u64 size;
@@ -17,6 +20,7 @@ struct nvif_vmm_v0 {
 #define NVIF_VMM_V0_UNMAP  0x04
 #define NVIF_VMM_V0_PFNMAP 0x05
 #define NVIF_VMM_V0_PFNCLR 0x06
+#define NVIF_VMM_V0_RAW0x07
 #define NVIF_VMM_V0_MTHD(i) ((i) + 
0x80)
 
 struct nvif_vmm_page_v0 {
@@ -66,6 +70,26 @@ struct nvif_vmm_unmap_v0 {
__u64 addr;
 };
 
+struct nvif_vmm_raw_v0 {
+   __u8 version;
+#define NVIF_VMM_RAW_V0_GET0x0
+#define NVIF_VMM_RAW_V0_PUT0x1
+#define NVIF_VMM_RAW_V0_MAP0x2
+#define NVIF_VMM_RAW_V0_UNMAP  0x3
+#define NVIF_VMM_RAW_V0_SPARSE 0x4
+   __u8  op;
+   __u8  sparse;
+   __u8  ref;
+   __u8  shift;
+   __u32 argc;
+   __u8  pad01[7];
+   __u64 addr;
+   __u64 size;
+   __u64 offset;
+   __u64 memory;
+   __u64 argv;
+};
+
 struct nvif_vmm_pfnmap_v0 {
__u8  version;
__u8  page;
diff --git a/drivers/gpu/drm/nouveau/include/nvif/vmm.h 
b/drivers/gpu/drm/nouveau/include/nvif/vmm.h
index a2ee92201ace..0ecedd0ee0a5 100644
--- a/drivers/gpu/drm/nouveau/include/nvif/vmm.h
+++ b/drivers/gpu/drm/nouveau/include/nvif/vmm.h
@@ -4,6 +4,12 @@
 struct nvif_mem;
 struct nvif_mmu;
 
+enum nvif_vmm_type {
+   UNMANAGED,
+   MANAGED,
+   RAW,
+};
+
 enum nvif_vmm_get {
ADDR,
PTES,
@@ -30,8 +36,9 @@ struct nvif_vmm {
int page_nr;
 };
 
-int nvif_vmm_ctor(struct nvif_mmu *, const char *name, s32 oclass, bool 
managed,
- u64 addr, u64 size, void *argv, u32 argc, struct nvif_vmm *);
+int nvif_vmm_ctor(struct nvif_mmu *, const char *name, s32 oclass,
+ enum nvif_vmm_type, u64 addr, u64 size, void *argv, u32 argc,
+ struct nvif_vmm *);
 void nvif_vmm_dtor(struct nvif_vmm *);
 int nvif_vmm_get(struct nvif_vmm *, enum nvif_vmm_get, bool sparse,
 u8 page, u8 align, u64 size, struct nvif_vma *);
@@ -39,4 +46,12 @@ void nvif_vmm_put(struct nvif_vmm *, struct nvif_vma *);
 int nvif_vmm_map(struct nvif_vmm *, u64 addr, u64 size, void *argv, u32 argc,
 struct nvif_mem *, u64 offset);
 int nvif_vmm_unmap(struct nvif_vmm *, u64);
+
+int nvif_vmm_raw_get(struct nvif_vmm *vmm, u64 addr, u64 size, u8 shift);
+int nvif_vmm_raw_put(struct nvif_vmm *vmm, u64 addr, u64 size, u8 shift);
+int nvif_vmm_raw_map(struct nvif_vmm *vmm, u64 addr, u64 size, u8 shift,
+void *argv, u32 argc, struct nvif_mem *mem, u64 offset);
+int nvif_vmm_raw_unmap(struct nvif_vmm *vmm, u64 addr, u64 size,
+  u8 shift, bool sparse);
+int nvif_vmm_raw_sparse(struct nvif_vmm *vmm, u64 addr, u64 size, bool ref);
 #endif
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/mmu.h 
b/drivers/gpu/drm/nouveau/include/nvkm/subdev/mmu.h
index 70e7887ef4b4..2fd2f2433fc7 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/mmu.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/mmu.h
@@ -17,6 +17,7 @@ s

[PATCH drm-next v6 12/13] drm/nouveau: implement new VM_BIND uAPI

[Danilo Krummrich]

This commit provides the implementation for the new uapi motivated by the
Vulkan API. It allows user mode drivers (UMDs) to:

1) Initialize a GPU virtual address (VA) space via the new
   DRM_IOCTL_NOUVEAU_VM_INIT ioctl for UMDs to specify the portion of VA
   space managed by the kernel and userspace, respectively.

2) Allocate and free a VA space region as well as bind and unbind memory
   to the GPUs VA space via the new DRM_IOCTL_NOUVEAU_VM_BIND ioctl.
   UMDs can request the named operations to be processed either
   synchronously or asynchronously. It supports DRM syncobjs
   (incl. timelines) as synchronization mechanism. The management of the
   GPU VA mappings is implemented with the DRM GPU VA manager.

3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC ioctl. The
   execution happens asynchronously. It supports DRM syncobj (incl.
   timelines) as synchronization mechanism. DRM GEM object locking is
   handled with drm_exec.

Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC, use the DRM
GPU scheduler for the asynchronous paths.

Signed-off-by: Danilo Krummrich 
---
 Documentation/gpu/driver-uapi.rst   |3 +
 drivers/gpu/drm/nouveau/Kbuild  |3 +
 drivers/gpu/drm/nouveau/Kconfig |2 +
 drivers/gpu/drm/nouveau/nouveau_abi16.c |   24 +
 drivers/gpu/drm/nouveau/nouveau_abi16.h |1 +
 drivers/gpu/drm/nouveau/nouveau_bo.c|  147 +-
 drivers/gpu/drm/nouveau/nouveau_bo.h|2 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c   |   27 +-
 drivers/gpu/drm/nouveau/nouveau_drv.h   |   59 +-
 drivers/gpu/drm/nouveau/nouveau_exec.c  |  414 +
 drivers/gpu/drm/nouveau/nouveau_exec.h  |   54 +
 drivers/gpu/drm/nouveau/nouveau_gem.c   |   25 +-
 drivers/gpu/drm/nouveau/nouveau_mem.h   |5 +
 drivers/gpu/drm/nouveau/nouveau_prime.c |2 +-
 drivers/gpu/drm/nouveau/nouveau_sched.c |  462 ++
 drivers/gpu/drm/nouveau/nouveau_sched.h |  123 ++
 drivers/gpu/drm/nouveau/nouveau_uvmm.c  | 1970 +++
 drivers/gpu/drm/nouveau/nouveau_uvmm.h  |  107 ++
 18 files changed, 3365 insertions(+), 65 deletions(-)
 create mode 100644 drivers/gpu/drm/nouveau/nouveau_exec.c
 create mode 100644 drivers/gpu/drm/nouveau/nouveau_exec.h
 create mode 100644 drivers/gpu/drm/nouveau/nouveau_sched.c
 create mode 100644 drivers/gpu/drm/nouveau/nouveau_sched.h
 create mode 100644 drivers/gpu/drm/nouveau/nouveau_uvmm.c
 create mode 100644 drivers/gpu/drm/nouveau/nouveau_uvmm.h

diff --git a/Documentation/gpu/driver-uapi.rst 
b/Documentation/gpu/driver-uapi.rst
index 9c7ca6e33a68..c08bcbb95fb3 100644
--- a/Documentation/gpu/driver-uapi.rst
+++ b/Documentation/gpu/driver-uapi.rst
@@ -13,4 +13,7 @@ drm/nouveau uAPI
 VM_BIND / EXEC uAPI
 ---
 
+.. kernel-doc:: drivers/gpu/drm/nouveau/nouveau_exec.c
+:doc: Overview
+
 .. kernel-doc:: include/uapi/drm/nouveau_drm.h
diff --git a/drivers/gpu/drm/nouveau/Kbuild b/drivers/gpu/drm/nouveau/Kbuild
index 5e5617006da5..cf6b3a80c0c8 100644
--- a/drivers/gpu/drm/nouveau/Kbuild
+++ b/drivers/gpu/drm/nouveau/Kbuild
@@ -47,6 +47,9 @@ nouveau-y += nouveau_prime.o
 nouveau-y += nouveau_sgdma.o
 nouveau-y += nouveau_ttm.o
 nouveau-y += nouveau_vmm.o
+nouveau-y += nouveau_exec.o
+nouveau-y += nouveau_sched.o
+nouveau-y += nouveau_uvmm.o
 
 # DRM - modesetting
 nouveau-$(CONFIG_DRM_NOUVEAU_BACKLIGHT) += nouveau_backlight.o
diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig
index a70bd65e1400..c52e8096cca4 100644
--- a/drivers/gpu/drm/nouveau/Kconfig
+++ b/drivers/gpu/drm/nouveau/Kconfig
@@ -10,6 +10,8 @@ config DRM_NOUVEAU
select DRM_KMS_HELPER
select DRM_TTM
select DRM_TTM_HELPER
+   select DRM_EXEC
+   select DRM_SCHED
select I2C
select I2C_ALGOBIT
select BACKLIGHT_CLASS_DEVICE if DRM_NOUVEAU_BACKLIGHT
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c 
b/drivers/gpu/drm/nouveau/nouveau_abi16.c
index 82dab51d8aeb..a112f28681d3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
@@ -35,6 +35,7 @@
 #include "nouveau_chan.h"
 #include "nouveau_abi16.h"
 #include "nouveau_vmm.h"
+#include "nouveau_sched.h"
 
 static struct nouveau_abi16 *
 nouveau_abi16(struct drm_file *file_priv)
@@ -125,6 +126,17 @@ nouveau_abi16_chan_fini(struct nouveau_abi16 *abi16,
 {
struct nouveau_abi16_ntfy *ntfy, *temp;
 
+   /* When a client exits without waiting for it's queued up jobs to
+* finish it might happen that we fault the channel. This is due to
+* drm_file_free() calling drm_gem_release() before the postclose()
+* callback. Hence, we can't tear down this scheduler entity before
+* uvmm mappings are unmapped. Currently, we can't detect this case.
+*
+* However, this should be rare and harmless, since the channel isn't
+* needed anymore.
+*/
+   nouveau_sched_entity_fini(&chan->sched_entity);
+
/* wait for all activity 

[PATCH drm-next v6 10/13] drm/nouveau: chan: provide nouveau_channel_kill()

[Danilo Krummrich]

The new VM_BIND UAPI implementation introduced in subsequent commits
will allow asynchronous jobs processing push buffers and emitting fences.

If a job times out, we need a way to recover from this situation. For
now, simply kill the channel to unblock all hung up jobs and signal
userspace that the device is dead on the next EXEC or VM_BIND ioctl.

Signed-off-by: Danilo Krummrich 
---
 drivers/gpu/drm/nouveau/nouveau_chan.c | 14 +++---
 drivers/gpu/drm/nouveau/nouveau_chan.h |  1 +
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c 
b/drivers/gpu/drm/nouveau/nouveau_chan.c
index f47c0363683c..a975f8b0e0e5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.c
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
@@ -40,6 +40,14 @@ MODULE_PARM_DESC(vram_pushbuf, "Create DMA push buffers in 
VRAM");
 int nouveau_vram_pushbuf;
 module_param_named(vram_pushbuf, nouveau_vram_pushbuf, int, 0400);
 
+void
+nouveau_channel_kill(struct nouveau_channel *chan)
+{
+   atomic_set(&chan->killed, 1);
+   if (chan->fence)
+   nouveau_fence_context_kill(chan->fence, -ENODEV);
+}
+
 static int
 nouveau_channel_killed(struct nvif_event *event, void *repv, u32 repc)
 {
@@ -47,9 +55,9 @@ nouveau_channel_killed(struct nvif_event *event, void *repv, 
u32 repc)
struct nouveau_cli *cli = (void *)chan->user.client;
 
NV_PRINTK(warn, cli, "channel %d killed!\n", chan->chid);
-   atomic_set(&chan->killed, 1);
-   if (chan->fence)
-   nouveau_fence_context_kill(chan->fence, -ENODEV);
+
+   if (unlikely(!atomic_read(&chan->killed)))
+   nouveau_channel_kill(chan);
 
return NVIF_EVENT_DROP;
 }
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.h 
b/drivers/gpu/drm/nouveau/nouveau_chan.h
index e06a8ffed31a..e483f4a254da 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.h
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.h
@@ -65,6 +65,7 @@ int  nouveau_channel_new(struct nouveau_drm *, struct 
nvif_device *, bool priv,
 u32 vram, u32 gart, struct nouveau_channel **);
 void nouveau_channel_del(struct nouveau_channel **);
 int  nouveau_channel_idle(struct nouveau_channel *);
+void nouveau_channel_kill(struct nouveau_channel *);
 
 extern int nouveau_vram_pushbuf;
 
-- 
2.41.0

[PATCH drm-next v6 09/13] drm/nouveau: fence: fail to emit when fence context is killed

[Danilo Krummrich]

The new VM_BIND UAPI implementation introduced in subsequent commits
will allow asynchronous jobs processing push buffers and emitting
fences.

If a fence context is killed, e.g. due to a channel fault, jobs which
are already queued for execution might still emit new fences. In such a
case a job would hang forever.

To fix that, fail to emit a new fence on a killed fence context with
-ENODEV to unblock the job.

Signed-off-by: Danilo Krummrich 
---
 drivers/gpu/drm/nouveau/nouveau_fence.c | 7 +++
 drivers/gpu/drm/nouveau/nouveau_fence.h | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c 
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index e946408f945b..77c739a55b19 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -96,6 +96,7 @@ nouveau_fence_context_kill(struct nouveau_fence_chan *fctx, 
int error)
if (nouveau_fence_signal(fence))
nvif_event_block(&fctx->event);
}
+   fctx->killed = 1;
spin_unlock_irqrestore(&fctx->lock, flags);
 }
 
@@ -229,6 +230,12 @@ nouveau_fence_emit(struct nouveau_fence *fence, struct 
nouveau_channel *chan)
dma_fence_get(&fence->base);
spin_lock_irq(&fctx->lock);
 
+   if (unlikely(fctx->killed)) {
+   spin_unlock_irq(&fctx->lock);
+   dma_fence_put(&fence->base);
+   return -ENODEV;
+   }
+
if (nouveau_fence_update(chan, fctx))
nvif_event_block(&fctx->event);
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.h 
b/drivers/gpu/drm/nouveau/nouveau_fence.h
index 7c73c7c9834a..2c72d96ef17d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.h
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.h
@@ -44,7 +44,7 @@ struct nouveau_fence_chan {
char name[32];
 
struct nvif_event event;
-   int notify_ref, dead;
+   int notify_ref, dead, killed;
 };
 
 struct nouveau_fence_priv {
-- 
2.41.0

[PATCH drm-next v6 07/13] drm/nouveau: move usercopy helpers to nouveau_drv.h

[Danilo Krummrich]

Move the usercopy helpers to a common driver header file to make it
usable for the new API added in subsequent commits.

Signed-off-by: Danilo Krummrich 
---
 drivers/gpu/drm/nouveau/nouveau_drv.h | 26 ++
 drivers/gpu/drm/nouveau/nouveau_gem.c | 26 --
 2 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 81350e685b50..20a7f31b9082 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -130,6 +130,32 @@ nouveau_cli(struct drm_file *fpriv)
return fpriv ? fpriv->driver_priv : NULL;
 }
 
+static inline void
+u_free(void *addr)
+{
+   kvfree(addr);
+}
+
+static inline void *
+u_memcpya(uint64_t user, unsigned nmemb, unsigned size)
+{
+   void *mem;
+   void __user *userptr = (void __force __user *)(uintptr_t)user;
+
+   size *= nmemb;
+
+   mem = kvmalloc(size, GFP_KERNEL);
+   if (!mem)
+   return ERR_PTR(-ENOMEM);
+
+   if (copy_from_user(mem, userptr, size)) {
+   u_free(mem);
+   return ERR_PTR(-EFAULT);
+   }
+
+   return mem;
+}
+
 #include 
 #include 
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 45ca4eb98f54..a48f42aaeab9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -613,32 +613,6 @@ nouveau_gem_pushbuf_validate(struct nouveau_channel *chan,
return 0;
 }
 
-static inline void
-u_free(void *addr)
-{
-   kvfree(addr);
-}
-
-static inline void *
-u_memcpya(uint64_t user, unsigned nmemb, unsigned size)
-{
-   void *mem;
-   void __user *userptr = (void __force __user *)(uintptr_t)user;
-
-   size *= nmemb;
-
-   mem = kvmalloc(size, GFP_KERNEL);
-   if (!mem)
-   return ERR_PTR(-ENOMEM);
-
-   if (copy_from_user(mem, userptr, size)) {
-   u_free(mem);
-   return ERR_PTR(-EFAULT);
-   }
-
-   return mem;
-}
-
 static int
 nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
struct drm_nouveau_gem_pushbuf *req,
-- 
2.41.0

[PATCH drm-next v6 08/13] drm/nouveau: fence: separate fence alloc and emit

[Danilo Krummrich]

The new (VM_BIND) UAPI exports DMA fences through DRM syncobjs. Hence,
in order to emit fences within DMA fence signalling critical sections
(e.g. as typically done in the DRM GPU schedulers run_job() callback) we
need to separate fence allocation and fence emitting.

Signed-off-by: Danilo Krummrich 
---
 drivers/gpu/drm/nouveau/dispnv04/crtc.c |  9 -
 drivers/gpu/drm/nouveau/nouveau_bo.c| 52 +++--
 drivers/gpu/drm/nouveau/nouveau_chan.c  |  6 ++-
 drivers/gpu/drm/nouveau/nouveau_dmem.c  |  9 +++--
 drivers/gpu/drm/nouveau/nouveau_fence.c | 16 +++-
 drivers/gpu/drm/nouveau/nouveau_fence.h |  3 +-
 drivers/gpu/drm/nouveau/nouveau_gem.c   |  5 ++-
 7 files changed, 59 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c 
b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index a6f2e681bde9..a34924523133 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -1122,11 +1122,18 @@ nv04_page_flip_emit(struct nouveau_channel *chan,
PUSH_NVSQ(push, NV_SW, NV_SW_PAGE_FLIP, 0x);
PUSH_KICK(push);
 
-   ret = nouveau_fence_new(chan, false, pfence);
+   ret = nouveau_fence_new(pfence);
if (ret)
goto fail;
 
+   ret = nouveau_fence_emit(*pfence, chan);
+   if (ret)
+   goto fail_fence_unref;
+
return 0;
+
+fail_fence_unref:
+   nouveau_fence_unref(pfence);
 fail:
spin_lock_irqsave(&dev->event_lock, flags);
list_del(&s->head);
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 057bc995f19b..e9cbbf594e6f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -820,29 +820,39 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int 
evict,
mutex_lock(&cli->mutex);
else
mutex_lock_nested(&cli->mutex, SINGLE_DEPTH_NESTING);
+
ret = nouveau_fence_sync(nouveau_bo(bo), chan, true, 
ctx->interruptible);
-   if (ret == 0) {
-   ret = drm->ttm.move(chan, bo, bo->resource, new_reg);
-   if (ret == 0) {
-   ret = nouveau_fence_new(chan, false, &fence);
-   if (ret == 0) {
-   /* TODO: figure out a better solution here
-*
-* wait on the fence here explicitly as going 
through
-* ttm_bo_move_accel_cleanup somehow doesn't 
seem to do it.
-*
-* Without this the operation can timeout and 
we'll fallback to a
-* software copy, which might take several 
minutes to finish.
-*/
-   nouveau_fence_wait(fence, false, false);
-   ret = ttm_bo_move_accel_cleanup(bo,
-   &fence->base,
-   evict, false,
-   new_reg);
-   nouveau_fence_unref(&fence);
-   }
-   }
+   if (ret)
+   goto out_unlock;
+
+   ret = drm->ttm.move(chan, bo, bo->resource, new_reg);
+   if (ret)
+   goto out_unlock;
+
+   ret = nouveau_fence_new(&fence);
+   if (ret)
+   goto out_unlock;
+
+   ret = nouveau_fence_emit(fence, chan);
+   if (ret) {
+   nouveau_fence_unref(&fence);
+   goto out_unlock;
}
+
+   /* TODO: figure out a better solution here
+*
+* wait on the fence here explicitly as going through
+* ttm_bo_move_accel_cleanup somehow doesn't seem to do it.
+*
+* Without this the operation can timeout and we'll fallback to a
+* software copy, which might take several minutes to finish.
+*/
+   nouveau_fence_wait(fence, false, false);
+   ret = ttm_bo_move_accel_cleanup(bo, &fence->base, evict, false,
+   new_reg);
+   nouveau_fence_unref(&fence);
+
+out_unlock:
mutex_unlock(&cli->mutex);
return ret;
 }
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c 
b/drivers/gpu/drm/nouveau/nouveau_chan.c
index 1068abe41024..f47c0363683c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.c
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
@@ -62,9 +62,11 @@ nouveau_channel_idle(struct nouveau_channel *chan)
struct nouveau_fence *fence = NULL;
int ret;
 
-   ret = nouveau_fence_new(chan, false, &fence);
+   ret = nouveau_fence_new(&fence);
if (!ret) {
-   ret = nouveau_fence_wait(fence, false, false);
+   ret = nouveau_fence_

[PATCH drm-next v6 06/13] drm/nouveau: bo: initialize GEM GPU VA interface

[Danilo Krummrich]

Initialize the GEM's DRM GPU VA manager interface in preparation for the
(u)vmm implementation, provided by subsequent commits, to make use of it.

Signed-off-by: Danilo Krummrich 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 7724fe63067d..057bc995f19b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -215,11 +215,14 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, int 
*align, u32 domain,
nvbo = kzalloc(sizeof(struct nouveau_bo), GFP_KERNEL);
if (!nvbo)
return ERR_PTR(-ENOMEM);
+
INIT_LIST_HEAD(&nvbo->head);
INIT_LIST_HEAD(&nvbo->entry);
INIT_LIST_HEAD(&nvbo->vma_list);
nvbo->bo.bdev = &drm->ttm.bdev;
 
+   drm_gem_gpuva_init(&nvbo->bo.base);
+
/* This is confusing, and doesn't actually mean we want an uncached
 * mapping, but is what NOUVEAU_GEM_DOMAIN_COHERENT gets translated
 * into in nouveau_gem_new().
-- 
2.41.0

[PATCH drm-next v6 05/13] drm/nouveau: get vmm via nouveau_cli_vmm()

[Danilo Krummrich]

Provide a getter function for the client's current vmm context. Since
we'll add a new (u)vmm context for UMD bindings in subsequent commits,
this will keep the code clean.

Signed-off-by: Danilo Krummrich 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c   | 2 +-
 drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +-
 drivers/gpu/drm/nouveau/nouveau_drv.h  | 9 +
 drivers/gpu/drm/nouveau/nouveau_gem.c  | 6 +++---
 4 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index c2ec91cc845d..7724fe63067d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -204,7 +204,7 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, int 
*align, u32 domain,
struct nouveau_drm *drm = cli->drm;
struct nouveau_bo *nvbo;
struct nvif_mmu *mmu = &cli->mmu;
-   struct nvif_vmm *vmm = cli->svm.cli ? &cli->svm.vmm : &cli->vmm.vmm;
+   struct nvif_vmm *vmm = &nouveau_cli_vmm(cli)->vmm;
int i, pi = -1;
 
if (!*size) {
diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c 
b/drivers/gpu/drm/nouveau/nouveau_chan.c
index e648ecd0c1a0..1068abe41024 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.c
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
@@ -148,7 +148,7 @@ nouveau_channel_prep(struct nouveau_drm *drm, struct 
nvif_device *device,
 
chan->device = device;
chan->drm = drm;
-   chan->vmm = cli->svm.cli ? &cli->svm : &cli->vmm;
+   chan->vmm = nouveau_cli_vmm(cli);
atomic_set(&chan->killed, 0);
 
/* allocate memory for dma push buffer */
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index b5de312a523f..81350e685b50 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -112,6 +112,15 @@ struct nouveau_cli_work {
struct dma_fence_cb cb;
 };
 
+static inline struct nouveau_vmm *
+nouveau_cli_vmm(struct nouveau_cli *cli)
+{
+   if (cli->svm.cli)
+   return &cli->svm;
+
+   return &cli->vmm;
+}
+
 void nouveau_cli_work_queue(struct nouveau_cli *, struct dma_fence *,
struct nouveau_cli_work *);
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index ab9062e50977..45ca4eb98f54 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -103,7 +103,7 @@ nouveau_gem_object_open(struct drm_gem_object *gem, struct 
drm_file *file_priv)
struct nouveau_bo *nvbo = nouveau_gem_object(gem);
struct nouveau_drm *drm = nouveau_bdev(nvbo->bo.bdev);
struct device *dev = drm->dev->dev;
-   struct nouveau_vmm *vmm = cli->svm.cli ? &cli->svm : &cli->vmm;
+   struct nouveau_vmm *vmm = nouveau_cli_vmm(cli);
struct nouveau_vma *vma;
int ret;
 
@@ -180,7 +180,7 @@ nouveau_gem_object_close(struct drm_gem_object *gem, struct 
drm_file *file_priv)
struct nouveau_bo *nvbo = nouveau_gem_object(gem);
struct nouveau_drm *drm = nouveau_bdev(nvbo->bo.bdev);
struct device *dev = drm->dev->dev;
-   struct nouveau_vmm *vmm = cli->svm.cli ? &cli->svm : & cli->vmm;
+   struct nouveau_vmm *vmm = nouveau_cli_vmm(cli);
struct nouveau_vma *vma;
int ret;
 
@@ -269,7 +269,7 @@ nouveau_gem_info(struct drm_file *file_priv, struct 
drm_gem_object *gem,
 {
struct nouveau_cli *cli = nouveau_cli(file_priv);
struct nouveau_bo *nvbo = nouveau_gem_object(gem);
-   struct nouveau_vmm *vmm = cli->svm.cli ? &cli->svm : &cli->vmm;
+   struct nouveau_vmm *vmm = nouveau_cli_vmm(cli);
struct nouveau_vma *vma;
 
if (is_power_of_2(nvbo->valid_domains))
-- 
2.41.0

[PATCH drm-next v6 03/13] drm: debugfs: provide infrastructure to dump a DRM GPU VA space

[Danilo Krummrich]

This commit adds a function to dump a DRM GPU VA space and a macro for
drivers to register the struct drm_info_list 'gpuvas' entry.

Most likely, most drivers might maintain one DRM GPU VA space per struct
drm_file, but there might also be drivers not having a fixed relation
between DRM GPU VA spaces and a DRM core infrastructure, hence we need the
indirection via the driver iterating it's maintained DRM GPU VA spaces.

Reviewed-by: Boris Brezillon 
Signed-off-by: Danilo Krummrich 
---
 drivers/gpu/drm/drm_debugfs.c | 40 +++
 include/drm/drm_debugfs.h | 25 ++
 2 files changed, 65 insertions(+)

diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 4855230ba2c6..c90dbcffa0dc 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "drm_crtc_internal.h"
 #include "drm_internal.h"
@@ -175,6 +176,45 @@ static const struct file_operations drm_debugfs_fops = {
.release = single_release,
 };
 
+/**
+ * drm_debugfs_gpuva_info - dump the given DRM GPU VA space
+ * @m: pointer to the &seq_file to write
+ * @mgr: the &drm_gpuva_manager representing the GPU VA space
+ *
+ * Dumps the GPU VA mappings of a given DRM GPU VA manager.
+ *
+ * For each DRM GPU VA space drivers should call this function from their
+ * &drm_info_list's show callback.
+ *
+ * Returns: 0 on success, -ENODEV if the &mgr is not initialized
+ */
+int drm_debugfs_gpuva_info(struct seq_file *m,
+  struct drm_gpuva_manager *mgr)
+{
+   struct drm_gpuva *va, *kva = &mgr->kernel_alloc_node;
+
+   if (!mgr->name)
+   return -ENODEV;
+
+   seq_printf(m, "DRM GPU VA space (%s) [0x%016llx;0x%016llx]\n",
+  mgr->name, mgr->mm_start, mgr->mm_start + mgr->mm_range);
+   seq_printf(m, "Kernel reserved node [0x%016llx;0x%016llx]\n",
+  kva->va.addr, kva->va.addr + kva->va.range);
+   seq_puts(m, "\n");
+   seq_puts(m, " VAs | start  | range  | end   
 | object | object offset\n");
+   seq_puts(m, 
"-\n");
+   drm_gpuva_for_each_va(va, mgr) {
+   if (unlikely(va == kva))
+   continue;
+
+   seq_printf(m, " | 0x%016llx | 0x%016llx | 0x%016llx | 
0x%016llx | 0x%016llx\n",
+  va->va.addr, va->va.range, va->va.addr + 
va->va.range,
+  (u64)va->gem.obj, va->gem.offset);
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_debugfs_gpuva_info);
 
 /**
  * drm_debugfs_create_files - Initialize a given set of debugfs files for DRM
diff --git a/include/drm/drm_debugfs.h b/include/drm/drm_debugfs.h
index 7616f457ce70..cb2c1956a214 100644
--- a/include/drm/drm_debugfs.h
+++ b/include/drm/drm_debugfs.h
@@ -34,6 +34,22 @@
 
 #include 
 #include 
+
+#include 
+
+/**
+ * DRM_DEBUGFS_GPUVA_INFO - &drm_info_list entry to dump a GPU VA space
+ * @show: the &drm_info_list's show callback
+ * @data: driver private data
+ *
+ * Drivers should use this macro to define a &drm_info_list entry to provide a
+ * debugfs file for dumping the GPU VA space regions and mappings.
+ *
+ * For each DRM GPU VA space drivers should call drm_debugfs_gpuva_info() from
+ * their @show callback.
+ */
+#define DRM_DEBUGFS_GPUVA_INFO(show, data) {"gpuvas", show, DRIVER_GEM_GPUVA, 
data}
+
 /**
  * struct drm_info_list - debugfs info list entry
  *
@@ -134,6 +150,9 @@ void drm_debugfs_add_file(struct drm_device *dev, const 
char *name,
 
 void drm_debugfs_add_files(struct drm_device *dev,
   const struct drm_debugfs_info *files, int count);
+
+int drm_debugfs_gpuva_info(struct seq_file *m,
+  struct drm_gpuva_manager *mgr);
 #else
 static inline void drm_debugfs_create_files(const struct drm_info_list *files,
int count, struct dentry *root,
@@ -155,6 +174,12 @@ static inline void drm_debugfs_add_files(struct drm_device 
*dev,
 const struct drm_debugfs_info *files,
 int count)
 {}
+
+static inline int drm_debugfs_gpuva_info(struct seq_file *m,
+struct drm_gpuva_manager *mgr)
+{
+   return 0;
+}
 #endif
 
 #endif /* _DRM_DEBUGFS_H_ */
-- 
2.41.0

[PATCH drm-next v6 04/13] drm/nouveau: new VM_BIND uapi interfaces

[Danilo Krummrich]

This commit provides the interfaces for the new UAPI motivated by the
Vulkan API. It allows user mode drivers (UMDs) to:

1) Initialize a GPU virtual address (VA) space via the new
   DRM_IOCTL_NOUVEAU_VM_INIT ioctl. UMDs can provide a kernel reserved
   VA area.

2) Bind and unbind GPU VA space mappings via the new
   DRM_IOCTL_NOUVEAU_VM_BIND ioctl.

3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC ioctl.

Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC support
asynchronous processing with DRM syncobjs as synchronization mechanism.

The default DRM_IOCTL_NOUVEAU_VM_BIND is synchronous processing,
DRM_IOCTL_NOUVEAU_EXEC supports asynchronous processing only.

Co-authored-by: Dave Airlie 
Signed-off-by: Danilo Krummrich 
---
 Documentation/gpu/driver-uapi.rst |   8 ++
 include/uapi/drm/nouveau_drm.h| 209 ++
 2 files changed, 217 insertions(+)

diff --git a/Documentation/gpu/driver-uapi.rst 
b/Documentation/gpu/driver-uapi.rst
index 4411e6919a3d..9c7ca6e33a68 100644
--- a/Documentation/gpu/driver-uapi.rst
+++ b/Documentation/gpu/driver-uapi.rst
@@ -6,3 +6,11 @@ drm/i915 uAPI
 =
 
 .. kernel-doc:: include/uapi/drm/i915_drm.h
+
+drm/nouveau uAPI
+
+
+VM_BIND / EXEC uAPI
+---
+
+.. kernel-doc:: include/uapi/drm/nouveau_drm.h
diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h
index 853a327433d3..4d3a70529637 100644
--- a/include/uapi/drm/nouveau_drm.h
+++ b/include/uapi/drm/nouveau_drm.h
@@ -126,6 +126,209 @@ struct drm_nouveau_gem_cpu_fini {
__u32 handle;
 };
 
+/**
+ * struct drm_nouveau_sync - sync object
+ *
+ * This structure serves as synchronization mechanism for (potentially)
+ * asynchronous operations such as EXEC or VM_BIND.
+ */
+struct drm_nouveau_sync {
+   /**
+* @flags: the flags for a sync object
+*
+* The first 8 bits are used to determine the type of the sync object.
+*/
+   __u32 flags;
+#define DRM_NOUVEAU_SYNC_SYNCOBJ 0x0
+#define DRM_NOUVEAU_SYNC_TIMELINE_SYNCOBJ 0x1
+#define DRM_NOUVEAU_SYNC_TYPE_MASK 0xf
+   /**
+* @handle: the handle of the sync object
+*/
+   __u32 handle;
+   /**
+* @timeline_value:
+*
+* The timeline point of the sync object in case the syncobj is of
+* type DRM_NOUVEAU_SYNC_TIMELINE_SYNCOBJ.
+*/
+   __u64 timeline_value;
+};
+
+/**
+ * struct drm_nouveau_vm_init - GPU VA space init structure
+ *
+ * Used to initialize the GPU's VA space for a user client, telling the kernel
+ * which portion of the VA space is managed by the UMD and kernel respectively.
+ */
+struct drm_nouveau_vm_init {
+   /**
+* @unmanaged_addr: start address of the kernel managed VA space region
+*/
+   __u64 unmanaged_addr;
+   /**
+* @unmanaged_size: size of the kernel managed VA space region in bytes
+*/
+   __u64 unmanaged_size;
+};
+
+/**
+ * struct drm_nouveau_vm_bind_op - VM_BIND operation
+ *
+ * This structure represents a single VM_BIND operation. UMDs should pass
+ * an array of this structure via struct drm_nouveau_vm_bind's &op_ptr field.
+ */
+struct drm_nouveau_vm_bind_op {
+   /**
+* @op: the operation type
+*/
+   __u32 op;
+/**
+ * @DRM_NOUVEAU_VM_BIND_OP_MAP:
+ *
+ * Map a GEM object to the GPU's VA space. Optionally, the
+ * &DRM_NOUVEAU_VM_BIND_SPARSE flag can be passed to instruct the kernel to
+ * create sparse mappings for the given range.
+ */
+#define DRM_NOUVEAU_VM_BIND_OP_MAP 0x0
+/**
+ * @DRM_NOUVEAU_VM_BIND_OP_UNMAP:
+ *
+ * Unmap an existing mapping in the GPU's VA space. If the region the mapping
+ * is located in is a sparse region, new sparse mappings are created where the
+ * unmapped (memory backed) mapping was mapped previously. To remove a sparse
+ * region the &DRM_NOUVEAU_VM_BIND_SPARSE must be set.
+ */
+#define DRM_NOUVEAU_VM_BIND_OP_UNMAP 0x1
+   /**
+* @flags: the flags for a &drm_nouveau_vm_bind_op
+*/
+   __u32 flags;
+/**
+ * @DRM_NOUVEAU_VM_BIND_SPARSE:
+ *
+ * Indicates that an allocated VA space region should be sparse.
+ */
+#define DRM_NOUVEAU_VM_BIND_SPARSE (1 << 8)
+   /**
+* @handle: the handle of the DRM GEM object to map
+*/
+   __u32 handle;
+   /**
+* @pad: 32 bit padding, should be 0
+*/
+   __u32 pad;
+   /**
+* @addr:
+*
+* the address the VA space region or (memory backed) mapping should be 
mapped to
+*/
+   __u64 addr;
+   /**
+* @bo_offset: the offset within the BO backing the mapping
+*/
+   __u64 bo_offset;
+   /**
+* @range: the size of the requested mapping in bytes
+*/
+   __u64 range;
+};
+
+/**
+ * struct drm_nouveau_vm_bind - structure for DRM_IOCTL_NOUVEAU_VM_BIND
+ */
+struct drm_nouveau_vm_bind {
+   /**
+* @op_count: the number of &drm_nou

[PATCH drm-next v6 02/13] drm: manager to keep track of GPUs VA mappings

[Danilo Krummrich]

Add infrastructure to keep track of GPU virtual address (VA) mappings
with a decicated VA space manager implementation.

New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers
start implementing, allow userspace applications to request multiple and
arbitrary GPU VA mappings of buffer objects. The DRM GPU VA manager is
intended to serve the following purposes in this context.

1) Provide infrastructure to track GPU VA allocations and mappings,
   making use of the maple_tree.

2) Generically connect GPU VA mappings to their backing buffers, in
   particular DRM GEM objects.

3) Provide a common implementation to perform more complex mapping
   operations on the GPU VA space. In particular splitting and merging
   of GPU VA mappings, e.g. for intersecting mapping requests or partial
   unmap requests.

Tested-by: Donald Robson 
Reviewed-by: Boris Brezillon 
Suggested-by: Dave Airlie 
Signed-off-by: Danilo Krummrich 
---
 Documentation/gpu/drm-mm.rst|   36 +
 drivers/gpu/drm/Makefile|1 +
 drivers/gpu/drm/drm_gem.c   |3 +
 drivers/gpu/drm/drm_gpuva_mgr.c | 1743 +++
 include/drm/drm_drv.h   |6 +
 include/drm/drm_gem.h   |   52 +
 include/drm/drm_gpuva_mgr.h |  756 ++
 7 files changed, 2597 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_gpuva_mgr.c
 create mode 100644 include/drm/drm_gpuva_mgr.h

diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index a52e6f4117d6..3d5dc9dc1bfe 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -466,6 +466,42 @@ DRM MM Range Allocator Function References
 .. kernel-doc:: drivers/gpu/drm/drm_mm.c
:export:
 
+DRM GPU VA Manager
+==
+
+Overview
+
+
+.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c
+   :doc: Overview
+
+Split and Merge
+---
+
+.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c
+   :doc: Split and Merge
+
+Locking
+---
+
+.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c
+   :doc: Locking
+
+Examples
+
+
+.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c
+   :doc: Examples
+
+DRM GPU VA Manager Function References
+--
+
+.. kernel-doc:: include/drm/drm_gpuva_mgr.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c
+   :export:
+
 DRM Buddy Allocator
 ===
 
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 414855e2a463..6d6c9dec66e8 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -45,6 +45,7 @@ drm-y := \
drm_vblank.o \
drm_vblank_work.o \
drm_vma_manager.o \
+   drm_gpuva_mgr.o \
drm_writeback.o
 drm-$(CONFIG_DRM_LEGACY) += \
drm_agpsupport.o \
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 1a5a2cd0d4ec..cd878ebddbd0 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -164,6 +164,9 @@ void drm_gem_private_object_init(struct drm_device *dev,
if (!obj->resv)
obj->resv = &obj->_resv;
 
+   if (drm_core_check_feature(dev, DRIVER_GEM_GPUVA))
+   drm_gem_gpuva_init(obj);
+
drm_vma_node_reset(&obj->vma_node);
INIT_LIST_HEAD(&obj->lru_node);
 }
diff --git a/drivers/gpu/drm/drm_gpuva_mgr.c b/drivers/gpu/drm/drm_gpuva_mgr.c
new file mode 100644
index ..4414990c05cc
--- /dev/null
+++ b/drivers/gpu/drm/drm_gpuva_mgr.c
@@ -0,0 +1,1743 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2022 Red Hat.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ * Danilo Krummrich 
+ *
+ */
+
+#include 
+
+#include 
+#include 
+
+/**
+ * DOC: Overview
+ *
+ * The DRM GPU VA Manager, represented by struct drm_gpuva_manager keeps track
+ * of a GPU's virtual address (VA) space and manages the corresponding virtual
+ * mappings represented by &drm_gpuva objects. It a

[PATCH drm-next v6 01/13] drm: execution context for GEM buffers v5

[Danilo Krummrich]

From: Christian König 

This adds the infrastructure for an execution context for GEM buffers
which is similar to the existing TTMs execbuf util and intended to replace
it in the long term.

The basic functionality is that we abstracts the necessary loop to lock
many different GEM buffers with automated deadlock and duplicate handling.

v2: drop xarray and use dynamic resized array instead, the locking
overhead is unecessary and measurable.
v3: drop duplicate tracking, radeon is really the only one needing that.
v4: fixes issues pointed out by Danilo, some typos in comments and a
helper for lock arrays of GEM objects.
v5: some suggestions by Boris Brezillon, especially just use one retry
macro, drop loop in prepare_array, use flags instead of bool

Signed-off-by: Christian König 
---
 Documentation/gpu/drm-mm.rst |  12 ++
 drivers/gpu/drm/Kconfig  |   6 +
 drivers/gpu/drm/Makefile |   2 +
 drivers/gpu/drm/drm_exec.c   | 330 +++
 include/drm/drm_exec.h   | 120 +
 5 files changed, 470 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_exec.c
 create mode 100644 include/drm/drm_exec.h

diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index a79fd3549ff8..a52e6f4117d6 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -493,6 +493,18 @@ DRM Sync Objects
 .. kernel-doc:: drivers/gpu/drm/drm_syncobj.c
:export:
 
+DRM Execution context
+=
+
+.. kernel-doc:: drivers/gpu/drm/drm_exec.c
+   :doc: Overview
+
+.. kernel-doc:: include/drm/drm_exec.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_exec.c
+   :export:
+
 GPU Scheduler
 =
 
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index afb3b2f5f425..c2f3d234c89e 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -194,6 +194,12 @@ config DRM_TTM
  GPU memory types. Will be enabled automatically if a device driver
  uses it.
 
+config DRM_EXEC
+   tristate
+   depends on DRM
+   help
+ Execution context for command submissions
+
 config DRM_BUDDY
tristate
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 7a09a89b493b..414855e2a463 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -78,6 +78,8 @@ obj-$(CONFIG_DRM_PANEL_ORIENTATION_QUIRKS) += 
drm_panel_orientation_quirks.o
 #
 # Memory-management helpers
 #
+#
+obj-$(CONFIG_DRM_EXEC) += drm_exec.o
 
 obj-$(CONFIG_DRM_BUDDY) += drm_buddy.o
 
diff --git a/drivers/gpu/drm/drm_exec.c b/drivers/gpu/drm/drm_exec.c
new file mode 100644
index ..285bf80740b5
--- /dev/null
+++ b/drivers/gpu/drm/drm_exec.c
@@ -0,0 +1,330 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */
+
+#include 
+#include 
+#include 
+
+/**
+ * DOC: Overview
+ *
+ * This component mainly abstracts the retry loop necessary for locking
+ * multiple GEM objects while preparing hardware operations (e.g. command
+ * submissions, page table updates etc..).
+ *
+ * If a contention is detected while locking a GEM object the cleanup procedure
+ * unlocks all previously locked GEM objects and locks the contended one first
+ * before locking any further objects.
+ *
+ * After an object is locked fences slots can optionally be reserved on the
+ * dma_resv object inside the GEM object.
+ *
+ * A typical usage pattern should look like this::
+ *
+ * struct drm_gem_object *obj;
+ * struct drm_exec exec;
+ * unsigned long index;
+ * int ret;
+ *
+ * drm_exec_init(&exec, DRM_EXEC_INTERRUPTIBLE_WAIT);
+ * drm_exec_until_all_locked(&exec) {
+ * ret = drm_exec_prepare_obj(&exec, boA, 1);
+ * drm_exec_retry_on_contention(&exec);
+ * if (ret)
+ * goto error;
+ *
+ * ret = drm_exec_prepare_obj(&exec, boB, 1);
+ * drm_exec_retry_on_contention(&exec);
+ * if (ret)
+ * goto error;
+ * }
+ *
+ * drm_exec_for_each_locked_object(&exec, index, obj) {
+ * dma_resv_add_fence(obj->resv, fence, DMA_RESV_USAGE_READ);
+ * ...
+ * }
+ * drm_exec_fini(&exec);
+ *
+ * See struct dma_exec for more details.
+ */
+
+/* Dummy value used to initially enter the retry loop */
+#define DRM_EXEC_DUMMY (void*)~0
+
+/* Unlock all objects and drop references */
+static void drm_exec_unlock_all(struct drm_exec *exec)
+{
+   struct drm_gem_object *obj;
+   unsigned long index;
+
+   drm_exec_for_each_locked_object(exec, index, obj) {
+   dma_resv_unlock(obj->resv);
+   drm_gem_object_put(obj);
+   }
+
+   drm_gem_object_put(exec->prelocked);
+   exec->prelocked = NULL;
+}
+
+/**
+ * drm_exec_init - initialize a drm_exec object
+ * @exec: the drm_exec object to initialize
+ * @flags: controls locking behavior, see DRM_EXEC_* defines
+ *
+ * Initialize the object and make sure t

[PATCH drm-next v6 00/13] [RFC] DRM GPUVA Manager & Nouveau VM_BIND UAPI

[Danilo Krummrich]

This patch series provides a new UAPI for the Nouveau driver in order to
support Vulkan features, such as sparse bindings and sparse residency.

Furthermore, with the DRM GPUVA manager it provides a new DRM core feature to
keep track of GPU virtual address (VA) mappings in a more generic way.

The DRM GPUVA manager is indented to help drivers implement userspace-manageable
GPU VA spaces in reference to the Vulkan API. In order to achieve this goal it
serves the following purposes in this context.

1) Provide infrastructure to track GPU VA allocations and mappings,
   making use of the maple_tree.

2) Generically connect GPU VA mappings to their backing buffers, in
   particular DRM GEM objects.

3) Provide a common implementation to perform more complex mapping
   operations on the GPU VA space. In particular splitting and merging
   of GPU VA mappings, e.g. for intersecting mapping requests or partial
   unmap requests.

The new VM_BIND Nouveau UAPI build on top of the DRM GPUVA manager, itself
providing the following new interfaces.

1) Initialize a GPU VA space via the new DRM_IOCTL_NOUVEAU_VM_INIT ioctl
   for UMDs to specify the portion of VA space managed by the kernel and
   userspace, respectively.

2) Allocate and free a VA space region as well as bind and unbind memory
   to the GPUs VA space via the new DRM_IOCTL_NOUVEAU_VM_BIND ioctl.

3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC ioctl.

Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC, make use of the DRM
scheduler to queue jobs and support asynchronous processing with DRM syncobjs
as synchronization mechanism.

By default DRM_IOCTL_NOUVEAU_VM_BIND does synchronous processing,
DRM_IOCTL_NOUVEAU_EXEC supports asynchronous processing only.

The new VM_BIND UAPI for Nouveau makes also use of drm_exec (execution context
for GEM buffers) by Christian König. Since the patch implementing drm_exec was
not yet merged into drm-next it is part of this series, as well as a small fix
for this patch, which was found while testing this series.

This patch series is also available at [1].

There is a Mesa NVK merge request by Dave Airlie [2] implementing the
corresponding userspace parts for this series.

The Vulkan CTS test suite passes the sparse binding and sparse residency test
cases for the new UAPI together with Dave's Mesa work.

There are also some test cases in the igt-gpu-tools project [3] for the new UAPI
and hence the DRM GPU VA manager. However, most of them are testing the DRM GPU
VA manager's logic through Nouveau's new UAPI and should be considered just as
helper for implementation.

However, I absolutely intend to change those test cases to proper kunit test
cases for the DRM GPUVA manager, once and if we agree on it's usefulness and
design.

[1] https://gitlab.freedesktop.org/nouvelles/kernel/-/tree/new-uapi-drm-next /
https://gitlab.freedesktop.org/nouvelles/kernel/-/merge_requests/1
[2] https://gitlab.freedesktop.org/nouveau/mesa/-/merge_requests/150/
[3] https://gitlab.freedesktop.org/dakr/igt-gpu-tools/-/tree/wip_nouveau_vm_bind

Changes in V2:
==
  Nouveau:
- Reworked the Nouveau VM_BIND UAPI to avoid memory allocations in fence
  signalling critical sections. Updates to the VA space are split up in 
three
  separate stages, where only the 2. stage executes in a fence signalling
  critical section:

1. update the VA space, allocate new structures and page tables
2. (un-)map the requested memory bindings
3. free structures and page tables

- Separated generic job scheduler code from specific job implementations.
- Separated the EXEC and VM_BIND implementation of the UAPI.
- Reworked the locking parts of the nvkm/vmm RAW interface, such that
  (un-)map operations can be executed in fence signalling critical sections.

  GPUVA Manager:
- made drm_gpuva_regions optional for users of the GPUVA manager
- allow NULL GEMs for drm_gpuva entries
- swichted from drm_mm to maple_tree for track drm_gpuva / drm_gpuva_region
  entries
- provide callbacks for users to allocate custom drm_gpuva_op structures to
  allow inheritance
- added user bits to drm_gpuva_flags
- added a prefetch operation type in order to support generating prefetch
  operations in the same way other operations generated
- hand the responsibility for mutual exclusion for a GEM's
  drm_gpuva list to the user; simplified corresponding (un-)link functions

  Maple Tree:
- I added two maple tree patches to the series, one to support custom tree
  walk macros and one to hand the locking responsibility to the user of the
  GPUVA manager without pre-defined lockdep checks.

Changes in V3:
==
  Nouveau:
- Reworked the Nouveau VM_BIND UAPI to do the job cleanup (including page
  table cleanup) within a workqueue rather than the job_free() callback of
  the sch

Re: [Intel-gfx] [PATCH v3] drm/i915/selftest/gsc: Ensure GSC Proxy init completes before selftests

[Tvrtko Ursulin]

On 29/06/2023 21:42, Alan Previn wrote:

On MTL, if the GSC Proxy init flows haven't completed, submissions to the
GSC engine will fail. Those init flows are dependent on the mei's
gsc_proxy component that is loaded in parallel with i915 and a
worker that could potentially start after i915 driver init is done.

That said, all subsytems that access the GSC engine today does check
for such init flow completion before using the GSC engine. However,
selftests currently don't wait on anything before starting.

To fix this, add a waiter function at the start of __run_selftests
that waits for gsc-proxy init flows to complete. While implementing this,
use an table of function pointers so its scalable to add additional
waiter functions for future such "wait on dependency" cases that.

Difference from prior versions:
v3: Rebase to latest drm-tip.
v2: Based on internal testing, increase the timeout for gsc-proxy
specific case to 8 seconds.

Signed-off-by: Alan Previn 
Reviewed-by: Zhanjun Dong 

---
  .../gpu/drm/i915/selftests/i915_selftest.c| 61 +++
  1 file changed, 61 insertions(+)

diff --git a/drivers/gpu/drm/i915/selftests/i915_selftest.c 
b/drivers/gpu/drm/i915/selftests/i915_selftest.c
index 39da0fb0d6d2..a74b7e264d92 100644
--- a/drivers/gpu/drm/i915/selftests/i915_selftest.c
+++ b/drivers/gpu/drm/i915/selftests/i915_selftest.c
@@ -24,6 +24,8 @@
  #include 
  
  #include "gt/intel_gt_pm.h"

+#include "gt/uc/intel_gsc_fw.h"
+
  #include "i915_driver.h"
  #include "i915_drv.h"
  #include "i915_selftest.h"
@@ -127,6 +129,63 @@ static void set_default_test_all(struct selftest *st, 
unsigned int count)
st[i].enabled = true;
  }
  
+static int

+__wait_gsc_proxy_completed(struct drm_i915_private *i915,
+  unsigned long timeout_ms)
+{
+   bool need_to_wait = (IS_ENABLED(CONFIG_INTEL_MEI_GSC_PROXY) &&
+i915->media_gt &&
+HAS_ENGINE(i915->media_gt, GSC0) &&
+
intel_uc_fw_is_loadable(&i915->media_gt->uc.gsc.fw));
+
+   /*
+* For gsc proxy component loading + init, we need a much longer timeout
+* than what CI selftest infrastrucutre currently uses. This longer wait
+* period depends on the kernel config and component driver load 
ordering
+*/


How is a CI timeout value relevant?

Plus from the commit message it sounds like the point of wait is so 
submission to gsc does not fail if loading is still in progress, not 
that the CI times out. So what is the main problem?



+   if (timeout_ms < 8000)
+   timeout_ms = 8000;
+
+   if (need_to_wait &&
+   (wait_for(intel_gsc_uc_fw_proxy_init_done(&i915->media_gt->uc.gsc, 
true),
+   timeout_ms)))
+   return -ETIME;
+
+   return 0;
+}
+
+struct __startup_waiter {
+   const char *name;
+   int (*wait_to_completed)(struct drm_i915_private *i915, unsigned long 
timeout_ms);
+};
+
+static struct __startup_waiter all_startup_waiters[] = { \
+   {"gsc_proxy", __wait_gsc_proxy_completed} \
+   };
+
+static int __wait_on_all_system_dependencies(struct drm_i915_private *i915)
+{
+   struct __startup_waiter *waiter = all_startup_waiters;
+   int count = ARRAY_SIZE(all_startup_waiters);
+   int ret;
+
+   if (!waiter || !count || !i915)
+   return 0;


Ugh.

If it ever becomes an empty array just zap this whole code and not have 
these checks.


Also, no i915 is a possibility?

But actually.. please don't add the function table generalization unless 
it is already known something else is coming to be plugged into it.



+
+   for (; count--; waiter++) {
+   if (!waiter->wait_to_completed)
+   continue;
+   ret = waiter->wait_to_completed(i915, i915_selftest.timeout_ms);
+   if (ret) {
+   pr_info(DRIVER_NAME ": Pre-selftest waiter %s failed with 
%d\n",
+   waiter->name, ret);
+   return ret;
+   }
+   }
+
+   return 0;
+}
+
  static int __run_selftests(const char *name,
   struct selftest *st,
   unsigned int count,
@@ -134,6 +193,8 @@ static int __run_selftests(const char *name,
  {
int err = 0;
  
+	__wait_on_all_system_dependencies(data);


Why does this need to be top level selftests and not just a wait for 
intel_gsc_uc_fw_proxy_init_done in the tests where it is relevant, via 
some helper or something?


Regards,

Tvrtko


+
while (!i915_selftest.random_seed)
i915_selftest.random_seed = get_random_u32();
  


base-commit: 6f8963ce33be65c67e53b16fa18325e12ab76861

ttm_bo and multiple backing store segments

[Welty, Brian]

Hi Christian / Thomas,

Wanted to ask if you have explored or thought about adding support in 
TTM such that a ttm_bo could have more than one underlying backing store 
segment (that is, to have a tree of ttm_resources)?

We are considering to support such BOs for Intel Xe driver.

Some of the benefits:
 * devices with page fault support can fault (and migrate) backing store
   at finer granularity than the entire BO
 * BOs can support having multiple backing store segments, which can be
   in different memory domains/regions
 * BO eviction could operate on smaller granularity than entire BO

Or is the thinking that workloads should use SVM/HMM instead of 
GEM_CREATE if they want above benefits?


Is this something you are open to seeing an RFC series that starts 
perhaps with just extending ttm_bo_validate() to see how this might 
shape up?


-Brian

[PATCH v3] drm/xe/guc: Fix h2g_write usage of GUC_CTB_MSG_MAX_LEN

[Alan Previn]

In the ABI header, GUC_CTB_MSG_MIN_LEN is '1' because
GUC_CTB_HDR_LEN is 1. This aligns with H2G/G2H CTB specification
where all command formats are defined in units of dwords so that '1'
is a dword. Accordingly, GUC_CTB_MSG_MAX_LEN is 256-1 (i.e. 255
dwords). However, h2g_write was incorrectly assuming that
GUC_CTB_MSG_MAX_LEN was in bytes. Fix this.

v3: Fix nit on #define location.(Matt)
v2: By correctly treating GUC_CTB_MSG_MAX_LEN as dwords, it causes
a local array to consume 4x the stack size. Rework the function
to avoid consuming stack even if the action size is large. (Matt)

Signed-off-by: Alan Previn 
Reviewed-by: Matthew Brost 

---
 drivers/gpu/drm/xe/xe_guc_ct.c | 31 ++-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_guc_ct.c b/drivers/gpu/drm/xe/xe_guc_ct.c
index 22bc9ce846db..aa04b5c4822f 100644
--- a/drivers/gpu/drm/xe/xe_guc_ct.c
+++ b/drivers/gpu/drm/xe/xe_guc_ct.c
@@ -401,19 +401,21 @@ static int h2g_write(struct xe_guc_ct *ct, const u32 
*action, u32 len,
 {
struct xe_device *xe = ct_to_xe(ct);
struct guc_ctb *h2g = &ct->ctbs.h2g;
-   u32 cmd[GUC_CTB_MSG_MAX_LEN / sizeof(u32)];
-   u32 cmd_len = len + GUC_CTB_HDR_LEN;
-   u32 cmd_idx = 0, i;
+#define H2G_CT_HEADERS (GUC_CTB_HDR_LEN + 1) /* one DW CTB header and one DW 
HxG header */
+   u32 cmd[H2G_CT_HEADERS];
u32 tail = h2g->info.tail;
+   u32 full_len;
struct iosys_map map = IOSYS_MAP_INIT_OFFSET(&h2g->cmds,
 tail * sizeof(u32));
 
+   full_len = len + GUC_CTB_HDR_LEN;
+
lockdep_assert_held(&ct->lock);
-   XE_BUG_ON(len * sizeof(u32) > GUC_CTB_MSG_MAX_LEN);
+   XE_BUG_ON(full_len > (GUC_CTB_MSG_MAX_LEN - GUC_CTB_HDR_LEN));
XE_BUG_ON(tail > h2g->info.size);
 
/* Command will wrap, zero fill (NOPs), return and check credits again 
*/
-   if (tail + cmd_len > h2g->info.size) {
+   if (tail + full_len > h2g->info.size) {
xe_map_memset(xe, &map, 0, 0,
  (h2g->info.size - tail) * sizeof(u32));
h2g_reserve_space(ct, (h2g->info.size - tail));
@@ -428,30 +430,33 @@ static int h2g_write(struct xe_guc_ct *ct, const u32 
*action, u32 len,
 * dw1: HXG header (including action code)
 * dw2+: action data
 */
-   cmd[cmd_idx++] = FIELD_PREP(GUC_CTB_MSG_0_FORMAT, GUC_CTB_FORMAT_HXG) |
+   cmd[0] = FIELD_PREP(GUC_CTB_MSG_0_FORMAT, GUC_CTB_FORMAT_HXG) |
FIELD_PREP(GUC_CTB_MSG_0_NUM_DWORDS, len) |
FIELD_PREP(GUC_CTB_MSG_0_FENCE, ct_fence_value);
if (want_response) {
-   cmd[cmd_idx++] =
+   cmd[1] =
FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
FIELD_PREP(GUC_HXG_EVENT_MSG_0_ACTION |
   GUC_HXG_EVENT_MSG_0_DATA0, action[0]);
} else {
-   cmd[cmd_idx++] =
+   cmd[1] =
FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_EVENT) |
FIELD_PREP(GUC_HXG_EVENT_MSG_0_ACTION |
   GUC_HXG_EVENT_MSG_0_DATA0, action[0]);
}
-   for (i = 1; i < len; ++i)
-   cmd[cmd_idx++] = action[i];
+
+   /* H2G header in cmd[1] replaces action[0] so: */
+   --len;
+   ++action;
 
/* Write H2G ensuring visable before descriptor update */
-   xe_map_memcpy_to(xe, &map, 0, cmd, cmd_len * sizeof(u32));
+   xe_map_memcpy_to(xe, &map, 0, cmd, H2G_CT_HEADERS * sizeof(u32));
+   xe_map_memcpy_to(xe, &map, H2G_CT_HEADERS * sizeof(u32), action, len * 
sizeof(u32));
xe_device_wmb(ct_to_xe(ct));
 
/* Update local copies */
-   h2g->info.tail = (tail + cmd_len) % h2g->info.size;
-   h2g_reserve_space(ct, cmd_len);
+   h2g->info.tail = (tail + full_len) % h2g->info.size;
+   h2g_reserve_space(ct, full_len);
 
/* Update descriptor */
desc_write(xe, h2g, tail, h2g->info.tail);

base-commit: 2ec46ad7578ebba3048d6031c1a75c21920f0e19
-- 
2.39.0

Re: [PATCH v2 2/4] regulator: Introduce Qualcomm REFGEN regulator driver

[Konrad Dybcio]

On 29.06.2023 22:35, Konrad Dybcio wrote:
> Modern Qualcomm SoCs have a REFGEN (reference voltage generator)
> regulator, providing reference voltage to on-chip IP, like PHYs.
> 
> Add a driver to support toggling that regulator.
> 
> Signed-off-by: Konrad Dybcio 
> ---
Ugh. Missed the 'const' here and below. LMK if that warrants a resend
(or.. perhaps you just have other comments)

Konrad
> + .ops = &(struct regulator_ops) {
> + .enable = qcom_sdm845_refgen_enable,
> + .disable= qcom_sdm845_refgen_disable,
> + .is_enabled = qcom_sdm845_refgen_is_enabled,
> + },
> +};
> +
> +static struct regulator_desc sm8250_refgen_desc = {
> + .enable_reg = REFGEN_REG_PWRDWN_CTRL5,
> + .enable_mask = REFGEN_PWRDWN_CTRL5_MASK,
> + .enable_val = REFGEN_PWRDWN_CTRL5_ENABLE,
> + .disable_val = 0,
> + .enable_time = 5,
> + .name = "refgen",
> + .owner = THIS_MODULE,
> + .type = REGULATOR_VOLTAGE,
> + .ops = &(struct regulator_ops) {
> + .enable = regulator_enable_regmap,
> + .disable= regulator_disable_regmap,
> + .is_enabled = regulator_is_enabled_regmap,
> + },
> +};
> +
> +static const struct regmap_config qcom_refgen_regmap_config = {
> + .reg_bits = 32,
> + .reg_stride = 4,
> + .val_bits = 32,
> + .fast_io = true,
> +};
> +
> +static int qcom_refgen_probe(struct platform_device *pdev)
> +{
> + struct regulator_init_data *init_data;
> + struct regulator_config config = {};
> + const struct regulator_desc *rdesc;
> + struct device *dev = &pdev->dev;
> + struct regulator_dev *rdev;
> + struct regmap *regmap;
> + void __iomem *base;
> +
> + rdesc = of_device_get_match_data(dev);
> + if (!rdesc)
> + return -ENODATA;
> +
> + base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
> +
> + regmap = devm_regmap_init_mmio(dev, base, &qcom_refgen_regmap_config);
> + if (IS_ERR(regmap))
> + return PTR_ERR(regmap);
> +
> + init_data = of_get_regulator_init_data(dev, dev->of_node, rdesc);
> + if (!init_data)
> + return -ENOMEM;
> +
> + config.dev = dev;
> + config.init_data = init_data;
> + config.of_node = dev->of_node;
> + config.regmap = regmap;
> +
> + rdev = devm_regulator_register(dev, rdesc, &config);
> + if (IS_ERR(rdev))
> + return PTR_ERR(rdev);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id qcom_refgen_match_table[] = {
> + { .compatible = "qcom,sdm845-refgen-regulator", .data = 
> &sdm845_refgen_desc },
> + { .compatible = "qcom,sm8250-refgen-regulator", .data = 
> &sm8250_refgen_desc },
> + { }
> +};
> +
> +static struct platform_driver qcom_refgen_driver = {
> + .probe = qcom_refgen_probe,
> + .driver = {
> + .name = "qcom-refgen-regulator",
> + .of_match_table = qcom_refgen_match_table,
> + },
> +};
> +module_platform_driver(qcom_refgen_driver);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("Qualcomm REFGEN regulator driver");
> 

[PATCH v3] drm/i915/selftest/gsc: Ensure GSC Proxy init completes before selftests

[Alan Previn]

On MTL, if the GSC Proxy init flows haven't completed, submissions to the
GSC engine will fail. Those init flows are dependent on the mei's
gsc_proxy component that is loaded in parallel with i915 and a
worker that could potentially start after i915 driver init is done.

That said, all subsytems that access the GSC engine today does check
for such init flow completion before using the GSC engine. However,
selftests currently don't wait on anything before starting.

To fix this, add a waiter function at the start of __run_selftests
that waits for gsc-proxy init flows to complete. While implementing this,
use an table of function pointers so its scalable to add additional
waiter functions for future such "wait on dependency" cases that.

Difference from prior versions:
   v3: Rebase to latest drm-tip.
   v2: Based on internal testing, increase the timeout for gsc-proxy
   specific case to 8 seconds.

Signed-off-by: Alan Previn 
Reviewed-by: Zhanjun Dong 

---
 .../gpu/drm/i915/selftests/i915_selftest.c| 61 +++
 1 file changed, 61 insertions(+)

diff --git a/drivers/gpu/drm/i915/selftests/i915_selftest.c 
b/drivers/gpu/drm/i915/selftests/i915_selftest.c
index 39da0fb0d6d2..a74b7e264d92 100644
--- a/drivers/gpu/drm/i915/selftests/i915_selftest.c
+++ b/drivers/gpu/drm/i915/selftests/i915_selftest.c
@@ -24,6 +24,8 @@
 #include 
 
 #include "gt/intel_gt_pm.h"
+#include "gt/uc/intel_gsc_fw.h"
+
 #include "i915_driver.h"
 #include "i915_drv.h"
 #include "i915_selftest.h"
@@ -127,6 +129,63 @@ static void set_default_test_all(struct selftest *st, 
unsigned int count)
st[i].enabled = true;
 }
 
+static int
+__wait_gsc_proxy_completed(struct drm_i915_private *i915,
+  unsigned long timeout_ms)
+{
+   bool need_to_wait = (IS_ENABLED(CONFIG_INTEL_MEI_GSC_PROXY) &&
+i915->media_gt &&
+HAS_ENGINE(i915->media_gt, GSC0) &&
+
intel_uc_fw_is_loadable(&i915->media_gt->uc.gsc.fw));
+
+   /*
+* For gsc proxy component loading + init, we need a much longer timeout
+* than what CI selftest infrastrucutre currently uses. This longer wait
+* period depends on the kernel config and component driver load 
ordering
+*/
+   if (timeout_ms < 8000)
+   timeout_ms = 8000;
+
+   if (need_to_wait &&
+   (wait_for(intel_gsc_uc_fw_proxy_init_done(&i915->media_gt->uc.gsc, 
true),
+   timeout_ms)))
+   return -ETIME;
+
+   return 0;
+}
+
+struct __startup_waiter {
+   const char *name;
+   int (*wait_to_completed)(struct drm_i915_private *i915, unsigned long 
timeout_ms);
+};
+
+static struct __startup_waiter all_startup_waiters[] = { \
+   {"gsc_proxy", __wait_gsc_proxy_completed} \
+   };
+
+static int __wait_on_all_system_dependencies(struct drm_i915_private *i915)
+{
+   struct __startup_waiter *waiter = all_startup_waiters;
+   int count = ARRAY_SIZE(all_startup_waiters);
+   int ret;
+
+   if (!waiter || !count || !i915)
+   return 0;
+
+   for (; count--; waiter++) {
+   if (!waiter->wait_to_completed)
+   continue;
+   ret = waiter->wait_to_completed(i915, i915_selftest.timeout_ms);
+   if (ret) {
+   pr_info(DRIVER_NAME ": Pre-selftest waiter %s failed 
with %d\n",
+   waiter->name, ret);
+   return ret;
+   }
+   }
+
+   return 0;
+}
+
 static int __run_selftests(const char *name,
   struct selftest *st,
   unsigned int count,
@@ -134,6 +193,8 @@ static int __run_selftests(const char *name,
 {
int err = 0;
 
+   __wait_on_all_system_dependencies(data);
+
while (!i915_selftest.random_seed)
i915_selftest.random_seed = get_random_u32();
 

base-commit: 6f8963ce33be65c67e53b16fa18325e12ab76861
-- 
2.39.0

[PATCH v2 2/4] regulator: Introduce Qualcomm REFGEN regulator driver

[Konrad Dybcio]

Modern Qualcomm SoCs have a REFGEN (reference voltage generator)
regulator, providing reference voltage to on-chip IP, like PHYs.

Add a driver to support toggling that regulator.

Signed-off-by: Konrad Dybcio 
---
 drivers/regulator/Kconfig |  10 ++
 drivers/regulator/Makefile|   1 +
 drivers/regulator/qcom-refgen-regulator.c | 154 ++
 3 files changed, 165 insertions(+)

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 2c2405024ace..ea5549d62825 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -978,6 +978,16 @@ config REGULATOR_PWM
  This driver supports PWM controlled voltage regulators. PWM
  duty cycle can increase or decrease the voltage.
 
+config REGULATOR_QCOM_REFGEN
+   tristate "Qualcomm REFGEN regulator driver"
+   depends on REGMAP
+   help
+ This driver supports the MMIO-mapped reference voltage regulator,
+ used internally by some PHYs on many Qualcomm SoCs.
+
+ Say M here if you want to include support for this regulator as
+ a module. The module will be named "qcom-refgen-regulator".
+
 config REGULATOR_QCOM_RPM
tristate "Qualcomm RPM regulator driver"
depends on MFD_QCOM_RPM
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index ebfa75379c20..a044ad20e202 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -107,6 +107,7 @@ obj-$(CONFIG_REGULATOR_MT6380)  += mt6380-regulator.o
 obj-$(CONFIG_REGULATOR_MT6397) += mt6397-regulator.o
 obj-$(CONFIG_REGULATOR_MTK_DVFSRC) += mtk-dvfsrc-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_LABIBB) += qcom-labibb-regulator.o
+obj-$(CONFIG_REGULATOR_QCOM_REFGEN) += qcom-refgen-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_RPMH) += qcom-rpmh-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
diff --git a/drivers/regulator/qcom-refgen-regulator.c 
b/drivers/regulator/qcom-refgen-regulator.c
new file mode 100644
index ..4c442fa3f552
--- /dev/null
+++ b/drivers/regulator/qcom-refgen-regulator.c
@@ -0,0 +1,154 @@
+// SPDX-License-Identifier: GPL-2.0-only
+// Copyright (c) 2017, 2019-2020, The Linux Foundation. All rights reserved.
+// Copyright (c) 2023, Linaro Limited
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REFGEN_REG_BIAS_EN 0x08
+#define REFGEN_BIAS_EN_MASKGENMASK(2, 0)
+ #define REFGEN_BIAS_EN_ENABLE 0x7
+ #define REFGEN_BIAS_EN_DISABLE0x6
+
+#define REFGEN_REG_BG_CTRL 0x14
+#define REFGEN_BG_CTRL_MASKGENMASK(2, 1)
+ #define REFGEN_BG_CTRL_ENABLE 0x3
+ #define REFGEN_BG_CTRL_DISABLE0x2
+
+#define REFGEN_REG_PWRDWN_CTRL50x80
+#define REFGEN_PWRDWN_CTRL5_MASK   BIT(0)
+ #define REFGEN_PWRDWN_CTRL5_ENABLE0x1
+
+static int qcom_sdm845_refgen_enable(struct regulator_dev *rdev)
+{
+   regmap_update_bits(rdev->regmap, REFGEN_REG_BG_CTRL, 
REFGEN_BG_CTRL_MASK,
+  FIELD_PREP(REFGEN_BG_CTRL_MASK, 
REFGEN_BG_CTRL_ENABLE));
+
+   regmap_write(rdev->regmap, REFGEN_REG_BIAS_EN,
+FIELD_PREP(REFGEN_BIAS_EN_MASK, REFGEN_BIAS_EN_ENABLE));
+
+   return 0;
+}
+
+static int qcom_sdm845_refgen_disable(struct regulator_dev *rdev)
+{
+   regmap_write(rdev->regmap, REFGEN_REG_BIAS_EN,
+FIELD_PREP(REFGEN_BIAS_EN_MASK, REFGEN_BIAS_EN_DISABLE));
+
+   regmap_update_bits(rdev->regmap, REFGEN_REG_BG_CTRL, 
REFGEN_BG_CTRL_MASK,
+  FIELD_PREP(REFGEN_BG_CTRL_MASK, 
REFGEN_BG_CTRL_DISABLE));
+
+   return 0;
+}
+
+static int qcom_sdm845_refgen_is_enabled(struct regulator_dev *rdev)
+{
+   u32 val;
+
+   regmap_read(rdev->regmap, REFGEN_REG_BG_CTRL, &val);
+   if (FIELD_GET(REFGEN_BG_CTRL_MASK, val) != REFGEN_BG_CTRL_ENABLE)
+   return 0;
+
+   regmap_read(rdev->regmap, REFGEN_REG_BIAS_EN, &val);
+   if (FIELD_GET(REFGEN_BIAS_EN_MASK, val) != REFGEN_BIAS_EN_ENABLE)
+   return 0;
+
+   return 1;
+}
+
+static struct regulator_desc sdm845_refgen_desc = {
+   .enable_time = 5,
+   .name = "refgen",
+   .owner = THIS_MODULE,
+   .type = REGULATOR_VOLTAGE,
+   .ops = &(struct regulator_ops) {
+   .enable = qcom_sdm845_refgen_enable,
+   .disable= qcom_sdm845_refgen_disable,
+   .is_enabled = qcom_sdm845_refgen_is_enabled,
+   },
+};
+
+static struct regulator_desc sm8250_refgen_desc = {
+   .enable_reg = REFGEN_REG_PWRDWN_CTRL5,
+   .enable_mask = REFGEN_PWRDWN_CTRL5_MASK,
+   .enable_val = REFGEN_PWRDWN_CTRL5_ENABLE,
+   .disable_val = 0,
+   .enable_time = 5,
+   .name = "refgen",
+   .owner = THIS_MODULE,
+   .type = REGULATOR_VOLTAGE,
+  

[PATCH v2 4/4] drm/msm/dsi: Hook up refgen regulator

[Konrad Dybcio]

Consume the refgen supply on configurations that may use it.

Signed-off-by: Konrad Dybcio 
---
 drivers/gpu/drm/msm/dsi/dsi_cfg.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c 
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 8a5fb6df7210..1f98ff74ceb0 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -160,6 +160,7 @@ static const char * const dsi_v2_4_clk_names[] = {
 
 static const struct regulator_bulk_data dsi_v2_4_regulators[] = {
{ .supply = "vdda", .init_load_uA = 21800 },/* 1.2 V */
+   { .supply = "refgen" },
 };
 
 static const struct msm_dsi_config sdm845_dsi_cfg = {
@@ -191,6 +192,7 @@ static const struct msm_dsi_config sm8550_dsi_cfg = {
 
 static const struct regulator_bulk_data sc7280_dsi_regulators[] = {
{ .supply = "vdda", .init_load_uA = 8350 }, /* 1.2 V */
+   { .supply = "refgen" },
 };
 
 static const struct msm_dsi_config sc7280_dsi_cfg = {

-- 
2.41.0

[PATCH v2 3/4] dt-bindings: display/msm: dsi-controller-main: Allow refgen-supply

[Konrad Dybcio]

DSI host needs REFGEN to be enabled (if it's present on a given platform).
Allow consuming it.

Acked-by: Rob Herring 
Signed-off-by: Konrad Dybcio 
---
 .../devicetree/bindings/display/msm/dsi-controller-main.yaml  | 4 
 1 file changed, 4 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml 
b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
index 01848bdd5873..76270992305a 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
@@ -166,6 +166,10 @@ properties:
 description:
   Phandle to vdd regulator device node
 
+  refgen-supply:
+description:
+  Phandle to REFGEN regulator device node
+
   vcca-supply:
 description:
   Phandle to vdd regulator device node

-- 
2.41.0

[PATCH v2 1/4] dt-bindings: regulator: Describe Qualcomm REFGEN regulator

[Konrad Dybcio]

Modern Qualcomm SoCs have a REFGEN (reference voltage generator)
regulator, providing reference voltage to on-chip IP, like PHYs.
It's controlled through MMIO and we can toggle it or read its state back.

Describe it.

Signed-off-by: Konrad Dybcio 
---
 .../regulator/qcom,sdm845-refgen-regulator.yaml| 57 ++
 1 file changed, 57 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/regulator/qcom,sdm845-refgen-regulator.yaml 
b/Documentation/devicetree/bindings/regulator/qcom,sdm845-refgen-regulator.yaml
new file mode 100644
index ..f02f97d4fdd2
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/regulator/qcom,sdm845-refgen-regulator.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/qcom,sdm845-refgen-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. REFGEN Regulator
+
+maintainers:
+  - Konrad Dybcio 
+
+description:
+  The REFGEN (reference voltage generator) regulator provides reference
+  voltage for on-chip IPs (like PHYs) on some Qualcomm SoCs.
+
+allOf:
+  - $ref: regulator.yaml#
+
+properties:
+  compatible:
+oneOf:
+  - items:
+  - enum:
+  - qcom,sc7180-refgen-regulator
+  - qcom,sc8180x-refgen-regulator
+  - qcom,sm8150-refgen-regulator
+  - const: qcom,sdm845-refgen-regulator
+
+  - items:
+  - enum:
+  - qcom,sc7280-refgen-regulator
+  - qcom,sc8280xp-refgen-regulator
+  - qcom,sm6350-refgen-regulator
+  - qcom,sm6375-refgen-regulator
+  - qcom,sm8350-refgen-regulator
+  - const: qcom,sm8250-refgen-regulator
+
+  - enum:
+  - qcom,sdm845-refgen-regulator
+  - qcom,sm8250-refgen-regulator
+
+  reg:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+
+unevaluatedProperties: false
+
+examples:
+  - |
+regulator@162f000 {
+  compatible = "qcom,sm8250-refgen-regulator";
+  reg = <0x0162f000 0x84>;
+};
+...

-- 
2.41.0

[PATCH v2 0/4] Qualcomm REFGEN regulator

[Konrad Dybcio]

Recent Qualcomm SoCs have a REFGEN (reference voltage generator) regulator
responsible for providing a reference voltage to some on-SoC IPs (like DSI
or PHYs). It can be turned off when unused to save power.

This series introduces the driver for it and lets the DSI driver
consume it.

Signed-off-by: Konrad Dybcio 
---
Changes in v2:
- Remove "|" from bindings description
- fix 'renegator' typo
- define number of 'reg'
- adjust reg= to size/address-cells = 1
- fix regmap usage
- use C++ comments for the header
- remove now-unused struct qcom_refgen
- use common helpers for sm8250 refgen (simple bit ops)
- add missing FIELD_PREPs (small brain forgot regmap_update_bits
  doesn't do shifting)
- pick up tags
- Link to v1: 
https://lore.kernel.org/r/20230628-topic-refgen-v1-0-126e59573...@linaro.org

---
Konrad Dybcio (4):
  dt-bindings: regulator: Describe Qualcomm REFGEN regulator
  regulator: Introduce Qualcomm REFGEN regulator driver
  dt-bindings: display/msm: dsi-controller-main: Allow refgen-supply
  drm/msm/dsi: Hook up refgen regulator

 .../bindings/display/msm/dsi-controller-main.yaml  |   4 +
 .../regulator/qcom,sdm845-refgen-regulator.yaml|  57 
 drivers/gpu/drm/msm/dsi/dsi_cfg.c  |   2 +
 drivers/regulator/Kconfig  |  10 ++
 drivers/regulator/Makefile |   1 +
 drivers/regulator/qcom-refgen-regulator.c  | 154 +
 6 files changed, 228 insertions(+)
---
base-commit: 5c875096d59010cee4e00da1f9c7bdb07a025dc2
change-id: 20230628-topic-refgen-14fb0b762115

Best regards,
-- 
Konrad Dybcio 

Re: [PATCH v2 13/15] arm64: dts: qcom: sm6125: Add dispcc node

[Konrad Dybcio]

On 29.06.2023 14:24, Dmitry Baryshkov wrote:
> On Thu, 29 Jun 2023 at 15:14, Marijn Suijten
>  wrote:
>>
>> On 2023-06-29 13:56:25, Dmitry Baryshkov wrote:
>>> On 27/06/2023 23:14, Marijn Suijten wrote:
 Enable and configure the dispcc node on SM6125 for consumption by MDSS
 later on.

 Signed-off-by: Marijn Suijten 
 ---
   arch/arm64/boot/dts/qcom/sm6125.dtsi | 25 +
   1 file changed, 25 insertions(+)

 diff --git a/arch/arm64/boot/dts/qcom/sm6125.dtsi 
 b/arch/arm64/boot/dts/qcom/sm6125.dtsi
 index edb03508dba3..a5cc0d43d2d9 100644
 --- a/arch/arm64/boot/dts/qcom/sm6125.dtsi
 +++ b/arch/arm64/boot/dts/qcom/sm6125.dtsi
 @@ -3,6 +3,7 @@
* Copyright (c) 2021, Martin Botka 
*/

 +#include 
   #include 
   #include 
   #include 
 @@ -1203,6 +1204,30 @@ sram@469 {
 reg = <0x0469 0x1>;
 };

 +   dispcc: clock-controller@5f0 {
 +   compatible = "qcom,sm6125-dispcc";
 +   reg = <0x05f0 0x2>;
 +   clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
 +<0>,
 +<0>,
 +<0>,
 +<0>,
 +<0>,
 +<&gcc GCC_DISP_AHB_CLK>,
 +<&gcc GCC_DISP_GPLL0_DIV_CLK_SRC>;
 +   clock-names = "bi_tcxo",
 + "dsi0_phy_pll_out_byteclk",
 + "dsi0_phy_pll_out_dsiclk",
 + "dsi1_phy_pll_out_dsiclk",
 + "dp_phy_pll_link_clk",
 + "dp_phy_pll_vco_div_clk",
 + "cfg_ahb_clk",
 + "gcc_disp_gpll0_div_clk_src";
 +   power-domains = <&rpmpd SM6125_VDDCX>;
>>>
>>> Would it be logical to specify the required-opps too?
>>
>> Perhaps, but barely any other SoC aside from sm8x50 sets it on dispcc.
>> What should it be, rpmhpd_opp_low_svs?  IIRC we used "svs" for the DSI
>> PHY despite not having a reference value downstream (it sets a range of
>> NOM-TURBO_NO_CPR, and RETENTION when it's off).
> 
> Then for DSI PHY the required-opps should be rpmpd_opp_nom.
Yes

> 
> For the dispcc I think the rpmpd_opp_ret, the lowest possible vote,
> should be enough.
I'm not 100% sure but not specifying an opp and turning on the domain
***probably*** just sticks with the lowest vote

Konrad
> 
>>
>> - Marijn
>>
>>>
 +   #clock-cells = <1>;
 +   #power-domain-cells = <1>;
 +   };
 +
 apps_smmu: iommu@c60 {
 compatible = "qcom,sm6125-smmu-500", "qcom,smmu-500", 
 "arm,mmu-500";
 reg = <0x0c60 0x8>;

>>>
>>> --
>>> With best wishes
>>> Dmitry
>>>
> 
> 
> 

[PATCH v3 3/3] drm/msm/dpu: drop DPU_INTF_DATA_COMPRESS from dpu catalog

[Abhinav Kumar]

Now that all usages of DPU_INTF_DATA_COMPRESS have been replaced
with the dpu core's major revision lets drop DPU_INTF_DATA_COMPRESS
from the catalog completely.

Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 --
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 0de507d4d7b7..35994e676450 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -105,7 +105,7 @@
 BIT(DPU_INTF_STATUS_SUPPORTED) | \
 BIT(DPU_DATA_HCTL_EN))
 
-#define INTF_SC7280_MASK (INTF_SC7180_MASK | BIT(DPU_INTF_DATA_COMPRESS))
+#define INTF_SC7280_MASK (INTF_SC7180_MASK)
 
 #define WB_SM8250_MASK (BIT(DPU_WB_LINE_MODE) | \
 BIT(DPU_WB_UBWC) | \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 8b900be3ea90..572e618150b8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -181,7 +181,6 @@ enum {
  * @DPU_DATA_HCTL_ENAllows data to be transferred at different 
rate
  *  than video timing
  * @DPU_INTF_STATUS_SUPPORTED   INTF block has INTF_STATUS register
- * @DPU_INTF_DATA_COMPRESS  INTF block has DATA_COMPRESS register
  * @DPU_INTF_MAX
  */
 enum {
@@ -189,7 +188,6 @@ enum {
DPU_INTF_TE,
DPU_DATA_HCTL_EN,
DPU_INTF_STATUS_SUPPORTED,
-   DPU_INTF_DATA_COMPRESS,
DPU_INTF_MAX
 };
 
-- 
2.40.1

[PATCH v3 1/3] drm/msm/dpu: re-introduce dpu core revision to the catalog

[Abhinav Kumar]

With [1] dpu core revision was dropped in favor of using the
compatible string from the device tree to select the dpu catalog
being used in the device.

This approach works well however also necessitates adding catalog
entries for small register level details as dpu capabilities and/or
features bloating the catalog unnecessarily. Examples include but
are not limited to data_compress, interrupt register set, widebus etc.

Introduce the dpu core revision back as an entry to the catalog so that
we can just use dpu revision checks and enable those bits which
should be enabled unconditionally and not controlled by a catalog
and also simplify the changes to do something like:

if (dpu_core_revision > x && dpu_core_revision < x)
   enable the bit;

Since dpu's major and minor versions are now separate fields, lets
drop all the DPU_HW_VER macros.

[1]: https://patchwork.freedesktop.org/patch/530891/?series=113910&rev=4

changes in v3:
- drop DPU step version as features are not changing across steps
- add core_major_version / core_minor_version to avoid conflicts
- update the commit text to drop references to the dpu macros

Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h  | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h  | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_3_sm6115.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h  | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h   | 8 ++--
 16 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
index 7d0d0e74c3b0..a5d486783c3f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
@@ -190,6 +190,8 @@ static const struct dpu_perf_cfg msm8998_perf_data = {
 };
 
 const struct dpu_mdss_cfg dpu_msm8998_cfg = {
+   .core_major_version = 0x3,
+   .core_minor_version = 0x0,
.caps = &msm8998_dpu_caps,
.ubwc = &msm8998_ubwc_cfg,
.mdp_count = ARRAY_SIZE(msm8998_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
index b6098141bb9b..1fdb89a4b7a6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
@@ -194,6 +194,8 @@ static const struct dpu_perf_cfg sdm845_perf_data = {
 };
 
 const struct dpu_mdss_cfg dpu_sdm845_cfg = {
+   .core_major_version = 0x4,
+   .core_minor_version = 0x0,
.caps = &sdm845_dpu_caps,
.ubwc = &sdm845_ubwc_cfg,
.mdp_count = ARRAY_SIZE(sdm845_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
index b5f751354267..129c62cf450d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
@@ -208,6 +208,8 @@ static const struct dpu_perf_cfg sm8150_perf_data = {
 };
 
 const struct dpu_mdss_cfg dpu_sm8150_cfg = {
+   .core_major_version = 0x5,
+   .core_minor_version = 0x0,
.caps = &sm8150_dpu_caps,
.ubwc = &sm8150_ubwc_cfg,
.mdp_count = ARRAY_SIZE(sm8150_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
index 8ed2b263c5ea..ca037b070f44 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
@@ -214,6 +214,8 @@ static const struct dpu_perf_cfg sc8180x_perf_data = {
 };
 
 const struct dpu_mdss_cfg dpu_sc8180x_cfg = {
+   .core_major_version = 0x5,
+   .core_minor_version = 0x1,
.caps = &sc8180x_dpu_caps,
.ubwc = &sc8180x_ubwc_cfg,
.mdp_count = ARRAY_SIZE(sc8180x_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
index daebd2170041..e446af90767e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
@@ -2

[PATCH v3 2/3] drm/msm/dpu: use dpu core's major version to enable data compress

[Abhinav Kumar]

Instead of using a feature bit to decide whether to enable data
compress or not for DSC use-cases, use dpu core's major version instead.
This will avoid defining feature bits for every bit level details of
registers.

Also, rename the intf's enable_compression() op to program_datapath()
and allow it to accept a struct intf_dpu_datapath_cfg to program
all the bits at once. This can be re-used by widebus later on as
well as it touches the same register.

Signed-off-by: Abhinav Kumar 
---
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c |  9 +++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c  |  9 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h  | 16 ++--
 3 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index b856c6286c85..f4e15b4c4cc9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -50,6 +50,7 @@ static void _dpu_encoder_phys_cmd_update_intf_cfg(
to_dpu_encoder_phys_cmd(phys_enc);
struct dpu_hw_ctl *ctl;
struct dpu_hw_intf_cfg intf_cfg = { 0 };
+   struct dpu_kms *dpu_kms = phys_enc->dpu_kms;
 
ctl = phys_enc->hw_ctl;
if (!ctl->ops.setup_intf_cfg)
@@ -68,8 +69,12 @@ static void _dpu_encoder_phys_cmd_update_intf_cfg(
phys_enc->hw_intf,
phys_enc->hw_pp->idx);
 
-   if (intf_cfg.dsc != 0 && phys_enc->hw_intf->ops.enable_compression)
-   phys_enc->hw_intf->ops.enable_compression(phys_enc->hw_intf);
+   if (intf_cfg.dsc != 0 && dpu_kms->catalog->core_major_version >= 0x7) {
+   struct intf_dpu_datapath_cfg datapath_cfg = { 0 };
+
+   datapath_cfg.data_compress = true;
+   phys_enc->hw_intf->ops.program_datapath(phys_enc->hw_intf, 
&datapath_cfg);
+   }
 }
 
 static void dpu_encoder_phys_cmd_pp_tx_done_irq(void *arg, int irq_idx)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index 5b0f6627e29b..85333df08fbc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -513,11 +513,13 @@ static void dpu_hw_intf_disable_autorefresh(struct 
dpu_hw_intf *intf,
 
 }
 
-static void dpu_hw_intf_enable_compression(struct dpu_hw_intf *ctx)
+static void dpu_hw_intf_program_datapath(struct dpu_hw_intf *ctx,
+struct intf_dpu_datapath_cfg 
*datapath_cfg)
 {
u32 intf_cfg2 = DPU_REG_READ(&ctx->hw, INTF_CONFIG2);
 
-   intf_cfg2 |= INTF_CFG2_DCE_DATA_COMPRESS;
+   if (datapath_cfg->data_compress)
+   intf_cfg2 |= INTF_CFG2_DCE_DATA_COMPRESS;
 
DPU_REG_WRITE(&ctx->hw, INTF_CONFIG2, intf_cfg2);
 }
@@ -543,8 +545,7 @@ static void _setup_intf_ops(struct dpu_hw_intf_ops *ops,
ops->disable_autorefresh = dpu_hw_intf_disable_autorefresh;
}
 
-   if (cap & BIT(DPU_INTF_DATA_COMPRESS))
-   ops->enable_compression = dpu_hw_intf_enable_compression;
+   ops->program_datapath = dpu_hw_intf_program_datapath;
 }
 
 struct dpu_hw_intf *dpu_hw_intf_init(const struct dpu_intf_cfg *cfg,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
index 99e21c4137f9..f736dca38463 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
@@ -48,6 +48,11 @@ struct intf_status {
u32 line_count; /* current line count including blanking */
 };
 
+struct intf_dpu_datapath_cfg {
+   u8 data_compress;   /* enable data compress between dpu and dsi */
+   /* can be expanded for other programmable bits */
+};
+
 /**
  * struct dpu_hw_intf_ops : Interface to the interface Hw driver functions
  *  Assumption is these functions will be called after clocks are enabled
@@ -70,7 +75,7 @@ struct intf_status {
  * @get_autorefresh:Retrieve autorefresh config from hardware
  *  Return: 0 on success, -ETIMEDOUT on timeout
  * @vsync_sel:  Select vsync signal for tear-effect 
configuration
- * @enable_compression: Enable data compression
+ * @program_datapath:   Program the DPU to interface datapath for 
relevant chipsets
  */
 struct dpu_hw_intf_ops {
void (*setup_timing_gen)(struct dpu_hw_intf *intf,
@@ -108,7 +113,14 @@ struct dpu_hw_intf_ops {
 */
void (*disable_autorefresh)(struct dpu_hw_intf *intf, uint32_t 
encoder_id, u16 vdisplay);
 
-   void (*enable_compression)(struct dpu_hw_intf *intf);
+   /**
+* Program the DPU to intf datapath by specifying
+* which of the settings need to be programmed for
+* use-cases which need DPU-intf handshake such as
+* widebus, compression etc.
+

[PATCH v2 1/3] drm/msm/dpu: re-introduce dpu core revision to the catalog

[Abhinav Kumar]

With [1] dpu core revision was dropped in favor of using the
compatible string from the device tree to select the dpu catalog
being used in the device.

This approach works well however also necessitates adding catalog
entries for small register level details as dpu capabilities and/or
features bloating the catalog unnecessarily. Examples include but
are not limited to data_compress, interrupt register set, widebus etc.

Introduce the dpu core revision back as an entry to the catalog so that
we can just use dpu revision checks and enable those bits which
should be enabled unconditionally and not controlled by a catalog
and also simplify the changes to do something like:

if (dpu_core_revision > x && dpu_core_revision < x)
   enable the bit;

Also, add some of the useful macros back to be able to use dpu core
revision effectively.

[1]: https://patchwork.freedesktop.org/patch/530891/?series=113910&rev=4

changes in v2:
- drop DPU step version as features are not changing across steps
- add core_major_version / core_minor_version to avoid conflicts

Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h  | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h  | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_3_sm6115.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h  | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h   | 8 ++--
 16 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
index 7d0d0e74c3b0..a5d486783c3f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
@@ -190,6 +190,8 @@ static const struct dpu_perf_cfg msm8998_perf_data = {
 };
 
 const struct dpu_mdss_cfg dpu_msm8998_cfg = {
+   .core_major_version = 0x3,
+   .core_minor_version = 0x0,
.caps = &msm8998_dpu_caps,
.ubwc = &msm8998_ubwc_cfg,
.mdp_count = ARRAY_SIZE(msm8998_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
index b6098141bb9b..1fdb89a4b7a6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
@@ -194,6 +194,8 @@ static const struct dpu_perf_cfg sdm845_perf_data = {
 };
 
 const struct dpu_mdss_cfg dpu_sdm845_cfg = {
+   .core_major_version = 0x4,
+   .core_minor_version = 0x0,
.caps = &sdm845_dpu_caps,
.ubwc = &sdm845_ubwc_cfg,
.mdp_count = ARRAY_SIZE(sdm845_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
index b5f751354267..129c62cf450d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
@@ -208,6 +208,8 @@ static const struct dpu_perf_cfg sm8150_perf_data = {
 };
 
 const struct dpu_mdss_cfg dpu_sm8150_cfg = {
+   .core_major_version = 0x5,
+   .core_minor_version = 0x0,
.caps = &sm8150_dpu_caps,
.ubwc = &sm8150_ubwc_cfg,
.mdp_count = ARRAY_SIZE(sm8150_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
index 8ed2b263c5ea..ca037b070f44 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
@@ -214,6 +214,8 @@ static const struct dpu_perf_cfg sc8180x_perf_data = {
 };
 
 const struct dpu_mdss_cfg dpu_sc8180x_cfg = {
+   .core_major_version = 0x5,
+   .core_minor_version = 0x1,
.caps = &sc8180x_dpu_caps,
.ubwc = &sc8180x_ubwc_cfg,
.mdp_count = ARRAY_SIZE(sc8180x_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
index daebd2170041..e446af90767e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
@@ -214,6 +214,8 @@ static const struct dpu_perf_cfg sm8250_perf_data = {
 };
 
 con

[PATCH v2 3/3] drm/msm/dpu: drop DPU_INTF_DATA_COMPRESS from dpu catalog

[Abhinav Kumar]

Now that all usages of DPU_INTF_DATA_COMPRESS have been replaced
with the dpu core's major revision lets drop DPU_INTF_DATA_COMPRESS
from the catalog completely.

Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 --
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 0de507d4d7b7..35994e676450 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -105,7 +105,7 @@
 BIT(DPU_INTF_STATUS_SUPPORTED) | \
 BIT(DPU_DATA_HCTL_EN))
 
-#define INTF_SC7280_MASK (INTF_SC7180_MASK | BIT(DPU_INTF_DATA_COMPRESS))
+#define INTF_SC7280_MASK (INTF_SC7180_MASK)
 
 #define WB_SM8250_MASK (BIT(DPU_WB_LINE_MODE) | \
 BIT(DPU_WB_UBWC) | \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 8b900be3ea90..572e618150b8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -181,7 +181,6 @@ enum {
  * @DPU_DATA_HCTL_ENAllows data to be transferred at different 
rate
  *  than video timing
  * @DPU_INTF_STATUS_SUPPORTED   INTF block has INTF_STATUS register
- * @DPU_INTF_DATA_COMPRESS  INTF block has DATA_COMPRESS register
  * @DPU_INTF_MAX
  */
 enum {
@@ -189,7 +188,6 @@ enum {
DPU_INTF_TE,
DPU_DATA_HCTL_EN,
DPU_INTF_STATUS_SUPPORTED,
-   DPU_INTF_DATA_COMPRESS,
DPU_INTF_MAX
 };
 
-- 
2.40.1

[PATCH v2 2/3] drm/msm/dpu: use dpu core's major version to enable data compress

[Abhinav Kumar]

Instead of using a feature bit to decide whether to enable data
compress or not for DSC use-cases, use dpu core's major version instead.
This will avoid defining feature bits for every bit level details of
registers.

Also, rename the intf's enable_compression() op to program_datapath()
and allow it to accept a struct intf_dpu_datapath_cfg to program
all the bits at once. This can be re-used by widebus later on as
well as it touches the same register.

Signed-off-by: Abhinav Kumar 
---
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c |  9 +++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c  |  9 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h  | 16 ++--
 3 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index b856c6286c85..f4e15b4c4cc9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -50,6 +50,7 @@ static void _dpu_encoder_phys_cmd_update_intf_cfg(
to_dpu_encoder_phys_cmd(phys_enc);
struct dpu_hw_ctl *ctl;
struct dpu_hw_intf_cfg intf_cfg = { 0 };
+   struct dpu_kms *dpu_kms = phys_enc->dpu_kms;
 
ctl = phys_enc->hw_ctl;
if (!ctl->ops.setup_intf_cfg)
@@ -68,8 +69,12 @@ static void _dpu_encoder_phys_cmd_update_intf_cfg(
phys_enc->hw_intf,
phys_enc->hw_pp->idx);
 
-   if (intf_cfg.dsc != 0 && phys_enc->hw_intf->ops.enable_compression)
-   phys_enc->hw_intf->ops.enable_compression(phys_enc->hw_intf);
+   if (intf_cfg.dsc != 0 && dpu_kms->catalog->core_major_version >= 0x7) {
+   struct intf_dpu_datapath_cfg datapath_cfg = { 0 };
+
+   datapath_cfg.data_compress = true;
+   phys_enc->hw_intf->ops.program_datapath(phys_enc->hw_intf, 
&datapath_cfg);
+   }
 }
 
 static void dpu_encoder_phys_cmd_pp_tx_done_irq(void *arg, int irq_idx)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index 5b0f6627e29b..85333df08fbc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -513,11 +513,13 @@ static void dpu_hw_intf_disable_autorefresh(struct 
dpu_hw_intf *intf,
 
 }
 
-static void dpu_hw_intf_enable_compression(struct dpu_hw_intf *ctx)
+static void dpu_hw_intf_program_datapath(struct dpu_hw_intf *ctx,
+struct intf_dpu_datapath_cfg 
*datapath_cfg)
 {
u32 intf_cfg2 = DPU_REG_READ(&ctx->hw, INTF_CONFIG2);
 
-   intf_cfg2 |= INTF_CFG2_DCE_DATA_COMPRESS;
+   if (datapath_cfg->data_compress)
+   intf_cfg2 |= INTF_CFG2_DCE_DATA_COMPRESS;
 
DPU_REG_WRITE(&ctx->hw, INTF_CONFIG2, intf_cfg2);
 }
@@ -543,8 +545,7 @@ static void _setup_intf_ops(struct dpu_hw_intf_ops *ops,
ops->disable_autorefresh = dpu_hw_intf_disable_autorefresh;
}
 
-   if (cap & BIT(DPU_INTF_DATA_COMPRESS))
-   ops->enable_compression = dpu_hw_intf_enable_compression;
+   ops->program_datapath = dpu_hw_intf_program_datapath;
 }
 
 struct dpu_hw_intf *dpu_hw_intf_init(const struct dpu_intf_cfg *cfg,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
index 99e21c4137f9..f736dca38463 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
@@ -48,6 +48,11 @@ struct intf_status {
u32 line_count; /* current line count including blanking */
 };
 
+struct intf_dpu_datapath_cfg {
+   u8 data_compress;   /* enable data compress between dpu and dsi */
+   /* can be expanded for other programmable bits */
+};
+
 /**
  * struct dpu_hw_intf_ops : Interface to the interface Hw driver functions
  *  Assumption is these functions will be called after clocks are enabled
@@ -70,7 +75,7 @@ struct intf_status {
  * @get_autorefresh:Retrieve autorefresh config from hardware
  *  Return: 0 on success, -ETIMEDOUT on timeout
  * @vsync_sel:  Select vsync signal for tear-effect 
configuration
- * @enable_compression: Enable data compression
+ * @program_datapath:   Program the DPU to interface datapath for 
relevant chipsets
  */
 struct dpu_hw_intf_ops {
void (*setup_timing_gen)(struct dpu_hw_intf *intf,
@@ -108,7 +113,14 @@ struct dpu_hw_intf_ops {
 */
void (*disable_autorefresh)(struct dpu_hw_intf *intf, uint32_t 
encoder_id, u16 vdisplay);
 
-   void (*enable_compression)(struct dpu_hw_intf *intf);
+   /**
+* Program the DPU to intf datapath by specifying
+* which of the settings need to be programmed for
+* use-cases which need DPU-intf handshake such as
+* widebus, compression etc.
+

Re: [PATCH v2 12/15] arm64: dts: qcom: sm6125: Switch fixed xo_board clock to RPM XO clock

[Konrad Dybcio]

On 29.06.2023 14:26, Dmitry Baryshkov wrote:
> On Thu, 29 Jun 2023 at 15:09, Marijn Suijten
>  wrote:
>>
>> On 2023-06-29 13:55:28, Dmitry Baryshkov wrote:
>>> On 27/06/2023 23:14, Marijn Suijten wrote:
 We have a working RPM XO clock; no other driver except rpmcc should be
 parenting directly to the fixed-factor xo_board clock nor should it be
 reachable by that global name.  Remove the name to that effect, so that
 every clock relation is explicitly defined in DTS.

 Reviewed-by: Konrad Dybcio 
 Signed-off-by: Marijn Suijten 
 ---
   arch/arm64/boot/dts/qcom/sm6125.dtsi | 7 ---
   1 file changed, 4 insertions(+), 3 deletions(-)

 diff --git a/arch/arm64/boot/dts/qcom/sm6125.dtsi 
 b/arch/arm64/boot/dts/qcom/sm6125.dtsi
 index 722dde560bec..edb03508dba3 100644
 --- a/arch/arm64/boot/dts/qcom/sm6125.dtsi
 +++ b/arch/arm64/boot/dts/qcom/sm6125.dtsi
 @@ -22,7 +22,6 @@ xo_board: xo-board {
 compatible = "fixed-clock";
 #clock-cells = <0>;
 clock-frequency = <1920>;
 -   clock-output-names = "xo_board";
>>>
>>> Why? I'd say, leave it.
>>
>> The exact reason is explained in the commit message.
> 
> Usually we do no not kill the xo_board name for the sake of anybody
> still looking for the old name. Weak argument, I know.
The only users are (rg -l '"xo_board"' drivers):

drivers/clk/qcom/mmcc-msm8974.c
drivers/clk/qcom/a53-pll.c
drivers/clk/qcom/gcc-msm8974.c
drivers/clk/qcom/clk-smd-rpm.c
drivers/clk/qcom/mmcc-msm8996.c
drivers/clk/qcom/gcc-msm8916.c
drivers/clk/qcom/gcc-apq8084.c
drivers/clk/qcom/gcc-msm8996.c
drivers/clk/qcom/mmcc-apq8084.c
drivers/clk/qcom/clk-rpmh.c
drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c

This platform only binds clk-smd-rpm, but patch 11 provides a
direct reference in the DT.

Konrad

> 
>>
>>>
>>> With that fixed:
>>
>> Hence I don't think it makes sense to "fix" this.
>>
>> - Marijn
>>
>>> Reviewed-by: Dmitry Baryshkov 
> 
> 
> 

[PATCH AUTOSEL 6.1 09/12] drm: use mgr->dev in drm_dbg_kms in drm_dp_add_payload_part2

[Sasha Levin]

From: Jeff Layton 

[ Upstream commit 54d217406afe250d7a768783baaa79a035f21d38 ]

I've been experiencing some intermittent crashes down in the display
driver code. The symptoms are ususally a line like this in dmesg:

amdgpu :30:00.0: [drm] Failed to create MST payload for port 
6d3a3885: -5

...followed by an Oops due to a NULL pointer dereference.

Switch to using mgr->dev instead of state->dev since "state" can be
NULL in some cases.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=2184855
Suggested-by: Jani Nikula 
Signed-off-by: Jeff Layton 
Reviewed-by: Jani Nikula 
Reviewed-by: Lyude Paul 
Signed-off-by: Lyude Paul 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20230419112447.18471-1-jlay...@kernel.org
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 38dab76ae69ea..e2e21ce79510e 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3404,7 +3404,7 @@ int drm_dp_add_payload_part2(struct 
drm_dp_mst_topology_mgr *mgr,
 
/* Skip failed payloads */
if (payload->vc_start_slot == -1) {
-   drm_dbg_kms(state->dev, "Part 1 of payload creation for %s 
failed, skipping part 2\n",
+   drm_dbg_kms(mgr->dev, "Part 1 of payload creation for %s 
failed, skipping part 2\n",
payload->port->connector->name);
return -EIO;
}
-- 
2.39.2

[PATCH AUTOSEL 6.3 12/17] drm: use mgr->dev in drm_dbg_kms in drm_dp_add_payload_part2

[Sasha Levin]

From: Jeff Layton 

[ Upstream commit 54d217406afe250d7a768783baaa79a035f21d38 ]

I've been experiencing some intermittent crashes down in the display
driver code. The symptoms are ususally a line like this in dmesg:

amdgpu :30:00.0: [drm] Failed to create MST payload for port 
6d3a3885: -5

...followed by an Oops due to a NULL pointer dereference.

Switch to using mgr->dev instead of state->dev since "state" can be
NULL in some cases.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=2184855
Suggested-by: Jani Nikula 
Signed-off-by: Jeff Layton 
Reviewed-by: Jani Nikula 
Reviewed-by: Lyude Paul 
Signed-off-by: Lyude Paul 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20230419112447.18471-1-jlay...@kernel.org
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 38dab76ae69ea..e2e21ce79510e 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3404,7 +3404,7 @@ int drm_dp_add_payload_part2(struct 
drm_dp_mst_topology_mgr *mgr,
 
/* Skip failed payloads */
if (payload->vc_start_slot == -1) {
-   drm_dbg_kms(state->dev, "Part 1 of payload creation for %s 
failed, skipping part 2\n",
+   drm_dbg_kms(mgr->dev, "Part 1 of payload creation for %s 
failed, skipping part 2\n",
payload->port->connector->name);
return -EIO;
}
-- 
2.39.2

Re: [Freedreno] [RFC PATCH 0/3] Support for Solid Fill Planes

[Jessica Zhang]

On 6/29/2023 12:29 AM, Pekka Paalanen wrote:

On Wed, 28 Jun 2023 09:40:21 -0700
Jessica Zhang  wrote:


On 6/28/2023 12:34 AM, Pekka Paalanen wrote:

On Tue, 27 Jun 2023 15:10:19 -0700
Abhinav Kumar  wrote:
   

On 6/27/2023 2:59 PM, Dmitry Baryshkov wrote:

On 28/06/2023 00:27, Jessica Zhang wrote:



On 6/27/2023 12:58 AM, Pekka Paalanen wrote:

On Mon, 26 Jun 2023 16:02:50 -0700
Jessica Zhang  wrote:
 

On 11/7/2022 11:37 AM, Ville Syrjälä wrote:

On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zhang wrote:

Introduce and add support for COLOR_FILL and COLOR_FILL_FORMAT
properties. When the color fill value is set, and the framebuffer
is set
to NULL, memory fetch will be disabled.


Thinking a bit more universally I wonder if there should be
some kind of enum property:

enum plane_pixel_source {
  FB,
  COLOR,
  LIVE_FOO,
  LIVE_BAR,
  ...
}


Reviving this thread as this was the initial comment suggesting to
implement pixel_source as an enum.

I think the issue with having pixel_source as an enum is how to decide
what counts as a NULL commit.

Currently, setting the FB to NULL will disable the plane. So I'm
guessing we will extend that logic to "if there's no pixel_source set
for the plane, then it will be a NULL commit and disable the plane".

In that case, the question then becomes when to set the pixel_source to
NONE. Because if we do that when setting a NULL FB (or NULL solid_fill
blob), it then forces userspace to set one property before the other.


Right, that won't work.

There is no ordering between each property being set inside a single
atomic commit. They can all be applied to kernel-internal state
theoretically simultaneously, or any arbitrary random order, and the
end result must always be the same. Hence, setting one property cannot
change the state of another mutable property. I believe that doing
otherwise would make userspace fragile and hard to get right.

I guess there might be an exception to that rule when the same property
is set multiple times in a single atomic commit; the last setting in
the array prevails. That's universal and not a special-case between two
specific properties.
 

Because of that, I'm thinking of having pixel_source be represented
by a
bitmask instead. That way, we will simply unset the corresponding
pixel_source bit when passing in a NULL FB/solid_fill blob. Then, in
order to detect whether a commit is NULL or has a valid pixel
source, we
can just check if pixel_source == 0.


Sounds fine to me at first hand, but isn't there the enum property that
says if the kernel must look at solid_fill blob *or* FB_ID?

If enum prop says "use solid_fill prop", the why would changes to FB_ID
do anything? Is it for backwards-compatibility with KMS clients that do
not know about the enum prop?

It seems like that kind of backwards-compatiblity will cause problems
in trying to reason about the atomic state, as explained above, leading
to very delicate and fragile conditions where things work intuitively.
Hence, I'm not sure backwards-compatibility is wanted. This won't be
the first or the last KMS property where an unexpected value left over
will make old atomic KMS clients silently malfunction up to showing no
recognisable picture at all. *If* that problem needs solving, there
have been ideas floating around about resetting everything to nice
values so that userspace can ignore what it does not understand. So far
there has been no real interest in solving that problem in the kernel
though.

Legacy non-atomic UAPI wrappers can do whatever they want, and program
any (new) properties they want in order to implement the legacy
expectations, so that does not seem to be a problem.


Hi Pekka and Dmitry,

After reading through both of your comments, I think I have a better
understanding of the pixel_source implementation now.

So to summarize, we want to expose another property called
"pixel_source" to userspace that will default to FB (as to not break
legacy userspace).

If userspace wants to use solid fill planes, it will set both the
solid_fill *and* pixel_source properties to a valid blob and COLOR
respectively. If it wants to use FB, it will set FB_ID and
pixel_source to a valid FB and FB.

Here's a table illustrating what I've described above:

+-+-+-+
| Use Case    | Legacy Userspace    | solid_fill-aware    |
| | | Userspace   |
+=+=+=+
| Valid FB    | pixel_source = FB   | pixel_source = FB   |
| | FB_ID = valid FB    | FB_ID = valid FB    |
+-+-+-+
| Valid   | pixel_source = COLOR    | N/A |
| solid_fill blob | solid_fill = valid blob | |


Probably these two cells were swapped.
  


Ack, yes th

Re: [RFC PATCH 0/3] Support for Solid Fill Planes

[Jessica Zhang]

On 6/27/2023 3:10 PM, Abhinav Kumar wrote:



On 6/27/2023 2:59 PM, Dmitry Baryshkov wrote:

On 28/06/2023 00:27, Jessica Zhang wrote:



On 6/27/2023 12:58 AM, Pekka Paalanen wrote:

On Mon, 26 Jun 2023 16:02:50 -0700
Jessica Zhang  wrote:


On 11/7/2022 11:37 AM, Ville Syrjälä wrote:

On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zhang wrote:

Introduce and add support for COLOR_FILL and COLOR_FILL_FORMAT
properties. When the color fill value is set, and the framebuffer 
is set

to NULL, memory fetch will be disabled.


Thinking a bit more universally I wonder if there should be
some kind of enum property:

enum plane_pixel_source {
FB,
COLOR,
LIVE_FOO,
LIVE_BAR,
...
}


Reviving this thread as this was the initial comment suggesting to
implement pixel_source as an enum.

I think the issue with having pixel_source as an enum is how to decide
what counts as a NULL commit.

Currently, setting the FB to NULL will disable the plane. So I'm
guessing we will extend that logic to "if there's no pixel_source set
for the plane, then it will be a NULL commit and disable the plane".

In that case, the question then becomes when to set the 
pixel_source to

NONE. Because if we do that when setting a NULL FB (or NULL solid_fill
blob), it then forces userspace to set one property before the other.


Right, that won't work.

There is no ordering between each property being set inside a single
atomic commit. They can all be applied to kernel-internal state
theoretically simultaneously, or any arbitrary random order, and the
end result must always be the same. Hence, setting one property cannot
change the state of another mutable property. I believe that doing
otherwise would make userspace fragile and hard to get right.

I guess there might be an exception to that rule when the same property
is set multiple times in a single atomic commit; the last setting in
the array prevails. That's universal and not a special-case between two
specific properties.

Because of that, I'm thinking of having pixel_source be represented 
by a

bitmask instead. That way, we will simply unset the corresponding
pixel_source bit when passing in a NULL FB/solid_fill blob. Then, in
order to detect whether a commit is NULL or has a valid pixel 
source, we

can just check if pixel_source == 0.


Sounds fine to me at first hand, but isn't there the enum property that
says if the kernel must look at solid_fill blob *or* FB_ID?

If enum prop says "use solid_fill prop", the why would changes to FB_ID
do anything? Is it for backwards-compatibility with KMS clients that do
not know about the enum prop?

It seems like that kind of backwards-compatiblity will cause problems
in trying to reason about the atomic state, as explained above, leading
to very delicate and fragile conditions where things work intuitively.
Hence, I'm not sure backwards-compatibility is wanted. This won't be
the first or the last KMS property where an unexpected value left over
will make old atomic KMS clients silently malfunction up to showing no
recognisable picture at all. *If* that problem needs solving, there
have been ideas floating around about resetting everything to nice
values so that userspace can ignore what it does not understand. So far
there has been no real interest in solving that problem in the kernel
though.

Legacy non-atomic UAPI wrappers can do whatever they want, and program
any (new) properties they want in order to implement the legacy
expectations, so that does not seem to be a problem.


Hi Pekka and Dmitry,

After reading through both of your comments, I think I have a better 
understanding of the pixel_source implementation now.


So to summarize, we want to expose another property called 
"pixel_source" to userspace that will default to FB (as to not break 
legacy userspace).


If userspace wants to use solid fill planes, it will set both the 
solid_fill *and* pixel_source properties to a valid blob and COLOR 
respectively. If it wants to use FB, it will set FB_ID and 
pixel_source to a valid FB and FB.


Here's a table illustrating what I've described above:

+-+-+-+
| Use Case    | Legacy Userspace    | solid_fill-aware    |
| | | Userspace   |
+=+=+=+
| Valid FB    | pixel_source = FB   | pixel_source = FB   |
| | FB_ID = valid FB    | FB_ID = valid FB    |
+-+-+-+
| Valid   | pixel_source = COLOR    | N/A |
| solid_fill blob | solid_fill = valid blob | |


Probably these two cells were swapped.



Ack, yes they were swapped.


+-+-+-+
| NULL commit | pixel_source = FB   | pixel_source = FB   |
| 

Re: [git pull] drm for 6.5-rc1

[pr-tracker-bot]

The pull request you sent on Thu, 29 Jun 2023 11:28:02 +1000:

> git://anongit.freedesktop.org/drm/drm tags/drm-next-2023-06-29

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1b722407a13b7f8658d2e26917791f32805980a2

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

RE: [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register

[Limonciello, Mario]

[Public]

> -Original Message-
> From: 15330273...@189.cn <15330273...@189.cn>
> Sent: Thursday, June 29, 2023 12:00 PM
> To: Bjorn Helgaas ; Sui Jingfeng
> 
> Cc: Bjorn Helgaas ; linux-fb...@vger.kernel.org;
> Cornelia Huck ; Karol Herbst ;
> nouv...@lists.freedesktop.org; Joonas Lahtinen
> ; dri-devel@lists.freedesktop.org; Chai,
> Thomas ; Limonciello, Mario
> ; Gao, Likun ; David
> Airlie ; Ville Syrjala ; Yi 
> Liu
> ; k...@vger.kernel.org; amd-...@lists.freedesktop.org;
> Jason Gunthorpe ; Ben Skeggs ; linux-
> p...@vger.kernel.org; Kevin Tian ; Lazar, Lijo
> ; Thomas Zimmermann ;
> Zhang, Bokun ; intel-...@lists.freedesktop.org;
> Maarten Lankhorst ; Jani Nikula
> ; Alex Williamson
> ; Abhishek Sahu ;
> Maxime Ripard ; Rodrigo Vivi ;
> Tvrtko Ursulin ; Yishai Hadas
> ; Pan, Xinhui ; linux-
> ker...@vger.kernel.org; Daniel Vetter ; Deucher, Alexander
> ; Koenig, Christian
> ; Zhang, Hawking 
> Subject: Re: [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function
> callback to vga_client_register
>
> Hi,
>
> On 2023/6/29 23:54, Bjorn Helgaas wrote:
> > On Thu, Jun 22, 2023 at 01:08:15PM +0800, Sui Jingfeng wrote:
> >> Hi,
> >>
> >>
> >> A nouveau developer(Lyude) from redhat send me a R-B,
> >>
> >> Thanks for the developers of nouveau project.
> >>
> >>
> >> Please allow me add a link[1] here.
> >>
> >>
> >> [1]
> https://lore.kernel.org/all/0afadc69f99a36bc9d03ecf54ff25859dbc10e28.ca
> m...@redhat.com/
> > 1) Thanks for this.  If you post another version of this series,
> > please pick up Lyude's Reviewed-by and include it in the relevant
> > patches (as long as you haven't made significant changes to the
> > code Lyude reviewed).
>
> Yes, no significant changes. Just fix typo.
>
> I also would like to add support for other DRM drivers.
>
> But I think this deserve another patch.
>
> >   Whoever applies this should automatically
> > pick up Reviewed-by/Ack/etc that are replies to the version being
> > applied, but they won't go through previous revisions to find them.
> >
> > 2) Please mention the commit to which the series applies.  I tried to
> > apply this on v6.4-rc1, but it doesn't apply cleanly.
>
> Since I'm a graphic driver developer, I'm using drm-tip.
>
> I just have already pulled, it still apply cleanly on drm-tip.
>
> > 3) Thanks for including cover letters in your postings.  Please
> > include a little changelog in the cover letter so we know what
> > changed between v6 and v7, etc.
>
> No change between v6 and v7,
>
> it seems that it is because the mailbox don't allow me to sending too
> many mails a day.
>
> so some of the patch is failed to delivery because out of quota.
>
>
> > 4) Right now we're in the middle of the v6.5 merge window, so new
> > content, e.g., this series, is too late for v6.5.  Most
> > maintainers, including me, wait to merge new content until the
> > merge window closes and a new -rc1 is tagged.  This merge window
> > should close on July 9, and people will start merging content for
> > v6.6, typically based on v6.5-rc1.
>
> I'm wondering
>
> Would you will merge all of the patches in this series (e.g. including
> the patch for drm/amdgpu(7/8) and drm/radeon(8/8)) ?
>
> Or just part of them?
>
> Emm, I don't know because my patch seems across different subsystem of
> Linux kernel.
>
> There is also a developer for AMDGPU (Mario) give me a R-B for the
> patch-0002 of this series.
>
> So, at least, PATCH-0001, PATCH-0002, PATCH-0003, PATCH-0004, PATCH-
> 0006
> are already OK(got reviewed by).
>
> Those 5 patch are already qualified to be merged, I think.

I think what you can do is pick up all the tags in your next version.  Once the
whole series has tags we can discuss how it merges.

>
> I means that if you could merge those 5 patch first, then there no need
> to send another version again.
>
> I will refine the rest patch with more details and description.
>
> I'm fear of making too much noise.
>
> > Bjorn

Re: [Freedreno] [PATCH 2/3] drm/msm/dpu: Set DATABUS_WIDEN on command mode encoders

[Jessica Zhang]

On 6/29/2023 10:26 AM, Abhinav Kumar wrote:



On 6/22/2023 4:37 PM, Abhinav Kumar wrote:



On 6/22/2023 4:14 PM, Dmitry Baryshkov wrote:

On 23/06/2023 01:37, Abhinav Kumar wrote:



On 6/21/2023 4:46 PM, Dmitry Baryshkov wrote:

On 22/06/2023 02:01, Abhinav Kumar wrote:



On 6/21/2023 9:36 AM, Dmitry Baryshkov wrote:

On 21/06/2023 18:17, Marijn Suijten wrote:

On 2023-06-20 14:38:34, Jessica Zhang wrote:


+    if (phys_enc->hw_intf->ops.enable_widebus)
+ phys_enc->hw_intf->ops.enable_widebus(phys_enc->hw_intf);


No. Please provide a single function which takes necessary
configuration, including compression and wide_bus_enable.



There are two ways to look at this. Your point is coming 
from the
perspective that its programming the same register but just 
a different

bit. But that will also make it a bit confusing.


My point is to have a high-level function that configures the 
INTF for

the CMD mode. This way it can take a structure with necessary
configuration bits.


Hi Dmitry,

After discussing this approach with Abhinav, we still have a few
questions about it:

Currently, only 3 of the 32 bits for INTF_CONFIG2 are being 
used (the
rest are reserved with no plans of being programmed in the 
future). Does

this still justify the use of a struct to pass in the necessary
configuration?


No.  The point Dmitry is making is **not** about this concidentally
using the same register, but about adding a common codepath to 
enable
compression on this hw_intf (regardless of the registers it 
needs to

touch).


Actually to setup INTF for CMD stream (which is equal to setting 
up compression at this point).




Yes it should be setup intf for cmd and not enable compression.

Widebus and compression are different features and we should be 
able to control them independently.


We just enable them together for DSI. So a separation is necessary.

But I am still not totally convinced we even need to go down the 
path for having an op called setup_intf_cmd() which takes in a 
struct like


struct dpu_cmd_intf_cfg {
 bool data_compress;
 bool widebus_en;
};

As we have agreed that we will not touch the video mode timing 
engine path, it leaves us with only two bits.


And like I said, its not that these two bits always go together. 
We want to be able to control them independently which means that 
its not necessary both bits program the same register one by one. 
We might just end up programming one of them if we just use widebus.


Thats why I am still leaning on keeping this approach.


I do not like the idea of having small functions being called 
between modules. So, yes there will a config of two booleans, but 
it is preferable (and more scalable) compared to separate callbacks.




I definitely agree with the scalable part and I even cross checked 
that the number of usable bitfields of this register is going up 
from one chipset to the other although once again that depends on 
whether we will use those features.


For that reason I am not opposed to the struct idea.

But there is also another pattern i am seeing which worries me. 
Usable bitfields sometimes even reduce. For those cases, if we go 
with a pre-defined struct it ends up with redundant members as those 
bitfields go away.


With the function op based approach, we just call the op if the 
feature bit / core revision.


So I wanted to check once more about the fact that we should 
consider not just expansion but also reduction.


As we have to support all generations, there is no actual reduction. 
Newer SoCs do not have particular feature/bit, but older ones do. By 
having multiple optional ops we just move this knowledge from 
ops->complex_callback() to _setup_block_ops(). But more importantly 
the caller gets more complicated. Instead of just calling 
ops->set_me_up(), it has to check all the optional callbacks and call 
the one by one.




Alright, I am thinking that perhaps because this register is kind of 
unique that its actually controlling a specific setting in the 
datapath, downstream also has separate ops for this.


But thats fine, we can go ahead with the struct based approach.



As data_compress has already landed, let me introduced the struct along 
with the core_revision based approach in the core_revision series and 
this series will expand that struct to include widebus too.


Acked. Will rebase on top of the core_revision series and add widebus to 
the config struct.


Thanks,

Jessica Zhang

Re: [GIT PULL] fbdev fixes for v6.5-rc1

[pr-tracker-bot]

The pull request you sent on Tue, 27 Jun 2023 08:17:50 +0200:

> http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git 
> tags/fbdev-for-6.5-rc1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/675285ad819293844018aa8096ba9a6d7c77b90b

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [Freedreno] [PATCH 2/3] drm/msm/dpu: Set DATABUS_WIDEN on command mode encoders

[Abhinav Kumar]

On 6/22/2023 4:37 PM, Abhinav Kumar wrote:



On 6/22/2023 4:14 PM, Dmitry Baryshkov wrote:

On 23/06/2023 01:37, Abhinav Kumar wrote:



On 6/21/2023 4:46 PM, Dmitry Baryshkov wrote:

On 22/06/2023 02:01, Abhinav Kumar wrote:



On 6/21/2023 9:36 AM, Dmitry Baryshkov wrote:

On 21/06/2023 18:17, Marijn Suijten wrote:

On 2023-06-20 14:38:34, Jessica Zhang wrote:


+    if (phys_enc->hw_intf->ops.enable_widebus)
+ phys_enc->hw_intf->ops.enable_widebus(phys_enc->hw_intf);


No. Please provide a single function which takes necessary
configuration, including compression and wide_bus_enable.



There are two ways to look at this. Your point is coming from 
the
perspective that its programming the same register but just a 
different

bit. But that will also make it a bit confusing.


My point is to have a high-level function that configures the 
INTF for

the CMD mode. This way it can take a structure with necessary
configuration bits.


Hi Dmitry,

After discussing this approach with Abhinav, we still have a few
questions about it:

Currently, only 3 of the 32 bits for INTF_CONFIG2 are being used 
(the
rest are reserved with no plans of being programmed in the 
future). Does

this still justify the use of a struct to pass in the necessary
configuration?


No.  The point Dmitry is making is **not** about this concidentally
using the same register, but about adding a common codepath to 
enable

compression on this hw_intf (regardless of the registers it needs to
touch).


Actually to setup INTF for CMD stream (which is equal to setting 
up compression at this point).




Yes it should be setup intf for cmd and not enable compression.

Widebus and compression are different features and we should be 
able to control them independently.


We just enable them together for DSI. So a separation is necessary.

But I am still not totally convinced we even need to go down the 
path for having an op called setup_intf_cmd() which takes in a 
struct like


struct dpu_cmd_intf_cfg {
 bool data_compress;
 bool widebus_en;
};

As we have agreed that we will not touch the video mode timing 
engine path, it leaves us with only two bits.


And like I said, its not that these two bits always go together. We 
want to be able to control them independently which means that its 
not necessary both bits program the same register one by one. We 
might just end up programming one of them if we just use widebus.


Thats why I am still leaning on keeping this approach.


I do not like the idea of having small functions being called 
between modules. So, yes there will a config of two booleans, but it 
is preferable (and more scalable) compared to separate callbacks.




I definitely agree with the scalable part and I even cross checked 
that the number of usable bitfields of this register is going up from 
one chipset to the other although once again that depends on whether 
we will use those features.


For that reason I am not opposed to the struct idea.

But there is also another pattern i am seeing which worries me. 
Usable bitfields sometimes even reduce. For those cases, if we go 
with a pre-defined struct it ends up with redundant members as those 
bitfields go away.


With the function op based approach, we just call the op if the 
feature bit / core revision.


So I wanted to check once more about the fact that we should consider 
not just expansion but also reduction.


As we have to support all generations, there is no actual reduction. 
Newer SoCs do not have particular feature/bit, but older ones do. By 
having multiple optional ops we just move this knowledge from 
ops->complex_callback() to _setup_block_ops(). But more importantly 
the caller gets more complicated. Instead of just calling 
ops->set_me_up(), it has to check all the optional callbacks and call 
the one by one.




Alright, I am thinking that perhaps because this register is kind of 
unique that its actually controlling a specific setting in the datapath, 
downstream also has separate ops for this.


But thats fine, we can go ahead with the struct based approach.



As data_compress has already landed, let me introduced the struct along 
with the core_revision based approach in the core_revision series and 
this series will expand that struct to include widebus too.

[PATCH] drm/i915/quirk: Add quirk for devices that cannot be dimmed

[Allen Ballway]

Cybernet T10C cannot be dimmed without the backlight strobing. Create a
new quirk to lock the minimum brightness to the highest supported value.
This aligns the device with its behavior on Windows, which will not
lower the brightness below maximum.

Signed-off-by: Allen Ballway 
---
V2 -> V3: Fix typo.
V1 -> V2: Fix style issue.

.../gpu/drm/i915/display/intel_backlight.c|  5 
 drivers/gpu/drm/i915/display/intel_quirks.c   | 27 +++
 drivers/gpu/drm/i915/display/intel_quirks.h   |  1 +
 3 files changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c 
b/drivers/gpu/drm/i915/display/intel_backlight.c
index 2e8f17c045222..f015563d3ebd5 100644
--- a/drivers/gpu/drm/i915/display/intel_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_backlight.c
@@ -1192,6 +1192,11 @@ static u32 get_backlight_min_vbt(struct intel_connector 
*connector)

drm_WARN_ON(&i915->drm, panel->backlight.pwm_level_max == 0);

+   if (intel_has_quirk(i915, QUIRK_NO_DIM)) {
+   /* Cannot dim backlight, set minimum to highest value */
+   return panel->backlight.pwm_level_max - 1;
+   }
+
/*
 * XXX: If the vbt value is 255, it makes min equal to max, which leads
 * to problems. There are such machines out there. Either our
diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c 
b/drivers/gpu/drm/i915/display/intel_quirks.c
index a280448df771a..910c95840a539 100644
--- a/drivers/gpu/drm/i915/display/intel_quirks.c
+++ b/drivers/gpu/drm/i915/display/intel_quirks.c
@@ -65,6 +65,12 @@ static void quirk_no_pps_backlight_power_hook(struct 
drm_i915_private *i915)
drm_info(&i915->drm, "Applying no pps backlight power quirk\n");
 }

+static void quirk_no_dim(struct drm_i915_private *i915)
+{
+   intel_set_quirk(i915, QUIRK_NO_DIM);
+   drm_info(&i915->drm, "Applying no dim quirk\n");
+}
+
 struct intel_quirk {
int device;
int subsystem_vendor;
@@ -90,6 +96,12 @@ static int intel_dmi_no_pps_backlight(const struct 
dmi_system_id *id)
return 1;
 }

+static int intel_dmi_no_dim(const struct dmi_system_id *id)
+{
+   DRM_INFO("No dimming allowed on %s\n", id->ident);
+   return 1;
+}
+
 static const struct intel_dmi_quirk intel_dmi_quirks[] = {
{
.dmi_id_list = &(const struct dmi_system_id[]) {
@@ -136,6 +148,20 @@ static const struct intel_dmi_quirk intel_dmi_quirks[] = {
},
.hook = quirk_no_pps_backlight_power_hook,
},
+   {
+   .dmi_id_list = &(const struct dmi_system_id[]) {
+   {
+   .callback = intel_dmi_no_dim,
+   .ident = "Cybernet T10C Tablet",
+   .matches = {DMI_EXACT_MATCH(DMI_BOARD_VENDOR,
+   "Cybernet 
Manufacturing Inc."),
+   DMI_EXACT_MATCH(DMI_BOARD_NAME, 
"T10C Tablet"),
+   },
+   },
+   { }
+   },
+   .hook = quirk_no_dim,
+   },
 };

 static struct intel_quirk intel_quirks[] = {
@@ -218,6 +244,7 @@ void intel_init_quirks(struct drm_i915_private *i915)
 q->subsystem_device == PCI_ANY_ID))
q->hook(i915);
}
+
for (i = 0; i < ARRAY_SIZE(intel_dmi_quirks); i++) {
if (dmi_check_system(*intel_dmi_quirks[i].dmi_id_list) != 0)
intel_dmi_quirks[i].hook(i915);
diff --git a/drivers/gpu/drm/i915/display/intel_quirks.h 
b/drivers/gpu/drm/i915/display/intel_quirks.h
index 10a4d163149fd..b41c7bbf0a5e3 100644
--- a/drivers/gpu/drm/i915/display/intel_quirks.h
+++ b/drivers/gpu/drm/i915/display/intel_quirks.h
@@ -17,6 +17,7 @@ enum intel_quirk_id {
QUIRK_INVERT_BRIGHTNESS,
QUIRK_LVDS_SSC_DISABLE,
QUIRK_NO_PPS_BACKLIGHT_POWER_HOOK,
+   QUIRK_NO_DIM,
 };

 void intel_init_quirks(struct drm_i915_private *i915);
--
2.41.0.255.g8b1d071c50-goog

Re: [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register

[Sui Jingfeng]

Hi,

On 2023/6/29 23:54, Bjorn Helgaas wrote:

On Thu, Jun 22, 2023 at 01:08:15PM +0800, Sui Jingfeng wrote:

Hi,


A nouveau developer(Lyude) from redhat send me a R-B,

Thanks for the developers of nouveau project.


Please allow me add a link[1] here.


[1] 
https://lore.kernel.org/all/0afadc69f99a36bc9d03ecf54ff25859dbc10e28.ca...@redhat.com/

1) Thanks for this.  If you post another version of this series,
please pick up Lyude's Reviewed-by and include it in the relevant
patches (as long as you haven't made significant changes to the
code Lyude reviewed).


Yes, no significant changes. Just fix typo.

I also would like to add support for other DRM drivers.

But I think this deserve another patch.


  Whoever applies this should automatically
pick up Reviewed-by/Ack/etc that are replies to the version being
applied, but they won't go through previous revisions to find them.

2) Please mention the commit to which the series applies.  I tried to
apply this on v6.4-rc1, but it doesn't apply cleanly.


Since I'm a graphic driver developer, I'm using drm-tip.

I just have already pulled, it still apply cleanly on drm-tip.


3) Thanks for including cover letters in your postings.  Please
include a little changelog in the cover letter so we know what
changed between v6 and v7, etc.


No change between v6 and v7,

it seems that it is because the mailbox don't allow me to sending too 
many mails a day.


so some of the patch is failed to delivery because out of quota.



4) Right now we're in the middle of the v6.5 merge window, so new
content, e.g., this series, is too late for v6.5.  Most
maintainers, including me, wait to merge new content until the
merge window closes and a new -rc1 is tagged.  This merge window
should close on July 9, and people will start merging content for
v6.6, typically based on v6.5-rc1.


I'm wondering

Would you will merge all of the patches in this series (e.g. including 
the patch for drm/amdgpu(7/8) and drm/radeon(8/8)) ?


Or just part of them?

Emm, I don't know because my patch seems across different subsystem of 
Linux kernel.


There is also a developer for AMDGPU (Mario) give me a R-B for the 
patch-0002 of this series.


So, at least, PATCH-0001, PATCH-0002, PATCH-0003, PATCH-0004, PATCH-0006 
are already OK(got reviewed by).


Those 5 patch are already qualified to be merged, I think.

I means that if you could merge those 5 patch first, then there no need 
to send another version again.


I will refine the rest patch with more details and description.

I'm fear of making too much noise.


Bjorn

Re: [PATCH v3] drm/xe/guc: Fix h2g_write usage of GUC_CTB_MSG_MAX_LEN

[Teres Alexis, Alan Previn]

On Wed, 2023-06-28 at 21:44 +, Brost, Matthew wrote:
> On Wed, Jun 28, 2023 at 11:17:18AM -0700, Alan Previn wrote:
> > In the ABI header, GUC_CTB_MSG_MIN_LEN is '1' because
> > GUC_CTB_HDR_LEN is 1. This aligns with H2G/G2H CTB specification
> > where all command formats are defined in units of dwords so that '1'
> > is a dword. Accordingly, GUC_CTB_MSG_MAX_LEN is 256-1 (i.e. 255
> > dwords). However, h2g_write was incorrectly assuming that
> > GUC_CTB_MSG_MAX_LEN was in bytes. Fix this.
> 
alan:snip
> > diff --git a/drivers/gpu/drm/xe/xe_guc_ct.c b/drivers/gpu/drm/xe/xe_guc_ct.c
> > index 22bc9ce846db..aa04b5c4822f 100644
> > --- a/drivers/gpu/drm/xe/xe_guc_ct.c
> > +++ b/drivers/gpu/drm/xe/xe_guc_ct.c
> > @@ -401,19 +401,21 @@ static int h2g_write(struct xe_guc_ct *ct, const u32 
> > *action, u32 len,
> >  {
> > struct xe_device *xe = ct_to_xe(ct);
> > struct guc_ctb *h2g = &ct->ctbs.h2g;
> > -   u32 cmd[GUC_CTB_MSG_MAX_LEN / sizeof(u32)];
> > -   u32 cmd_len = len + GUC_CTB_HDR_LEN;
> > -   u32 cmd_idx = 0, i;
> > +#define H2G_CT_HEADERS (GUC_CTB_HDR_LEN + 1) /* one DW CTB header and one 
> > DW HxG header */
> 
> Hate to nit pick but again this should be above the h2g_write per
> feedback from Oden on Xe in general.
> 
> Otherwise LGTM.
> 
> With the nit addressed:
> 
> Reviewed-by: Matthew Brost 

Thanks for reviewing. My bad on the #define - you mentioned that before.
Will fix that now.
...alan

Re: [PATCH 3/4] dt-bindings: display/msm: dsi-controller-main: Allow refgen-supply

[Rob Herring]

On Wed, 28 Jun 2023 18:29:47 +0200, Konrad Dybcio wrote:
> DSI host needs REFGEN to be enabled (if it's present on a given platform).
> Allow consuming it.
> 
> Signed-off-by: Konrad Dybcio 
> ---
>  .../devicetree/bindings/display/msm/dsi-controller-main.yaml  | 4 
> 
>  1 file changed, 4 insertions(+)
> 

Acked-by: Rob Herring 

Re: [PATCH 1/4] dt-bindings: regulator: Describe Qualcomm REFGEN regulator

[Rob Herring]

On Wed, Jun 28, 2023 at 06:29:45PM +0200, Konrad Dybcio wrote:
> Modern Qualcomm SoCs have a REFGEN (reference voltage generator)
> regulator, providing reference voltage to on-chip IP, like PHYs.
> It's controlled through MMIO and we can toggle it or read its state back.
> 
> Describe it.
> 
> Signed-off-by: Konrad Dybcio 
> ---
>  .../regulator/qcom,sdm845-refgen-regulator.yaml| 56 
> ++
>  1 file changed, 56 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/regulator/qcom,sdm845-refgen-regulator.yaml
>  
> b/Documentation/devicetree/bindings/regulator/qcom,sdm845-refgen-regulator.yaml
> new file mode 100644
> index ..19d3eb9db98f
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/regulator/qcom,sdm845-refgen-regulator.yaml
> @@ -0,0 +1,56 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: 
> http://devicetree.org/schemas/regulator/qcom,sdm845-refgen-regulator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm Technologies, Inc. REFGEN Regulator
> +
> +maintainers:
> +  - Konrad Dybcio 
> +
> +description: |

Don't need '|'.

> +The REFGEN (reference voltage renegator) regulator provides reference

renegator?

> +voltage for on-chip IPs (like PHYs) on some Qualcomm SoCs.
> +
> +allOf:
> +  - $ref: regulator.yaml#
> +
> +properties:
> +  compatible:
> +oneOf:
> +  - items:
> +  - enum:
> +  - qcom,sc7180-refgen-regulator
> +  - qcom,sc8180x-refgen-regulator
> +  - qcom,sm8150-refgen-regulator
> +  - const: qcom,sdm845-refgen-regulator
> +
> +  - items:
> +  - enum:
> +  - qcom,sc7280-refgen-regulator
> +  - qcom,sc8280xp-refgen-regulator
> +  - qcom,sm6350-refgen-regulator
> +  - qcom,sm6375-refgen-regulator
> +  - qcom,sm8350-refgen-regulator
> +  - const: qcom,sm8250-refgen-regulator
> +
> +  - enum:
> +  - qcom,sdm845-refgen-regulator
> +  - qcom,sm8250-refgen-regulator
> +
> +  reg: true

Need to define how many.

> +
> +required:
> +  - compatible
> +  - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +regulator@162f000 {
> +  compatible = "qcom,sm8250-refgen-regulator";
> +  reg = <0 0x0162f000 0 0x84>;

Default cell size is 1.

> +};
> +...
> 
> -- 
> 2.41.0
> 

Re: [PATCH v2 06/15] dt-bindings: display/msm: sc7180-dpu: Describe SM6125

[Rob Herring]

On Tue, 27 Jun 2023 22:14:21 +0200, Marijn Suijten wrote:
> SM6125 is identical to SM6375 except that while downstream also defines
> a throttle clock, its presence results in timeouts whereas SM6375
> requires it to not observe any timeouts.  This is represented by
> reducing the clock array length to 6 so that it cannot be passed.  Note
> that any SoC other than SM6375 (currently SC7180 and SM6350) are
> unconstrained and could either pass or leave out this "throttle" clock.
> 
> Signed-off-by: Marijn Suijten 
> ---
>  .../devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml   | 14 
> ++
>  1 file changed, 14 insertions(+)
> 

Reviewed-by: Rob Herring 

Re: [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register

[Bjorn Helgaas]

On Thu, Jun 22, 2023 at 01:08:15PM +0800, Sui Jingfeng wrote:
> Hi,
> 
> 
> A nouveau developer(Lyude) from redhat send me a R-B,
> 
> Thanks for the developers of nouveau project.
> 
> 
> Please allow me add a link[1] here.
> 
> 
> [1] 
> https://lore.kernel.org/all/0afadc69f99a36bc9d03ecf54ff25859dbc10e28.ca...@redhat.com/

1) Thanks for this.  If you post another version of this series,
   please pick up Lyude's Reviewed-by and include it in the relevant
   patches (as long as you haven't made significant changes to the
   code Lyude reviewed).  Whoever applies this should automatically
   pick up Reviewed-by/Ack/etc that are replies to the version being
   applied, but they won't go through previous revisions to find them.

2) Please mention the commit to which the series applies.  I tried to
   apply this on v6.4-rc1, but it doesn't apply cleanly.

3) Thanks for including cover letters in your postings.  Please
   include a little changelog in the cover letter so we know what
   changed between v6 and v7, etc.

4) Right now we're in the middle of the v6.5 merge window, so new
   content, e.g., this series, is too late for v6.5.  Most
   maintainers, including me, wait to merge new content until the
   merge window closes and a new -rc1 is tagged.  This merge window
   should close on July 9, and people will start merging content for
   v6.6, typically based on v6.5-rc1.

Bjorn

Re: [PATCH v2 03/15] dt-bindings: clock: qcom, dispcc-sm6125: Require GCC PLL0 DIV clock

[Rob Herring]

On Tue, 27 Jun 2023 22:14:18 +0200, Marijn Suijten wrote:
> The "gcc_disp_gpll0_div_clk_src" clock is consumed by the driver, will
> be passed from DT, and should be required by the bindings.
> 
> Fixes: 8397c9c0c26b ("dt-bindings: clock: add QCOM SM6125 display clock 
> bindings")
> Signed-off-by: Marijn Suijten 
> ---
>  Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 

Reviewed-by: Rob Herring 

RE: [PATCH v2 0/3] Checksum Region with new CRTC properties

[Liu, HaoPing (Alan)]

[AMD Official Use Only - General]

Dear DRM development community,

I also developed an IGT for testing this checksum_region feature.
Please check it at: https://patchwork.freedesktop.org/series/120017/
Thank you and welcome any feedback.

Best Regards,
Alan

-Original Message-
From: Alan Liu 
Sent: Sunday, June 18, 2023 6:39 PM
To: dri-devel@lists.freedesktop.org
Cc: Wentland, Harry ; Gong, Lili (Sophia) 
; Lin, Wayne ; Liu, HaoPing (Alan) 
; Liu, HaoPing (Alan) 
Subject: [PATCH v2 0/3] Checksum Region with new CRTC properties

Dear DRM development community,

We'd like to introduce the implementation of the new crtc properties.

First of all, please let me introduce the problem we try to address. With the 
popularity of electric vehicles, the car vendors have increasing requirement 
for ensuring the integrity of the critical content on the display. For example, 
tell-tales are icons to indicate malfunction or operation on a car system. For 
safty concern, car vendors always want to make sure these icons are not 
tampered and can be correctly displayed on the instrument cluster.

To address this problem, since modern display control hardware is able to 
calculate the CRC checksum of the display content, we are thinking of a feature 
to let userspace specify a region on display, and we can utilize the hardware 
to calculate the CRC checksum as frames scanned out, and finally, provide the 
checksum for userspace for validation purpose.
In this case, since the icons themselves are often fixed over static 
backgrounds, the CRC of the pixels in the region can be known in advance. So 
one of the usage of the region and corresponding CRC result is that as users 
know the CRC checksum of the tell-tales in advance, at runtime they can 
retrieve the CRC value from kernel for validation as frames are scanned out.

We implement this feature and call it checksum region. To let userspace set a 
region and retrieve the corresponding CRC value, we provide 2 new properties, 
CHECKSUM_REGION and CHECKSUM_CRC. Both of them are blob properties under CRTC, 
and the detailed struct of the two properties are listed below. One for 
userspace to set the region to kernel, and the other for userspace to retrieve 
CRC values from kernel. Upon userspace submitting the 4 coordinate values with 
checksum_region_enable true, kernel instructs DC hardware to calculate the CRC 
value accordingly as frames scanned out. The result CRC value of RGB colors are 
then stored in CHECKSUM_CRC property, with a reference frame count for 
userspace to know which frame the CRCs are calculated at.

/**
 * struct drm_checksum_region - The enablement and region of checksum_region
 * @x_start: Horizontal starting coordinate of the region.
 * @y_start: Vertical starting coordinate of the region.
 * @x_end: Horizontal ending coordinate of the region.
 * @y_end: Vertical ending coordinate of the region.
 * @checksum_region_enable: To enable or disable checksum_region.
 *
 * Userspace uses this structure to configure the region and enablement for
 * checksum_region. Userspace should not submit a region out of the displayable
 * region because there is nothing to display and need protection.
 */
struct drm_checksum_region {
__u32 x_start;
__u32 y_start;
__u32 x_end;
__u32 y_end;
__u8 checksum_region_enable;
__u8 pad[7];
};

/**
 * struct drm_checksum_crc - The CRC value of the corresponding checksum region.
 * @crc_r: CRC value of red color.
 * @crc_g: CRC value of green color.
 * @crc_b: CRC value of blue color.
 * @frame_count: a referenced frame count to indicate which frame the CRC values
 *  are generated at.
 *
 * Userspace uses this structure to retrieve the CRC values of the current
 * checksum region. @frame_count will be reset once a new region is updated or
 * it reaches a maximum value. Currently these CRC values are designed to
 * be validated with pre-saved CRC values, so userspace doesn't need to concern
 * about the algorithm used to compute the CRC.
 */
struct drm_checksum_crc {
__u32 crc_r;
__u32 crc_g;
__u32 crc_b;
__u32 frame_count;
};

To better introduce the usage of this feature, we also have a paired Weston 
application as an reference app to use secure display via the properties. 
Please check the Weston application and see how the application set the region 
and validate the content from the CRC here: 
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1236
This application can draw patterns on the display, and allow users to set the 
region and submit it to kernel via properties. With kernel keeping calculating 
the CRC, this example application takes the first CRC as source CRC, and keeps 
retrieving the new CRCs at each frame later. By comparing source CRC with the 
following CRC value, the application can validate if the display content got 
changed down the road.

Finally, let me briefly introduce the patches. There are 3 patches i

Re: [PATCH 00/12] arch,fbdev: Move screen_info into arch/

[Arnd Bergmann]

On Thu, Jun 29, 2023, at 16:15, Thomas Zimmermann wrote:
> Am 29.06.23 um 15:31 schrieb Arnd Bergmann:
>> On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
>>> Future directions: with the patchset in place, it will become possible
>>> to provide screen_info and edid_info only if there are users. Some
>>> architectures do this by testing for CONFIG_VT, CONFIG_DUMMY_CONSOLE,
>>> etc. A more uniform approach would be nice. We should also attempt
>>> to minimize access to the global screen_info as much as possible. To
>>> do so, some drivers, such as efifb and vesafb, would require an update.
>>> The firmware's EDID data could possibly made available outside of fbdev.
>>> For example, the simpledrm and ofdrm drivers could provide such data
>>> to userspace compositors.
>> 
>> I suspect that most architectures that provide a screen_info only
>> have this in order to compile the framebuffer drivers, and provide
>> hardcoded data that does not even reflect any real hardware.
>
> That's quite possible. Only x86's bootparam and EFI code sets 
> screen_info from external data. The rest is hardcoded. A number of 
> architectures protect screen_info with CONFIG_VT, CONFIG_DUMMY_CONSOLE, 
> etc. In a later patchset, I wanted to change this such that these users 
> of screen_info would enable the feature via select in their Kconfig.
>
> Do you know the reason for this branch in dummycon:
>
> https://elixir.bootlin.com/linux/v6.4/source/drivers/video/console/dummycon.c#L21
>
> What is special about arm that dummycon uses the screeninfo?

I can only guess myself, but I see that the values are only ever
set from the old ATAGS data, and not from DT on any of the
modern ones, and my interpretation is that this is meant to
match whatever the vga console was set to on the three
platforms that support vgacon.
 
I see this was added in linux-2.1.111, just before the
corresponding sparc specific hack was removed, but I don't have
patch descriptions from that era. Russell might remember, or know
if that is actually still needed.

   Arnd

Re: [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register

[Sui Jingfeng]

Hi,


Humble ping !


Please share some bandwidth to help reviewing this series, OK ?


As this series is useful for all architecture, I have tested on my X86, 
mips and LoongArch computer.


Questions and comments is also welcome.

If no one response within three days,

I'm going to send a updated version with another trivial improvement, OK?

On 2023/6/13 11:01, Sui Jingfeng wrote:

From: Sui Jingfeng 

The vga_is_firmware_default() function is arch-dependent, it's probably
wrong if we simply remove the arch guard. As the VRAM BAR which contains
firmware framebuffer may move, while the lfb_base and lfb_size members of
the screen_info does not change accordingly. In short, it should take the
re-allocation of the PCI BAR into consideration.

With the observation that device drivers or video aperture helpers may
have better knowledge about which PCI bar contains the firmware fb,
which could avoid the need to iterate all of the PCI BARs. But as a PCI
function at pci/vgaarb.c, vga_is_firmware_default() is not suitable to
make such an optimization since it is loaded too early.

There are PCI display controllers that don't have a dedicated VRAM bar,
this function will lose its effectiveness in such a case. Luckily, the
device driver can provide an accurate workaround.

Therefore, this patch introduces a callback that allows the device driver
to tell the VGAARB if the device is the default boot device. This patch
only intends to introduce the mechanism, while the implementation is left
to the device driver authors. Also honor the comment: "Clients have two
callback mechanisms they can use"

Cc: Alex Deucher 
Cc: Christian Konig 
Cc: Pan Xinhui 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: Ben Skeggs 
Cc: Karol Herbst 
Cc: Lyude Paul 
Cc: Bjorn Helgaas 
Cc: Alex Williamson 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: Hawking Zhang 
Cc: Mario Limonciello 
Cc: Lijo Lazar 
Cc: YiPeng Chai 
Cc: Bokun Zhang 
Cc: Likun Gao 
Cc: Ville Syrjala 
Cc: Jason Gunthorpe 
CC: Kevin Tian 
Cc: Cornelia Huck 
Cc: Yishai Hadas 
Cc: Abhishek Sahu 
Cc: Yi Liu 
Signed-off-by: Sui Jingfeng 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  2 +-
  drivers/gpu/drm/i915/display/intel_vga.c   |  3 +--
  drivers/gpu/drm/nouveau/nouveau_vga.c  |  2 +-
  drivers/gpu/drm/radeon/radeon_device.c |  2 +-
  drivers/pci/vgaarb.c   | 21 -
  drivers/vfio/pci/vfio_pci_core.c   |  2 +-
  include/linux/vgaarb.h |  8 +---
  7 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 5c7d40873ee2..7a096f2d5c16 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3960,7 +3960,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,
/* this will fail for cards that aren't VGA class devices, just
 * ignore it */
if ((adev->pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA)
-   vga_client_register(adev->pdev, amdgpu_device_vga_set_decode);
+   vga_client_register(adev->pdev, amdgpu_device_vga_set_decode, 
NULL);
  
  	px = amdgpu_device_supports_px(ddev);
  
diff --git a/drivers/gpu/drm/i915/display/intel_vga.c b/drivers/gpu/drm/i915/display/intel_vga.c

index 286a0bdd28c6..98d7d4dffe9f 100644
--- a/drivers/gpu/drm/i915/display/intel_vga.c
+++ b/drivers/gpu/drm/i915/display/intel_vga.c
@@ -115,7 +115,6 @@ intel_vga_set_decode(struct pci_dev *pdev, bool 
enable_decode)
  
  int intel_vga_register(struct drm_i915_private *i915)

  {
-
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
int ret;
  
@@ -127,7 +126,7 @@ int intel_vga_register(struct drm_i915_private *i915)

 * then we do not take part in VGA arbitration and the
 * vga_client_register() fails with -ENODEV.
 */
-   ret = vga_client_register(pdev, intel_vga_set_decode);
+   ret = vga_client_register(pdev, intel_vga_set_decode, NULL);
if (ret && ret != -ENODEV)
return ret;
  
diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c b/drivers/gpu/drm/nouveau/nouveau_vga.c

index f8bf0ec26844..162b4f4676c7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vga.c
+++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
@@ -92,7 +92,7 @@ nouveau_vga_init(struct nouveau_drm *drm)
return;
pdev = to_pci_dev(dev->dev);
  
-	vga_client_register(pdev, nouveau_vga_set_decode);

+   vga_client_register(pdev, nouveau_vga_set_decode, NULL);
  
  	/* don't register Thunderbolt eGPU with vga_switcheroo */

if (pci_is_thunderbolt_attached(pdev))
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index afbb3a80c0c6..71f2ff39d6a1 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -

Re: [PATCH 00/12] arch,fbdev: Move screen_info into arch/

[Arnd Bergmann]

On Thu, Jun 29, 2023, at 15:31, Arnd Bergmann wrote:
> On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
>>
>> Future directions: with the patchset in place, it will become possible
>> to provide screen_info and edid_info only if there are users. Some
>> architectures do this by testing for CONFIG_VT, CONFIG_DUMMY_CONSOLE,
>> etc. A more uniform approach would be nice. We should also attempt
>> to minimize access to the global screen_info as much as possible. To
>> do so, some drivers, such as efifb and vesafb, would require an update.
>> The firmware's EDID data could possibly made available outside of fbdev.
>> For example, the simpledrm and ofdrm drivers could provide such data
>> to userspace compositors.
>
> I suspect that most architectures that provide a screen_info only
> have this in order to compile the framebuffer drivers, and provide
> hardcoded data that does not even reflect any real hardware.
>
> We can probably reduce the number of architectures that do this
> a lot, especially if we get EFI out of the picture.

I tried to have another look at who uses what, and here are
some observations:

- EFIFB and hyperv are the only ones that are relevant on modern
  systmes, and they are only used on systems using EFI, so they
  could use a separate data structure that is defined as part of
  drivers/firmware/efi. This would likely mean we don't have to
  define a separate screen_info for arm64, loongarch, ia64 and
  riscv, and could separate the legacy vgacon/vesafb stuff on
  arm32 from the efi side.

- FB_SIS can likely be marked 'depends on X86' like FB_INTEL,
  it seems to depend on x86 BOOT_VESA_SUPPORT.

- FB_VGA16 is currently support on powerpc and enabled on
  one defconfig (pasemi), which I'm fairly sure is a mistake,
  so this could be made x86 specific as well.

- VGA_CONSOLE has a complicated Kconfig dependency list that
  lists platforms without VGA support but I think this is better
  expressed with a positive list. It looks like csky, hexagon,
  nios2 and xtensa should be excluded here and not provide
  screen_info.

- arm and mips only need to provide screen_info on machines
  with VGA_CONSOLE. On Arm we have a dependency on
  footbridge/integrator/netwinder, while on mips the
  dependency can be added to the platforms that fill
  the info (mips, malta, sibyte, sni).

- DUMMY_CONSOLE only uses screen_info on arm, and this should
  likely be limited to the three obsolete machines that
  support VGACON. Almost all Arm machines use DT these days
  and won't ever fill the screen info dynamically.

  Arnd

Re: Why does kgd2kfd_interrupt() have to schedule work on a specific CPU?

[Philip Yang]

  
This was to fix application long event wait latency, when app
  shader generates lots of event interrupts in short period, the
  scheduled work no chance to execute on the same CPU core, this
  causes event cannot post/return to app thread which are waiting
  the event. To schedule work on the core of same NUMA node is to
  optimize cache usage in general.

Regards
Philip

On 2023-06-27 11:42, Alex Deucher
  wrote:


  +Felix, Philip

On Tue, Jun 27, 2023 at 4:42 AM Philipp Stanner  wrote:

  

Hello folks,

I'm currently trying to learn more about DRM and discovered the
following code sequence:


drivers/gpu/drm/amd/amdkfd/kfd_device.c, Line 824 on 6.4-rc7

static inline void kfd_queue_work(struct workqueue_struct *wq,
  struct work_struct *work)
{
int cpu, new_cpu;

cpu = new_cpu = smp_processor_id();
do {
new_cpu = cpumask_next(new_cpu, cpu_online_mask) % nr_cpu_ids;
if (cpu_to_node(new_cpu) == numa_node_id())
break;
} while (cpu != new_cpu);

queue_work_on(new_cpu, wq, work);
}

/* This is called directly from KGD at ISR. */
void kgd2kfd_interrupt(struct kfd_dev *kfd, const void *ih_ring_entry)
{
uint32_t patched_ihre[KFD_MAX_RING_ENTRY_SIZE];
bool is_patched = false;
unsigned long flags;

if (!kfd->init_complete)
return;

if (kfd->device_info.ih_ring_entry_size > sizeof(patched_ihre)) {
dev_err_once(kfd_device, "Ring entry too small\n");
return;
}

spin_lock_irqsave(&kfd->interrupt_lock, flags);

if (kfd->interrupts_active
&& interrupt_is_wanted(kfd, ih_ring_entry,
   patched_ihre, &is_patched)
&& enqueue_ih_ring_entry(kfd,
 is_patched ? patched_ihre : ih_ring_entry))
kfd_queue_work(kfd->ih_wq, &kfd->interrupt_work);

spin_unlock_irqrestore(&kfd->interrupt_lock, flags);
}


These functions seem to be exclusively invoked by amdgpu_irq_dispatch()
in amdgpu_irq.c
At first glance it seems to me that it's just a typical scenario taking
place here: Interrupt arises, interrupt submits work to wq, then jumps
back to sleep / former process execution context again.

What I don't understand is why it's apparently important to schedule
the work on a particular CPU.

It seems that the do-while in kfd_queue_work() is searching for a CPU
within the same NUMA-Node. Thus I suspect that this is done because
either
a) performance requires it or
b) the work-function needs access to something that's only available
   within the same node.

I suspect there is an interrupt-related reason why that particular work
should be enqueued on a specific CPU. Just by reading the code alone I
can't really figure out why precisely that's necessary, though.

Does someone have any hints for me? :)

Cheers,
Philipp



  

  

[PATCH v2] drm/i915: Refactor PAT/cache handling

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Informal commit message for now.

I got a bit impatient and curious to see if the idea we discussed would
work so sketched something out. I think it is what I was describing back
then..

So high level idea is to teach the driver what caching modes are hidden
behind PAT indices. Given you already had that in static tables, if we
just turn the tables a bit around and add a driver abstraction of caching
modes this is what happens:

 * We can lose the ugly runtime i915_gem_get_pat_index.

 * We can have a smarter i915_gem_object_has_cache_level, which now can
   use the above mentioned table to understand the caching modes and so
   does not have to pessimistically return true for _any_ input when user
   has set the PAT index. This may improve things even for MTL.

 * We can simplify the debugfs printout to be platform agnostic.

 * We are perhaps opening the door to un-regress the dodgy addition
   made to i915_gem_object_can_bypass_llc? See QQQ/FIXME in the patch.

I hope I did not forget anything, but anyway, please have a read and see
what you think. I think it has potential.

Proper commit message can come later.

Signed-off-by: Tvrtko Ursulin 
Cc: Fei Yang 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/display/intel_dpt.c  |   2 +-
 drivers/gpu/drm/i915/display/intel_fb_pin.c   |   2 +-
 .../drm/i915/display/intel_plane_initial.c|   4 +-
 drivers/gpu/drm/i915/gem/i915_gem_domain.c|  66 +-
 drivers/gpu/drm/i915/gem/i915_gem_domain.h|   7 +-
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  13 +-
 drivers/gpu/drm/i915/gem/i915_gem_internal.c  |   6 +-
 drivers/gpu/drm/i915/gem/i915_gem_mman.c  |  10 +-
 drivers/gpu/drm/i915/gem/i915_gem_object.c| 116 +
 drivers/gpu/drm/i915/gem/i915_gem_object.h|   9 +-
 .../gpu/drm/i915/gem/i915_gem_object_types.h  | 117 +++---
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c |  10 +-
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c|  13 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c  |  43 ---
 drivers/gpu/drm/i915/gem/i915_gem_userptr.c   |   2 +-
 .../drm/i915/gem/selftests/huge_gem_object.c  |   6 +-
 .../gpu/drm/i915/gem/selftests/huge_pages.c   |   8 +-
 drivers/gpu/drm/i915/gt/gen6_ppgtt.c  |   4 +-
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c  |  19 +--
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |   2 +-
 drivers/gpu/drm/i915/gt/intel_ggtt.c  |  33 ++---
 drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c |   4 +-
 drivers/gpu/drm/i915/gt/intel_gtt.c   |   2 +-
 drivers/gpu/drm/i915/gt/intel_gtt.h   |   3 +-
 drivers/gpu/drm/i915/gt/intel_migrate.c   |  11 +-
 drivers/gpu/drm/i915/gt/intel_ppgtt.c |   6 +-
 .../gpu/drm/i915/gt/intel_ring_submission.c   |   2 +-
 drivers/gpu/drm/i915/gt/intel_timeline.c  |   2 +-
 drivers/gpu/drm/i915/gt/selftest_hangcheck.c  |   2 +-
 drivers/gpu/drm/i915/gt/selftest_migrate.c|   9 +-
 drivers/gpu/drm/i915/gt/selftest_reset.c  |  14 +--
 drivers/gpu/drm/i915/gt/selftest_timeline.c   |   1 +
 drivers/gpu/drm/i915/gt/selftest_tlb.c|   5 +-
 .../gpu/drm/i915/gt/selftest_workarounds.c|   2 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc.c|   2 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  |   8 +-
 drivers/gpu/drm/i915/i915_cache.c |  72 +++
 drivers/gpu/drm/i915/i915_cache.h |  49 
 drivers/gpu/drm/i915/i915_debugfs.c   |  65 +++---
 drivers/gpu/drm/i915/i915_driver.c|   5 +
 drivers/gpu/drm/i915/i915_drv.h   |   3 +
 drivers/gpu/drm/i915/i915_gem.c   |  21 +---
 drivers/gpu/drm/i915/i915_gpu_error.c |   7 +-
 drivers/gpu/drm/i915/i915_pci.c   |  83 +++--
 drivers/gpu/drm/i915/i915_perf.c  |   2 +-
 drivers/gpu/drm/i915/intel_device_info.h  |   6 +-
 drivers/gpu/drm/i915/selftests/i915_gem.c |   5 +-
 .../gpu/drm/i915/selftests/i915_gem_evict.c   |   8 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c |  13 +-
 drivers/gpu/drm/i915/selftests/igt_spinner.c  |   2 +-
 .../drm/i915/selftests/intel_memory_region.c  |   4 +-
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  12 +-
 drivers/gpu/drm/i915/selftests/mock_region.c  |   2 +-
 54 files changed, 440 insertions(+), 485 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_cache.c
 create mode 100644 drivers/gpu/drm/i915/i915_cache.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 2be9dd960540..2c3da8f0c78e 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -30,6 +30,7 @@ subdir-ccflags-y += -I$(srctree)/$(src)
 # core driver code
 i915-y += i915_driver.o \
  i915_drm_client.o \
+ i915_cache.o \
  i915_config.o \
  i915_getparam.o \
  i915_ioctl.o \
diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c 
b/drivers/gpu/drm/i915/display/intel_dpt.c

Re: [PATCH 00/12] arch,fbdev: Move screen_info into arch/

[Thomas Zimmermann]

Hi

Am 29.06.23 um 15:31 schrieb Arnd Bergmann:

On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:

The variables screen_info and edid_info provide information about
the system's screen, and possibly EDID data of the connected display.
Both are defined and set by architecture code. But both variables are
declared in non-arch header files. Dependencies are at bease loosely
tracked. To resolve this, move the global state screen_info and its
companion edid_info into arch/. Only declare them on architectures
that define them. List dependencies on the variables in the Kconfig
files. Also clean up the callers.

Patch 1 to 4 resolve a number of unnecessary include statements of
. The header should only be included in source
files that access struct screen_info.

Patches 5 to 7 move the declaration of screen_info and edid_info to
. Architectures that provide either set
a Kconfig token to enable them.

Patches 8 to 9 make users of screen_info depend on the architecture's
feature.

Finally, patches 10 to 12 rework fbdev's handling of firmware EDID
data to make use of existing helpers and the refactored edid_info.

Tested on x86-64. Built for a variety of platforms.


This all looks like a nice cleanup!


I guess that patches 1 to 4 are uncontroversial and could be landed 
quickly. Patches 10 to 12 are probably as well.





Future directions: with the patchset in place, it will become possible
to provide screen_info and edid_info only if there are users. Some
architectures do this by testing for CONFIG_VT, CONFIG_DUMMY_CONSOLE,
etc. A more uniform approach would be nice. We should also attempt
to minimize access to the global screen_info as much as possible. To
do so, some drivers, such as efifb and vesafb, would require an update.
The firmware's EDID data could possibly made available outside of fbdev.
For example, the simpledrm and ofdrm drivers could provide such data
to userspace compositors.


I suspect that most architectures that provide a screen_info only
have this in order to compile the framebuffer drivers, and provide
hardcoded data that does not even reflect any real hardware.


That's quite possible. Only x86's bootparam and EFI code sets 
screen_info from external data. The rest is hardcoded. A number of 
architectures protect screen_info with CONFIG_VT, CONFIG_DUMMY_CONSOLE, 
etc. In a later patchset, I wanted to change this such that these users 
of screen_info would enable the feature via select in their Kconfig.


Do you know the reason for this branch in dummycon:

https://elixir.bootlin.com/linux/v6.4/source/drivers/video/console/dummycon.c#L21

What is special about arm that dummycon uses the screeninfo?



We can probably reduce the number of architectures that do this
a lot, especially if we get EFI out of the picture.


Can you elaborate?

Best regards
Thomas



   Arnd


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH 6/6] drm/amdgpu: use the new drm_exec object for CS v2

[Christian König]

Am 29.06.23 um 10:20 schrieb Tatsuyuki Ishi:

On 6/28/23 19:44, Christian König wrote:
@@ -958,18 +904,57 @@ static int amdgpu_cs_parser_bos(struct 
amdgpu_cs_parser *p,

  e->user_invalidated = userpage_invalidated;
  }
  -    r = ttm_eu_reserve_buffers(&p->ticket, &p->validated, true,
-   &duplicates);
-    if (unlikely(r != 0)) {
-    if (r != -ERESTARTSYS)
-    DRM_ERROR("ttm_eu_reserve_buffers failed.\n");
-    goto out_free_user_pages;
+    drm_exec_until_all_locked(&p->exec) {
+    r = amdgpu_vm_lock_pd(&fpriv->vm, &p->exec, 1 + p->gang_size);
+    drm_exec_retry_on_contention(&p->exec);
+    if (unlikely(r))
+    goto out_free_user_pages;
+
+    amdgpu_bo_list_for_each_entry(e, p->bo_list) {
+    /* One fence for TTM and one for each CS job */
+    r = drm_exec_prepare_obj(&p->exec, &e->bo->tbo.base,
+ 1 + p->gang_size);
+    drm_exec_retry_on_contention(&p->exec);
+    if (unlikely(r))
+    goto out_free_user_pages;
+
+    e->bo_va = amdgpu_vm_bo_find(vm, e->bo);
+    e->range = NULL;

Still leaking.


Scratching my head, I though I fixed this.

Thanks for pointing this out,
Christian.


+    }
+
+    if (p->uf_bo) {
+    r = drm_exec_prepare_obj(&p->exec, &p->uf_bo->tbo.base,
+ 1 + p->gang_size);
+    drm_exec_retry_on_contention(&p->exec);
+    if (unlikely(r))
+    goto out_free_user_pages;
+    }
  }

Re: [PATCH 00/12] arch,fbdev: Move screen_info into arch/

[Arnd Bergmann]

On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
> The variables screen_info and edid_info provide information about
> the system's screen, and possibly EDID data of the connected display.
> Both are defined and set by architecture code. But both variables are
> declared in non-arch header files. Dependencies are at bease loosely
> tracked. To resolve this, move the global state screen_info and its
> companion edid_info into arch/. Only declare them on architectures
> that define them. List dependencies on the variables in the Kconfig
> files. Also clean up the callers.
>
> Patch 1 to 4 resolve a number of unnecessary include statements of
> . The header should only be included in source
> files that access struct screen_info.
>
> Patches 5 to 7 move the declaration of screen_info and edid_info to
> . Architectures that provide either set
> a Kconfig token to enable them.
>
> Patches 8 to 9 make users of screen_info depend on the architecture's
> feature.
>
> Finally, patches 10 to 12 rework fbdev's handling of firmware EDID
> data to make use of existing helpers and the refactored edid_info.
>
> Tested on x86-64. Built for a variety of platforms.

This all looks like a nice cleanup!

> Future directions: with the patchset in place, it will become possible
> to provide screen_info and edid_info only if there are users. Some
> architectures do this by testing for CONFIG_VT, CONFIG_DUMMY_CONSOLE,
> etc. A more uniform approach would be nice. We should also attempt
> to minimize access to the global screen_info as much as possible. To
> do so, some drivers, such as efifb and vesafb, would require an update.
> The firmware's EDID data could possibly made available outside of fbdev.
> For example, the simpledrm and ofdrm drivers could provide such data
> to userspace compositors.

I suspect that most architectures that provide a screen_info only
have this in order to compile the framebuffer drivers, and provide
hardcoded data that does not even reflect any real hardware.

We can probably reduce the number of architectures that do this
a lot, especially if we get EFI out of the picture.

  Arnd

Re: [PATCH 07/12] arch/x86: Declare edid_info in

[Arnd Bergmann]

On Thu, Jun 29, 2023, at 15:01, Thomas Zimmermann wrote:
> Am 29.06.23 um 14:35 schrieb Arnd Bergmann:
>> On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
>>> The global variable edid_info contains the firmware's EDID information
>>> as an extension to the regular screen_info on x86. Therefore move it to
>>> .
>>>
>>> Add the Kconfig token ARCH_HAS_EDID_INFO to guard against access on
>>> architectures that don't provide edid_info. Select it on x86.
>> 
>> I'm not sure we need another symbol in addition to
>> CONFIG_FIRMWARE_EDID. Since all the code behind that
>> existing symbol is also x86 specific, would it be enough
>> to just add either 'depends on X86' or 'depends on X86 ||
>> COMPILE_TEST' there?
>
> FIRMWARE_EDID is a user-selectable feature, while ARCH_HAS_EDID_INFO 
> announces an architecture feature. They do different things.

I still have trouble seeing the difference.

> Right now, ARCH_HAS_EDID_INFO only works on the old BIOS-based VESA 
> systems. In the future, I want to add support for EDID data from EFI and 
> OF as well. It would be stored in edid_info. I assume that the new 
> symbol will become useful then.

I don't see why an OF based system would have the same limitation
as legacy BIOS with supporting only a single monitor, if we need
to have a generic representation of EDID data in DT, that would
probably be in a per device property anyway.

I suppose you could use FIRMWARE_EDID on EFI or OF systems without
the need for a global edid_info structure, but that would not
share any code with the current fb_firmware_edid() function.

 Arnd

Re: [PATCH 06/12] arch: Declare screen_info in

[Thomas Zimmermann]

Hi

Am 29.06.23 um 15:03 schrieb Arnd Bergmann:

On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:


diff --git a/include/asm-generic/screen_info.h
b/include/asm-generic/screen_info.h
new file mode 100644
index 0..6fd0e50fabfcd
--- /dev/null
+++ b/include/asm-generic/screen_info.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _ASM_GENERIC_SCREEN_INFO_H
+#define _ASM_GENERIC_SCREEN_INFO_H
+
+#include 
+
+#if defined(CONFIG_ARCH_HAS_SCREEN_INFO)
+extern struct screen_info screen_info;
+#endif
+
+#endif /* _ASM_GENERIC_SCREEN_INFO_H */
diff --git a/include/linux/screen_info.h b/include/linux/screen_info.h
index eab7081392d50..c764b9a51c24b 100644
--- a/include/linux/screen_info.h
+++ b/include/linux/screen_info.h
@@ -4,6 +4,6 @@

  #include 

-extern struct screen_info screen_info;
+#include 



What is the purpose of adding a file in asm-generic? If all
architectures use the same generic file, I'd just leave the
declaration in include/linux/. I wouldn't bother adding the


That appears a bit 'un-clean' for something that is defined in 
architecture? But OK, I would not object.



#ifdef either, but I can see how that helps turn a link
error into an earlier compile error.


Yes, that's intentional. If there's a Kconfig token anyway, we can also 
fail early during the build.


Best regards
Thomas



   Arnd


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)


OpenPGP_signature
Description: OpenPGP digital signature